SSHStalker botnet compromises Linux machines via brute-force

The newly discovered SSHStalker botnet is breaching poorly secured Linux servers via brute-force attacks on weak SSH passwords. Researchers at Canadian company Flare Systems, who discovered the botnet, managed to gain access to its staging server and believe that at least 7,000 servers had been compromised by the end of January, half of them in the US.

See also: Aisuru botnet: New record with 31.4 Tbps DDoS attack

The botnet's weapons include exploits for unpatched Linux vulnerabilities dating back to 2009. Researchers describe the SSHStalker botnet as “a sophisticated operation that combines 2009-era IRC botnet tactics with modern mass breach automation.” It features a “stitched botnet kit” that executes fileless malware, rootkits, log cleaners, and a wide range of kernel exploits.

Among other things, it harvests AWS credentials. Researchers call SSHStalker “an enterprise that prioritizes scale over secrecy.” However, so far the botnet hasn’t done much more than maintain its presence on infected machines. It has the ability to launch DDoS (distributed denial of service) attacks and conduct cryptocurrency mining, but it hasn’t done anything yet to exploit its access.

This, according to Flare, suggests either that the operator is still preparing the botnet infrastructure, is in a testing phase, or is retaining access for future use. The good news for CSOs, according to Flare cybersecurity researcher Assaf Morag, is that at this point there is a way to stop the SSHStalker botnet: Disable SSH password authentication on Linux machines and replace it with SSH-key-based authentication, or hide password connections behind a VPN.

See also: RondoDox Botnet exploits vulnerability in HPE OneView

This change should be accompanied by implementing SSH brute-force rate limiting, monitoring who is trying to access Linux servers connected to the internet, and restricting remote access to servers to specific IP ranges. However, Morag warned that currently SSHStalker looks for Linux servers with weak SSH protection, but at any time, the operator could add another attack method, such as an unpatched server vulnerability or misconfiguration.

Chris Cochran, SANS Institute field CISO and vice president of AI security, said SSHStalker is a reminder that security fundamentals still define the battle. “Yes, AI is changing the threat landscape. Yes, automation is accelerating attacks. But this campaign proves something simpler and more inconvenient: The old tactics still work,” he said.

IT security leaders should either move to key-based authentication, short-lived credential solutions, or identity-aware intermediaries. Second, they should aggressively document their IT assets, given the old rule, Most of the thousands of systems hit by the SSHStalker botnet were forgotten servers.

Also, IT security leaders need to realize that the real problem in their environment is security debt: The backlog of unpatched systems, the remaining known vulnerabilities, and the “we’ll do it next quarter” mentality. Dave Lewis, global CISO at 1Password, added that IT security leaders should make sure there are no compilers on production servers and that build tools are only on designated build servers.

See also: Researchers take down over 550 servers of the Kimwolf and Aisuru Botnets

Tips for IT security leaders

In addition to disabling SSH password authentication, the report recommends that IT security leaders:

• configure alerts that are triggered when non-system processes attempt to modify connection logs.
• remove compilers from production images if possible
• allow tools to run only in controlled build environments
• enforce output filtering based on business needs
• use an anti-virus scanner to detect binaries originating from the SSHStalker botnet
• to monitor for unauthorized execution of gcc
• set up notifications when compilers are run from user directories, /tmp or /dev/shm
• set up notifications when newly compiled binaries are executed within seconds or minutes of their creation
• set up alerts on servers to detect communication with unknown external chat or relay infrastructure