ShinyHunters Passkey Phishing Campaign Targets Microsoft 365: Detection and Defense Guide for SSO Social Engineering Attacks

Microsoft has confirmed that threat actors affiliated with ShinyHunters, Helix, and other extortion-focused criminal groups are running a coordinated wave of social engineering attacks themed around passkeys and single sign-on (SSO) to compromise corporate Microsoft accounts and exfiltrate data from Microsoft 365 services. This is not a vulnerability in Microsoft's platform — it is the industrialization of identity theft against the very mechanisms organizations adopted to become "phishing-resistant."

The irony is deliberate and dangerous. Enterprises spent the last two years rolling out passkeys and FIDO2 authentication specifically to defeat credential phishing. Attackers have adapted faster than many security programs anticipated: instead of stealing passwords, they now trick users into registering attacker-controlled passkeys, approving fraudulent SSO enrollments, or surrendering session material through adversary-in-the-middle (AiTM) flows dressed up as legitimate passkey or SSO setup pages. The end result is the same as every identity campaign we've tracked since the token-theft wave of 2023 — unauthorized access to Exchange Online, SharePoint, OneDrive, and Teams, followed by bulk data theft and extortion.

If your organization uses Microsoft 365 with Entra ID (formerly Azure AD), this campaign applies to you. The sections below break down the attack chain and give you concrete detection logic and hardening steps you can deploy this week.

Technical Analysis

Threat Actors and Campaign Context

Microsoft attributes this activity to clusters associated with ShinyHunters and Helix, both known for data-theft-and-extortion operations, along with other extortion gangs. These groups have a well-documented playbook: gain access to cloud SaaS environments, steal sensitive data at scale, and extort victim organizations with threats of public leaks. ShinyHunters in particular has a long history of monetizing stolen corporate datasets, and its recent evolution toward voice phishing (vishing) and SSO-themed lures against enterprise tenants marks a shift from exploiting misconfigurations to exploiting people and identity workflows.

No CVE is associated with this campaign. There is nothing to patch — the attack surface is the identity lifecycle itself: authentication method registration, SSO enrollment, and session establishment.

Attack Chain: How Passkey-Themed Social Engineering Works

From the defender's perspective, the campaign follows a consistent pattern:

1. Initial lure. Targets receive phishing emails, Teams messages, or vishing calls themed around a mandatory passkey rollout, SSO migration, or "security upgrade." The lures impersonate internal IT or Microsoft, and they are effective precisely because real IT departments are actively deploying passkeys right now — the pretext matches reality.

2. Credential and session capture. The victim is directed to an attacker-controlled page that proxies the genuine Microsoft login flow (AiTM phishing) or a fake SSO/passkey enrollment portal. The victim authenticates — including completing MFA — and the attacker captures the resulting session token, or harvests credentials for direct replay against legacy authentication endpoints.

3. Persistence via authentication method registration. This is the stage that makes the campaign "passkey-themed" rather than generic phishing. With a valid session, the attacker navigates to the victim's security info registration (aka.ms/mysecurityinfo or the Entra ID authentication methods blade) and registers a new passkey, FIDO2 security key, or authenticator app under attacker control. From this point forward, the attacker no longer needs the stolen session — they possess a durable, phishing-resistant credential on the victim's account that survives password resets.

4. Access and data theft. The attacker authenticates to Exchange Online, SharePoint Online, OneDrive, and Teams from attacker-controlled infrastructure (frequently commercial VPNs, bulletproof hosting, or residential proxies), then performs bulk access and download of mailboxes and document libraries. Data is staged for extortion.

5. Extortion. Victim organizations receive ransom demands with proof-of-theft samples, consistent with ShinyHunters' known extortion model.

Exploitation Status

This is confirmed active, in-the-wild exploitation reported by Microsoft. This is not theoretical tradecraft. The technique set maps to MITRE ATT&CK as follows: T1566 (Phishing), T1078 (Valid Accounts), T1557 (Adversary-in-the-Middle), T1556.006 (Multi-Factor Authentication modification), T1098.001 (Account Manipulation: Additional Cloud Credentials), and T1530 (Data from Cloud Storage).

Why Traditional MFA Catches Don't Fire

The critical lesson here: an attacker-registered passkey is indistinguishable from a legitimate one at authentication time. Entra ID sees a valid FIDO2 assertion and lets the session in. Conditional Access policies that require "phishing-resistant MFA" are satisfied by the attacker's own key. The only reliable place to catch this campaign is at registration time (the addition of the new authentication method) and at anomalous session establishment (impossible travel, unfamiliar ASN, token replay from divergent infrastructure). That is where the detection content below is focused.

Detection & Response

Sigma Rules

The following rules target the two highest-fidelity observables in this campaign: authentication method changes originating from anomalous contexts, and endpoint behavior consistent with AiTM phishing kit interaction. Note that cloud-side registration events are best hunted in Sentinel (see KQL below); these Sigma rules cover endpoint and log-forwarded telemetry.

---
title: Browser Access to Authentication Method Registration Portal from Non-Standard Path
title_note: Detects proxy indicators of user navigation to security info registration shortly after suspicious navigation
id: 3f8a2c91-7d4e-4b5a-9c1d-2e6f8a0b3d5e
status: experimental
description: Detects process execution where a browser is launched directly to the Microsoft security info registration page, which is atypical outside of IT-driven enrollment campaigns and may indicate attacker-guided passkey registration during a social engineering session.
references:
  - https://www.bleepingcomputer.com/news/security/passkey-themed-phishing-attacks-lead-to-microsoft-365-data-theft/
  - https://attack.mitre.org/techniques/T1098/001/
author: Security Arsenal
date: 2026/02/15
tags:
  - attack.persistence
  - attack.t1098.001
  - attack.t1566
logsource:
  category: process_creation
  product: windows
detection:
  selection_browser:
    Image|endswith:
      - '\msedge.exe'
      - '\chrome.exe'
      - '\firefox.exe'
  selection_url:
    CommandLine|contains:
      - 'mysignins.microsoft.com/security-info'
      - 'aka.ms/mysecurityinfo'
      - 'account.activedirectory.windowsazure.com'
  condition: all of selection_*
falsepositives:
  - Legitimate IT-directed MFA or passkey enrollment during onboarding
  - Helpdesk-guided security info updates
level: medium
---
title: Credential Harvesting Phishing Page Indicators in Browser Command Line
id: 9b1e4d72-6a3c-4f8b-8e2a-5c7d9f1a4b6e
status: experimental
description: Detects browsers launched with URLs containing common AiTM phishing kit patterns impersonating Microsoft login or passkey enrollment flows, including login.microsoftonline lookalike paths on non-Microsoft domains.
references:
  - https://www.bleepingcomputer.com/news/security/passkey-themed-phishing-attacks-lead-to-microsoft-365-data-theft/
  - https://attack.mitre.org/techniques/T1557/
author: Security Arsenal
date: 2026/02/15
tags:
  - attack.credential_access
  - attack.t1557
  - attack.t1566.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_browser:
    Image|endswith:
      - '\msedge.exe'
      - '\chrome.exe'
  selection_patterns:
    CommandLine|contains:
      - '/common/oauth2'
      - 'login.microsoftonline'
      - 'passkey'
      - 'fido2'
  filter_legitimate:
    CommandLine|contains:
      - 'https://login.microsoftonline.com'
      - 'https://login.microsoft.com'
      - 'https://mysignins.microsoft.com'
  condition: all of selection_* and not filter_legitimate
falsepositives:
  - Rare; legitimate Microsoft auth flows occur on Microsoft-owned domains
level: high

KQL — Microsoft Sentinel / Defender

These queries target the identity-plane events that matter most: new authentication method registration, registration from anomalous network locations, and sign-ins immediately following method changes. The first query is the one I would deploy to production today — passkey/FIDO2 registration is a low-frequency, high-signal event in most tenants.

// Hunt 1: New passkey / FIDO2 / MFA method registrations in Entra ID
// High-fidelity: attacker persistence registration post-phish
AuditLogs
| where TimeGenerated > ago(14d)
| where OperationName has_any (
    "User registered security info",
    "User registered all required security info",
    "Register passkey",
    "Add passkey",
    "User started registration of FIDO2",
    "Admin registered security info"
  )
| extend UserPrincipal = tostring(TargetResources[0].userPrincipalName)
| extend InitiatedBy = tostring(parse_json(tostring(InitiatedBy.user)).userPrincipalName)
| extend IpAddress = tostring(parse_json(tostring(InitiatedBy.user)).ipAddress)
| extend Detail = tostring(AdditionalDetails)
| project TimeGenerated, OperationName, UserPrincipal, InitiatedBy, IpAddress, Result, Detail, CorrelationId
| order by TimeGenerated desc
;

// Hunt 2: Authentication method registration followed by sign-in from NEW ASN/location within 1 hour
// Correlates the registration event with the attacker's first use of their new credential
let RegistrationWindow = 1h;
let Registrations = AuditLogs
| where TimeGenerated > ago(14d)
| where OperationName has "registered security info"
| extend UserPrincipal = tostring(TargetResources[0].userPrincipalName)
| extend RegIP = tostring(parse_json(tostring(InitiatedBy.user)).ipAddress)
| project RegTime=TimeGenerated, UserPrincipal, RegIP, OperationName;
let Signins = SigninLogs
| where TimeGenerated > ago(14d)
| where ResultType == 0
| extend AuthDetail = tostring(parse_json(tostring(AuthenticationDetails)))
| project SigninTime=TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, AuthDetail;
Registrations
| join kind=inner Signins on $left.UserPrincipal == $right.UserPrincipalName
| where SigninTime between (RegTime .. RegTime + RegistrationWindow)
| where IPAddress != RegIP
| project RegTime, UserPrincipal, RegIP, SigninTime, IPAddress, Location, AppDisplayName, OperationName
| order by RegTime desc
;

// Hunt 3: SharePoint/OneDrive bulk download behavior post-signin (data theft staging)
// Tune thresholds to your tenant baseline
AuditLog
| where TimeGenerated > ago(7d)
| where Operation in ("FileDownloaded", "FileSyncDownloadedFull", "FileAccessed")
| summarize FileOps = count(), DistinctFiles = dcount(OfficeObjectId), UniqueIPs = dcount(ClientIP)
    by UserId, bin(TimeGenerated, 1h)
| where FileOps > 200 or DistinctFiles > 100
| order by FileOps desc

Velociraptor VQL

On the endpoint side, the most useful artifact during IR scoping is browser history: confirming whether a victim navigated to an AiTM phishing page or a fake passkey enrollment portal, and when. This artifact parses Chrome and Edge history for Microsoft-login-themed URLs hosted off Microsoft domains.

-- Hunt browser history for Microsoft login / passkey themed phishing URLs
-- Flags auth-flow paths and passkey lures hosted on non-Microsoft domains
LET HistoryGlob = {
    SELECT FullPath FROM glob(globs=[[
        'C:/Users/*/AppData/Local/Google/Chrome/User Data/*/History',
        'C:/Users/*/AppData/Local/Microsoft/Edge/User Data/*/History'
    ]])
};

SELECT FullPath AS HistoryDB,
       url.url AS URL,
       timestamp(epoch=url.visit_time / 1000000 - 11644473600) AS VisitTime,
       url.title AS PageTitle
FROM foreach(
    row=HistoryGlob,
    query={
        SELECT url FROM sqlite(
            file=FullPath,
            query="SELECT urls.url AS url, urls.title AS title, visits.visit_time AS visit_time FROM urls JOIN visits ON urls.id = visits.url"
        )
    })
WHERE (
        URL =~ '(?i)(passkey|fido|sso[-_]?(setup|enroll|migrat)|security[-_]?info|/common/oauth2)'
        AND NOT URL =~ '(?i)https://[^/]*\\.microsoft(online)?\\.com'
        AND NOT URL =~ '(?i)https://[^/]*\\.live\\.com'
      )
ORDER BY VisitTime DESC

Remediation & Audit Script

Use this PowerShell script (requires the Microsoft Graph PowerShell SDK with UserAuthenticationMethod.Read.All and AuditLog.Read.All scopes) to audit your tenant for recently registered passkeys and authentication methods — the persistence mechanism this campaign depends on. Run it as an urgent one-time sweep, then operationalize it as a scheduled job feeding your SIEM.

# Connect with read-only audit scopes
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","AuditLog.Read.All","User.Read.All" -NoWelcome

# Sweep 1: Enumerate passkey (FIDO2) registrations across the tenant in the last 14 days
$cutoff = (Get-Date).AddDays(-14)
$users = Get-MgUser -All -Property "Id,UserPrincipalName"
$findings = foreach ($u in $users) {
    try {
        $methods = Get-MgUserAuthenticationFido2Method -UserId $u.Id -ErrorAction SilentlyContinue
        foreach ($m in $methods) {
            if ($m.CreatedDateTime -and [datetime]$m.CreatedDateTime -gt $cutoff) {
                [PSCustomObject]@{
                    UserPrincipalName = $u.UserPrincipalName
                    MethodType        = 'FIDO2/Passkey'
                    CreatedDateTime   = $m.CreatedDateTime
                    DisplayName       = $m.DisplayName
                    AaGuid            = $m.AaGuid
                }
            }
        }
    } catch {}
}
$findings | Export-Csv -Path ".\RecentPasskeyRegistrations.csv" -NoTypeInformation
$findings | Format-Table -AutoSize

# Sweep 2: Pull Entra ID audit log for all security-info registration events (last 14 days)
$filterDate = $cutoff.ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
$auditEvents = Get-MgAuditLogDirectoryAudit -All `
    -Filter "activityDateTime gt $filterDate" |
    Where-Object { $_.ActivityDisplayName -match 'registered security info|passkey|FIDO2' }
$auditEvents | Select-Object ActivityDateTime, ActivityDisplayName,
    @{n='InitiatedBy';e={$_.InitiatedBy.User.UserPrincipalName}},
    @{n='TargetUser';e={$_.TargetResources[0].UserPrincipalName}},
    Result |
    Export-Csv -Path ".\SecurityInfoRegistrationAudit.csv" -NoTypeInformation

# Sweep 3: Flag users with MORE THAN ONE passkey (common attacker artifact — their key plus victim's)
$multi = foreach ($u in $users) {
    try {
        $m = Get-MgUserAuthenticationFido2Method -UserId $u.Id -ErrorAction SilentlyContinue
        if (($m | Measure-Object).Count -gt 1) { $u.UserPrincipalName }
    } catch {}
}
Write-Host "Users with multiple registered passkeys (investigate):" -ForegroundColor Yellow
$multi

Remediation

There is no patch to deploy — remediation here is identity architecture and process control. Prioritize in this order:

1. Gate authentication method registration with Conditional Access. Require the "Register security information" user action to be protected by a Conditional Access policy: compliant device, trusted location, and/or a Temporary Access Pass (TAP). This is the single highest-impact control against this campaign — it means a phished session token alone cannot register an attacker passkey. Microsoft's guidance on securing MFA and passkey registration is in the Entra ID documentation under "Combined security information registration."

2. Enforce phishing-resistant MFA broadly — and understand its limit. Passkeys and FIDO2 keys still defeat AiTM relay at authentication time. The gap this campaign exploits is registration. Keep enforcing FIDO2, but treat every registration event as a privileged action requiring out-of-band verification (manager/helpdesk callback on a known number, never a number supplied by the requester).

3. Audit passkey and MFA registrations tenant-wide today. Run the script above. Investigate any FIDO2 registration that was not tied to a documented IT enrollment activity, any user with an unexpected second passkey, and any registration originating from a non-corporate IP or unusual geography. If you find an unauthorized method, treat it as a confirmed compromise: revoke all sessions (Revoke-MgUserSignInSession), remove the rogue method, reset credentials, and scope mailbox/SharePoint access via unified audit log.

4. Enable and alert on the KQL detections above. The registration-to-sign-in correlation query (Hunt 2) catches the attacker using their newly registered credential from different infrastructure. Wire Hunt 1 into an analytic rule with a severity of High — passkey registration is rare enough in most tenants that every event deserves a human look.

5. Disrupt the lure channel. Train users — explicitly and with this campaign as the example — that IT will never direct them to a passkey or SSO enrollment page via an unsolicited email, Teams message, or phone call. Vishing is a primary delivery vector for these groups; establish a verification phrase or ticket-number requirement for any IT-initiated authentication change.

6. Constrain data egress from M365. Conditional Access session controls, SharePoint/OneDrive download restrictions for unmanaged devices, and alerting on bulk-download patterns (Hunt 3) limit blast radius when an account is compromised despite everything above.

7. Prepare for the extortion phase. These groups monetize through data-leak extortion. Know now — before an incident — what your legal counsel, cyber insurance carrier, and communications plan say about extortion demands, and ensure your unified audit log retention is sufficient to prove or disprove claimed data theft.

If you discover unauthorized authentication methods or anomalous sign-ins during your sweep, treat it as an incident, not a hygiene issue: preserve audit logs, isolate the account, and engage your IR retainer. The window between registration and bulk exfiltration in these campaigns is often measured in hours.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub