Entra ID Attacks in Practice: Device Code Phishing, PRT Theft, and Conditional Access Bypass

An attacker sends you a message: “Please sign in with this code: ABCD-1234.” It looks exactly like a real Microsoft login page. You enter the code. Nothing suspicious happens. But the attacker now has full access to your Microsoft 365 account — no password required, no MFA prompt triggered.

This is Device Code Phishing, and it’s one of the most dangerous Entra ID attack techniques active right now.

TL;DR

Device Code Phishing bypasses MFA by abusing Microsoft’s own OAuth authentication flow

A stolen PRT (Primary Refresh Token) grants up to 90 days of access to all organizational resources

Attackers can register their own device in Entra ID and satisfy high-assurance Conditional Access policies

Storm-2372 ran a large-scale campaign using these techniques throughout 2025

Detection is possible — but requires the right logs and SIEM rules in place

Why This Matters

Nearly every organization uses Microsoft 365 and Entra ID (formerly Azure AD — Microsoft’s cloud identity platform). Entra ID controls who can access email, Teams, SharePoint, OneDrive, and every connected cloud application.

If an attacker obtains an Entra ID token, they have the organization’s keys in their pocket. And unlike a stolen password, token theft doesn’t necessarily trigger a single alert.

Core Concepts

Before diving into attack techniques, a few terms explained:

Token — A digital proof of authentication. Think of it like a hotel key card: valid for a certain period, opens specific doors, no password needed as long as it’s valid.

OAuth 2.0 — The protocol apps use to request permissions from Microsoft. Device Code Flow is one OAuth flow, originally designed for devices without keyboards (smart TVs, IoT devices).

PRT (Primary Refresh Token) — An extremely high-value token valid for up to 90 days. It silently issues new access tokens for all Microsoft services. Think of it as a master key to the entire building.

Conditional Access — Entra ID’s policy engine that decides under what conditions a sign-in is allowed. For example: “Allow access only from compliant devices” or “Require strong authentication for sensitive apps.”

Attack 1: Device Code Phishing

How It Works

Device Code Flow was designed for scenarios like signing into Netflix on a smart TV. The TV can’t show a login form, so Microsoft issues a short code you enter on your phone or computer.

Attackers have turned this mechanism against itself:

The attacker requests a device code from Microsoft (e.g., ABCD-1234) using a known app’s client identifier
The attacker sends the code to the victim — via Teams message, email, or SMS — asking them to enter it at microsoft.com/devicelogin
The victim signs in normally with their credentials and MFA — everything looks legitimate
The attacker immediately receives an access token and refresh token — as the direct result of a legitimate authentication

# Simplified flow — attacker initiates the device code request
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode
→ Response: { "user_code": "ABCD-1234", "device_code": "...", "expires_in": 900 }

# Attacker polls while waiting for the victim to authenticate
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
→ Once victim approves: { "access_token": "...", "refresh_token": "..." }

Red team tools like TokenSmith and AADInternals include Device Code phishing modules that automate this entire flow.

Storm-2372: A Nation-State Actor Used This at Scale

In February 2025, Microsoft Threat Intelligence warned that Storm-2372 (suspected Russia-nexus APT) was running Device Code phishing campaigns targeting technology, manufacturing, and financial sectors.

The campaign continued throughout 2025. By September 2025, Proofpoint tracked a major surge in activity, with two publicly available frameworks — SquarePhish2 and Graphish — lowering the barrier for any operator to run Device Code phishing at scale.

Attack 2: PRT Theft and Device Registration

This is the more sophisticated follow-on to Device Code phishing. Storm-2372 pushed the technique further:

Step 1: Targeting the Authentication Broker Client ID

Instead of requesting a generic token, the attacker requests one using the Microsoft Authentication Broker application client ID (29d9ed98-a469-4536-ade2-f981bc1d605e).

This matters because a token issued to this client can be used to register a device in Entra ID.

Step 2: Registering an Attacker-Controlled Device

With the harvested token, the attacker registers their own device as a member of the victim’s Entra ID tenant. From Microsoft’s perspective, this device appears to be a fully legitimate organizational asset.

# AADInternals example of device registration
# (red team research tool — for understanding the technique)
$token = Get-AADIntAccessTokenForAADJoin
Join-AADIntDeviceToAzureAD `
    -DeviceName "CORP-LAPTOP-01" `
    -DeviceType "Windows" `
    -OSVersion "10.0.19045"

Step 3: Obtaining a PRT

From the registered device, the attacker requests a Primary Refresh Token. A PRT is so valuable because it:

Remains valid for up to 90 days
Grants silent access to all Entra ID-protected resources
Doesn’t require re-authentication during normal use
Is treated as a “trusted device” — Conditional Access policies accept it

Step 4: Registering Windows Hello for Business

The attacker goes one step further: they register Windows Hello for Business credentials (cryptographic, passwordless authentication) on their registered device.

The result: Entra ID treats the device as using phishing-resistant, strong authentication — satisfying even the highest assurance level Conditional Access policies. MFA is bypassed entirely, and the attacker meets requirements designed to stop exactly this kind of attack.

Attack 3: FIDO Downgrade Attack

In August 2025, security researchers published a new attack: FIDO authentication downgrade against Microsoft Entra ID.

Under normal conditions, FIDO2 security keys are extremely strong. But an attacker can trick Entra ID into requesting weaker authentication (password + SMS) instead of FIDO2, then conduct a traditional adversary-in-the-middle phishing attack against that weaker channel.

Blue Team: How to Detect These Attacks

Detection Point 0: Analyze Suspicious URLs and Tokens From Phishing Messages

When a Device Code phishing message lands in your inbox, the attacker-controlled URL and any embedded tokens can reveal a lot. Paste the URL or JWT token into our Security Decoder — it automatically detects phishing indicators, homoglyph characters, brand impersonation patterns, and decodes JWT payloads to expose the underlying claims. Fully client-side, nothing is sent to any server.

Detection Point 1: Unexpected Device Code Sign-Ins

Entra ID logs all sign-ins — but you need to know what to look for. Device Code Flow sign-ins are rare in a standard Windows corporate environment.

// KQL — Microsoft Sentinel / Entra ID Sign-in Logs
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where TimeGenerated > ago(7d)
| summarize count() by UserPrincipalName, IPAddress, AppDisplayName
| where count_ > 2
| sort by count_ desc

Alert threshold: if standard office workers are authenticating via Device Code, it’s almost certainly phishing.

// Device registered and used within 10 minutes — high suspicion
let newDevices = AuditLogs
| where OperationName == "Register device"
| project DeviceId = tostring(TargetResources[0].id), RegisterTime = TimeGenerated;
SigninLogs
| join kind=inner newDevices on $left.DeviceId == $right.DeviceId
| where TimeGenerated - RegisterTime < 10m
| project UserPrincipalName, DeviceId, RegisterTime, TimeGenerated, IPAddress

In a legitimate environment, device registrations happen through IT onboarding — not randomly at 2am from an unknown IP.

Detection Point 3: Windows Hello / FIDO Registration on Unmanaged Devices

AuditLogs
| where OperationName contains "Register security info"
| where TargetResources[0].modifiedProperties has "StrongAuthenticationPhoneAppDetail"
    or TargetResources[0].modifiedProperties has "fido2"
| project
    User = InitiatedBy.user.userPrincipalName,
    IP = InitiatedBy.user.ipAddress,
    Time = TimeGenerated
| order by Time desc

Detection Point 4: Impossible Travel

If the same user signs in from Helsinki at 09:00 and Moscow at 09:05, something is wrong. Entra ID Identity Protection detects this automatically — but only if it’s enabled and alerts are being acted on.

// Check for Identity Protection impossible travel events
AADUserRiskEvents
| where RiskEventType == "impossibleTravel"
| where TimeGenerated > ago(30d)
| project UserPrincipalName, IPAddress, Location, RiskLevel, TimeGenerated
| order by RiskLevel desc

MITRE ATT&CK Mapping

Technique	ID	Description
Device Code Auth Abuse	T1528	OAuth device code flow exploitation
Token Impersonation	T1134.001	Stealing and reusing authentication tokens
Cloud Account Registration	T1136.003	Registering attacker-controlled device in Entra ID
MFA Bypass	T1556.006	Authentication process manipulation
Valid Accounts	T1078.004	Using legitimate cloud account access

What You Can Do Today

Immediate Actions

1. Disable Device Code Flow if you don’t need it

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

# Disable device code flow tenant-wide
Update-MgPolicyAuthorizationPolicy -AllowedToUseSSO $false

Or restrict via Conditional Access if some users legitimately need it.

2. Block device registration from untrusted locations

Conditional Access policy:
- Users: All users
- Cloud apps: Device Registration Service
- Conditions: Location = NOT trusted named location
- Grant: Block access

3. Enable Entra ID Identity Protection

Identity Protection automatically flags:

Impossible travel
Anonymous IP addresses
Atypical sign-in properties
Leaked credentials

4. Alert on new device registrations

Set up an alert that fires whenever a new device is registered. Every registration that IT didn’t initiate should be investigated.

Longer-Term Hardening

Phishing-resistant MFA everywhere — FIDO2 keys or Windows Hello for Business on IT-managed devices only
Privileged Identity Management (PIM) — high-privilege roles granted just-in-time, not permanently
Continuous Access Evaluation (CAE) — real-time token validation, not just at sign-in
Named Locations — define trusted IP ranges and countries, require step-up auth from everywhere else

Conclusion

Device Code Phishing doesn’t require the victim to do anything obviously wrong. The victim visits a real Microsoft page, uses real credentials, completes a real MFA challenge — and still loses their account.

This marks the end of “traditional” MFA as a sufficient control against certain threat models. Effective defense requires:

Restricting Device Code Flow
Monitoring device registrations
Collecting and querying the right logs
Deploying Identity Protection

Without these controls, your Entra ID environment is significantly exposed — regardless of how complex your password policy or MFA requirements are.

Investigating sign-in anomalies from Entra ID logs? Our SOC Log Analyzer parses Windows Event Log entries and syslog lines — paste raw authentication log output and get a structured breakdown of what happened and when.

Identity-First Attacks in Cloud — broader look at cloud identity attacks from an IAM perspective
AD Attack Chains: Initial Access to Domain Admin — on-premises Active Directory attack chains that often precede cloud identity attacks
Human: The Weakest Link — how AI-assisted phishing makes Device Code attacks even more convincing