XMRig-CoinminerExecutive Summary

Introduction to Malware Binary Triage (IMBT) Course

Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor of the Malware Binary Triage (IMBT) course starting this Black Friday and Cyber Monday!

Enroll Now and Save 10%: Coupon Code MWNEWS10

Note: This is an affiliate link – your enrollment helps support this platform at no extra cost to you.

On December 4, a malicious version 8.3.41 of the popular AI library ultralytics — which has almost 60 million downloads — was published to the Python Package Index (PyPI) package repository. The package contained downloader code that was downloading the XMRig  coinminer. The compromise of the project’s build environment was achieved by exploiting a known and previously reported GitHub Actions script injection.

Discussion

On December 4th, a new version 8.3.41 of a popular AI library ultralytics was released on GitHub and also published to PyPI package repository. Similar to a recent RL research team post regarding the aiocpa incident, the content in the GitHub repository didn’t match the content of the matching PyPI package. Malicious actors managed to compromise the build environment related to the mentioned project and injected the malicious code after the code review part of the process was finished.

What made the ultralytics incident worse: Project maintainers didn’t properly locate the compromise and as a result, on December 5, version 8.3.42, which was supposed to address the incident and serve as a safe version to upgrade from the malicious one, ended up containing the same malicious code. Finally a clean version, 8.3.43, was published on the same day, resolving this supply chain attack.

This supply chain compromise had the potential to impact a huge number of users since ultralytics (see RL Spectra Assure Community listing) is a GitHub project with more than 30,000 stars — and the PyPI package shows about 60 million downloads. 

Infection vector

Unlike the recent compromise of a trusted npm package @solana/web3.js (See Spectra Assure Community listing), which also had a similar impact radius but was caused by a compromise of one of the maintainer accounts, in this case intrusion into the build environment was achieved by a more sophisticated vector, by exploiting a known GitHub Actions Script Injection that was previously reported by the security researcher Adnan Khan.

Comment on the GitHub issue pages explaining the infection vector

Figure 1: Comment on the GitHub issue pages explaining the infection vector

With this GitHub Actions Script injection, a malicious actor can create a fork of any repository that uses ultralytics/actions, and by crafting a pull request from a branch that has injection payload code in its title, he can achieve arbitrary code execution. 

Two maliciously crafted pull requests, #18018 and #18020, were designed to enable backdoor access to the compromised environment. Figure 2 shows the malicious code embedded in the name of the forked branch.

Malicious pull requests designed to trigger execution of the payload code

Figure 2: Malicious pull requests designed to trigger execution of the payload code

The user account behind this pull request, openimbot, and the remote connection that was established after the execution of the malicious payload was initiated from Hong Kong, based on information provided by ultralytics maintainers.

User data behind the malicious pull request

Figure 3: User data behind the malicious pull request

This GitHub user, openimbot, has an interesting contribution history, with a long period of inactivity, between the end of August and beginning of December, when the reported attack was executed. While researchers could conclude that the account was overtaken sometime in this period, that may not be a correct conclusion. 

Contributions history of the openimbot account which initiated the compromise

Figure 4: Contributions history of the openimbot account which initiated the compromise

The RL Spectra Assure platform can help prevent this type of attack and quickly pinpoint the malicious content inserted into the package. Figure 5 shows the file-based behavior differences between non-malicious version 8.3.40 and malicious version 8.3.41.

Behavior differences

Figure 5: Behavior differences between non-malicious version 8.3.40 and malicious version 8.3.41

From the behavior diff, security teams can conclude that the malicious code was inserted into files downloads.py and model.py. Figure 6 shows that the code inserted into the model.py file is designed to check the machine type of the system on which the code is executed. This type of behavior is often used by malware to deliver payload specific to the infected machine. 

New behavior introduced in model.py file

Figure 6: New behavior introduced in model.py file

Inspection of the source code confirms the above assumption. The code designed to download platform-specific payload is visible in Figure 7.

Code responsible for downloading and executing payload

Figure 7: Code responsible for downloading and executing payload

File system-related behavior changes visible in Figure 8 suggest that the code that performs the actual downloading of the file and writing it to disk is located in the downloads.py file. The code difference between downloads.py file from versions 8.3.40 and 8.3.41 confirm that conclusion. 

New behavior introduced in downloads.py file

Figure 8: New behavior introduced in downloads.py file

While in this case, based on the present information the RL research team has, it seems that the malicious payload served was simply an XMRig miner, and that the malicious functionality was aimed at cryptocurrency mining. But it is not hard to imagine what the potential impact and the damage could be if threat actors decided to plant more aggressive malware like backdoors or remote-access trojans (RATs).

Indicators of Compromise (IoCs)

Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach, or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.

The following IOCs were collected as part of RL research team’s investigation of this software supply chain incident.

PyPI packages:

package_name version SHA1
ultralytics 8.3.42 ee304a92a9e68e7923d7a37a370c7556ac596250
ultralytics 8.3.42 7c6136cf4e857582c2f086673359be94e7e4b702
ultralytics 8.3.41 dd0577b10e73792f2b2315af63b872fe4123ec9c
ultralytics 8.3.41 bea3060707e6f3fec47aa2af64ea2e774b56e9f5

Article Link: Compromised ultralytics PyPI package delivers crypto coinminer

1 post – 1 participant

Read full topic

​Executive Summary

Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor of the Malware Binary Triage (IMBT) course starting this Black Friday and Cyber Monday!
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: This is an affiliate link – your enrollment helps support this platform at no extra cost to you.

On December 4, a malicious version 8.3.41 of the popular AI library ultralytics — which has almost 60 million downloads — was published to the Python Package Index (PyPI) package repository. The package contained downloader code that was downloading the XMRig  coinminer. The compromise of the project’s build environment was achieved by exploiting a known and previously reported GitHub Actions script injection.
Discussion
On December 4th, a new version 8.3.41 of a popular AI library ultralytics was released on GitHub and also published to PyPI package repository. Similar to a recent RL research team post regarding the aiocpa incident, the content in the GitHub repository didn’t match the content of the matching PyPI package. Malicious actors managed to compromise the build environment related to the mentioned project and injected the malicious code after the code review part of the process was finished.
What made the ultralytics incident worse: Project maintainers didn’t properly locate the compromise and as a result, on December 5, version 8.3.42, which was supposed to address the incident and serve as a safe version to upgrade from the malicious one, ended up containing the same malicious code. Finally a clean version, 8.3.43, was published on the same day, resolving this supply chain attack.
This supply chain compromise had the potential to impact a huge number of users since ultralytics (see RL Spectra Assure Community listing) is a GitHub project with more than 30,000 stars — and the PyPI package shows about 60 million downloads. 
Infection vector
Unlike the recent compromise of a trusted npm package @solana/web3.js (See Spectra Assure Community listing), which also had a similar impact radius but was caused by a compromise of one of the maintainer accounts, in this case intrusion into the build environment was achieved by a more sophisticated vector, by exploiting a known GitHub Actions Script Injection that was previously reported by the security researcher Adnan Khan.

Figure 1: Comment on the GitHub issue pages explaining the infection vector
With this GitHub Actions Script injection, a malicious actor can create a fork of any repository that uses ultralytics/actions, and by crafting a pull request from a branch that has injection payload code in its title, he can achieve arbitrary code execution. Two maliciously crafted pull requests, #18018 and #18020, were designed to enable backdoor access to the compromised environment. Figure 2 shows the malicious code embedded in the name of the forked branch.

Figure 2: Malicious pull requests designed to trigger execution of the payload code
The user account behind this pull request, openimbot, and the remote connection that was established after the execution of the malicious payload was initiated from Hong Kong, based on information provided by ultralytics maintainers.

Figure 3: User data behind the malicious pull request
This GitHub user, openimbot, has an interesting contribution history, with a long period of inactivity, between the end of August and beginning of December, when the reported attack was executed. While researchers could conclude that the account was overtaken sometime in this period, that may not be a correct conclusion. 

Figure 4: Contributions history of the openimbot account which initiated the compromise
The RL Spectra Assure platform can help prevent this type of attack and quickly pinpoint the malicious content inserted into the package. Figure 5 shows the file-based behavior differences between non-malicious version 8.3.40 and malicious version 8.3.41.

Figure 5: Behavior differences between non-malicious version 8.3.40 and malicious version 8.3.41
From the behavior diff, security teams can conclude that the malicious code was inserted into files downloads.py and model.py. Figure 6 shows that the code inserted into the model.py file is designed to check the machine type of the system on which the code is executed. This type of behavior is often used by malware to deliver payload specific to the infected machine. 

Figure 6: New behavior introduced in model.py file
Inspection of the source code confirms the above assumption. The code designed to download platform-specific payload is visible in Figure 7.

Figure 7: Code responsible for downloading and executing payload
File system-related behavior changes visible in Figure 8 suggest that the code that performs the actual downloading of the file and writing it to disk is located in the downloads.py file. The code difference between downloads.py file from versions 8.3.40 and 8.3.41 confirm that conclusion. 

Figure 8: New behavior introduced in downloads.py file
While in this case, based on the present information the RL research team has, it seems that the malicious payload served was simply an XMRig miner, and that the malicious functionality was aimed at cryptocurrency mining. But it is not hard to imagine what the potential impact and the damage could be if threat actors decided to plant more aggressive malware like backdoors or remote-access trojans (RATs).
Indicators of Compromise (IoCs)
Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach, or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.The following IOCs were collected as part of RL research team’s investigation of this software supply chain incident.
PyPI packages:

package_name
version
SHA1

ultralytics
8.3.42
ee304a92a9e68e7923d7a37a370c7556ac596250

ultralytics
8.3.42
7c6136cf4e857582c2f086673359be94e7e4b702

ultralytics
8.3.41
dd0577b10e73792f2b2315af63b872fe4123ec9c

ultralytics
8.3.41
bea3060707e6f3fec47aa2af64ea2e774b56e9f5

Article Link: Compromised ultralytics PyPI package delivers crypto coinminer
1 post – 1 participant
Read full topic