Leadership1 publisher2 min readPublished
Fake helpdesk calls use the passkey rollout as the pretext for Microsoft 365 intrusions
Microsoft has tracked intrusions since May in which callers posing as IT told employees a passkey update was due, then steered them to a phishing page or a device-code prompt. The enrollment step is where the chain starts.
The Board Room · Leadership desk
What happened
- Microsoft Security Research says it has tracked cloud intrusions since May in which attackers posed as IT helpdesk staff and told employees a passkey needed to be updated or enrolled.
- The approach typically comes as a call or message to an employee's personal mobile number, claiming a passkey, MFA or SSO configuration must be changed immediately to avoid disruption.
- Victims are sent to a page resembling a Microsoft sign-in, where an adversary-in-the-middle setup captures credentials and session tokens, or to a real Microsoft device-code prompt that authorizes the attacker's client.
- Inside a tenant, the attackers enumerated users, groups, roles and applications through Microsoft Graph, then went into SharePoint and OneDrive for files, with some intrusions reaching Exchange Online email.
- Microsoft also saw passkey-themed messages sent over Teams from accounts the attackers had already compromised, so the requests looked like they came from a colleague.
Compiled by The Board RoomSomething wrong?How this is made
Why it matters
- constraint Advice to double-check an odd request over internal chat is spent once the attacker is messaging from a colleague's account, so verification has to run outbound from the employee to a destination the employee chooses.
- exposure When the first contact lands on an unmanaged personal phone, the security team's earliest evidence is a sign-in record, not an endpoint alert.
- decision Device-code and authentication-transfer flows are now a setting someone has to own by name, because leaving them enabled for convenience is a documented route in.
- contradiction AttackIQ's Baker holds that real passkeys would have blocked this, which argues for finishing the rollout faster, while the rollout itself is what makes an enrollment demand plausible to staff.
An enrollment prompt is the one moment in an identity program when an employee is expected to do what security training otherwise forbids: follow a link, on whatever device is to hand, and register a new authenticator. The campaign Microsoft describes borrows that expectation [1]. "The passkey in this campaign is the lure, not the weakness," said Jon Baker, VP of Threat-Informed Defense at AttackIQ. "The MFA that got bypassed was phishable. Real passkeys would have stopped it." [4]
Microsoft's advice is a tenant-configuration list. It recommended enforcing phishing-resistant MFA through Conditional Access, blocking device-code and authentication-transfer flows where there is no legitimate business need, and correlating unusual sign-ins with new authentication method registrations, Graph reconnaissance and abnormal SharePoint, OneDrive and Exchange activity [11]. A skeptic would say that settles it: close the device-code flow, finish the phishing-resistant rollout, and what is left is a configuration backlog. The limit on that reading is where the first move happens. Microsoft says the initial interaction can leave little endpoint evidence, particularly when the victim opens the phishing link on a personal device that is not managed by Defender for Endpoint [7].
So the interruption has to be procedural, and it has to survive the case Microsoft logged of passkey-themed messages arriving from accounts the attackers already held [8]. That leaves a rule about who initiates. The employee starts the confirmation, using a number or ticket queue they look up themselves, and an inbound request is not sufficient authority to change a credential.
The reason to settle that rule this quarter is what the attackers do with an enrollment step of their own. Once an identity was compromised, Microsoft observed them registering phone numbers, authenticator applications and software-based OTP tokens under their control. That gave them a way to satisfy future MFA challenges without the legitimate user [5]. In some intrusions the credentials and MFA methods in use had apparently been registered days earlier, so persistence was already established before the activity that drew attention [9]. Signs of automation appeared as well, including a python-httpx user agent behind high-volume SharePoint and OneDrive activity [12]. "The actor registers their own authenticator method, maps the tenant through Microsoft Graph, and pulls files and mail at a pace that reads like a busy employee," Baker said. "None of those calls is suspicious on its own. The sequence is." [10]
What to watch
- Whether Microsoft attributes the campaign to a named actor or publishes a count of affected tenants.
- Whether device-code authentication becomes blocked by default instead of an opt-in Conditional Access setting.
- Whether helpdesk and ITSM vendors add an employee-initiated callback step to credential-change workflows.