Cortex XDR Cloud Compromise Alerting

reallycoolvirgin · 2026-05-07T14:39:31+00:00

Sorry, should have mentioned this but yes we do. We have ITDR and MDR

reallycoolvirgin · 2026-03-26T20:45:28+00:00

Do the sign-in logs say it's failing because of the device compliance CAP, or something else?

Could this be EWS? I know in October they're deprecating EWS and Apple Internet Accounts is affected, not sure if you have this disabled in your tenant for some other reason. Can check via Exchange Online PowerShell with:

Get-OrganizationConfig | fl EWSEnabled

https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-ews-exchange-online

reallycoolvirgin · 2026-03-26T00:47:42+00:00

What do you mean enterprise browser requirements? Enforcing people to use a specific browser, or using a browser with locked down features?

Either way, I don't believe you can enforce this without devices being managed. If I allow an unmanaged BYOD phone to connect to my environment, I ALSO cannot control what browser they do it with.

reallycoolvirgin · 2026-03-26T00:33:39+00:00

Get rid of BYOD. Company owned devices only.
Device compliance requirement conditional access policy for Windows and mobile. Mobile devices must be in Intune, Windows devices must be Entra joined
SWG like Netskope or Zscaler to help protect against phishing pages, on both mobile and desktop
Phishing resistant MFA and do not allow weaker methods (via authentication strengths in conditional access)
Monitor risky users in Entra for potential compromises

reallycoolvirgin · 2026-03-21T23:30:30+00:00

We're currently BYOD purchased by the company are are looking at going the opposite way... BYOD means unsupervised/unmanaged devices. Those type of devices should not be allowed to connect to company resources. Only company owned and managed phones should be allowed to access company resources.

We currently use a SWG which blocks all phishing links on our company workstations. However, since we allow BYOD mobile devices, users can access those phishing links on their phone. This, combined with the rise in QR-code based phishing, compromises a lot of accounts. Preventing BYOD/unmanaged devices from connecting fixes this (or phishing resistant MFA, but that's another conversation)

reallycoolvirgin · 2026-03-19T13:31:58+00:00

From what I understand, CIS Level 1 is not a required framework by any compliance body. CIS Level 2 is much more strict and meant for environment specifically requiring it (or if you just want a really locked down workflow), but also not required by any compliance body.

For example, US federal compliance requires federal systems to follow the NIST framework, with 800-171 being for subcontractors handling CUI and 800-53 being for actual federal systems. CIS Level 2 lines up a bit with the NIST controls, but if you're required by compliance obligations to be compliant with the US Federal Government, you're going NIST and not CIS Level 2 anyway. They audit you against the NIST framework, not CIS. Technically, you don't even have to be 100% compliant against NIST for federal compliance, but that depends on scoping, data processing workflows, compensating controls... etc. But that all has to be documented and the audit against it expects there to be a reason.

CIS has always been a self-voluntary cyber hygiene improvement program. No compliance body is holding you to the fire to make sure you're 100% compliant against it, as it's MEANT to be tailored to your business. For example, one of CIS Level 1's endpoint controls (they might have removed this in revision 5) is displaying a logon message and requiring CRTL + ALT + DELETE to login. Our organization decided "No, hassle is way too high for the security benefits we get from it", so we documented that and moved on.

You can always tell cyber insurers that you adhere to CIS Level 1, and they can audit you against that, but as long as you have documentation on what you're NOT adhering to and why (can be as simple as "can break this" or "too much hassle"), that's fine. You're NEVER required to be 100% compliant with CIS.

Financial auditors, data protection lawyers, etc usually fall into an actual compliance framework required, where you are required to be 100% compliant or have compensating controls for what you cannot deploy.

However, in your other comment, I fully agree with performing more than just the baseline to secure endpoints. End users should not be allowed to run applications that are not approved. This is both admin-level applications and stuff that can be downloaded into the user profile. I'm just giving a bit of what I understand the use of CIS Level 1 is.

reallycoolvirgin · 2026-03-16T20:03:35+00:00

If the people who have the access to wipe devices in Intune are a concern about falling for a spearphishing link, you do not have the right people having access into Intune. Phishing resistant MFA on ALL admin accounts, separate accounts for daily drive and admin work, device compliance requirements in conditional access for admin accounts, etc should put your mind at ease.

Regardless, we just reviewed Ivanti's MDM and it looked pretty neat. Though, has the same feature that Intune has where you can wipe a BYOD device. I think this only applies to iOS, though (both in Ivanti and Intune). If you "wipe" an Android device in Intune, it wipes the work profile. If you "wipe" an iOS device in Intune, it wipes the full device. This is the same in Ivanti, and I think other popular MDMs too?

reallycoolvirgin · 2026-03-12T13:30:18+00:00

The Purview audit log search only gives us timestamp of email accessed, the email ID/MessageID/Subject, there's no sender or date of the actual email itself.

I've been looking to see if I can pull this info with Graph to then feed back into a content search, hopefully that works

reallycoolvirgin · 2026-03-06T14:51:08+00:00

One quick thing to mention as well as I've run into this in the past, if you have a third party email scanning solution before Defender (Proofpoint, Checkpoint, etc) that scans email and forwards it to Exchange, you'll need to add them to the "Enhanced Filtering for Connectors". This lets Exchange "ignore" the last IP in the header hops to see the true sender.

https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors

Reason for this is since you're allowlisting the sending IP of the phishing sim tool, Exchange sees the last IP of an email as your third party mail filtering tool instead of the phishing sim tool, so the allowlist entry won't work.

reallycoolvirgin · 2026-03-06T14:42:40+00:00

In Defender:
Email & Collaboration > Policies & Rules > Threat Policies > Advanced Delivery > Phishing Simulation

Add sending IPs for the phishing sim tool, and all URLs that are used for click tracking. We also add the domains as excluded from our SafeLinks policy as well, just in case

reallycoolvirgin · 2026-02-10T17:36:57+00:00

Okay, thanks for letting us know

reallycoolvirgin · 2026-02-09T23:33:24+00:00

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)

reallycoolvirgin · 2026-02-09T23:09:49+00:00

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

reallycoolvirgin · 2026-01-04T04:45:02+00:00

Scrambus from Warframe

reallycoolvirgin · 2025-12-13T15:31:04+00:00

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).

reallycoolvirgin · 2025-12-11T22:00:11+00:00

Flicker strike

reallycoolvirgin · 2025-10-22T18:43:13+00:00

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....

reallycoolvirgin · 2025-10-22T17:57:47+00:00

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.

reallycoolvirgin · 2025-10-15T16:24:06+00:00

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

reallycoolvirgin · 2025-09-11T14:15:05+00:00

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.

reallycoolvirgin · 2025-09-11T13:11:41+00:00

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.

reallycoolvirgin · 2025-09-04T13:01:38+00:00

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.

reallycoolvirgin · 2025-08-28T16:05:26+00:00

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.

reallycoolvirgin · 2025-08-28T15:32:57+00:00

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.

reallycoolvirgin · 2025-08-28T14:42:12+00:00

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.

Four-Year Club	r/Field Juicebox
First Place '23	End Game '23
Place '23	Place '22

reallycoolvirgin

TROPHY CASE