User Compromised via EvilTokens - Question
Posted by HovercraftSilver9379@reddit | sysadmin | View on Reddit | 15 comments
Hello,
I recently discovered one of our M365 users was compromised on Friday 5/15, via EvilTokens. I went through the usual remediation steps.
I have a question though - Why was our CA not triggered for Risky User/Risky Sign-in? I have it configured to trigger on medium and high risks for both sign-in and user risk.
Sign-in logs indicate 2 separate sign-ins from two different locations at the same time. Wouldn't this have at least triggered impossible travel? There was 0 risk associated with these sign-ins. Very confusing to me.
Maybe I have to CAs configured incorrectly? Any input is appreciated!
Theycallmethediddler@reddit
Was it a Device Code flow login?
HovercraftSilver9379@reddit (OP)
Yes
I've since created a CAP to block device flow authentication. It's in report mode for now, just to make sure I'm not blocking any legitimate authentications. From what I've seen in historical logs, I can probably just enable it and be fine as the only logs from the last 30 days were these malicious ones.
cantdrawastickman@reddit
Azure cloud shell uses devices login. Only legitimate thing I've encountered in our environment since blocking it everywhere.
PTCruiserGT@reddit
Thought you could use a service principal with a certificate in cloud shell?
Latter_Reception_600@reddit
Add a CAP for authentication transfer (in the same link above) just for good measure... Device flow should be caught by geoblock policies, but of course only if it's not originating from your country.
I've added reporting CAPs for those two right after they hit the news, so far they are not common in my org. It should be safe to block them soon
Lava604@reddit
I would advise checking to ensure they did not register their own devices. It immediately attempts to register devices after getting access.
lart2150@reddit
This reminds me I still need to disable device codes https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows
I've found risky signins to be not the best. in the past when I've had users phished there was low risk for anonymous ip. I then worked on building out a bunch of locations based on announced blocks on the same as the anonymous ip. the CA policy I have based on those locations annoys my users but then I tell them not to work on something like nord vpn.
bjc1960@reddit
How do you block ASNs in CA?
lart2150@reddit
With named locations. step 1 is creating a named location with all if the cidr blocks. There is a limit on the number of cidr blocks you can add to a named location so I use some tools to get the list of cidr blocks and then collapse then.
bjc1960@reddit
I have added CIDR before but I bet there are a lot with these. -thx
lart2150@reddit
M247 has 2,478 🙃 but a lot of bad actors come from their AS numbers. Datacamp is second at 1,680.
HovercraftSilver9379@reddit (OP)
Risky Sign-ins has caught some in the past, but I'm just completely confused as to how it missed this one entirely. The only reason I caught it was because I was looking at sign in logs to diagnose a separate issue and noticed the sign in from Germany. I've since implemented a location based CA.
I have also created a CA to block device flow authentication, but have in report mode only for now. From what I've seen, the only sign ins from the last 30 days using device flow were these malicious ones.
ProfessionalWorkAcct@reddit
Its great when it works but mother fuck it sucks when it doesn't flag the login as low medium or high. I don't understand it either. User logs in California, next login 3 minutes later New Jersey and it doesn't do a fucking thing.
Secret_Account07@reddit
Yeah it’s strange because that’s simple coding for a flag. I mean, most of us could figure out how to code that in an afternoon.
If country changes within x amount of minutes or distance is x miles within y minutes…like how does that not get flagged lol
Kinda wild
anxiousinfotech@reddit
Yet I log in from an Azure VM I've logged in from regularly for the last 3 years, medium risk, forced password change.