On the Proactive Generation of Unsafe Images From Text-To-Image Models Using Benign Prompts

Catch-22: Uncovering Compromised Hosts using SSH Public Keys

Speakers: Cristian Munteanu, Max Planck Institute for Informatics; Georgios Smaragdakis, Delft University of Technology; Anja Feldmann, Max Planck Institute for Informatics; Tobias Fiebig, Max Planck Institute for Informatics

Conference: USENIX Security

YouTube: N/A

Paper Page: https://www.usenix.org/conference/usenixsecurity25/presentation/munteanu

Paper PDF: https://www.usenix.org/system/files/usenixsecurity25-munteanu.pdf

Overview

This distinguished paper from USENIX Security 2025 presents a novel, scalable methodology to identify compromised SSH (Secure Shell) servers across the Internet. Authored by researchers from the Max Planck Institute for Informatics and Delft University of Technology, the work leverages a specific, intended behavior of the SSH protocol: a server only sends a cryptographic challenge during public key authentication if the provided public key is actually installed for the specified user. This subtle distinction allows researchers to remotely ascertain the presence of known malicious public keys without requiring access to the corresponding private keys or completing the authentication process.

The significance of this research lies in its ability to proactively identify compromised systems at an unprecedented scale, moving beyond the reactive insights typically gained from honeypots. By collaborating with a threat intelligence company, the authors obtained a set of 52 verified malicious public keys. Their Internet-wide scanning campaign, targeting both IPv4 and IPv6 on standard (tcp/22) and non-standard (tcp/2222) SSH ports, successfully identified over 21,700 unique compromised systems across 1,649 autonomous systems (ASes) in 144 countries. This includes critical Internet infrastructure, offering invaluable insights into the modus operandi of various malicious campaigns and threat actors, from IoT botnets like 'fritzfrog' to actors like 'teamtnt' and even keys potentially associated with state-sponsored activities. The findings facilitate targeted clean-up efforts through partnerships with national CSIRTs and the Shadowserver Foundation, demonstrating a practical pathway to enhance Internet security.

Background

SSH has been the de facto standard for secure remote access to shell-enabled systems since its introduction in 1995. Its widespread adoption spans Unix, Linux, and even Windows systems, with an estimated 40 million SSH servers publicly accessible on the Internet. The proliferation of Internet-of-Things (IoT) devices, many running Linux with SSH enabled by default, has further expanded its footprint. SSH supports various authentication mechanisms, primarily password-based and public/private key-based authentication.

Attackers frequently target SSH servers. Brute-force attacks against weak or default passwords are a constant threat, particularly impacting IoT devices. Once a system is compromised, attackers often seek to establish persistence. Changing system passwords could alert legitimate owners, so a common tactic observed in honeypot studies and incident investigations is to install their own public SSH keys into user accounts on compromised systems. This allows them to regain access easily and discreetly.

The core of this paper's methodology hinges on a specific, intended design choice in the SSH protocol (RFC4252, Section 7). When a client attempts public key authentication by providing a public key fingerprint, the SSH server's behavior differs based on whether that public key is installed for the specified user. If the key is present in the user's authorized_keys file (or equivalent), the server will send a cryptographic challenge encrypted with that public key. If the key is not present, the server typically does not send a challenge, effectively skipping the computationally intensive public-private key authentication step. This behavior was first described by Siebenmann in 2016 and later noted by Golubin in 2019 in the context of identifying GitHub users' infrastructure. While a pull request was submitted to OpenSSH in 2021 to change this behavior, referencing CVE-2016-20012, OpenSSH developers clarified that it is, in fact, intended. This deliberate design choice, not considered a security vulnerability by OpenSSH developers, forms the foundational mechanic that the authors exploit to identify compromised systems at scale.

Key Findings

The research yielded significant findings, providing an unprecedented view into the landscape of SSH compromises:

• Vast Scale of Compromise: The study identified 22,938 instances of malicious keys installed, corresponding to 21,061 unique IPv4 hosts and 163 unique IPv6 hosts. Filtering by server host key, this number consolidated to 16,753 unique compromised servers. These systems were distributed across 1,649 ASes in 144 countries, including critical Internet infrastructure.
• Prevalence of Malicious Keys: Out of the 52 verified malicious public keys obtained from Bitdefender, 41 were found in the wild. The most frequently observed keys were MK06 (16,535 hits), MK35 (2,050 hits), and MK32 (727 hits), suggesting varied exploitation methodologies and attacker operational security.
• Attacker Attribution and Behavior:
• 'teamtnt': Six keys were attributed to 'teamtnt' (MK23, MK30-34), a group known for targeting cloud environments. Their keys were disproportionately found in hosting ASes and South-East Asian networks classified as CDNs (likely misclassified cloud networks), aligning with their focus on cloud vulnerabilities.
• 'fritzfrog': MK01, associated with the 'fritzfrog' IoT botnet, was most prevalent in end-user ISPs, consistent with its targeting of IoT devices.
• 'muhstick': The 'muhstick' botnet's key (MK29) showed high prevalence (over 95% of hits) in end-user ISPs but was not common on Dropbear servers, suggesting it targets home servers rather than typical embedded IoT devices, likely due to its exploitation of Apache RocketMQ vulnerability CVE-2023-33246.
• 'Jia Tan': Two keys (MK51, MK52) were linked to the persona 'Jia Tan', involved in the XZ backdoor. These keys were also found on GitHub, along with MK05, MK17, and MK36.
• 'mdrfckr': MK06, the most prominent key, was labeled 'mdrfckr' due to its comment field. It was widespread among IoT devices and confirmed as one of the most aggressive attacks in related honeypot studies.
• Infrastructure Insights:
• The study identified gitee.com, a Chinese Git SaaS solution, as a likely code repository used by 'teamtnt' and the actor behind MK06 and MK36. This was inferred from the platform's custom SSH implementation responding to these specific malicious keys across multiple users, indicating user-uploaded keys rather than a compromise of the platform itself.
• A core router of a leading ISP in a large central European country was found to be compromised with MK06, highlighting the severe risk to critical Internet infrastructure.
• State-Actor Associated Keys: MK48 showed diverse prevalence, appearing in European hosters, ASes associated with a Middle-Eastern state (MES), and IoT devices. The consistent presence of OpenSSH 8.2p1 (Ubuntu 20.04 LTS) across these systems suggested potential operation by the actor behind MK48 rather than compromise. This key's presence on five hosts also listed on the KillNet DDoS Blocklist further complicated attribution, suggesting possibilities of collaboration, false attribution, or state-operated censorship evasion honeypots.
• Comparison to Honeypots: The active measurement data was cross-referenced with a large honeypot network, revealing that 24 of the identified compromised hosts were actively performing attacks, and two were used as malware storage locations. The study also highlighted that honeypots can both under- and over-represent attacker activity, even underestimating some Advanced Persistent Threat (APT) activities.
• Continuous Remediation: The methodology has been integrated into continuous scanning operations with automated notifications distributed via the Shadowserver Foundation and CERT-Bund (the national CSIRT for Germany), ensuring ongoing remediation efforts.

Technical Deep Dive

The core innovation of this research lies in its methodology to accurately identify compromised SSH servers by leveraging unique characteristics of the SSH protocol (Section 3). The process capitalizes on the SSH server's behavior during public key authentication, specifically that a cryptographic challenge is only sent if the public key is actually installed for the specified user (RFC4252, Section 7).

The authors implemented this method as a patch for Zgrab2, a fast, modular application-layer scanner (Section 3.1). The probing mechanism operates as follows:

1. Initiate an SSH authentication process.
2. Send a SSH2_MSG_USERAUTH_REQ message containing a username (e.g., 'root', 'admin', 'udatabase') and the fingerprint of a public key to be tested.
3. Observe the server's response:

• If a challenge (an encrypted message) is received, it confirms that the specific public key is installed for that user.
• If no challenge is received, the key is not installed for that user.

Crucially, the researchers are only in possession of the public keys, not the corresponding private keys. Therefore, they cannot complete the authentication process or log into the compromised systems, which significantly limits the ethical implications of their active scanning. Their probes end immediately after determining the presence or absence of a challenge (as depicted by the red line in Figure 1 of the paper).

To ensure the reliability and efficacy of their methodology across diverse SSH implementations, a comprehensive in-lab validation was performed (Section 3.3). They tested their patched Zgrab2 against various versions of OpenSSH, Dropbear, BitviseSSH, and WolfSSH, selected based on their prevalence in Internet scans (Table 1). The validation included four steps: deployment, Zmap test (port identification), Zgrab2 test (public key recognition), and public key login (functional verification). One notable issue involved ssh-rsa keys, which OpenSSH versions 8.2 and higher deprecate. The tool implements a workaround to retry with rsa-sha-256 if ssh-rsa fails.

A critical aspect of the methodology is handling false positives (Section 3.4). Some SSH servers, particularly honeypots or specific SFTP implementations, might consistently reply with a challenge regardless of whether the key is installed. To mitigate this, the authors use Canary keys. These are newly generated, valid SSH keys that are tested before any malicious keys. If a remote server responds with a challenge for a canary key, the system is classified as untestable with this methodology (approximately 0.2% of hosts). The canary key must also be of the same key-type (e.g., ED25519, RSA) as the malicious keys being tested to ensure accurate detection.

The dataset of malicious public keys comprised 52 keys obtained through a collaboration with Bitdefender, a threat intelligence company (Section 3.5). These keys were observed in honeypots, during malware analysis, or incident investigations. For scanning efficiency, the researchers limited their tests to three common usernames: 'root', 'admin', and 'udatabase', which collectively accounted for 83% of observed compromises in the Bitdefender dataset (Section 3.6).

The scanning infrastructure consisted of four physical machines with 16 cores/32 threads and 64GB memory, connected to a dedicated network segment. They utilized CAIDA Routing Data for IPv4 prefixes and the IPv6 Hitlist for IPv6 targets (Section 4). The scanning protocol (Algorithm 1) involved:

1. Splitting public keys into 11 sets.
2. Iterating through target ports (tcp/22 and tcp/2222) and usernames.
3. Zmap for initial port discovery.
4. Zgrab2 (patched) for public key verification.
5. Applying a rate limit of no more than one authentication attempt per hour per IP address to prevent system overload and minimize impact.
6. Pre-testing with a canary key for each set of malicious keys.

The full IPv4 scan for one port and all users took 37 days, while the IPv6 scan took 9–10 days. The scans completed on 2024-06-01 for tcp/22 and 2024-07-31 for tcp/2222. Out of approximately 25 million SSH servers on port 22 and 643K on port 2222, the methodology was successfully executed on 16.9 million hosts (Section 4).

Ethical considerations were paramount (Section 3.7). The work received IRB clearance (No. 24-02-1) and adhered to best practices for Internet-wide scans, including maintaining a responsive reverse DNS entry, hosting an informative webpage, and actively handling abuse reports and opt-out requests. A harm-benefit analysis was conducted, weighing potential harms (non-authorized connections, system overloading, increased workload) against significant benefits (identifying compromised hosts for remediation, characterizing malicious actors). To mitigate harm, the researchers partnered with the Shadowserver Foundation and CERT-Bund to automate notification and remediation efforts, with individual notifications for high-profile cases (e.g., government infrastructure, core routers).

Demo / Proof of Concept

As this is a peer-reviewed conference paper rather than a live presentation, the "Demo / Proof of Concept" section refers to the rigorous validation and testing of the proposed methodology. The authors did not present a traditional "demo" but rather demonstrated the efficacy and safety of their approach through extensive lab experiments and controlled Internet-wide scans.

The in-lab validation (Section 3.3) served as the initial proof of concept. The researchers successfully built and deployed various versions of prominent SSH server implementations, including OpenSSH, Dropbear, BitviseSSH, and WolfSSH. They then used Zmap to confirm port accessibility and their patched Zgrab2 tool to issue "preauth" requests, verifying that the servers correctly recognized installed public keys by sending a challenge. A final public key login test confirmed the functionality of the installed keys and the SSH servers' authentication process. This controlled environment allowed them to confirm that their instrument accurately detects the presence of public keys as intended by the SSH protocol.

Beyond the lab, the methodology was further validated through tests over the Internet against two consenting Autonomous Systems (ASes) (Section 3.3). In these real-world scenarios, SSH public keys were installed on various hosts and user accounts within the ASes. Team members, unaware of the specific key placements, then used the instrument to scan these ASes, successfully identifying the hosts and users with the installed keys. High-throughput scans were also conducted with operator consent to assess potential issues under load. These initial Internet-based runs were crucial for identifying and resolving minor bugs and unexpected behaviors, such as specific error messages for deprecated ssh-rsa keys and implementing the rsa-sha-256 retry mechanism. The successful execution of these validation steps, culminating in the detection of over 21,700 compromised systems in the subsequent Internet-wide campaign, serves as a robust proof of concept for the method's accuracy, scalability, and practical applicability.

Defensive Implications

The findings of this research offer several critical implications for network defenders seeking to secure their SSH infrastructure and identify potential compromises:

• Proactive Compromise Detection: Organizations should leverage this methodology by scanning their own public-facing SSH servers using known malicious public keys from threat intelligence feeds. This allows for proactive identification of systems where attackers have already established persistence, even if no other malicious activity has yet been observed.
• Regular Auditing of authorized_keys: The fundamental persistence mechanism used by attackers is installing their public keys into authorized_keys files. Defenders must implement rigorous, regular audits of these files across all user accounts, especially privileged ones like root and admin, for any unauthorized or unfamiliar entries. Automated tools for this purpose are highly recommended.
• Strengthen SSH Configuration:
• Disable Password Authentication: Where feasible, disable password-based SSH authentication entirely in favor of public key authentication. This eliminates the primary vector for brute-force attacks.
• Restrict root Login: Configure SSH servers to disallow direct root login. Instead, users should log in with a non-privileged account and then use sudo.
• Keep Software Updated: Regularly update SSH server implementations (OpenSSH, Dropbear, etc.) to patch known vulnerabilities and ensure support for modern cryptographic algorithms. Be aware of deprecated algorithms like ssh-rsa in newer OpenSSH versions and configure clients/servers accordingly.
• Enhanced Monitoring and Alerting: Implement advanced monitoring for SSH authentication logs. Look for patterns that might indicate probing attempts using this technique (failed public key authentication attempts that receive a challenge but do not complete). While the authors' scans are designed to be indistinguishable from brute-force, specific patterns of challenge-response without completion could be a signal.
• Consistent IPv6 Security: The observation that IPv6 networks sometimes have more permissive firewall configurations than their IPv4 counterparts is a significant concern. Defenders must ensure that IPv6 security policies, including SSH access controls and firewall rules, are as stringent and well-enforced as their IPv4 counterparts.
• Threat Intelligence Integration: Actively integrate threat intelligence feeds containing known malicious SSH public keys into security operations. This enables organizations to quickly identify if their systems are associated with known malicious campaigns or actors.
• Collaborate with CSIRTs: The success of this research highlights the importance of collaboration with national CSIRTs and organizations like the Shadowserver Foundation. Participating in information-sharing initiatives and acting on notifications of compromised systems is crucial for collective defense.
• Review Opt-Out Policies: Network operators who typically opt out of Internet-wide security measurements should reconsider their stance. The paper demonstrates that opting out can inadvertently hide malicious activity within their networks, potentially allowing harm to spread to third parties. A balanced approach that allows for beneficial security research while respecting privacy is essential.
• Network Segmentation and Least Privilege: For critical infrastructure, ensure strict network segmentation to limit the blast radius of a compromise. Apply the principle of least privilege to all user accounts, restricting sudo access only when absolutely necessary.

By adopting these defensive strategies, organizations can significantly improve their posture against SSH-based compromises and contribute to a more secure Internet ecosystem.

Key Takeaways

• A novel methodology leverages a unique, intended behavior of the SSH protocol to identify compromised servers at Internet scale without requiring private keys or completing authentication.
• Over 21,700 unique compromised systems were identified across 144 countries, including critical Internet infrastructure, demonstrating the widespread nature of SSH compromises.
• The research provides unprecedented insights into the tactics, techniques, and procedures (TTPs) of various threat actors and botnets, such as 'teamtnt', 'fritzfrog', and 'muhstick', and even linked keys to the XZ backdoor and potential state-sponsored activity.
• Collaboration with threat intelligence companies (Bitdefender) and CSIRTs (Shadowserver Foundation, CERT-Bund) is vital for obtaining malicious key data and facilitating automated, continuous notification and remediation of compromised systems.
• Ethical considerations in large-scale Internet measurements are complex, highlighting a tension between potential harm from scanning and the benefit of identifying widespread malicious activity, especially concerning network operators opting out.
• IPv6 network security often lags behind IPv4, with more permissive firewall configurations potentially exposing critical infrastructure to increased risks.

About the Speaker(s)

This article is based on a peer-reviewed conference paper, not a recorded talk, and therefore does not include a speaker's transcript with biographical details. The authors of the paper, "Catch-22: Uncovering Compromised Hosts using SSH Public Keys," are:

• Cristian Munteanu: Max Planck Institute for Informatics
• Georgios Smaragdakis: Delft University of Technology
• Anja Feldmann: Max Planck Institute for Informatics
• Tobias Fiebig: Max Planck Institute for Informatics