M365 Device Code Phishing : When MFA Works Against You

CyberDefender 9 mins0

UNK_AcademicFlare is a Russia-linked threat actor (the “UNK” prefix usually means unattributed / newly tracked) observed abusing Microsoft 365 authentication via a technique called device code phishing.

This activity is dangerous because nothing “hacky” happens. No malware. No fake Microsoft login page. No password stealing. The attacker simply convinces the victim to finish a real Microsoft login on the attacker’s behalf. That’s why this technique keeps working.

Microsoft has a login method called device code authentication. It’s meant for things like smart TVs, printers, or command-line tools that don’t have a browser.

The attacker abuses this flow so that the victim logs the attacker in — willingly, unknowingly, and successfully.

The attacker does NOT need to know the user’s device ID, and the attacker does NOT need to use the victim’s device.
In device code phishing, the user’s credentials (and MFA) authorize the attacker’s device/session, even though it does not belong to the user.

Step-by-step: what the victim experiences

  1. Victim receives a convincing message
    • Usually email, sometimes Teams or messaging platforms
    • Phrased as:
      • “You’ve been granted access to a document”
      • “New academic collaboration”
      • “Secure research portal login”
  2. Message contains a short code
    • Looks harmless: J7QF-K2LM
    • Mentally feels safer than clicking a link
  3. Victim is told to visit a Microsoft site
    • https://microsoft.com/devicelogin
    • This is a real Microsoft page, not phishing
  4. Victim logs in and completes MFA
    • Password entered
    • MFA approved
    • Everything looks normal
  5. Victim closes the browser
    • They think they’re done
    • They never realize anything went wrong

What actually happened behind the scenes

While the victim was typing that code:

  • The attacker already initiated the login
  • The code ties the victim’s authentication to the attacker’s session
  • When the victim finishes MFA:
    • Microsoft issues OAuth access + refresh tokens
    • Tokens go to the attacker

No password is shared.
No MFA is bypassed.
No exploit is used.

Microsoft did exactly what it was told to do.

What the attacker gets access to

Once they have OAuth tokens, the attacker can quietly access:

  • Outlook (email history, attachments)
  • OneDrive (research, drafts, credentials)
  • Teams (chat logs, internal discussions)
  • SharePoint (institutional data)

And because this uses Microsoft’s own identity system:

  • Sessions can last days or weeks
  • Access survives password changes
  • Alerts often look “low risk”

Why UNK_AcademicFlare focuses on academics

This cluster (tracked as UNK_AcademicFlare) appears aligned with Russian intelligence interests, not cybercrime.

Academic targets are ideal because:

  • They exchange documents constantly
  • They collaborate with governments and NGOs
  • They’re trained to trust “research access” emails
  • Security controls are usually weaker than corporate tenants

This isn’t about stealing money.
It’s about long-term intelligence collection.

Why security tools struggle to catch this

Most phishing detection looks for:

  • Fake domains
  • Credential harvesting pages
  • Malware downloads

This attack has none of those.

What defenders see instead:

  • A successful Microsoft login
  • MFA completed
  • Legit OAuth tokens issued
  • Access from “cloud IPs”

From Microsoft’s perspective, it looks like a valid user action.

The human mistake attackers rely on

“I didn’t click a link.
I didn’t download anything.
I logged into Microsoft like I always do.”

That’s exactly why this works.

The psychological trick is shifting responsibility:

  • Instead of “enter your password here”
  • It becomes “enter this code to continue”

Users are trained to fear links — not device codes.

How organizations actually stop this

Not with more phishing training alone.

Effective defenses include:

  • Disabling device code authentication if unused
  • Blocking device-code logins via Conditional Access
  • Monitoring sign-ins where:
    • Auth method = Device Code
    • User never initiated a login
  • Reviewing OAuth apps and token issuance

And teaching users one critical rule:

If you didn’t start the login yourself, never enter a device code — ever.

Why this matters long-term

This campaign shows the future of phishing:

  • No fake websites
  • No malware
  • No stolen passwords
  • Just abusing trust in identity systems

Expect more actors to copy this.

  • Targets
    • Universities & research institutions
    • Think tanks
    • NGOs
    • Government-adjacent academics
  • Tradecraft
    • Uses living-off-the-land authentication abuse
    • Bypasses many traditional phishing detections
    • MFA-resistant when device codes are allowed
  • Motivation
    • Likely espionage / intelligence collection, not financial fraud

Indicators defenders should watch

  • Unusual logins using OAuth device code flow
  • Successful sign-ins without password entry
  • Logins from:
    • New geographies
    • VPS / cloud IP ranges
  • Consent to unfamiliar Microsoft apps
  • Tokens issued shortly after a phishing email

Mitigations :

For Microsoft 365 tenants:

  • Disable Device Code Flow unless explicitly needed
  • Enforce Conditional Access
    • Restrict device code auth by location / device
  • Monitor Sign-in logs → Authentication Details
  • Regularly review Enterprise Applications & OAuth consents
  • Train users:
    • Never enter a code unless they initiated the login themselves

Real detection logic (KQL / Microsoft Sentinel)

Detection #1 — Device code auth usage (primary signal)

SigninLogs
| where AuthenticationDetails has "Device Code"
| where ResultType == 0
| project
    TimeGenerated,
    UserPrincipalName,
    AppDisplayName,
    ClientAppUsed,
    IPAddress,
    Location,
    AuthenticationDetails

Detection #2 — MFA satisfied via device code (high confidence)

SigninLogs
| where AuthenticationRequirement == "multiFactorAuthentication"
| where AuthenticationDetails has "Device Code"
| project
    TimeGenerated,
    UserPrincipalName,
    AuthenticationDetails,
    IPAddress,
    Location

Detection #3 — OAuth token abuse after device-code login

let DeviceCodeUsers =
SigninLogs
| where AuthenticationDetails has "Device Code"
| summarize by UserPrincipalName;

SigninLogs
| where SignInEventType == "NonInteractiveUserSignIn"
| where UserPrincipalName in (DeviceCodeUsers)
| where TimeGenerated > ago(7d)
| project
    TimeGenerated,
    UserPrincipalName,
    AppDisplayName,
    IPAddress,
    UserAgent

This catches:

  • Token reuse
  • Attacker automation
  • Long-term access

Detection #4 — “Impossible flow” correlation

SigninLogs
| summarize
    methods = make_set(AuthenticationDetails),
    locations = make_set(Location),
    apps = make_set(AppDisplayName)
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where methods has "Device Code"
| where array_length(locations) > 1

Victim logs in locally → attacker accesses cloud resources minutes later.

CyberDefender