Das neu identifizierte Linux-Botnet SSHStalker zeigt, wie effektiv eine Kombination aus schwachen SSH-Konfigurationen, veralteten Linux-Kernen und unzureichend gehärteten Cloud-Umgebungen sein kann. Forschende des Sicherheitsunternehmens Flare berichten, dass der Schadcode vor allem auf Cloud-Infrastrukturen abzielt, mit einem besonderen Fokus auf Oracle-Cloud-Instanzen, aber grundsätzlich jede öffentlich erreichbare Linux-Maschine bedroht.
Angriffsablauf von SSHStalker: systematisches SSH-Scanning und selbstständige Ausbreitung
Der Einstiegspunkt der Angriffe ist ein aggressiver SSH-Brute-Force-Angriff. SSHStalker scannt großflächig das Internet nach offenen SSH-Diensten und probiert automatisiert schwache oder wiederverwendete Zugangsdaten aus. Dafür nutzen die Angreifer ein in Go geschriebenes Binary, das sich als nmap-Prozess tarnt. Diese Tarnung erschwert die Erkennung, weil Administratoren einen legitimen Netzwerkscanner vermuten könnten.
Sobald ein Login erfolgreich ist, wird das kompromittierte System sofort in die weitere Angriffskette eingebunden. Flare fand eine Datei mit Ergebnissen von knapp 7000 SSH-Scans allein im Januar 2026, ausgeführt von nur einem infizierten Host. Das weist auf ein wurmähnliches Verbreitungsmodell hin: Jede übernommene Maschine scannt selbst aktiv nach neuen Zielen und trägt zur Vergrößerung des Botnetzes bei.
Ausnutzung alter Linux-Kernel-Schwachstellen für Root-Rechte
Hat SSHStalker zunächst nur Zugang zu einem Konto mit eingeschränkten Rechten, folgt unmittelbar der Versuch der Privilegienerweiterung. Dazu bringt der Botnet-Code Exploits für 16 bekannte Schwachstellen im Linux-Kernel mit, die überwiegend Kernel-Versionen aus den Jahren 2009–2010 betreffen. Ziel ist der Sprung von einem normalen Benutzerkonto zu Root-Rechten.
Obwohl diese Sicherheitslücken seit Jahren gepatcht sind, finden sich in der Praxis weiterhin legacy-Systeme mit veralteten Kernen – etwa schlecht gewartete Server, interne Spezialanwendungen oder vergessene Test- und Entwicklungsumgebungen. Gerade solche Systeme werden häufig übersehen und können als Sprungbrett für laterale Bewegungen in sensiblere Netzsegmente dienen.
Architektur des Linux-Botnets SSHStalker und genutzte Payloads
Eine Besonderheit von SSHStalker ist der Umgang mit seinen Binaries: Nach erfolgreicher Infektion lädt der Bot einen GCC-Compiler nach oder nutzt bereits vorhandene Compiler und kompiliert Schadprogramme direkt auf dem Zielsystem. Dadurch unterscheiden sich die erzeugten Binärdateien von Host zu Host, was klassische signaturbasierte Erkennung deutlich erschwert.
Die erste Nutzlast besteht aus IRC-Bots in C mit fest kodierten Adressen der Command-and-Control-Server (C2) und vordefinierten Kanälen. Darüber bauen neue Opfer eine Verbindung zur Steuerungsinfrastruktur auf. Anschließend lädt SSHStalker Archive mit den Namen GS und bootbou, die weitere Bot-Varianten enthalten. Diese Komponenten übernehmen die Orchestrierung von Befehlen und deren Ausführungsreihenfolge auf den kompromittierten Knoten.
Zur Persistenz richtet SSHStalker cron-Jobs mit sehr kurzen Intervallen ein: Etwa alle 60 Sekunden wird geprüft, ob der Hauptprozess des Bots noch läuft, und bei Bedarf neu gestartet. Dieser „Watchdog“-Mechanismus sorgt dafür, dass das Botnet einfache Bereinigungsversuche und Prozessabstürze übersteht.
Ziele, Monetarisierung und mögliche Auswirkungen von SSHStalker
Die beobachteten Kampagnen konzentrieren sich auf Cloud-Server, insbesondere auf Oracle-Cloud-Instanzen. Solche Umgebungen bieten meist hohe Rechenleistung, sehr gute Netzwerkanbindung und teilweise weniger restriktive Regeln für ausgehenden Traffic. Damit eignen sie sich ideal als Plattform für Folgeangriffe oder ressourcenintensive Aktivitäten.
Für die Monetarisierung setzt SSHStalker auf mehrere Methoden. Zum einen durchsucht der Schadcode kompromittierte Systeme nach AWS-Zugriffsschlüsseln und anderen Cloud-Credentials, um zusätzliche Ressourcen zu kompromittieren. Zum anderen werden Websites gescannt und Tools für das Kryptomining nachgeladen. Unter den identifizierten Komponenten befindet sich der leistungsfähige Ethereum-Miner PhoenixMiner, der die CPU- und GPU-Ressourcen der infizierten Server maximal ausnutzen kann.
Zusätzlich sind im Code Funktionen für DDoS-Angriffe vorhanden. Während der Analyse wurden diese zwar noch nicht aktiv genutzt, die Bots verbleiben jedoch in einer Art „Bereitschaftsmodus“. Erfahrungsgemäß kann sich ein solches Botnet damit kurzfristig in eine Angriffsplattform für großvolumige Überlastungsangriffe verwandeln – mit entsprechenden Risiken für betroffene Unternehmen und deren Kunden.
Indikatoren für SSHStalker-Infektionen und wirksame Schutzmaßnahmen
Organisationen sollten ihre Linux- und Cloud-Umgebungen gezielt auf typische Indikatoren einer Kompromittierung (IoCs) durch SSHStalker und ähnliche Botnetze überwachen. Auffällig sind insbesondere:
1. Unerwartete Compiler auf Produktionssystemen: Die Installation oder Ausführung von GCC und anderen Compilern auf produktiven Servern, auf denen üblicherweise nur Laufzeitumgebungen vorhanden sein sollten, ist ein wichtiges Warnsignal.
2. Auffällige ausgehende Verbindungen: Verbindungen zu IRC-ähnlichen Infrastrukturen – insbesondere über ungewöhnliche Ports oder zu Domains mit schlechter Reputation – sollten automatisiert erkannt und blockiert werden. Moderne NDR- und IDS-Lösungen können hier hilfreich sein.
3. Kurz getaktete cron-Jobs und ungewöhnliche Pfade: Cron-Einträge mit Intervallen um die 60 Sekunden, die aus temporären Verzeichnissen oder Benutzerpfaden heraus Prozesse starten, sind verdächtig. Gleiches gilt für die Ausführung von Binaries aus Verzeichnissen wie /dev/shm oder /tmp.
Als präventive Maßnahmen empfehlen sich etablierte Best Practices des SSH- und Linux-Hardening. Dazu gehören insbesondere das Deaktivieren der Passwort-Authentifizierung zugunsten von SSH-Schlüsseln, strikte Vorgaben für Schlüsselverwaltung, Rate-Limits und IP-Filterung für SSH-Zugriffe, das Entfernen von Compilern aus Produktions-Images sowie die konsequente Aktualisierung des Linux-Kernels. Ergänzend sollten ausgehende Verbindungen aus Server-Segmenten nur nach dem „Need-to-connect“-Prinzip erlaubt und Skriptausführungen aus temporären Speicherbereichen untersagt werden.
Die Kampagne rund um SSHStalker verdeutlicht, dass vermeintlich „alte“ Schwachstellen und triviale Konfigurationsfehler wie schwache SSH-Passwörter weiterhin zu den effektivsten Einfallsvektoren gehören. Organisationen, die regelmäßig ihre Systeme auditieren, Kernel und Pakete aktualisieren, Passwort-Logins konsequent durch Schlüssel ersetzen und Anomalien in Cloud- und On-Prem-Umgebungen überwachen, reduzieren ihr Risiko signifikant, Teil eines Linux-Botnetzes wie SSHStalker zu werden und unbewusst fremde Angriffe oder Kryptomining zu unterstützen.
