Cybercriminals linked to several prominent data-extortion operations are exploiting confusion surrounding passkeys and single sign-on systems to compromise enterprise Microsoft accounts, establish persistent access and systematically steal sensitive information from cloud services.
The attacks do not appear to defeat the cryptographic protections built into passkeys. Instead, criminals use passkey registration, multifactor authentication updates and security migrations as convincing social-engineering pretexts. Victims are manipulated into completing authentication actions that ultimately provide the attackers with valid Microsoft cloud sessions.
According to an investigation published byMicrosoft Security Research, the activity has been observed since May 2026. Microsoft identified a recurring sequence involving suspicious sign-ins, the registration of attacker-controlled authentication methods, automated Microsoft Graph reconnaissance and sustained collection of files and emails from Microsoft 365 environments.
The campaign demonstrates how attackers are adapting to the wider corporate adoption of passwordless authentication. Rather than necessarily attacking passkey technology itself, criminals are changing the story presented to employees.
Attackers Impersonate Corporate IT Support Teams
The intrusions frequently begin with extensive research into a targeted organisation and its employees. Attackers appear to collect names, job titles, telephone numbers, reporting structures and information about the company’s technology from public websites, social networks and professional profiling platforms.
An employee may then receive a telephone call, text message or Microsoft Teams communication from someone claiming to represent the organisation’s IT department or help desk.
The supposed technician warns that the employee must urgently register or synchronise a passkey, update an MFA method or complete a single sign-on migration. Victims may be told that failing to comply will result in their accounts being suspended or their access to corporate applications being interrupted.
Microsoft’s analysisfound that malicious links were sometimes delivered directly to employees’ personal mobile phones. This technique can help attackers bypass corporate email filtering, link scanning and endpoint-security controls deployed on managed business devices.
If the phishing page is opened on a personal phone that is not enrolled in the organisation’s endpoint-management or security platform, investigators may have little or no endpoint telemetry showing what occurred. In some cases, the employee’s recollection of a telephone call or text message may become the earliest evidence explaining how the compromise started.
Attackers have also used previously compromised employee accounts to distribute passkey-themed messages through Microsoft Teams. A request that appears to originate from a known colleague or internal account can be considerably more convincing than an unsolicited external message.
Microsoft observed criminals rapidly establishing phishing infrastructure around themes including passkey registration, SSO enrolment, account activation, identity verification and security-key synchronisation.
- passkeyhelpdesk[.]com
- secure-passkey[.]com
- setupmypasskey[.]com
- integratedsso[.]com
- oktasession[.]com
- syncmykey[.]com
Attackers can place a targeted company’s name at the beginning of an address, creating a domain such as company-name.secure-passkey[.]com. This may look like an organisation-specific authentication portal, even though the criminal controls the underlying secure-passkey[.]com domain.
The infrastructure can become operational within hours of registration and can be quickly replaced when defenders block it. Microsoft cautioned that registration through a particular provider does not, by itself, indicate that the registrar knowingly participated in the malicious activity.
Passkeys Are the Lure, Not the Vulnerability
Although the attacks are presented to victims as passkey updates, the available evidence does not indicate that criminals have broken WebAuthn cryptography or extracted the private keys underlying legitimate passkeys.
Passkeys are designed to resist conventional phishing because authentication is cryptographically bound to the legitimate website’s domain. A passkey registered for a genuine Microsoft service should not directly authenticate a user to an unrelated phishing site.
This origin-binding property is one of the principal reasons passkeys and FIDO2 security keys are stronger than passwords, SMS codes and manually entered one-time passcodes. The private key remains on the user’s device and is not transmitted to the website during authentication.
The attackers work around these protections by directing victims into a different authentication process. Microsoft identified adversary-in-the-middle phishing and device-code authentication as two of the principal techniques employed in the campaign.
In an adversary-in-the-middle, or AiTM, attack, a malicious server positions itself between the user and the legitimate authentication service. The fraudulent portal relays information to the real provider while capturing the victim’s credentials and, where weaker authentication factors are used, a valid session token.
If the victim uses an app-generated code, SMS code or push approval, the attacker may relay the authentication in real time. A stolen session token can subsequently allow the criminal to operate as the authenticated employee without repeatedly supplying the password or completing another MFA challenge.
The second technique abuses Microsoft’s legitimate OAuth device-code flow. This process is intended for devices or applications where directly entering credentials may be difficult.
During a malicious device-code operation, the attacker initiates an authentication request from a client under their control. The victim receives a code and is instructed to enter it into Microsoft’s real authentication page. Because the site itself is legitimate, its web address and certificate will appear correct.
However, entering the code authorises the attacker’s client rather than registering a passkey for the employee. Once the victim completes authentication, an access token is issued to the attacker-controlled session.
Microsoft documented one sequence in which a passkey lure led to device-code phishing, after which the attacker replayed the resulting token and proceeded with account enumeration. The full technical account of this activity is available inMicrosoft’s threat-research report.
This distinction is critical. Blocking lookalike domains alone will not stop every version of the attack because device-code phishing can direct the victim to an authentic Microsoft page. Organisations must also examine the context of authentication requests and determine whether device-code functionality is genuinely required.
The incidents are therefore more accurately described as passkey-themed phishing. The criminals exploit the language, urgency and unfamiliarity surrounding a security migration to manipulate users into approving access through another authentication channel.
One Successful Authentication Opens the Cloud Environment
Once an attacker obtains a valid session, the operation can rapidly progress from initial account access to extensive cloud reconnaissance.
In one case examined by Microsoft, suspicious activity began with a sign-in from an unmanaged device to a Microsoft 365 service recorded in Entra ID logs as OfficeHome. After MFA was completed, the attacker obtained a valid session and began examining applications and resources assigned to the compromised account.
Within minutes, the session accessed My Apps, My Profile, Microsoft Approval Management, account-management services and My Sign-Ins. The attacker subsequently reached SharePoint Online, Outlook on the web, Microsoft 365 collaboration and search services, an internal business application and authentication processes associated with virtual desktops.
The session remained active for approximately one hour while the intruder mapped available applications and searched for potentially sensitive information.
A compromised cloud identity can expose far more than an employee’s inbox. Where Microsoft Entra ID or another identity provider functions as the organisation’s central SSO platform, the attacker may be able to reach numerous connected services according to the victim’s existing permissions.
These could include Salesforce, Google Workspace, Dropbox, Slack, SAP, Adobe, Zendesk, Atlassian products and internally developed applications. The precise exposure depends on the services assigned to the user, their privileges and whether additional device-trust or conditional-access controls are applied.
This makes identity compromise particularly dangerous in cloud-first organisations. Instead of moving laterally between traditional network endpoints, an attacker can use a trusted identity token to move among approved software-as-a-service platforms.
Criminals Register Their Own Authentication Methods
Following initial access, attackers frequently attempt to convert a temporary session into a persistent foothold by adding an authentication method they control.
Microsoft has observed criminals registering new telephone numbers, authenticator applications and software-generated one-time-password tokens against compromised identities. Once enrolled, these methods may allow the intruder to complete future authentication challenges without assistance from the victim.
In another investigated sequence, an attacker signed in with previously compromised credentials while the MFA requirement was approved through an authenticator method that appeared to have been registered several days earlier. The delay suggests some operators establish persistence and return later to conduct reconnaissance and data theft.
This creates a serious incident-response risk. Resetting the employee’s password may not remove an attacker-enrolled authentication method, while terminating a single browser session may not invalidate every access or refresh token available to the intruder.
Responders must review the identity as a whole, including:
- Registered authentication methods
- Active browser and application sessions
- Refresh and access tokens
- Registered or joined devices
- OAuth grants and application consent
- Mailbox rules and delegated access
- Enterprise-application permissions
- Changes made to the account during the suspected intrusion
Microsoft said an attacker-added MFA method should not survive a complete credential and session reset when the unauthorised method is also removed. An incomplete response, however, may leave the criminal with a route back into the environment.
Microsoft Graph Used to Map the Organisation
Once persistent access has been established, the attackers use Microsoft Graph and related cloud interfaces to inventory the compromised environment.
Microsoft Graph is a legitimate API that allows applications to interact with Microsoft 365 and Entra ID data. Depending on the compromised identity’s permissions, it can expose information relating to employees, groups, applications, files, messages and organisational relationships.
According toMicrosoft’s investigation, the attackers used Graph requests to examine:
- Tenant information, licences and enabled services
- Employees, groups and group membership
- Directory roles and privileged identities
- Registered authentication methods
- Applications and service principals
- OAuth permissions and application-role assignments
- SharePoint sites and document libraries
- OneDrive folders and files
- Mail folders, messages and attachments
Requests to endpoints such as /users, /groups or /sites are not inherently malicious. Approved corporate applications commonly generate similar traffic.
The stronger detection opportunity lies in the progression of events. A newly authenticated account connecting from an unmanaged device, registering an authentication method, rapidly enumerating users and privileges and subsequently downloading documents represents a much stronger signal than any single Graph request.
Microsoft found evidence that portions of the activity were automated using Node.js-based tooling. It also observed the python-httpx user agent during some high-volume SharePoint and OneDrive access.
A user-agent string alone is not proof of malicious activity. It becomes relevant when correlated with unusual sign-ins, proxy infrastructure, abnormal request volumes, authentication-method changes and access to cloud workloads unrelated to the employee’s normal duties.
SharePoint, OneDrive and Email Targeted for Theft
After completing reconnaissance, the attackers transition to data collection across SharePoint Online, OneDrive for Business and Exchange Online.
Microsoft observed substantial numbers of FileAccessed and FileDownloaded events consistent with systematic retrieval of corporate documents. Some intrusions also involved access to email through REST APIs, enabling criminals to collect messages and attachments without relying entirely on an interactive web browser.
The attackers did not always conduct a conspicuous, high-speed smash-and-grab operation. Collection sometimes continued for several hours or multiple days, with the criminals generally accessing fewer than 1,000 files or emails during any single hour.
Maintaining a controlled pace may help malicious activity blend into normal business traffic and evade simple volume-based detection rules. Even at that rate, however, attackers can steal substantial quantities of information when a compromised employee has access to shared document repositories or departmental mailboxes.
Related research from theGoogle Threat Intelligence Groupdocumented similar operations involving the threat cluster UNC6671. Google said the group combined voice phishing with victim-branded credential-harvesting sites to compromise SSO accounts and intercept MFA.
After obtaining access, UNC6671 used compromised identities to reach Microsoft 365, Okta and connected SaaS environments. Researchers observed searches for terms including “confidential” and “SSN,” indicating an attempt to locate information capable of creating regulatory, financial or reputational pressure.
Google also observed Python and PowerShell tools being used to extract information programmatically from SharePoint and OneDrive before victims received extortion demands.
Crucially,Google’s investigationconcluded that the incidents did not result from vulnerabilities in Microsoft 365, Okta or the connected SaaS products. The initial access was obtained through identity-focused social engineering.
Activity Connected to a Wider Extortion Ecosystem
Microsoft attributed elements of the initial-access activity to several actors operating within a fluid data-extortion ecosystem, including groups tracked as Storm-3121 and Storm-3032.
According toMicrosoft Security Research, Storm-3121 conducts initial-access activity that can lead to extortion under the ShinyHunters and Falcon brands. Storm-3032 represents actors associated with BlackFile who later operated under the Helix banner.
Google tracks overlapping activity as UNC6671. Its research links operators in this ecosystem with brands including BlackFile, Helix, Falcon, Pink and Redact.
Attribution within this criminal environment requires caution. Extortion groups frequently rebrand, divide into smaller crews, cooperate with initial-access brokers, reuse infrastructure or adopt established names to make their threats appear more credible.
The recurring objective is data theft followed by pressure to pay, rather than the deployment of conventional file-encrypting ransomware. This does not necessarily reduce the impact.
The theft of personal information, contracts, financial documents, intellectual property and internal communications can result in regulatory investigations, legal claims, operational disruption and lasting reputational harm.
Why Organisations Should Continue Adopting Passkeys
The campaign could create the misleading impression that passkeys no longer provide meaningful protection. The evidence supports a different conclusion.
Passkeys can prevent many conventional credential-phishing attacks because the user does not enter a reusable secret into a website and the private key is not disclosed during authentication. The credential is also bound to the legitimate service’s origin.
However, organisations cannot treat passkey deployment as a complete defence against identity compromise.
Attackers may direct victims toward fallback authentication methods, abuse legitimate device-authorisation processes, steal existing sessions, compromise already authenticated endpoints or persuade help-desk employees to reset security controls. They can also exploit inconsistent policies where some applications require phishing-resistant authentication while others continue accepting weaker methods.
Defenders must therefore secure the entire authentication lifecycle, including enrolment, account recovery, help-desk verification, device trust, token issuance, legacy authentication and access to connected SaaS applications.
If an attacker can persuade an employee to authorise a malicious device or convince support personnel to enrol another authentication factor, the presence of a passkey elsewhere in the process may not prevent compromise.
Recommended Defensive Measures
Microsoft recommends investigating identity and cloud-workload events as a connected sequence rather than reviewing each service in isolation.
Security teams should prioritise cases in which an unusual sign-in is followed by registration of a new MFA method, Microsoft Graph enumeration, suspicious token activity and abnormal access to SharePoint, OneDrive or Exchange Online.
Organisations should restrict security-information registration through Conditional Access. Requiring a fresh interactive authentication, a managed and compliant device and phishing-resistant MFA can reduce the likelihood of an attacker adding a persistent authentication method.
Device-code and authentication-transfer flows should be blocked where there is no documented business requirement. Where these capabilities must remain available, organisations should restrict them to approved users, applications and device conditions while closely monitoring their use.
Access from unmanaged devices can be limited to browser-only sessions, with file downloading and synchronisation disabled. Anonymous and external sharing settings in SharePoint and OneDrive should also be reviewed.
Microsoft Graph activity logs, mailbox auditing and Entra ID sign-in records should be enabled and retained for long enough to support investigations. Defenders can then alert on suspicious combinations such as:
- A risky sign-in followed by an authentication-method change
- Device-code authentication involving an unexpected application
- Rapid enumeration of users, groups and directory roles
- Searches across multiple SharePoint or OneDrive repositories
- Sustained access to files, messages and attachments
- Automated activity from proxy infrastructure or unfamiliar user agents
User consent for third-party applications should be restricted, with high-risk permission requests requiring administrator approval. Service principals and enterprise applications holding powerful Graph permissions, including Mail.Read, Files.Read.All and Directory.Read.All, should be regularly reviewed.
Help-desk procedures require similar protection. Staff should not approve authentication resets or enrolment changes using information an attacker could obtain from social media, a compromised database or an internal employee directory.
High-risk changes should require strong identity verification and generate immediate notifications to both the affected employee and the security team.
Employees should also be taught that legitimate IT personnel should not unexpectedly contact them and demand immediate passkey, MFA or SSO action through an unfamiliar link. Organisations need a simple and trusted channel through which workers can independently verify support requests.
Microsoft has published detailed investigation, containment and hunting recommendations—including Microsoft Defender queries—in itstechnical report on the campaign.
Incident Response Requires More Than a Password Reset
Where compromise is suspected, administrators should immediately revoke active sessions and refresh tokens, reset affected credentials and inspect every authentication method associated with the account.
Any unrecognised telephone number, authenticator registration, passkey, software token or device should be removed after verification with the legitimate user.
Responders should also examine OAuth approvals, enterprise-application access, inbox forwarding rules, mailbox delegates, application passwords, registered devices and service-principal permissions.
The affected employee’s access to SharePoint, OneDrive, Exchange and third-party SSO applications must be reviewed to establish the possible scope of the breach.
Cloud logs should be examined for unusual Graph requests, role enumeration, large-scale or sustained file access, email collection and connections from proxy infrastructure. Investigators should not rely exclusively on obvious download spikes because the criminals may intentionally spread collection across several hours or days.
If sensitive information was accessed, the organisation should involve its legal, privacy and executive-response teams to assess regulatory, contractual and notification obligations.
The wider lesson is that enterprise authentication now represents an attack surface extending far beyond the login page. Passkeys can remove one of the most phishable secrets—the password—but attackers are increasingly targeting enrolment workflows, fallback mechanisms, user trust, access tokens and the cloud applications behind a successful sign-in.
As passwordless authentication becomes more common, organisations must ensure that every surrounding identity process is at least as secure as the passkey itself.
