Case File No. 024 · September 13, 2026
Two confidence games share tonight’s desk. In one, a caller turns a real security idea—passkeys—into a reason for an employee to authorize the wrong session. In the other, a polished invoice and a borrowed executive name try to turn routine accounts payable into a nearly $50,000 mistake. The tools differ, but the defensive habit is the same: pause, verify through a channel the requester did not supply, preserve the record, and act in the right order.
Case-board summary
Microsoft says it has observed active, multi-account cloud intrusions since May 2026 in which unusual sign-ins were followed by attacker-added authentication methods, Microsoft Graph reconnaissance, and collection from Microsoft 365 workloads.[1] The “passkey” in the pitch was commonly a social-engineering theme; Microsoft’s report does not show a break of FIDO2 cryptography.[1][6]
In a separate campaign detected from August 3 through August 5, 2026, Microsoft reported more than one million fraudulent emails built around executive impersonation, a fake ServiceNow subscription invoice, and a requested ACH payment of nearly $50,000.[7] Microsoft described indicators consistent with generative-AI assistance, but said those indicators did not independently establish how much of the material AI generated.[7]
Tonight’s judgment: neither file is solved by teaching people to spot bad grammar. Identity teams need correlated sign-in, authentication-method, application, file, and mail evidence; finance teams need a payment-change process that cannot be overridden by a convincing message. No cited source identifies a Treasure Coast victim, and this article does not infer one.
Tonight’s risk at a glance
Highest urgency
A user reports an unexpected IT call, text, Teams message, passkey prompt, or device-code instruction—and Entra shows an unusual sign-in or a newly added authentication method. Microsoft’s observed chain could progress from sign-in to cloud discovery and content access within about an hour in one example.[1]
Money at risk
An invoice, reply-to address, beneficiary, bank account, payment method, or urgency changes inside email. The disclosed invoice campaign targeted accounts-payable personnel by impersonating executives and sending money instructions to attacker-controlled accounts.[7]
Best first move
Do not continue the conversation using the number, link, meeting, or reply path in the suspicious message. Contact the employee, executive, vendor, bank, or IT provider through an independently known channel, then contain access or pause payment while preserving evidence.
File 1 — The “security update” that opens the cloud
What happened
Microsoft reported a recurring campaign in which a researched employee receives a tailored call, text message, or sometimes a Teams contact from an already compromised employee account. The actor poses as IT support and uses a passkey, MFA, or single-sign-on update as the reason the employee must act immediately.[1] The reporting is best understood as an identity-authorization attack wrapped in security language, not as a newly discovered cryptographic weakness in passkeys.[1][6]
Microsoft documented three initial-access patterns in the observed activity: adversary-in-the-middle phishing after the user supplied credentials and completed a non-phishing-resistant MFA challenge; device-code phishing in which the user entered an actor-supplied code on Microsoft’s legitimate page; and a sequence that began with previously compromised credentials plus a PhoneAppOTP method apparently registered days earlier.[1] The flows differ, but all depend on usable identity authorization and permissive access—not on the attacker extracting a FIDO private key from the victim’s authenticator.[1][6]
After establishing access, the actors queried identity portals and Microsoft Graph, discovered applications and permissions, and added authentication methods they controlled. Microsoft then observed substantial SharePoint and OneDrive access or download activity and, in some intrusions, REST-based collection of Exchange email and attachments.[1] A successful sign-in or resource request is not automatically proof that every listed application was launched or every requested object was exfiltrated, so this article keeps “access,” “collection,” and “suspected exfiltration” separate.
Evidence and timeline
| Date or phase | What the frozen evidence says | Boundary |
|---|---|---|
| Since April 2026 | Okta observed O-UNC-066/Pink-linked targeting and a panel-controlled kit aimed at Microsoft Entra passkey enrollment.[3] | Okta said it did not directly observe Microsoft-account compromise in its telemetry; parts of the proposed enrollment mechanism were labeled likely or assumed.[3] |
| Since May 2026 | Microsoft observed the broader active intrusion sequence across multiple accounts.[1] | The number and names of organizations and accounts were not disclosed.[1] |
| September 4, 2026 | Microsoft reproduced a redacted real-world Update user event at 16:57:42Z showing a software-token addition.[1] |
The tenant and user were redacted; the event is an example, not a universal timestamp or signature. |
| September 9–11 | Microsoft published its principal report on September 9; RH-ISAC summarized it on September 10, and BleepingComputer reported on it September 11.[1][2][4] | The latter two sources corroborate the published account but do not expose separate raw incident telemetry in the frozen record. |
The April and May clocks should not be collapsed into a contradiction. Okta described an earlier, separately scoped cluster and infrastructure, while Microsoft described a broader intrusion sequence beginning in May.[1][3] Likewise, Okta assessed that its kit likely concealed enrollment of an attacker-held passkey, while Microsoft said passkey enrollment often was not the true objective in the activity it analyzed.[1][3]
Exposure: who is actually in this file?
A Microsoft cloud identity becomes materially exposed when several conditions line up: the actor can reach a believable target; the employee assists an authorization step; the tenant permits the relevant device-code, authentication-transfer, security-info registration, unmanaged-device, or session context; and the resulting identity or application token can reach valuable data.[1] Broad assigned access raises the potential impact because Graph and connected applications are still bounded by what the compromised identity or application is authorized to reach.[1]
A personal phone can be part of the exposure without being “hacked.” Microsoft noted that opening the lure on a personal device not onboarded to Defender for Endpoint may leave little endpoint evidence, making the employee’s memory of the interaction an important initial clue.[1] Conversely, receiving a call, seeing an odd URL, or finding one unfamiliar IP does not prove compromise. The case strengthens when human reporting, sign-in context, factor changes, Graph activity, and workload access align around the same identity and time window.[1]
Organizations using Microsoft 365 without a full security operations team are still in scope. CISA’s SCuBA project publishes Microsoft 365 secure-configuration baselines and makes the ScubaGear assessment tool available to public- and private-sector organizations to compare tenant settings with those baselines.[9] That is a posture check, not an incident detector or a promise that a conforming tenant cannot be compromised.
In-the-wild evidence
Microsoft observed unusual sign-ins followed by authentication-method additions, high-volume Graph activity, SharePoint and OneDrive downloads, and REST-based email collection across multiple accounts.[1] In one sequence, an unmanaged OfficeHome sign-in was followed by MFA completion, a successful session, identity and application discovery, then access to SharePoint, Outlook, and internal applications over roughly an hour.[1] Microsoft cautioned that portions of the sign-in telemetry did not by themselves establish document downloads, attachment downloads, or launch of the referenced virtual resources.[1]
The collection pattern was not always a spectacular spike. Microsoft said activity often continued for hours to multiple days and generally stayed below 1,000 files or emails in any one-hour period.[1] Some automated Graph activity showed Node.js characteristics, and several cases used the python-httpx user agent, but neither runtime nor user-agent string is malicious on its own.[1] Defenders should look for progression—directory and authentication discovery, application or consent review, repository or mailbox traversal, then content access—rather than treating a common developer tool as a verdict.
Okta separately saw branded, per-target infrastructure aimed at sectors including food and beverage, technology, healthcare, automotive, construction, and aviation.[3] That is evidence of targeting in Okta’s telemetry, not proof that every targeted organization was compromised. RH-ISAC and BleepingComputer echoed Microsoft’s published sequence; they are useful corroborating summaries, but the frozen copies do not establish a separate victim population.[2][4]
What remains unknown
- The public record does not identify the exact number, names, geography, or size of affected organizations; the amount and sensitivity of collected data; or whether every collection sequence ended in off-platform exfiltration.[1]
- Microsoft connected initial-access activity to multiple actors, including Storm-3121 and Storm-3032, while Okta and secondary coverage used other cluster and extortion labels.[1][2][3] The frozen evidence does not prove that all those names represent one operator, one campaign, or one-to-one aliases.
- The sources do not establish that Microsoft’s observed campaign generally enrolled attacker-held passkeys. Microsoft emphasized other actor-added methods; Okta’s separate kit analysis described passkey enrollment as likely and included explicit assumptions.[1][3]
- Access to an application, virtual desktop flow, internal portal, or attachment resource does not by itself establish launch, download, or downstream compromise.[1]
What it means for a home or small business
A home user may meet this story through a work account on a personal phone: an urgent “IT” call arrives after hours, the caller knows the employer’s name, and the page used for one step may even be a genuine Microsoft page. A small business may have the opposite problem: one Microsoft 365 administrator also handles billing, client files, mailbox rules, vendors, and every recovery route. The local risk is not proven local victimization; it is concentrated authority combined with informal support habits.
Set a plain rule before the call arrives: real support will let the employee hang up and call the published company number or known provider contact. An IT technician should never need the employee to read out a device code supplied by the technician, approve an unexplained sign-in, or rush through a security-information change. Businesses that need help building the policy, tenant controls, backups, and escalation path can review The IT Guys’ Small Business Services.
Immediate actions — evidence first, then recovery
- Verify through a trusted channel. Contact the employee and the real IT provider using a known number or directory entry. Record what was requested, which device was used, what the employee entered or approved, and the approximate time. Do not continue in the suspicious chat or call.
- Contain and block. From a clean, appropriately privileged administrator account, disable or block the affected Entra identity if compromise is plausible, restrict the suspicious access path, and consider temporary limits on sensitive applications while scope is established.[1][5]
- Preserve evidence. Export or retain Entra sign-in and audit records, authentication-method changes, Graph activity, SharePoint and OneDrive events, Exchange events, mailbox rules, relevant endpoint or mobile observations, and the employee’s timeline before normal retention or cleanup erases context.[1]
- Revoke sessions and remove rogue methods. Revoke Microsoft-held sign-in sessions and refresh tokens, then remove unauthorized phone, authenticator, or software OTP methods and inspect suspect registered devices.[1][5] Check OAuth grants, app-role assignments, service principals, and applications that keep their own sessions; Entra revocation cannot directly invalidate an application’s own session cookie.[1][5]
- Reset, recover, and monitor. Reset credentials from a clean administrative path, require secure re-registration of approved authentication methods, remove attacker-created mailbox rules, validate connected applications, restore affected data if necessary, and monitor for renewed sign-ins, factor changes, Graph enumeration, file access, and mail collection.[1] Microsoft says unauthorized method removal plus a complete credential and session reset defeats the described MFA persistence.[1]
Order matters. Resetting the password before blocking access and removing persistence can give an active intruder another chance at the replacement credential. Deleting the suspicious message before recording headers and context can destroy the fastest route to scope. Patching configuration without checking application-side sessions can leave a connected service open.
Detection and verification
Start with the person, not an IOC feed. A report of unsolicited IT contact, a personal-device link, or passkey and MFA urgency is high-value context when it shares a time window with an unusual or unmanaged sign-in.[1] Review the same identity for newly registered authentication methods and for fast visits to My Apps, My Profile, Approval Management, Account Controls, and My Sign-Ins.[1]
Then follow the session into Microsoft Graph and the workloads. Look for broad directory, role, authentication-method, application, service-principal, consent, repository, mailbox, and attachment discovery followed by SharePoint or OneDrive FileAccessed, FileDownloaded, or SyncDownloadedFull activity and Exchange REST access.[1] Compare identity, IP and provider, application, browser or user agent, timestamps, response volume, and content category. A solitary Graph request, IP, ISP, or python-httpx string is supporting context, not proof.[1]
Verification must include business applications outside Microsoft. Microsoft Learn notes that access-token and session invalidation behavior varies: default Entra access tokens last about one hour, Continuous Access Evaluation can invalidate supported Office 365 tokens near real time, and applications may maintain their own session cookies.[5] Confirm revocation or deprovisioning in every high-value connected app instead of assuming the Entra button reached them all.
Recovery and escalation
Escalate to a qualified Microsoft 365 incident responder when an unauthorized method exists, Graph activity crosses several categories, file or mail collection appears, a privileged account is involved, logs are incomplete, or the business cannot prove that application-side sessions are closed. Notify legal, insurance, affected business owners, and any required regulators according to the organization’s incident plan; the cited sources do not determine a particular company’s notification duties.
Recovery is not complete until no unauthorized factors, rules, grants, devices, or application sessions remain; risky sign-ins no longer succeed; abnormal Graph, file, and mail activity has stopped; and required files and messages are available from trusted backups. For practical preparation, see The IT Guys’ Microsoft 365 backup and recovery guide and OAuth consent revocation guide.
After containment, strengthen phishing-resistant authentication, restrict security-information registration, require managed devices for sensitive applications where practical, and block device-code or authentication-transfer flows unless the business has a documented need.[1] CISA’s SCuBA baselines and ScubaGear can provide a repeatable Microsoft 365 configuration review, but local requirements and risk tolerance still govern changes.[9]
Confidence: High that Microsoft observed the identity-to-cloud chain and associated authentication-method changes and workload activity; moderate and explicitly qualified for Okta’s inferred attacker-held passkey enrollment; low for any claim about local victims or a single unified actor, which this article does not make.[1][3]
File 2 — The invoice that borrows the boss’s voice
What happened
Microsoft reported detecting more than one million fraudulent emails sent through multiple third-party email-service accounts between August 3 and August 5, 2026.[7] The messages impersonated CEOs, CFOs, presidents, and other executives and tried to persuade accounts-payable staff at the same companies to initiate payment.[7] Microsoft said 87.7 percent of the campaign emails in its observed set were sent to users in the United States.[7] Those units matter: one million emails are not one million victims, 87.7 percent of messages are not 87.7 percent of companies, and a detected attempt is not a paid invoice.
The centerpiece was a fabricated “ServiceNow Platform — Annual Subscription” invoice seeking an ACH payment of nearly $50,000 to attacker-controlled bank accounts.[7] The message included invoice-like details and recipient-specific billing information, then reinforced the request with a fabricated forwarded conversation between the target company’s executive and an impersonated ServiceNow president.[7] Microsoft found no evidence that ServiceNow or the other legitimate organizations referenced in the lure were compromised or involved.[7]
Microsoft assessed that the templates showed indicators consistent with generative-AI assistance, including extensive HTML comments, structured section labels, uniform construction, and stable narrative or invoice elements with target-specific substitutions.[7] The company explicitly cautioned that those indicators did not independently prove the extent of AI generation.[7] “AI-assisted” is therefore a qualified vendor assessment, not a forensic finding that a particular model wrote every line or made the campaign successful.
Evidence and timeline
| Date or item | Observed or reported evidence | What it does not prove |
|---|---|---|
| July 31, 2026 | Microsoft said two lookalike or reply-to domains used in the campaign were registered shortly before the observed email activity.[7] | Registration does not establish that campaign preparation began that day or reveal the actor. |
| August 3–5, 2026 | Microsoft’s disclosed detection window covered more than one million emails sent through multiple third-party email-service accounts.[7] | The source does not call this the complete operating period or disclose unique inboxes, recipients, companies, or services. |
| Payment request | The lure sought an ACH transfer of nearly $50,000 and directed transfers to attacker-controlled accounts at multiple financial institutions across samples.[7] | No completed transfer, confirmed loss, bank count, account count, or recovery result was reported. |
| September 10 and 13 | Microsoft published the primary report September 10; The Hacker News included the campaign in its September 13 story and attributed the campaign facts to Microsoft.[7][8] | The Hacker News item is the same-day candidate index and derivative context, not independent incident telemetry. |
Exposure: where the process can fail
The exposed system is the payment process. A company is at material risk when email alone can create or change a vendor, approve an invoice, alter bank instructions, or waive a second review. Executive authority makes the request feel safe; vendor branding makes it look routine; recipient-specific fields make it feel researched; and a fake prior thread supplies the illusion of history. Microsoft observed those elements together in this campaign.[7]
Email authentication and filtering still matter. Microsoft recommended correct SPF, DKIM, and DMARC configuration, spoof protection, mail-flow controls, enhanced connector filtering, anti-phishing protections, Defender for Office 365, Zero-hour Auto Purge, and Defender XDR investigation capabilities.[7] Those are layered vendor recommendations, not evidence that targeted organizations had the controls enabled or that one control guarantees prevention.
A household can meet the same pattern in a smaller costume: a fake contractor invoice, title-company wire instruction, association payment, tuition bill, or urgent message supposedly from a family member. The frozen evidence concerns an enterprise campaign; these household examples are practical analogies, not additional incidents attributed to Microsoft.
In-the-wild evidence
Microsoft observed messages in which the executive identity appeared in display names, reply-to display names, signatures, and fabricated correspondence.[7] The supposed forwarded exchange lacked normal forwarded-message headers and visual grouping, and some messages contained subject or wording anomalies, identity-to-address mismatches, and narrative contradictions.[7] One pressure-reducing phrase suggested there was “no need to copy” the executive, which would reduce the chance of independent verification.[7]
The actor used multiple third-party email-service accounts, while payment destinations varied across samples and involved multiple financial institutions.[7] Microsoft published a bounded indicator set, but this article omits sender addresses and live domains to reduce accidental interaction. Organizations should search their own telemetry using authorized, defanged indicators from the primary report and validate any block against normal business context.
Microsoft described how Defender classifications and post-delivery removal paths could identify or remove scam messages, including quarantine and Zero-hour Auto Purge.[7] The report did not quantify delivery, block, removal, reply, PDF-request, conversion, or payment rates, so it would be wrong to say all one million messages were blocked or that every attempt failed.
What remains unknown
- Microsoft did not report whether anyone paid, how much was lost, whether any money was recovered, or whether a receiving account was frozen.[7]
- The public evidence does not disclose counts of unique recipients, inboxes, companies, countries beyond the U.S. share, sender accounts, delivery services, financial institutions, or beneficiary accounts.[7]
- The source does not identify how targets were selected or whether personalization came from public research, scraping, stolen records, vendors, or another source.[7]
- No actor, group, country, or attribution confidence is named for this invoice campaign.[7] Actor names elsewhere in the same Hacker News story belong to the separate passkey-themed campaign and must not be attached to the invoice operation.[8]
- The evidence does not identify a generative-AI system, isolate which material it produced, or measure whether AI improved scale, quality, evasion, or success.[7]
What it means for a home or small business
A small office does not need a million-message campaign to lose money; it needs one believable request reaching the one person who can pay. The practical control is deliberate friction: a known vendor record, a callback number sourced from that record, a second approver, and a no-exceptions rule for new or changed banking instructions. The executive must support the pause, especially when the message claims the executive wants speed or secrecy.
Homeowners should treat wiring instructions and changed payment details the same way. Verify with the business through a phone number you already trust, not the number or reply address in the new message. If your organization needs a documented payment and email-safety process, use Contact Us; this link is for assistance, not evidence that any local incident occurred.
Immediate actions — verify before money moves
- Verify through a trusted channel. Pause the payment. Call the executive and vendor using established directory or contract records. Confirm the invoice, amount, purchase, beneficiary, account number, and any changed instructions. Do not use contact details introduced by the suspicious email.
- Contain and block. If the request is fraudulent, stop approval, tell finance not to pay or reply, quarantine matching messages where authorized, block the validated malicious route, and alert other likely recipients without forwarding active links or attachments. Microsoft recommends layered mail authentication, anti-phishing, and post-delivery response controls.[7]
- Preserve evidence. Retain the original message, full headers, attachments in a safe evidence store, mailbox and gateway records, approval history, vendor-master changes, callback notes, payment-system logs, and the exact time each action occurred. Do not merely screenshot the body and delete the source.
- Revoke access and remove persistence if an account is involved. If investigation shows a mailbox or cloud identity was compromised, revoke sessions, remove unauthorized authentication methods, inspect OAuth grants and mailbox rules, and verify application-side sessions before resetting credentials.[1][5]
- Recover and monitor. If no funds moved, document the attempted fraud, restore normal mail flow carefully, and watch for follow-up variants. If money moved, contact the sending bank’s fraud department immediately through a known number, request a recall or hold, notify the receiving institution through authorized banking channels, preserve the case number, and follow legal, insurer, and law-enforcement reporting requirements applicable to the organization.
Detection and verification
Start with identity and process mismatches: the display name does not fit the sender address; the reply-to differs; the vendor or bank information changed; the invoice bypasses purchase-order history; or a senior leader asks finance to avoid copying someone who would normally review the payment. Microsoft observed address mismatches, malformed thread structure, wording anomalies, and internal contradictions in the campaign material.[7]
Do not make “sounds AI-written” a detection rule. Uniform HTML comments and section labels supported Microsoft’s qualified assessment, but an em dash, polished tone, or clean grammar cannot authenticate or condemn a message.[7] Verify the business event instead: did procurement approve the service, does the vendor record exist, has the bank information changed, does the executive confirm through the corporate directory, and can the vendor confirm through a previously established number?
Mail administrators should search for matching sender and reply-to patterns, subject themes, template structure, recipient targeting, and related campaign alerts, then identify every mailbox that received or acted on a message. Microsoft recommends Defender XDR investigation tooling to connect affected users, alerts, and campaign indicators.[7] Finance should separately review vendor-master edits, payment drafts, approvals, failed transactions, and callbacks; a clean mail search cannot prove that no payment-system action occurred.
Recovery and escalation
If funds moved, time matters more than embarrassment. Contact the bank immediately, using its known fraud channel, and ask what recall, freeze, or interbank notification is available. Preserve transaction identifiers and do not promise recovery: Microsoft’s public report did not disclose completed transfers or outcomes.[7] Escalate internally to finance leadership, legal counsel, the insurer, and incident response, then make reports required by the organization’s jurisdiction and contracts.
If the email arrived without account compromise, recovery may be mostly process repair: remove related messages, verify that no vendor record or payment instruction changed, document the attempt, and reinforce callback rules. If a real mailbox was used or forwarding rules, OAuth access, or authentication changes appear, merge this file with the cloud-identity response in File 1. Treat the incident as both fraud and unauthorized access, and do not close it merely because the transfer was stopped.
Before normal payment activity resumes, require two-person approval for new beneficiaries and changes to bank details, keep vendor contact data outside the incoming email thread, and log the independent callback. These are practical controls derived from the documented fraud pattern, not measured guarantees of prevention.
Good news
The campaign left checkable defects beyond prose style: identity and address mismatches, thread-format problems, narrative contradictions, new payment destinations, and a purchase that should exist in procurement records.[7] A trusted callback plus a second approver can break the chain before money moves.
Bad news
The operation combined executive authority, vendor branding, personalized billing fields, fabricated history, reusable templates, and high-volume delivery through third-party email infrastructure.[7] It targeted accounts payable, where one successful action can have immediate financial consequences.[7]
Confidence: High on Microsoft’s detection window, email-volume lower bound, U.S. share, lure design, requested payment, and infrastructure characterization; qualified on AI assistance; unknown on successful payments, losses, unique organizations, and actor identity.[7] The Hacker News source is discovery and derivative context, not independent corroboration.[8]
Do this tonight
- Tell staff to stop any unexpected passkey, MFA, device-code, or “IT update” interaction and verify by calling the known helpdesk or provider number.
- Ask Microsoft 365 administrators to review today’s unusual sign-ins and authentication-method additions, then correlate suspicious identities with Graph, SharePoint, OneDrive, Exchange, and mailbox-rule activity.[1]
- Pause every invoice involving a new beneficiary, changed bank instruction, unusual urgency, secrecy request, or executive override until the executive and vendor confirm through independently known channels.
- If compromise is plausible, block access, preserve logs, revoke sessions, remove rogue methods and grants, then reset credentials and verify application-side sessions—in that order.[1][5]
- If payment moved, call the bank’s established fraud number now, request available recall or hold actions, preserve the transaction record, and open the organization’s incident and fraud procedures.
Do this this week
- Publish a support rule: IT will never object when an employee hangs up and calls back through the company directory.
- Review who may register authentication methods, use device-code or authentication-transfer flows, sign in from unmanaged devices, consent to applications, and access high-value Microsoft 365 data.[1]
- Use CISA’s Microsoft 365 SCuBA baseline and ScubaGear as a repeatable configuration-assessment input, then reconcile recommendations with business requirements and risk tolerance.[9]
- Require independent callback and two-person approval for new vendors, new beneficiaries, changed bank data, and exceptional payments.
- Test restoration of important Microsoft 365 content and document which provider owns identity, mail, file, application, finance, bank, insurance, and legal escalation.
- Run a tabletop exercise that begins with a personal-phone call and ends with both cloud data collection and an attempted invoice, because identity compromise and payment fraud can cross the same mailbox.
FAQ
Were passkeys cracked?
No cryptographic break is established. Microsoft documents FIDO2 passkeys as origin-bound public-key credentials, and the campaign report centers on social engineering, session authorization, device-code use, and attacker-added authentication methods.[1][6]
Should we stop deploying passkeys?
The evidence does not support that conclusion. Genuine FIDO2 passkeys are phishing-resistant; the operational lesson is to secure enrollment and recovery, restrict unauthorized method registration, and train staff to reject surprise support-led setup.[1][6]
Does revoking Entra sessions log the user out everywhere?
Not necessarily. Microsoft says token and session behavior varies, supported Office 365 tokens may be invalidated near real time with Continuous Access Evaluation, and Entra cannot directly revoke an application’s own session cookie.[5] Verify every high-value connected application.
Did the invoice campaign steal $50,000 from each victim?
No. Microsoft described a request for nearly $50,000 but did not report a completed transfer, a confirmed loss, or a victim count.[7]
Did AI write the fraudulent invoice?
Microsoft saw indicators consistent with generative-AI assistance but said they did not independently establish how much material AI generated.[7] The specific model and measurable effect on success remain unknown.
Is a polished email safer than one with typos?
No. The campaign combined polished structure with anomalies and contradictions.[7] Authenticity should come from verified identity, procurement records, known vendor contacts, and payment controls—not writing style.
Does this prove a local Treasure Coast incident?
No. None of the frozen sources identifies a victim in Port Saint Lucie, Jensen Beach, Fort Pierce, Vero Beach, or elsewhere on the Treasure Coast. Local sections explain relevance and defensive action, not local incident attribution.
Methodology and source note
The September 13, 2026 candidate ledger contained one qualifying Hacker News editorial, and that story joined two related but distinct campaign subjects: passkey-themed identity and cloud compromise, and Microsoft’s executive-impersonation invoice-fraud research.[8] This case file therefore treats them as separate evidence records rather than implying one actor, victim set, infrastructure set, or outcome.
Drafting used the frozen local captures and claim memos retrieved through September 13, 2026, 7:54 PM EDT (September 13, 2026, 23:54 UTC). Microsoft’s two security reports are the primary campaign sources.[1][7] Microsoft Learn supplies product behavior for passkeys and session revocation; Okta supplies separately scoped kit and targeting research; CISA supplies a reusable cloud-configuration resource; RH-ISAC, BleepingComputer, and The Hacker News are treated as secondary or derivative where the frozen material does not contain independent telemetry.[2][3][4][5][6][8][9]
Consequential factual claims carry numbered markers beside the sentence they support. “Microsoft reported” preserves vendor provenance; “unknown” means the frozen record does not establish the point, not that the event is impossible. Counts preserve their units, targeting is not called compromise, access is not automatically called exfiltration, attempted payment is not called loss, and an AI indicator is not called proof.
The article intentionally omits live malicious domains, unredacted sender addresses, exploit instructions, and other offensive operational detail. Recommendations are defensive practice derived from the reported conditions; they are not guarantees, legal advice, or proof of a local incident.
AI-writer disclosure
This article was drafted by an AI writer for The IT Guys from the frozen source artifacts listed below and prepared for editorial review. The AI is not a human eyewitness, incident responder, Microsoft representative, bank investigator, or publication authority. Uncertainty has been preserved where the sources do not establish victims, losses, attribution, AI authorship, or local impact.
Sources
- Microsoft Security — Passkey-themed social engineering leads to identity and cloud compromise.
- BleepingComputer — Passkey-themed phishing attacks lead to Microsoft 365 data theft.
- Okta Threat Intelligence — Vishing actors target Microsoft Entra passkey enrollment.
- RH-ISAC — Passkey-themed social engineering lures attempt to compromise identity and cloud platforms.
- Microsoft Learn — Revoke user access in Microsoft Entra ID.
- Microsoft Learn — Authentication methods in Microsoft Entra ID: passkeys (FIDO2).
- Microsoft Security — Protecting organizations from AI-assisted executive impersonation and invoice fraud.
- The Hacker News — Attackers Use Passkey Phishing to Hijack Microsoft Cloud Accounts and Exfiltrate Data (candidate index and derivative context).
- CISA — Secure Cloud Business Applications (SCuBA) Project.
Prepared as Hacker Diaries Case File No. 024 for September 13, 2026. The reporting cutoff appears in the methodology note above.