Leverage Device Code Phishing for Initial Access

What this lab covers

You run a device code phishing flow to obtain tokens for a target identity, then use that access to enumerate the tenant and move onward into the connected Windows environment.

The lab covers the full arc rather than stopping at initial access, because tokens on their own are only interesting for what they reach. Enumeration, lateral movement and maintaining access are all part of understanding why this technique matters.

It suits red teamers and defenders equally. If you own conditional access policy, this is the technique those policies most need to account for.

How device code phishing works

The device code flow exists for inputs where typing a password is impractical, such as televisions and command line tools on headless machines. The device displays a short code, the user visits a Microsoft URL on a second device, enters the code and signs in, and the original device receives tokens.

The flow does not verify that the device requesting the code and the person entering it are related. An attacker initiates the flow, sends the genuine code and the genuine Microsoft URL to a target, and collects the tokens once the target completes sign-in.

Every signal a user is taught to check is legitimate. The domain is Microsoft's, the certificate is valid, the sign-in prompt is the familiar one, and multi-factor authentication completes normally. What is missing is any indication of which application the approval is for, which is the part users cannot evaluate.

How to detect this in your own environment

Sign-in logs record the authentication protocol, so device code sign-ins can be identified specifically. In most organizations this flow is used by a very small set of legitimate scenarios, so filtering for it produces a short list worth reviewing.

Look for mismatches between the sign-in location and the user. Because the attacker's infrastructure requests the tokens, the resulting sign-in often shows characteristics inconsistent with the user's normal pattern, and location or network anomalies are the practical discriminator.

Watch what happens next. Token acquisition is followed by enumeration, so a device code sign-in followed by directory reads from an identity that does not normally perform them is a much stronger signal than either event alone.

How to prevent it

Block the device code flow with conditional access unless you have a documented need for it. This is the decisive control, and for most organizations the flow is used by nothing, so blocking it costs nothing and removes the technique.

Where it must be permitted, restrict it to specific users, applications and compliant devices, so the token cannot be issued to arbitrary infrastructure.

Use token protection and device compliance conditions so that stolen tokens are less portable. Binding tokens to a device means possession of the token alone is not sufficient to use it elsewhere.

Real-world context

Device code phishing has been used by nation-state actors against high-value targets, and reporting from Microsoft and others has repeatedly described campaigns using this flow against government, defense and research organizations. It is attractive precisely because it defeats both fake-site detection and standard multi-factor authentication.

It illustrates a general point about identity attacks in cloud environments. The strongest techniques do not break authentication, they abuse a legitimate authentication path, which means the countermeasure is policy configuration rather than user vigilance.

The pattern maps to MITRE ATT&CK T1566 Phishing, T1528 Steal Application Access Token and T1078.004 Cloud Accounts.

Applying this at work

• Check whether the device code flow is blocked by conditional access in your tenant. For most organizations it should be, and frequently it is not.
• Query your sign-in logs for device code authentications over the last ninety days and review every one.
• Where the flow is needed, scope it to named users and applications rather than leaving it open tenant-wide.
• Evaluate token protection and device compliance conditions to reduce the portability of stolen tokens.
• Add a detection for a device code sign-in followed by directory enumeration from the same identity.

Frequently asked questions

Does multi-factor authentication stop device code phishing?

No. The victim completes multi-factor authentication legitimately on Microsoft's own site, and the resulting tokens reflect that. The tokens the attacker receives are fully authenticated, which is what makes the technique effective.

How can a user spot device code phishing?

Realistically they cannot, from the sign-in page alone. Everything they are taught to check is genuine. The practical defense is blocking the flow with conditional access rather than expecting users to detect it.

Why does the device code flow exist at all?

For devices where entering a password is impractical, such as smart televisions and command line tools on headless systems. It is a legitimate flow being used for its intended mechanics against an unintended participant.

Do I need my own Azure account to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own tenant.

Which certification covers this in depth?

The Microsoft Cloud Red Team Professional (MCRTP) covers Entra ID, Azure and Microsoft 365 attack paths in full, including token abuse, phishing tradecraft and privilege escalation, and is assessed hands-on in a live tenant.