Passkey-themed social engineering leads to identity and cloud compromise

What it is

A Microsoft Security Research writeup on an active campaign (observed since May 2026, with a dated example from September 4, 2026) combining phone/SMS-based passkey-SSO social engineering with AiTM and device-code phishing against Microsoft 365 identities, attributed to initial-access actors Storm-3121 and Storm-3032 (feeding ShinyHunters/Falcon and Helix extortion). Beyond what the existing summary covers, the page gives specific technical artifacts: domain patterns, a registrar, exact Graph API field names for persistence detection, and runnable KQL hunts.

How it works

Attackers register throwaway domains following the pattern companyname.maliciousdomain.com (e.g., contoso.add-passkey.com, company-name.integratedsso[.]com, company-name.secure-passkey[.]com), commonly through the Nicenic registrar, operational within hours. Three distinct compromise patterns are documented: (1) anomalous OfficeHome sign-in from an unmanaged device, MFA completed, then ~1 hour of SharePoint/OneDrive enumeration via Graph; (2) device-code flow abused directly after the passkey lure, with the resulting token replayed to bypass MFA; (3) reuse of credentials where MFA was already satisfied via a PhoneAppOTP method the actor had registered days earlier. For persistence, actors add a second MFA factor to the account — a real redacted audit log example shows a software OTP token added with DeviceName: "NO_DEVICE", DeviceToken: "NO_DEVICE_TOKEN", DeviceTag: "SoftwareTokenActivated", under Operation "Update user." in Azure AD audit logs.

Preconditions / Affected

Microsoft 365 tenants using passkey/SSO/MFA enrollment via helpdesk-style flows; particularly exposed when phishing links are opened on personal mobile devices not onboarded to Defender for Endpoint (leaves no endpoint telemetry), and when device-code or authentication-transfer flows are not blocked by Conditional Access.

What to do

• Detect new attacker-controlled MFA devices by diffing StrongAuthenticationPhoneAppDetail/StrongAuthenticationUserDetails on "Update user." events where new device count exceeds old count (full KQL given in the article).
• Hunt Exchange REST exfiltration: CloudAppEvents filtered to ApplicationId == '20893', One Outlook Web clients, grouped by IP/account/hour, flagging ≥500 events/hour.
• Hunt SharePoint/OneDrive exfiltration via the python-httpx user agent on FileDownloaded/FileAccessed/SyncDownloadedFull events, ≥100 files per 2-hour window.
• Hunt anonymous-proxy exfiltration: IsAnonymousProxy == true on file actions, flagging ≥5GB or ≥1000 events per 2-hour bucket.
• Four additional Graph-reconnaissance KQL queries are provided to catch broad multi-category enumeration (≥3 categories, ≥10 requests/30min), privilege/consent discovery, SharePoint/OneDrive traversal via delta/skiptoken paging, and mailbox/attachment enumeration.
• Block device-code and authentication-transfer flows via Conditional Access except where explicitly needed; require phishing-resistant MFA (FIDO2/passkeys, Windows Hello for Business) and managed/compliant devices for Exchange, SharePoint, and Graph-privileged apps; set sign-in frequency to "always" for security-info registration and block registration under high sign-in risk.
• Revoke sessions/tokens and remove attacker-registered authentication methods and mailbox rules on confirmed compromise.

Caveats

The page explicitly cautions that domain registration via Nicenic is not itself evidence of registrar complicity, that the python-httpx user agent alone is not proof of malice, and that IP/domain matches should not be treated as conclusive — all these signals require correlation with identity, volume, and behavioral context before action.