Software supply chain research, created GitHax, threat intel platform for supply chain threats and former founder of SecureStack. Author of open-source projects like the DevSecOps Playbook, TVPO threat modelling framework, and more.
Submissions
North Korean Hackers Compromise Go and PHP Packages
opensourcemalware.com
11 points·by 6mile··1 comments
NPM attack targets Zapier and security tool browser extensions
opensourcemalware.com
5 points·by 6mile··1 comments
Microsoft Compromised Again. Shuts Down Azure Function GitHub Actions
opensourcemalware.com
49 points·by 6mile··2 comments
More live NPM packages attributed to Axios threat actors
opensourcemalware.com
3 points·by 6mile··1 comments
Popular Kubernetes Networking Project Antrea Compromised
opensourcemalware.com
3 points·by 6mile··1 comments
Popular Kubernetes Networking Project Antrea Compromised
opensourcemalware.com
2 points·by 6mile··0 comments
Intercom-client NPM package and lightning PyPI packages compromised
opensourcemalware.com
2 points·by 6mile··1 comments
Bitwarden CLI NPM package has been compromised
opensourcemalware.com
16 points·by 6mile··1 comments
Vercel Incident Response Playbook
github.com
7 points·by 6mile··4 comments
GitHub Accounts Compromised
opensourcemalware.com
13 points·by 6mile··2 comments
Neutralinojs developer framework compromised with malware
opensourcemalware.com
1 points·by 6mile··0 comments
Malicious skills targeting Claude Code and Moltbot users
Because the Go and Packagist registries don't require additional publishing credentials like NPM and PyPI North Korean threat actors have been able to compromise legitimate packages via their PolinRider campaign.
NPM attack targeting Mastro targets browser extensions other than crypto wallets.
- Credential managers and MFA authenticators from LastPass, Bitwarden, 1Password, Deloitte, Dashlane, ExpressVPN, KeePass, Proton, Kaspersky, passbolt, NordPass, Zoho, etc.
- Zapier browser extension. Assuming this is to gain access to platforms the victim has integrated with Zapier
The same threat actor that compromised Axios published three additional NPM packages within 18 hours. Unfortunately, these packages are still alive on NPM and compromising victims.
If you are a Kubernetes shop, you will want to check whether you are using the Antrea project. Nothing malicious has been deployed yet, as we caught this one early, but the threat actors compromised the Jenkins build servers, so we expect new malicious releases soon.
First, @Tyriar thanks for being a part of this conversation. I know you don't have to, and I want to let you know I get that you are choosing to contribute, and I personally appreciate it.
The reality is that VS Code ships in a way that is perfect for attackers to use tasks files to compromise developers:
1. You have to click "trust this code" on every repo you open, which is just noise and desensitizes the user to the real underlying security threat. What VS Code should do is warn you when there is a tasks file, especially if there is a "command" parameter in that tasks file.
2. You can add parameters like these to tasks files to disable some of the notification features so devs never see the notifications you are talking about:
"presentation": {
"reveal": "never",
"echo": false,
"focus": false,
"close": true,
"panel": "dedicated",
"showReuseMessage": false}
3. Regardless of Microsofts observations that opening other people's code is risky, I want to remind you that all of us open other peoples code all day long, so it seems a little duplicitous to say "you'd still be vulnerable if you trust the workspace". I mean, that's kind of our jobs. Your "Workspaces" abstraction is great on paper, especially for project based workflows, but that's not the only way that most of us use VS Code. The issue here is that Microsoft created a new feature (tasks files) that executes things when I open code in VS Code. This is new, and separate from the intrinsic risk of opening other people's code. To ignore that fact to me seems like you are running away from the responsibility to address what you've created.
Because of the above points we are quickly seeing VS Code tasks file become the number one way that developers are being compromised by nation state actors (typically North Korea/Lazarus).
This malware is a full-featured RAT that uses Telegram for C2 and is only 143 lines of code. It's "RAT-as-a-library" design means that we are already seeing criminals build more complext, customized malware on top of Scopper.
The undelete package lets you recover NPM packages that have been removed and are no longer in the NPM registry. Works for both the tarballs and metadata. I use it for malware research, but you can use it for whatever you want!
I wrote this blog article to address several misconceptions I hear when I talk to engineering or infosec teams. The problem of malicious software packages isn't really well understood, so I thought I would try and tackle some misconceptions head on. I hope you enjoy it!
Thanks! Lots of tooling out there, but not much uptake. I mean, npm itself has better, more secure alternatives, but is still the most popular registry on the planet. Like, wtf?!
Transitive dependencies, yeah, but top-level dependencies that you are installing with npm i or via your manifest file are areas that you do control and can manage.
It's not a smoking gun. It is just one of a number of signals you look for when identifying potentially malicious packages. Other things you look for are number of collaborators, how long it existed, domains it talks to, and artifacts it pulls in.
Yeah, I agree the incentive structure is broken for bug bounty hunters. Until the BB platforms themselves create some rules for their customers and researchers, we are gonna continue to have the sh*t show that we do now. The reality is that bug bounty hunters are deploying a significant percentage of the total malicious NPM packages each month.
GitHax is a labour of love right now and is in heavy development. I'm going to create a small beta testing group soon. Hit me up if you want to be in that group. Contact deets are in my GH profile.
There has been a lot of noise about software supply chain attacks over the last few years. These threats are often novel, and have colorful names like dependency confusion, repo-jacking, and commit spoofing.
Unfortunately, there is no common, agreed upon definition for what is in the software supply chain. When asked, most people I talked to would say "Uh, its your open-source libraries, right?" This is a problem, as there is a lot more that goes into building modern applications than just some open-source components. To me, the software supply chain should be all those things that are needed to build a working application. This would include things like the software engineers themselves, and the CI/CD components used. The third-parity APIs and cloud resources that the application uses should also be included. We can't hope to know how to secure the software supply chain if we don't know what's in it, or how broad its scope is.
I decided to build a project that would help the software engineering community create a common definition, and lexicon, for the software supply chain. This GitHub repository is the first version of that project.
I am looking for feedback, input, and hopefully some collaboration to help make this a viable, and lasting project. I hope you enjoy it!