Satine Sentinel: August 7, 2026

This week the water story stopped being a Minnesota story. The coordinated OT campaign we covered last week when it hit 30-plus municipal systems in one state has spread to at least 12 states, and the follow-on research explains why it spread that fast: the attackers didn’t need a zero-day, they needed port 44818 open to the internet and no password on the other end of it. A supply chain attacker with a compromised GitHub account turned a caching library with 127 million weekly downloads into a credential-stealing worm that jumped to more than 440 packages in under 24 hours, and did it with cryptographically valid provenance the whole time. And Amgen told the SEC that patient health records and proprietary research data were pulled out of cloud storage it doesn’t even operate itself, the latest in a run of pharmaceutical breaches that all share the same shape: the victim’s own network was never touched.

This week: what six years of unheeded warnings and a fresh Forescout exposure analysis reveal about why the water utility campaign metastasized from one state to a dozen, how a single compromised GitHub account turned routine caching libraries into a worm with a blockchain-based command channel, and what it means when a biotech giant’s most sensitive patient data lives, and gets stolen from, servers the company doesn’t control.


Update: Water Utility Cyberattacks Expand to 12 States, Exposing a Visibility Crisis Behind the Vulnerability Crisis

What happened:

The campaign we covered last week, more than 30 Minnesota water systems disrupted the weekend of July 26 to 27, has grown considerably. The FBI and EPA’s July 30 joint advisory initially confirmed incidents in at least seven states; by August 4, federal officials and multiple outlets put the count at 12 states, with Michigan (nine systems), South Dakota, and Georgia named alongside Minnesota. CISA confirmed that some affected jurisdictions issued boil-water notices and sustained manual operations after losing automated control. Attribution still hasn’t been formally confirmed, though US intelligence officials continue to point to Iran and tradecraft consistent with the CyberAv3ngers ecosystem. This is a genuine escalation, not just wider reporting of the same incident: new states, new advisories, and a substantial new body of exposure research published this week that explains the mechanics of why this spread so easily.

Technical details that matter:

The FBI and EPA advisory names the specific targets: Rockwell Automation/Allen-Bradley MicroLogix 1100 and 1400 series PLCs. After remotely accessing internet-facing devices, attackers changed IP addresses and passwords, locking operators out of monitoring and control. At least one victim organization found modified PLC project files, meaning attackers altered the ladder logic governing physical equipment, not just the access credentials. Reported operational effects included pressure loss and flooding, with pressure loss creating a pathway for untreated groundwater to enter distribution pipes.

Forescout’s Vedere Labs published a technical exposure analysis on August 5 that fills in why this was possible at scale. Querying Shodan for port 44818 (EtherNet/IP, the Rockwell-developed industrial protocol these PLCs use) turned up 4,407 exposed devices worldwide, 65 percent of them in the US. In standard configuration, the mode nearly every small water utility runs, port 44818 accepts CIP connections with no authentication at all: an attacker can enumerate device identity, read tag values, and in many cases write controller state without ever supplying a credential. CIP Security, the authentication layer Rockwell added later, requires firmware version 20-plus and deliberate configuration that virtually no small utility has done. Forescout’s Sai Molige told CyberScoop the pattern looks like mass opportunistic scanning of a known-vulnerable device class, not a sophisticated targeted intrusion.

The more striking finding is structural. More than 70 percent of US-exposed controllers sit inside large mobile carrier networks, meaning cellular modems, not enterprise wiring, are the actual attack surface, exactly matching how the FBI described attackers reaching Plymouth’s water towers and lift stations. Of 22 exposed hosts Forescout traced to cities directly hit in this campaign, 19 (86 percent) sat on the same carrier network, a clustering pattern that points to a shared managed-service-provider configuration replicated across multiple utilities rather than independent local choices. Beyond the PLCs themselves, Forescout’s certificate-transparency research turned up “ghost assets”: a server provisioned for a web app in 2019 that never launched, still carrying a currently valid certificate and still reachable in 2026; expired remote-access certificates; abandoned hostnames whose DNS records still resolve. These are not devices utilities chose to leave exposed. They are devices utilities apparently forgot existed, and a device that isn’t in anyone’s inventory can’t be patched, firewalled, or noticed missing until an attacker uses it.

Separately, roughly 349 MicroLogix 1100 units remain internet-exposed globally (168 in the US). Rockwell discontinued that model in April 2022. It will never receive another firmware update, and the known vulnerabilities on it, including a cleartext credential flaw and an unauthenticated RCE, are permanent.

Why critical institutions should care:

This is now the widest documented coordinated cyberattack on US municipal water systems, and the Forescout data reframes six years of failed CISA and Rockwell advisories: the standard explanation has been that utilities lack the budget and staff to comply, but the ghost-asset finding suggests some utilities couldn’t comply even if fully funded, because they don’t have a complete inventory of what’s reachable on their own network. Water utilities also face no mandatory cybersecurity framework comparable to NERC CIP for electric utilities; a 2024 EPA enforcement alert found 70 percent of inspected water systems weren’t even compliant with the voluntary risk-assessment requirements that do exist. For any critical institution, and this generalizes well past water, the carrier-clustering finding is the sharper lesson: if your OT relies on a third-party managed service provider for remote connectivity, ask now whether that provider replicated the same architecture across every client site, because that’s exactly the pattern that let this campaign multiply.

Key sources:


The Keyv/Cacheable npm Worm: A Blockchain-Directed Supply Chain Attack Hits 2 Billion Monthly Installs

What happened:

On August 4 at roughly 09:00 UTC, an attacker who had compromised the GitHub account of the maintainer behind keyv, a key-value caching library with about 127 million weekly npm downloads, pushed malicious commits directly to keyv’s main branch and cut a new release. The same account maintained cacheable, flat-cache, file-entry-cache, and several other widely used caching utilities, all swept into the same compromise within minutes. By the next day, researchers had counted at least 444 packages across 1,381 versions carrying the payload, with a combined total exceeding 2 billion monthly installs at the time of writing. Because the malicious releases were built and signed through the legitimate GitHub Actions pipeline, every cryptographic provenance check on the poisoned tarballs passed. The code really was built by that repository, in that workflow, on that commit. It just also happened to be malware.

Technical details that matter:

Each compromised release added a “preinstall”: “node setup.mjs” hook to package.json, meaning the payload executed automatically the moment anyone ran npm install, before any application code ran. setup.mjs is an 11KB obfuscated loader that checks for the Bun JavaScript runtime, installing it if absent, then launches a roughly 728KB second-stage stealer under Bun. That stealer targets .npmrc tokens, GitHub CLI tokens, AWS credentials, HashiCorp Vault tokens, Kubernetes configs, and cryptocurrency wallets, exfiltrating them to the domain npm-cache[.]com and to GitHub repositories set up under other compromised identities. The most distinctive technical detail: the malware looks up its command-and-control domain from an Ethereum smart contract rather than a hardcoded address, letting the operator rotate infrastructure without ever touching or re-publishing the payload itself. Researchers at Wiz identified the User-Agent string Bun/1.3.13 as a reliable indicator of compromise. Security researchers have attributed the payload to the “Mini” Shai-Hulud malware family, tracking it as a descendant of campaigns including March 2026’s Axios compromise and June 2026’s @redhat-cloud-services compromise, both of which used the same technique of stealing tokens to automatically republish trojanized versions of legitimate packages.

Why critical institutions should care:

This is the second major npm compromise in three months to ship malware with fully legitimate cryptographic attestation, which means the standard defensive advice, verify package provenance and signatures, no longer catches this attack class. keyv and its dependents are transitive dependencies buried deep in build pipelines across an enormous share of the JavaScript ecosystem; an organization doesn’t need to have heard of keyv to be running it. Because the credential theft specifically targets CI/CD tokens, cloud credentials, and Kubernetes configs rather than end-user data, the practical risk to any institution, hospital IT department, utility SCADA vendor, or financial services back office running Node-based tooling in its build or ops pipeline, is that a single developer’s or CI runner’s compromised credentials become the attacker’s next foothold into production infrastructure. This is precisely the kind of trusted-platform, trusted-toolchain targeting this newsletter keeps returning to: the defense isn’t scanning your own code, it’s knowing what showed up in your lockfile this week.

Key sources:


Amgen Discloses Material Breach: Patient Health Data Stolen From Cloud Systems It Doesn’t Operate

What happened:

Amgen, one of the world’s largest biotechnology companies, disclosed in a Form 8-K filed with the SEC on July 31 that attackers exfiltrated proprietary company data and patients’ protected health information from cloud environments hosted by third-party service providers. Amgen detected the unauthorized activity in July, activated its incident response plan, brought in outside forensic investigators, and determined the incident to be “material” under SEC rules, largely because of the volume of files apparently affected. The company says it has found no impact to manufacturing, product supply, or financial reporting systems. No threat actor has publicly claimed the breach and no ransom demand has been disclosed; Amgen has not named the affected cloud providers or said how the environments were initially accessed.

Technical details that matter:

The attack vector remains publicly unconfirmed, which is itself the notable detail: unlike a ransomware deployment or a phishing-driven account takeover, this was framed by Amgen purely as unauthorized access to and exfiltration from cloud storage the company relies on but does not directly operate. Security researchers have flagged, without forensic confirmation, that the pattern matches ShinyHunters’ documented method against healthcare targets this year: compromising SSO credentials to reach downstream SaaS and cloud platforms rather than attacking a target’s core network directly. That inference rests on timing and sector targeting, not disclosed indicators: Health-ISAC issued an advisory on ShinyHunters targeting healthcare organizations on July 24, one week before Amgen’s disclosure, and the group had reportedly flagged Amgen as a target as early as January. None of this has been confirmed by Amgen or independently verified through published IOCs, and this newsletter treats it as an open attribution question rather than a fact. What is confirmed is the vector class: third-party-hosted cloud storage, not Amgen’s own infrastructure, which places this alongside a run of 2026 pharma-sector incidents (Novo Nordisk’s clinical trial data exposure in June, West Pharmaceutical Services’ ransomware attack in May, Analog Devices’ breach disclosed July 30) that share a common shape, the compromise happens one or two vendor hops away from the company whose name ends up in the headline.

Why critical institutions should care:

A biotech company disclosing patient PHI theft from infrastructure it doesn’t control is a preview of a liability question most critical institutions haven’t resolved: when the exfiltration point is a third-party cloud environment, who owns the incident response, the regulatory notification burden, and the reputational fallout? Amgen still has to make HIPAA-driven notification decisions and SEC materiality disclosures for data it never directly held on its own servers. For hospitals, insurers, and any institution that has pushed sensitive data into vendor-managed cloud environments to reduce its own operational burden, the Amgen filing is a reminder that data custody doesn’t transfer with data storage, the regulatory and reputational exposure stays with the data owner even when the infrastructure doesn’t.

Key sources:


The Pattern This Week

Every story this week involves an attacker exploiting something the victim organization didn’t fully control or couldn’t fully see. The water utilities didn’t lack awareness that internet-exposed PLCs were dangerous, CISA and Rockwell have said so for six years, they lacked a complete inventory of which devices, certificates, and hostnames were actually reachable, and in a meaningful share of cases, the exposure ran through a third-party carrier or managed-service configuration nobody at the utility had audited. The keyv worm didn’t exploit a flaw in the code itself; it exploited the fact that a single compromised GitHub account sat upstream of 2 billion monthly installs, and that cryptographic provenance, the exact control meant to prevent this, can’t distinguish a legitimate maintainer’s bad day from an attacker with their credentials. And Amgen’s breach happened in infrastructure it pays a vendor to run, meaning the company’s own security posture was never the thing that failed.

The throughline: “we secured our own environment” is no longer a sufficient claim for any of these institutions, water utility, software consumer, or biotech company. The exposure increasingly lives in the layer you don’t operate: the carrier network your integrator chose, the maintainer account upstream of your dependency tree, the cloud tenant your vendor manages. Auditing your own perimeter is necessary. It is not, on its own, sufficient anymore.

See you next week.


What Your Business Can Do This Week

  1. If you operate or depend on any water, energy, or manufacturing OT with cellular or third-party managed connectivity, ask your provider directly whether the same remote-access architecture is replicated across their other clients. The 86 percent carrier-clustering finding in the Forescout analysis is the sharpest actionable detail from this week’s water research: a shared MSP configuration is a shared vulnerability. Request a network diagram showing every external IP and cellular gateway the provider manages on your behalf, and cross-check it yourself against Shodan for port 44818 or 502 exposure.
  2. Audit your dependency tree for keyv, cacheable, flat-cache, file-entry-cache, and related packages published on or immediately before August 4, 2026, and rotate any credentials that touched an affected build pipeline. Cryptographic provenance passing is not evidence of safety in this campaign; pin to versions independently verified as clean rather than trusting the “latest” tag, and treat any CI runner or developer machine that ran npm install during the exposure window as a credential-rotation event, not just a package-update event.
  3. If your organization stores regulated or sensitive data (patient health information, financial records, research IP) in a third-party-managed cloud environment, confirm in writing which party owns breach notification and regulatory disclosure obligations if that vendor’s environment, not yours, is the one that gets breached. Amgen’s filing shows that data custody and data liability don’t move together; find out now whether your vendor contracts actually specify this, rather than during an active incident.
  4. Treat “no zero-day was used” as a warning sign, not reassurance, when evaluating vendor and supplier incident disclosures this week. Both the water campaign and the npm worm succeeded using basic techniques (unauthenticated protocol access, a single compromised account) against widely deployed, trusted infrastructure. If a supplier tells you an incident was “not sophisticated,” ask what specifically stopped it from reaching you, rather than treating unsophisticated as synonymous with contained.
Final CTA Section
GET STARTED

Ready to Strengthen Your Defenses?

Whether you need to test your security posture, respond to an active incident, or prepare your team for the worst: we’re ready to help.

📍 Based in Atlanta | Serving Nationwide

Discover more from Satine Technologies

Subscribe now to keep reading and get access to the full archive.

Continue reading