M365 Identity Device Code Grant by an Unusual User (Non-Compliant Device)

Identifies a Microsoft 365 user completing an OAuth device code grant ("Cmsi:Cmsi") from a non-compliant device for the first time within the rule's historical window, regardless of the requesting application or target resource. Device code phishing kits complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them. Because the victim authorizes the flow in their own browser, the grant is frequently completed on a personal or attacker-controlled device that is not enrolled or compliant with the organization's device policies. A user appearing with this device code flow on a non-compliant device for the first time in the lookback window is a strong early indicator of device code phishing, and removing the application and target constraints catches grants against any first-party application, not just the Microsoft Authentication Broker.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/06/02"
  3integration = ["o365"]
  4maturity = "production"
  5updated_date = "2026/06/02"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies a Microsoft 365 user completing an OAuth device code grant ("Cmsi:Cmsi") from a non-compliant device for the
 11first time within the rule's historical window, regardless of the requesting application or target resource. Device code
 12phishing kits complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting
 13token by polling, so MFA does not stop them. Because the victim authorizes the flow in their own browser, the grant is
 14frequently completed on a personal or attacker-controlled device that is not enrolled or compliant with the
 15organization's device policies. A user appearing with this device code flow on a non-compliant device for the first time
 16in the lookback window is a strong early indicator of device code phishing, and removing the application and target
 17constraints catches grants against any first-party application, not just the Microsoft Authentication Broker.
 18"""
 19false_positives = [
 20    """
 21    A user legitimately using the device code flow for the first time on a personal or otherwise non-compliant device,
 22    such as a smart TV, kiosk, IoT device, conference room device, or a personal laptop for a CLI or headless developer
 23    workflow. Review the source ASN, geolocation, application, and the user's device posture to confirm whether the
 24    activity is expected before escalating.
 25    """,
 26]
 27from = "now-9m"
 28index = ["logs-o365.audit-*"]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "M365 Identity Device Code Grant by an Unusual User (Non-Compliant Device)"
 32note = """## Triage and analysis
 33
 34### Investigating M365 Identity Device Code Grant by an Unusual User (Non-Compliant Device)
 35
 36This rule detects a user completing an OAuth device code grant (`Cmsi:Cmsi`) from a device reported as non-compliant in the Microsoft 365 unified audit log for the first time within the rule's historical window (defined by the new terms history setting), independent of the requesting application or target resource. A match means the user has not been seen in this flow during the lookback window, not necessarily that it has never happened. Device code phishing kits (for example Kali365, Storm-2372 tradecraft) drive the device code flow against the genuine Microsoft endpoint and poll the token endpoint in the background, so the victim satisfies MFA while the attacker harvests a fully MFA-satisfied token, typically completed from a personal or attacker-controlled device that is not enrolled or compliant.
 37
 38### Possible investigation steps
 39
 40- Review `o365.audit.UserId` to identify the impacted account and confirm whether the user expected to perform a device code sign-in.
 41- Examine `o365.audit.DeviceProperties` to understand the device posture (compliance, management state, OS, browser) and whether the device is recognized for this user.
 42- Confirm `o365.audit.ApplicationId` and `o365.audit.Target.ID` to identify the application and resource the grant was for. Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) and developer tooling (Azure CLI, PowerShell) are commonly abused.
 43- Inspect `source.as.number`, `source.as.organization.name`, `source.ip`, and `source.geo.*` and compare with the user's normal sign-in origins. Hosting, VPN, or datacenter providers are unusual for interactive user authentication.
 44- Examine `user_agent.original` for automation or headless-browser patterns.
 45- Pivot to `azure.signinlogs` for the corresponding `deviceCode` sign-in, conditional access decisions, and any concurrent non-interactive token-issuance legs from a different ASN (the kit's polling backend).
 46- Pivot to `azure.graphactivitylogs` for follow-up Graph activity (`/me` recon, mailbox or file enumeration).
 47- Check `azure.auditlogs` for subsequent device registration events on the user, which device code phishing kits use to establish Primary Refresh Token persistence.
 48
 49### False positive analysis
 50
 51- A legitimate first-time device code sign-in on a personal or non-compliant device.
 52- Provisioning of input-constrained devices (smart TVs, kiosks, IoT, conference room devices).
 53- CLI or headless developer workflows using the device code flow on an unmanaged device.
 54- If a user or device combination is confirmed benign and recurring, suppress it via a rule exception rather than broadening the query.
 55
 56### Response and remediation
 57
 58- Contact the user to confirm whether they initiated the device code sign-in or may have entered a code presented on a phishing page.
 59- If unauthorized, revoke all refresh tokens for the user and reset credentials to invalidate the harvested token.
 60- Review and remove any unauthorized device registrations to cut off Primary Refresh Token persistence.
 61- Review recent Microsoft Graph, Exchange, SharePoint, and Teams activity for the user for signs of recon or exfiltration.
 62- Restrict device code authentication to only the users and applications that require it, and require compliant or hybrid-joined devices, via Conditional Access policies.
 63- Educate users on device code phishing and the risk of entering codes presented by unsolicited documents or messages.
 64"""
 65references = [
 66    "https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/",
 67    "https://arcticwolf.com/resources/blog/kali365-expands-into-aws-microsoft-okta-xerox-max-messenger/",
 68    "https://www.ic3.gov/PSA/2026/PSA260521",
 69    "https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/",
 70    "https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/",
 71]
 72risk_score = 47
 73rule_id = "7e2abdb3-c7b0-4e11-ba2f-6657602800a1"
 74setup = """#### Required Microsoft 365 Audit Logs
 75This rule requires the Microsoft 365 integration with unified audit logs (Azure AD / Entra sign-in events surfaced in the Microsoft 365 audit log) enabled and shipping to Elastic.
 76"""
 77severity = "medium"
 78tags = [
 79    "Domain: Cloud",
 80    "Domain: SaaS",
 81    "Domain: Identity",
 82    "Data Source: Microsoft 365",
 83    "Data Source: Microsoft 365 Audit Logs",
 84    "Use Case: Identity and Access Audit",
 85    "Use Case: Threat Detection",
 86    "Resources: Investigation Guide",
 87    "Tactic: Initial Access",
 88]
 89timestamp_override = "event.ingested"
 90type = "new_terms"
 91
 92query = '''
 93event.dataset: "o365.audit"
 94    and o365.audit.ExtendedProperties.RequestType: "Cmsi:Cmsi"
 95    and o365.audit.Actor.Type: (0 or 2 or 3 or 5 or 10)
 96    and o365.audit.DeviceProperties.Value: "False"
 97'''
 98
 99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102[[rule.threat.technique]]
103id = "T1078"
104name = "Valid Accounts"
105reference = "https://attack.mitre.org/techniques/T1078/"
106[[rule.threat.technique.subtechnique]]
107id = "T1078.004"
108name = "Cloud Accounts"
109reference = "https://attack.mitre.org/techniques/T1078/004/"
110
111
112[[rule.threat.technique]]
113id = "T1566"
114name = "Phishing"
115reference = "https://attack.mitre.org/techniques/T1566/"
116[[rule.threat.technique.subtechnique]]
117id = "T1566.002"
118name = "Spearphishing Link"
119reference = "https://attack.mitre.org/techniques/T1566/002/"
120
121
122
123[rule.threat.tactic]
124id = "TA0001"
125name = "Initial Access"
126reference = "https://attack.mitre.org/tactics/TA0001/"
127[[rule.threat]]
128framework = "MITRE ATT&CK"
129[[rule.threat.technique]]
130id = "T1550"
131name = "Use Alternate Authentication Material"
132reference = "https://attack.mitre.org/techniques/T1550/"
133[[rule.threat.technique.subtechnique]]
134id = "T1550.001"
135name = "Application Access Token"
136reference = "https://attack.mitre.org/techniques/T1550/001/"
137
138
139
140[rule.threat.tactic]
141id = "TA0005"
142name = "Defense Evasion"
143reference = "https://attack.mitre.org/tactics/TA0005/"
144
145[rule.new_terms]
146field = "new_terms_fields"
147value = ["o365.audit.UserId"]
148[[rule.new_terms.history_window_start]]
149field = "history_window_start"
150value = "now-7d"

Triage and analysis

Investigating M365 Identity Device Code Grant by an Unusual User (Non-Compliant Device)

This rule detects a user completing an OAuth device code grant (Cmsi:Cmsi) from a device reported as non-compliant in the Microsoft 365 unified audit log for the first time within the rule's historical window (defined by the new terms history setting), independent of the requesting application or target resource. A match means the user has not been seen in this flow during the lookback window, not necessarily that it has never happened. Device code phishing kits (for example Kali365, Storm-2372 tradecraft) drive the device code flow against the genuine Microsoft endpoint and poll the token endpoint in the background, so the victim satisfies MFA while the attacker harvests a fully MFA-satisfied token, typically completed from a personal or attacker-controlled device that is not enrolled or compliant.

Possible investigation steps

  • Review o365.audit.UserId to identify the impacted account and confirm whether the user expected to perform a device code sign-in.
  • Examine o365.audit.DeviceProperties to understand the device posture (compliance, management state, OS, browser) and whether the device is recognized for this user.
  • Confirm o365.audit.ApplicationId and o365.audit.Target.ID to identify the application and resource the grant was for. Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) and developer tooling (Azure CLI, PowerShell) are commonly abused.
  • Inspect source.as.number, source.as.organization.name, source.ip, and source.geo.* and compare with the user's normal sign-in origins. Hosting, VPN, or datacenter providers are unusual for interactive user authentication.
  • Examine user_agent.original for automation or headless-browser patterns.
  • Pivot to azure.signinlogs for the corresponding deviceCode sign-in, conditional access decisions, and any concurrent non-interactive token-issuance legs from a different ASN (the kit's polling backend).
  • Pivot to azure.graphactivitylogs for follow-up Graph activity (/me recon, mailbox or file enumeration).
  • Check azure.auditlogs for subsequent device registration events on the user, which device code phishing kits use to establish Primary Refresh Token persistence.

False positive analysis

  • A legitimate first-time device code sign-in on a personal or non-compliant device.
  • Provisioning of input-constrained devices (smart TVs, kiosks, IoT, conference room devices).
  • CLI or headless developer workflows using the device code flow on an unmanaged device.
  • If a user or device combination is confirmed benign and recurring, suppress it via a rule exception rather than broadening the query.

Response and remediation

  • Contact the user to confirm whether they initiated the device code sign-in or may have entered a code presented on a phishing page.
  • If unauthorized, revoke all refresh tokens for the user and reset credentials to invalidate the harvested token.
  • Review and remove any unauthorized device registrations to cut off Primary Refresh Token persistence.
  • Review recent Microsoft Graph, Exchange, SharePoint, and Teams activity for the user for signs of recon or exfiltration.
  • Restrict device code authentication to only the users and applications that require it, and require compliant or hybrid-joined devices, via Conditional Access policies.
  • Educate users on device code phishing and the risk of entering codes presented by unsolicited documents or messages.

References

Related rules

to-top