W4SP continues to nest in PyPI: Same supply chain attack, different distribution method

Days after researchers for Phylum and Checkmarx revealed an ongoing software supply chain attack spreading the W4SP Stealer malware through malicious packages on the Python Package Index (PyPI), ReversingLabs researchers discovered 10 additional PyPI packages pushing modified versions of W4SP that were overlooked.

The newly discovered packages appear to be part of the same campaign but are using slightly modified versions of the W4SP Stealer malware and different command and control infrastructure.

Here's our discoveries, indicators of compromise (IOCs), and ReversingLabs YARA rules that can be used to detect the malicious packages in your environment. 

Introduction

In the beginning of November several malicious python packages distributing the W4SP malware were found in the Python Package Index (PyPI) open source repository. These packages contain malicious code, hidden inside __init__.py or setup.py scripts, which downloads a stage 2 payload from a remote location. Stage 2 payload is W4SP stealer capable of stealing a wide range of sensitive data including stored passwords, cookies, Discord tokens, crypto wallets, telegram data and a long list of files related to different web services. This Python malware contains several layers of obfuscation in order to avoid detection. More details can be found in Phylum and Checkmarx reports. 

Despite the disclosure by Phylum and Checkmarx, this supply chain attack is ongoing. Further investigation by ReversingLabs has uncovered 10 previously undisclosed Python packages that appear to be part of the same campaign, but that are pushing a slightly modified version of the W4SP Stealer and relying on a different command and control (C2) infrastructure.

Same attack, different downloader 

The architecture of the attack uncovered by ReversingLabs is the same as the attack documented by Phylum and Checkmarx. PyPI packages are infected with downloader code and published to the PyPI repository. The malicious code executes upon package installation and downloads an obfuscated stage 2 payload from a remote location and loads it on the infected machine. W4SP Stealer, the stage 2 malware, is capable of stealing sensitive data and exfiltrating it to a remote location.  

The versions of the malicious modules ReversingLabs discovered differ from those identified by Phylum and Checkmarx in a number of ways. Previous downloaders were embedded in PyPI package __init__.py scripts and in some cases setup.py scripts and were downloading stage 2 payloads from urls similar to the following: 

hxxp://wasp.plague.fun/inject/<random_string>

Transfer.sh: Malware distribution made easy

However, samples discovered during our research were using the public file sharing service transfer.sh to deliver W4SP Stealer. This service provides “easy file sharing from the command line.” It is convenient from an attacker's perspective because it is very friendly for command line scripting and allows uploading up to 10GB of data which can be stored for up to 14 days, for free. What is even more convenient is the ability to define a maximum number of downloads. Such a feature can be used to assure malware gets downloaded only once, ideally by the targeted victim, before it gets removed from the remote location, preventing security researchers from getting their hands on malicious samples. The sample download and execution is performed in a large powershell one-line command. (Figure 1.)

Figure 1: Stage 2 downloader code

In the observed samples, files hosted on transfer.sh service were typically named Updater.zip or transfer.zip. This is the YARA rule that can be used to hunt such downloader python scripts:

rule transfer_sh_url

{

    strings:

        $updater_url =  { 3A 2F 2F 74 72 61 6E 73 66 65 72

                          2E 73 68 2F ?? ?? ?? ?? ?? ?? 2F 

                          55 70 64 61 74 65 72 2E 7A 69 70 }

        $transfer_url = { 3A 2F 2F 74 72 61 6E 73 66 65 72

                          2E 73 68 2F ?? ?? ?? ?? ?? ?? 2F 

                          74 72 61 6E 73 66 65 72 2E 7A 69 70 }


    condition:

        $updater_url or $transfer_url

}

W4SP reloaded: expanded data stealing options

In all samples, the entrypoint for the W4SP Stealer payload is in server.pyw file. This file contains a large LZMA compressed and Base64 encoded file which is a minify-ed version of the original payload created using the pyminifier application. 

Figure 2: Stage 2 entrypoint before decoding and decompression

After decompression and decoding are performed, the original code is executed. The main function sets up the persistence and threads responsible for keylogging and data stealing.  

Figure 3: Main function

An interesting feature of the W4SP Stealer is that there are two mechanisms for data exfiltration. The first uploads stolen data to the tranfer.sh service and sends the download url to the threat actor controlled C2 server together with the information about the infected machine. You can see this part of code in Figure 4, together with the calls to data stealing functions to get a sense about the type of data that gets stolen.

Figure 4: Data exfiltration using transfer.sh service

The second data exfiltration mechanism is based on Cloudflare’s reverse tunnels. The malware first downloads Cloudflare Tunnel client (formerly Argo Tunnel) from their GitHub repository. Then it creates a reverse tunnel and sends the generated tunnel’s URL to the same threat actor-controlled C2 server mentioned in the first case.    

 Figure 5: Data exfiltration using reverse cloudflare tunnel

The Flask micro web framework is then used to create a local web server which responds to the requests received through the created tunnel. URL paths are created in a modular way, so each functionality could be executed on its own. This activity can be seen in Figure 6, where the paths are the strings inside the @app.route() annotations. This is another example of malicious actors abusing commercial services to further attacks and data exfiltration with tools like reverse tunnels, an increasingly popular technique among malware authors.

Figure 6: Url paths defined using Flask framework

A new RUST downloader

As part of our research, we also employed the ReversingLabs Titanium Platform’s  RetroHunt feature, which can test YARA rules against recent file samples submitted to us. The results of that scan included several Python scripts which were expected since the campaign was targeting PyPI users, but also an unexpected Windows PE (portable executable). That sample executes a Powershell block very similar to the one documented above and seen in the PyPI downloader packages. (Figure 7.)

Figure 7: Powershell code snippet responsible for downloading Stage 2 payload

Strings from the executable lead us to the conclusion that this sample was written in Rust. This, again, is consistent with recent trends among malware authors, who are turning to rust to create ransomware and other malicious applications. 

The compilation timestamp on the Rust downloader also helps to confirm the timeline for this PyPi campaign. Specifically: the sample we observed was created on September 25th 2022. That is the same date on which the first PyPI package observed as a part of this research — pygradient — was published. 

The malicious packages ReversingLabs discovered predate those discovered by Phylum by weeks. According to that company’s blog, the supply chain attack started “around October 12, 2022” but intensified in the third week in October, before it was detected. Phylum did mention, as well, a small set of malicious PyPI packages with similar IOCs it discovered that date to July, 2022. 

That suggests the September packages were part of a larger and longer running campaign. One possible explanation is that the packages we discovered were used to test functionality before the actual launch of the malicious campaign in October. Another possibility is that the packages we discovered are artifacts of a real malicious compromise that has not been disclosed. Unfortunately typical pivoting attempts like searching on file similarity and section hashes didn’t have any results so no additional samples were discovered, so there are many questions that remain unanswered at this time.  

Conclusion

Our discovery of an earlier tranche of malicious PyPI packages expands our understanding of this latest software supply chain attack on the PyPI platform. It is also a reminder to organizations that the mere discovery and disclosure of supply chain attacks and compromises is not enough to end such attacks, or prevent malicious actors from continuing their work. 

Based on our findings, the W4SP Stealer malware campaign exposed by Phylum and Checkmarx in October started on September 25th and had its climax a month later, in late October. Based on Phylum data, the campaign may stretch back even further, to July, 2022. Still, it is alive and active today, with new PyPI packages published on a daily basis. 

This is similar to the behavior we have seen with earlier supply chain attacks, such as IconBurst, where new, malicious packages consistent with the IconBurst campaign have continued to turn up in the months following initial discovery of that campaign on the npm platform. 

As this incident and incidents like IconBurst reveal: Disclosure of supply chain attacks might fail to capture the full breadth of malicious campaigns. At the same time, malicious actors may continue to publish new malicious packages during and even after the campaign has been exposed. To counter these threats, development organizations and their customers have to remain vigilant: scanning open source packages for malicious functionality and being on the lookout for other supply chain attacks including dependency confusion, typosquatting and more. 

Indicators of Compromise (IOC) list

C2 IP address:

206.189.80.30

185.112.83.115

PyPI packages:

Stage 2 zip archives SHA1:

Executable downloader SHA1:

f6849ddf8b5f043b7499e239092ffeee91da2e47

[ Open-source protection: ReversingLabs YARA Rules GitHub page ]