Entra device code sign-in
A Microsoft Entra ID sign-in that used the OAuth 2.0 **device authorization grant** (authenticationProtocol=deviceCode).
What it detects
A Microsoft Entra ID sign-in that used the OAuth 2.0 **device authorization grant** (authenticationProtocol=deviceCode). Device-code flow is meant for input-constrained devices (CLIs, smart TVs, IoT), but attackers abuse it for phishing: the attacker starts a device-code request, sends the victim the short user-code + microsoft.com/devicelogin link, and — once the victim authenticates — collects the resulting access/refresh tokens, bypassing the password and often satisfying MFA (as seen in the Storm-2372 campaign). In most tenants device-code sign-ins are rare, so each one warrants review.
MITRE ATT&CK mapping
False positives and triage
Some legitimate tooling uses device-code flow — Azure CLI / Azure PowerShell az login --use-device-code, and genuinely input-constrained devices (conference-room / signage / IoT). Allowlist those known apps and service accounts, then treat any remaining device-code sign-in as suspect — especially a SUCCESS from an unfamiliar IP or country, from a user who never uses CLI tooling, or one closely followed by inbox-rule creation, mass mail access, or MFA-method registration. This rule intentionally matches on the device-code protocol itself (not on any "device" keyword), so a normal interactive sign-in from a registered deviceId does not fire.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/cloud/entra_device_code_signin.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_device_code_signin
version: 1.0.0
status: experimental
severity: high
confidence: 0.6
platforms: [application]
mitre_techniques: [T1566, T1078.004]
description: |
A Microsoft Entra ID sign-in that used the OAuth 2.0 **device authorization
grant** (`authenticationProtocol=deviceCode`). Device-code flow is meant for
input-constrained devices (CLIs, smart TVs, IoT), but attackers abuse it for
phishing: the attacker starts a device-code request, sends the victim the
short user-code + `microsoft.com/devicelogin` link, and — once the victim
authenticates — collects the resulting access/refresh tokens, bypassing the
password and often satisfying MFA (as seen in the Storm-2372 campaign). In
most tenants device-code sign-ins are rare, so each one warrants review.
match:
provider: AzureAD
event_category: authentication
raw_message_contains_any:
- "authenticationProtocol=deviceCode"
- "originalTransferMethod=deviceCodeFlow"
- "protocol=deviceCode"
- "grant_type=device_code"
- "grant_type=urn:ietf:params:oauth:grant-type:device_code"
correlation_keys: [user_name]
false_positive_guidance: |
Some legitimate tooling uses device-code flow — Azure CLI / Azure PowerShell
`az login --use-device-code`, and genuinely input-constrained devices
(conference-room / signage / IoT). Allowlist those known apps and service
accounts, then treat any remaining device-code sign-in as suspect —
especially a SUCCESS from an unfamiliar IP or country, from a user who never
uses CLI tooling, or one closely followed by inbox-rule creation, mass
mail access, or MFA-method registration. This rule intentionally matches on
the device-code protocol itself (not on any "device" keyword), so a normal
interactive sign-in from a registered `deviceId` does not fire.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.