Session CRT-20260819 — 19 August 2026 · Morning Edition

Halil, I assess this as one coordinated campaign of opportunity at moderate confidence—but not yet a proven campaign intentionally designed to cause physical harm. FBI/EPA link incidents since July 27 across at least seven states to internet-facing MicroLogix 1100/1400 PLCs; CISA reports the repeated password/IP-change lockout pattern, with pressure loss, flooding, boil-water notices, and sustained manual operations. That places initial impact at Purdue Level 1, with consequences reaching the physical process. The evidence establishes a common campaign pattern, but not common command-and-control, attribution, or safety intent.
FBI/EPA | CISA

Operators have three decisions today:

1. Can the process remain safely under remote control? Independently verify pressure, tank levels, pumps, and valves; move affected zones to approved local/manual operation if PLC state or operator access is untrustworthy.
2. Which access paths must be isolated now? Remove direct PLC internet exposure and contain indirect Level 2–3 paths—including engineering workstations and vendor access—without interrupting required control or safety communications. Validate segmentation changes before deployment.
3. How will recovery be sequenced? Preserve configurations and network evidence, compare logic/IP/passwords with known-good baselines, restore trusted credentials, and return one process zone at a time under operator supervision. Do not perform an IT-style reset or patch cycle while the plant is unstable.

What would disprove coordination: forensic timelines showing unrelated opportunistic scanners; no shared source infrastructure, accounts, tooling, or distinctive configuration changes; materially different initial-access methods; or credible evidence that separate actors independently exploited the same exposed devices. Because this playbook is simple, identical outcomes alone are not enough to prove central direction.

1. vCenter — lowest assume-compromise threshold. Shadowserver reports identified victims compromised through CVE-2026-59310. Assessment: an exposed, vulnerable vCenter during the exploitation window deserves incident handling, not patch-and-watch; it controls the virtualization estate. Decisive trigger: any unexplained persistence such as a malicious cron entry or reverse_ssh artifact means rebuild the appliance and rotate vCenter, SSO, service-account, and reachable ESXi credentials.

2. Windchill/FlexPLM. PTC published an observed command-and-control IP (216.152.148.54) and a custom C2 command-header indicator. Decisive trigger: evidence that this header reached the application—or unauthorized server-side code executed—means rebuild affected nodes and rotate application, database, integration, and service-account secrets. The Clop label does not establish Clop-scale exfiltration, ransomware deployment, or compromise of every exposed instance.

3. Exposed Macs. CISA lists CVE-2026-65400 as exploited; reported cases involved root access and Monero miners. Decisive trigger: a Screen Sharing event with session_username: root should trigger rebuild and rotation of local administrator credentials and credentials used from that Mac. Exposure alone warrants isolation and hunting, but its likely blast radius remains below an infrastructure controller or enterprise PLM server.

The verified picture is exploitation plus host artifacts. Ransomware deployment, mass Clop-scale theft, and named-actor attribution remain unverified here. Don’t let campaign branding outrun the evidence.

Halil, FACT: Wiz demonstrated a tenant-control failure: Entra’s Device Registration Service lets a holder of a compromised identity register a rogue device, potentially satisfying poorly designed device-based access policies. Wiz observed this in nearly one in seven environments over 90 days. That demonstrates abuse of legitimate tenant trust—not an Azure platform vulnerability. UNKNOWN: TheHatman’s claims remain allegations; the available reporting does not independently establish the acquisition path, affected tenants, or connect the claimed dataset to this device-registration technique.

Approve two changes tonight:

1. Create Conditional Access for the “Register or join devices” user action, requiring the phishing-resistant authentication strength—FIDO2/passkey or certificate-based authentication—not SMS or push approval.
2. Restrict device registration/join permissions to a dedicated enrollment group. Remove ordinary and privileged accounts unless enrollment is part of their role. Also verify that Microsoft 365 access policies require a managed, compliant device, rather than treating registration alone as trust.

Run these two Sentinel queries:

AuditLogs
| where TimeGenerated > ago(7d)
| where LoggedByService == "Device Registration Service"
| where OperationName == "Add device"
| extend UPN=tolower(tostring(InitiatedBy.user.userPrincipalName)),
         IP=tostring(InitiatedBy.user.ipAddress),
         DeviceId=tostring(TargetResources[0].id),
         Device=tostring(TargetResources[0].displayName)
| project AddTime=TimeGenerated, UPN, IP, DeviceId, Device, Result
| order by AddTime desc

let NewDevices =
    AuditLogs
    | where TimeGenerated > ago(7d)
    | where LoggedByService == "Device Registration Service"
    | where OperationName == "Add device"
    | extend UPN=tolower(tostring(InitiatedBy.user.userPrincipalName)),
             DeviceId=tostring(TargetResources[0].id)
    | project AddTime=TimeGenerated, UPN, DeviceId;
SigninLogs
| where TimeGenerated > ago(7d) and ResultType == 0
| extend UPN=tolower(UserPrincipalName),
         DeviceId=tostring(DeviceDetail.deviceId)
| join kind=inner NewDevices on UPN, DeviceId
| where TimeGenerated >= AddTime and TimeGenerated <= AddTime + 24h
| project AddTime, TimeGenerated, UPN, DeviceId, IPAddress,
          ResourceDisplayName, AppDisplayName, ConditionalAccessStatus
| order by AddTime desc

Halil, freeze potentially affected environments immediately, then restore only from a separately verified artifact. Version 1.82.6 is a rollback candidate—not automatically trusted. Use it only if its wheel hash matches a pre-incident artifact and its contents have been reviewed. Otherwise, deploy a later clean release after independently comparing source, wheel contents, provenance, and hashes. The confirmed failure is in the distributed PyPI artifacts; whether the maintainer account, build system, or publishing credentials failed remains unknown.

The evidence ladder is:

• Download: proxy, PyPI-mirror, or cache logs show retrieval. This does not prove installation.
• Installation: pip/image-layer records, SBOM, dist-info/RECORD, or filesystem evidence confirms the version. In 1.82.8, look specifically for litellm_init.pth; 1.82.7 placed the payload in proxy_server.py.
• Python execution: for 1.82.8, any Python interpreter start with that site-packages active may trigger the .pth payload—no LiteLLM import is required. For 1.82.7, evidence must show the malicious proxy module was imported or executed.
• Confirmed exfiltration: an IOC-domain connection alone proves contact, not stolen data. Require captured outbound content, equivalent endpoint telemetry, or subsequent verified use of an exposed credential. The documented domains include models.litellm[.]cloud and checkmarx[.]zone.

Minimum CI/CD decision tree: download only → block both versions, purge caches, and inspect downstream artifacts; installed but demonstrably never executed → destroy the environment/image and rebuild, with rotation generally limited to credentials whose non-exposure cannot be established; Python executed → revoke and rotate every secret reachable by that job or runtime, including CI, cloud, registry, API, and signing credentials; IOC traffic, telemetry gaps, or confirmed exfiltration → treat those secrets as compromised, revoke before rebuilding, review their use, and replace runners rather than cleaning them in place. Lock the replacement by hash, generate an SBOM, and reject unexpected .pth files during artifact inspection.