One Key, 511 Hosts: How a Shared SSH Public Key Fingerprints a Botnet That IP Blocklists Cannot See

In 30 days of honeypot logs, one RSA public key appears 632 times. It arrives from 511 distinct source IP addresses spread across dozens of countries and autonomous systems. The IPs have nothing in common. The key has everything.

That is the structure of a distributed SSH botnet as seen from the target side. Each of those 511 IPs is a previously compromised machine, running the same operator's tooling, adding the same backdoor credential to every new host it can reach. The key never changes - not because the operator is careless, but because changing it would orphan every machine already backdoored.

This is an analysis of what that key reveals and what you can do with it.

//The Numbers

644 sessions in the dataset ran SSH key replacement commands. Five distinct RSA public keys appear across those sessions, sourced from 514 distinct IPs in total. The distribution is not even:

98.1% of key implants in the dataset are the same key. The four minor keys are noise - one-off experiments or different operators testing access before handing off. The dominant key is a systematic campaign.

//The Delivery

The command that installs the key was byte-for-byte identical across all 632 implants. No variation in whitespace, no variation in quoting, no variation in argument order across 511 source addresses and 30 days:

cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4..." >> .ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~

The sequence removes any existing .ssh directory entirely, creates a fresh one, appends the backdoor key, and locks down the permissions. chmod -R go= ~/.ssh removes group and other read/write/execute from the directory recursively - the same permission set SSH requires to accept the authorized_keysfile in the first place. The operator knows the ssh daemon's permission requirements; this is not a copy-pasted one-liner but a correctly formed credential installation sequence.

Median time from TCP connect to implant completion was 2.13 seconds. Minimum 0.10 seconds, maximum 13.13 seconds. No human is in this loop.

The chattr sequence

The key implant was preceded in the same sessions by:

cd ~; chattr -ia .ssh; lockr -ia .ssh

chattr -ia removes the immutable (i) and append-only (a) filesystem attributes from the .ssh directory. These attributes, set with chattr +ia ~/.ssh, are a hardening technique intended to prevent exactly this modification - the directory becomes read-only at the filesystem level even for root. The attacker's tooling explicitly strips this protection before attempting the key installation.

Two things follow from this. First, the tooling was written by someone who had encountered hardened deployments and added countermeasures - this is not beginner code. Second, the chattr command itself is a useful detection signal: any successful chattr -i ~/.ssh on a production system, without a corresponding change-management ticket, warrants investigation. The attacker cannot avoid running it, because without it the key installation fails on hardened hosts.

The lockr command alongside chattr targets a non-standard attribute management utility found on some distributions. Its presence here suggests the tooling accounts for environments where the standard chattr binary is replaced or augmented with alternative attribute managers.

//What the Key Tells You About the Botnet

IP addresses are poor IOCs for this campaign. The 511 source IPs span at minimum dozens of countries and autonomous systems. A blocklist built on those IPs blocks 511 already-compromised third-party machines - most of them home routers, small business servers, and low-end VPS instances belonging to victims, not the operator. The operator's own infrastructure never appears in the honeypot logs directly.

The public key is a much stronger IOC for two reasons:

Cost to change. Rotating the RSA key requires updating every previously compromised host to remove the old key and add the new one. That requires re-accessing each compromised machine - which requires the old key. The operator cannot rotate the credential without maintaining access to every node in their botnet, which is the same access the credential provides. Changing the key is operationally expensive in exactly the way that changing an IP address is not.

Breadth as a hunt indicator. Searching authorized_keys files across a fleet for AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4 identifies compromised hosts regardless of which IP performed the implant. The IOC propagates backwards in time - any machine in the fleet that received this key at any point is in scope, even if the implant happened before the threat intelligence was available.

What the botnet is built for

SSH key implantation without any follow-on command execution in the honeypot session is consistent with infrastructure staging. The operator is not running commands on machines they successfully compromise in this phase - they are adding their key and moving on, building a roster of machines with persistent root access. A subsequent phase - DDoS participation, crypto mining, lateral movement toward higher-value targets - requires only that the key works, not that the initial access session was interactive.

The scale (511 source IPs over 30 days against a single low-profile honeypot) suggests a large existing fleet. A botnet with 511 actively scanning nodes is not small. Each of those nodes is itself a compromised machine that has had this key added to it at some earlier point by the same process.

//The Cleanup Sequence

347 of the key-implant sessions also ran:

rm /dev/.t; rm /dev/.sh; rm /dev/.human

These are cleanup commands for a specific toolset that stages files in /dev/ using hidden names. The /dev/ directory is unusual staging territory - most monitoring tools, backup agents, and integrity checkers are configured to ignore device directories, treating them as a hardware abstraction layer rather than a location where user files might appear. Files placed in /dev/ are less likely to be caught by file integrity monitoring, less likely to appear in backup snapshots, and less likely to be noticed in a manual review of unusual file locations.

The specific filenames - .t, .sh, .human- are consistent enough across sessions to constitute a campaign signature. This is the operator's own toolset being cleaned up after itself, presumably to avoid detection after the key implant is complete.

//Detection and Hunting

Authorized keys sweep

The highest-value hunt is a sweep of ~/.ssh/authorized_keys and /root/.ssh/authorized_keys across a fleet for the key prefix AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4. Any match indicates a compromised machine that has been prepared for persistent backdoor access. The match is definitive - this key prefix has no legitimate use.

grep -r "AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null

Against a managed fleet this can be wrapped in a compliance check or pushed through a configuration management tool. The search cost is trivial; the miss cost is a persistent backdoor that survives OS reinstalls if the home directory or authorized_keys file is preserved across reinstallations.

The chattr detection signal

Any process running chattr -i /root/.ssh or chattr -i /home/*/.ssh that is not a known administrative process is worth alerting on. This command has almost no legitimate non-administrative use case against the .ssh directory. An EDR rule or auditd rule watching for execve of chattr with -i and a path under a home directory would catch this campaign at the pre-implant phase.

The /dev/ staging indicator

Files matching /dev/.* (hidden files in the device directory) with user-writable permissions are unusual and worth flagging in any file integrity monitoring configuration. The specific names .t, .sh, .human can be added to a watchlist, but the broader pattern - any hidden non-device file in /dev/ - is the more durable rule.