Build1 publisher3 min readPublished
A passkey 'upgrade' call ends with the attacker's phone number registered as an MFA method
Microsoft Security Research describes callers posing as IT staff to get a Microsoft 365 session relayed or minted to their own client. The lasting damage comes from the MFA method they then register.
The Engineer · Build desk
What happened
- Callers and text messages posing as IT help desk staff reach employees on their personal phone numbers, telling them to update passkeys, MFA or single sign-on urgently.
- Microsoft reports heavy data access and downloading, with the volume of theft and the success of extortion in individual cases still unconfirmed.
- Microsoft's answer to the persistence step is to gate registration of authentication methods behind fresh strong authentication or a managed device, and to monitor unauthorised additions.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Mail delivery logs will not answer the question this incident asks, so the response depends on Exchange mailbox auditing and cloud operation logging having been switched on before the call came in.
- decision Turning off device code flow in Conditional Access puts someone on the hook for an exception list of named users and use cases, and for keeping it small.
- exposure The reach of the compromise is set by the permissions the targeted identity already holds over apps and data, because the attacker inherits them the moment the session is relayed.
- contradiction The dev.to summary grades this critical on the chain from personal-phone contact through MFA registration to the mail and file services, while Microsoft has not confirmed the volume taken, so defenders are sizing it on access.
In the device code path, the victim types a genuine code into a genuine Microsoft sign-in screen, and the tokens that come out are issued to a client the attacker runs [5]. Microsoft's writeup, summarised on dev.to, says the legitimacy of the request cannot be judged by screen validity alone [23]. A user trained to check the domain checks it and sees the right domain.
The other path is older. A fake authentication site relays a sign-in that is not phishing-resistant and captures the credentials and the session token together [4]. Neither path needs browser cookie theft [6], and neither breaks passkey cryptography [7]. Detection tuned to stolen-cookie replay is watching for an artifact these cases do not have to produce [24].
The session is then used for reconnaissance: My Apps, My Sign-Ins, and the business applications the identity can reach [8]. The durable step follows. The attackers register a phone number or an authenticator app of their own as an MFA method on the account, and while credentials or sessions remain valid that method is a route back in [9].
The precondition sits in the source's own list of conditions. Adding a method requires registration operations to be permitted under the compromised authentication state [10]. So the registration policy is the control point. Microsoft's guidance is to require fresh strong authentication or a managed device before a method can be registered, and to monitor unauthorised additions [16]. It also recommends blocking device code flows the business does not need, with exceptions scoped to specific users and use cases [15], and restricting Microsoft 365 access or downloads from unmanaged devices [17].
The first contact arrives on a personal phone number [2], while the detection guidance covers connections to fake authentication domains recorded from monitored devices and communication paths [20]. The opening move therefore happens on a channel the enterprise is not watching [22]. Collection then runs through Microsoft Graph, SharePoint, OneDrive and Exchange [11] over hours to days, which the source treats separately from the initial app discovery [21]. Standard mail delivery logs alone cannot track that collection; it shows up in Exchange mailbox audits and cloud operation logs [19].
Two other conditions have to hold for the chain to work: Conditional Access has to permit the flow, and the compromised identity has to hold permissions to the apps and data [18]. Microsoft also notes that attackers may have researched the employees and the organisation from public information beforehand [3]. The account is dated September 9, 2026 [1]. Heavy data access and downloading has been observed, and the volume of theft and the success of extortion in individual cases remain unconfirmed [12].
What to watch
- Whether Microsoft confirms how much data left in these cases, or that extortion succeeded in any of them.
- Whether the fresh-authentication and managed-device condition for registering authentication methods ships as a default instead of an admin-set policy.
- Whether tenants that block device code flow in Conditional Access then see the AiTM path used against them instead.