W4SP Stealer: Why Discord Malware Could Already Be in Your Python Code
We first reported on W4SP Stealer in November in response to widespread news of a new Python supply chain attack. Unfortunately, as it so often happens, W4SP Stealer looks like it’s here to stay – and will continue to plague Python code packages across the globe.
In this article, we’ll revisit the origins of W4SP Stealer, explain how its infiltration of PyPI makes it a threat to Python developers everywhere, and explain why due diligence is still your best defense.
What Is W4SP Stealer?
The malware involved in this big story, W4SP Stealer, has been around for an unknown period. At one point, the code for the trojan was freely available on GitHub, but the community caught up with it and deactivated the GitHub page (even though, reportedly, it’s still available for $20 a pop – payable in crypto or gift cards – if you know where to look).
From reports, we learn that W4SP Stealer was typically spread through phishing campaigns or by exploiting vulnerabilities in software. At one point, it was spreading through a TikTok challenge.
The information that W4SP Stealer can collect varies, but can include credit card information and passwords. The malware can also go after crypto wallets and Discord tokens. In fact, it can slurp up any file that could seem useful. It’s published by someone calling themselves names like billythegoat356, BillyV3 and BillyTheGoat.
How Did W4SP Stealer End Up in the Python Supply Chain?
Reports about W4SP infiltrating the Python code supply chain started to become loud and clear through November and December 2022… but it was, in fact, first detected in August 2022. It was a company that helps developers secure the software supply chain, called Phylum, that first made the discovery.
The malware was discovered in packages delivered on the Python Package Index (PyPI). PyPI is a repository of Python software packages where users can easily download and install packages and modules created by the Python community, including third-party libraries, tools, and applications. It’s a central location for users to find and share reusable code, speeding up the development process.
However, it’s very hard to consistently monitor a package ecosystem. You need a lot of resources to do so, and that’s where Phylum comes in. In post after post, the Phylum research team reported how the sponsors of W4SP Stealer managed to evade elementary detection mechanisms to inject malicious code into PyPI packages.
The net result is that Python developers deploying any of a long list of PyPI packages in their code will have inadvertently also included code for W4SP Stealer. Packages like modulesecurity, informmodule and randomtime contain W4SP Stealer code and have been used by countless developers.
Supply Chain Attacks (Nothing New to See Here)
A software supply chain attack is where an attacker infiltrates the software development process to introduce malicious code or exploit vulnerabilities. It can be launched at any stage of the supply chain, including the components, third-party libraries and dependencies used, the building and packaging process, and even the distribution of software updates.
So, something with malicious intent, like W4SP Stealer, can get through to package listings, the same listings that developers browse to find libraries to simplify their work. And W4SP Stealer proves that where developers don’t do their due diligence, they can end up getting more than they bargained for and consequently ship malicious code inside an application.
What can developers do to perform due diligence?
- Conduct background checks: It’s a tough one to do when in a rush, but it is important. A developer must verify third-party vendors, including those posting to package repositories such as PyPI, to ensure that they have a good security track record. Watch out for tampering too.
- Use secure build pipelines and encryption: Make use of automated code checks and vulnerability scans to identify any potential security threats. Encrypt software packages before distribution and use digital signatures to verify their authenticity.
- Monitor software dependencies: Keep track of the software dependencies and packages you use, regularly check for vulnerabilities in the dependencies, and regularly apply any recommended updates to make sure vulnerabilities are patched.
- Educate your team: All the members of the development team must be aware of the risks across the software supply chain and must understand that just because a package in a package repository is popular and well-presented does not mean that it is safe.
It’s an extensive process and a long way away from the old days when developers could simply use packages to speed up their work without worrying about the consequences too much.
Get Your Foundations Right
At TuxCare, we’re advocating for secure development processes across the SDLC. The development environment is complex, with many moving parts, and it is unquestionably tough for under-pressure developers to make sure that cybersecurity prerogatives are always accounted for.
That’s why it’s no surprise that threat actors find a way past even conscientious developers. Though, that said, sometimes development teams leave the door wide open by working with unreliable code sources, relying on out-of-date language versions, and so forth.
While TuxCare can help you with out-of-date Python through our Extended Lifecycle Support, the rest of it is up to you and your development team. Your best course of action: follow our tips above, and follow the news to stay ahead of major events.