Cryptominer ELFs Using MSR to Boost Mining Process

The Uptycs Threat Research Team recently observed Golang-based worm dropping cryptominer binaries which use the MSR (Model Specific Register) driver.

 By UPTYCS THREAT RESEARCH 

Original research by Siddarth Sharma

The Uptycs Threat Research Team recently observed Golang-based worm dropping cryptominer binaries which use the MSR (Model Specific Register) driver to disable hardware prefetchers and increase the speed of the mining process by 15%.

The Golang-based worm which targets vulnerable *nix servers exploit known vulnerabilities in the popular web servers in order to spread itself and the embedded miner. The new variants of the worm were identified in June 2021 by our threat intelligence systems. Though some of the functionalities were similar to the malware discussed by the security firm Intezer last year, the newer variants of this malware had a bunch of activities up its sleeve.

In this blog, we will detail the usage of MSR to disable the hardware prefetcher in the cryptomining malwares. We will also cover certain new techniques employed by the attackers in the attack kill chain for the persistence and dropping of the worm into certain sensitive directories on the vulnerable servers.

Hardware Prefetcher and the MSR

Hardware prefetcher is a technique in which the processors prefetch data based on the past access behaviour by the core. The processor (or the CPU)_, by using hardware prefetcher, stores instructions from the main memory into the L2 cache. However, on multicore processors, the use of aggressive hardware prefetching causes hampering and results in overall degradation of system performance.

MSR registers in processor architecture are used to toggle certain CPU features and computer performance monitoring. By manipulating the MSR registers, hardware prefetchers can be disabled.

Miners Using MSR to Disable Hardware Prefetcher

A miner running with root privileges can disable the prefetcher. This is done to boost the miner execution performance, thereby increasing the speed of the mining process. We have seen Xmrig miners in our threat intelligence systems using MSR to disable the hardware prefetcher.

Xmrig miners use the RandomX algorithm which generates multiple unique programs that are generated by data selected from the dataset generated from the hash of a key block. The code to be run inside the VM is generated randomly and the resultant hash of its outcome is used as proof of work.

As RandomX programs are run in a VM, this operation is generally memory intensive. Hence, the miner disables the hardware prefetcher using the MSR. According to the documentation of Xmrig, disabling the hardware prefetcher increases the speed upto 15%.

The miner uses the modprobe msr command to load the msr driver (see Figure 1).

Figure 1: Command used to load msr driver

This is done because in modular kernels the msr driver is not automatically loaded. Once the msr driver gets loaded, a pseudo file is created in /dev/cpu/ (/dev/cpu/CPUNUM/msr). This provides an interface to read and write the model-specific registers (MSRs) of an x86 CPU. The miner accesses /dev/cpu/CPUNUM/msr to modify the existing value of the msr with the new value as shown below (see Figure 2).

Figure 2: MSR file modification

For disabling hardware prefetcher, the miner accesses the /dev/CPU/CPUNUM/msr special character file to read the old value of msr and then modifies it using pwrite system call in chunks of 8 bytes. The pseudo-code of this activity is shown below (see Figure 3).

Figure 3: Pseudo-code

Also, the “wrmsr” set to true in the miner config for enabling MSR feature is shown below (see Figure 4).

Figure:4 Config file:Miner

Wormed cyptominer: attack kill chain

1. The attack kill chain of the wormed cryptominer starts with a Shell script which downloads the Golang worm using curl utility. 
2. The worm scans and exploits existing server based vulnerabilities like CVE-2020-14882 and CVE-2017-11610 from the victim machine.
3. After having access to a vulnerable server, the worm downloads another shell script which downloads a copy of the same Golang worm.
4. The worm also writes multiple copies of itself to various sensitive directories like /boot,/efi,/grub and later drops Xmrig miner ELF in /tmp location.
5. The miner disables the hardware prefetcher by using MSR to boost the mining process. 

The shell-script we analysed (hash: 28e9b06e5a4606c9d806092a8ad78ce2ea7aa1077a08bcf3ec1d8e3d19714f08) involved several defense evasive techniques like firewall altering, disabling monitoring agents which we have detailed in our previous blog. Alongside this, the script also used the ‘sed -i’ command to modify the /etc/hosts file with the nanopool URL as shown in the below figure (see Figure 5).

Figure 5: /etc/hosts modification

The script finally downloads the first stage worm sample from 194.145.227[.]21 as shown below (see Figure 6).

 Figure 6: Shell script network traffic – Downloading Worm

First stage payload: Worm

The Worm (163ef20a1c69bcb29f436ebf1e8a8a2b6ab6887fc48bfacd843a77b7144948b9) was compiled in Golang and UPX packed. The worm used the go-bindata package to embed Xmrig miner inside itself as shown below (see Figure 7).

Figure 7: Embedded XMRig miner

Vulnerabilities exploited by the Worm

After getting downloaded in the victim system, the worm first scans for vulnerable servers from the victim system to exploit certain known web server vulnerabilities like CVE-2020-14882 and CVE-2017-11610. The scanner package used by the worm for scanning remote vulnerable servers is shown below (see Figure 8).

Figure 8: Scanner modules

The majority of the worm samples exploited the following vulnerabilities:

1. CVE-2020-14882 – A classic path traversal vulnerability used for exploiting vulnerable web logic servers. It seemed like the attacker tried to bypass the authorization mechanism by changing the URL and performing a path traversal using double encoding on /console/images (see Figure 9).

Figure 9: Worm exploiting Path traversal vulnerability

2. CVE-2017-11610 – A Remote Code Authentication (RCE) vulnerability in the XMLRPC interface in supervisord. XMLRPC is an interface which is provided by the wordpress. The encoded payload in <param> used by the attacker in the XMLRPC exploit is shown below (see Figure 10).

Figure 10: Encoded payload in <param>

After successful exploitation, the worm uses base64 encoded command that downloads the shell-script (hash: dfbe48ade0b70bd999abaf68469438f528b0e108e767ef3a99249a4a8cfa0176) on the remote vulnerable servers from the C2 using a base64 encoded command (see Figure 11).

Figure 11: Post exploitation command to deploy worm

This shell script (ldr.sh) downloads the worm from the C2 to deploy XMrig miner on the servers via the worm again (see Figure 12).

Figure 12: Shell-script downloading the worm

Worm dropping Xmrig miner into /tmp

The worm deploys the embedded Xmrig miner to the /tmp location on the victim server. For this action, the worm first creates a directory in /tmp by the name u0jhm2. After changing the permission using fchmod utility, it gets executed (see Figure 13).

Figure 13: Worm dropping miner in /tmp 

After execution of the miner, the miner binary(kthreaddk) gets removed using unlinkat syscall – unlinkat(AT_FDCWD, “/tmp/u0jhm2/kthreaddk”, 0).

The worm also writes copies of itself to certain sensitive directories like /boot, /boot/grub, /boot,efi, /X11 (see Figure:14,15).

Figure 14: Worm binary copying itself to /boot

Figure 15: Worm binary copying itself to /boot/efi

Persistence

After writing itself to sensitive directories, the worm registers itself into the crontabs and uses fchmod to change permissions of the cron registered file, tmp.6GnMiL which later gets renamed as root (see Figure 16).

Figure 16:Writing to Cron and later changing the permission

Our threat intelligence systems identified seven similar samples of the Golang-based wormed cryptominer. Though the functionality and working of the binaries were the same, some of the worm samples register different paths like /dev/dri/by-path/<file_name>,/boot/<file_name> in crontab.

Uptycs EDR detections

Uptycs EDR armed with YARA process scanning detected the Xmrig cryptominer and the MSR modification with a threat score of 10/10 (see Figure 17).

Figure 17: Uptycs EDR detection for MSR modification and other malicious activities

Additionally, Uptycs EDR contextual detection provides additional details about the detected malware. Users can navigate to the toolkit data section in the detection alert and click on the name to find out the behavior and working of Xmrig as shown in the figure below (see Figure 18).

Figure 18: Toolkit data showing attribution

Conclusion

With the rise and sky-high valuation of Bitcoin and several other cryptocurrencies, cryptomining-based attacks have continued to dominate the threat landscape. Wormed cyptominer attacks have a greater threshold as they write multiple copies and also spread across endpoints in a corporate network. Alongside the mining process, modification of the MSR registers can lead to fatal performance issues of the corporate resources. The Uptycs EDR solution offers the added benefit of taking a deep dive into the events logged, providing more insights of an attack.

The Indicators of Compromise (IOCs) associated with wormed cryptomier are reported in the original report at https://www.uptycs.com/blog/cryptominer-elfs-using-msr-to-boost-mining-process.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, MSR)

The post Cryptominer ELFs Using MSR to Boost Mining Process appeared first on Security Affairs.