← All Chokepoints HIGH

OAuth Device Code Phishing via Auth Broker

authenticationProtocol: deviceCode + MAB app ID 29d9ed98-... + resultType 0 + isInteractive on Entra ID sign-in event when victim redeems device code

Defense Evasion T1550.001 Detection difficulty: LOW Prevalence: MEDIUM

Adversaries abuse the OAuth 2.0 device authorization grant flow to obtain Microsoft access and refresh tokens without a credential-harvest page or MFA bypass. The attacker initiates a device code using the Microsoft Authentication Broker (MAB) app (client ID 29d9ed98-a469-4536-ade2-f981bc1d605e), then social-engineers the victim to enter the code at microsoft.com/devicelogin, presenting it as a "verification code" or MFA prompt. The completed flow yields access and refresh tokens scoped to the Auth Broker FOCI (Family of Client IDs) family, granting access to Exchange, Graph, SharePoint, and Teams without requiring the victim to visit a fake login page. The MAB app ID is hardcoded in Tycoon 2FA's device-code-grant variant and generates a distinctive authenticationProtocol: deviceCode signal in Entra ID sign-in logs on a first-party app ID rarely used interactively by end users.

By @iimp0ster · Updated 2026-05-29 · View source YAML

Attack Chokepoints 2 invariant stages

Each stage is an invariant condition the attacker must satisfy, regardless of tool, variant, or threat actor. Detection at any stage breaks the chain.

1 Device Code Redemption via MAB App ▶
Prerequisites
  • Attacker can deliver a lure to the victim (email, Teams message, embedded link) that presents a device code as a legitimate verification prompt
  • Target must have a Microsoft 365 / Entra ID account
  • Tenant must not have a Conditional Access policy blocking device code flows (CA policy "Block device code flow" returns error 53003)
  • Attacker must be able to poll oauth2/token until victim redeems the code
Input Victim has entered the device code at microsoft.com/devicelogin
Chokepoint The attacker MUST use a specific OAuth application to initiate the device code flow - Tycoon 2FA hardcodes the Microsoft Authentication Broker (client ID 29d9ed98-a469-4536-ade2-f981bc1d605e). Redemption generates an interactive sign-in event with authenticationProtocol: deviceCode and the MAB app ID, regardless of how the code was delivered to the victim.
Observable Entra ID SigninLogs: authenticationProtocol == "deviceCode" AND appId == "29d9ed98-a469-4536-ade2-f981bc1d605e" AND resultType == "0" AND isInteractive == true. End users rarely initiate device-code flows to the Auth Broker interactively in managed environments - this combination is low-FP.
Why unavoidable
The FOCI token chain required for Exchange/Graph/SharePoint/Teams access depends on the Auth Broker app ID. Using a different app ID would require re-engineering the token exchange chain and would break the downstream FOCI inheritance that makes the technique valuable. The authenticationProtocol: deviceCode field is set server-side by Microsoft when the device-code grant type is used - the attacker cannot change this to appear as a different flow.
Data Sources
  • Entra ID Sign-in Logs (SigninLogs table in Sentinel)
  • Entra ID Interactive User Sign-In Logs
View rule →
↓ Kit has obtained Auth Broker refresh token; begins access...
2 Token Inheritance via FOCI ▶
Input Kit has obtained Auth Broker refresh token; begins accessing M365 resources via FOCI token exchange
Chokepoint The attacker MUST exchange the Auth Broker refresh token for access tokens to other M365 services via FOCI - generating non-interactive sign-in records on Exchange, Graph, SharePoint, and Teams from a cloud-VPS ASN within 10-20 minutes of the device-code completion event.
Observable Entra ID NonInteractiveUserSignInLogs: Multiple resource sign-ins (Exchange, Graph, SharePoint, Teams) from cloud-VPS ASN within 10-20 minutes of the device-code interactive sign-in event for same UPN. incomingTokenType: refreshToken → primaryRefreshToken progression in Graph Activity Logs.
Why unavoidable
Access to M365 resources requires valid tokens, which require token exchange calls that generate non-interactive sign-in log entries. The FOCI token exchange is the only mechanism to access multiple M365 resources from a single Auth Broker refresh token.
Data Sources
  • Entra ID NonInteractiveUserSignInLogs
  • Microsoft Graph Activity Logs
View rule →

Variations 1 variant tracked

Tools and methods that exploit this chokepoint. The list grows. The chokepoint doesn't change.

Tycoon 2FA - Device Code Grant Variant 2024-Q1 Active ▶
Post-takedown adaptation by Tycoon 2FA operators. Device code delivered as "verification code" lure exploiting victim familiarity with MFA prompts. MAB client ID 29d9ed98-a469-4536-ade2-f981bc1d605e hardcoded. Token progression: incomingTokenType none → refreshToken → (optional) Rogue Device Registration → primaryRefreshToken. Bypasses URL-filtering defenses entirely - no phishing page to block.
Command / artifacts
Variant bypasses credential-harvest detection (no fake login page). Code delivered via email lure as "verification code". Operators post- takedown combined device-code tradecraft with AiTM WebSocket relay. 
# Step 1: Request device code using MAB app
POST https://login.microsoftonline.com/common/oauth2/v2.0/devicecode
  client_id=29d9ed98-a469-4536-ade2-f981bc1d605e
  scope=https://graph.microsoft.com/.default
# Returns: device_code (shown to victim as "verification code"), user_code

# Step 2: Poll until victim redeems code at microsoft.com/devicelogin
POST https://login.microsoftonline.com/common/oauth2/token
  grant_type=urn:ietf:params:oauth:grant-type:device_code
  device_code=<device_code>
  client_id=29d9ed98-a469-4536-ade2-f981bc1d605e
# Polls until resultType "0" - victim has entered code

# Step 3: FOCI token exchange to access M365 resources
POST https://login.microsoftonline.com/common/oauth2/token
  grant_type=refresh_token
  refresh_token=<mab_refresh_token>
  resource=https://outlook.office365.com  # Exchange
  client_id=29d9ed98-a469-4536-ade2-f981bc1d605e
  • Entra ID SigninLogs: authenticationProtocol "deviceCode" appId "29d9ed98-..." resultType "0" isInteractive "true"
  • Entra ID NonInteractiveUserSignInLogs: FOCI token exchanges to Exchange/Graph/SharePoint from cloud-VPS ASN
  • Graph Activity Logs: incomingTokenType progression none → refreshToken → primaryRefreshToken
Same chokepoint: Kit requests device code → lure delivers code to victim → victim redeems at devicelogin (interactive sign-in event: deviceCode + MAB app ID) → kit polls and receives tokens → FOCI exchange to M365 resources
Source: www.elastic.co →

Detection Strategy

Rules organized by the chokepoint stage they detect. Each stage has one or more rules at different maturity levels.

1 Device Code Redemption via MAB App
2 Token Inheritance via FOCI
Device-code flow on the Microsoft Authentication Broker app ID - rarely used ...
Hunt
▶
Goal
Device-code flow on the Microsoft Authentication Broker app ID - rarely used interactively by end users in managed environments.
Log Sources
  • Entra ID Sign-in Logs
FP Rate
Low (legitimate MAB device-code in managed device enrollment; rare)
Use Case
Active hunting. MAB app ID + device-code combination is low-FP in most enterprise tenants. Investigate each occurrence.
Detection Logic
authenticationProtocol == "deviceCode" AND appId == "29d9ed98-a469-4536-ade2-f981bc1d605e" AND resultType == "0". Alert on any occurrence - MAB app ID + device code interactive sign-in is low-volume and should be reviewed.
Sigma Rule - Hunt Level
GitHub → Download 
title: Entra ID Device Code Flow on Microsoft Authentication Broker App (OAuth Device Code Phishing)
id: c9d0e1f2-a3b4-4c5d-6e7f-8a9b0c1d2e3f
status: experimental
description: >
  Detects successful OAuth device-code-flow sign-ins using the Microsoft Authentication
  Broker app ID (29d9ed98-a469-4536-ade2-f981bc1d605e). Tycoon 2FA's device-code-grant
  variant hardcodes this client ID to obtain FOCI refresh tokens granting access to
  Exchange, Graph, SharePoint, and Teams without a phishing page. End users in managed
  environments rarely initiate device-code flows to the Auth Broker interactively;
  any occurrence should be reviewed. CA policy blocking device code flows (error 53003)
  is the most effective prevention -- this rule covers tenants without that policy.
references:
  - https://www.elastic.co/security-labs/tycoon-2fa-aitm-detection-engineering
author: '@iimp0ster'
date: 2026-05-27
tags:
  - attack.defense-evasion
  - attack.t1550.001
  - detection.maturity.hunt
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    AuthenticationProtocol: 'deviceCode'
    AppId: '29d9ed98-a469-4536-ade2-f981bc1d605e'
    ResultType: '0'
  filter_known_automation:
    # PENDING: Add known-good service account UPNs or device enrollment flows if documented
    # UserPrincipalName|contains:
    #   - 'svc-intune@tenant.onmicrosoft.com'
    UserPrincipalName: ''  # placeholder — remove and populate before production
  condition: selection and not filter_known_automation
falsepositives:
  - Legitimate Microsoft Authentication Broker device-code flows in managed device enrollment
  - Shared device scenarios (kiosk, Surface Hub) using MAB for token refresh
level: high
MAB device-code flow + isInteractive flag confirms victim redemption. High-co...
Analyst
▶
Goal
MAB device-code flow + isInteractive flag confirms victim redemption. High-confidence phishing indicator in managed tenants.
Log Sources
  • Entra ID Sign-in Logs
FP Rate
Very Low
Use Case
SOC alerting. Immediate investigation. Trigger: enumerate registered devices, review recent sign-ins, revoke if confirmed phishing.
Detection Logic
authenticationProtocol == "deviceCode" AND appId == "29d9ed98-a469-4536-ade2-f981bc1d605e" AND resultType == "0" AND isInteractive == true. Exclude known-legitimate automation (document per tenant).
Sigma Rule - Analyst Level
GitHub → Download 
title: Entra ID Interactive Device Code Redemption via Microsoft Authentication Broker (High-Confidence Phishing)
id: d0e1f2a3-b4c5-4d6e-7f8a-9b0c1d2e3f4a
status: experimental
description: >
  Detects successful interactive OAuth device-code-flow sign-ins using the Microsoft
  Authentication Broker app ID (29d9ed98-a469-4536-ade2-f981bc1d605e) with isInteractive
  true — confirming victim-entered redemption at microsoft.com/devicelogin. The
  isInteractive flag distinguishes victim redemption (attacker delivers code as lure)
  from legitimate service flows. This three-field combination (deviceCode + MAB appId +
  isInteractive) is high-confidence phishing in managed tenants. Remediation: enumerate
  registered devices on victim UPN, delete any unrecognized devices BEFORE revoking
  sessions (to prevent PRT persistence), then revoke sessions and reset credentials.
references:
  - https://www.elastic.co/security-labs/tycoon-2fa-aitm-detection-engineering
author: '@iimp0ster'
date: 2026-05-27
tags:
  - attack.defense-evasion
  - attack.t1550.001
  - detection.maturity.analyst
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    AuthenticationProtocol: 'deviceCode'
    AppId: '29d9ed98-a469-4536-ade2-f981bc1d605e'
    ResultType: '0'
    IsInteractive: 'true'
  filter_known_legitimate:
    # PENDING: Document any tenant-specific legitimate MAB interactive device-code flows
    # UserPrincipalName|contains:
    #   - 'svc-kiosk@tenant.onmicrosoft.com'
    UserPrincipalName: ''  # placeholder — remove and populate before production
  condition: selection and not filter_known_legitimate
falsepositives:
  - Interactive MAB device-code flows from documented shared-device or kiosk enrollment
  - Internal IT workflows requiring manual device-code entry with Auth Broker (rare)
level: high