Session CRT-20260928 — 28 September 2026 · Afternoon Edition

Halil, the urgency is real, but don’t let “worldwide attacks” become “every exposed box is owned.” Fact: Citrix’s CTX697096 covers both CVEs, while Rapid7 reports active zero-day exploitation and notes that reliable exploitation carries high attack complexity. Unknown: the evidence available here does not establish the first observed attack timestamp, exact vulnerable/fixed build strings, or validated public IOCs. So the defensible exposure window is appliance-specific: from the later of vulnerable-build installation or first external reachability, until the fixed build was verified active on every serving node. Use CTX697096—not product name or CVSS—to determine build membership tonight.

Tonight’s decision tree:

• Build outside CTX697096’s affected range: document the build evidence; no incident from these CVEs.
• Affected build, never reachable from untrusted networks: patch immediately and review internal access paths; exposure alone is not compromise.
• Affected build externally reachable during the window, but no positive evidence: preserve logs and available appliance state, patch, restrict management access, and hunt. Classify as potentially exposed, not compromised.
• Positive evidence of successful unauthorized execution or resulting state change: declare an incident, isolate the node, preserve evidence before destructive reboot/rebuild actions, rotate appliance-accessible secrets and sessions, and examine adjacent identity systems.

The minimum threshold is one credible fact showing the chain crossed from opportunity into execution: an appliance-spawned unauthorized process or command, an unexplained file/configuration/account change, an outbound connection correlated with exploitation, unauthorized session or data access, or integrity/log tampering. Scans, exploit requests without demonstrated success, Internet exposure, and a vulnerable version are warning lights—not proof the engine caught fire. Hunt for process anomalies, unexpected files and persistence, configuration drift, unauthorized administrative activity, outbound network traffic, session misuse, and missing or altered logs; absent published validated IOCs, a clean signature scan cannot close the case.

The hard boundary is this: patching removes the CVE entry path; it does not remove code or persistence already established. CISA lists CVE-2026-65660 as exploited, while NVD describes network-reachable code injection by an authorized attacker. I have no validated campaign-specific webshell filename, hash, mutex, or payload lineage, so defenders should not reduce this hunt to IOC matching.

Artifacts that can survive patching — hunt assumptions, not confirmed campaign IOCs:

• ASPX or managed-code payloads in SharePoint/IIS directories, including renamed or timestomped files.
• Persistence outside the webroot: services, scheduled tasks, autoruns, startup scripts, modified assemblies, or unauthorized administrative accounts.
• Credentials, certificates, application secrets, or signing/encryption material copied before remediation.
• In-memory payloads and attacker processes that remain active until IIS services or the host are restarted.
• Modified configuration and deleted or truncated logs. Preserve evidence before recycling application pools or running cleanup tools.

Highest-value telemetry, in order: first, EDR process ancestry showing w3wp.exe or SharePoint service processes spawning shells, PowerShell, script engines, LOLBins, or previously unseen executables; second, IIS access logs correlated with file-creation timestamps and authenticated identities; third, filesystem metadata and hashes across all web front ends; fourth, SharePoint ULS logs; then PowerShell Script Block/Module logs, Windows Security/System/Task Scheduler logs, service creation, account changes, and outbound connections from IIS workers. A webshell by itself proves server-side execution, but the process tree and security logs establish what happened after the first opcode landed.

Short hunt plan: verify at least SharePoint 2016 build 16.0.5565.1001/KB5002905, 2019 build 16.0.10417.20198/KB5002894, and Subscription Edition build 16.0.19725.20522/KB5002893; snapshot logs and disks; inventory every webroot and deployed assembly across every farm node; diff against a known-good baseline; hunt w3wp.exe descendants, new persistence, privileged account activity, and unusual egress; then rotate exposed credentials and secrets. Rebuild rather than clean when there is confirmed code execution plus persistence, privileged or secret access, integrity-sensitive key theft, unexplained binaries/assemblies, log destruction, or incomplete telemetry. If execution is disproved with continuous evidence and only exploit attempts are present, patching and monitored retention may be sufficient.

Halil, chronology matters: the September 26 reporting already described /%50SEMHUB/ WAF evasion, Java deserialization, x.jsp/u.jsp web shells, SIDEEYE, Neo-reGeorg, MeshAgent, and multi-sector compromises. Assessment: today’s HCA item adds a renewed-attack headline, but no visibly independent exploit reproduction, infrastructure pivot, new IOC, or victim confirmation. Confidence is high that exploitation occurred, moderate in the exact bypass chain, moderate for the UNC6240 label, low for equating it conclusively with ShinyHunters, and low for “dozens” of victims or separate FBIJobs data-theft claims.

The single-source update does not justify declaring a new wave or confirmed compromise. It does justify more than patching for systems that were internet-facing while vulnerable: preserve and review logs for encoded PSEMHUB requests, hunt for JSP web shells and persistence tooling, and rotate credentials exposed to PeopleSoft. That maps most firmly to T1190 Exploit Public-Facing Application and T1505.003 Web Shell; patching alone cannot remove pre-existing access.

TrustSink: The crossed boundary is Entra’s authentication control plane. An attacker already holding Global Administrator or Authentication Policy Administrator privileges registers an attacker-controlled external authentication method and supporting application/service principal; Entra then trusts that provider’s signed response. This is post-compromise credential harvesting, not an initial Entra authentication bypass. Evidence should exist in Entra audit logs—particularly “Add external authentication method” and “Update authentication methods policy,” plus application, service-principal, consent, and group-assignment changes. Sign-in logs can correlate affected users, but cannot show what they typed into the provider’s page. Tonight’s control: disable every unapproved external authentication method and remove its associated application/service principal. Then treat exposed users as compromised and revoke sessions and refresh tokens—not merely rotate passwords.

Reported WhatsApp chain: The claimed boundary is different: unauthorized synchronization allegedly establishes a parallel WhatsApp account session without normal QR pairing or a visible companion device. Reported forensic evidence includes unusually frequent WhatsApp “resync” events, ImageIO-related errors in iOS unified logs/sysdiagnose, and unauthorized payment-request messages; victims reportedly saw nothing suspicious under Linked Devices. But the public evidence is too thin to claim a generally reliable zero-click chain across enterprises: it rests largely on a limited forensic report and derivative reporting, without enough public validation to establish prevalence, exact exploit reliability, or that every reported takeover used the proposed CVE chain.

For immediate payment-fraud reduction, enforce out-of-band approval for every payment request received through WhatsApp, using a previously registered telephone number or corporate payment workflow—not a reply or call initiated inside the same potentially compromised account. Updating affected iPhones remains important, but independent transaction verification breaks the fraud path even where the exact account-linking mechanism remains uncertain.