Skip to content

Microsoft

Summary

On September 9, 2026, Microsoft Security Research published a research post documenting active cloud-based intrusions observed since May 2026 across multiple accounts, in which the opening move is identity-focused social engineering dressed up as passkey / MFA / SSO "helpdesk" activity. The durable sequence, repeated across engagements, is: phone-based social engineering → AiTM phishing or device-code flow → actor-registered MFA method (persistence) → Microsoft Graph reconnaissance → high-volume SharePoint / OneDrive / Exchange data collection and suspected exfiltration, all through proxy-associated infrastructure.

Microsoft Threat Intelligence assesses that the initial-access activity is used by a range of threat actors, including Storm-3121 (which conducts initial-access activity leading to ShinyHunters and Falcon extortion) and Storm-3032 (actors that splintered from the BlackFile group and now operate under the Helix extortion banner), as well as others. The post publishes a full KQL/Sentinel hunt kit and a Graph reconnaissance pattern matrix.

Tags

The attack chain

Initial access: passkey and SSO lures

  • The attack usually begins with a call or SMS on the victim's personal phone from someone claiming to be the organization's IT helpdesk, creating urgency that a passkey, MFA, or SSO configuration must be updated immediately to avoid disruption, with a link to a site that closely resembles the legitimate Microsoft sign-in experience.
  • The passkey narrative is pretext, not objective: it exists to drive the victim into an adversary-in-the-middle (AiTM) phishing or device-code authentication flow. In AiTM the actor captures credentials and session tokens; in the device-code flow the victim approves a token for an attacker-controlled client, and the token can then be replayed, bypassing MFA without a stolen browser cookie.
  • Lures are personalized: pre-attack research on employees and org structure (social/professional platforms), and, where an account is already compromised, passkey-themed messages sent through Microsoft Teams from a trusted employee identity, which significantly raises engagement.
  • If the victim opens the link on a personal, unmanaged device (not onboarded to Defender for Endpoint), endpoint telemetry is absent; the employee's recollection of the call/text is often the only early evidence.

Phishing infrastructure: reusable domains, victim-name subdomains

  • Rapidly deployed phishing infrastructure around themes: passkeys, SSO enrollment, account activation, identity verification.
  • Generic domains are registered and the target organization's name is embedded as a subdomain, contoso[.]add-passkey[.]com, so the URL looks familiar; multiple domains per target allow rotation. Domains are operational within hours, and are often registered with Nicenic (a registrar previously observed in extortion campaigns, Microsoft notes registration alone is not evidence of registrar involvement).
  • Observed themes: passkey (passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, add-passkey[.]com), SSO/IdP (integratedsso[.]com, oktasession[.]com), key setup/sync (keysyncos[.]com, oskeysync[.]com, oskeysetup[.]com, oskeyregister[.]com, syncmykey[.]com, myconnectkey[.]com, oskeyconnect[.]com), setup/verification (validationsetupac[.]com, portalsetuphub[.]com).

Identity compromise, then MFA persistence

  • Observed sequences: (a) anomalous OfficeHome sign-in from an unmanaged context → MFA (non-phishing-resistant) completed via AiTM → same session enumerates My Apps, My Sign-Ins, Microsoft Approval Management, Account Controls, then SharePoint/OneDrive via Graph; (b) device-code flow after the passkey lure, token replay; (c) sign-in with compromised credentials where MFA was approved by a PhoneAppOTP method the actor had registered days earlier, pre-seeded persistence, driven by an automated Node.js + Microsoft Graph system.
  • First objective after access: enroll an actor-controlled MFA method, a new phone number, authenticator app, or software-based OTP token. Microsoft shows a real-world Update user. / StrongAuthenticationPhoneAppDetail record in which a second entry appears with DeviceName: NO_DEVICE, DeviceTag: SoftwareTokenActivated, AuthenticationType: 2, a durable, attacker-controlled factor that survives until explicitly removed.

Graph reconnaissance

  • A deliberate, multi-stage inventory of the tenant: /organization, /subscribedSkus, /licenseDetails (tenant profile); /users, /groups, /members, /transitiveMembers (directory); /directoryRoles, /roleManagement, /authentication/methods (privilege + MFA discovery); /applications, /servicePrincipals, /oauth2PermissionGrants, /appRoleAssignments (application + consent discovery); /sites, /lists, /drives, /drive/items, /root/children, /search (SharePoint/OneDrive discovery); /messages, /mailFolders, /attachments (mailbox discovery); with automation/pagination ($top, $skip, $skiptoken, /delta, /search).
  • No single Graph call looks suspicious, /users or /groups is routine. The tell is one identity/application/token systematically traversing multiple recon categories, then content endpoints, from the same source context, assessed holistically, not call-by-call. Infrastructure rotates across the lifecycle (different IPs for auth, recon, and exfil), so correlation across stages, not per-IP blocklists, is the detection.

Collection and suspected exfiltration

  • High-volume SharePoint Online and OneDrive FileAccessed / FileDownloaded activity, plus Exchange Online access via REST APIs (mailbox and attachment retrieval).
  • The pace is deliberately throttled, fewer than 1,000 files or emails per hour, spanning hours to days, blending into normal enterprise usage while steadily extracting large volumes.
  • A python-httpx user agent was associated with high-volume SharePoint/OneDrive access in several cases; Microsoft is explicit that the user agent alone is not malicious, evaluate volume, identities, source infrastructure, and prior identity-compromise evidence together.
  • Exfiltration paths in the hunt kit: anonymous-proxy CloudAppEvents, One Outlook Web REST event bursts (≥500/hour per account/IP), and python-httpx download windows (≥100 files/2h).

Attribution

Microsoft Threat Intelligence assesses the initial-access activity is used by a range of threat actors, and names Storm-3121 (initial access leading to ShinyHunters and Falcon extortion) and Storm-3032 (a splinter of BlackFile, now operating under the Helix extortion banner). Activity observed since May 2026. No named malware family, C2 infrastructure, or victim list is published; domains/IPs/hosting providers "can change quickly."

Defender guidance (from the post)

  1. Investigate as a connected sequence: unusual sign-in → authentication-method enrollment → Graph reconnaissance → token issuance → abnormal SaaS download / mailbox activity. Prioritize unusual sign-ins followed by new auth-method registration.
  2. Hunt the Graph recon matrix: identities/applications touching ≥3 recon categories from the same IP within 30 minutes (the published query thresholds: ≥10 requests, ≥3 categories, ≥6 distinct paths); control-plane recon on /directoryRoles, /authentication/methods, /oauth2PermissionGrants; repository discovery via /search, /delta, $skiptoken/$top paging; mailbox/attachment enumeration (≥3 attachment requests in a window).
  3. Hunt exfil: One Outlook Web REST bursts, python-httpx + uncommon-for-user ISP/user-agent on download events, anonymous-proxy CloudAppEvents.
  4. Contain confirmed compromises: revoke sessions and refresh tokens, reset credentials, remove attacker-registered authentication methods and mailbox rules, require secure re-registration.
  5. Reduce future risk: do not treat an IP/domain match as conclusive, validate behavior, persistence events, and data-access volume; enforce phishing-resistant MFA (FIDO2/passkeys, Windows Hello for Business) via Conditional Access; require managed, compliant devices for Exchange, SharePoint, and Graph-privileged apps; keep the passkey/MFA-update pretext on the phishing blocklist and train helpdesk-aware verification (call back through known numbers before acting on "MFA update" requests).

Durable read

The passkey is a smokescreen, not the target: the campaign's value is in converting a human into a token issuer (AiTM or device-code) and then installing an attacker-owned MFA factor so the compromise outlives every password and session reset that doesn't specifically remove the registered method. Defenders should treat "new authentication method added after an unusual sign-in" as a near-always-investigate event, and hunt behavioral progression (recon → collection → exfil) instead of single-call anomalies.

Sources