Microsoft cloud defenders should treat “passkey update” requests with the same skepticism they already apply to password reset emails. New reporting based on Microsoft research describes threat actors combining help-desk impersonation, passkey-themed lures, device-code phishing, and attacker-controlled MFA enrollment to take over cloud identities and harvest business data from Microsoft 365 environments.

The activity matters because it targets controls that many organizations recently adopted to reduce password risk. Passkeys and stronger MFA remain important security upgrades, but attackers are adapting their social engineering around the enrollment and recovery moments that surround those controls. If a user can be convinced to visit a fake setup portal, approve a device-code flow, or add an authentication method controlled by someone else, the organization may lose the account even when traditional password theft is not the only path.

What Microsoft observed

The report describes two separate but related enterprise threat patterns. The first was a large financial fraud campaign that sent more than a million scam emails over a short period in August 2026. Attackers impersonated senior executives and attempted to convince accounts payable staff to initiate ACH transfers for a fake annual ServiceNow subscription. The messages reportedly used fabricated invoices, forged supporting email threads, impersonation domains, and names of real executives to make the request look routine.

The second campaign is more directly relevant to cloud incident response. Since at least May 2026, Microsoft has observed suspicious sign-ins followed by attackers adding their own authentication methods, using Microsoft Graph at high volume, downloading SharePoint and OneDrive content, and collecting mailbox data through APIs. The intrusions appear designed not only to gain access, but to convert that initial access into persistence and data theft.

A typical path begins outside the corporate inbox. Attackers contact employees by phone or message, often on personal numbers, and claim to be from the organization’s IT help desk. The pretext is urgent but plausible: update your passkey, MFA, or single sign-on configuration now to avoid losing access. Victims are then sent to counterfeit Microsoft-style sign-in or enrollment pages, often by SMS, where the attacker can run an adversary-in-the-middle flow or a device-code authentication attack.

Why passkey-themed lures work

Passkeys are still new enough in many workplaces that employees may not have a strong mental model for what a legitimate enrollment process should look like. That uncertainty creates a social engineering opportunity. A message about “passkey activation,” “SSO enrollment,” or “identity verification” can sound like normal IT housekeeping, especially during a real authentication rollout.

The attackers also appear to conduct pre-attack research. Using public information about employees, roles, and organizational structure, they can tailor calls and messages to make the request more convincing. In some cases, compromised accounts may be used to send similar lures through Microsoft Teams, increasing trust because the message appears to come from inside the tenant.

Domains observed in this broader style of activity have used themes such as passkey help desks, secure passkey setup, SSO integration, and account activation. Examples reported include passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, add-passkey[.]com, integratedsso[.]com, oktasession[.]com, syncmykey[.]com, and portalsetuphub[.]com. Defenders should not rely only on these names; the pattern is more important than any single indicator.

The post-compromise objective: persistence and exfiltration

Once inside, the attacker’s priority is often to make the compromise durable. Microsoft described cases where threat actors enrolled an MFA method under their control, such as a phone number, authenticator app, or software-based one-time password token. That step can allow continued access even after the initial phishing interaction ends, particularly if sessions remain valid or credentials are not reset.

From there, the activity may move quickly into reconnaissance and collection. Microsoft Graph can be used to enumerate users, groups, permissions, resources, mailbox content, SharePoint sites, OneDrive files, and other accessible data. Because Graph is a legitimate API used constantly in Microsoft 365 environments, a single request may not look suspicious. The risk emerges from the sequence: unusual sign-in, authentication method changes, broad enumeration, and large-scale downloads across cloud storage and email.

This is why defenders should correlate identity, device, application, and data access signals rather than reviewing each event in isolation. A login from an unmanaged device, followed by a newly registered MFA factor and a spike in file downloads, should be treated as a high-priority incident even if each individual action uses a valid account.

Practical defenses for Microsoft 365 tenants

Organizations should start by tightening authentication method registration. Require strong reauthentication for adding or changing MFA methods, restrict registration to trusted locations or managed devices where practical, and alert on any new phone, authenticator, passkey, or OTP method added to an account. High-value users and finance staff deserve especially close monitoring because both campaigns show a focus on business process abuse.

Device-code authentication should also be reviewed. If the organization does not need device-code flow broadly, consider limiting or blocking it. Where it is required, monitor for unusual device-code activity, new applications, and sign-ins from proxy or anonymizing infrastructure.

For detection, build rules that connect the full timeline: personal-device or unfamiliar-location sign-in, MFA method registration, consent or token anomalies, Microsoft Graph enumeration, mailbox access, and high-volume SharePoint or OneDrive downloads. Investigations should include session revocation, password reset where applicable, removal of attacker-added authentication methods, review of mailbox rules and OAuth grants, and a search for downstream data access.

User education should be specific. Tell employees that the help desk will never ask them by SMS or phone to visit an unverified passkey setup site, read out device codes, approve unexpected prompts, or add a new MFA method during an unsolicited call. Provide a simple internal channel for verifying identity-related requests before users act.

Bottom line

Passkeys reduce many password-based risks, but they do not eliminate social engineering. Attackers are moving toward the enrollment, recovery, and support workflows around modern identity systems. Security teams should harden those workflows now, monitor for MFA persistence, and treat abnormal Microsoft Graph activity as a tenant-wide signal rather than a low-level API detail.

Source: The Hacker News source