SOCLIFE
SOCLIFE

Evidence-led security analysis

Published knowledge

Search SOC//LIFE

CasesCASE-005

SOC investigation

High-Risk User Reveals Device Code Phishing

A User Risk alert led to a successful device-code authentication that matched Microsoft's 2026 phishing tradecraft, shifting the investigation from password theft to attacker-controlled OAuth token acquisition.

Based on publicly reported attack activity. User identities and workstation names have been anonymized.

User
denis@example.com
Initial alert
User Risk increased for cloud identity
Severity
High

Case story

What happened

The investigation starts from a medium/high active user-risk event and determines whether the same identity completed an unexpected device-code authentication associated with Microsoft's 2026 phishing tradecraft.

  1. User Risk becomes the investigation trigger

    The SOC receives an active medium/high risk condition for the cloud identity.

  2. Unexpected device-code authentication is identified

    The identity completes a device-code flow that is not expected for the user's normal work pattern.

  3. Risk and sign-in sequence reinforce the compromise hypothesis

    The analyst checks for the documented 50199-to-success sequence and preserves session/correlation identifiers.

  4. The attacker can operate with valid token-backed access

    Microsoft reports that successful compromise can progress into device registration, Graph reconnaissance, inbox rules, or mail access.

Investigation

What was checked

Follow how the analyst tested and revised explanations. This is discovery order, not event chronology.
  1. Start with User Risk

    The risk event defines the identity and authentication timeframe for the investigation.

    Next pivot

    Search the same user for device-code authentication around the risk window.

    View query
    Q-01

    Inspect the user's active risk detections

    What this checks

    Start from the User Risk alert and determine which risk detections are active, when they were detected, and whether they are tied to a sign-in.

    KQL
    let target_user = "denis@example.com";
    AADUserRiskEvents
    | where TimeGenerated >= ago(7d)
    | where UserPrincipalName =~ target_user
    | where RiskLevel in~ ("medium", "high")
    | where RiskState in~ ("atRisk", "confirmedCompromised")
    | project
        TimeGenerated,
        ActivityDateTime,
        DetectedDateTime,
        UserPrincipalName,
        UserId,
        IpAddress,
        RiskEventType,
        RiskLevel,
        RiskState,
        RiskDetail,
        DetectionTimingType,
        Activity,
        CorrelationId,
        RequestId
    | order by TimeGenerated asc
    SPL
    index=<entra_risk_index> sourcetype=<entra_user_risk_sourcetype>
    earliest=-7d
    | eval
        user=lower(coalesce(user, UserPrincipalName, user_principal_name)),
        src=coalesce(src, IpAddress, ip_address),
        risk_type=coalesce(risk_type, RiskEventType),
        risk_level=lower(coalesce(risk_level, RiskLevel)),
        risk_state=lower(coalesce(risk_state, RiskState)),
        correlation_id=coalesce(correlation_id, CorrelationId),
        request_id=coalesce(request_id, RequestId)
    | where user="denis@example.com"
        AND risk_level IN ("medium","high")
        AND risk_state IN ("atrisk","confirmedcompromised")
    | table _time user src risk_type risk_level risk_state correlation_id request_id
    | sort 0 _time
    What to look for

    One or more active medium/high risk events for denis@example.com, with risk type, source IP, timing, and correlation context preserved.

    Technical details
    Tested signal

    Medium or high user-risk event in an at-risk or confirmed-compromised state.

    Assumptions
    • Microsoft Entra ID Protection telemetry is licensed and exported.
    • The user-risk event contains a UPN and, where sign-in linked, correlation or request identifiers.
    Data requirements and relevant fields
    identity

    Microsoft Entra ID Protection user-risk events with identity, event type, risk level/state, source IP, and sign-in correlation identifiers.

    • TimeGenerated
    • ActivityDateTime
    • DetectedDateTime
    • UserPrincipalName
    • UserId
    • IpAddress
    • CorrelationId
    • RequestId
    • RiskEventType
    • RiskLevel
    • RiskState
    • RiskDetail
    • DetectionTimingType
    • Activity
    KQL schema

    Validate table availability, Entra ID Protection licensing, connector retention, and local field population.

    SPL schema

    Replace index/sourcetype placeholders and map user-risk and sign-in concepts to the local Entra export.

    Limitations
    • Some risk detections are calculated offline and can appear after the originating sign-in.
    • Risk level is a prioritization signal, not proof of compromise.

    KQL uses Microsoft Entra / Defender XDR identity telemetry. SPL is a normalized raw-event scaffold and requires local field mapping.

    More reasoning

    Observation

    The user's risk state is the first security signal.

    Working explanation

    A medium/high active risk event may represent unauthorized authentication rather than benign travel or network change.

    What was checked

    Review the user's active risk events, timing, source IP, risk type, risk state, and linked correlation identifiers.

    Interpretation

    Risk is a prioritization signal that needs sign-in evidence before compromise is confirmed.

    Supporting evidence
  2. Identify device-code authentication

    Unexpected device-code use materially strengthens the phishing hypothesis.

    Next pivot

    Validate the 50199-to-success authentication sequence.

    View query
    Q-02

    Find device-code sign-ins around the risk event

    What this checks

    Determine whether the affected identity completed a successful device-code authentication near the active user-risk event.

    KQL
    let target_user = "denis@example.com";
    SigninLogs
    | where TimeGenerated >= ago(7d)
    | where UserPrincipalName =~ target_user
    | where AuthenticationProtocol =~ "deviceCode"
    | where tostring(ResultType) == "0"
    | project
        TimeGenerated,
        UserPrincipalName,
        IPAddress,
        AuthenticationProtocol,
        AuthenticationRequirement,
        RiskLevelDuringSignIn,
        RiskLevelAggregated,
        RiskState,
        AppDisplayName,
        AppId,
        ResourceDisplayName,
        ConditionalAccessStatus,
        DeviceDetail,
        AutonomousSystemNumber,
        CorrelationId,
        SessionId
    | order by TimeGenerated asc
    SPL
    index=<entra_signin_index> sourcetype=<entra_signin_sourcetype>
    earliest=-7d
    | eval
        user=lower(coalesce(user, UserPrincipalName, user_principal_name)),
        src=coalesce(src, IPAddress, ip_address),
        auth_protocol=lower(coalesce(auth_protocol, AuthenticationProtocol)),
        result=coalesce(result, ResultType),
        signin_risk=lower(coalesce(signin_risk, RiskLevelDuringSignIn, RiskLevelAggregated)),
        risk_state=lower(coalesce(risk_state, RiskState)),
        app_name=coalesce(app_name, AppDisplayName),
        session_id=coalesce(session_id, SessionId),
        correlation_id=coalesce(correlation_id, CorrelationId)
    | where user="denis@example.com" AND auth_protocol="devicecode" AND tostring(result)="0"
    | table _time user src auth_protocol signin_risk risk_state app_name session_id correlation_id
    | sort 0 _time
    What to look for

    A successful device-code sign-in for the affected user that is risky, unfamiliar, or unexpected for the user's normal authentication behavior.

    Technical details
    Tested signal

    Successful authentication using the device-code protocol with medium/high sign-in risk or an active linked user-risk event.

    Assumptions
    • SigninLogs exposes the authentication protocol and risk fields.
    • Device code use is uncommon or tightly controlled for the affected user population.
    Data requirements and relevant fields
    authentication

    Microsoft Entra sign-in logs with authentication protocol, risk state, result, application, device, IP, and correlation/session context.

    • TimeGenerated
    • UserPrincipalName
    • UserId
    • IPAddress
    • AuthenticationProtocol
    • AuthenticationRequirement
    • ResultType
    • ResultDescription
    • RiskLevelDuringSignIn
    • RiskLevelAggregated
    • RiskState
    • CorrelationId
    • SessionId
    • AppDisplayName
    • AppId
    • ResourceDisplayName
    • ConditionalAccessStatus
    • DeviceDetail
    • AutonomousSystemNumber
    KQL schema

    Validate table availability, Entra ID Protection licensing, connector retention, and local field population.

    SPL schema

    Replace index/sourcetype placeholders and map user-risk and sign-in concepts to the local Entra export.

    Limitations
    • Legitimate CLI, IoT, shared-device, or administrative workflows can use device code.
    • Risk fields require Entra ID Protection licensing for full detail.

    KQL uses Microsoft Entra / Defender XDR identity telemetry. SPL is a normalized raw-event scaffold and requires local field mapping.

    More reasoning

    Observation

    Device-code flow is legitimate but high risk when a user or environment does not normally require it.

    Working explanation

    The risky identity may have authenticated an attacker-controlled device-code session.

    What was checked

    Search successful device-code sign-ins and preserve IP, app, resource, risk, device, session, and correlation context.

    Interpretation

    Do not treat all device-code flow as malicious; compare it with approved CLI, IoT, shared-device, or administration workflows.

    Supporting evidence
  3. Correlate the user-interrupt sequence

    The pattern aligns the risky identity with current Microsoft-documented device-code phishing tradecraft.

    Next pivot

    Scope persistence and cloud activity after the suspicious session.

    View query
    Q-03

    Validate the user-interrupt-to-success sequence

    What this checks

    Look for the Microsoft-documented sign-in pattern where error 50199 is followed by success for the same user/session or correlation context.

    KQL
    let target_user = "denis@example.com";
    EntraIdSigninEvents
    | where Timestamp >= ago(7d)
    | where AccountUpn =~ target_user
    | where ErrorCode in (0, 50199)
    | summarize
        FirstSeen=min(Timestamp),
        LastSeen=max(Timestamp),
        ErrorCodes=make_set(ErrorCode),
        IPAddresses=make_set(IPAddress, 20),
        RiskLevels=make_set(RiskLevelDuringSignin, 10),
        Applications=make_set(Application, 20)
        by AccountUpn, CorrelationId, SessionId
    | where ErrorCodes has_all (0, 50199)
    | extend Duration=LastSeen-FirstSeen
    | where Duration <= 5m
    | order by FirstSeen asc
    SPL
    index=<entra_signin_index> sourcetype=<defender_entra_signin_sourcetype>
    earliest=-7d
    | eval
        user=lower(coalesce(user, AccountUpn)),
        error_code=coalesce(error_code, ErrorCode),
        correlation_id=coalesce(correlation_id, CorrelationId),
        session_id=coalesce(session_id, SessionId),
        src=coalesce(src, IPAddress)
    | where user="denis@example.com" AND error_code IN (0,50199)
    | stats
        min(_time) as first_seen
        max(_time) as last_seen
        values(error_code) as error_codes
        values(src) as source_ips
        values(RiskLevelDuringSignin) as risk_levels
        by user correlation_id session_id
    | eval duration=last_seen-first_seen
    | where mvfind(error_codes,"50199")>=0 AND mvfind(error_codes,"0")>=0 AND duration<=300
    | convert ctime(first_seen) ctime(last_seen)
    | sort 0 first_seen
    What to look for

    The same user/session contains both 50199 and success within a short interval, supporting device-code phishing investigation.

    Technical details
    Tested signal

    A 50199 user-interrupt event followed shortly by a successful sign-in for the same identity and session context.

    Assumptions
    • Microsoft Defender XDR Entra sign-in events are available.
    • SessionId or CorrelationId is populated consistently enough to correlate the pair.
    Data requirements and relevant fields
    authentication

    Microsoft Defender XDR Entra sign-in events used for the documented 50199-to-success device-code investigation pattern.

    • Timestamp
    • AccountUpn
    • AccountObjectId
    • IPAddress
    • ErrorCode
    • RiskLevelDuringSignin
    • CorrelationId
    • SessionId
    • Application
    • ResourceDisplayName
    • Call
    • ReportId
    KQL schema

    Validate table availability, Entra ID Protection licensing, connector retention, and local field population.

    SPL schema

    Replace index/sourcetype placeholders and map user-risk and sign-in concepts to the local Entra export.

    Limitations
    • 50199 can occur in legitimate authentication flows.
    • The sequence is a campaign-relevant indicator and must be combined with device-code/risk context.

    KQL uses Microsoft Entra / Defender XDR identity telemetry. SPL is a normalized raw-event scaffold and requires local field mapping.

    More reasoning

    Observation

    Microsoft published a 50199-to-success pattern for device-code phishing investigations.

    Working explanation

    The victim paused to enter the device code and then completed the attacker-controlled authentication session.

    What was checked

    Correlate error 50199 and success for the same user, SessionId, and CorrelationId within five minutes.

    Interpretation

    50199 alone is not malicious and must remain joined to device-code/risk context.

    Supporting evidence
  4. Scope post-compromise cloud actions

    The query establishes whether the account progressed beyond token acquisition and which resources require containment.

    Next pivot

    Revoke sessions/tokens, remove malicious persistence, and restrict device-code flow where it is not required.

    View query
    Q-04

    Scope post-compromise persistence and mailbox activity

    What this checks

    Check for Microsoft-observed follow-on behavior after device-code compromise, including device registration, inbox-rule activity, and unusual mail access.

    KQL
    let target_user = "denis@example.com";
    CloudAppEvents
    | where Timestamp >= ago(7d)
    | where AccountObjectId != ""
    | extend UserPrincipalName = tolower(tostring(RawEventData.ObjectId))
    | where UserPrincipalName == tolower(target_user)
        or AccountDisplayName =~ target_user
    | where AccountDisplayName == "Device Registration Service"
        or ActionType in (
            "New-InboxRule",
            "Set-InboxRule",
            "Enable-InboxRule",
            "UpdateInboxRules",
            "MailItemsAccessed"
        )
    | project
        Timestamp,
        AccountDisplayName,
        ActionType,
        ApplicationId,
        IPAddress,
        UncommonForUser,
        ActivityObjects,
        RawEventData
    | order by Timestamp asc
    SPL
    index=<cloud_app_index> sourcetype=<cloud_app_events_sourcetype>
    earliest=-7d
    | eval
        user=lower(coalesce(user, UserPrincipalName, AccountDisplayName)),
        action=coalesce(action, ActionType),
        app_id=coalesce(app_id, ApplicationId),
        src=coalesce(src, IPAddress)
    | where user="denis@example.com"
        AND (
            action IN ("New-InboxRule","Set-InboxRule","Enable-InboxRule","UpdateInboxRules","MailItemsAccessed")
            OR AccountDisplayName="Device Registration Service"
        )
    | fields _time user src action app_id AccountDisplayName UncommonForUser ActivityObjects RawEventData
    | sort 0 _time
    What to look for

    Device registration, mailbox-rule changes, or unusual mail access occurring after the suspicious device-code session.

    Technical details
    Tested signal

    Sensitive cloud actions by the affected identity after the suspicious authentication.

    Assumptions
    • CloudAppEvents is available with Microsoft 365 and device-registration activity.
    • The query is used as a scoping check; the Case does not assume every documented post-compromise behavior occurred.
    Data requirements and relevant fields
    saas audit

    Defender XDR cloud application events for device registration, Exchange actions, and uncommon user activity after compromise.

    • Timestamp
    • AccountObjectId
    • AccountDisplayName
    • ApplicationId
    • ActionType
    • IPAddress
    • ActivityObjects
    • RawEventData
    • UncommonForUser
    KQL schema

    Validate table availability, Entra ID Protection licensing, connector retention, and local field population.

    SPL schema

    Replace index/sourcetype placeholders and map user-risk and sign-in concepts to the local Entra export.

    Limitations
    • Microsoft observed different post-compromise branches across victims; absence of one branch does not clear the account.
    • CloudAppEvents field shape can vary by workload and connector.

    KQL uses Microsoft Entra / Defender XDR identity telemetry. SPL is a normalized raw-event scaffold and requires local field mapping.

    More reasoning

    Observation

    Microsoft observed multiple follow-on branches after device-code compromise.

    Working explanation

    The attacker may have registered a device or accessed Microsoft 365 resources after obtaining token-backed access.

    What was checked

    Check for device registration, inbox-rule changes, unusual mail access, and related cloud activity after the suspicious authentication.

    Interpretation

    The Case does not fabricate a downstream branch; these are source-backed scoping checks for behavior Microsoft observed across campaign victims.

    Supporting evidence

Response

Actions to take

Contain affected systems, preserve evidence, and scope the same behavior elsewhere.
  • Temporarily disable the compromised identity when active attacker use is suspected.
  • Revoke refresh tokens and active sign-in sessions.
  • Review and remove untrusted device registrations created after the compromise.
  • Review mailbox rules, mail access, Graph activity, and other high-value cloud actions after token acquisition.
  • Reset credentials when credential compromise is also suspected, but do not rely on password reset alone to invalidate token-backed access.
  • Block device-code flow through Conditional Access where the organization has no business requirement.
  • Where device code is required, restrict it to tightly defined users, apps, resources, and managed scenarios.
  • Use sign-in risk / user risk Conditional Access controls and phishing-resistant authentication.

Conclusion

What was concluded

The alert is deliberately identity-first. The analyst does not begin with a known malicious IP, malware family, or endpoint process. The starting point is a user whose Entra risk state requires explanation.

Microsoft's April 2026 research makes device-code abuse a strong modern pivot: the victim can authenticate on the legitimate Microsoft page and complete MFA while authorizing an attacker-controlled pending session. Microsoft then observed device-code phishing again in July 2026 in CaptiveCrunch operations.

The Case therefore moves from User Risk to authentication protocol, session sequencing, and cloud follow-on activity. It does not assume that every risky user or every legitimate device-code flow is malicious.

Technical detail

Technical evidence

Stable evidence anchors preserve the fields behind the investigation story.
E-01

E-01Identity telemetry

The investigation begins with an active medium/high risk condition for denis@example.com rather than a malware alert.

Account
denis@example.com
Risk focus
Medium or high active user risk
Investigation goal
Explain the identity-risk signal
Referenced by
E-02

E-02Authentication event

Microsoft observed large-scale device-code phishing in which victims completed MFA on the legitimate Microsoft sign-in page while authenticating the attacker's backend session.

Authentication flow
Device code
Token impact
Valid access token and refresh-token capability
MFA context
Victim completes legitimate authentication
Referenced by
E-03

E-03Authentication event

Microsoft published a hunting pattern that looks for error 50199 followed by success and separately correlates risky sign-ins with URL-click activity.

Sequence
50199 then success
Risk context
Risky sign-in
Correlation
User/session/correlation identifiers
Referenced by
E-04

E-04Cloud audit event

Post-compromise branches observed by Microsoft included device registration, Graph reconnaissance, inbox-rule activity, and mail access.

Post compromise
Device registration / Graph / mailbox activity
Scope note
Observed across campaign victims, not asserted for every account
Referenced by
E-05

E-05Authentication event

Microsoft observed device-code phishing again in July 2026 as part of CaptiveCrunch traffic-manipulation operations, showing the technique remained operationally relevant later in the year.

Observed
July 2026
Delivery context
Captive portal / traffic manipulation
Technique
Device code phishing
Referenced by

Detection engineering

Would your SOC catch this behavior?

See the detection built for this investigation.
View detection

Behavior context

ATT&CK and sources

Behavior mapping

MITRE ATT&CK

  • T1566.002 · Spearphishing LinkEnterprise ATT&CK 19.2

    The attacker delivers a phishing link that leads the victim toward the device-code authorization flow.

  • T1204.001 · Malicious LinkEnterprise ATT&CK 19.2

    The victim follows the malicious link and completes the legitimate device-code sign-in steps.

  • Successful device-code phishing results in valid OAuth access and refresh tokens for the attacker-controlled session.

  • T1078.004 · Cloud AccountsEnterprise ATT&CK 19.2

    The attacker then operates through the compromised cloud identity using valid token-backed access.

These mappings describe the behavior examined here. They do not establish attribution.

Review boundary

Sources and limits

Last reviewed
External sources
7

This case documents the available evidence and analytical limits; control effectiveness is environment-specific.