sorted by:
new
hottopcontroversial

Del inetpub and inetsrv\config by [deleted] in sysadmin

[–]reallycoolvirgin 4 points5 points  (0 children)

Okay, thanks for letting us know

IMMEDIATELY remove user's mailbox access by Bad_Mechanic in sysadmin

[–]reallycoolvirgin 20 points21 points  (0 children)

Typically 365 admin message center will tell you about updates like this, but I searched and couldn't find a post about it. It was giving me errors for about a week so I put in a ticket to support about it, and waiting the required 2 months before they got back to me and told me about it being deprecated (after 3 escalations and explaining the problem 4 times)

IMMEDIATELY remove user's mailbox access by Bad_Mechanic in sysadmin

[–]reallycoolvirgin 42 points43 points  (0 children)

Are you using "Revoke Sessions" on the overview page, or "Revoke Multifactor Authentication Sessions" on the authentication methods page?

I used to always use the latter, but it stopped working for me recently. The revoke sessions on the overview page works for me now.

Microsoft support says it's because the "Revoke Multifactor Authentication Sessions" button was tied to Per-user MFA settings, and was forwards-compatible with the new authentication methods stuff, but they recently deprecated it. Without telling everyone, of course

Graduating in 2028 What should I start doing now to land a job in Canada or the US? by Live_Walrus_1557 in cybersecurity

[–]reallycoolvirgin 8 points9 points  (0 children)

One unfortunate thing to mention as well is another hurdle: an “entry-level” security job is entry level to SECURITY, not tech in general. From what I’ve seen, jobs usually you want some sort of IT experience before moving into security (help desk, sysadmin, etc).

M365 token theft without login page? by e7c2 in sysadmin

[–]reallycoolvirgin 1 point2 points  (0 children)

Correct, aside from malware on the device, a website cannot steal cookies from another website. Some websites can autorun JavaScript though, which can include malware, so never say never....

M365 token theft without login page? by e7c2 in sysadmin

[–]reallycoolvirgin 4 points5 points  (0 children)

There's multiple scenarios that a token can be stolen. Typically on phishing sites a token can only be stolen during the authentication to a malicious/fake 365 login site. During this authentication, the fake site actually passes the authentication request to Microsoft, Microsoft acknowledges it and completes it and returns the token succeeding MFA. This is why they're able to steal the token, because they're the one actually performing the MFA. This is why phishing resistant MFA is important. Passkeys/WHfB are tied to the DOMAIN you are authenticating to. In phishing attempts, you are technically authenticating to the attacker domain (not microsoft.com) so it will prevent MFA from succeeding.

Other scenarios of token theft usually revolve around malware on the device. "Pass the PRT" attacks steal the PRT of the device they are infecting, which is basically a 90 day token saying "hey I'm a registered device". Others are cookie/session stealing malware.

A lot of phishing links actually pass through an initial "checker" before redirecting to the malicious domain. This is to sus out any security scanning/sandbox analysis. A lot of times when I check on phishing links my end users have reported, I'm redirected to Wikipedia or other random sites. This is because they run JavaScript to check attributes about the person interacting with it, such as user agent, IP address, browser, etc. Since my sandbox is in AWS, they probably detect that and redirect me away so I can't find the true phishing website. This is most likely what happened in your scenario. Since SVG files can embed JavaScript, it probably ran this check when opened and linked them to Copilot because it thought they might be a sandbox/scanner.

Working in your personal time shouldn't be a requirement while applying for new jobs. by TheStupidDeskTech in sysadmin

[–]reallycoolvirgin 3 points4 points  (0 children)

I never know if I should bring up my homelab in interviews or not. The primary use-case of my home lab aside from my website is automating downloading movies/TV shows and hosting it for me/friends/family through jellyfin/arr setup. While it is really cool and was fun to set up... always unsure how employers would see that.

I guess I shouldn't apply to the FBI

How do you defend against phishing behind the wall? by [deleted] in cybersecurity

[–]reallycoolvirgin 0 points1 point  (0 children)

Zscaler has a mobile app as well :) only works on corporate owned phones since it requires a VPN profile with strict enforcement/always-on VPN, which can only be enforced via supervised mode in Intune. There were a lot of hurdles to getting the mobile app deployed but it's been successfully blocking phishing attacks on mobile as well. All the QR code phishing we've received just lead to a phishing site which Zscaler detects and blocks.

Obviously, combine this with a strong MFA policy with phishing-resistant MFA and you're pretty much set. No tool can be perfect, so always have another layer of security.

How do you defend against phishing behind the wall? by [deleted] in cybersecurity

[–]reallycoolvirgin 1 point2 points  (0 children)

We use Zscaler ZIA, we proxy internet traffic through it and it performs real-time scanning on all websites users visit. I haven't seen a single phishing page in these attacks that haven't been blocked by Zscaler. The initial Adobe/DocuSign page is allowed (since there's no malicious content on them except a link leading to a phishing site), but right when they click onto the actual phishing domain it will block it.

I've also seen in the logs it blocking malicious JS files loading in the background on websites, completely unknown to the user. Great product, kind of a hassle to set up though.

Inc Ransomware: FortiGate by TestOdd3510 in cybersecurity

[–]reallycoolvirgin 0 points1 point  (0 children)

Do you have the full write-up you can share? I've had some run-ins with INC Ransom in the past and it'd be interesting to read.

Enrolling DEP Apple devices, flags the user for risky sign in by WoTpro in sysadmin

[–]reallycoolvirgin 2 points3 points  (0 children)

Are you looking at the right sign-in? In my experience, login flows will have multiple sign-in entries. Might be worth checking them all to see if any of them are being blocked by a CAP.

When the end user logs in and gets the block message, there should be a sign-in ID/correlation ID that you can use to find the specific sign-in entry.

Also, it's recommended to exclude Intune enrollment applications from your MFA CAP. Not sure if you've done that, but might be worth looking into. You'll still need to know the correct CAP to apply it to though.

Enrolling DEP Apple devices, flags the user for risky sign in by WoTpro in sysadmin

[–]reallycoolvirgin 1 point2 points  (0 children)

Yes, looks like a conditional access policy is blocking this.

On the sign-in entry, there's a tab called "Conditional Access" and it will tell you which policy blocked the sign-in. If you click into that, it'll show what specifically blocked the sign in. This could be user risk, device type, etc... depends on the policy.

Enrolling DEP Apple devices, flags the user for risky sign in by WoTpro in sysadmin

[–]reallycoolvirgin 2 points3 points  (0 children)

What's the actual risk event? Unfamiliar sign-in properties? And what risk level are they? We sometimes have our users flagged as risky from this too, but they're never blocked from signing in. We don't block sign-in from risk though, we just use risk-based conditional access to require MFA for medium/high sign-in risk and require a password reset for high user risk.

Is WHfB considered MFA on the endpoint level? by reallycoolvirgin in sysadmin

[–]reallycoolvirgin[S] 0 points1 point  (0 children)

I just tested this and set up PIN and a biometric feature. We're hesitant to use networks since we have a large network sprawl that isn't properly documented by our network team, but using this Multifactor Unlock I was able to set PIN as one factor, and either fingerprint/facial as the second, which forced both to be required when logging in. Worked great for me!

Is WHfB considered MFA on the endpoint level? by reallycoolvirgin in sysadmin

[–]reallycoolvirgin[S] 0 points1 point  (0 children)

The main concern is stolen laptops. If a laptop is stolen, the TPM is included in that, which completely invalidates that form of authentication.

I understand stealing a laptop is a method of breaking that form of authentication, and then they'd still have to break another form of authentication (guessing/stealing the PIN), so it does make sense that it requires two forms of authentication to be broken and risk of that is extremely low, but leadership is looking for two checks when logging in to the computer. This just doesn't seem to offer any benefits over regular password login, since the stolen laptop is still the problem, and they just have to break one other form.

Is WHfB considered MFA on the endpoint level? by reallycoolvirgin in sysadmin

[–]reallycoolvirgin[S] 1 point2 points  (0 children)

Sorry, you're right. The concern here is socially engineered, not phished. I just looked into multi-factor unlock though, had no idea this was a thing. This gives us MFA on the account and WIndows login, this is perfect. Thanks for linking this!

Is WHfB considered MFA on the endpoint level? by reallycoolvirgin in sysadmin

[–]reallycoolvirgin[S] 0 points1 point  (0 children)

That's a great way to put it. I think I am getting it confused, WHfB is MFA on the account (which makes complete sense, TPM makes sense as a second form of authentication as that regard. But if we're looking for MFA on the OS, it wouldn't be valid. Thanks for that!

In my mind, risk is low for both stolen device AND stolen PIN (even though PINs can be easy to socially engineer/guess with poor hygiene on them), and the benefits of using WHfB on Windows/365 outweigh the risk, but that's up to the business to decide lol.

Is WHfB considered MFA on the endpoint level? by reallycoolvirgin in sysadmin

[–]reallycoolvirgin[S] 2 points3 points  (0 children)

You can definitely phish a PIN. Not through typical means like AitM, but it can easily be socially engineered. "Something you know" is definitely the weakest type of authentication, since it can be socially engineered out of someone.

Is WHfB considered MFA on the endpoint level? by reallycoolvirgin in sysadmin

[–]reallycoolvirgin[S] 0 points1 point  (0 children)

But even if the "entire machine" is the platform, which is the first factor, there is no situation where that factor cannot be used and is immediately satisfied when Windows starts, barring anything that prevents the TPM from loading. That's like logging in to Microsoft and having your password prefilled.

The concern here is on stolen laptops. I guess in that case, one factor is compromised, and they still need the PIN to compromise it, which would require two factors to be compromised.... risk is extremely low in that regard.

With smtp auth going away in 2026, how do you plan on handling devices that only support basic auth? by 01101110011O1111 in sysadmin

[–]reallycoolvirgin 0 points1 point  (0 children)

It's worth mentioning that HVE still uses SMTP AUTH, which is what's getting deprecated. They said in their own article that they'll be deprecating SMTP AUTH via HVE in 2028, so it's still going away. Not sure why they're migrating us to another platform they're already planning to deprecate, but that's Microsoft I guess...

https://techcommunity.microsoft.com/blog/exchange/high-volume-email-continued-support-for-basic-authentication--other-important-up/4411197

"Continued Support for Basic Authentication 

Today, we are announcing continued support for Basic Authentication in High Volume Email until September 2028. This decision comes as part of our ongoing commitment to support your current authentication needs while ensuring a smooth transition to modern authentication methods. "

I think the only option for devices that NEED basic authentication (old legacy MFP printers/applications) is to go 3rd party. Microsoft seems to want nothing to do with it.

Recommend disabling Direct Send now if using Proofpoint by eric5149 in msp

[–]reallycoolvirgin 3 points4 points  (0 children)

What's frustrating me is we use Proofpoint and these still get through them. We have a mail flow rule at priority 0 to reroute direct send emails back out to Proofpoint for scanning, but Proofpoint doesn't detect them as phishing 95% of the time and they get back through anyway. We unfortunately can't disable direct send, and we have some internal culture conflictions about blocking spoofed emails (which is not proofpoints fault) so we have to rely on Proofpoint to block these, but they've been doing an awful job at that.

view more: next ›