ReversingLabs researchers have recently uncovered a malicious open-source package known as xFileSyncerx on the Python Package Index (PyPI). This particular package, which had been downloaded nearly 300 times, contained separate malicious “wiper” components that initially raised concerns about its potential as an open-source supply chain threat.

However, upon further investigation, it was revealed that the downloader and wipers included in the package were actually created by a cybersecurity professional who was conducting “red team” penetration testing for a client’s Security Operations Center (SOC). This discovery sheds light on a significant challenge faced by firms when it comes to tracking and mitigating open-source threats, specifically the “noise” generated by grayware such as test packages and low-quality, low-distribution malicious packages.

With the increasing attention on open-source and supply chain threats, the low signal-to-noise ratio presented by packages like xFileSyncerx complicates the process of identifying and remediating legitimate threats. This underlines the importance of a more robust system for differentiating between harmless test packages and actual malicious threats in order to enhance the security posture of organizations operating within the open-source ecosystem.

ReversingLabs researchers regularly scan open-source repositories like npm, GitHub, and PyPI for suspicious and malicious packages using their Spectra family of software supply chain security technology. By identifying characteristics that correlate with malicious or compromised code, such as communication with predefined external servers or dependencies on known malicious packages, they are able to uncover potential threats before they become widespread.

One common red flag that researchers look for is code obfuscation, which was present in the xFileSyncerx package. The obfuscated code within the package contained a malicious download URL stored as a sequence of characters inside an array that was further obfuscated with bitwise shifts. Once de-obfuscated, this URL led to a file hosted in a GitHub repository.

The file, named s2.py and downloaded by xFileSyncerx, represented the second-stage malware in the chain. Actively maintained on GitHub by the user d3duct1v with more than 20 commits since its initial posting, s2.py encrypted files within the /home directory using the Fernet symmetric encryption algorithm. This encryption process excluded hidden files and directories to ensure the integrity of SSH functionality for further malware operations.

Following the encryption process, the s2.py malware attempted to spread across local networks using hard-coded SSH credentials. Success in this endeavor would trigger the download and execution of a third-stage malware, s3.py, which contained only wiper functionality. The presence of hard-coded credentials and IP addresses suggests the possibility of a targeted attack or a testing environment.

Upon deeper investigation, ReversingLabs engaged with the individual behind the d3duct1v account and confirmed that the xFileSyncerx package was part of a red team assessment conducted to evaluate the client’s SOC’s ability to detect suspicious activities and lateral movement. The author had intended to remove the package before ReversingLabs’ intervention, and both the xFileSyncerx package and associated malware were subsequently removed from PyPI and GitHub.

The incident surrounding xFileSyncerx underscores the issue of increasing “noise” on open-source repositories and the challenges it poses for threat assessment and detection in the face of supply chain attacks. Red team packages like xFileSyncerx contribute to this challenge, highlighting the need for clearer guidelines and better demarcation of test and grayware packages to avoid confusion among developers and security teams.

While xFileSyncerx may not have been the next “Mirai” or part of a significant supply chain attack, its discovery serves as a stark reminder of the complexities and challenges inherent in monitoring open-source repositories for potential threats. This incident emphasizes the necessity for improved practices in publishing and identifying test packages to safeguard the security and integrity of open-source ecosystems in the future.

Source link