CTI Daily Brief — 2026-05-12

ICO fines South Staffordshire Water £963,900 — water-sector OES with partial SIEM coverage; Cl0p attribution and ZeroLogon kill-chain detail sourced to The Record

The UK Information Commissioner's Office on 2026-05-11 issued a £963,900 fine against South Staffordshire Plc and its water-supply subsidiary for the 2020–2022 intrusion. The ICO's published findings cite inadequate vulnerability management, unpatched critical systems, obsolete unsupported software (the estate still contained Windows Server 2003, EOL since July 2015), and incomplete SIEM coverage; the regulator does not name a CVE or threat actor in its public notice. The technical kill-chain detail — phishing initial access in September 2020 → CVE-2020-1472 (ZeroLogon, T1068) against two unpatched domain controllers → domain admin → ~20 months of unimpeded lateral movement → detection in July 2022 when IT performance degraded — comes from The Record's reporting, as does the Cl0p attribution. The ICO press release records that data on about 1.85 million customers (approximately 750,000 current and 1.1 million former) was held by the company, of which 633,887 individuals had data published on the dark web, and that the published dataset totalled over 4.1 TB including customer credentials, bank account/sort codes, Priority Services Register data (from which disability status can be inferred) and HR records (The Register, 2026-05-11). The fine was reduced 40% on the basis of early admission and cooperative engagement; South Staffordshire agreed not to appeal.

Why it matters to us: The ICO action is the first significant post-Cyber-Security-and-Resilience-Bill UK regulatory action against a water-sector OES, and the regulator's operational findings transfer verbatim to NIS2 Article 21 technical measures and the German KRITIS-DachG public-administration scope that came into force this spring. Concrete defender takeaway: (a) measure your actual SIEM/XDR coverage percentage by hostname inventory rather than by sensor-licence count — partial coverage on a high-value subset is materially worse than uniform sampling; (b) the ZeroLogon pivot reported by The Record is a long-tail patch-management hygiene point on domain controllers any SOC can audit against; (c) detection logic that survives this case maps to Sysmon-class auditing of DC authentication events — 4742 (account changes) and 4769 Kerberos service-ticket anomalies — after vendor disclosure of any DC-impacting CVE.

BKA and ZIT dismantle relaunched Crimenetwork darknet marketplace; German operator arrested in Mallorca on European Arrest Warrant

The German Bundeskriminalamt (BKA) and Frankfurt's Central Office for Combating Internet Crime (ZIT), with Spanish National Police support, arrested a 35-year-old German national at his residence in Mallorca on a European Arrest Warrant on 2026-05-08 and shut down the relaunched Crimenetwork (Bundeskriminalamt press release — Deutscher Betreiber von "Crimenetwork" auf Mallorca verhaftet, 2026-05-08; Help Net Security, 2026-05-11). Crimenetwork was the dominant German-language darknet marketplace; the platform was originally taken down in December 2024, and a new operator rebuilt the infrastructure under the same branding shortly afterwards. The rebooted platform reached ~22,000 users and 100+ vendors and brokered stolen data, narcotics, forged documents and illegal services in BTC / LTC / XMR for an estimated €3.6 million in commissions and vendor fees before being seized. Investigators recovered approximately €194,000 in assets and substantial user/transaction data, which the BKA states will drive a wave of follow-on prosecutions — the press release explicitly frames the seized infrastructure data as the operational value, not the headline arrest.

[SINGLE-SOURCE-OTHER] West Pharmaceutical Services files SEC Form 8-K Item 1.05 — data exfiltrated, systems encrypted, global operations partially restarted

West Pharmaceutical Services Inc. (NYSE: WST), a US-headquartered global manufacturer of drug-delivery and packaging components, filed a Form 8-K on 2026-05-11 disclosing a material cybersecurity incident under Item 1.05 (SEC EDGAR — WST 8-K, 2026-05-11). The filing states that detection occurred on May 4 2026, materiality was determined May 7, and that "certain data was exfiltrated by an unauthorized party and certain systems were encrypted" — terminology consistent with a T1486 Data Encrypted for Impact plus T1041 Exfiltration Over C2 Channel double-extortion ransomware pattern. The company took global systems offline, activated incident response, notified law enforcement and engaged external forensics; core enterprise systems are restored, shipping/receiving/manufacturing are partially restarted at some facilities, and full restoration timeline and material financial impact remain undetermined. No threat actor has claimed responsibility publicly at time of filing.

Škoda Auto Deutschland online-shop breach exposes customer PII and password hashes; logging gap prevents exfiltration confirmation

Škoda Auto Deutschland GmbH disclosed on 2026-05-11 that an unauthorised actor exploited a vulnerability in the standard shop-software platform underlying its German online-retail store, accessing customer names, postal addresses, email addresses, telephone numbers, order history, account data and password hashes (Škoda Auto Deutschland — Sicherheitsvorfall Škoda Shop; SecurityWeek, 2026-05-11). Credit-card data was not exposed — payment processing is delegated to external PSPs and never stored in the shop database. Škoda's own monitoring detected the intrusion; the shop was taken offline, the underlying vulnerability patched, and external forensics retained. The disclosure flags one notable operational shortfall in the company's own framing: insufficient logging coverage prevents investigators from determining definitively whether the accessed data was actually exfiltrated, so customers must be treated as if it was. Škoda Auto a.s. is a VW Group subsidiary headquartered in Mladá Boleslav (Czech Republic); the German operating company's notification reached the competent EU supervisory authority within the GDPR Article 33 72-hour window. No threat actor has been attributed.

UPDATE: Palo Alto PAN-OS CVE-2026-0300 — first-wave fixed builds now scheduled for 2026-05-13; until then interim mitigation remains the only option

UPDATE (originally covered as the 2026-05-07 deep dive; updates 2026-05-08 → 2026-05-10): Palo Alto Networks' PSIRT page for CVE-2026-0300 (last updated 2026-05-07 at time of run) now lists first-wave fixed builds with an ETA of 2026-05-13 for several mainline branches and a second wave around 2026-05-28 for the remaining branches; no patched build is yet shipped against the unauthenticated root RCE in the User-ID Authentication Portal / Captive Portal service. The CL-STA-1132 cluster attribution and the ~2026-04-09 first-observed-exploitation date come from Unit 42's separate Captive Portal Zero-Day threat bulletin, not from the PSIRT advisory itself.

Operationally: until the 05/13 first-wave builds ship, the interim Threat Prevention signature 510019 plus source-IP restriction of the captive-portal interface to trusted internal ranges remain the only defender controls for branches that do not yet have a fixed build. PA-Series and VM-Series operators with User-ID Authentication Portal or Captive Portal exposed should treat tomorrow as a pre-staged deployment window — confirm a tested rollback path, validate the interim signature is enforced (Threat Prevention licence required), and verify the captive-portal listener is reachable only from authorised source ranges. Prisma Access, Cloud NGFW and Panorama are not affected. The CISA KEV deadline (2026-05-09) has already expired for FCEB agencies and per PD-13 does not drive Swiss/EU action framing on its own — the operational driver is the actively-exploited ITW status and the imminent first-wave patch ship date.

UPDATE: Instructure (Canvas LMS) — ransom paid to ShinyHunters with "shred logs"; second intrusion confirmed; per-institution leak deadline reset to today

UPDATE (originally covered 2026-05-09; updated 2026-05-10): Instructure on 2026-05-11 disclosed that it "reached an agreement with the unauthorized actor" and received "digital confirmation of data destruction (shred logs)" — a ransom payment in everything but name, undisclosed amount, covering the platform-wide ~3.65 TB dataset that ShinyHunters claimed to have lifted from Canvas's Free-for-Teacher tier on 2026-04-29 (Inside Higher Ed, 2026-05-11; Infosecurity Magazine, 2026-05-11).

Two material developments accompany the settlement: (a) Instructure confirmed a second intrusion on 2026-05-07 in which ShinyHunters defaced approximately 330 individual institution login portals via the same Free-for-Teacher vulnerability — the first ITW evidence that the underlying flaw remained exploitable post-patch; (b) ShinyHunters has now reset a per-institution payment deadline to end-of-day 2026-05-12 (today), positioning the central settlement as covering only the bulk dataset while leaving individual institutions exposed to targeted publication (The Register, 2026-05-12). CEO Steve Daly publicly acknowledged delayed external communication ("we got the balance wrong" on disclosure timing). CrowdStrike remains engaged for the IR work.

Operational reality for any European university running Canvas: the "data was destroyed" claim is not technically verifiable — by ransomware-actor practice, the artefact provided is typically a hash list or a video, not a forensically meaningful proof of deletion. The dataset must continue to be treated as compromised in perpetuity for GDPR / Swiss DSG purposes, downstream phishing risk planning, and student-identity exposure communications. Institutions that received the per-institution deadline note should validate that any locally-stored Canvas-derived data (course rosters, communications, gradebooks) is included in the breach-notification scope, regardless of the platform-wide settlement.

UPDATE: TeamPCP (UNC6780 / PCPJack ecosystem) backdoors the Checkmarx Jenkins AST plugin — third Checkmarx supply-chain compromise in three months, SANDCLOCK exfiltrates every CI secret reachable from the runner

UPDATE (TeamPCP / mini-shai-hulud first covered 2026-05-07; PCPJack worm covered 2026-05-10; this is a distinct new artefact in the same actor ecosystem): On 2026-05-09–10 (UTC) TeamPCP (UNC6780) published a backdoored build of the Checkmarx Jenkins AST plugin (version 2026.5.09, marketed under the actor's signature naming "Checkmarx-Fully-Hacked-by-TeamPCP") to the Jenkins Marketplace. Any Jenkins instance configured to auto-update the AST plugin during that window pulled the malicious build and executed the SANDCLOCK credential stealer in the runner context (Checkmarx — Ongoing Security Updates, last updated 2026-05-09; The Hacker News, 2026-05-11; SecurityWeek, 2026-05-11).

SANDCLOCK targets every secret reachable from a typical CI/CD pipeline environment: GitHub Personal Access Tokens, AWS / Azure / GCP credentials, Kubernetes service-account tokens, Docker / OCI registry credentials, SSH keys, and Checkmarx One API tokens. Affected pipelines should be treated as full secrets-compromise events: every credential the runner could read must be rotated and any artefact built or deployed in the window audited. Checkmarx's ongoing-security-updates page specifies plugin version 2.0.13-829.vc72453fa_1c16 (published December 2025) as the safe pinned version; a CVE has been issued as CVE-2026-33634 per the Checkmarx advisory. This is the third Checkmarx-product supply-chain compromise by this actor in three months, after the March 2026 KICS Docker image and the April 2026 VS Code extension defacement — the cadence and the actor's naming convention indicate persistent targeting of the Checkmarx product line specifically, not opportunistic distribution-channel abuse.

Mapped to T1195.002 Compromise Software Supply Chain and T1552.001 Credentials In Files. The GTIG AI Threat Tracker (see § 5) attributes SANDCLOCK specifically to TeamPCP and flags the stealer as explicitly designed to harvest LLM API keys in addition to traditional cloud credentials — consistent with the actor's pivot to monetising stolen LLM access. Defender pivot: inventory every Jenkins plugin auto-update enabled across CI/CD estates; constrain runners to short-lived OIDC-federated credentials (no long-lived PATs in runner env) where the platform supports it; audit Checkmarx One API logs for unexpected source IPs since 2026-05-09.

The first AI-generated zero-day exploit observed in the wild

GTIG describes a criminal campaign that used an LLM-generated Python exploit script targeting an unnamed widely-deployed open-source web-based systems-administration tool. The underlying flaw is a 2FA-bypass arising from a semantic logic error: developers hardcoded a trust assumption in one code path that contradicts the authentication-enforcement logic in another. GTIG's editorial point is that this bug class is exactly where LLMs outperform classical static analysis and fuzzers — semantic intent mismatch is undetectable to a fuzzer because the program does not crash, and undetectable to a typical SAST rule because both code paths individually are syntactically defensible.

GTIG attributes the script to LLM generation with high confidence based on structural artefacts atypical of human exploit authors: abundant "educational" docstrings explaining each function's purpose to a hypothetical reader; a hallucinated CVSS score embedded in comments; ANSI-colour helper imports and a --help menu scaffold characteristic of LLM training-data formatting; consistent variable-naming patterns that read like a tutorial rather than an exploit. Mapped to T1190 Exploit Public-Facing Application at runtime, and notable as the first publicly attributed instance of an LLM operating as the exploit author rather than as a phishing-content generator. Responsible-disclosure coordination patched the underlying tool before mass exploitation took hold; GTIG explicitly believes the disclosure disrupted the campaign.

AI-augmented malware families: CANFAIL, LONGSTREAM, PROMPTFLUX, HONESTCUE

The same GTIG release documents four malware families that integrate LLM calls into runtime behaviour rather than into development:

• CANFAIL and LONGSTREAM (Russia-nexus) insert LLM-generated inert decoy code blocks and daylight-saving-time API calls at runtime to inflate benign-looking telemetry, polluting downstream behavioural-sequence detectors. Mapped to T1553 Subvert Trust Controls (as an EDR-evasion variant) and T1027 Obfuscated Files or Information (LLM-generated junk code as obfuscation).
• PROMPTFLUX uses the Gemini API at runtime to generate just-in-time self-modifying code for EDR evasion — a logical extension of the polymorphism / packer class, but with the unique property that no two execution-instance signatures need ever match because the LLM is the polymorphism engine.
• HONESTCUE requests VBScript-obfuscation stubs from Gemini at runtime, weaponising the cloud-API surface as the obfuscator's compiler.

State-actor abuse of Gemini: UNC2814 (PRC), APT45 (DPRK), APT27, UNC5673 (TEMP.Hex / PRC)

GTIG documents state-affiliated actor usage of Gemini for: ORB-fleet management (operating relay-network proxies), recursive-prompting validation of CVE / PoC quality at scale, and persona-driven jailbreaking attempts against embedded-device firmware analysis (TP-Link, the OFTP industrial protocol). UNC5673 (TEMP.Hex) is specifically called out for operating Claude-Relay-Service and CLI-Proxy-API tooling to pool illicit LLM access across Southeast Asian government-targeting operations — meaning the operational unit of compromise has shifted to include stolen LLM API keys as a primary objective, not a side-channel. This is the structural reason TeamPCP's SANDCLOCK stealer (§ 4 UPDATE) now explicitly enumerates LLM API keys alongside cloud credentials: there is a developed criminal market for stolen LLM access keys, driven by both volume billing arbitrage and access to higher-rate-limit / less-monitored model tiers.

Defender takeaway for Swiss / EU public-sector estates running AI workloads: treat LLM API keys as Tier-1 secrets equivalent to cloud-administrator credentials. Specifically: rotate at the same cadence; store in the same KMS / HSM-backed secret manager; enable usage-anomaly alerting at the LLM provider (rate-limit baselines per service principal, geographic / ASN anomalies, prompt-content categories outside business profile); audit any embedded-key check-ins to source control with the same gates as cloud-credential leak detection (T1552.001 Credentials In Files). The GTIG attribution that UNC5673 specifically targets government organisations means the threat profile applies directly to government developers and government-procured AI tooling.

Hardening / detection summary

Concrete posture changes a Swiss federal / cantonal / EU public-sector SOC can implement based on this report alone, in priority order:

1. Egress allowlisting for LLM-API endpoints: only workloads where LLM access is justified should be permitted outbound to *.googleapis.com/v1beta/, api.openai.com/v1/, api.anthropic.com/, etc. — enforce at SWG and at host firewall on production servers. Catches PROMPTFLUX / HONESTCUE / CANFAIL-class runtime LLM calls from workloads that should not be making them.
2. LLM-API-key secrets management: treat as Tier-1; rotate quarterly minimum; enable provider-side usage alerting on per-key baselines.
3. Exploit-artefact LLM-output heuristics added to triage pipelines for PoC scripts pulled from public sources — docstring-density / hallucinated-metadata / ANSI-bootstrap pattern, used as a triage prior, not a verdict.
4. CI/CD secrets hygiene at the runner level — directly applicable both to the AI-key theft trend and to the SANDCLOCK / TeamPCP Jenkins compromise carried as the § 4 UPDATE. OIDC-federated short-lived credentials where the platform supports it; no long-lived PATs in runner environment.
5. Behavioural-sequence detector cross-validation: where ML-based EDR is in use, validate against API-call-sequence pollution by sampling current detection thresholds against synthetic LLM-generated benign sequences.

Pre-stage PAN-OS Captive Portal upgrade for the 2026-05-13 first-wave release; keep interim mitigation enforced until then

For any PA-Series / VM-Series perimeter device on PAN-OS 12.1, 11.2, 11.1, or 10.2 that has User-ID Authentication Portal or Captive Portal enabled, prepare today for the 2026-05-13 first-wave build release per Palo Alto's PSIRT advisory for CVE-2026-0300: confirm a tested rollback path, validate the change window for tomorrow, and pre-fetch release notes the moment the fixed builds publish. Until the first-wave builds ship, keep Threat Prevention signature 510019 enforced (requires Threat Prevention licence) and restrict the captive-portal listener to trusted internal source ranges. The second wave is expected around 2026-05-28 for the remaining branches (12.1.7, 11.2.4-h17, 11.2.12, 11.1.7-h6, 11.1.15, 10.2.7-h34, 10.2.13-h21, 10.2.16-h7); plan a second deployment window then. The CISA KEV deadline has expired but the operational driver here is active ITW exploitation per Unit 42 — Captive Portal Zero-Day, not the FCEB compliance date.

Audit Jenkins pipelines for Checkmarx AST plugin auto-update window 2026-05-09 → 2026-05-10 and treat any match as full secrets compromise

For every Jenkins controller running the Checkmarx Jenkins AST plugin: confirm installed plugin version; if 2026.5.09 was ever pulled (auto-update enabled, or manual install in window), declare a secrets-compromise incident, rotate every credential the runner could read (GitHub PATs, AWS / Azure / GCP access keys, Kubernetes service-account tokens, Docker registry credentials, SSH keys, Checkmarx One API tokens, and any LLM API keys exposed to CI), and audit any artefact built or deployed in the window. Pin the plugin to 2.0.13-829.vc72453fa_1c16 per Checkmarx's ongoing-security-updates page. Where the Jenkins platform supports it, migrate runners to OIDC-federated short-lived credentials so the next supply-chain compromise yields no usable secrets.

Treat the Instructure Canvas "shred logs" as legally unverifiable; align with EU university IR teams on per-institution deadline today

For any Swiss / EU higher-education institution running Canvas: continue to treat the dataset as compromised regardless of Instructure's bulk-settlement disclosure; the platform-wide "shred logs" are not forensically meaningful proof of deletion. Verify whether the institution received the per-institution leak notice and validate that local Canvas-derived data (course rosters, communications, gradebooks) is included in the GDPR / Swiss DSG breach-notification scope. Ensure student-identity exposure communications cover the longer-tail credential-stuffing risk against federated SSO endpoints over the next quarter.

Implement egress controls on LLM API endpoints for production server workloads

Catches PROMPTFLUX / HONESTCUE / CANFAIL-class runtime LLM-API abuse and the LLM-API-key theft model the GTIG report attributes to UNC5673 (TEMP.Hex). Concrete: add an SWG / firewall allowlist policy that only permits outbound to *.googleapis.com/v1beta/, api.openai.com/v1/, api.anthropic.com/ from workloads where LLM access is justified; deny on production servers without an explicit override. Reinforce by treating LLM API keys as Tier-1 secrets — rotate quarterly minimum, store alongside cloud-administrator credentials, enable provider-side usage alerting on per-key baselines (rate-limit, geographic, ASN, prompt-content category outside business profile).

Audit SIEM/XDR telemetry coverage as a percentage of host inventory; the South Staffordshire 5%-coverage finding is the operational lesson

For any NIS2 / KRITIS-DachG / CER essential-entity SOC: measure SIEM / XDR coverage by hostname inventory rather than by sensor-licence count. The South Staffordshire 5% finding is what the ICO judged as inadequate for a water OES; with NIS2 transposition in force across the EU and KRITIS-DachG live in Germany, regulators are now armed with a concrete UK precedent for what "proportionate technical measures" failure looks like in court. Practical first step: pull a list of every Active Directory–joined host from AD; cross-reference against the EDR / SIEM source list; flag the delta. The delta is what the ICO would call the gap.