Session CRT-20260724 — 24 July 2026 · Morning Edition

Halil, the operators who should treat themselves as exposed tonight are the ones with PLC-native services reachable from the internet: Rockwell EtherNet/IP on 44818/2222, Siemens S7 on 102, Schneider/Modbus on 502, or modem/remote-admin paths like SSH on 22. CISA/IC3 says Iranian-affiliated actors are targeting internet-connected OT and PLCs, using vendor engineering software including Studio 5000, EcoStruxure Control Expert, and Siemens TIA Portal. Rafael’s outside-in read matches that: if your “remote access” is really a public PLC, cellular modem, VNC/HMI, or unmanaged vendor path, assume you are discoverable tonight — especially U.S. water/wastewater, energy, government/municipal, and other small critical infrastructure operators.

Separate the risk by Purdue level. Direct PLC exposure is Level 1/2 risk: unauthorized online edits, malicious project downloads, forced outputs, changed setpoints, alarm suppression, or bypassed shutdown/interlock logic can become a physical safety event. Level 2–4 compromise is different but still dangerous: an engineering workstation, HMI, historian, or SCADA server may not directly move a valve, but it can hide bad process state from operators or become the staging point for a later logic download. The evidence I would prioritize is: unexpected PLC upload/download events, project-file extraction, checksum or logic mismatch against last-known-good, engineering software used from unknown hosts, HMI/SCADA screens disagreeing with field indicators, alarm/shutdown functions disabled, or “temporary” forces left active.

Containment that is generally safe tonight: block inbound internet access to PLC-native ports at the upstream firewall/ISP edge, disable unauthenticated vendor dial-ins, require VPN/jump-host access with MFA for engineering tools, put affected controllers into a mode that prevents remote programming where the process permits it, freeze logic changes, and take read-only backups/exports for comparison. Do not hot-patch, reboot PLCs, or yank OT network links blindly during production. Any segmentation change that could affect HMI-to-controller or safety-system communications needs engineering validation first — a broken safety PLC path can be worse than the cyber risk you are trying to reduce.

Halil, my ranking is:

1. Check Point CVE-2026-16232 — Highest feasibility and cleanest kill-chain closure. The reported primitive is ugly: unauthenticated remote attacker gets an application login token and lands as admin on the Security Management Server. If that box was internet-reachable and not tightly restricted, assume management-plane compromise before patching: policy changes, admin permission changes, VPN/config tampering, and log manipulation.

2. SonicWall SMA1000 — Also nasty. The reported chain is not just “a bug”; it closes: SSRF via /wsproxy, access to an Erlang service with a hardcoded auth cookie, then root-level execution through the hotfix-removal path. If exposed, assume appliance compromise, credential theft, session harvesting, and TOTP seed exposure. Patching alone is like changing the lock after someone copied the keys.

3. Zimbra CVE-2025-66376 Classic UI — Very feasible for mailbox theft: zero-click stored XSS where rendering a malicious email in an authenticated session runs attacker JavaScript. Assume mailbox access, address book theft, browser-saved credential targeting, and 2FA recovery-code collection. I rank it below Check Point/SMA because the evidence here closes cleanly to data and identity theft, not necessarily server takeover.

4. FortiSandbox KEV item / GlobalProtect CVE-2026-0257 — I’m not going to fake precision. The evidence visible here supports FortiSandbox as a KEV-listed enterprise appliance exposure, but not the exploit primitive. I don’t have source-backed detail here for GlobalProtect CVE-2026-0257. So operationally: treat exposed instances as suspicious, but do not rank them above the three chains where we can see the attacker path close.

Before patching: Check Point and SonicWall exposed? Assume compromise. Zimbra exposed with Classic UI? Assume mailbox and identity material theft. Preserve logs first, snapshot configs, rotate affected credentials/session material, then patch. Not the other way around.

Halil, I’d split it this way:

• LAUNDRY BEAR / Void Blizzard against Zimbra: attribution is strong enough to prioritize. CISA and partners name Russian state-supported actors, tie them to Zimbra targeting since at least July 2025, and describe a view-based exploit plus persistence and credential collection. ICD 203 confidence: high for campaign continuity; prioritize exposed Zimbra, mailbox/session persistence, and mail-exfil hunts now.

• Kimsuky / APT43 / MITRE G0094 against South Korean software and groupware providers: strong enough for targeted sectors, but not universally. ENKI tracks the campaign from 2025 into early 2026, with spear-phishing/vulnerability exploitation and Gomir deployment; MITRE lists Gomir as uniquely associated with Kimsuky operations. Confidence: high for G0094 linkage where Gomir is present, moderate for broader downstream compromise absent IOCs.

• Iranian-linked PLC activity: stay actor-agnostic operationally. CISA/FBI report Iranian-affiliated actors accessing internet-facing PLCs and causing HMI/SCADA disruption, including ATT&CK ICS T0883 Internet Accessible Device. Confidence: high on behavior and OT risk, moderate on broad Iranian affiliation, too low for a more specific actor call.

James’ control-order point is right: don’t let the flag drive the first 48 hours. Decision today: inventory and remove internet exposure for Zimbra and PLC/HMI/SCADA first; then hunt by behavior—Zimbra mailbox persistence/exfiltration, OT engineering-protocol access, and Gomir/Linux server persistence—not by actor name alone.

Halil, the sequencing matters: patching is step zero, not recovery. For Zimbra, the relevant trust issue is mailbox/session-token abuse in the zero-click phishing/webmail case involving Laundry Bear. For Check Point Security Management / Multi-Domain Security Management, it is SmartConsole administrative tokens in the CVE-2026-16232 exploitation context. For SonicWall, GlobalProtect, malicious OAuth apps, AgentForger, and bridge validator keys, I’d keep the response at the artifact level rather than pretending the mechanics are identical.

Tonight’s CISO order should be:

1. Stop new trust issuance first. Put exposed Zimbra, VPN, firewall management, OAuth-consent, agent-registration, and bridge-validator control planes into emergency change mode. Disable new OAuth app consent, new workspace-agent enrollment, new admin-token issuance, and new validator signing where feasible.

2. Patch and isolate, but assume existing trust is dirty. For Zimbra and Check Point specifically, do not let teams say “we patched” and move on. Force logout of active mailbox/admin sessions, revoke exposed or suspicious session tokens, rotate admin credentials, and review privileged account creation and mailbox-rule changes.

3. Revoke by artifact class, not by username.

   • Zimbra: invalidate mailbox sessions/auth tokens; reset affected mailbox passwords; remove malicious forwarding rules, app passwords, delegated mailbox grants, and persistence rules.
   • Check Point SmartConsole: kill active administrative sessions/tokens; rotate admin passwords and API credentials; review newly created admins, policy pushes, and management-server changes.
   • SonicWall / GlobalProtect: reset credentials, revoke sessions, rotate VPN secrets, and treat MFA seeds as credentials — re-enroll factors if seed exposure is plausible.
   • Malicious OAuth apps: revoke app consent grants, refresh tokens, service principals, client secrets/certificates, and conditional-access exclusions.
   • AgentForger-style rogue agents: delete rogue agents, rotate workspace enrollment tokens, invalidate agent certificates/API keys, and require re-attestation.
   • Bridge validators: rotate signing keys via the chain’s approved governance/emergency path; remove compromised validators; verify no queued signatures or pending transactions remain trusted.

4. Rebuild trust with stronger issuance rules. For humans: phishing-resistant MFA, preferably FIDO2/passkeys, especially for admins and VPN users. For services and agents: short-lived workload identity, certificate-bound tokens where supported, no static API keys, and explicit re-enrollment after compromise.

The board-level demand is simple: “Show me the revocation evidence.” Not the patch ticket. Not the password-reset count. I want proof that sessions, refresh tokens, OAuth grants, admin tokens, MFA seeds, agent credentials, and signing keys were killed or reissued.