Pierluigi Paganini
August 05, 2021
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 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.
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
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
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
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:
Figure 9: Worm exploiting Path traversal vulnerability
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
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
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 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
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
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(SecurityAffairs – hacking, MSR)
[adrotate banner=”5″]
[adrotate banner=”13″]
