A malicious Python file found on the PyPI repository adds backdoor and data exfiltration features to what appears to be a legitimate SDK client from SentinelOne.

A malicious Python package is posing as a software development kit (SDK) for the security firm SentinelOne, researchers at ReversingLabs discovered. The package, SentinelOne has no connection to the noted threat detection firm of the same name and was first uploaded to PyPI, the Python Package Index, on Dec 11, 2022. It has been updated 20 times since, with the most recent version, 1.2.1, uploaded on Dec 13, 2022. 

The package appears to be a fully functional SentinelOne client, but contains a malicious backdoor, according to ReversingLabs threat researcher Karlo Zanki. The malicious functionality in the library does not execute upon installation, but waits to be called on programmatically before activating - a possible effort to avoid detection. We are calling this campaign "SentinelSneak."

The SentinelOne imposter package is just the latest threat to leverage the PyPI repository and underscores the growing threat to software supply chains, as malicious actors use strategies like “typosquatting” to exploit developer confusion and push malicious code into development pipelines and legitimate applications.

Background

The ReversingLabs research team is continuously monitoring open-source package repositories for instances of malicious code and software supply chain attacks. This work involves both automated and human-led scanning and analysis of packages published in the most popular public package repositories like NPM, PyPI, Ruby and NuGet. 

During these scans, we leverage our proprietary Titanium platform, and our deep file repository of goodware and badware to spot malicious and even suspicious elements hiding in plain view. Our ReversingLabs secure.software solution builds upon that past work. The platform provides a way for dev and SOC teams to deeply examine their CI/CD workflows, containers and release packages to spot nascent or active software supply chain compromises.

Frequently, our work turns up evidence of active software supply chain attacks. In April, for example, we came across NPM packages that used a javascript obfuscator to hide their functionality. Our analysis of those packages produced proof of simulated “dependency confusion” attacks on the software supply chain of leading German companies across a number of industries. (That campaign turned out to be the product of an authorized “red team” exercise conducted by a security firm on behalf of its customers.)

In July, a similar inquiry uncovered a wide ranging campaign on the npm platform we dubbed “IconBurst.” That campaign employed a technique known as “typosquatting,” with many of the malicious packages using naming that was similar to popular npm packages offering icons for use in graphical interfaces. We wrote about another typosquatting campaign dubbed “Material Tailwind” in September, also on the npm platform. That included a malicious npm package masquerading as a development tool for Tailwind CSS and Material Design, two popular npm packages. That malicious package included a post-install script that downloaded a malicious executable capable of running PowerShell scripts on systems that installed the Material Tailwind package.  

PyPI saw less malicious activity relative to npm. In fact, our State of Software Supply Chain Security report found that, in contrast to npm, the PyPI repository saw a nearly 60% decrease in malicious package uploads this year, going from 3,685 in 2021 to 1,493 packages through the first 10 months of 2022. But malicious PyPI activity since 2020 is still way up (there were just eight malicious packages detected in 2020). And recent weeks have seen a number of malicious campaigns on PyPI, including a campaign of malicious packages distributing the W4SP stealer malware. 

We are continually tracking PyPI repositories for suspicious behaviors. And those efforts led to the discovery of our most recent malicious package, which attempts to hijack the name of a respected cybersecurity firm, SentinelOne.

Discussion

The core capability of ReversingLabs’ secure.software solution is analyzing code intent while highlighting malicious behaviors. These indicators cover all kinds of software behavior, from network and file system activities to use of packers associated with malicious campaigns, and the use of evasion techniques.

Red flags in allegedly ‘commercial’ module

In the case of the SentinelOne PyPI package, our researchers were tipped off by telltale suspicious behavior including the execution of a file, the spawning of new processes and the presence of URLs that reference a host by IP address. 

Figure 1: PyPI package without description is always suspicious

Even a cursory glance at the SentinelOne PyPI package raises red flags. The project page has a very rudimentary look with no description of the SentinelOne package and a maintainer account that was created only days before the initial package was uploaded. While such behaviors are sometimes observed in legitimate modules, this is not behavior that would be expected from a commercial software vendor of SentinelOne’s stature. 

Taking a look at the SDLC (software development lifecycle) report generated with ReversingLabs secure.software platform provides clues that helped to quickly pinpoint the location of the malicious content in the counterfeit SentinelOne package. In the following sections, we'll discuss that in more detail.

Why SentinelOne? 

The most obvious point is that the SentinelOne PyPI package we discovered has no connection to SentinelOne, the respected cybersecurity firm that offers threat detection and response capabilities. It appears that the malicious actor(s) behind the SentinelOne PyPi package are attempting to draft on SentinelOne’s strong brand recognition and reputation. The malicious PyPI package poses as an SDK that will abstract access to SentinelOne’s APIs and make programmatic consumption of the APIs more simple.

Funky functionality

The first clue that something was amiss with the SentinelOne PyPI package was that most of the “interesting” behaviors detected by TitaniumPlatform were concentrated in just two api.py files, out of more than 100 code files in the project. Especially interesting was the combination of the detected behaviors which includes enumeration of files in a given directory, deleting of a file/directory and creation of a new process. When such behaviors are combined with the presence of a URL which references the host by IP address, you can mark that module as suspicious. Referencing the host by an official domain would be expected from a commercial product.  

Figure 2: Interesting behavior indicators triggered on api.py files

That sense was confirmed when we compared the differences between roughly 20 versions of the SentinelOne PyPI package uploaded over the course of two days. Only one python source code file changed between the versions out of the scores of files that make up the package. Which package? You guessed it: api.py.

Figure 3: Data exfiltration URL from api.py files

The second “red flag” was the discovery of networking strings in the code of the two api.py files. As mentioned earlier, one of the things that triggered our threat detection heuristics was the presence of URLs that reference the host by an IP address that was not affiliated with the company SentinelOne.

Figure 4: Behavior differences between two of the package versions

The api.py files were also where we located the malicious code. A detailed analysis of that code revealed capabilities that are focused on exfiltration of data that is characteristic for development environments. 

Figure 5: Data exfiltration

In the above screen grab, for example, we see the malicious code for collecting information about shell command execution history as well as the contents of the .ssh folder containing ssh keys and configuration information, including access credentials and secrets, related to git, kubernetes and AWS services. 

The code likewise performs a directory listing of the root directory. The collected data is then exfiltrated to the command and control (C2) server. Though clearly malicious, the counterfeit SentinelOne package is selective: taking only what is needed, and focusing on the subset of services that are found on machines used for software development. 

Figure 6: Anomalies in module naming

Further analysis of the changes between the versions of the counterfeit SentinelOne module shows that the attacker modified its functionality to adapt to targets. For example, initial versions of the module didn’t make any distinction based on the operating system in which they were executed. But it seems that version of the data collection algorithm didn't work correctly if it was executed in the Linux environment, based on hardcoded paths to targeted directories. Those issues were fixed in later versions and the malware’s data stealing capabilities were expanded with subsequent releases.

Figure 7: Adapting malicious code based on host environment

During development, the malicious actor published five additional packages with similar naming variations, which were used for testing purposes and did not contain api.py files with malicious functionality. These packages were published between December 8th and 11th, 2022. ReversingLabs reported the incident to the PyPI security team on December 15th, 2022, and SentinelOne was notified on December 16th, 2022. 

IOCs

Data exfiltration IP address:

54.254.189.27

PyPI packages:

SSL certificate:

A self-signed SSL certificate was associated with the 54.254.189.27 IP address. Since the data exfiltration uses https protocol and there is a high correlation between the certificate issue and package publishing dates, it is very likely that the certificate is related to this campaign.

Conclusion

The SentinelOne PyPI package is a malicious module that attempts to exploit the name and reputation of the cybersecurity firm SentinelOne. The module appears to have been built on top of legitimate SentinelOne SDK client code, likely obtained from the company by way of a legitimate customer account. 

It contains a backdoor as well as information stealing capabilities. The malicious functionality was placed in the package through the addition of two Python modules, both api.py files. The malicious code appears designed to siphon sensitive information from development environments, according to an analysis by ReversingLabs.

Based on our analysis of the malware and the associated C2 infrastructure, it is unclear if this package was or is being used in active attacks against development environments. We found no evidence of such attacks. However, download statistics from PyPi suggest that the package was downloaded more than 1,000 times. ReversingLabs notified PyPI and SentinelOne about our discovery and the presence of this malicious package in the PyPI repository. 

This latest discovery underscores the ongoing threat of malicious code lurking on open source repositories such as PyPI, npm, RubyGems, GitHub and more. As with prior malicious open source supply chain campaigns, this one attempts to exploit confusion on the part of developers to push malicious code into development pipelines. In this case, the attackers attempt to leverage the name and reputation of SentinelOne, a highly respected cybersecurity firm, to fool users into downloading a malicious payload that includes a backdoor. 

Also like prior incidents, this discovery shows telltale signs of malicious activity, including the execution of a file and use of URLs in the code that reference a host by IP address, rather than a DNS host name. 

Though small in scope, this campaign is a reminder to development organizations of the persistence of software supply chain threats. As with previous malicious campaigns, the "SentinelSneak" campaign plays on tried and true social engineering tactics to confuse and mislead developers into downloading a malicious module. To counter such attacks, development organizations need to invest more heavily in training and awareness campaigns that ensure developers will not fall for typosquatting and other impersonation attacks. It also highlights the need for tools and processes to ensure that any open source or proprietary code is evaluated for the presence of suspicious or malicious indicators including hidden (obfuscated) functionality, unexplained communications with third party infrastructure and more.