Secure SHell (SSH) is one of the most common tools used to manage servers remotely. It protects communication between administrators and machines and is considered one of the core protocols of the Internet. Because it is everywhere, SSH is also one of the main entry points for attackers.
When attackers gain access to a server, they often want to maintain control for as long as possible. A common technique is to install their own SSH keys, allowing them to log in again at any time without relying on the original password. This approach is both simple and stealthy: the legitimate user’s password remains unchanged, so typical alerts based on password misuse are never triggered. Detecting this kind of compromise across the Internet is not a trivial task.
Existing defenses, such as system logs, intrusion detection systems, or honeypots, have important limits. Logs can be deleted, detection systems often generate false alerts, and honeypots only see a fraction of the real attacks. What we wanted was a method that could track compromised systems at Internet scale, reliably, and without needing inside access to a server.
At USENIX Security 2025, we presented Catch-22: Uncovering Compromised Hosts using SSH Public Keys. Our method makes use of a
Our approach relies on the way SSH handles public key authentication. In SSH, authentication with keys works as a pair: the client keeps the private key, while the server stores the corresponding public key in its authorized list. The SSH private key file does not only store the private key but also includes the corresponding public key. When a client attempts to log in, it offers a public key to the server, the server checks if that key is present on its list of authorized keys for the account the user tries to authenticate to. The private key is never
When an attacker gets access to a server, they usually install their own public keys in order to ensure future access. Hence: If we probe a server with a public key that is known to belong to a malicious actor and the server responds with a challenge, we know that the attacker’s key has been installed on the server. This way, a server silently reveals whether or not it has been compromised by an attacker. The general mechanism behind this was first described by Siebenmann[1] in 2016 and later noted by Golubin[2] in 2019, who showed that it could be used to identify infrastructure linked to GitHub users. Building on this foundation, our work demonstrates how the same mechanism can be used systematically at Internet scale to uncover compromised machines. Using this method we can perform active measurements to test if a system is likely to be compromised. The figure below illustrates two scenarios: one in which a challenge is sent because the key exists, and another showing the error that occurs when no key is found. The red line indicates the point at which our scan terminates.
To take this idea beyond a proof of concept, we built an Internet-scale measurement pipeline that tests whether real attacker keys are installed on hosts in the Internet. In collaboration with our partner Bitdefender, we collected 52 SSH public keys linked to malicious activity. These keys had been identified through honeypots, malware analysis, and incident response.
For each key, we initiated SSHv2 authentication to hosts found to run SSH in Internet-wide active measurements, by presenting, in multiple rounds, the three most commonly compromised usernames together with the public key. Checking whether the servers return a challenge whether the keys are installed on these systems, i.e., the systems are likely compromised. Importantly, we do not have access to the private keys, and cannot complete the authentication even if a key was found to be installed; the probe ended immediately after the challenge stage.
We implemented this logic as a patch to the Zgrab2 scanner, and, with the help of ZMap, scanned the Internet (IPv4 and IPv6) for hosts running SSH on the standard SSH port (tcp/22) as well as the most common SSH off port (tcp/2222). The study ran in 11 rounds beginning in April 2024 and finishing by August 2024, rotating through selected usernames (the names were selected based on the provided data from Bitdefender) such as root, admin, and udatabase and inserting pauses between rounds to avoid overloading systems and disturbing system administrators worldwide. Because a small fraction of endpoints might respond with a challenge to any key – such as misconfigured SSH servers or honeypots – in every round we first tested each host with a “canary key” of the same algorithm before trying the malicious key.
A canary key is a harmless test key
Before scaling up, we validated the method extensively. We tested different SSH implementations, including OpenSSH, Dropbear, BitviseSSH, and WolfSSH, to confirm consistent behavior. We also ran controlled scans against networks that had explicitly consented to be included, verifying that our probes were safe and correct. To support further work, we released our patched scanner and automation scripts to the public[3].
The measurement campaign revealed more than 16 thousand SSH servers worldwide that recognized one of the 52 attacker keys. These were not only low-value personal machines but also systems in hosting environments, academic institutions, and enterprise networks. In many cases, the servers we flagged matched known botnet infrastructures or malware command-and-control hosts, confirming that the method uncovered real compromises.
Perhaps most important was the accuracy of the signal. Because a server must explicitly recognize a key for us to record it as compromised, false positives were rare. The few anomalies we observed were usually linked to misconfigurations rather than attacks, which underscores the reliability of the approach.
Among our findings, one stood out for both its rarity and significance: one of the compromised hosts was actually a core router belonging to a Internet Service Provider in central Europe. This router responded to an attacker-linked public key – specifically mkey-06. Given that this device was just one or two network hops from the ISP’s border, its compromise illustrates that SSH key-based persistence can extend into critical infrastructure, not just end-hosts. This case underscores the breadth of environments where such attacks can occur – and highlights the importance of a detection method capable of spanning diverse host types, from ordinary servers to core networking equipment.
The results are also illustrated in two figures. The first presents a world map showing the geographic distribution of compromised hosts. The map makes clear that these systems are spread across all regions, with concentrations in Europe, North America, and Asia, reflecting both global deployment of SSH and the global reach of attacker operations. The second figure summarizes how many hosts recognized each malicious key. Each bar corresponds to one of the attacker keys (mkeys), while the color within the bar represents the proportion of accounts that were compromised under different usernames.
The ability to identify compromised hosts at Internet scale has several important applications. For global security monitoring, SSH key probing can be integrated into regular Internet scans, providing visibility into the scope and distribution of compromises. For enterprises and universities, the method can be used internally to ensure that no known malicious SSH keys are present across their infrastructure, adding an extra layer of assurance to existing security practices. In the area of threat intelligence, the ability to tie compromised hosts to attacker keys enriches attribution efforts and allows faster detection of coordinated campaigns.
An important aspect of the technique is that it is difficult for attackers to evade. In theory, an attacker could generate a unique SSH key pair for every compromised host to prevent recognition of reused keys. In practice, however, this does not scale: managing and distributing thousands of distinct keys across large botnets or long-lived infrastructures would add significant operational complexity. Attackers rely on reusing the same keys across many systems precisely because it is simpler and more manageable. This operational constraint makes the method robust, as it ensures that reused keys leave detectable traces that can be observed at Internet scale.
Because active probing always raises ethical questions, we designed our scans to minimize risks: the probing rate was reduced to be barely noticeable to the sysadmins, authentication was never completed, and only public information was collected.
But detection alone is not enough – compromised machines need to be reported to their operators so they can be cleaned. For that reason, before starting the scans, we partnered with the Shadowserver Foundation (a nonprofit organization that specializes in large-scale security notifications), and the German Federal CSIRT CERT-BUND to also get notifications about compromised systems to affected parties. Shadowserver and CERT-BUND received the results of our measurements and used its established channels to inform network operators and national CERTs around the world about the affected systems. This ensured that the knowledge we gained was turned into actionable remediation steps without exposing or mishandling sensitive data[4,5].
Follow-up scans conducted after the notifications showed a clear decrease in the number of compromised hosts, demonstrating that the reporting process had a measurable effect. This outcome underlines the importance of linking technical research with operational partners: by combining large-scale measurement with established remediation networks, it is possible not only detect compromised hosts, but also to contribute directly to solving them.
Our work demonstrates that the SSH authentication process itself can be leveraged to detect compromised servers at scale. By focusing on whether a server recognizes known attacker keys, we can detect compromises and with high confidence.
This method does not aim to replace existing defenses, but it complements them with a tool that is simple, scalable, and precise. Attackers install SSH keys to guarantee their access; that very action can now be turned against them.
