Passkey Phishing Attacks on Microsoft Entra ID: Detection and Hardening Guide for Cloud Account Takeover

Microsoft has disclosed two active campaigns that should be on every cloud defender's radar right now. The first is a high-volume financial fraud operation: between August 3 and 5, 2026, threat actors abused third-party email delivery infrastructure to blast over a million scam emails impersonating chief executive officers — a classic business email compromise (BEC) pattern executed at industrial scale through legitimate sending services. The second campaign is more technically dangerous: attackers are using passkey-themed social engineering to compromise Microsoft cloud accounts and exfiltrate data from victim tenants.

The passkey angle matters. Organizations have spent the last two years rolling out FIDO2 passkeys specifically because they are phishing-resistant — the credential is cryptographically bound to the legitimate origin and cannot be replayed on a fake site. Attackers have responded not by breaking the cryptography, but by attacking the enrollment and recovery workflows around it. If an attacker can socially engineer a user (or a help desk) into registering an attacker-controlled passkey, or trick a user through a cross-device authentication flow, the phishing resistance of the passkey itself is irrelevant. The attacker walks in with a valid, strong credential.

No CVE is associated with these campaigns — this is identity abuse, not a software flaw. That makes detection and configuration hardening, not patching, the entire defensive game. This post breaks down the attack chain and gives you concrete detection rules and remediation steps you can deploy today.

Technical Analysis

Campaign 1: BEC at Scale via Third-Party Email Infrastructure

The first campaign sent over one million scam emails in a three-day window (August 3–5, 2026) masquerading as CEOs. The defining characteristic is the abuse of legitimate third-party email delivery services — bulk sending platforms that carry good sender reputation, valid SPF/DKIM/DMARC alignment, and high inbox placement rates. This defeats reputation-based filtering and makes the messages look clean to gateways that trust authenticated senders.

Defensive implication: authentication success is not intent verification. A message that passes DMARC can still be a CEO fraud lure. Detection must shift to content signals (payment urgency, bank detail changes, gift card requests), sender-recipient relationship anomalies (first-time sender to finance staff, executive display-name spoofing with mismatched domains), and behavioral analytics on outbound replies and payment workflow changes.

Campaign 2: Passkey-Themed Social Engineering for Account Takeover

The second campaign uses lures themed around passkeys — messages or prompts styled as passkey enrollment, passkey upgrade, or security verification flows. The realistic attack chains defenders should model:

Credential/session theft via adversary-in-the-middle (AiTM) phishing leading to follow-on passkey registration. The attacker steals a session or primary credential through a phishing page, then — critically — registers a new authentication method (their own passkey or phone) on the victim account via Entra ID's security info registration. This gives them durable, MFA-satisfying persistence that survives password resets.
Cross-device passkey abuse. Cross-device (hybrid) WebAuthn flows let a passkey on one device authenticate a session on another via a QR code and Bluetooth proximity check. Social engineering a user into scanning an attacker-presented QR code and approving the flow on their phone can authenticate the attacker's session. Proximity requirements limit this but do not eliminate it, and users conditioned to 'just approve' prompts are the weak link.
Help-desk social engineering. Attackers impersonate locked-out users to convince help desk staff to issue a Temporary Access Pass (TAP) or reset authentication methods, then enroll an attacker-controlled passkey during the TAP window.

Persistence and Exfiltration

Post-compromise, the objectives are data exfiltration from the Microsoft 365 environment — typically SharePoint/OneDrive bulk downloads, mailbox access (sometimes with new inbox rules to hide security alerts or forward mail), and potentially OAuth consent grants for persistent API access. The exfiltration typically runs through legitimate Microsoft service endpoints, so network-layer detection has limited value; the signal lives in Entra ID audit logs, Unified Audit Log (UAL), and Microsoft Graph activity.

Exploitation Status

Both campaigns are confirmed active in the wild, per Microsoft's disclosure. There is no CISA KEV entry (no CVE exists), and no public PoC is required — these are social engineering and identity-abuse techniques. Treat as an ongoing, present-tense threat against any Entra ID tenant, especially those mid-migration to passkeys where users expect enrollment-related communications.

Detection & Response

The highest-fidelity signals for this threat class live in Entra ID sign-in and audit telemetry:

Authentication method registration events (User registered security info) immediately following an anomalous sign-in — especially FIDO2/passkey registration from an unfamiliar device, ASN, or geography.
TAP creation and use events, correlated against actual help desk ticket activity.
Inbox rule creation (New-InboxRule, Set-InboxRule operations in UAL) with delete/move/forward actions after a suspicious sign-in.
Bulk file download/sync activity in SharePoint and OneDrive from anomalous sessions.

SIGMA Rules

YAML

---
title: Suspicious Authentication Method Registration After Anomalous Sign-In
id: 3f8a2c91-7b4e-4d1a-9c52-8e6f1a3b5d07
status: experimental
description: Detects registration of new security info (e.g., passkey/FIDO2, phone) in Entra ID, which may indicate an attacker adding persistence to a compromised account after passkey-themed social engineering. Correlate with sign-in risk and device familiarity before escalating.
references:
  - https://thehackernews.com/2026/09/attackers-use-passkey-phishing-to.html
  - https://attack.mitre.org/techniques/T1098/001/
  - https://attack.mitre.org/techniques/T1556/
author: Security Arsenal
date: 2026/09/08
tags:
  - attack.persistence
  - attack.t1098.001
  - attack.t1556
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    operationName|contains:
      - 'User registered security info'
      - 'User registered all required security info'
      - 'Admin registered security info'
    targetResources|contains:
      - 'Fido2AuthenticationMethod'
      - 'MicrosoftAuthenticator'
      - 'PhoneAuthenticationMethod'
  condition: selection
falsepositives:
  - Legitimate user self-service MFA/passkey enrollment, especially during onboarding or passwordless rollout campaigns
level: medium
---
title: Temporary Access Pass Creation Outside Help Desk Workflow
id: 9c1d5e72-3a68-4f0b-b214-6d8a9c2e4f15
status: experimental
description: Detects creation of a Temporary Access Pass in Entra ID. TAPs are a known target of help-desk social engineering used to bootstrap attacker-controlled passkey enrollment on victim accounts.
references:
  - https://thehackernews.com/2026/09/attackers-use-passkey-phishing-to.html
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/09/08
tags:
  - attack.persistence
  - attack.initial_access
  - attack.t1078
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    operationName|contains:
      - 'Create Temporary Access Pass'
      - 'Create temporary access pass authentication method'
  condition: selection
falsepositives:
  - Legitimate help desk passwordless onboarding and account recovery - alert on any TAP not backed by a change/incident ticket
level: high
---
title: Malicious Inbox Rule Creation After Cloud Account Compromise
id: 5b7e3f08-2c94-4a6d-8e17-1f4a6c9b3d82
status: experimental
description: Detects Exchange inbox rules created to delete, move, or forward messages - a common post-compromise action to hide security alerts and exfiltrate mail after account takeover via passkey phishing.
references:
  - https://thehackernews.com/2026/09/attackers-use-passkey-phishing-to.html
  - https://attack.mitre.org/techniques/T1114/002/
author: Security Arsenal
date: 2026/09/08
tags:
  - attack.collection
  - attack.defense_evasion
  - attack.t1114.002
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    operationName|contains:
      - 'New-InboxRule'
      - 'Set-InboxRule'
    parameters|contains:
      - 'DeleteMessage'
      - 'ForwardTo'
      - 'ForwardAsAttachmentTo'
      - 'RedirectTo'
  condition: selection
falsepositives:
  - User-created organizational rules - investigate external forwarding targets and rules created within hours of anomalous sign-ins
level: medium

KQL (Microsoft Sentinel / Defender)

This hunt identifies the core persistence behavior: a new authentication method (passkey or phone) registered on an account that showed risky or anomalous sign-in characteristics in the preceding 24 hours. Tune the lookback and join keys to your tenant's naming.

KQL — Microsoft Sentinel / Defender

let Lookback = 7d;
let RiskySignIns =
    SigninLogs
    | where TimeGenerated >= ago(Lookback)
    | where RiskLevelDuringSignIn in~ ('high','medium')
       or (ResultType == 0 and Location !in (SigninLogs
                                                | where TimeGenerated >= ago(30d)
                                                | summarize KnownLocations = make_set(Location) by UserPrincipalName
                                                | project KnownLocations))
    | summarize FirstRiskySignIn = min(TimeGenerated),
                SignInIPs = make_set(IPAddress),
                SignInLocations = make_set(Location),
                SignInApps = make_set(AppDisplayName)
        by UserPrincipalName;
AuditLogs
| where TimeGenerated >= ago(Lookback)
| where OperationName has_any ("User registered security info", "Admin registered security info", "Create temporary access pass")
| extend TargetUser = tostring(TargetResources[0].userPrincipalName)
| extend MethodDetail = tostring(TargetResources[0].modifiedProperties)
| join kind=inner RiskySignIns on $left.TargetUser == $right.UserPrincipalName
| where TimeGenerated between (FirstRiskySignIn .. FirstRiskySignIn + 24h)
| project TimeGenerated, OperationName, TargetUser, MethodDetail,
          InitiatedBy = tostring(parse_json(InitiatedBy).user.userPrincipalName),
          CorrelationId, FirstRiskySignIn, SignInIPs, SignInLocations, SignInApps
| order by TimeGenerated desc

Supplementary hunt for bulk exfiltration from SharePoint/OneDrive following a new-method registration — pivot the same users against the UAL:

KQL — Microsoft Sentinel / Defender

let CompromisedUsers = dynamic(["user1@contoso.com","user2@contoso.com"]); // populate from prior hunt output
OfficeActivity
| where TimeGenerated >= ago(7d)
| where UserId in~ (CompromisedUsers)
| where Operation in~ ("FileDownloaded","FileSyncDownloadedFull","FileAccessed")
| summarize DownloadCount = count(),
            DistinctFiles = dcount(OfficeObjectId),
            SourceIPs = make_set(ClientIP),
            Sites = make_set(SiteUrl)
    by UserId, bin(TimeGenerated, 1h)
| where DownloadCount > 200 or DistinctFiles > 100
| order by DownloadCount desc

Velociraptor VQL

Endpoint forensics has limited visibility into pure cloud identity abuse, but when a suspected AiTM phishing page was opened on a managed endpoint, browser history and WebAuthn-adjacent artifacts help establish the initial access vector and timeline. This artifact hunts Chrome/Edge history for passkey- and login-themed phishing URLs visited in the last 14 days:

VQL — Velociraptor

-- Hunt browser history for passkey/login-themed phishing lures
LET HistoryGlob = {
   SELECT FullPath FROM glob(globs='C:/Users/*/AppData/Local/*/Chrome/User Data/*/History')
   UNION ALL
   SELECT FullPath FROM glob(globs='C:/Users/*/AppData/Local/Microsoft/Edge/User Data/*/History')
};

SELECT FullPath AS HistoryDB,
       copy(filename=FullPath, accessor='file') AS Copied,
       url.URL AS URL,
       url.title AS Title,
       timestamp(epoch=url.last_visit_time / 1000000 - 11644473600) AS VisitTimeUTC
FROM foreach(row=HistoryGlob,
query={
   SELECT FullPath, url FROM sqlite(file=FullPath,
      query="SELECT url, title, last_visit_time FROM urls WHERE url LIKE '%passkey%' OR title LIKE '%passkey%' OR (url LIKE '%login%' AND url NOT LIKE '%microsoftonline.com%' AND url NOT LIKE '%microsoft.com%' AND url NOT LIKE '%live.com%')")
})
WHERE VisitTimeUTC > now() - 1209600
ORDER BY VisitTimeUTC DESC

Note: Velociraptor's SQLite accessor may require copying locked browser databases first — in production, use the Windows.Forensics.Usn or a VSS-backed accessor pattern, or deploy via a scheduled collection while browsers are closed. Treat any non-Microsoft URL matching passkey/login themes as a lead for user interview and sign-in log correlation.

Remediation / Verification Script

This PowerShell (Microsoft Graph SDK) audits a tenant for the exact persistence artifacts this campaign creates: recently registered authentication methods, active TAPs, and risky sign-ins. Run with AuditLog.Read.All, UserAuthenticationMethod.Read.All, and Directory.Read.All scopes.

PowerShell

#Requires -Modules Microsoft.Graph.Identity.SignIns, Microsoft.Graph.Users
# Audit Entra ID for passkey-phishing persistence artifacts
Connect-MgGraph -Scopes "AuditLog.Read.All","UserAuthenticationMethod.Read.All","Directory.Read.All","Policy.Read.All"

$start = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")

# 1. Recent security info registrations (attacker passkey persistence)
Write-Host "`n=== Recent authentication method registrations (last 7 days) ===" -ForegroundColor Cyan
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $start" -All |
  Where-Object { $_.ActivityDisplayName -match 'registered security info|registered all required security info' } |
  Select-Object ActivityDateTime, ActivityDisplayName,
    @{N='InitiatedBy';E={$_.InitiatedBy.user.userPrincipalName}},
    @{N='Target';E={$_.TargetResources[0].userPrincipalName}} |
  Format-Table -AutoSize

# 2. Temporary Access Pass creations (help-desk social engineering vector)
Write-Host "`n=== Temporary Access Pass creations ===" -ForegroundColor Cyan
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $start" -All |
  Where-Object { $_.ActivityDisplayName -match 'Temporary Access Pass' } |
  Select-Object ActivityDateTime, ActivityDisplayName,
    @{N='InitiatedBy';E={$_.InitiatedBy.user.userPrincipalName}},
    @{N='Target';E={$_.TargetResources[0].userPrincipalName}} |
  Format-Table -AutoSize

# 3. Enumerate registered FIDO2/passkey methods per user for review
Write-Host "`n=== Users with FIDO2/passkey methods registered (review for unfamiliar registrations) ===" -ForegroundColor Cyan
Get-MgUser -All -Property Id,UserPrincipalName | ForEach-Object {
  $methods = Get-MgUserAuthenticationFido2Method -UserId $_.Id -ErrorAction SilentlyContinue
  foreach ($m in $methods) {
    [PSCustomObject]@{
      User           = $_.UserPrincipalName
      MethodId       = $m.Id
      CreatedDate    = $m.CreatedDateTime
      DisplayName    = $m.DisplayName
      AaGuid         = $m.AaGuid
    }
  }
} | Sort-Object CreatedDate -Descending | Format-Table -AutoSize

# 4. Risky sign-ins in window for correlation
Write-Host "`n=== Medium/High risk sign-ins (last 7 days) ===" -ForegroundColor Cyan
Get-MgIdentityProtectionRiskySignIn -Filter "createdDateTime ge $start" -All -ErrorAction SilentlyContinue |
  Select-Object CreatedDateTime, UserPrincipalName, RiskLevel, IPAddress,
    @{N='Location';E={"$($_.Location.city), $($_.Location.countryOrRegion)"}} |
  Format-Table -AutoSize

Write-Host "`nAction: For any suspicious FIDO2 method, revoke with: Remove-MgUserAuthenticationFido2Method -UserId <id> -Fido2AuthenticationMethodId <methodId>; then revoke sessions: Revoke-MgUserSignInSession -UserId <id>" -ForegroundColor Yellow

Remediation

Since there is no patch, remediation is configuration hardening and response discipline. Prioritize in this order:

Constrain passkey enrollment. Require authentication strength (phishing-resistant MFA or a fresh TAP issued through a verified help-desk workflow) to register new FIDO2/passkey methods, enforced via Conditional Access authentication context. Registration campaigns should use dedicated, time-boxed Conditional Access policies so off-cycle enrollment fires alerts.
Lock down Temporary Access Pass issuance. Restrict TAP creation to a named admin group, set short lifetimes and one-time use, and build a control that every TAP must map to an ITSM ticket. Alert on any TAP creation by an account outside the named group.
Alert and auto-respond on method-registration anomalies. Deploy the Sigma/KQL detections above. Wire the high-severity rule to an automated playbook: revoke sessions (Revoke-MgUserSignInSession), disable the account pending review, and open an incident.
Enable and enforce passkey attestation in the Entra ID passkey (FIDO2) authentication method policy. Maintain an AAGUID allowlist so only approved, organization-issued authenticators can be registered — this blocks attacker-registered consumer authenticators outright.
Harden against the BEC campaign. Deploy display-name impersonation and first-time-sender banners for executive spoofing in your mail gateway, tighten DMARC enforcement (p=reject) on your own domains, and require out-of-band verification (a phone call on a known number) for any payment or bank-detail change request — no exceptions for 'CEO urgency.'
Post-compromise checklist for confirmed victims: revoke all sessions and refresh tokens, remove all attacker-registered auth methods (FIDO2, authenticator, phone, TAP), reset credentials, review and delete malicious inbox rules and OAuth consents, audit UAL/Graph activity for the full dwell window to scope exfiltration, and rotate any secrets stored in accessed mailboxes or SharePoint sites.
Train for the specific lure. Users mid-migration to passkeys are primed to click enrollment-themed emails. Brief them that legitimate passkey setup is initiated from the security settings portal they navigate to themselves — never from an emailed link — and brief help desk staff on TAP-abuse social engineering with a mandatory identity-proofing step.

Review Microsoft's disclosure and authentication method policy guidance at the Microsoft Security Response Center and Microsoft Learn (Entra ID passkey/FIDO2 documentation), and confirm your Sentinel workspace is ingesting both SigninLogs and AuditLogs with at least 90 days of retention — the registration-to-exfiltration window in these campaigns can span days.

Related Resources

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