What Happened
On June 8, 2026, security researchers at Socket discovered that 19 packages on the Python Package Index (PyPI) had been compromised in a supply-chain attack. The affected packages — including popular bioinformatics tools like Dynamo, Spateo, CoolBox, and Napari-UFISH — had been downloaded hundreds of thousands of times by developers and data scientists.
The attack worked through a clever mechanism: malicious wheel distributions included a .pth startup hook file that executed automatically whenever Python started. This hook downloaded the Bun JavaScript runtime from GitHub and executed an obfuscated payload that targeted developer credentials.
The malware’s objective was straightforward: read every credential file it could find on the developer’s workstation. The target list included GitHub tokens, npm and PyPI publishing tokens, AWS/GCP/Azure credentials, SSH keys, Docker credentials, .env files, .npmrc and .pypirc configuration files, shell history files, and Claude/MCP configuration files.
Socket attributed this campaign to the broader “Shai-Hulud” operation, which now includes 453 malicious artifacts designed to compromise software development workflows and propagate further through stolen publishing credentials.
Why It Worked
Supply-chain attacks work because developers trust their package managers. When you run pip install dynamo, you expect to get a legitimate tool, not a credential thief. The malware authors compromised the maintainer account and pushed trojanized versions to PyPI. Developers installed them, Python executed the startup hook, and the malware ran with the full privileges of the developer’s account.
Every credential theft in this attack required reading a file from the local file system. The malware needed to open ~/.aws/credentials, read ~/.ssh/id_rsa, parse .env files, and extract tokens from .npmrc. These are all file read operations at the Windows kernel level.
Traditional security tools struggle here because the malware is executing as a legitimate Python process under the developer’s own account. Signature-based detection fails because the payload is obfuscated and changes with each campaign. Behavioral detection struggles because “Python reading files” is exactly what Python is supposed to do.
How FileSure Would Have Prevented It
FileSure Defend operates at the Windows kernel level via a file system filter driver. It intercepts every file operation — open, read, write, delete, create, rename — before the operation completes. This means you can enforce policies like “only these specific programs may read credential files,” regardless of which user account is running them.
Here’s the specific rule configuration that would have stopped this attack:
File name filter: *.pem;*.key;id_rsa;id_dsa;id_ecdsa;id_ed25519;credentials;.env;.npmrc;.pypirc;.aws\*;.ssh\*;.docker\*
Program name filter (allowed): \ssh.exe;\aws.exe;\docker.exe;\code.exe;\pycharm64.exe (the legitimate tools that need credential access)
Operations: Read
Drive type: Hard drives
Action: Block and log
With this rule active, the Shai-Hulud payload would have executed normally — Python would have started, the .pth hook would have fired, Bun would have downloaded and launched. But the moment the malware tried to open ~/.aws/credentials or .ssh/id_rsa, the file read operation would have been blocked at the kernel level. The malware would receive an access-denied error. No credentials stolen. Attack contained.
The developer would see a FileSure alert showing that an unauthorized program (the Bun runtime or Python itself, depending on the process tree) attempted to read a protected credential file. Investigation follows. The malicious package gets identified and removed. But the credentials never left the machine.
This approach works because it doesn’t depend on recognizing the malware. The payload can be obfuscated, polymorphic, or brand new. The fact remains: if it can’t read the credential files, it can’t steal the credentials. You’re enforcing a simple, durable policy at the layer where the attack must succeed — the file system.
FileSure Defend runs on all Windows versions, including the older systems that modern EDR tools won’t touch. It’s a kernel filter driver, not a userland agent, which means the malware can’t bypass it by manipulating processes or API calls. Every file operation goes through the kernel. Every file operation gets evaluated against your policies.
If you’re responsible for developer workstations, CI/CD infrastructure, or any environment where credentials live on disk, you need kernel-level file access control. Start a free trial at bystorm.com and see how many unauthorized credential reads are happening in your environment right now.
Source: New Shai-Hulud attack trojanizes 19 science-focused PyPI packages
Category: Threat Intelligence
Tags: shai-hulud, supply chain attack, pypi, credential theft, developer workstation security, kernel filter driver, file system security, python malware
