The silent danger of SSH key mismanagement [Q&A]

The recent AyySSHush botnet campaign compromised over 9,000 ASUS routers worldwide via SSH key injection. Unlike traditional botnets, this campaign flips the C2 model -- routers silently await inbound contact from the attacker, making detection incredibly difficult.

And since SSH key authentication happens after encryption is established, key usage remains invisible to most monitoring tools. Combine that with the fact that routers are critical, often unmonitored devices, and it’s easy to see why this attack is a sweet spot for adversaries.

We talked to Vince Berk, product owner, discovery at Keyfactor to understand more about the risk of poor SSH key management.

BN: The AyySSHush botnet campaign quietly compromised thousands of routers. What made this attack so stealthy and difficult to detect compared to traditional botnets?

VB: The AyySSHush campaign was unusual in both method and stealth. Traditional botnets typically involve compromised devices "phoning home" to a command-and-control (C2) server on a regular basis. That outbound communication is relatively noisy and creates signatures defenders can monitor.

In this case, the attackers flipped the model. Instead of the router reaching out, it sits quietly and waits for inbound contact from the attacker. That means no periodic traffic patterns or chatter to detect; just silence until the adversary decides to use it. It’s a far more passive, patient approach.

Combine that with the fact that these are home and small-business routers, devices that usually serve as both firewall and Wi-Fi access point and often directly connected to the ISP uplink. They’re critical, always-on, internet-facing devices, but rarely monitored closely for security anomalies. Once compromised, they become invisible backdoors, hiding in plain sight.

BN: You’ve noted that SSH keys don’t appear in network monitoring because authentication happens after encryption is established. Why does that pose such a challenge for defenders?

VB: That’s the crux of the problem. SSH is a strong, well-designed protocol. When a connection is established, encryption comes first -- before any authentication details are exchanged. From a network monitoring perspective, you see a secure tunnel being set up, but you don’t see who is logging in or which key is being used.

This makes SSH both a defender’s friend and foe. On one hand, it’s an excellent protocol for secure remote access. On the other, it gives adversaries a cloak of invisibility. Unless you’re collecting logs directly from the SSH server itself, you won’t know who authenticated. And in the case of AyySSHush, the malware authors disabled local logging entirely, removing one of the few remaining sources of visibility.

hat leaves defenders with only a handful of potential signals, such as monitoring for known malicious IPs or the specific high-port used in this attack (53282). But those can be easily changed by the attackers at any time.

BN: What role does poor SSH key management play in enabling these kinds of attacks -- and why is it often overlooked in organizations?

VB: Poor SSH key management is the enabler here. SSH keys are essentially passwords that never expire. Once an attacker gets a key into the right place -- for example, the ‘authorized_keys’ file on a router -- they can come and go as they please, often indefinitely.

The problem is that most organizations don’t treat SSH keys with the same discipline they apply to digital certificates or passwords. Keys don’t get rotated, they don’t expire, and there’s little to no auditing of which keys are authorized. Over time, organizations accumulate thousands of unmanaged keys across servers, routers, and embedded devices, many of which were installed years ago by people who no longer even work there.

Attackers know this. By slipping in one more authorized key, they blend in with all the legitimate ones and gain durable access that’s nearly invisible. It’s overlooked because SSH just works, until it’s too late.

BN: Given the difficulty of traditional detection, what proactive steps can organizations take to prevent unauthorized SSH key access, especially across routers and other hard-to-monitor devices?

VB: Prevention becomes critical, because detection is so weak. A few key steps stand out:

• Implement SSH key discovery and inventory. The first step is knowing what keys exist and where. Automated discovery can reveal authorized keys across your environment, including on routers and embedded devices, so you can validate whether they belong.
• Audit the authorized_keys file. On Unix-based devices, every allowed key lives in a predictable place. Checking that file regularly, even manually, can catch unauthorized entries before attackers take advantage.
• Keep router firmware updated. Vendors like ASUS regularly patch vulnerabilities, but attackers count on outdated devices staying online. Timely updates are often the difference between safety and compromise.
• Control who can install keys. Restrict permissions so only authorized administrators can push new public keys to endpoints. Any change to the keyset should follow formal change management.
• Monitor for unauthorized key changes. Even if you can’t see who logs in, you can monitor when a new key appears. That’s a strong indicator of potential compromise.

These steps don’t guarantee safety -- especially against an attacker as stealthy as those behind AyySSHush -- but they significantly reduce the available attack surface.

BN: What larger lessons should defenders take from the AyySSHush campaign?

VB: The big takeaway is that attackers are innovating in ways that exploit gaps in visibility. Routers are in the ‘sweet spot’ for adversaries: critical, internet-facing, and nearly impossible to monitor with traditional tools. Add in the invisibility of SSH authentication, and you have the perfect hiding place.

The lesson for defenders is twofold. First, don’t assume that what you can’t see can’t hurt you. Silent backdoors are often the most dangerous. Second, treat SSH keys with the same rigor you apply to every other form of digital identity. Keys are not just ‘convenient login tools.’ They are powerful credentials that can grant attackers unfettered, long-term access.

Ultimately, SSH is a great protocol. But like many great tools, it works just as well for attackers as for defenders. Our job is to close the gaps before those tools are turned against us. We can do this through strategies like discovery and auditing.

Image credit: Matthew Trommer/Dreamstime.com