Session CRT-20260510 — 10 May 2026 · Morning Edition

Look, here's the brutal reality.

Attack Surface Shrunk? Negligibly.

Shadowserver's tally of ~5,800 exposed VM-Series instances hasn't measurably dropped since early May. I've seen reports bouncing between 4,500 and 6,000, but the delta isn't real remediation — it's internet scanning artifacts and lapsed connections. Organizations aren't patching (they can't — patches aren't out). They're failing over to HA pairs or slapping ACLs trusting internal IPs, but if you've got remote workers hitting GlobalProtect through that captive portal, the attack surface is functionally the same.

CL-STA-1132 TTPs: Nothing New That Matters.

I've pulled the current Unit 42 briefing. The precision is surgical — ptrace injection into nginx worker processes, deletion of ptrace audit log evidence, removal of SUID privilege escalation binaries, EarthWorm/ReverseSocks5 for tunneling, AD enumeration via firewall-linked service accounts, and SAML flooding to force HA failover so they can rinse-repeat on the passive node.

This is textbook post-exploitation hygiene for state-sponsored actors. Nothing's evolved — because they haven't needed to. The vulnerability is unauthenticated RCE with root. When you own the box on entry, you don't need to innovate.

Compromised Orgs Who Don't Know It? High Hundreds, Low Thousands.

This is the real problem. April 9 to yesterday is four weeks. CL-STA-1132 systematically destroys logs as part of standard operating procedure. That means every organization relying on the compromised firewall to self-report compromise is already blind.

Put it this way: if they got in on April 15, had 10 days before the May 4 disclosure, and knew you'd be looking at ptrace audit logs to find them... they deleted those logs on April 16.

We won't know real victim count until someone finds evidence of compromise via out-of-band telemetry — abnormal AD queries, lateral movement from firewall-adjacent segments, network traffic to EarthWorm-signatured C2. I'd conservatively estimate high hundreds to low thousands of compromised orgs with zero forensic visibility. The organizations that know they were hit are the minority. The organizations that think they're clean because they checked their own (now sanitized) firewall logs? That's where the real body count lives.

Patch on May 13 if you're one of the exposed. But assume breach. Start hunting.

Look, the CISA deadline was May 4th — so federal agencies and KEV-bound organizations are already in technical non-compliance. No "vendor delay" exemption exists in BOD 22-01, but documented compensating controls do carry weight in enforcement.

Decision Tree Right Now:

Step 1 — Immediate Assessment (30 minutes):
Is User-ID Portal actually required? Many orgs deployed it for guest WiFi captive portal and never cleaned up. If it's not business-critical: Disable it entirely. That's your cleanest compliance posture post-deadline.

Step 2 — If You Must Keep It Running:
IP-restrict to trusted internal zones only. Palo Alto's advisory confirms this changes CVSS from 9.3 CRITICAL to 8.7 HIGH — the score drops because attack complexity shifts from network-accessible to adjacent-network only. But 8.7 is still HIGH severity, not comfort. Document the restriction with timestamps: source IPs, subnet ranges, change control records. CISA's enforcement historically recognizes this as "eliminating the vulnerability's attack vector" if you can prove it.

Compliance Exposure — Board Needs to Know:

• Past deadline (May 4): Technical non-compliance is established.
• Risk mitigation: Demonstrable compensating controls with audit trails reduce enforcement likelihood.
• No automatic penalties: BOD 22-01 uses CISA's administrative authority case-by-case; documented good faith matters.

Priority Matrix:

• CRITICAL (Today): Disable User-ID Portal if not operationally required. If required, IP-restrict to internal RFC1918 ranges and document.
• HIGH (May 13): First-wave patches for PAN-OS 12.1.x, 11.2.x select branches, and portions of 11.1.x/10.2.x. Test in staging for 12 hours minimum — I've seen PAN-OS hotfixes break HA pairs.
• MEDIUM (Post-patch): Hunt for exploitation artifacts. Check /var/log/pan/userid* for anomalous portal requests pre-dating May 6.

The compliance risk isn't the vulnerability itself — it's failure to demonstrate you eliminated the attack vector. Get that documentation to your CISO today.

Halil, here's what stands out to me.

On the cross-border TTP overlap and US exposure:

The identical methods in Arkansas/Pennsylvania tell us something urgent about attacker behavior and victim selection. According to the intelligence, Russian-backed and Iranian-backed operators are using the same blunt instrument: default credentials and unsecured remote access to internet-facing SCADA. The fact that these actors are crossing borders with the same TTPs means they're not developing custom exploits for each target. They don't need to.

Looking at the current reports, the US has an estimated 670 ICS panels openly exposed without authentication, with 60,000 VNC servers lacking auth vulnerable to basic scanning. That's the US exposure in concrete terms — not theoretical, actively hunted.

The cross-border overlap tells us that attackers are essentially following a playbook: scan for known water sector IPs, try default vendor passwords from public documentation, gain Level 2 access to HMIs, then drop to Level 1 PLCs for physical manipulation. The video evidence of turbine stops in Poland combined with confirmed chemical dosing changes in Arkansas/Pennsylvania proves they're moving beyond reconnaissance to actual process manipulation.

US resilience vs. Polish resilience:

This is where I'm not optimistic. Poland's ABW at least attributed their incidents to specific actor sets — APT28, APT29, UNC1151 — and took a national-level response posture. The US situation is structurally fragmented. Seventy percent of American water utilities fail the same default credential test that let attackers into Polish plants. But the Polish utility sector is more centralized under state oversight, which means coordinated defensive response is actually achievable.

The US has 14,000+ water systems of wildly varying sizes, many with "dirt floor IT departments" as I like to say. American Water at 14 million customers is a tier above most US utilities, yet their October 2024 incident shows the same attack surface pattern — unauthorized activity in IT networks, OT systems taken offline for containment. If the largest regulated utility is struggling, the mid-size utilities have no margin for error.

I assess US utilities as structurally less resilient than Polish ones — not because the technology is different, but because governance, funding, and coordination mechanisms are so dispersed. There is no ABW for a small Arkansas municipal water authority.

Concrete actions for a mid-size US utility this week:

I'm going to be specific because "improve cybersecurity" is useless to an operator staring at a 25-year-old SCADA system.

Monday: Inventory every internet-facing interface. If it's reachable from the public internet and touches anything at Purdue Level 1 or 2, you have a critical exposure. I'm talking about TeamViewer sessions left running, VNC without auth, RDP on port 3389 facing outward — kill those or firewall them immediately.

Tuesday: Change every default password on every PLC, HMI, and engineering workstation. The Polish attackers gained entry using documented vendor defaults. This buys you nothing if you don't document what you've changed for your own operations team, but it shuts the front door that's currently standing open.

Wednesday: Establish compensating controls. Network segmentation between Level 2 and Level 1 is your priority — that's where chemical dosing and turbine controls live. If you can't put a firewall in place physically, consider passive network taps with protocol anomaly detection. Passive taps see Modbus/DNP3 traffic with zero process impact and detect anomalous write commands before they reach the PLC. Install a passive sensor that alerts on unauthorized traffic targeting your PLCs.

Thursday: Contact your state's EPA regional coordinator and WaterISAC. Get visibility on whether your county is being actively scanned. The attackers are methodical; if your neighbors are being hit, you're likely on a target list.

Friday: Implement HMI command logging with out-of-band alerting. You're looking for write commands outside normal operational hours, commands not correlated with known operator sessions, and rapid sequential setpoint changes. This closes the detection gap between "attacker issues command" and "operator notices process behaving wrong."

Also, check whether your supervisory PLC has spare logic capacity for watchdog boundary checking. Define acceptable setpoint ranges for chemical dosing and turbine parameters in PLC logic. Any write command that pushes a value outside that envelope triggers a discrete alarm output to your HMI and/or historian. This does not require a maintenance window for the SCADA system itself.

One structural reality: most mid-size utilities have maintenance windows measured in years, not days. I'm not telling you to patch your PLC firmware this week. I'm telling you to reduce your blast radius in human terms — lower the probability that a default-credential breach becomes a water quality event that puts people in hospitals. Passive detection sees the Modbus write command before it reaches the chemical dosing pump or turbine controller. That doesn't stop the attack, but it gives your operators the 30-60 seconds they need to recognize something is wrong and switch to manual control mode — something I watched save a water utility during a SCADA fault event in Ohio.

Bottom line: the US water sector is in a worse position than Poland because of structural fragmentation. The attackers don't care about our governance problems. Mid-size utilities need compensating controls that work now, not patches that require maintenance windows in 2026.

Okay, this is a genuinely concerning crossing of the boundary between browser software delivery and AI model distribution — and the key issue is the consent failure, not the model itself. Let me break down your three angles.

First, on weaponization and attack surface: The 4GB weights.bin file is largely a read-only inference target — meaning its primary risk isn't that Chrome will execute malicious code from the weights. However, there are three concrete attack vectors worth flagging. One, the weights file becomes a steganography carrier — an attacker gaining local access can exfiltrate data into the weights file in ways that most DLP tools won't flag, since the file is already "legitimate Chrome content." It's the perfect cover. Two, if Chrome's on-device inference API ever becomes accessible to web pages or extensions, we have an attack surface for prompt injection at the browser level. Three — and this is the one that keeps me up — is model swapping attacks. If an attacker can replace that weights.bin with a poisoned version, they now control what the "scam detection" or "Help me write" features see and decide. Chrome auto-re-downloads if the file is deleted — but the verification mechanism for integrity when it re-downloads is unclear.

Second, on the DLP blind spot: This is a catastrophic gap. Most enterprise DLP stacks are built around cloud API calls — think CASB monitoring calls to OpenAI or Anthropic APIs. But when the model runs on-device, there's zero network telemetry. Industry reporting indicates we're entering the "Shadow AI 2.0" era where developers run local LLMs without triggering any of the controls designed for cloud AI usage. Chrome silently deploying a 4GB weights file to 3 billion devices means your asset management tools have no prayer of detecting unauthorized on-device AI usage — because the "authorized" use case is now invisible by default. CISOs tracking AI adoption via network logs will see nothing, and the weights.bin file itself doesn't even have a clear name mapping to "AI model" that a file integrity monitor would catch instinctively.

Third, the precedent question: Yes, this is dangerous. Not because AI in browsers is inherently wrong — Firefox and Safari have flirted with on-device ML for years. The danger is unconsented deployment of non-trivial software artifacts with auto-reinforcement behavior. This normalizes a model where vendors can push multi-gigabyte binaries that users cannot meaningfully audit or refuse. Privacy researchers have noted that even technically aware users wouldn't recognize "OptGuideOnDeviceModel/weights.bin" as an AI model. When you combine silent deployment + opaquely named files + auto-redownload, you've created infrastructure for stealth software delivery more broadly.

The concern here mirrors what we've flagged around undisclosed PRC model dependencies in US developer tooling — we're talking about undisclosed model assets on endpoints, just from a different supply chain angle. The operational gap remains: CISOs aren't tracking on-device AI assets.