Session CRT-20260806 — 6 August 2026 · Afternoon Edition

Halil, ranked for tonight:

1. N-able N-central — assume compromise first, not just patch. The evidence is already past “patch fast”: CISA-listed active exploitation, reporting that attackers gained admin access, pivoted via Take Control into MSP-managed endpoints, targeted domain controllers, and installed a Cloudflare tunnel as a Windows service for persistence. That closes the kill chain. If an exposed N-central instance was vulnerable during the exploitation window, treat it like a stolen master key: isolate, preserve logs, rotate N-central/admin credentials, review downstream client access, and hunt for remote-control sessions and tunnel services.

2. JetBrains TeamCity CVE-2026-63077 — assume compromise if internet-facing or build-sensitive. CISA flagged active exploitation; reporting describes unauthenticated auth bypass plus OS command execution in the TeamCity agent polling protocol, with risk to stored credentials, configs, server state, and CI/CD pipelines. The move from “patch fast” to “hunt now” is any exposed TeamCity server, unknown patch timing, unexpected agent registration/polling activity, modified build configs, new tokens, suspicious build steps, or outbound traffic from the build server. CI is a factory floor; if the controller is hit, don’t just repaint the door.

3. Apache Tomcat CVE-2026-34486 — containment for clustered/exposed Tomcat, otherwise rapid targeted patch. Current evidence supports KEV/active exploitation and the technical path involves Tomcat cluster communication/encryption bypass behavior feeding unsafe deserialization conditions. The hunt-now trigger is narrower than TeamCity: Tomcat Tribes/cluster communication exposed or reachable from untrusted networks, affected 11.0.20-era deployment, evidence of malformed cluster traffic, unexpected Java process children, webshell indicators, or new outbound callbacks. If it’s a standalone non-clustered Tomcat with no exposed cluster channel, patch fast, but don’t burn the building down without telemetry.

Cisco FMC, Gitea, and WPMU stay quick-hit comparators unless we have the same three things: KEV/active exploitation, usable PoC or repeatable exploit path, and exposed management/application surface in your estate. I don’t have visible evidence here that they outrank the three above tonight.

Halil, the delta today is scale and access pattern. This is no longer “a few weakly managed water sites”; the handoff ties CyberAv3ngers-linked activity to 30+ Minnesota water/wastewater systems and at least seven U.S. states, with exposed cellular modem paths and unprotected PLC access leading to password changes, PLC program deletion, operator lockout, and manual/offline operations. LevelBlue separately notes the Minnesota campaign affected more than 30 systems and highlights internet-facing PLCs, HMIs, cellular modems, remote access, and third-party configurations as recurring weak points. Tenable says CISA observed increased PLC targeting in water/wastewater, including password changes that lock operators out and IP changes that disconnect PLCs, with no known public-health impact reported in that advisory context.

First 24 hours — safety first: put operators physically in front of the process, not just the HMI. Verify tank levels, pump status, chemical feed, lift station state, alarms, and water-quality readings locally. If automation is untrusted, move to approved manual procedures, but do not improvise around interlocks or safety logic. A false trip can interrupt water service; a missed trip can put unsafe water or sewage overflow into the real world. If there is any uncertainty on water quality, coordinate immediately with public health officials on sampling and boil-water decision thresholds.

Cyber containment: disconnect exposed cellular modems, vendor remote access, and public-facing PLC/HMI paths from the OT side in an OT-safe sequence. Do not mass-reboot PLCs or “patch now” on an IT timeline. At Purdue Level 1/2, first preserve the process state, then isolate. Rotate compromised remote-access credentials, block inbound access to PLC management interfaces, validate firewall rules between the OT DMZ and control network, and compare PLC logic against known-good offline backups before restoring automation. Any segmentation change must be tested or reviewed by controls engineers, because breaking legitimate PLC-to-HMI or telemetry paths can create the outage you are trying to prevent.

Evidence handling: before restoring from backups, capture PLC project files if still present, controller diagnostics, HMI logs, historian events, cellular modem logs, firewall/VPN logs, remote-access records, screenshots of lockout messages, changed passwords/IP settings, and timestamps of manual switchover. State fusion centers should collect a common incident template across utilities: affected equipment, access path, ISP/cellular provider, remote vendor involved, PLC/HMI vendor, changed credentials, deleted logic, and public-health status. Share that quickly with CISA, EPA, FBI, state emergency management, and neighboring utilities so this becomes a coordinated OT containment effort, not thirty isolated small-town incidents.

Halil, the containment line tonight is: freeze every developer trust path that can execute code until proven clean. For npm, block known poisoned versions of keyv, cacheable, flat-cache, file-entry-cache, and related packages using registry deny rules, lockfile overrides, and CI policy gates. CSA says this is still ongoing, and reporting from Expel/BleepingComputer says the Keyv maintainer GitHub account was hijacked, malicious releases were built through GitHub Actions, and npm provenance/signatures could still look legitimate. So don’t treat “signed” or “published by expected workflow” as clean.

Minimum viable plan:

1. Package blocking: immediately deny affected Shai-Hulud/ChainDrop versions from npm installs; force clean lockfile regeneration only after affected versions are enumerated; block install-time scripts for untrusted packages where feasible.
2. Rebuild criteria: any developer laptop, CI runner, container image, or build cache that installed affected packages must be treated as credential-exposed. Rebuild from a known-clean base, not just npm uninstall.
3. Developer endpoint checks: hunt for npm preinstall activity, Bun runtime drops, suspicious setup.mjs / Math_Symbol.js, unexpected GitHub repos used for exfiltration, and environment-variable scraping. Also check IDE/plugin exposure: Open VSX evil-twin extensions were harvesting developer and CI metadata, so extension inventories matter tonight.
4. Token rotation: rotate npm, GitHub, GitHub Actions, AWS, Kubernetes, Vault, SSH deploy keys, Stripe/Slack/API tokens found on exposed hosts or CI jobs. Revoke first, reissue second; don’t “rotate later” while poisoned runners still exist.
5. Team communication: tell engineering plainly: “Do not run fresh installs, do not publish packages, do not approve dependency bumps, and do not trust provenance alone until Security publishes the blocked-version list and rebuild status.”

The blast-radius question is still the hard part: the public figures vary — CSA reports more than 1,300 affected npm package versions, while other reporting says 400+ packages and roughly two billion monthly installs. Your source pack’s 444 packages / 2,000+ versions should be treated as the floor until your SBOM and lockfile inventory proves otherwise.

Halil, the decision tonight is not “reset passwords.” It is invalidate every reusable trust artifact that can keep authenticating after the user is gone from the keyboard.

For the items where we have grounded evidence in the handoff: N-able N-central is flagged as an actively exploited critical issue in the handoff, so the identity move is to revoke or constrain N-central admin sessions, local and directory-linked admin accounts, API tokens, MSP/customer delegated access paths, and any downstream RMM credentials pushed through N-central. If an attacker reached the admin plane, a password reset alone is misleading because the real asset is the administrative trust path into managed endpoints and tenants.

For Shai-Hulud, the handoff identifies an npm supply-chain worm involving automation secrets. Tonight’s revocation list is: npm tokens, GitHub/GitLab tokens, CI/CD secrets, cloud deploy keys, package-publishing credentials, webhook secrets, and any secrets exposed to build logs or runner environments. A user MFA reminder is almost irrelevant here; the attacker does not need to log in as the developer if they already have a publishing token or automation secret.

For the other named identity failures — Kali365 / Greatness Microsoft 365 token theft and device-code abuse, Pass-ta-key / Pass-the-Passkey against synced passkeys, n8n leaked API tokens, and AI platform API key theft — I do not have enough visible source detail here to assert campaign specifics. But the trust-artifact decision is still clear: revoke Microsoft 365 refresh tokens, device-code grants, OAuth app consents, session cookies, synced passkey registrations where compromise is suspected, n8n API tokens, workflow credentials, and AI platform API keys. Constrain re-issuance with conditional access, device compliance, token lifetime reduction, and phishing-resistant WebAuthn where humans are involved.

Where password reset is actively misleading: device-code phishing, stolen refresh tokens, stolen session cookies, leaked API keys, CI/CD automation secrets, and synced passkey abuse. In all of those, the attacker may continue authenticating without knowing the new password. The minimum tonight is: revoke sessions, revoke refresh tokens, rotate API keys, remove unauthorized OAuth grants, re-issue automation secrets, invalidate passkey sync trust where exposed, and force re-authentication with phishing-resistant factors — not SMS, not push fatigue, not “please be careful.”