It seems that every week that the mentions of token theft increase, or even the mention of similar attacker-in-the-middle style of attacks are sweeping the forums, Reddit, that one edgy former bird site, Bluesky, etc. Someone’s account was compromised, but it never triggered conditional access; maybe triggered an identity alert in Entra, or a risk event, but was generally quiet.
Stealing tokens isn’t necessarily new – the same with cookies – but it is gaining traction. Why? My head-canon is that threat actors are running into more multi-factor authentication (MFA) and people are starting to adopt conditional access in greater numbers. However, misconfigurations, misconceptions, and weak MFA options still abound. One way to bypass the controls that has proven effective is by stealing the tokens - why try and SIM swap or keep sending MFA pushes to a user when you can just have the user actually authenticate for you? I’ll add - and authenticate properly and legitimately?
That right there, to me at least, is the allure of this AiTM style of attack. The bonus with this is that it’s extremely hard to detect. The session looks valid; it’s using the same access token or refresh token that the user just authenticated with - it doesn’t yell, “hI I’m A bAd aCtOr!” like some other attacks might signal.
For example, with an MFA fatigue attempt, you can detect based on the volume of requests, provided you are monitoring it, of course (and you should be!). User training combined with monitoring through a SIEM system and even proactively auditing your users can combat most of these, but when the sessions look normal and pass the sniff tests, what do you do?
The answer is a combination of machine learning, risk-based detections for sign-in events, combined with Entra Identity Protection, and conditional access - these are all parts of the solution right now.
To become another part of the solution, we turned to anomaly detection. Our Microsoft 365: User Session Token Anomaly detection is just the first step we’re taking to identify and respond to this behavior. This detection has several parts to it, but before we get to that, we need to know what these attacks have in common and what they look like.
Our team dove in headfirst and began emulating the attacker behavior, reading through documentation of attacks and looking to Microsoft for how they cover detecting this behavior.
Microsoft References:
With that knowledge in hand, we first need to establish a mini-baseline as part of the detection as we can’t detect what’s abnormal without first knowing what is normal - statistically speaking of course. This needs to happen on the fly as well with some form of history or memory. Now I can’t give every detail away - but I will say this is something that we are constantly looking at to tune so that the results become more accurate and are working through customer feedback all the time to gauge if we are hitting the mark. Also, we had to keep in mind one of the hallmarks of Session Token Theft is that the session IDs remain the same throughout the attack.
Next, we start looking at calculating the deviations. These can be things like the amount of unique IPs, the browsers used, user-agent strings, devices, the amount of operations performed within the session, and more. All of these enter into the calculation. Some things are weighted a bit higher than others, but each can be tuned individually by our detection engineers to give us more control over the detection easily and quickly, should a quick adjustment be necessary in the future.
Once we have all the data and all the sessions within our time period, we can see the spikes and dips and pull out the statistically significant deviations. We group these by session and by user, which then makes it to our Blumira customers as a detection they can investigate (see the example from our platform below).
This is not foolproof; this can and does sometimes surface normal behavior that just happens to deviate on occasion - we’ve all done this, “I’m going to clean out my OneDrive today” or “I think I’m going to work from this coffee shop, oh wait, maybe 2 coffee shops today” the list goes on. That’s why we’re working closely with our CX team to gather feedback and tune as needed.
The benefit though is a tight feedback loop as well as a detection that can surface far more than potential sessions involving session token theft, cookie theft, and other AiTM (attacker-in-the-middle) style attacks in Microsoft 365.
Blumira’s new rule helps identify credential access attacks against your environment. This detection identifies when at least one Microsoft 365 user has been seen displaying anomalous behavioral patterns that deviate from their normal activity (based on sessions observed).
Security Impact: Why Should You Care?
This could be a sign of a token theft attack. Attackers can use refresh tokens to gain persistent access to different services, allowing them to conduct discovery, send emails, steal data, and more. This type of activity can be hard to detect for typical security solutions, since the behavior blends into normal user behavior.
Threat Response: What Should You Do?
Blumira alerts you by sending you a finding and giving you steps to take for further investigation. Using Blumira’s M365 Threat Response, you can also take action to immediately disable the M365 user and revoke sessions.
Learn more about M365 Threat Response – Microsoft 365 Threat Response lets you respond to suspicious activity in your Microsoft 365, Azure, and Entra environments directly from Blumira as soon as you receive a finding notification. You can disable users and revoke their sessions from supported findings in the app without signing into Microsoft 365.