A Clean Session Isn't Clean Forever
Over the past few months, we've been tracking a sharp rise in device code phishing attacks.
The technique abuses Microsoft's OAuth 2.0 device authorization flow, a feature built for sign-in on devices that can't handle a password prompt (smart TVs, printers, CLI tools). The attacker generates a code on their own infrastructure, phishes the victim into entering it on Microsoft's real login page, and walks away with a valid session tied to the victim's account. We're seeing these attacks hit C-suite executives and law firms particularly hard.
The attacks break a core assumption defenders rely on: a session that was benign at creation stays benign forever. In the cases below, sessions Microsoft minted for legitimate users, on legitimate devices, end up being controlled by attackers. The telemetry doesn't go back and relabel it.
That's the thread through the three cases below. Part 2 will cover what happens after the attacker is inside.
Case 1: A Longstanding Session Turns Malicious
A user at [Company A] receives an email: "Re: [Company A]", from a Gmail address posing as a business contact. The email walks the user to microsoft.com/devicelogin with a code to enter. The user, looking at a genuine Microsoft URL, enters it.
Minutes later, the attacker is logged into Microsoft 365 as the user, from a workload on Railway (a developer cloud platform). No MFA challenge fired, because device code flow trades the need for credentials on the device for the code-entry step the user already did.
Case 2: The Attacker's Login Shows Up on the User's Own Registered Device
We’ve been seeing attackers use a lot more than just Railway infrastructure in these device code compromises. Here’s one from a proxy IP belonging to Nord VPN.
What makes this one particularly gnarly is the malicious logins appear to come from the user’s registered company device. This user works at [Company B]. The device name on the login is [companyB]-pc014: the user's real registered workstation. This is the name the user's laptop has been reporting to Entra for months.
How can the malicious logins appear to come from the user’s own device?
Device code flow, by design, binds the resulting session to the authenticating device. Once the user entered the code on their laptop, Microsoft associated the attacker's session with the laptop's device record. The attacker then used that session from a proxy, and the device name came along for the ride.
This has some pretty serious consequences for defenders:
A Conditional Access policy trusting registered devices would pass this login.
A "new device" alert wouldn't fire.
The device is still the same registered workstation it's always been, but the activity is now the attacker.
Case 3: The Attacker Hides With a Residential Proxy
A user at [Company D] fell for an "Invoice Remittance" lure from a compromised trusted vendor.
This time, the attacker tried really hard to blend in by using a residential proxy in Tennessee. This IP belonged to an ISP called Clarksville Department of Electricity. The real user is based in Nebraska.
While some of these malicious device code logins come from known, malicious infrastructure like Railway, those are just the tip of the iceberg.
We've also seen attackers come in over consumer VPN exit nodes and residential proxies, all in an attempt to blend in with normal user traffic. The attacker in this case used a residential ISP in Tennessee, two states away from where the user actually lives.
Blocklisting known bad IPs is a great starting point, but it's not enough.
Just like in the first example, the session ID on the attacker's login wasn't new. In the Microsoft telemetry, there were several instances of this session ID being associated with this user before, under legitimate circumstances. Once the user enters the code, a token is minted and bound to that session ID. From then on, anyone holding the token can present it to Microsoft from anywhere, including a residential proxy two states away, and Microsoft sees a continuation of a session it has already observed. These tokens can live a long time, so the attacker can disappear for weeks and come back from a different residential IP producing zero new login events.
The session ID was one the user had used before, and will keep being one the user used before.
Takeaway: A Session Is Only As Clean As The Last Person Holding It
Most detection stacks trust what Microsoft's session records say: registered device, known session, familiar user. Cases 2 and 3 show why that trust is misplaced. A session is only as clean as the person currently holding the token. Once the token moves, nothing in the login metadata moves with it.
Of the three cases above, two tenants were on Petra at the time. In both, the attacker was caught within two minutes and never got a chance to do anything with the session.
The third tenant was being monitored by another ITDR product. The attacker had more than two hours of unmonitored access before the compromise was caught. In that window, they accessed more than 5,000 emails, sent over 1,500, and deleted 50.
That gap is what Part 2 is about.
If you're defending Microsoft environments against stealthy account compromise, schedule a demo today.