Threat Actor Continues to Plague the Open-Source Ecosystem with Sophisticated Info-Stealing Malware

In May, we sounded the alarm about PYTA31, an advanced persistent threat actor distributing the “WhiteSnake” malware. Since then, we’ve been rigorously monitoring this group, which has been active from April through mid-August, distributing malicious PyPI packages laced with “WhiteSnake Malware.” 

WhiteSnake Malware, also known as the “WhiteSnake Stealer”, first appeared on hacking forums in early 2022. Its main objective: Stealing data from various browsers and applications. 

Key Points

• Threat actor PYTA31 has continuously distributed “WhiteSnake” malware through malicious packages in the PyPI repository from April through mid-August.
• The malware contains the capacity to target multiple operating systems.
•   The malware uses a complex exfiltration mechanism, uploads and sends bulk data via a file-sharing service, and sends the link to the data using a telegram channel to avoid detection. 
• The malware also downloads a legitimate OPENSSH that connects to serveo.net to maintain control on Windows machines.
• The end goal of this malware is to exfiltrate sensitive and particularly crypto wallet data from the target machines through multiple Command and Control (C2) servers.
• Checkmarx’s Supply Chain Intelligence customers are protected against these attacks.

Dissecting the Malicious Payload

The nefarious code is cunningly hidden within the setup.py file of the package. It’s base64 encoded and designed to execute OS-specific code upon installation on the victim’s machine.

Linux Specific Code

The code targeting Linux systems was designed to hide its intent from the average developer to understand what the code does.

Using Obfuscation

The code is filled with single-letter variables and complex functions. However, a closer look reveals its malicious intent: unauthorized data gathering, system information collection, and data upload to remote servers. 

We cleaned this script up so that it is more readable and easier to understand, let’s go over the main parts of this script:

Platform Specificity:

The script verifies if it’s running on a Linux system. If not, it exits, limiting its operation to the intended target.

Systems Information Gathering:

The script continues, collecting basic system details like the target’s public IP address, Internet Service Provider (ISP), username, computer name, and operating system. If it detects certain ISPs such as Google or Mythic Beasts, it terminates immediately – likely an anti-analysis technique. If possible, the script also takes a screenshot of the current state of the target’s computer.

Targeted Data Theft:

The script uses hard-coded XML commands to specify which files or directories to steal. This includes browser data, application configurations, and cryptocurrency wallet files.

Data Encryption and Compression:

The gathered data is compressed and encrypted before exfiltration in an attempt to evade basic security mechanisms. 

Data Upload and Notification via Telegram:

The zip archive is then uploaded to an external server via transfer.sh, a simple file-sharing service. It uses the following naming mechanisms for these archives: {username}@{hostname}.wsr

Finally, a Telegram message is sent to a specified Telegram chat, notifying them that the data is ready for download. The message includes a unique URL to the uploaded data.

Window Specific Code

If the system running the package was a Windows NT machine, the package creates a random directory in the temp folder of the current user and generates a Windows executable file with pre-written code and provides it with a long complex name which is then executed. An example of this implementation in one of the packages: “e8d74164335ac04bb4abef4671e98ef.exe”. 

Here, the malware adopts a similar strategy to the Linux specific code, but with some nuanced differences:

• It creates a scheduled task that runs the malicious executable at a fixed time interval.
• It downloads an official copy of OPENSSH for port forwarding the compromised host’s local port 80 using “[serveo.net](http://serveo.net/)“.
• The gathered information is zip archived with a “.wsr” extension and then uploaded to remote URLs in the following format http://{ip-address}:{port}/{archive_name}.wsr. (example: http://81.24.11.40:8080/LdBzv_azure%40AZURE-PC_report.wsr)

Conclusion

This episode reiterates the imperative for vigilance in vetting open-source packages. It also underscores once again the persistence of adversaries who execute meticulously planned and long-term attacks. We are not just dealing with a package problem. We are dealing with an adversary problem.

Mere reactive countermeasures, like deleting malicious packages, offer only temporary relief. a more proactive, sophisticated strategy is what’s needed to protect against these unrelenting threats.

For any queries or package needs, feel free to contact us at supplychainsecurity@checkmarx.com

Together, let’s work to keep the ecosystem safe.

Packages

IOC

• 195[.]201[.]135[.]141
• 135[.]181[.]98[.]45
• 141[.]95[.]160[.]216
• 81[.]24[.]11[.]40
• 51[.]178[.]53[.]191
• 46[.]226[.]106[.]173
• 5[.]135[.]9[.]248
• hxxps[:]//api.telegram[.]org/bot6414966437:AAHtThsoeAj36fZY4941ZVfnzRpMQXVXz_Y
• e0ab9cb803607ae567be2c05100b818c90f21161918ea5a55b999f88d0b99e94
• 46dfc336088c6f5f725c0909ed32dbb8a5fcb70b045fea43d3c5e685322d492f
• 1090a8d1ba7d8464488d6810e8a71d34f6e00d8a9611382319ef69112382561e