On 9 September, Microsoft published details of an intrusion pattern that starts with a phone call. Someone claiming to be from IT tells an employee that their passkey, MFA or single sign-on setup has to be updated today. A text message with a link follows. Within minutes the attacker holds a working Microsoft 365 session, and shortly after that, an authentication method of their own on the account.

The lure talks about passkeys, but nobody is breaking passkeys. Microsoft notes that passkey enrolment is often not the goal at all. The story gives the caller a believable reason to walk someone through a sign-in they would otherwise question. That makes this a test of your help desk process, your Conditional Access design and your detection, more than of any single authentication technology.

Microsoft has observed the activity since May 2026 and links the initial access to groups it tracks as Storm-3121 and Storm-3032, which supply data extortion operations. Microsoft’s write-up contains the indicators and hunting queries. This article looks at what it should change in how you test.

How the takeover works

The attackers research the organisation first, using public profiles to find names, roles and reporting lines. They register generic domains such as setupmypasskey[.]com and place the target company’s name in front, so the link reads like a company portal. New domains go live within hours, which leaves little time for blocklists to catch up.

Microsoft describes three routes in:

  • Adversary-in-the-middle phishing. A proxy page relays the real Microsoft sign-in. The employee completes MFA and the attacker keeps the session. In one timeline, the MFA prompt and a usable session were about a minute apart.
  • Device code phishing. The employee enters a code on the genuine Microsoft page. That approval issues a token to the attacker’s client. This does not require stealing a password or browser cookie: the approval happens on a genuine Microsoft page.
  • Credentials from an earlier compromise. The attacker signs in with a password they already hold and an authenticator app they registered days before the campaign.

The first move after access is persistence. The attacker registers a phone number, authenticator app or software token under their control, so they can satisfy later MFA challenges without the employee. Continued access still depends on valid credentials or tokens and the response taken by defenders. Reconnaissance through Microsoft Graph follows: users, groups, admin roles, registered authentication methods and applications, then SharePoint, OneDrive and mailboxes. Separate IP addresses handle sign-in, reconnaissance and exfiltration, so no single network indicator ties the stages together.

Why current controls may not catch it

Three details in the report matter to anyone who owns identity or detection.

First contact happens outside your estate. The call and the text arrive on a personal phone. If that device is not covered by your endpoint monitoring, you may have no endpoint record of the interaction. Microsoft notes that an employee remembering a phone call is sometimes the earliest evidence investigators have.

MFA is completed, not bypassed. Push approvals, SMS codes and authenticator codes all confirm the session the attacker is relaying. Phishing-resistant methods such as FIDO2 security keys, passkeys and Windows Hello for Business prevent the proxied sign-in from completing. Device code phishing works differently: it abuses a legitimate flow, so policy has to block it.

Each Graph request looks ordinary. Calls to /users or /sites happen all day in any tenant. The signal is the sequence: a new authentication method, then enumeration of roles and methods, then bulk file or mail access by the same identity. Alerting that evaluates events one at a time can let the whole pattern through.

The controls that change the outcome

Microsoft’s list of recommendations is long. For a Microsoft 365 assessment, we would check these controls and the exceptions that affect them:

  • Protect security info registration. Adding an MFA method should require phishing-resistant authentication, a managed device or trusted location, and a fresh sign-in. Block registration outright when sign-in risk is high. Also test how a new employee or someone who has lost their authenticator can enrol safely. A verified, time-limited Temporary Access Pass process can support bootstrap and recovery, provided the registration authentication-strength policy allows it. Requiring a method the user cannot yet register can lock them out.
  • Block device code flow. Use Conditional Access to block device code and authentication transfer flows, with documented exceptions for verified business needs. Check who uses each exception and whether it is still required.
  • Roll out phishing-resistant MFA where it matters first. Start with administrators, finance, executives and the help desk itself, then widen.
  • Require compliant devices for data. Access to Exchange, SharePoint and privileged Graph applications from an unmanaged device should be refused, or limited to browser sessions without download or sync.
  • Verify identity before any help desk reset. An attacker calling your help desk to reset an employee’s MFA is the same trick aimed the other way. Define how callers are verified, and alert on every reset.
  • Turn on the logs. Enable Microsoft Graph activity logs and mailbox auditing, and alert on authentication method changes. Graph activity logs require Entra ID P1 or P2 and a configured storage or analytics destination; they are not retained without one. Verify collection and retention before an incident. Missing logs may leave significant gaps when reconstructing reconnaissance.

Exceptions accumulate. A meeting room device needs device code flow. A contractor group sits outside the compliant device rule. An old policy still lets users add a phone number from anywhere. An attacker does not need every control to fail, only the exception that covers the account they reached.

What to test

A configuration review shows what the policies say. It does not show how they behave for the people this campaign targets. That takes testing against your real tenant, with scope and safeguards agreed in advance.

A useful exercise answers questions like these:

  • Can a standard user in finance or HR complete a device code sign-in today, and from which devices and locations?
  • With a valid session, can that user register a new authenticator app or phone number without stronger authentication?
  • Which Conditional Access exclusions apply to high-value users, and who approved them?
  • When an employee receives an unsolicited call about passkey setup, do they verify it through a known IT contact and report the request before following the caller’s instructions?
  • Does the help desk verify a caller before resetting MFA or issuing a Temporary Access Pass, and does that still hold under time pressure?
  • If a test account gains an extra authentication method and starts enumerating roles or downloading files, does anyone receive an alert? Can responders identify and remove the added method, revoke sessions and verify that access has stopped?

The policy and registration questions belong in an identity assessment covering Entra ID and Conditional Access. Test the employee-facing call and the help desk’s reset process separately through a controlled, pre-agreed social engineering exercise. Include first-time enrolment and lost-authenticator recovery in scope, so the stronger registration policy is tested alongside its fallback process. A response exercise with your defenders should record the timeline from first sign-in to confirmed loss of attacker access.

Do not stop the response test when someone clicks “revoke sessions”. Effective revocation depends on the application and token type. For this campaign, Microsoft also recommends resetting compromised credentials, removing attacker-added authentication methods and mailbox rules, and securely re-registering methods. Verify the outcome by checking that the test account’s attacker-controlled access no longer works.

Whichever route you choose, ask for findings tied to a specific policy, group or process, with an owner and a way to confirm the fix. A report that says “MFA can be phished” describes the internet. It does not tell your team which exclusion to remove first.

A note on the evidence

This is Microsoft’s account of incidents it investigated, and attribution to named groups carries the usual limits of a vendor report. The listed domains will change quickly. The sequence of steps is the durable part, and it is the part worth testing against.

If you run Microsoft 365 and want to know how your tenant holds up against this pattern, talk to us about scoping an identity-focused assessment.