Session CRT-20261020 — 20 October 2026 · Afternoon Edition

Confirmed facts: Reporting links exploitation of CVE-2024-47575 in FortiManager to theft of configurations and credentials associated with more than 500 managed FortiGate devices. The attacker subsequently used CVE-2025-61624 for file manipulation and PEERSTITCH deployment. PEERSTITCH runs in memory, injects into miglogd and iked, avoids a listening port and persistent disk artifacts, while a separate mod_md path provided an SSH reverse shell; evidence was also erased. The handoff identifies CVE-2025-61624 and CVE-2026-102764 as KEV-listed, but the available reporting does not establish the latter’s precise exploit mechanics or affected-version boundaries. KEV is proof of exploitation somewhere—not proof that every exposed box was compromised.

Thirty-minute decision tree: 0–5 minutes: identify FortiManager-managed appliances, affected software, and current or historical management-plane exposure; block external management immediately. 5–15 minutes: preserve volatile state and collect off-device logs before rebooting. Check for unexpected configuration access/export, unauthorized successful sessions or administrators, unexplained policy changes, cleared logs, root activity, anomalous miglogd/iked behavior, and unexpected mod_md or outbound SSH traffic. 15–25 minutes: isolate any positive system and its managing FortiManager; enumerate every credential, VPN secret, API token, and private key stored on or distributed through them. 25–30 minutes: choose the recovery lane and notify incident response leadership.

My threshold: Patch and hunt in place only where the appliance was demonstrably not vulnerable during exposure, or where trustworthy off-device telemetry covers the entire vulnerable exposure window and shows no successful access, configuration theft, integrity change, or persistence signal. Isolate and perform a trusted rebuild when any such signal exists, when FortiManager itself was compromised, or when telemetry is missing enough that appliance integrity cannot be established. Rebuild from trusted media and a validated configuration—not a blind backup restore. Rotate credentials after isolation or rebuild so they are not immediately stolen again; rotate certificates when private keys were resident or accessible, and replace device/VPN identity material after confirmed root access. Patching a rooted firewall is like changing the lock while the burglar is still inside. But “every exposed appliance is compromised” overstates the evidence: exposure raises the investigation priority; compromise evidence—or an inability to establish integrity—crosses the rebuild threshold.

Halil, the trust failure was the update metadata and distribution path—not a client vulnerability. A client was likely exposed if it contacted AOMEI’s infrastructure during a brief tampering window and consumed either altered file. UNC7017 changed down_html.ini by incrementing the thrid build value and replacing the expected MD5, causing the client to accept and extract a redirected upgrade-now.zip. Separately, Notifycfg.ini could make ABNotify.exe execute content from AOMEI’s local html directory; during the six-minute July 16 window, it also referenced a remote file:// resource over WebDAV, potentially sending NetNTLMv2 authentication material to 8.210.84.56. Fetching metadata, downloading the ZIP, executing its loader, and leaking credentials are therefore four distinct exposure states.

To identify affected clients, correlate proxy, DNS, firewall, and EDR telemetry with the published tampering windows. Look for network activity from Backupper.exe or ABNotify.exe, access to 8.210.84.56, modified configuration values, and upgrade-now.zip or upgrade-now.exe under AOMEI’s cache or html directory. Published SHA-256 indicators include 6670ab3f...f6eec7 for the May 20 ZIP and loader hashes 11e576df...913ad, 9a58e8f4...a450, and b360b6db...ae21. Execution confidence requires process or forensic evidence: an AOMEI process launching upgrade-now.exe, hidden PowerShell, the reported Nitro PDF/Adaptix C2 chain, or corresponding Prefetch, Amcache, USN Journal, process-creation, and persistence records. Unknown: without AOMEI server-side access logs or retained enterprise egress telemetry, absence of those artifacts does not prove that a host never fetched the altered files.

Installing a clean AOMEI version is not sufficient by itself. It can restore application integrity only where evidence shows the malicious archive was never executed, remaining cached content is removed, and the replacement installer is independently verified. Once the loader ran, treat the host as compromised: replacing AOMEI does not remove downstream payloads or invalidate secrets. Likewise, a WebDAV authentication attempt creates a separate credential-recovery requirement even if no executable launched.

Tonight’s minimum is: isolate execution-positive systems and rebuild them from trusted media; suspend direct AOMEI updating, block the published infrastructure and outbound Internet WebDAV/SMB, preserve configuration, archive, filesystem, and EDR evidence, and hunt every AOMEI installation. Reset identities observed authenticating toward the actor infrastructure, rotate privileged/service credentials and accessible tokens on execution-positive hosts, and invalidate sessions. Resume distribution only through a controlled internal repository using an approved installer pinned by SHA-256, verified code signature, logged deployment, and independently signed provenance or attestation.

The AI changed tempo, parallelism, and adaptability—not the attack primitives. Wiz reports hundreds or thousands of actions per hour, rapid trial-and-error, and simultaneous operation across Kubernetes, cloud control planes, identity systems, and CI/CD. The underlying chain was conventional: exploit the exposed Kafka UI, execute from its Java process, harvest credentials, use valid service identities across AWS/GCP and development systems, create an administrator identity, stage data in a ConfigMap/repository or send it to webhook[.]site, then persist through a self-healing Kubernetes workload. AI made ordinary credential chaining machine-speed and harder to correlate; it did not invent a new IAM bypass.

The three actions I would authorize tonight are:

1. Quarantine the execution plane without immediately deleting it. Remove the Kafka UI and suspect namespace/workloads from ingress and egress, block the observed C2/exfiltration destinations, and suspend the controller reconciling the malicious workload. First preserve Kubernetes API audit logs, pod/controller manifests, ConfigMaps, Secrets metadata, ServiceAccounts, RoleBindings/ClusterRoleBindings, admission-webhook configurations, image digests, node/runtime logs, DNS and network telemetry. Killing one pod is theater if a Deployment, DaemonSet, operator, or GitOps controller recreates it.
2. Freeze the identity trust graph, capture it, then revoke from the outside inward. Preserve AWS CloudTrail and current role trust/permission policies, session context and access-key metadata; GCP Admin/Data Access audit logs and service-account IAM/impersonation bindings; Kubernetes token and RBAC relationships; and OIDC federation configuration. Then disable the newly created administrator, invalidate active sessions, revoke exposed workload credentials, rotate static secrets, and remove cross-account or service-account impersonation paths. Start with identities capable of minting or restoring other identities.
3. Pause CI/CD and GitOps reconciliation before cleaning repositories. Preserve source-control audit logs, commits, branches, deploy keys, webhooks, runner registrations, pipeline definitions, artifacts, GitOps application state, and the identities used to approve or synchronize changes. Disable suspect runners and deployment credentials, protect affected repositories read-only, and only then remove malicious commits and reconcile from a verified-good revision.

The CISO position is: declare a multi-control-plane identity incident, not merely a compromised Kubernetes pod. Nothing cited indicates compromise of AWS or GCP’s underlying control planes; the exposed application, workload identities, IAM/RBAC relationships, repositories, and GitOps permissions sit on the customer side of shared responsibility. CloudTrail alone will not reconstruct this—Wiz explicitly notes that relevant workload activity may not appear in cloud control-plane logs—so containment must preserve Kubernetes and developer-platform evidence before revocation destroys the session and trust-chain context.

The immediate safety question is whether operators can trust the local refrigeration state independently of the remote-management plane. Treat the refrigeration manager as Purdue Level 2: first verify actual case and cold-room temperatures with independent calibrated instruments, then compare compressor, valve, fan, defrost, setpoint, schedule, clock, and manual-override states against the last approved configuration. At the same time, test alarm generation, delay, acknowledgement, suppression, and routing locally—not only through the remote dashboard. Preserve logs before changing access, but disconnect direct Internet management, suspend remote vendor sessions, and admit support only through a monitored, time-limited path. Claroty recommends firmware R4.3.1 or later and restricting administration to trusted management networks or VPNs; any segmentation change must first be checked for dependencies so it does not sever essential controller or alarm communications.

Accept a controlled outage when operators cannot prove the local state, remote commands continue after the management path is isolated, displayed values disagree with independent measurements, unauthorized defrost or override states recur, or alarm suppression prevents reliable supervision. In that condition, trusting remote control risks uncontrolled warming—or unsafe equipment operation if outputs are being manipulated. A site refrigeration engineer should place the system in its documented local safe state and the food-safety lead should quarantine affected inventory. Do not perform an improvised power cut: the shutdown sequence must preserve compressor protection and any required local safety functions.

Evidence should be collected to separate the three hypotheses:

• Credential abuse: successful authenticated controller, VPN, or jump-host sessions using valid accounts from anomalous sources or times, followed by ordinary administrative actions, without pre-authentication exploit traffic. Identity and VPN records are needed; controller logs alone may not prove credential theft.
• Exposed legacy interface: direct Internet traffic to the controller management service, affected firmware, unauthenticated or malformed requests preceding configuration changes, and no corresponding valid login. The documented population of Internet-reachable AK-SM 800A interfaces makes this plausible, but exposure is not proof of exploitation.
• Upstream vendor compromise: correlated access across otherwise unrelated sites through the same vendor identity, certificate, support infrastructure, or tunnel—including affected sites whose controllers were not publicly reachable. Confirmation would require vendor-side authentication, session, administrative-action, and software-distribution records.

UNKNOWN: Available evidence does not yet identify which path was used, so operators should preserve controller, firewall, VPN, jump-host, and vendor-session telemetry rather than prematurely rebuilding or resetting devices.