Detect Business Email Compromise via OAuth Device Code Flow Phishing in Microsoft Sentinel
OAuth Device Code Flow phishing is a prevalent Business Email Compromise (BEC) technique actively used by Scattered Spider, Storm-2372, and nation-state actors including Midnight Blizzard. The attacker sends a phishing message containing a Microsoft device code (a short alphanumeric code from https://microsoft.com/devicelogin), social-engineered to appear as an IT helpdesk request, MFA enrollment notification, or remote support session. When the victim enters the code, the attacker receives a valid OAuth access token and refresh token for the victim's Microsoft 365 account — with no password required. The attacker then has full access to email, Teams, SharePoint, OneDrive, and any M365 service the victim is licensed for. Refresh tokens may persist for 90 days, providing long-term access even after password reset. This technique bypasses MFA entirely because the device code flow is a legitimate Microsoft authentication mechanism.
MITRE ATT&CK
- Tactic
- Credential Access Collection
KQL Detection Query
// THREAT: OAuth Device Code Flow BEC Phishing
// Detects suspicious OAuth token acquisition via device code flow in Microsoft 365
// Primary telemetry: Azure AD Sign-in logs, Office 365 audit logs
// Alert 1: Device code flow sign-ins from anomalous locations or user agents
let KnownMobileApps = dynamic(["Microsoft Office", "Microsoft Teams", "Outlook Mobile", "OneDrive"]);
let SuspiciousUserAgents = dynamic(["python-requests", "curl", "wget", "Go-http-client", "okhttp", "axios"]);
AADSignInLogs
| where TimeGenerated > ago(24h)
| where AuthenticationProtocol =~ "deviceCode" or TokenIssuerType =~ "AzureAD"
| where ResourceDisplayName !in ("Windows Sign In", "Microsoft App Access Panel")
// Flag device code logins from suspicious clients or unexpected locations
| where UserAgent has_any (SuspiciousUserAgents)
or (
// Device code used and then token immediately used from different country than user's typical location
Status.errorCode == 0 and
(
// Inline phishing sequence: initial device code poll + immediate use
AuthenticationDetails has "DeviceCode" and
Location !in ("GB", "US") // Adjust to your expected user country list
)
)
| project TimeGenerated, UserPrincipalName, IPAddress, Location, UserAgent,
AppDisplayName, ResourceDisplayName, AuthenticationProtocol,
ConditionalAccessStatus, RiskDetail, RiskLevelDuringSignIn
| extend ThreatType = "DeviceCode_BEC_Phishing"
| sort by TimeGenerated desc;
// Alert 2: Inbox rules created immediately after device code sign-in (typical BEC follow-on)
OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation in ("New-InboxRule", "Set-InboxRule", "Set-Mailbox")
| where Parameters has_any ("DeleteMessage", "ForwardTo", "RedirectTo",
"ForwardAsAttachmentTo", "MoveToFolder")
| where Parameters !has "Junk Email" // Exclude Junk folder rules which are often legitimate
| project TimeGenerated, UserId, ClientIP, Operation, Parameters, OrganizationId
| extend ThreatType = "BEC_InboxRule_Forwarding"Two-part detection: (1) OAuth device code flow sign-ins with suspicious user agents or unexpected geographic locations — the exact mechanism used by Storm-2372 and Scattered Spider BEC campaigns; (2) Inbox rule creation immediately following sign-in events — the BEC follow-on action to forward victim email to attacker-controlled addresses. Both should be investigated together for maximum fidelity.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate device code sign-in by users registering a new device (smart TV, printer, IoT device) against corporate M365 tenant
- IT helpdesk staff using device code flow to assist users in enrolling devices
- Developers testing OAuth device code flow against M365 APIs in dev/test tenants
- Users creating legitimate inbox rules to organise their mailbox (exclude forward/delete rules that move to specific business folders)
Other platforms for THREAT-BEC-OAuthDeviceCode
Testing Methodology
Validate this detection against 2 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1OAuth Device Code Flow Token Request (Simulated Phishing)
Expected signal: Azure AD Sign-in logs record a DeviceCode flow initiation. When user enters the code, AADSignInLogs records a successful authentication with AuthenticationProtocol=deviceCode.
- Test 2Create BEC Inbox Forwarding Rule via Exchange Online PowerShell
Expected signal: O365 Unified Audit Log records New-InboxRule operation with ForwardTo parameter for the authenticated user.
References (6)
- https://www.microsoft.com/en-us/security/blog/2024/08/08/midnight-blizzard-conducts-targeted-social-engineering-over-microsoft-teams/
- https://www.crowdstrike.com/blog/scattered-spider-attempts-to-avoid-detection-with-bring-your-own-vulnerable-driver-tactic/
- https://www.ncsc.gov.uk/collection/phishing-attacks/phishing-techniques/oauth-phishing
- https://attack.mitre.org/techniques/T1528/
- https://learn.microsoft.com/en-us/entra/identity/conditional-access/block-legacy-authentication
- https://github.com/dafthack/TokenTactics
Unlock Pro Content
Get the full detection package for THREAT-BEC-OAuthDeviceCode including response playbook, investigation guide, and atomic red team tests.