> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Passkey-themed social engineering leads to identity and cloud compromise - URL: https://f4n6.co.uk/security-feed/passkey-themed-social-engineering-leads-to-identity-and-cloud-compromise/ - Published: 2026-09-09T21:26:53.000Z - Updated: 2026-09-09T21:26:53.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary Microsoft Security Research is tracking active, multi-account cloud intrusions — observed since May 2026 — that begin with helpdesk-impersonation vishing and passkey/SSO-themed phishing lures delivered to employees' personal phones, proceed through adversary-in-the-middle (AiTM) phishing or device-code flow abuse to steal session tokens, and culminate in actor-registered MFA persistence, Microsoft Graph-based tenant reconnaissance, and measured, multi-day data collection from SharePoint Online, OneDrive for Business and Exchange Online. Microsoft attributes the initial-access activity to a range of actors including Storm-3121 (feeding ShinyHunters/Falcon extortion) and Storm-3032 (splintered from BlackFile, operating under the Helix extortion banner); no MITRE ATT&CK profiles are available for these names in our verified reference data, so attribution should be treated as unconfirmed. The bottom-line risk for EMEA financial services is credential- and token-level compromise of Microsoft 365 identities with no malware, no endpoint telemetry, and exfiltration paced below 1,000 files/emails per hour to blend with normal usage — followed by extortion. No CVEs are involved; this is a pure identity/social-engineering threat, and the durable defence is behavioural detection across sign-in, authentication-method, Graph, and file/mail download signals. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 19: reporting of major ICT-related incidents to competent authorities | The observed pattern is data collection and potential exfiltration from Microsoft 365 (SharePoint, OneDrive, Exchange) feeding extortion operations — a confidentiality breach at cloud scale whose classification must be assessed against major-incident thresholds | Financial entities that confirm compromise must run the Art. 19 assessment in conjunction with their Art. 18 classification process, and be prepared to submit initial/intermediate reports on the exfiltration timeline, which the source notes can span hours to multiple days | | DORA Art. 18: classification of ICT-related incidents and cyber threats | The campaign is a currently-active, multi-account threat with extortion downstream (Storm-3121/ShinyHunters/Falcon; Storm-3032/Helix), meaning affected clients face a live classification decision, not a historical one | Clients should classify any confirmed account compromise under their Art. 18 criteria with the extortion nexus explicitly weighed, since downstream actor use of stolen data changes severity | | NIS2 Art. 23: incident reporting obligations | For in-scope financial-sector entities in NIS2 member states, the same confirmed exfiltration events carry significant-operational-impact / significant-impact assessment and early-warning/notification duties | Clients dual-scoped under NIS2 should trigger their Art. 23 assessment in parallel with DORA reporting rather than sequentially | No specific UK NIS article is engaged beyond the general OES/RDSP duties; UK-regulated clients should apply their standard incident processes. ## 3\. Technical analysis & attack chain ### Confirmed attack chain (per Microsoft's investigation) 1. **Pre-attack research.** The actor gathers employee names and organisational structure from public sources — social networking and professional profiling platforms — to personalise the approach. 2. **Infrastructure deployment.** Generic domains are registered (frequently via Nicenic registrar, also observed in previous extortion campaigns — registration alone is not evidence of registrar involvement) with the target organisation's name embedded as a subdomain, e.g. `contoso[.]add-passkey[.]com`. Multiple domains per target allow rotation; domains are operational within hours. Themes: passkeys, SSO enrollment, account activation, identity verification. 3. **Initial contact.** A call or SMS to the user's *personal* phone number from a "helpdesk" caller, urging immediate passkey/MFA/SSO update to avoid disruption. In a minority of cases, already-compromised employee identities are used to send the same lures via Microsoft Teams, lending internal legitimacy. 4. **Token/credential capture** via one of three observed patterns: - **AiTM phishing:** victim authenticates at the lookalike portal; actor captures credentials and session token. Sign-in user-agent patterns indicated possible AiTM. - **Device code flow:** victim is persuaded to enter a code on the legitimate Microsoft authentication page; approval issues a token to an attacker-controlled client — no browser cookie theft required. The actor then replayed the compromised token, bypassing MFA. - **Pre-registered MFA:** actor signs in with compromised credentials and satisfies MFA via a PhoneAppOTP method registered *days before* the campaign — indicating earlier access to the account. 5. **Authentication persistence.** The actor enrolls an actor-controlled MFA method (new phone number, authenticator app, or software OTP token) via the `Update user.` operation, inserting a factor they control. This does not survive a full credential-and-session reset but is durable when combined with stolen tokens or unrevoked sessions. 6. **Cloud reconnaissance via Microsoft Graph.** Systematic enumeration of users, groups, permissions, resources and accessible content — see the URI table below. In one sequence, the actor used an automated Node.js system against Microsoft Graph. 7. **Collection and exfiltration.** High-volume `FileAccessed`/`FileDownloaded` events across SharePoint Online and OneDrive for Business, plus Exchange Online REST API access to email content. Paced at fewer than 1,000 files/emails per hour, spanning hours to days. Infrastructure is rotated per phase — separate IPs for authentication, reconnaissance and exfiltration — so single-IP pivoting is unreliable. **Observed session timeline (one investigated sequence, from sign-in):** OfficeHome sign-in from unmanaged device (error 50074 → MFA challenge) → MFA completed with non-phishing-resistant method, error 50140 keep-me-signed-in → session established (T+1) → My Apps and My Profile enumeration (T+2) → Microsoft Approval Management and Microsoft Account Controls V2 accessed (T+3) → My SignIns via Graph with same session/Chrome user agent/browser ID (T+4) → OCaaS app catalogue (T+10) → SharePoint Online site/document requests and Outlook Web mailbox access (T+11–50) → Azure Virtual Desktop auth flow via Windows App – Web (T+12) → internal virtual application/desktop portal auth (T+14) → OwaDownloadAttachments resource requested (T+15) → M365ChatClient and internal business workflow application (T+16). Sessions persisted approximately one hour in this sequence. Note Microsoft's own caveat: sign-in events do not prove a document was opened/downloaded or an attachment retrieved. ### Graph reconnaissance patterns (defender-relevant) | Recon pattern | Graph URI examples | Why it matters | | --------------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | Tenant profile | /organization, /subscribedSkus, /licenseDetails | Setup activity; stronger when followed by user/role discovery | | Directory enumeration | /users, /groups, /members, /transitiveMembers | Maps identities, privileged users, sensitive groups | | Privilege and MFA discovery | /directoryRoles, /roleManagement, /authentication/methods | High-value recon around identity control and persistence | | Application and consent discovery | /applications, /servicePrincipals, /oauth2PermissionGrants, /appRoleAssignments | Exposes reusable access paths and high-value service identities | | SharePoint/OneDrive discovery | /sites, /lists, /drives, /drive/items, /root/children, /search | Converts tenant recon into a collection-ready file map | | Mailbox discovery | /messages, /mailFolders, /attachments | Supports intelligence collection, BEC, targeted attachment retrieval | | Automation and pagination | $top, $skip, $skiptoken, $count, /delta, /search | Raises confidence when combined with broad discovery | | Content collection | /content, message/attachment retrieval, large ResponseSize | Strongest indicator recon has progressed to collection | **Key forensic artefact — actor-controlled software token.** Microsoft published a redacted `Update user.` audit record (Operation, RecordType 8, Workload AzureActiveDirectory, ResultStatus Success) in which `StrongAuthenticationPhoneAppDetail` gains a second `NewValue` entry with `DeviceName: NO_DEVICE`, `DeviceToken: NO_DEVICE_TOKEN`, `DeviceTag: SoftwareTokenActivated`, `PhoneAppVersion: NO_PHONE_APP_VERSION`, `AuthenticationType: 2`, `NotificationType: 1`, `HashFunction: hmacsha1` — distinct from the legitimate iOS Authenticator entry (`DeviceTag: iOS`, `PhoneAppVersion: 6.8.53`, `AuthenticationType: 3`, `NotificationType: 2`). This is a high-fidelity persistence signature. **Exfiltration characteristics.** The `python-httpx` user agent was observed with high-volume SharePoint/OneDrive access — Microsoft explicitly cautions the user agent alone is not malicious and must be evaluated in context. Anonymous-proxy sign-ins (`IsAnonymousProxy == true`) were also observed. Exchange REST access appeared via One Outlook Web / Office application IDs (`20893`; app GUIDs `9199bf20-a13f-4107-85dc-02114787ef48`, `d3590ed6-52b3-4102-aeff-aad2292ab01c`); SharePoint/OneDrive download activity via application IDs `20892` and `15600`. **Attribution caveat.** Microsoft Threat Intelligence assesses the initial access is used by a range of actors including Storm-3121 (initial access leading to ShinyHunters and Falcon extortion) and Storm-3032 (splintered from BlackFile, operating under the Helix extortion banner). These names have no MITRE profiles in our verified reference data — treat attribution as unconfirmed. Related reporting attributes similar passkey-enrollment vishing to Okta's O-UNC-066 and to the "Pink" extortion crew (single-sourced vendor attributions; verify before enforcement). No ransomware is described; the end-state is data theft and extortion. ## 4\. Mitigation & containment ### P1 — within 24 hours (confirmed or suspected compromise) - Revoke all active sessions and refresh tokens for affected identities; force password reset. - Remove unauthorized authentication methods — specifically hunt for the `NO_DEVICE` / `SoftwareTokenActivated` software-token signature in `StrongAuthenticationPhoneAppDetail` and any MFA method registered outside the user's normal device inventory. - Block the listed phishing domains at DNS/proxy/secure web gateway (see §5). - Review sign-in logs for the affected identities back to at least May 2026 for: unmanaged-device OfficeHome sign-ins, device-code flow authentications, anonymous-proxy IP sign-ins, and `python-httpx` user agents. - Notify staff that IT will never request passkey/MFA enrollment by unsolicited phone call or SMS; establish a verified callback channel now. ### P2 — within 72 hours - Run the Graph reconnaissance hunts from §6/§3 across the tenant: identities or applications touching ≥3 recon categories from one IP within 30 minutes; `/directoryroles`, `/rolemanagement`, `/authentication/methods` access; `$top`/`$skip`/`$skiptoken`/`/delta` pagination bursts; `/messages`/`/mailFolders`/`/attachments` concentration. - Hunt exfiltration: `FileDownloaded`/`FileAccessed`/`SyncDownloadedFull` ≥100 files per 2h window with `python-httpx`; Exchange REST event counts ≥500/hour via app IDs 20893/20892/15600; anonymous-proxy file events ≥5 GB or ≥1,000 events per 2h. - Enforce phishing-resistant MFA (FIDO2 passkeys held on managed devices) for all users — the observed AiTM and device-code paths both defeat non-phishing-resistant MFA. Conditional Access should require compliant/managed devices for Graph, SharePoint, OneDrive and Exchange access. - Restrict device code flow: disable or Conditional Access-limit the device code flow for users who do not require it. - Audit MFA method registration timelines for executive/director-level accounts (related reporting indicates these are preferentially targeted) for methods registered days before any observed sign-in anomaly. ### P3 — within 7 days - Implement the MFA-registration detection: `CloudAppEvents` where `ActionType == "Update user."`, `ResultStatus == "Success"`, `RawEventData` has `StrongAuthenticationPhoneAppDetail`/`StrongAuthenticationUserDetails`, comparing old/new device counts — alert on any net-new device entry. - Correlate user reports of unsolicited calls/SMS with subsequent sign-in and auth-method events; make helpdesk logging of such reports a first-class forensic source — Microsoft notes the employee's recollection is often the earliest or only evidence of initial access. - Review Teams external-communication and internal-message lures: warn users that passkey-themed messages from colleagues' accounts may themselves be compromised. - For DORA-scoped clients, feed confirmed findings into the Art. 18 classification and Art. 19 reporting workflow with the extortion nexus documented. ## 5\. Indicators of compromise All indicators are phishing domains from the Microsoft Security Blog (single primary source; corroborating coverage from BleepingComputer/The Hacker News/Help Net Security references the same campaign family but the domain list itself is Microsoft-sourced). | type | value | confidence | source | | ------ | ------------------------- | ---------- | ----------------------- | | domain | passkeyhelpdesk\[.\]com | High | Microsoft Security Blog | | domain | secure-passkey\[.\]com | High | Microsoft Security Blog | | domain | setupmypasskey\[.\]com | High | Microsoft Security Blog | | domain | add-passkey\[.\]com | High | Microsoft Security Blog | | domain | integratedsso\[.\]com | High | Microsoft Security Blog | | domain | oktasession\[.\]com | High | Microsoft Security Blog | | domain | keysyncos\[.\]com | High | Microsoft Security Blog | | domain | oskeysync\[.\]com | High | Microsoft Security Blog | | domain | oskeysetup\[.\]com | High | Microsoft Security Blog | | domain | oskeyregister\[.\]com | High | Microsoft Security Blog | | domain | syncmykey\[.\]com | High | Microsoft Security Blog | | domain | myconnectkey\[.\]com | High | Microsoft Security Blog | | domain | oskeyconnect\[.\]com | High | Microsoft Security Blog | | domain | validationsetupac\[.\]com | High | Microsoft Security Blog | | domain | portalsetuphub\[.\]com | High | Microsoft Security Blog | ```iocs domain passkeyhelpdesk[.]com domain secure-passkey[.]com domain setupmypasskey[.]com domain add-passkey[.]com domain integratedsso[.]com domain oktasession[.]com domain keysyncos[.]com domain oskeysync[.]com domain oskeysetup[.]com domain oskeyregister[.]com domain syncmykey[.]com domain myconnectkey[.]com domain oskeyconnect[.]com domain validationsetupac[.]com domain portalsetuphub[.]com ``` Note: the actor embeds the target organisation's name as a subdomain of these domains (e.g. `contoso[.]add-passkey[.]com`) and rotates infrastructure within hours — block the base domains and alert on any subdomain pattern matching `.*` against these suffixes. **Behavioural indicators** (no atomic indicators exist for these; hunt, don't just block): | behaviour | where to observe | confidence | | --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------ | | Update user. success adding a device entry with DeviceName: NO\_DEVICE, DeviceTag: SoftwareTokenActivated, HashFunction: hmacsha1 | Entra ID audit log (CloudAppEvents, StrongAuthenticationPhoneAppDetail) | High — real-world example published by Microsoft | | OfficeHome sign-in from unmanaged device, errors 50074 then 50140, MFA satisfied by non-phishing-resistant method | Entra ID sign-in logs | High | | Device-code flow authentication followed by token replay from new IP/infrastructure | Entra ID sign-in logs (device code flow events) | High | | MFA satisfied by PhoneAppOTP method registered days earlier | Entra ID sign-in + authentication method registration logs | High | | ≥3 Graph recon categories (tenant/directory/privilege/application/repository/mailbox) from one identity+IP within 30 min | GraphAPIAuditEvents | High | | /directoryroles, /roleManagement, /authentication/methods access | GraphAPIAuditEvents | High | | Pagination automation: $top, $skip, $skiptoken, $count, /delta, /search bursts | GraphAPIAuditEvents | High | | python-httpx user agent with ≥100 FileAccessed/FileDownloaded/SyncDownloadedFull per 2h | CloudAppEvents app IDs 20892/15600 | High | | Exchange REST event count ≥500/hour via One Outlook Web / Office app IDs | CloudAppEvents app ID 20893 | High | | File events from anonymous-proxy IPs, ≥5 GB or ≥1,000 events per 2h | CloudAppEvents, IsAnonymousProxy == true | High | | Passkey/SSO-themed lures sent via Microsoft Teams from a compromised internal account | Teams message reports / user reports | Medium | | Employee report of unsolicited "helpdesk" call or SMS to personal phone | Helpdesk ticketing / user reports | High — often the only initial-access evidence | ## 6\. Detection The sources provide distinctive audit-log artefacts (the `NO_DEVICE` software-token registration values) and behavioural log patterns. No file-based malware exists in this campaign, so a YARA rule is not applicable; Sigma and KQL rules are the correct instrumentation. ### Sigma — actor-controlled software OTP token registration (Entra ID audit) ```yaml title: Entra ID - Actor-Controlled SoftwareTokenActivated MFA Method Registration (NO_DEVICE) id: 8f3a1c92-5d47-4e8a-b6f1-2c9d0a7e4b53 status: experimental description: > Detects the Update user operation adding a second StrongAuthenticationPhoneAppDetail entry with the NO_DEVICE / SoftwareTokenActivated signature observed in passkey-themed identity compromise campaigns (Microsoft Security Blog, 2026-09-09). references: - https://www.microsoft.com/en-us/security/blog/2026/09/09/passkey-themed-social-engineering-leads-identity-cloud-compromise/ author: Adverse Trace date: 2026-09-09 logsource: product: microsoft365 service: audit.unified detection: selection: workload: AzureActiveDirectory operation|contains: 'Update user.' resultstatus: 'Success' modified_property: 'StrongAuthenticationPhoneAppDetail' software_token: new_value|contains: - 'NO_DEVICE' - 'NO_DEVICE_TOKEN' - 'SoftwareTokenActivated' - 'NO_PHONE_APP_VERSION' condition: selection and 1 of software_token falsepositives: - Legitimate software OTP token enrollment via non-standard tooling (rare; verify device inventory) level: high tags: - attack.persistence - attack.credential_access ``` ### Sigma — device code flow authentication (initial access vector) ```yaml title: Entra ID - Device Code Flow Authentication (Potential Phishing-Induced Token Issuance) id: c47e2b08-9a15-4f3d-8e6b-71f0c3d5a294 status: experimental description: > Flags device code flow authentications, which in this campaign were induced by passkey-themed lures and issued tokens to attacker-controlled clients. references: - https://www.microsoft.com/en-us/security/blog/2026/09/09/passkey-themed-social-engineering-leads-identity-cloud-compromise/ author: Adverse Trace date: 2026-09-09 logsource: product: azure service: signinlogs detection: selection: authentication_protocol: deviceCode condition: selection falsepositives: - Legitimate device-code sign-ins from constrained devices (printers, IoT, CLI tools); baseline per user level: medium ``` ### KQL — MFA persistence (from Microsoft's published query, reproduced for client deployment) ```kql // Detects a newly registered MFA device with a populated device token. CloudAppEvents | where ActionType == "Update user." | where tostring(RawEventData.ResultStatus) == "Success" | where RawEventData has_any ("StrongAuthenticationPhoneAppDetail", "StrongAuthenticationUserDetails") | extend AccountObjectId = extract(@"User_([a-f0-9\-]+)", 1, tostring(RawEventData.Target)) | where isnotempty(AccountObjectId) | mvexpand ModifiedProp = RawEventData.ModifiedProperties | where tostring(ModifiedProp.Name) in ("StrongAuthenticationPhoneAppDetail", "StrongAuthenticationUserDetails") | extend OldValue = tostring(ModifiedProp.OldValue), NewValue = tostring(ModifiedProp.NewValue) | extend OldDeviceCount = countof(OldValue, @"""Id"""), NewDeviceCount = countof(NewValue, @"""Id""") | where NewDeviceCount > OldDeviceCount ``` ### KQL — multi-category Graph reconnaissance (from Microsoft's published query) ```kql // Find identities or applications touching several reconnaissance categories // from the same IP within 30 minutes. let Lookback = 24h; GraphAPIAuditEvents | where Timestamp > ago(Lookback) | where toint(ResponseStatusCode) between (200 .. 299) | extend Uri = tolower(RequestUri), ActorId = coalesce(AccountObjectId, ServicePrincipalId, ApplicationId), Path = tostring(split(tolower(RequestUri), "?")[0]) | extend ReconType = case( Uri has "/organization" or Uri has "/subscribedskus", "Tenant", Uri has "/users" or Uri has "/groups", "Directory", Uri has "/directoryroles" or Uri has "/rolemanagement", "Privilege", Uri has "/applications" or Uri has "/serviceprincipals" or Uri has "/oauth2permissiongrants", "Application", Uri has "/sites" or Uri has "/drive", "Repository", Uri has "/messages" or Uri has "/mailfolders", "Mailbox", "Other") | where ReconType != "Other" and isnotempty(ActorId) | summarize Requests=count(), Categories=dcount(ReconType), DistinctPaths=dcount(Path), ReconTypes=make_set(ReconType, 10), SampleUris=make_set(RequestUri, 10) by ActorId, IpAddress, ApplicationId, bin(Timestamp, 30m) | where Requests >= 10 and Categories >= 3 and DistinctPaths >= 6 | order by Categories desc, Requests desc ``` ### KQL — python-httpx exfiltration pattern (from Microsoft's published query) ```kql // Exfiltration of data through python-httpx user agent CloudAppEvents | where ApplicationId == "20892" or ApplicationId == "15600" | where ActionType in ("FileDownloaded", "FileAccessed", "SyncDownloadedFull") | where isnotempty(AccountObjectId) | where isnotempty(IPAddress) | where isnotempty(UserAgent) | where UncommonForUser has_any("ISP","UserAgent") | where UserAgent has 'python-httpx' | project Timestamp, AccountObjectId, IPAddress, ISP, UserAgent | summarize FilesAccessedLastWindow = count() by AccountObjectId, IPAddress, ISP, UserAgent, bin(Timestamp,2h) | where FilesAccessedLastWindow >= 100 ``` ### KQL — Exchange REST exfiltration (from Microsoft's published query) ```kql // Exfiltration of data through REST API using Microsoft Office or One Outlook Web CloudAppEvents | where isempty(AccountObjectId) | where ApplicationId == '20893' | where AccountDisplayName in ("One Outlook Web", "9199bf20-a13f-4107-85dc-02114787ef48", "d3590ed6-52b3-4102-aeff-aad2292ab01c") | where isnotempty(IPAddress) | extend AccountObjectId = tostring(RawEventData.TokenObjectId) | summarize ExchangeRestEventCount=count() by IPAddress, AccountObjectId, bin(Timestamp,1h) | where ExchangeRestEventCount >= 500 ``` ### KQL — anonymous-proxy exfiltration (from Microsoft's published query) ```kql // Exfiltration of data through anonymous proxy CloudAppEvents | where ApplicationId in (20892, 20893, 15600) | where ActionType in~ ("FileDownloaded", "FileAccessed", "FilePreviewed") | where IsAnonymousProxy == true | where UserAgent !has "ODMTADemand" | extend FileSizeBytes = coalesce(tolong(RawEventData.FileSizeBytes), 0) | summarize FileSizeBytes = sum(FileSizeBytes), FirstSeen = min(Timestamp), LastSeen = max(Timestamp), EventCount = count(), ActionTypes = make_set(ActionType), Applications = make_set(Application) by AccountObjectId, IPAddress, TimeBucket = bin(Timestamp, 2h), UserAgent, ISP | extend FileSizeGB = round(FileSizeBytes / 1024.0 / 1024.0 / 1024.0, 2) | where FileSizeGB >= 5 or EventCount >= 1000 | order by EventCount desc ``` Microsoft Defender XDR detections referenced by Microsoft as covering this activity include: Microsoft Defender for Identity — "Malicious registration of a device with strong MFA", "Malicious registration of an attacker controlled MFA device", "Suspicious registration of a new Authenticator MFA method", "Malicious registration of a new Phone MFA method", "Suspicious Entra Graph API query observed"; Microsoft Defender XDR — "Malicious sign in from an IP address associated with recognized attacker infrastructure", "Automated mass SharePoint/OneDrive file access via python-httpx". ## 7\. Sources - Microsoft Security Research — *Passkey-themed social engineering leads to identity and cloud compromise* — https://www.microsoft.com/en-us/security/blog/2026/09/09/passkey-themed-social-engineering-leads-identity-cloud-compromise/ — 2026-09-09 - BleepingComputer — *Entra passkey enrollment vishing targets Microsoft 365 users* — https://www.bleepingcomputer.com/news/security/entra-passkey-enrollment-vishing-targets-microsoft-365-users/ — 2026 (related campaign coverage) - The Hacker News — *Hackers Use Fake Microsoft Entra Passkey Enrollment to Gain Microsoft 365 Access* — https://thehackernews.com/2026/07/hackers-use-fake-microsoft-entra.html — 2026-07 (Okta O-UNC-066 attribution) - The Hacker News — *Fake IT Calls Target Executives in Microsoft 365 Data Theft and Extortion Attacks* — https://thehackernews.com/2026/09/microsoft-365-attackers-use-help-desk.html — 2026-09 (related cluster, executive targeting) - Help Net Security — *Extortion crew hijacks Microsoft 365 accounts via fake passkey setup* — https://www.helpnetsecurity.com/2026/07/09/microsoft-365-fake-passkey-setup-enrollment/ — 2026-07-09 ("Pink" crew attribution) - The Hacker News — *Microsoft 365 AitM Phishing Hijacks Accounts to Collect Payroll and Finance Emails* — https://thehackernews.com/2026/08/microsoft-365-aitm-phishing-hijacks.html — 2026-08 (related AiTM campaign, residential proxies) - Microsoft Threat Intelligence — *How Storm-2949 turned a compromised identity into a cloud-wide breach* — https://www.microsoft.com/en-us/security/blog/2026/05/18/storm-2949-turned-compromised-identity-into-cloud-wide-breach/ — 2026-05-18 (related identity-compromise pattern, SSPR abuse) ## 8\. Adverse Trace position This is a high-severity, actively-exploited identity threat with direct extortion downstream, and it is precisely the attack class that evades perimeter and endpoint controls: no malware, no CVE, initial access often on personal devices outside MDE telemetry, and exfiltration paced to look like normal SaaS usage. The verified reference data resolved no independent CVSS/KEV entries for this item — it is a campaign, not a vulnerability — and the actor attributions (Storm-3121, Storm-3032, and the vendor-tracked O-UNC-066/"Pink" labels) are single-sourced to Microsoft and Okta respectively with no MITRE profiles available, so treat them as unconfirmed and do not build enforcement actions on attribution. The domain IOC set is likewise single-sourced to Microsoft and will age quickly given the documented infrastructure rotation; the durable defensive value is in the behavioural sequence — unusual sign-in → auth-method enrollment → Graph recon → content collection — and the `NO_DEVICE`/`SoftwareTokenActivated` persistence signature, which is high-fidelity. For EMEA financial services the exposure is acute: M365 tenants hold payroll, finance and client correspondence, related reporting shows executives preferentially targeted, and confirmed exfiltration engages DORA Art. 18/19 (and NIS2 Art. 23 where dual-scoped) reporting duties. Adverse Trace will track this cluster, update the IOC set as corroborating sources publish, and push follow-up advisories if the actor set, infrastructure patterns, or Graph abuse techniques materially change. --- [Read the original source →](https://www.microsoft.com/en-us/security/blog/2026/09/09/passkey-themed-social-engineering-leads-identity-cloud-compromise/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*