RedTail: one reused SSH key links two delivery routes

RedTail is a well-documented Linux cryptomining botnet. Its attack on PHP-CGI has already been described by the SANS Internet Storm Center (diary 32936), so we do not repeat that here. This post records something smaller and more practical: two indicators we did not find published.

1. RedTail's droppers carry an embedded SSH client key that they use to download their next stage over SFTP.

2. The same key turned up in both the web route and the SSH route, which ties the two to one operator.

For defenders, the key gives a concrete thing to search for on their own hosts. For analysts, it links two delivery routes that might otherwise be tracked separately. We offer these as indicators, not as a new technique. If they have been published before, we would like to know.

This matters to any organisation running internet-facing Linux servers, PHP applications or WordPress: we saw the same botnet come in through a website on one day and through SSH on the next.

How it reached our honeypots

Through the website, 2 October 2026. A system sending the User-Agent libredtail-http delivered RedTail's PHP-CGI dropper to our WordPress bait. Our web application firewall keeps full request bodies, so we could read the decoded dropper. The bait runs a modern PHP version and was not vulnerable to this attack; nothing executed.

Through SSH, 3 October 2026. A RedTail bot logged in to our Cowrie SSH honeypot and ran the same loader. Cowrie does not emulate outbound SFTP, so again nothing reached the attacker's server.

What the analysis showed

The first-stage shell script carries an ed25519 private key. Instead of simply downloading the next stage over the web, it prefers to log in to a server over SFTP, as the account dlr, using that key. Only if that fails does it fall back to an HTTPS download.

The two routes used different servers. The web dropper pointed to 217.60.103[.]56; the SSH loader pointed to 217.60.102[.]5, in a neighbouring network block. Everything else matched: the same credentials and the same HTTPS fallback. Both droppers embed the same key, with this fingerprint:

SHA256:O/at8341SoPpKvTPvMsJSgjQm30md9VTS2it25sY0vg (key comment dlr@sftp)

This is the botnet's own credential for the account it downloads from. It is useful only as a pivot for analysts and as a detection signal for defenders. We did not and will not use it to connect to any attacker system: that would be out of scope and unlawful. We also did not fetch the second stage, because that would mean contacting the C2. At the time of writing, a web search for this fingerprint and for the two C2 hosts returned no public results.

RedTail rotates its C2 addresses routinely, so the IPs below will age. The key fingerprint, the dlr@sftp comment and the loader's behaviour give defenders other things to look for.

What defenders can do

• Keep PHP patched and do not run it as CGI unless you need to. Our bait runs modern PHP and was not affected by this dropper.

• Harden SSH. RedTail also arrived by SSH login. Disable password logins for root, prefer key-based authentication, and limit who can reach SSH at all.

• Search for the key. A written-out private key with the fingerprint SHA256:O/at8341..., or the comment dlr@sftp, anywhere on a host is a clear sign of this loader.

• Watch for the loader pattern. An SSH config and key written to /dev/shm or /tmp, followed by an outbound SSH or SFTP connection, is unusual for most servers.

• Log the User-Agent. Inbound web requests with the User-Agent libredtail-http come from RedTail's self-propagating scanner and dropper.

• Limit outbound SSH. Most web servers never need to open SSH connections to the internet. Egress rules that block this would also block this download path.

• Use the published rules. Our repository has Suricata and Sigma rules for the signals above.

Key indicators

The indicators are also in machine-readable form in the finding's iocs.csv, with the full technical write-up alongside.

How we work

KSI Digital runs a WordPress bait, behind a firewall that keeps full request bodies, and a Cowrie SSH/Telnet honeypot. Both record what attackers send and keep the files they deliver. We review samples offline in an isolated lab, never reuse credentials or keys we find, and never connect to attacker infrastructure outside that lab. In this case no attacker system was contacted at all. Before we report an indicator, we check it against existing feeds. More on our research page and in our methodology.

Indicators shared with ThreatFox, URLhaus and AbuseIPDB as ksi_digital. For this finding we reported the SSH-route server to ThreatFox (ID 1948446); the HTTPS fallback URL was already on URLhaus. Corrections are welcome: open an issue on GitHub or email christophe@ksi-digital.com.