Honeypot-Auswertung: Was ein frischer Server in den ersten 100 Minuten erlebt

Ein Honeypot der Redaktion verzeichnete am 12. November 2026 in den ersten rund 100 Minuten nach dem Start 72 Verbindungen von 28 verschiedenen IP-Adressen. Der erste fremde Zugriff kam wenige Minuten nach dem Einschalten, zwei Sekunden später folgte der erste Anmeldeversuch. Das häufigste Zugangspaar war mit großem Abstand admin/admin.

Relevant ist das für alle, die Server, Router, Kameras oder NAS-Geräte mit SSH oder Telnet ins Internet stellen. Wer nur Schlüssel-Anmeldung zulässt und Telnet abgeschaltet hat, muss nichts Neues tun. Wer noch Standardpasswörter oder Passwort-Anmeldung offen hat, sollte das nicht auf das nächste Wartungsfenster verschieben.

Was ist passiert?

Der Honeypot läuft mit der Open-Source-Software Cowrie auf einem frisch angelegten Cloud-Server in Frankfurt. Er bietet SSH auf Port 22 und Telnet auf Port 23 an, nimmt fast jede Anmeldung an und protokolliert, was die Gegenseite danach eintippt. Ausgewertet ist der Zeitraum vom Start gegen 20:20 Uhr bis etwa 22:00 Uhr MEZ, eigene Zugriffe sind herausgefiltert.

Telnet lag mit 39 Verbindungen vor SSH mit 33. Von 58 Anmeldeversuchen nutzten 36 den Benutzernamen admin und 13 root. Das Paar admin/admin kam 35-mal, dahinter folgten mit je zwei Versuchen Passwörter wie Abcd1234, admin123 oder qwerty12345. Insgesamt tippten die Bots 498 Befehle. Schadsoftware lud in diesem Zeitraum niemand herunter.

Mirai-Muster über Telnet

Der häufigste Befehl war /bin/busybox HISILICON mit 51 Aufrufen, ausschließlich über Telnet. Dazu kamen je 34-mal enable, system, shell und sh. Diese Befehle sendet auch der öffentlich verfügbare Quelltext des Mirai-Botnetzes nach der Anmeldung, das Original prüft danach mit /bin/busybox MIRAI, ob es auf einer echten Busybox-Shell gelandet ist. Im Honeypot stand an dieser Stelle HISILICON. Laut einer Studie auf der USENIX Security 2017 bestand Mirai vor allem aus eingebetteten Geräten und IoT-Geräten und erreichte zur Spitze rund 600.000 Infektionen. Anschließend legten die Bots in zwölf Verzeichnissen wie /var/tmp, /dev/shm und /root eine leere Datei an, machten sie ausführbar und starteten sie, vermutlich um ein beschreibbares Verzeichnis für einen Nachlader zu finden.

Hintertür per SSH-Schlüssel

In drei SSH-Sitzungen versuchten Angreifer zuerst mit chattr -ia .ssh einen möglichen Schreibschutz aufzuheben, löschten dann das Verzeichnis ~/.ssh und legten einen eigenen RSA-Schlüssel mit dem Kommentar „mdrfckr“ ab. Der Schlüssel beginnt mit AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4… und ist identisch mit dem Schlüssel, den Kaspersky im April 2025 bei der Outlaw-Gruppe beschrieb. Die Prüfsumme der abgelegten Datei entspricht der aus einem Gastbeitrag beim SANS ISC, laut dem die Kampagne seit knapp sieben Jahren dokumentiert ist. Dazu passen zwei weitere Funde: ein chpasswd, das das root-Passwort ändern sollte, und ein Befehl, der Skripte konkurrierender Bots wie /tmp/secure.sh beendet und /etc/hosts.deny leert.

Für wen ist das relevant?

Betroffen ist jedes System, das SSH oder Telnet mit Passwort-Anmeldung aus dem Internet erreichbar macht. Die Telnet-Abtastung zielt nach der Mirai-Logik auf eingebettete Geräte mit Busybox, etwa Router oder Kameras. Die SSH-Hintertür trifft Linux-Server mit schwachen Passwörtern. Nicht betroffen sind Systeme, die SSH nur mit Schlüssel erlauben und Telnet gar nicht anbieten.

Wie kritisch ist das?

Es geht nicht um eine Sicherheitslücke, sondern um schwache Zugangsdaten. Gelingt die Anmeldung, haben Angreifer eine Shell, sperren mit dem neuen Passwort den Besitzer aus und behalten über den Schlüssel dauerhaft Zugang. Ein neuer Server ist nach Minuten im Visier.

Was sollten Admins jetzt tun?

• Inventar: Mit sudo ss -tlnp prüfen, welche Dienste auf Port 22 und 23 lauschen. Telnet abschalten, auch auf Routern, Kameras und NAS-Geräten.
• Standardpasswörter wie admin/admin auf allen Geräten ändern, vor allem bei Kameras und Rekordern.
• SSH nur mit Schlüssel: PasswordAuthentication no, KbdInteractiveAuthentication no und PermitRootLogin prohibit-password setzen, Dateien unter sshd_config.d mitprüfen und das Ergebnis mit sudo sshd -T kontrollieren.
• Zugriff einschränken: SSH per Firewall nur aus bekannten Netzen oder über VPN erreichbar machen.
• Wiederholte Fehlversuche mit fail2ban oder CrowdSec sperren.
• Kompromittierung prüfen: authorized_keys aller Benutzer nach „mdrfckr“ durchsuchen, mit lsattr -d ~/.ssh auf gesetzte Attribute achten und /etc/hosts.deny mit dem Sollstand vergleichen.

Einordnung für Unternehmen

Die Auswertung umfasst nur einen Server und knapp zwei Stunden, sie ist also eine Momentaufnahme und keine Statistik. Sie bestätigt aber, was Sicherheitsforscher seit Jahren beschreiben: Die Bots arbeiten mit Listen, alten Werkzeugen und Standardpasswörtern. Wer Passwort-Anmeldung und Telnet konsequent abschaltet, nimmt ihnen fast alle Angriffsfläche, die hier zu sehen war.

Passende Anleitungen auf S-EDV

• Die ersten Stunden im Netz: Was an einem neuen VPS anklopft
• VPS absichern und härten: UFW, SSH-Schlüssel und Fail2Ban
• CrowdSec mit Docker installieren

Quellen

• Mirai-Quelltext: Zeichenketten des Telnet-Scanners (GitHub-Spiegel)
• USENIX Security 2017: Studie zum Mirai-Botnetz
• Kaspersky Securelist: Analyse der Outlaw-Gruppe vom 29. April 2025
• SANS ISC: Gastbeitrag zur mdrfckr-Kampagne vom 15. Mai 2026
• Cowrie: SSH- und Telnet-Honeypot