Blog · · HoneyLabs
583 servers scanned SSH for 28 hours. Nine in ten are mail servers, two thirds run a dead OS.
Small organisations' mail servers, Postfix on CentOS 7 for the most part, spent 3 and 4 September scanning the internet for SSH. 583 hosts, 391 networks, one client fingerprint. What the scanner collects, who the machines are, why they were picked, and three checks if you run a mail server.
Someone is running an SSH reconnaissance tool from a pool of small organisations' mail servers. Between 18:37 UTC on 3 September and 22:53 UTC on 4 September, 583 of those hosts made 732 connections to HoneyLabs sensors with the same purpose-built client, read the server's version banner and disconnected without attempting authentication. Nine in ten of the hosts run a mail service, three quarters run Postfix, and two thirds of the ones that can be dated run an operating system that stopped receiving security updates between one and six years ago. The tool collects SSH banners, which is the input to a target list, and the pool it runs from is the neglected server that nobody maintains.
The client
The 583 hosts share one SSH client fingerprint, HASSH 594c57870d0ec290ad3f328d5116eb18, which is an MD5 over the algorithm lists the client offers in its key exchange. The connections went to port 22 from 391 networks in 81 countries. 460 of the 583 hosts connected once and the rest two or three times, for an average of 1.26 connections per host. The fingerprint had not been seen before 3 September and has not been seen since 4 September.
Every connection sent the same 1,036 bytes: the version string SSH-2.0-Go followed by a 1,020-byte SSH_MSG_KEXINIT, both in a single write before the server had answered, which is how the Go x/crypto/ssh library behaves. The sensor replies with its own version string and nothing else, and the client closes the connection after reading it.
The algorithm lists inside that KEXINIT are not the library defaults. The key-exchange list drops ecdh-sha2-nistp521 and the SHA-1 group-14 exchange, the ciphers are reordered strongest-first with ChaCha20-Poly1305 ahead of AES-256-GCM, and the MACs are cut down to the two ETM variants. All three were set deliberately, which is why this hash matches no other Go SSH client in our data or in public reporting, and the presence of the Terrapin mitigation kex-strict-c-v00@openssh.com dates the build to December 2023 or later. This is a tool someone wrote and configured for one job.
The version banner is the only thing the client collects. An SSH server sends its banner to any client that connects and does so before authentication. The banner names the implementation and version and usually the distribution and patch level:
SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3
A list of banners keyed by address is enough to select targets for a version-specific exploit later. The client's fixed structure makes it easy to match on the wire:
alert tcp any any -> any 22 (msg:"SSH-2.0-Go banner sweep, pipelined KEXINIT";
content:"SSH-2.0-Go|0d 0a 00 00 03 fc 0a 14|"; depth:18;
flow:to_server,established; sid:1000583; rev:1;)
The rule matches this build exactly and would also match any other Go client whose KEXINIT happens to be 1,020 bytes, so treat a hit as a lead rather than an alert. The fingerprint's population page classifies the shape as a dispersed coordinated operation: one short burst, hundreds of networks, about as many addresses as networks. That shape is the point of the design. No address ever makes a second connection, so nothing that counts per source ever fires.
The hosts
Reverse DNS names 242 of the 583 addresses with a leftmost label of mail, smtp, mx, webmail, imap, pop or proxmail. To test whether the names are accurate, each address was looked up in a passive database of open ports and software banners, which returned data for 497 of the 583. The same lookup was run on a control group of 320 hosts carrying HASSH f555226d, the libssh 0.9.6 client that has been scanning SSH from consumer devices for months and that has no connection to this operation.
Of the 497 hosts with data, 440 have a mail port open against 20 of the 320 controls, 371 run Postfix, and 413 carry the database's tag for addresses its own honeypot network has seen scanning, against 4 of the controls. So these are production mail servers, and a second sensor network independently sees them scan. What they are not is spam sources: Spamhaus lists 38 of the 583 as compromised hosts and only 6 as spam senders, which is no worse than the control group. Whoever holds this pool is using it for reconnaissance rather than for the thing a compromised mail server is usually used for.
The one property where the control group scores higher is SSH itself. 141 of the 497 sweep hosts expose port 22, against 219 of the 320 controls, so the majority of the sweep hosts cannot have been taken over through SSH.
By country the pool is led by Russia with 66 hosts, Indonesia with 60, the United States with 49, Brazil with 37, France with 35 and Vietnam with 34, followed by Turkey, Germany, India and Italy with around 20 each. One host is the mail server of a national education ministry. The hosts are not named here because the evidence points to them being victims.
An address that hosts a mail server does not prove the scanning process runs on the mail server itself, since a small office puts its mail server and its workstations behind the same public address. The port data also reflects the database's last visit rather than the state on 3 September. In either case the organisation has a compromised machine on its public address.
The operating systems
Some package versions are specific enough to identify the operating-system release. OpenSSH 7.4 ships only in CentOS and RHEL 7, OpenSSH 5.3 in CentOS 6, Apache 2.4.6 and OpenSSL 1.0.2k in CentOS 7 and OpenSSH 8.2p1 in Ubuntu 20.04. Those signatures pin a release for 162 of the 497 sweep hosts and 221 of the 320 controls.
Two thirds of the pinned sweep hosts run a release that is past end of life, against a third of the controls, and CentOS 7 alone is a third of the pool. It stopped receiving security updates on 30 June 2024, and CentOS 6, another nine percent, stopped in 2020. The control group is led by Ubuntu 24.04 and 22.04, both still supported.
The recruitment profile is therefore a small organisation's mail server running Postfix on CentOS 7, installed years ago and not updated since. Which vulnerability was used is not visible from outside, but the obvious candidates do not fit. SSH password guessing can account for at most the 28 percent that expose SSH, and Exim's unauthenticated RCE from May (CVE-2026-45185) does not affect Postfix. What remains is the web and mail surface of an operating system that has had no security patches for years, and an operator who selects for that does not need any single vulnerability.
A named operation with a similar shape was reported this year. Flare's February analysis of SSHStalker describes a botnet that compromises legacy Linux hosts with kernel exploits from 2009 and 2010, controls them over IRC, and uses a Go binary named nmap to scan port 22 for new targets. A file recovered from it held about 7,000 scan results from January 2026. The scanner language, the reconnaissance-only behaviour and the age of the victims match this pool. The victims themselves do not, because SSHStalker's exploits target 2.6.x kernels, which means CentOS 5 and 6, and its results were concentrated in Oracle Cloud address space, while this pool is mostly CentOS 7 mail servers at small ISPs. This sweep is consistent with an operation of that kind and cannot be attributed to it from our data.
The older precedent is closer in shape: on 7 April 2009 the SANS Internet Storm Center described 824 sources scanning port 22 of which 706 appeared from reverse DNS to be mail servers. That report could identify the hosts only by name, and what can be added seventeen years later is the client fingerprint, the payload, the software inventory and the operating-system ages of what turns out to be the same population doing the same job.
What this adds up to is an old business model with a current instance that can be measured end to end. Neglected small-organisation servers are compromised in bulk, held rather than burned on spam, and used to build a banner inventory of the internet's SSH servers, which is what an operator needs before choosing a version-specific exploit and a target list. The tool is purpose-built, the pool is dispersed so that no source stands out, and the only visible trace at the target end is one connection that never authenticates.
Checks
The first check is whether your own address has been seen scanning. Look up your mail server's public IP in HoneyLabs lookup. An address that appears there has connected to honeypot sensors, and the entry shows when it was first seen and which ports it touched. A mail server that appears in that list has a process on it, or behind it, that should not be there. For more than a few addresses, bulk enrich takes a pasted list and returns the same verdict for each.
The second check is outbound connections to port 22, because a mail server does not need to open SSH connections to arbitrary addresses and outbound firewall rules on mail hosts are usually written for port 25 only:
ss -tn 'dport = :22'
iptables -I OUTPUT -p tcp --dport 22 -m limit --limit 1/min -j LOG --log-prefix "OUT-SSH "
The scanner's traffic from any single host is a few hundred bytes per target, so it does not register in a bandwidth graph and has to be found in a connection log.
The third check is the operating system, and cat /etc/os-release on a CentOS 7 host returns a release that has had no security updates since June 2024, and 52 of the 162 hosts in this pool that could be dated run it. The fix is a supported release, since no patch for the current install is coming.
For anyone running SSH the useful log entry is a client that connects and exchanges version strings and then disconnects without authenticating, because that is banner collection and it precedes exploitation. Key such logs on the client's algorithm proposal rather than the source address. HASSH 594c57870d0ec290ad3f328d5116eb18 identifies this client from any source, and counting distinct client fingerprints per day shows a distributed sweep as one fingerprint arriving from hundreds of addresses even when no single address makes a second connection. The 583 addresses here are the ones that reached HoneyLabs sensors, and the full pool behind this fingerprint is larger by an amount that cannot be measured from one vantage point.
Window 3 September 18:37 UTC to 4 September 22:53 UTC 2026. Control group drawn from 8 June to 8 September. Port, banner and scanner-tag data from Shodan InternetDB, queried 19 September, passive lookup only.