First-Time Device Code Authentication — No Prior Protocol History

hunt-2025-043 v1.0 Entra ID · Azure created Mar 10, 2026 Paul Newton

Hypothesis

A user authenticating via device code for the first time — with no history of the protocol over the preceding 30 days — is a strong behavioural indicator of phishing. Legitimate device code usage is rare in most enterprises and tends to be associated with specific roles or devices. An unexpected first use of the protocol by a regular user is highly suspicious and warrants immediate triage.

Device Code Auth — No Prior 30-Day History

Uses a 30-day lookback window to build a baseline of users who regularly authenticate via device code, then flags any successful device code authentications in the past day by users who do not appear in that baseline. Limiting to ResultType == 0 (success) keeps the signal clean — only completed authentications indicate a token was actually issued to the attacker.

KQL

let LookbackWindow = 30d;
let HuntWindow     = 1d;
let HistoricUsers =
    SigninLogs
    | where TimeGenerated between (ago(LookbackWindow) .. ago(HuntWindow))
    | where AuthenticationProtocol == "deviceCode"
    | distinct UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(HuntWindow)
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0
| where UserPrincipalName !in (HistoricUsers)
| project
    TimeGenerated,
    UserPrincipalName,
    IPAddress,
    Country              = tostring(LocationDetails.countryOrRegion),
    AppDisplayName,
    RiskLevelDuringSignIn,
    IsManagedDevice      = tostring(DeviceDetail.isManaged),
    UserAgent
| order by TimeGenerated desc

Triage steps

1 Confirm the user has no legitimate reason to use device code authentication — check their role, assigned devices, and whether they use any IoT or meeting room hardware
2 Review AppDisplayName — first-time device code auth to Azure CLI or Microsoft Graph is particularly high risk
3 Check the IPAddress against threat intelligence and compare the Country against the user's normal sign-in geography
4 Search UrlClickEvents and EmailEvents for phishing indicators in the 30 minutes preceding the authentication
5 If the authentication is confirmed suspicious, immediately revoke the user's refresh tokens in Entra and audit downstream Graph API and Exchange activity
6 Raise an incident and investigate whether other users received the same phishing email

True positive example

TimeGenerated: 2026-01-15T09:25:02Z
UserPrincipalName: [email protected]
IPAddress: 185.220.101.47
Country: NL
AppDisplayName: Microsoft Azure CLI
RiskLevelDuringSignIn: high
IsManagedDevice: false
UserAgent: python-requests/2.28.0

First device code authentication by this user in 30+ days. The authentication completed successfully (ResultType 0), meaning a token was issued to the attacker's session. High Entra risk score, unmanaged device, and a Tor-associated IP. UrlClickEvents confirmed a workers.dev phishing link was clicked by this user 4 minutes prior. Treat as confirmed token theft.

Back to all hunts