Session CRT-20260924 — 24 September 2026 · Morning Edition

Halil, the dividing line is appliance integrity. Hotfix-and-hunt applies when the BIG-IP actually uses the vulnerable combination—an APM access policy plus OAuth authorization-server profile—but telemetry is intact and retrospective review finds no correlated exploitation signals. Install F5’s engineering hotfix, or the temporary iRule only as a bridge, then hunt. Immediately isolate and preserve the appliance when OAuth invalid_token bursts or rising total_failed counts coincide with TMM crashes/core files, suspicious audit-log commands, unexplained configuration changes, or missing telemetry during the exposure window. A request burst alone is weak evidence; command execution, persistence, or an unexplained logging gap on an exposed affected system crosses my rebuild threshold. This is unauthenticated, data-plane RCE. If execution occurred, patching is like changing the lock after someone copied every key.

Practically, MikroTrick has more preconditions: exposed RouterOS SSH, knowledge of a valid username, and the public modulus of that user’s authorized RSA key. But once those conditions exist, the second flaw closes the chain to administrative control; unauthorized privileged accounts and configuration changes have already been reported on compromised devices. BIG-IP is the easier initial-access proposition, although only on that specific APM/OAuth configuration. MikroTrick is narrower but gives a clearer end-to-end takeover path.

My default 24-hour order is: 1) affected, reachable BIG-IP APM; 2) internet-facing on-premises VeloCloud Orchestrator; 3) RouterOS with publicly exposed SSH; 4) GitLab pending identification of the exact issue and affected configuration. Any MikroTik showing a new privileged account or unexplained configuration change jumps immediately to isolation-and-rebuild. VeloCloud earns second place because active exploitation is reported, but the available evidence does not expose the exploit primitive, prerequisites, indicators, or persistence behavior. I found no sufficiently specific evidence here identifying the GitLab CVE or its attack chain, so ranking it higher would be guesswork.

The source-pack order could be wrong if exposure counts differ materially, if F5’s exact OAuth configuration is rare, if MikroTik usernames and RSA public keys are easily harvestable, or if VeloCloud/GitLab exploitation is authenticated, unreliable, or limited to targeted deployments. We also lack exploit success rates, victim counts, PoC quality, exploitation start dates, and IOC sensitivity. Those facts—not CVSS—could reorder the queue within hours.

The evidence makes both Graphalgo and MemTensor identity incidents, not merely poisoned-package incidents. Graphalgo’s malicious Terraform providers execute during initialization with the deploying user’s privileges; associated Go modules and earlier npm activity share infrastructure. That potentially exposes cloud CLI credentials, Git/SSH tokens, Terraform state and production access. MemTensor’s compromised npm/PyPI releases delivered sckit, which targets npm, PyPI, GitHub, GitLab, AWS, Vault and SSH credentials; investigators suspect compromised GitHub Actions publishing tokens. In cloud terms, the package is only initial access—the blast radius is the complete trust graph reachable from the process identity.

The minimum credible method is: identify every workstation, runner and workload where a malicious version executed or was imported; establish the execution window; then enumerate what that process could read or request. That means developer credential stores and environment variables, CI secret contexts, workload identities and OIDC tokens, instance profiles or managed identities, Vault paths, local and remote Terraform state backends, and npm/PyPI publishing rights. For each recovered principal, calculate effective permissions, role-chaining and cross-account trust, then examine cloud audit, source-control, CI and registry logs from first execution through containment. Do not rotate an entire tenant reflexively: rotate every credential class accessible to the compromised process and every downstream credential it could mint or assume.

A clean rebuild is mandatory where the malicious code executed, persistence cannot be excluded, a self-hosted runner was involved, or a release workflow produced artifacts after compromise. Reimaging only the developer laptop is inadequate if its principal could modify CI workflows or package releases. Broad rotation becomes mandatory—meaning all credentials reachable from affected identities, potentially across accounts—when sckit ran, cloud/Vault/admin credentials were readable, package-publishing rights were exposed, unauthorized releases occurred, role chaining reached privileged identities, or logging cannot demonstrate non-access. Revoke active sessions and federated credentials before issuing replacements, or the attacker gets the refresh before the engineers do.

For tonight, I would first spend capacity on package/version inventory and isolation across developer and CI estates because these campaigns can propagate through release identities. In parallel, inventory Ubuntu container nodes. The available reporting describes CVE-2026-80521 as an unpatched AF_UNIX flaw with a public exploit capable of host-root container escape; any affected node running untrusted or already-compromised containers should be cordoned, drained and remediated immediately. That issue is narrower but catastrophic per node; Graphalgo/MemTensor can cross repositories, registries and cloud accounts. Exact affected Ubuntu releases and exploit prerequisites are not established in the evidence here, so capacity should follow confirmed exposure. Shared responsibility is also different: customers own compromised IAM, CI secrets, worker-node configuration and package trust; CSP responsibility depends on whether the vulnerable kernel belongs to customer-managed nodes or a provider-managed runtime.

The strongest supported fact is the campaign pattern: CISA says actors modified PLC passwords, changed device IP addresses, locked out operators, and in some cases forced boil-water notices and sustained manual operation. CISA also attributes access to Iranian-affiliated actors targeting internet-facing Rockwell/Allen-Bradley, Schneider Electric, and Siemens PLCs. But the available reporting does not independently establish that the Georgia pressure loss was caused by an attacker rather than coincident equipment failure or loss of supervisory access. That remains an unknown causal link. (CISA advisory, CISA water-sector alert, Gizmodo)

To prove process disruption at Level 1, investigators need a synchronized timeline showing: an authenticated or network-recorded controller change; a resulting change in pump commands, VFD state, valve position, setpoints, or control logic; and then a matching pressure decline confirmed by independent field instruments, flow meters, tank levels, and electrical load. A changed PLC IP followed only by an unreachable HMI is evidence of loss of Level 2 operator visibility, not proof that the physical process changed. Conversely, breaker trips, VFD fault codes, loss of utility power, mechanical pump alarms, leaks, or a pressure decline preceding the cyber event would favor ordinary equipment failure. Preserve the PLC image and project file, controller diagnostics, historian tags, HMI alarms, engineering-workstation activity, firewall/VPN/cellular logs, and physical maintenance records before resetting anything.

The reported infostealer exposure associated credentials with 1,787 water providers. That materially widens the initial-access problem, especially for remote-access portals, vendor accounts, email, and engineering support systems—but it is exposure evidence, not proof that those credentials reached a PLC or caused pressure loss. Operators should immediately identify affected identities, reset passwords, revoke active sessions and tokens, rotate shared/vendor credentials, and review authentication from unfamiliar infrastructure. Remote OT access should require a controlled jump host and MFA rather than direct device exposure. (SpyCloud, Cryptonomist)

For safety and continuity, move affected stations to verified local or manual control under existing operating procedures; increase independent pressure, tank-level, and water-quality checks; remove direct internet reachability to PLCs; block observed hostile infrastructure; and verify a known-clean controller backup, as CISA recommends. Do not casually reboot, flash, or re-address a running controller: first confirm the fallback control path and test any segmentation change, because severing legitimate Level 1 communications can create the very loss of control we are trying to prevent. These actions are necessary regardless of whether attribution ultimately holds.

Halil, the source pack overstates attribution confidence:

• Water-PLC incidents: disruption of U.S. water PLCs is reported, but the pack provides one secondary source and no named group, infrastructure pivots, or corroborating evidence. Iranian affiliation: low confidence. Do not infer Iranian state direction from disruptive intent alone.
• Graphalgo: the malicious Terraform-provider supply-chain activity is strongly reported and maps to T1195.002 (Compromise Software Supply Chain). The evidence shown does not establish a North Korean operator or state tasking. North Korean linkage: low confidence.
• UTA0565: the Chrome/Windows chain is well enough supported to treat as observed exploitation, mapping to T1566.002, T1203, and potentially T1068. Volexity reportedly found the same exploit kit among multiple China-aligned clusters, but shared tooling establishes ecosystem overlap—not actor identity. China alignment: moderate confidence; organizational or state attribution: low confidence.

The most consequential unsupported inference is that shared campaign mechanics prove state control—especially the North Korean label on Graphalgo. Tonight’s actions should follow behavior, not flags: isolate Internet-exposed water controllers, audit Terraform providers and CI credentials, and patch/hunt affected Chrome and Windows systems. Those conclusions are strong enough for action; none of the three national-attribution claims should change response scope tonight.