Bunkers and Storms, Oh my!

The weather has turned stormy. Late last week, we saw several reports on attacks in the wild by various Russian threat actors such as Storm-2372 and CozyLarch using techniques such as Microsoft device code phishing to hijack sessions and gain initial access.

• ‍Multiple Russian Threat Actors Targeting Microsoft Device Code Authentication (Veloxity, 2/13/2025), which reviewed how device code phishing has been used for abuse

• ‍Storm-2372 conducts device code phishing campaign (Microsoft, 2/14/2025), which covers not just device code phishing including but specific use of the Microsoft Authentication Broker client id for stealth and evasion.

Are we overreacting or is it time to believe Chicken Little that the skies are rapidly lowering?

"There are some things you can only learn in a storm." – Joel Osteen

While initial analysis has rightfully focused on the TTP observed in the wild, we should take this opportunity to review OAuth abuse and identify what’s new vs known, what have we learned, is this indicative of an attack pattern, what are the defensive gaps, and importantly, how we can get ahead of the “next one.”

And while it may be tempting to think of this as an isolated incident or to thank the security gods that “it wasn’t me,” it’s clear that OAuth-related attacks and abuse are on the rise. Microsoft Blizzard (January 2024) showed how OAuth can be abused not just for initial access, but for privilege escalation and persistence. And if it can happen to Microsoft....

The latest Storm-2372 device code phishing attack is not an isolated incident when looking at the broad OAuth threat landscape, and we need to more fundamentally understand the problem and the attacker if we are to do better from a defensive perspective. 

An OAuth recap

“Never Put Off Till Tomorrow What You Can Do The Day After Tomorrow Just As Well”--Mark Twain

Security researchers have published a great deal about Microsoft OAuth device code phishing abuse for over four years, and now this technique is being used in the wild. Unfortunately, there is some déjà vu, much like the two-year window between research and exploit i.e., CyberArk’s Golden SAML research (11/21/2017) and the in-the-wild exploit at SolarWinds (2019-2020). Here’s a recap of the state of OAuth, Microsoft controls, and security research:

‍

‍

Researchers have found that Microsoft implemented an authorization protocol for SSO purposes but did not use OIDC (OAuth SSO framework) but rather a custom implementation, which ended up introducing a higher risk of phishing attacks, more evasion via impersonation of Microsoft apps, and opened up lateral movement to over 30 Microsoft apps including Azure, all with little logging and controls to support detection. 

‍

‍

There are multiple attack variants including attacks to obtain the Primary Refresh Token (PRT) to gain higher levels of trust/access at the domain-joined device level as well as non-phishing variants that brute-force access then use OAuth token abuse to move laterally.

What’s been done

"Sometimes, all you can do is tread water and wait for the storm to pass."--Anonymous

Microsoft has added logging (non-interactive logs including device code refreshes of tokens), changed (improved) Conditional Access Policies (CAP) at least twice in 2024, and added more session revocation features to Continuous Access Evaluation (CAE). They have also shared plans for binding of OAuth tokens to devices when discussing DPOP plans for OAuth token binding (RSA 2022). 

What’s to be done

“History Doesn’t Repeat Itself, but It Often Rhymes” – Mark Twain

But old problems have persisted, while some new problems have appeared. CAP is imperfect–avoiding device code flows completely can be a non-starter because of valid apps that use device code flow (Azure CLI, admin Powershell scripts, and other tools). And making CAP work with IP or device binding and device code flow and some apps can be difficult at best. CAP has been known to have holes in it. 

There are more logs but the semantics are confusing from an IR/detection viewpoint: the lack of session semantics, non-interactive services that use device code flow (Microsoft Authentication Broker, device registration, Primary Refresh Tokens, Azure Portal, ADIbizaUX), including mobile apps that may be transferring authenticated state to other devices using authentication transfer.

"You can't fight a hurricane with half an umbrella"--Isabel Sterling

Much of the challenge comes down to:

• The logging continues to have gaps and is difficult to construct accurate high-level views of what identities on which devices are truly doing what with which applications.
• Conditional Access Policies continues to change and has gaps.
• Continuous Access Evaluation can mitigate some situations such as revoking refresh tokens under certain conditions, but this is another downstream layer trying to mitigate difficulties in a complex token system.

What’s a security professional supposed to do?

"Where there is no solution, there is hope." - Albert Einstein

Understand the problem.

Before we start implementing solutions, let’s acknowledge that by definition, these attacks are session and session token attacks in a 3rd-party authorization/delegation frame (OAuth 2.0).

Microsoft’s implementation of device code flow is customized and is prone to more phishing abuse due to the allowance of 30+ of its own apps (FOCI) and additional services (Microsoft Authentication Broker) to be used with device code flow, and to be used for SSO, allowing dynamic changing of permissions (scopes) without additional user authorization.

The gaps in the logs obscure what is really happening within an authenticated session by a user or service.

It is dangerous to categorize this as a phishing, therefore user problem. As Flangvik pointed out in his DEFCON 30 talk, password-spraying can be effective to obtain access and OAuth tokens while still leveraging the SSO lateral movement and defense evasion with Microsoft OAuth. Additionally, Azure CLI is a common tool that can use both device code flow as well as authorization grant code flows, which allows additional attack variants for obtaining OAuth tokens. And Mollema has shown how different targets such as the PRT can be combined with device code phishing as another attack vector that results in even higher levels of permissions. This leads us to trying to understand more effective and broader approaches to defending against OAuth abuse.

That’s the bad news. The good, is that knowing the bad news allows us to move more clearly ahead with solutions.

Checklists can be helpful …

Only if you know what was left off the list! Checklists are usually security configuration settings or detection rules, which is a great start to reducing obvious threats and locking down environments so the problem doesn’t get bigger. Restricting consent policies or access with CAP is a good idea. Detecting suspicious application behavior at sign-in with multiple failed logins from untrusted devices is a good idea. But these only go so far, and additional detections are required to see if controls are bypassed.

We need to assume breach ‍

Or rather, that every part of the attack chain can be exploited and every defensive layer can be bypassed. All preventative measures and detection measures are imperfect. This prepares us to invest additional resources at detections at all steps of the attack chain.

It’s all about the session.

‍A session problem requires a session solution e.g., understanding of sessions, visibility into sessions, tracking of the circumstances around the formation of sessions. This is a modeling problem and a data classification problem. If we can’t focus on all activities for one user session, we will not be able to detect device code phishing attacks or PRT attacks. For example, we need to know how device code authorization starts with interactive events, causes non-interactive events, that they are correlated by a correlation_id but that the session_id is too broad as it encompasses multiple application sessions by the same user.

Signals matter.

‍If you model and classify right, you get higher fidelity signals for detection. The correlation of the signals matter, which will allow us to detect failed or broken sessions or match activities to sessions. In this case, being able to detect an incomplete session for device code flow, for example: a refresh token call that never started with a proper interactive, user authorization can be the difference between identifying an OAuth attack vs. valid device code flow.

Algorithms and analysis are key.

Detection has to go beyond rules and correlation. Machine learning will play a key role for more robust anomaly detection. Attackers are smart, and know that conditional access policies based on IP address, user agent, ASN, and even application ids can be bypassed with attack variants. Focused and properly trained models and other AI techniques can be effective when designed around specific high-fidelity indicators based on real attack techniques.

We’ll explore more of these topics in the coming weeks.

‍