Device Code Phishing, Part 2: What Attackers Do After They Get In

In Part 1, we covered how attackers use device code flow to steal a user’s session. Now, let’s dive into what the attacker does with the session, and why most of those actions don't look malicious on the surface.

‍

The First Problem: The Login Is Real.

When a user enters a device code on a phishing page, Microsoft gives the attacker the user’s real session. The session is authenticated, MFA is satisfied, and every subsequent request the attacker makes looks like the real user (at surface level). 

As we covered in Part 1, the login often comes from the user's own registered device, which means even device-based controls pass it cleanly. The proof of compromise is downstream of logins and devices, making this a blindspot for tools that only monitor authentication activity.

You can no longer ask "Does this login look like the real user?" You have to ask "is this session doing things the real user would?"

That's a different question, and it requires different telemetry. Two patterns consistently show up in these attacks that authentication logs can't catch on their own.

‍

The Session Outlives The Login

The first problem is what happens when the attacker doesn't act right away. A Microsoft session token can stay valid for weeks, which means the attacker can log in once, drop a small persistence mechanism, and walk away.

We saw this with a tax advisory firm who onboarded with a 1-click Scan to get Petra’s detailed BEC forensics. The attacker phished the user with a device code, logged in from a Railway IP, and about a minute later created a single inbox rule scoped to one sender. Then nothing for 27 days. The incumbent tool had nothing to alert on because nothing was happening.

Almost four weeks later, the same session woke up. Over the next half hour, the attacker read more than 4000 emails and sent a phishing message to every contact in the user’s Sent Items folder. Every one of those operations ran on the session that was handed to the attacker a month ago. There was one malicious login event in the entire compromise.

By day 28, a clean sign-in log can just as easily mean the attacker is biding their time.

‍

The Compromise Has A Session, Not An IP.

The second problem is what happens during the active burst. The IPs scatter.

In another similar case, the attacker's operations rotated through a hosting provider in Dallas, Microsoft's own service IPs (for outbound Send operations that run server-side), and a handful of residential US IPs across Comcast, Verizon, and other residential ISPs. All in the span of thirty minutes, all on the same session.

This is where the usual forensic playbook falls apart. Filtering audit logs by attacker IP catches a fraction of the activity. Filtering by user catches noise from the real user, who was also working that day. There is no single data point that gives a responder a clean view of what the attacker actually did.

The only true identifier across the entire compromise is the intent of the attacker.

‍

Logins Aren't Enough Anymore

Three things to take from this post:

  • A device code phishing login is built to look legitimate. The user did sign in, the token Microsoft minted is real, and (as Part 1 covered) the device on file is often the real device. Sign-in logs are the wrong place to catch this.
  • Attackers can wait weeks before doing anything.
  • The detection layer that works is the one watching the intent, not the login. Petra analyzes based on the intent of every mailbox and SharePoint action, which is how we surface activity spread across a dozen IPs and four weeks of dormancy as a single compromise rather than a pile of disconnected events.

‍

The login was the easy part. The intent is where the attack actually happens, and that's where you have to be looking.

Are you defending M365 environments and want to check if your tenants have been compromised? Run a free scan today.