An employee gets a call from someone claiming to be IT: update your passkey now or lose access. In the intrusions Microsoft described on September 9, the passkey story was often a pretext for stealing a session or getting the employee to authorize an attacker-controlled client.

TL;DR

  • Microsoft says the activity has been observed since May 2026 and can begin with calls or messages to a personal phone.
  • The useful investigation chain is unusual sign-in, new authentication method, Microsoft Graph reconnaissance, then SharePoint, OneDrive, or mailbox access.
  • A real passkey remains phishing-resistant when used through the intended flow. The attacker exploited alternative flows and support pretexts, not a demonstrated break of passkey cryptography.

The Call Is Only the First Event

Microsoft’s research report describes two initial paths. In adversary-in-the-middle phishing, a fake sign-in page can capture credentials and session tokens. In device-code phishing, the victim enters a code on a legitimate Microsoft page, but the resulting authorization belongs to the attacker’s client. The first step may happen on a personal phone outside corporate endpoint monitoring.

After access, Microsoft observed attacker-added authentication methods, Graph queries to map users and resources, and downloads or email collection from Microsoft 365. A single Graph request to /users or /sites is routine; a sequence of directory discovery, permission checks, and content retrieval by the same identity is much more informative. Microsoft attributes parts of this access ecosystem to several tracked actor groups. The shared behavior is more useful for defenders than assuming every matching event belongs to one gang.

Hunt the Sequence Across Services

Start with Entra sign-in and audit logs for unfamiliar sign-ins followed by authentication-method registration or device-code activity. Join by user and time to Graph activity logs, SharePoint and OneDrive downloads, and Exchange mailbox auditing. Look for a new method followed by broad enumeration and content access from a session or application the user does not recognize. Investigate the employee’s account history and ask about unsolicited support contact; that account may be the only record of the initial call.

For a confirmed compromise, Microsoft recommends revoking sessions and refresh tokens, resetting credentials, removing unauthorized authentication methods and mailbox rules, and requiring secure re-registration. Review what files and mail were accessed before declaring containment complete. A password reset alone does not establish that every existing session and persistence path was removed.

Reduce repeat exposure by requiring phishing-resistant MFA through Conditional Access, protecting authentication-method registration, limiting sensitive cloud access from unmanaged devices, and blocking device-code flows where there is no business need. Give employees a known channel to verify unexpected IT calls. The policy should make it easy to stop the call and check, even when the caller claims urgency.

Sources