Session CRT-20260808 — 8 August 2026 · Morning Edition

N-able is the one I would treat as presumed compromise tonight. Not “patch when convenient.” The handoff evidence says CVE-2026-18577 was exploited to reach customer networks, and CVE-2026-18556 zero-day exploitation is targeting MSPs. That closes the chain: management plane → admin capability → downstream customer reach. If the Cloudflare Tunnel persistence and second mandatory hotfix are in scope as described, then patching alone is not enough; assume the burglar may still have a side door. Isolate N-central, apply the second hotfix, revoke/rotate N-central and Take Control credentials, review customer-side admin actions, and hunt for tunnel binaries/services and new remote-access paths.

My urgency ranking after that:

1. TeamCity CVE-2026-63077 — presumed compromise if internet-exposed. Rapid7/JetBrains reporting describes unauthenticated RCE in TeamCity On-Prem via the agent polling protocol, with arbitrary OS command execution as the TeamCity server process. That is CI/CD root-of-trust territory. If exposed and unpatched, assume credential theft and pipeline tampering until proven otherwise.

2. Metabase SQLi — presumed data compromise where exposed and vulnerable. The handoff says this zero-day was exploited in customer data-theft attacks. This is less “own the whole enterprise” than TeamCity, but the objective is already proven: data theft. Patch, then review queries, exports, API tokens, database creds, and unusual access paths.

3. Tomcat CVE-2026-34486 — presumed compromise only where exposed and matching affected conditions; otherwise emergency patch-and-hunt. The evidence says it was added to CISA KEV after active exploitation. KEV means real exploitation, not lab drama. But I don’t have enough visible detail here on exploit preconditions, so I won’t rank it above TeamCity/N-able without the attack path.

4. WinRAR CVE-2025-8088 — patch-and-monitor broadly; presume compromise where suspicious archives were opened. The handoff says it is actively exploited in ransomware attacks, so it matters. But the chain usually needs file delivery and user/archive handling. That is dangerous at scale, but not the same as an exposed management-plane RCE.

Bottom line: N-able and exposed TeamCity get assume-compromise tonight. Metabase gets assume data theft if exposed. Tomcat gets KEV-driven urgent action, with scope depending on exposure. WinRAR gets aggressive endpoint patching and phishing/archive triage, not blanket infrastructure compromise.

Halil, the headline labels are doing too much.

• N-able N-central CVE-2026-18556: attribution confidence low. The evidence supports active zero-day exploitation targeting MSPs; it does not support a named actor from what we have here. Campaign continuity is unclear. Defenders should avoid actor-chasing and treat this as an MSP blast-radius problem: internet exposure, patching, identity/session review, and downstream customer access.
• Water PLC activity: operational confidence high, actor confidence moderate for Iran-linked activity, low for any specific group. The stronger pattern is exposed Rockwell/Allen-Bradley PLC access and use of engineering pathways; don’t overfit to “Iranian hackers” unless we get infrastructure, tooling, or operator overlaps.
• Storm-2945 / CaptiveCrunch: attribution confidence high to Microsoft’s Storm-2945 campaign label, moderate to broader Midnight Blizzard/APT29 linkage unless corroborating pivots are shown. Continuity is strong: compromised hotel/captive-portal Wi-Fi, DNS/HTTP manipulation, Microsoft 365 credential theft, and RAT delivery fit one coherent campaign. Defenders should hunt the captive-portal/AiTM pattern, not the nationality label.
• TeamPCP: attribution confidence low-to-moderate. The evidence supports a reported linkage between Redis attacks and later cloud supply-chain activity, but the source-family signal is thinner than Storm-2945. I would not tune defenses around “TeamPCP”; tune around exposed Redis, cloud credentials, CI/CD abuse, and package/build-chain telemetry.

I don’t materially disagree with critical for water, Storm-2945, or N-able. I’d place TeamPCP last until we see independent infrastructure pivots, malware lineage, victim telemetry, or repeated TTP overlap across unrelated sources.

Halil, the pattern is reusable trust artifacts. The N-able case is the clearest trust-chain break: according to Help Net Security and Rapid7, CVE-2026-18577 is an N-central authentication bypass exploited in the wild that let attackers gain administrative control, use Take Control to reach managed endpoints, and in some cases maintain access with Cloudflare Tunnel after N-central access was revoked. That means CISOs should not treat RMM as “inside the boundary.” MSP admin access should be assumed equivalent to customer-domain privileged access.

On the traveler/phishing side, the evidence lines up: Storm-2945/CaptiveCrunch compromised hotel or captive-portal Wi-Fi flows to redirect users into Microsoft 365 phishing/device-code flows or fake updates, with CornFlake able to steal credentials, cookies, and Microsoft 365 session tokens. The Microsoft 365 AiTM reporting points to payroll and finance mailbox access, and the Greatness PhaaS item abuses RingCentral-themed trust to steal Microsoft 365 tokens. So the decision is: password reset is not enough. Revoke active sessions, refresh tokens, device-code grants, OAuth consent grants, and mailbox delegation; then rotate credentials.

My CISO call today: shorten refresh-token lifetimes for high-risk roles, enforce sign-in risk and device-compliance conditional access, block or tightly govern device-code auth, require phishing-resistant MFA — FIDO2/passkeys or certificate-backed device auth, not SMS/push — and freeze new device registration during suspected compromise. For Windows Hello for Business key abuse specifically, I cannot confirm the abuse technique from the public discussion, so I would not overstate it; operationally, still audit newly registered WHfB keys/devices, remove unrecognized credentials, and require step-up/admin approval for new key enrollment after an incident.

For payments, assume the mailbox is not the control point. If AiTM gets a payroll or finance session token, inbox rules and approvals can be manipulated from a “valid” session. Require out-of-band payment verification, dual approval outside email, impossible-travel/session anomaly review before payroll changes, and hard separation between MSP/RMM admin paths and customer payment workflows.

Halil, my safety-first sequence is: stabilize the water process before “fixing” the cyber problem. CISA says Iranian-affiliated actors accessed internet-facing Rockwell Automation/Allen-Bradley PLCs and interacted with project files and HMI/SCADA displays; Censys separately reports thousands of Rockwell/Allen-Bradley EtherNet/IP exposures on port 44818, heavily concentrated in the U.S. So if a municipal utility has port 44818 exposed, treat this as Level 1/2 control equipment reachable from Level 5 internet, not as a normal IT alert.

Today’s sequence should be:

1. Put eyes on the process locally first — tank levels, pump status, chemical feed, valve positions, alarms, and any chlorine/pressure/flow readings. If the HMI is suspect, verify at the instrument, panel, or local operator station.
2. Safely isolate internet exposure — block inbound EtherNet/IP/44818 at the perimeter, disable exposed cellular modem forwarding, and remove public access to PLCs. Do this in a way that does not cut required plant telemetry or safety communications.
3. Preserve evidence before changing controller state — capture PLC mode, running logic checksum/project comparison if available, HMI screenshots, engineering workstation logs, firewall/NAT/VPN logs, and any recent Studio 5000 activity.
4. Then do engineering checks — compare running logic to the last known-good offline project, inspect reusable code modules/add-on instructions, verify setpoints, interlocks, alarm limits, comms paths, and controller task schedules.
5. Rotate credentials after access is contained — VPN/vendor remote access, cellular router, firewall, Windows/engineering workstation local admin, HMI/SCADA accounts, and any Rockwell software or controller-related credentials. Don’t rotate in a way that strands operators during an active water process.
6. Notify early — CISA/FBI plus the state water authority or emergency management channel. The point is not paperwork; it is getting IOCs, help with logic review, and coordination if multiple utilities are being hit.

What I would not touch immediately: do not power-cycle PLCs or HMIs casually, do not download/upload logic blindly, do not flash firmware, do not “factory reset” controllers, and do not wipe the engineering workstation before evidence is captured. A bad reset can turn a recoverable intrusion into loss of control history — or worse, interrupt pumping, treatment, or safety interlocks.

The Iran-backed framing matters for urgency and coordination, but it does not change the plant-floor defensive plan. Whether the actor is Iranian-affiliated or criminal, the immediate problem is the same: exposed control equipment, possible unauthorized logic/HMI interaction, and operators who must keep safe water and wastewater service running. Attribution should drive federal reporting and intelligence sharing; it should not tempt anyone into rushed OT changes that create the outage the attacker wanted.