# Cryptominer ELFs Using MSR to Boost Mining Process
**[uptycs.com/blog/cryptominer-elfs-using-msr-to-boost-mining-process](https://www.uptycs.com/blog/cryptominer-elfs-using-msr-to-boost-mining-process)**
_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](https://www.intezer.com/blog/research/new-golang-worm-drops-xmrig-miner-on-servers/)
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](https://github.com/tevador/RandomX)
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%.](https://github.com/xmrig/xmrig/blob/master/doc/CPU.md#wrmsr)
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.](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11610#:~:text=The%20XML%2DRPC%20server%20in,1%2C%203.1.&text=3%20allows%20remote%20authenticated%20users,to%20nested%20supervisord%20namespace%20lookups.)
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’](https://www.uptycs.com/blog/evasive-techniques-used-by-malicious-linux-shell-scripts)
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](https://github.com/go-bindata/go-bindata)
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-202014882 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](https://nvd.nist.gov/vuln/detail/CVE-2020-14882)
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
[1. CVE-2017-11610 - A Remote Code Authentication (RCE) vulnerability in the XMLRPC](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11610#:~:text=The%20XML%2DRPC%20server%20in,1%2C%203.1.&text=3%20allows%20remote%20authenticated%20users,to%20nested%20supervisord%20namespace%20lookups.)
interface in supervisord. XMLRPC is an interface which is provided by the wordpress.
The encoded payload in used by the attacker in the XMLRPC exploit is
shown below (see Figure 10).
Figure 10: Encoded payload in
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/bypath/,/boot/ in crontab.
## Uptycs EDR detections
[Uptycs EDR armed with YARA process scanning detected the Xmrig cryptominer and the](https://www.uptycs.com/product-attacksurface-endpoints-servers)
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](https://www.uptycs.com/product-attacksurface-endpoints-servers)
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 available on
Github.
## IOCs
C2: 194[.]145.227.21:5443
**Shell script**
28e9b06e5a4606c9d806092a8ad78ce2ea7aa1077a08bcf3ec1d8e3d19714f08
dfbe48ade0b70bd999abaf68469438f528b0e108e767ef3a99249a4a8cfa0176
**Worm**
41dbb7871093a6be9acc7327bc7a7757df2f157912ff5649b01390307283bb53
163ef20a1c69bcb29f436ebf1e8a8a2b6ab6887fc48bfacd843a77b7144948b9
de263e5ad81bb5e2be7d57c7e201fe172108d987562a98897736d8c9235661a2
-----
67bb4acf52cc57f62f84161e068e254dba6b4058c04a5d707c057492bd208659
b22e47e11ff7aefc271bff1cbd2c904d8c4208f494208357a949242f6926dfc9
1b2909eda77c14b559b06a68a794868989b7e38c9ca185a3180c63e5c38622b5
f17b64733fa1ba60dda283bd4f6e6ce74fc921028e95c4c1a2079be39084085e
0d3b0dc5ea6643d36d745fcaa177eba88200b2b16596111e140f59092070594f
**Miner**
ba518af59262e878d31c71020ebfcbd50dfadf1e7c47a340003c80284681794b
Tag(s): [threat hunting,](https://www.uptycs.com/blog/tag/threat-hunting) [threat research](https://www.uptycs.com/blog/tag/threat-research)
## Uptycs Threat Research
Research and updates from the Uptycs Threat Research team.
Connect with the author
-----