The article describes real supply-chain campaigns where attackers hid credential-stealing code inside trusted open-source packages and developer tools. When a developer or CI system installed the package, the malware ran immediately, stole cloud and pipeline credentials, and enabled unauthorized cloud activity using valid access. The key message is that removing the bad package is not enough, teams must rotate exposed credentials and investigate what those credentials could access in the cloud.
Key findings
- Install-time scripts in malicious packages can steal secrets before any application runs.
- Stolen developer/CI credentials can be used to access cloud resources with valid accounts, making the cloud the true blast radius.
- Campaigns described include compromised npm ecosystems, malicious Ruby gems and Go modules, and tampered CI/CD tooling.
- Containment requires credential revocation/rotation and reviewing cloud audit activity, not just removing the package.
Who’s being targeted
- Commonly targeted roles: Developers, DevOps / CI-CD Engineers, Application Security, Cloud Security, Engineering Leadership.
- Affected industries: Software development, Technology / SaaS, Cloud services, DevOps / CI-CD operations, Open-source ecosystems.
- Attack channels: github, website.
- Impersonated: A trusted npm package in the @ctrl / @antv ecosystem, Developer utility packages (Ruby gems / Go modules) published from “BufferZoneCorp”, Trusted developer/security tooling used in CI/CD.
Awareness takeaways
- Treat dependency installs as a high-risk action because malware can run before the app ever starts.
- If a build runner or developer machine ran an untrusted package, rotate/revoke all credentials it could access and review cloud logs for misuse.
- Reduce the blast radius by limiting CI/CD secrets and using short-lived cloud credentials wherever possible.
- Watch for cloud pivots after credential theft by monitoring audit logs and alerting on unusual API calls made with valid credentials.
Red flags to watch for
- Unexpected network activity during dependency install
- Install scripts running even when the install is canceled
- New or unexpected GitHub repository activity tied to the developer account
- Package publisher/account is unfamiliar or newly created
- Install changes system settings (PATH/GOPROXY) or writes to SSH authorized_keys
- Checksum verification disabled or warnings suppressed during install
- Unexpected force-pushes or tag changes in repositories
- Secrets exposure despite GitHub masking (suggesting memory scraping)
- Unexplained cloud API calls made with legitimate credentials shortly after pipeline runs
Read the video transcript
You run npm install, it fails, you shrug it off. But that failed install might’ve just logged into your cloud. In the Shai-Hulud campaign, a poisoned @ctrl/tinycolor package ran a preinstall hook that stole cloud and CI secrets, then pushed them to a public GitHub repo created under the victim’s own account. Another campaign used a GitHub account called BufferZoneCorp to ship fake Ruby and Go utilities. During install they grabbed env vars, rewrote GOPROXY, and even added an SSH key to ~/.ssh/authorized_keys on build hosts. If any untrusted package ever ran on your dev box or CI, don’t just uninstall it, immediately rotate those credentials and review your cloud audit logs for weird API calls.