Versehentliches Abstürzen eines Botnets
Zusammenfassung
Die Forscher von Akamai haben ihre Untersuchung von KmsdBot, ein Cryptomining-Botnet, fortgesetzt, und dabei beobachtet, wie die Autoren es versehentlich abstürzen ließen.
In unserer kontrollierten Umgebung konnten wir Befehle an den Bot senden, um seine Funktionalität und Angriffssignaturen zu testen.
Im Verlauf dieser Analyse führte ein Syntaxfehler dazu, dass der Bot keine Befehle mehr versendete, was das Botnet effektiv zerstörte.
Da dieses spezielle Botnet keine Persistenzfunktionen hat, kann es seine Mission nur dann fortsetzen, wenn es das System erneut infiziert.
Einführung
Anfang des Monats veröffentlichte Akamai Security Research einen Blogbeitrag über KmsdBot,ein Cryptomining-Botnet, das seine Opfer über SSH und schwache Anmeldedaten infizierte. Wir analysierten und berichteten über dieses Botnet, nachdem es einen unserer Honeypots infiziert hatte.
Nach dieser Veröffentlichung haben wir das Botnet weiter überwacht und jetzt haben wir einige Neuigkeiten – zum Beispiel, dass wir es unbrauchbar gemacht haben. In diesem Blogbeitrag erläutern wir die Schritte, die wir zur Untersuchung von KmsdBot unternommen haben, durch die wir unsere eigenen Befehle ausführen konnten, und die schließlich zum Untergang des Botnets führten.
Command and Control kontrollieren
Das gefährlichste Element eines schädlichen Bots ist die Fähigkeit, sich Command and Control (CnC) zu verschaffen. Da KmsdBot über CnC-Funktionen verfügt, wollten wir in diesem Zusammenhang verschiedene Szenarien testen. Ein Teil dieses Tests bestand darin, ein aktuelles Beispiel von KmsdBot zu modifizieren, um mit einer IP-Adresse im RFC 1918-Adressraum zu kommunizieren.
So konnten wir in einer kontrollierten Umgebung experimentieren – und letztendlich dem Bot unsere eigenen Befehle senden, um seine Funktionalität und Angriffssignaturen zu testen. Interessanterweise beendete der Bot nach einem einzigen falsch formatierten Befehl die Übertragung von Befehlen vollständig. Natürlich haben wir das untersucht. Man trifft nicht jeden Tag auf ein Botnet, das durch das Werk der Bedrohungsakteure selbst zerstört wird.
So haben wir es gefunden
Abb. 1: Disassemblierung der Funktion sys.main.connect()
Es ist zu sehen, dass der String Slice an Speicherposition 0x00632f19 gespeichert ist. Wir können zu dieser Adresse in der Binärdatei springen und ihren Inhalt so ändern, dass er auf eine Netzwerkadresse im RFC 1918-Raum verweist, und zwar irgendwo in 192.168.0.0/24, das wir steuern.
Auf diese Weise können wir wie CnC agieren und eigene Angriffsbefehle senden, um den Angriffsverkehr an ein Ziel zu leiten, an dem wir den Netzwerktraffic protokollieren können.
Abb. 2: Die Adresse ist aufgrund der Byte-Reihenfolge in Hex .861.291 rückwärts geschrieben
Unser neues CnC ist 192.168.0.31 am Port 57388 (Abbildung 2). Wir wissen, dass CnC in Klartext kommuniziert, sodass das Senden von Malware-Befehlen über Netcat erfolgen kann. Anschließend richteten wir zwei virtuelle Maschinen ein: eine, auf der die Malware ausgeführt wird, und die andere, die als unser CnC fungiert.
Während der Tests stellten wir fest, dass das Botnet keine Angriffsbefehle mehr sendet, nachdem es einen einzelnen fehlerhaften Befehl erhielt. Der Befehl:
!bigdata www.bitcoin.com443 / 30 3 3 100
Ein aufmerksamer Leser wird feststellen, dass zwischen der Zielwebsite und dem Port kein Leerzeichen vorhanden ist. Der Bot verfügt über keine integrierte Fehlerermittlung, die die korrekte Formatierung der Befehle überprüft.
Aus diesem Grund führt ein falsch formatierter Befehl dazu, dass Go Binary abstürzt, wobei eine Stapelüberwachung den Fehler „index out of range“ ausgibt. Dies liegt daran, dass die falsche Anzahl von Argumenten angegeben wurde. Wir haben diese Theorie mit unserem CnC- und Bot-Setup getestet (Abbildung 3).
Abb. 3: CnC wird emuliert und der fehlerhafte Befehl reproduziert
Abb. 4: Der Bot ist abgestürzt, weil die falsche Anzahl von Argumenten angegeben wurde
Dieser fehlerhafte Befehl hat wahrscheinlich den gesamten Botnet-Code abstürzen lassen, der auf infizierten Maschinen ausgeführt wurde und mit CnC kommunizierte – im Grunde genommen wurde das Botnet zerstört. Da der Bot keine Persistenzfunktionen auf einer infizierten Maschine hat, ist jetzt die einzige Möglichkeit, die Maschine erneut zu infizieren und das Botnet neu aufzubauen.
Fazit
Solche Dinge passieren im Sicherheitsbereich nicht oft. In unserer Welt von Zero-Days und Burnout ist es eine schöne Geschichte, eine Bedrohung zu entdecken, die mit dem Coding-Äquivalent eines Tippfehlers abgewehrt werden kann. Dieses Botnet hat es auf einige sehr große Luxusmarken und Gaming-Unternehmen abgesehen, und doch kann es mit einem einzigen fehlgeschlagenen Befehl nicht mehr fortfahren. Hier zeigt sich anschaulich die Unberechenbarkeit der Technologie, von der sogar die Angreifer selbst betroffen sein können.
Ziel von Akamai Security Research ist es, neue Entdeckungen zu verfolgen, zu erkennen, zu dokumentieren und zu veröffentlichen, um die Sicherheit und Stabilität von Akamai, den Kunden von Akamai und dem gesamten Internet zu schützen. Wir werden diese Angriffe weiterhin überwachen und diesen Blog entsprechend aktualisieren. Für Echtzeit-Updates zur Sicherheitsforschung folgen Sie uns auf Twitter.
