ShinyHunters breached the world’s largest medical device maker and exfiltrated data from a company whose products keep people alive. A utility technology firm quietly disclosed that someone had been inside its internal network, a company whose smart meters sit between the grid and 110 million homes and businesses. The same threat actor group responsible for last week’s Checkmarx KICS compromise turned around and weaponized the Bitwarden CLI through the exact same GitHub Actions vector, then expanded from npm to PyPI to hit PyTorch Lightning five days later, with a worm that now impersonates Anthropic’s Claude Code to hide its commits. And a campaign that has been running since March was finally written up this week: a threat actor is resolving its command-and-control infrastructure through the Ethereum blockchain, which means your DNS blocking is irrelevant, your IP blocklists are irrelevant, and your takedown requests go to a decentralized ledger no one controls.
The pattern this week is less about attack technique and more about target selection. Medtronic, Itron, Bitwarden, PyTorch Lightning. The companies the threat actors chose this week are the ones you actually depend on, and in most cases the one you did not think to include in your supply chain risk program.
This week: the second major medtech breach in two months and what ShinyHunters is building toward, a utility infrastructure breach with an unknown scope and a company that manages grid-connected endpoints at global scale, an update on the TeamPCP Shai-Hulud worm that has now crossed from npm into PyPI, and the EtherRAT campaign targeting IT administrators with admin tools that beacon through blockchain.
Medtronic Breach: ShinyHunters Claims 9 Million Records at the World’s Largest Medical Device Maker
What happened:
On April 17, 2026, the ShinyHunters data-theft and extortion group posted a claim to the dark web asserting they had breached Medtronic and exfiltrated over 9 million records containing personally identifiable information, along with additional terabytes of internal corporate data. ShinyHunters set an April 21 ransom deadline. Medtronic confirmed the breach in a public statement and SEC 8-K filing on April 24, stating that an unauthorized party had accessed data in certain corporate IT systems. The company said its product networks, manufacturing, distribution, and hospital-customer networks were unaffected, and that the breach is not expected to have a material financial impact. The specific data types compromised have not been confirmed, and no independent verification of ShinyHunters’ claimed record count has been published. Medtronic’s removal from ShinyHunters’ leak site following the deadline suggests a ransom negotiation may have occurred, though neither side has confirmed this.
Technical details that matter:
- Threat actor: ShinyHunters, also confirmed as responsible for the ADT breach (disclosed April 24, claimed 5.5 million individuals via HIBP), the Telus breach (700TB claimed, March 2026), and the Match Group/Hinge breach (January 2026). The group’s primary technique is social engineering targeting identity provider and SSO access, not sophisticated exploit chains. ShinyHunters has used vishing, Okta SSO compromise, and downstream marketing and analytics tooling exposure in prior campaigns.
- Claimed scope: 9 million records with PII, plus terabytes of internal data. Medtronic has not confirmed the record count or data categories. The investigation is ongoing.
- Network segmentation held (so far): Medtronic’s corporate IT, product networks, manufacturing, and hospital-customer environments are maintained as separate segments. The attacker did not traverse from IT into OT or clinical infrastructure, based on current findings. This is meaningful and should be credited.
- Medtech pattern: This is the third major medtech cybersecurity incident in two months. In March 2026, the Iran-linked Handala group wiped devices across Stryker’s global network, disrupting ordering and manufacturing for weeks. Intuitive Surgical reported a phishing-origin breach in the same period. All three are medtech giants. The sector is being worked deliberately.
Why critical institutions should care:
Medtronic makes pacemakers, defibrillators, insulin pumps, glucose monitoring systems, surgical robots, and ventilators. Even a breach limited to corporate IT systems exposes something more dangerous than credentials: it exposes the internal architecture of how those devices are supported, serviced, and connected. Corporate IT at a medtech company holds clinical support documentation, service protocols, firmware distribution records, customer hospital relationships, and potentially device configuration data. The exfiltration of terabytes of internal data from a company at this tier represents intelligence about medical infrastructure that is worth far more than 9 million individual records on a dark web forum. The pattern of repeated targeting across Stryker, Intuitive Surgical, and now Medtronic within a single quarter suggests coordinated sector interest, not opportunism.
Key sources:
- https://news.medtronic.com/Medtronic-statement-on-unauthorized-system-access
- https://www.theregister.com/2026/04/27/itron_medtronic_hacked/
- https://medcitynews.com/2026/04/medtronic-cyberattack-medical-device-hacker/
- https://www.hipaajournal.com/medical-device-maker-medtronic-data-breach/
Itron Breach: Utility Infrastructure for 110 Million Endpoints Compromised in Mid-April
What happened:
Itron, a Liberty Lake, Washington-based utility technology company, filed an 8-K with the SEC on April 24, 2026, disclosing that an unauthorized third party accessed certain internal systems on April 13. The company activated its incident response plan, engaged external advisors, and notified law enforcement. Itron stated it has seen no subsequent unauthorized activity in its corporate systems and no activity in the customer-hosted portion of its systems. No ransomware group has claimed responsibility. The breach type, duration of access, and scope of data exposure remain unknown. Itron’s investigation is ongoing, and the company noted it may need to file additional legal and regulatory notifications as findings develop, language that typically signals a data breach affecting personal information.
Technical details that matter:
- Scope of what Itron manages: Smart meters, sensors, and software for electricity, water, and gas distribution. The company serves 7,700 utility customers across 100 countries and provides technology connected to over 110 million homes and businesses. Its platforms include demand response, outage detection, grid analytics, and the communications networks between meters and utility control systems.
- Access vector: Not publicly disclosed. No attacker has claimed the intrusion, which is unusual for financially motivated groups. The absence of a ransomware claim, combined with the fact that Itron expects insurance to cover a significant portion of costs, suggests either the attackers were paid quietly, the breach was caught early before encryption was deployed, or this is a reconnaissance-focused intrusion with a longer dwell time objective.
- Customer system separation: Itron states customer-hosted systems were unaffected. This is a meaningful distinction because Itron’s architecture typically separates its internal IT infrastructure from the SaaS platforms and on-premise software that utilities actually operate. However, an attacker with access to Itron’s internal systems could obtain network diagrams, customer deployment configurations, support credentials, and documentation on how those customer environments are structured, even without directly touching them.
- Disclosure method: Itron disclosed via SEC 8-K filing rather than a public press release. This legal route limits immediate visibility outside the investor community. Detailed public statements typically follow 2 to 4 weeks after SEC filings in infrastructure sector incidents.
Why critical institutions should care:
The question in an Itron breach is not whether the grid went down. It did not. The question is what an attacker learned about how the grid is connected. Itron’s internal systems are likely to hold customer deployment architecture, API integration specifications, device configuration templates, and support access credentials that utilities have granted to Itron personnel for remote maintenance. An attacker doing reconnaissance on grid infrastructure would find Itron’s internal network far more informative than any publicly available documentation on how a specific city’s water or electricity metering system is wired. Utilities using Itron’s platform should not wait for Itron’s follow-up disclosures before asking their account teams what internal Itron personnel had access to their environments and whether those credentials have been rotated.
Key sources:
- https://www.bleepingcomputer.com/news/security/american-utility-firm-itron-discloses-breach-of-internal-it-network/
- https://techcrunch.com/2026/04/27/critical-infrastructure-giant-itron-says-it-was-hacked/
- https://www.securityweek.com/energy-and-water-management-firm-itron-hacked/
- https://www.infosecurity-magazine.com/news/utilities-tech-supplier-itron/
Update: TeamPCP / Shai-Hulud Campaign Expands from npm to PyPI, Now Impersonates Claude Code
Continuing from last week’s Checkmarx KICS supply chain compromise, covered in the April 17-24 edition.
What happened:
The campaign has continued to accelerate. On April 22, the same GitHub Actions infrastructure TeamPCP used against Checkmarx was turned against Bitwarden’s CLI, which uses the compromised checkmarx/ast-github-action in its build pipeline. Malicious version @bitwarden/[email protected] was published to npm from 5:57 PM to 7:30 PM ET and downloaded into an estimated 250,000-monthly-download pipeline before Bitwarden and Socket contained it. On April 29, the campaign hit SAP-related npm packages. On April 30, it crossed from npm into PyPI: versions 2.6.2 and 2.6.3 of lightning (PyTorch Lightning), a deep learning framework with 31,100 GitHub stars and millions of monthly PyPI downloads, were published with malicious payloads. PyPI administrators quarantined the package. The campaign also spread to [email protected] on npm and to PHP’s Packagist via intercom/intercom-php. The threat actor’s GitHub account pl-ghost appears to have been active inside Lightning-AI’s repository during the incident, closing disclosure issues within one minute and posting a meme, indicating active account compromise beyond just the PyPI package.
Technical details that matter:
- Cross-ecosystem propagation: The worm’s design crosses from PyPI to npm. If the malware obtains npm publish credentials, it injects a
setup.mjsdropper androuter_runtime.jsinto every package that token can publish to, bumps the patch version, and republishes, meaning downstream developers who install those packages run the full payload without any interaction with the original infected package. - Execution chain (PyTorch Lightning): Malicious
__init__.pyexecutes a background thread on import. The thread launchesstart.py, which downloads the Bun JavaScript runtime (v1.3.13) and executes an 11 MB obfuscatedrouter_runtime.jspayload. The payload runs without requiring any user action beyondimport lightning. - Target credential set: SSH keys, shell history, GitHub and npm tokens, cloud credentials across AWS/Azure/GCP, environment variables, Kubernetes secrets, Docker credentials,
.envfiles, MCP server configurations, and AI agent credentials. - Exfiltration via four parallel channels: HTTPS POST to
zero.masscan[.]cloud:443/v1/telemetry, GitHub-based exfiltration to newly created public repositories with the description “A Mini Shai-Hulud has Appeared,” npm token abuse for propagation, and if a validated GitHub server token (ghs_) is found, direct commit pushes to all branches of the victim’s own repositories. - Identity impersonation: The payload uses the GitHub GraphQL API to fetch branches and commit files under a hardcoded committer identity designed to impersonate Anthropic’s Claude Code:
claude <[email protected]>. The goal is to make backdoor commits indistinguishable from legitimate AI coding tool activity in repository history. - Russian locale kill switch: The payload does not execute if the Russian language is configured on the host machine, consistent with attribution indicators from prior campaigns.
- IOC commit prefix:
EveryBoiWeBuildIsAWormyBoi. Repository descriptions containing “A Mini Shai-Hulud has Appeared” and hidden.claude/or.vscode/directories with unexpected contents are forensic artifacts. - Bitwarden-specific scope: Vault data was not exposed. The compromise affected the CLI’s build pipeline, not vault infrastructure. 334 downloads of the malicious version occurred. If
@bitwarden/cliis wired into a CI pipeline for secrets injection (its primary enterprise use case), every secret accessible to that runner during the window should be treated as compromised. - Last known clean versions:
lightning==2.6.1,@bitwarden/[email protected](re-release of 2026.3.0).
Why critical institutions should care:
PyTorch Lightning is not a fringe tool. It sits in the dependency trees of image classification systems, LLM fine-tuning pipelines, diffusion model services, and time-series forecasters across enterprise AI infrastructure. The AI/ML development environment is increasingly high-value and historically under-secured: data scientists and ML engineers often pull dependencies from public registries without the same scrutiny applied to production application code, and their training environments frequently have access to GPU compute clusters, cloud storage, and model weights repositories that represent the highest-value intellectual property in those organizations. The campaign also demonstrates that the threat actor now understands how to make malicious commits invisible inside repositories that use Claude Code or similar AI coding tools, which changes the forensic calculation for teams relying on commit history as a security control.
Key sources:
- https://socket.dev/blog/lightning-pypi-package-compromised
- https://thehackernews.com/2026/04/pytorch-lightning-compromised-in-pypi.html
- https://www.aikido.dev/blog/pytorch-lightning-pypi-compromise-mini-shai-hulud
- https://www.endorlabs.com/learn/shai-hulud-the-third-coming—-inside-the-bitwarden-cli-2026-4-0-supply-chain-attack
- https://semgrep.dev/blog/2026/malicious-dependency-in-pytorch-lightning-used-for-ai-training/
EtherRAT: Ethereum Blockchain C2 Targets IT Administrators Through Fake Admin Utilities
What happened:
Atos Threat Research Center published analysis on April 30 of a campaign identified in March 2026 targeting enterprise administrators, DevOps engineers, and security analysts by impersonating the administrative utilities they use daily. The campaign uses SEO poisoning across Bing, Yahoo, DuckDuckGo, and Yandex to push malicious GitHub repositories near the top of results for admin tool queries. Targets searching for tools like PsExec, AzCopy, Sysmon, LAPS, Kusto Explorer, and ProcDump encounter convincing-looking repositories that serve a two-stage delivery: a clean-looking “storefront” repository that redirects to a second repository delivering a malicious MSI payload. The payload installs EtherRAT, a remote access trojan that resolves its command-and-control server address by querying the Ethereum blockchain rather than DNS. Atos assessed the campaign as active and continuing to evolve technically since initial observations.
Technical details that matter:
- Delivery chain: SEO poisoning on secondary search engines (not just Google) pushes fake GitHub repositories. First-stage repository appears clean, legitimate-looking with appropriate descriptions and fake Stars/Forks signals. Second repository serves the malicious MSI. The two-stage structure is specifically designed to survive platform-level takedowns: if the second repository is removed, the first can be updated to point to a new one without changing the search engine result or lure page.
- C2 architecture (the novel part): EtherRAT does not use DNS or a static IP for command-and-control. It queries the Ethereum blockchain for a transaction from a specific attacker-controlled wallet. The transaction payload encodes the current C2 server address. When the attacker needs to rotate their C2 infrastructure, they submit a new blockchain transaction, and all infected hosts pick up the new address on their next polling cycle. This removes the ability to disrupt the campaign through DNS sinkholing, IP blocking, or domain seizure. Blockchain transactions are immutable and globally visible; the C2 update is as reliable as Ethereum itself.
- Payload execution: EtherRAT executes JavaScript commands directly inside a Node.js process, enabling file system access, OS command execution, and data theft without dropping a traditional executable. Beaconing uses random-looking paths and file extensions to blend into normal web traffic.
- Target selection logic: The campaign specifically targets queries for tools used by privileged accounts. An administrator or security analyst searching for PsExec or LAPS has elevated access to the environment they manage, which makes infection substantially more valuable than compromising a standard user. The campaign demonstrates a clear understanding of who uses what tools.
- Detection gap: Standard threat intelligence feeds block known C2 IPs and domains. EtherRAT’s blockchain-based resolution means there is no static C2 endpoint to feed into blocklists. The malware phones home to the blockchain, not to a server, and the server address rotates dynamically. Defenders relying solely on network-level C2 blocking will not detect an active EtherRAT infection until it generates outbound traffic to the current (rotatable) server.
Why critical institutions should care:
Every IT administrator who has searched for an admin utility on a search engine they do not use daily is a potential EtherRAT target. The campaign specifically targets the people with the most access: domain administrators, DevOps engineers with cloud credentials, security analysts with incident response tooling. The blockchain C2 design means the attacker has effectively moved to infrastructure that no government, platform, or threat intelligence vendor can take down. What makes this operationally significant is not the RAT itself but the evasion model: if this technique proliferates to other campaigns, the standard “block the C2” response to infections becomes partially obsolete. Institutions should review their endpoint detection rules for Node.js spawning from unusual parent processes, unexpected Ethereum node queries or blockchain API calls, and MSI installations originating from user-downloaded files rather than software management systems.
Key sources:
- https://cyberpress.org/etherrat-seo-github-admin-assault/
- https://thehackernews.com/2026/04/etherrat-distribution-spoofing.html (Atos TRC disclosure)
- https://semgrep.dev/blog/2026/malicious-dependency-in-pytorch-lightning-used-for-ai-training/
The Pattern This Week
The incidents this week have a different shape than last week’s. Last week was about trust relationships: OAuth grants, publisher credentials, and design choices that prioritized access over verification. This week is about target selection.
ShinyHunters did not pick Medtronic because it was the easiest target in healthcare. It picked the largest medical device company by revenue after already working through ADT, Telus, and Match Group. Itron is not a random utility vendor; it is the vendor whose platform manages grid-connected endpoints at a scale that makes it one of the most informative targets available for anyone studying North American infrastructure. The Shai-Hulud campaign did not expand to PyPI arbitrarily; it went specifically to PyTorch Lightning, the framework sitting inside the AI training pipelines of enterprises with the highest-value machine learning workloads. EtherRAT does not target executives or end users; it targets the administrators and security analysts whose access reaches the most of the environment.
The common thread is that every target chosen this week was chosen because of what it touches, not just what it is. A breach of Medtronic’s corporate IT is interesting. Terabytes of internal data from the company that makes and services the hardware implanted in cardiac patients is something else. A breach of Itron’s internal systems is a contained IT incident. An attacker with Itron’s internal architecture documentation is looking at 110 million connected endpoints through a vendor’s eyes.
The defender’s calculus needs to account for this selection logic. Your highest-risk third parties are not the ones with the weakest security controls. They are the ones who see the most of your environment and whose internal knowledge, if stolen, would let an attacker reconstruct what you look like from the outside.
See you next week.
For the Business Side: Three Reviews Worth an Hour of Your Week
1. Audit what your vendors know about your environment, not just what they can access. The Itron breach is still being investigated, and the company says customer-hosted systems were unaffected. But an attacker with access to a vendor’s internal systems often learns more about customer environments from documentation, support tickets, and deployment records than from direct system access. Ask your utility software, infrastructure management, and medical device service vendors one specific question: what does your internal team store about our environment, and who has access to it? If the answer is “we don’t know,” that is the finding.
2. Treat your AI and ML dependency trees as production supply chain risk. The PyTorch Lightning compromise affected a framework that millions of monthly downloads bring into training pipelines, model development environments, and CI jobs. Most organizations that run data science or ML workloads do not apply the same dependency pinning, lockfile enforcement, and SBOM requirements they apply to production application code. If your organization trains models, fine-tunes LLMs, or runs ML experiments in cloud environments, ask your team whether those environments pin dependency versions and whether any unpinned install of a dependency ran in the past week. The last known clean PyTorch Lightning version is 2.6.1.
3. Check your search engine hygiene policy for administrative tooling downloads. The EtherRAT campaign succeeds because administrators search for tools on secondary search engines and trust the top results. This is a policy gap, not a technical one. Organizations can address it by maintaining an internal software distribution catalog for administrative tools, blocking unapproved software installation categories on privileged workstations, and briefing IT and security staff that search-engine-sourced admin tool downloads from GitHub are an active attack vector. The tools being spoofed (PsExec, AzCopy, Sysmon, LAPS, Kusto Explorer) are common enough that almost any IT team will recognize them. If your administrators are downloading these from search results rather than from an approved internal source, that is an exposure.