Storm-2372 took over Microsoft 365 accounts without stealing a single password, by persuading targets to type an attacker-generated device code into the genuine Microsoft sign-in page. Microsoft Threat Intelligence named the cluster in February 2025, assessed it as aligned with Russian interests, and in a July 2026 update assessed it as an initial access sub-cluster of Midnight Blizzard. This profile covers who the group is, what it targets, the ATT&CK techniques involved, how it turns one code entry into refresh tokens, a registered device and a Primary Refresh Token, and the Entra ID detections and Conditional Access controls that stop it. It goes beyond the technique-level Device Code Phishing Guide by focusing on this actor's tradecraft and the identity artefacts it leaves. It is written for Entra ID administrators, SOC analysts and threat intelligence teams.
Key takeaways
- The sign-in page is real. The victim authenticates on Microsoft's own site, so password strength, URL filtering and many MFA prompts do not help; the attacker simply receives the resulting access and refresh tokens.
- Rapport comes first. Microsoft observed the actor posing as prominent people on WhatsApp, Signal and Microsoft Teams before sending fake Teams meeting invitations whose "meeting ID" was the device code.
- Tokens become a device. From 14 February 2025 the actor used the Microsoft Authentication Broker client ID so that its refresh token could register an attacker-controlled device in Entra ID and obtain a Primary Refresh Token.
- Mailboxes were searched for secrets. Through Microsoft Graph the actor searched for words such as password, admin, credentials, secret, teamviewer and anydesk, then exfiltrated matching mail.
- Blocking device code flow works. Microsoft recommends blocking device code flow wherever possible with the Conditional Access authentication flows condition; restrict device registration and revoke sessions on any suspected compromise.
Who they are (names and aliases)
Storm-2372 is a Microsoft designation; "Storm" marks a developing cluster in Microsoft's naming system. In its February 2025 report Microsoft described Storm-2372 as a suspected nation-state actor and assessed with moderate confidence that it aligns with Russian interests, victimology and tradecraft. In an update dated 31 July 2026, Microsoft assessed Storm-2372 to be an initial access operations sub-cluster of Midnight Blizzard, based on technical and operational overlaps. Midnight Blizzard is Microsoft's name for the group also tracked as APT29; see the APT29 (Midnight Blizzard) Threat Actor Profile.
Volexity published research on the same day describing Russian device code phishing by clusters it calls UTA0304, UTA0307 and CozyLarch (which it links to APT29). Volexity's report does not mention Storm-2372, so this profile does not map those clusters to it. As of ATT&CK v20, MITRE has no group entry named Storm-2372. For how vendor names relate, see the Threat Actor Naming Conventions Guide.
Targeting and motivation
Microsoft reports activity since August 2024 against government, non-governmental organisations, IT services and technology, defence, telecommunications, health, higher education, and energy and oil and gas, across Europe, North America, Africa and the Middle East. The victim set and the post-compromise mailbox searches point to intelligence collection, with keywords such as ministry and gov alongside credential terms.
| Date | Event | Source |
|---|---|---|
| August 2024 | Earliest activity Microsoft attributes to Storm-2372 | Microsoft |
| 13 February 2025 | Microsoft publishes its Storm-2372 report; Volexity publishes related research on Russian device code phishing | Microsoft; Volexity |
| 14 February 2025 | Microsoft update: actor switches to the Microsoft Authentication Broker client ID and registers devices | Microsoft |
| 31 July 2026 | Microsoft assesses Storm-2372 as an initial access sub-cluster of Midnight Blizzard | Microsoft |
Tactics and techniques (MITRE ATT&CK)
Microsoft's report does not list ATT&CK IDs. The mapping below is ours, from Microsoft's documented behaviour, checked against ATT&CK v20.
| Tactic | Technique (ATT&CK v20) | Documented behaviour |
|---|---|---|
| Stealth | T1684.001 Impersonation | Posing as prominent people relevant to the target to build rapport |
| Initial access | T1566.003 Phishing: Spearphishing via Service | Contact through WhatsApp, Signal and Microsoft Teams, then fake Teams meeting invitations |
| Credential access | T1528 Steal Application Access Token | Victim completes the device code flow and the actor receives access and refresh tokens |
| Lateral movement | T1550.001 Use Alternate Authentication Material: Application Access Token | Tokens used against Microsoft Graph and Exchange without the password |
| Persistence | T1098.005 Account Manipulation: Device Registration | Refresh token from the Authentication Broker client used to register an actor-controlled device and obtain a PRT |
| Collection | T1114.002 Email Collection: Remote Email Collection | Graph keyword searches of mailboxes and exfiltration of matching messages |
| Lateral movement | T1534 Internal Spearphishing | New device code lures sent from the compromised mailbox to colleagues |
| Command and control | T1090 Proxy | Proxies regionally matched to the target to make sign-ins look local |
How they abuse identities and credentials
Every step trades one identity artefact for a stronger one.
- Device code: the actor requests a legitimate device code from Entra ID and hands it to the target as a meeting ID. When the target enters it at the device login page and signs in, Entra ID issues tokens to the actor's session. No malicious link or attachment is needed, which is why Volexity notes users may not recognise it as phishing.
- Refresh token: the refresh token keeps access alive for as long as it stays valid, independent of the user's password. A password reset alone does not end the session.
- Broker refresh token to device: by requesting the code under the Microsoft Authentication Broker client ID, the actor obtained a refresh token that could request a token for the Device Registration Service and enrol its own device in Entra ID.
- Primary Refresh Token: with a registered device and the same refresh token, the actor obtained a PRT, the device-bound token Windows uses for single sign-on, and used it to reach organisational resources and collect email. See the Entra ID Primary Refresh Token (PRT) Security Guide.
- Mailbox as a credential store: Graph searches for password, credentials, secret, admin and remote access tool names target the service account passwords, API keys and remote access credentials that people email to each other. Those become the next access path.
The registered device is itself a non-human identity in the directory. Treat any device object created during a suspected compromise as an attacker credential and remove it, not just the user's sessions.
Notable incidents
- August 2024 to February 2025 campaign: Microsoft's report describes victims across government, NGOs, defence, telecommunications, health, higher education and energy in four regions; it does not name victim organisations.
- Rapid adaptation, February 2025: within 24 hours of Microsoft's initial publication, the actor moved to the Authentication Broker client ID and device registration, showing it monitors defender reporting.
- Related Russian device code operations: Volexity documented lures impersonating the US Department of State, a senior Ukrainian Ministry of Defence official and a European Parliament member from mid-January 2025. These are context, not confirmed Storm-2372 activity.
No breach analysis page on this site is attributed to Storm-2372, so none is linked.
Detection and defence
Detections in Entra ID and Defender
| Signal | Where | Notes |
|---|---|---|
| Sign-ins with authentication protocol Device code (authenticationProtocol deviceCode) | Entra ID sign-in logs | In most organisations these should be rare and tied to known devices; investigate others |
| Original transfer method Device code flow on later sign-ins | Sign-in log activity details | Persists in refreshed sessions, so it reveals sessions born from a device code |
| Clicks to microsoft.com/devicelogin, aka.ms/devicelogin or login.microsoftonline.com/common/oauth2/deviceauth | Defender XDR UrlClickEvents, proxy and email logs | Correlate with a successful device code sign-in for the same user shortly after |
| Error 50199 followed by success | Sign-in logs | Microsoft notes this pause can indicate a user entering a code from a phishing message |
| Risky sign-ins, Activity from anonymous IP address, Microsoft Entra threat intelligence | Entra ID Protection | Risk detections Microsoft names for this activity |
| New device registration soon after a device code sign-in | Entra audit logs; CloudAppEvents for Device Registration Service | Key signal for the February 2025 technique |
| Graph mail searches for credential keywords | Mailbox audit and Graph activity logs | Look for search activity from new sessions or unusual locations |
See the Entra ID Sign-In and Audit Log Detection Guide for query building.
Prevent
- Block device code flow: create a Conditional Access policy using the authentication flows condition. Run it in report-only mode first and filter sign-in logs for device code use to find legitimate cases such as conference room devices, then allow only those by device, network location or group.
- Mind Device Registration Service: since early September 2024, authentication flows policies targeting all resources also apply to Device Registration Service; exclude it (client ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) only if you genuinely register devices with device code.
- Restrict device registration: limit which users can join or register devices in Entra ID, and require MFA for registration.
- Risk-based Conditional Access and Continuous Access Evaluation: block or challenge risky sign-ins and let CAE revoke sessions for high-risk users.
- Phishing-resistant MFA: use FIDO2 security keys or passkeys and avoid telephony factors; block legacy authentication. Note that MFA alone does not stop device code phishing, because the victim completes MFA for the attacker. See the Phishing-Resistant MFA Guide and Conditional Access Guide.
- Train for this lure: tell staff that no genuine meeting asks them to type a code at a Microsoft sign-in page, and to check the application name shown in the prompt.
Respond
- Revoke the user's refresh tokens with revokeSignInSessions and require re-authentication.
- Delete any device objects registered during the suspected window and review their sign-ins.
- Review mailbox audit records for Graph searches and exports, and list the messages accessed.
- Rotate every credential, key or remote access password found in the accessed mail.
- Search for internal device code lures sent from the account and warn recipients.
Metrics
- Number of device code sign-ins per month outside the approved exception group (target zero).
- Percentage of users covered by the authentication flows block policy.
- Number of device registrations not matched to an enrolment request.
- Median time from a suspected device code sign-in to session revocation and device removal.
- Percentage of privileged users on phishing-resistant MFA.
Framework mapping
| Defensive need | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Restrict risky authentication flows | AC-17 Remote Access; IA-2 Identification and Authentication | PR.AA-03 |
| Control device identities | IA-3 Device Identification and Authentication | PR.AA-01 |
| Session revocation | AC-12 Session Termination | RS.MI-01 |
| Detect anomalous sign-ins | AC-2(12) Account Monitoring for Atypical Usage; SI-4 | DE.CM-03 |
| User awareness | AT-2 Literacy Training and Awareness | PR.AT-01 |
Practitioner checklist
- Run a report-only authentication flows policy and list every legitimate device code sign-in.
- Enforce the device code block for all users except a named exception group on known devices and networks.
- Restrict device registration to authorised users with MFA.
- Alert on device code sign-ins, originalTransferMethod Device code flow and new device registrations that follow them.
- Hunt mailbox and Graph audit logs for credential keyword searches.
- Prepare a response runbook covering revokeSignInSessions, device deletion and secret rotation.
- Brief staff who use Signal, WhatsApp or Teams with external contacts about meeting code lures.
- Move privileged users to phishing-resistant MFA and keep CAE enabled.
Standards and references
- Microsoft Threat Intelligence: Storm-2372 conducts device code phishing campaign
- Microsoft Learn: Authentication flows as a condition in Conditional Access policy
- Volexity: Multiple Russian Threat Actors Targeting Microsoft Device Code Authentication
- MITRE ATT&CK: Steal Application Access Token
- MITRE ATT&CK: Account Manipulation: Device Registration
- MITRE ATT&CK: Phishing: Spearphishing via Service
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Device Code Phishing Guide · APT29 (Midnight Blizzard) Threat Actor Profile · Entra ID Security Guide · Russia State Cyber Operations Guide · Threat Actor Groups Guide