Du hattest mich schon beim „Hi“ – der Mirai-basierte NoaBot tritt in Erscheinung
Zusammenfassung
Sicherheitsforscher von Akamai haben eine neue Kryptomining-Kampagne entdeckt, die seit Anfang 2023 aktiv ist.
Die Malware wird mithilfe eines nutzerdefinierten Mirai-Botnets, das von den Bedrohungsakteuren modifiziert wurde, über das SSH-Protokoll verbreitet.
Das neue Botnet namens NoaBot verfügt über einen wurmfähigen Auto-Verteiler und eine SSH-Schlüssel-Backdoor zum Herunterladen und Ausführen zusätzlicher Binärdateien bzw. zur eigenständigen Verbreitung bei neuen Opfern.
Als Teil des Angriffs wird eine modifizierte Version des XMRig-Miners abgelegt. Der Miner verschleiert seine Konfiguration und nutzt außerdem einen spezifischen Mining-Pool, um zu vermeiden, dass die vom Miner verwendete Wallet-Adresse angegeben wird.
Wir konnten eine Verbindung des Botnets zum P2PInfect-Wurm nachweisen, der durch Unit 42 im Juli 2023 entdeckt wurde.
Die Malware-Verschleierung und der nutzerdefinierte Code weisen ein hohes Maß an Betriebssicherheit auf, was in der Regel ein Anzeichen für versierte Bedrohungsakteure ist. Die Benennung der Binärdateien und einiger darin enthaltener Zeichenfolgen ist jedoch ziemlich kindisch. Dadurch wird die Zuordnung erschwert.
2023 konnten wir über 800 verschiedene Angriffs-IPs beobachten, die gleichmäßig über die ganze Welt verteilt waren.
Wir haben IOCs (Indicators of Compromise), Abfragen, Signaturen und Skripte veröffentlicht, die zum Testen auf Infektionen verwendet werden können.
Einführung
NoaBot ist ein weiteres Mirai-basiertes Botnet. Das Mirai- Botnet ist ein Wurm-Botnet, das auf Linux-basierte IoT-Geräte (Internet der Dinge, Internet of Things) abzielt. Es wird für DDoS-Angriffe (Distributed Denial of Service),verwendet. Das ursprüngliche Mirai-Botnet wurde 2016 entdeckt, jedoch wurde dessen Quellcode öffentlich gemacht und seither sind zahlreiche Varianten im Umlauf.
Wir haben die NoaBot-Kampagne erstmals Anfang 2023 entdeckt. Seitdem wurden zwei Entwicklungen der Malware beobachtet, die aus zusätzlichen Verschleierungen oder einer Änderung der Command-and-Control- (C2) und Mining-Pool-Domains bestehen (Abbildung 1). Es wurden auch mehrere Vorfälle beobachtet, bei denen Varianten des P2PInfect-Wurms abgelegt wurden. Das ist ein Indiz dafür, dass die beiden Kampagnen miteinander verbunden sind.
Abb. 1: Malware-Aktivität für NoaBot im Lauf der Zeit
Das Botnet
Das NoaBot-Botnet verfügt über die meisten Funktionen des ursprünglichen Mirai-Botnet (z. B. ein Scannermodul und ein Angreifermodul, das den Prozessnamen verbirgt usw.), aber es lassen sich auch zahlreiche Unterschiede zum ursprünglichen Quellcodevon Mirai feststellen. In erster Linie basiert der Verteiler der Malware auf SSH und nicht wie bei Mirai auf Telnet.
Der SSH-Scanner wurde offenbar spezifisch entwickelt und weist ein eigenartiges Verhalten auf: Sobald eine Verbindung hergestellt ist, sendet das Botnet einfach die Zeichenfolge „Hi“ und beendet die Verbindung (Abbildung 2). Eine schnelle Beendigung ist im Zusammenhang mit einem Scanner sinnvoll, da es genügt zu prüfen, ob eine Verbindung vorhanden ist, diese jedoch nicht offen gehalten werden muss. Doch warum macht er sich die Mühe, „Hi“ zu senden? Es bleibt ein Rätsel.
Abb. 2: Das SSH-Paket mit der Zeichenfolge „Hi“. Es handelt sich nicht um ein gültiges SSH-Paket, weswegen es von Wireshark als fehlerhaft gekennzeichnet wird.
Eine weitere Eigenart der Malware sind die eingebetteten Songtexte. Frühere Varianten des Botnets enthielten Texte aus dem Song „Who’s Ready for Tomorrow“ von Rat Boy und IBDY (Abbildung 3). Soweit ersichtlich, haben diese Texte keinen Zweck. In später gefundenen Varianten waren sie nicht enthalten.
Abb. 3: Die eingebetteten Songtexte, die offenbar keinen Zweck erfüllen.
Das Botnet unterscheidet sich von Mirai auch dadurch, dass es ein anderes Credential-Wörterbuch für seinen SSH-Scanner verwendet und viele Funktionen nach der Infiltration enthält, wie z. B. die Installation eines neuen autorisierten SSH-Schlüssels als Backdoor, um zusätzliche Binärdateien herunterzuladen und auszuführen oder sich selbst bei neuen Opfern auszubreiten (Abbildung 4).
Abb. 4: Botnet-Befehl „switch case“
Ebenfalls im Gegensatz zu Mirai, das normalerweise mit GCC kompiliert wird (zumindest laut Quellcode und Leitfaden des Autors), wird NoaBot mit uClibc kompiliert. Das scheint die Art und Weise zu verändern, wie Antiviren-Engines die Malware erkennen. Während andere Mirai-Varianten in der Regel mit einer Mirai-Signatur erkannt werden, gehören die Antiviren-Signaturen von NoaBot zu einem SSH-Scanner oder einem generischen Trojaner (Abbildung 5).
Die Malware wird auch statisch kompiliert und etwaige Symbole werden entfernt. Neben der Tatsache, dass es sich um eine untypische Kompilierung handelte, war dies die Ursache dafür, dass sich das Reverse-Engineering der Malware als frustrierende Übung erwies.
Bei neueren Varianten des Botnets wurde die Zeichenfolge ebenfalls verschleiert und nicht als Klartext gespeichert. Dies erschwerte die Extraktion von Details aus den Binärdateien und die Disassemblierung bestimmter Teile, die Codierung selbst war jedoch einfach und leicht rückzuentwickeln.
Außerdem wurden im Laufe der Zeit Befehlszeilenargumente hinzugefügt. Das interessanteste ist das Flag „noa“, das das Botnet dazu veranlasste, eine Persistenzmethode in Form eines crontab-Eintrags zu installieren, der nach einem Neustart ausgeführt wird.
Zugleich hat es den Anschein, als ob dieses Flag im freien Internet häufig verwendet wurde, da einige der durch Antiviren-Programme erkannten Botnet-Varianten das Präfix „Noa-“ aufwiesen.
Die in Abbildung 4 dargestellten Vorgänge nach der Infiltration stellen eine weitere Entwicklungsstufe dar. Diese waren bei den zuvor von uns untersuchten Varianten nicht vorhanden.
Abb. 5: NoaBot-Erkennungen (links) im Vergleich zu einer anderen Mirai-Variante (rechts)
Der Miner – und der Grund für die Unauffindbarkeit seiner Wallet-Adresse
Der Miner selbst ist viel unkomplizierter. Es handelt sich um den Standard-Miner XMRig, auch wenn dieser selbst kompiliert wurde und die Angreifer vor der Ausführung des Miners einige Programmzeilen hinzugefügt haben, um die Mining-Konfiguration zu extrahieren, anstatt diese über Befehlszeilen bereitzustellen oder als Klartext innerhalb der Binärdatei zu speichern (Abbildung 6).
Abb. 6: Die Hauptfunktion des Miners
Wie ersichtlich, gibt es vor dem Funktionsaufruf zur Erstellung der XMRig-Konfiguration noch einige weitere Funktionsaufrufe. Wenn ein Fehler auftritt, wird der Miner beendet, anderenfalls wird er zur standardmäßigen XMRig-Miner-Logik weitergeleitet. (Sie können die Dekompilierung oben mit dem eigentlichen Quellcode von XMRig vergleichen.) Warum ist die XMRig-Konfiguration für Sicherheitsforscher interessant? In der Regel enthält sie Details zum Mining-Pool, mit dem sie eine Verbindung herstellt, sowie die Wallet-Adresse für den Erhalt von Mining-Zahlungen. Durch Abrufen der Wallet-Adresse und Verfolgung der an diese fließenden Zahlungen (die normalerweise von öffentlichen Pools verfolgt werden), lässt sich schätzen, wie profitabel das Kryptomining ist.
Dieses Mal waren uns die Angreifer jedoch voraus. Werfen wir daher einen genaueren Blick auf die Erstellung der Konfiguration. Im Open-Source-Code von XMRig können Miner Konfigurationen auf zwei Arten akzeptieren – entweder über die Befehlszeile oder über Umgebungsvariablen. In diesem Fall haben sich die Angreifer dafür entschieden, den ursprünglichen XMRig-Code nicht zu ändern und stattdessen Teile vor der Hauptfunktion hinzuzufügen. Um die Notwendigkeit von Befehlszeilenargumenten zu umgehen (die als Indicator of Compromise – IOC – ein Warnhinweis für Abwehrmechanismen sein können), mussten die Angreifer die eigene Befehlszeile durch „aussagekräftigere“ Argumente ersetzen (aus technischer Sicht muss argv ersetzt werden), bevor die Kontrolle an den XMRig-Code übergeben wird. Das Botnet führt den Miner mit (höchstens) einem Argument aus, das diesen anweist, dessen Protokolle zu drucken.
Bevor die Befehlszeile ersetzt wird, muss der Miner jedoch seine Konfiguration erstellen. Zunächst werden grundlegende Argumente kopiert, die im Klartext gespeichert sind – das rig-id-Flag, das den Miner mit drei zufälligen Buchstaben identifiziert, die Threads-Flags und ein Platzhalter für die IP-Adresse des Pools (Abbildung 7).
Da die Konfigurationen über die xmm-Register geladen werden, verpasst IDA eigentlich die ersten beiden geladenen Argumente, nämlich den Binärnamen und den Pool-IP-Platzhalter.
Abb. 7: Kopieren der Basis-Konfiguration des Miners
Als Nächstes entschlüsselt der Miner den Domainnamen des Pools. Der Domainname wird verschlüsselt in einigen Datenblöcken gespeichert, die über XOR-Vorgänge entschlüsselt werden. Obwohl XMRig auch mit einem Domainnamen funktioniert, haben sich die Angreifer für einen zusätzlichen Schritt entschieden und ihre eigene DNS-Auflösungsfunktion implementiert. Sie kommunizieren direkt mit dem DNS-Server von Google (8.8.8.8) und analysieren dessen Antwort, um den Domainnamen in eine IP-Adresse aufzulösen.
Der letzte Teil der Konfiguration wird auf ähnliche Weise verschlüsselt und ist der Passkey, mit dem der Miner eine Verbindung zum Pool herstellt. Alles in allem sieht die Gesamtkonfiguration des Miners etwa so aus:
<miner_binary_name> -o <pool_ip> --rig-id <random_id> --threads <cpus> –pass espana*tea |
Fällt Ihnen auf, dass etwas fehlt? Genau, es gibt keine Wallet-Adresse.
Wir glauben, dass sich die Angreifer dafür entschieden haben, anstelle eines öffentlichen Pools ihren eigenen privaten Pool zu betreiben, wodurch die Notwendigkeit entfällt, eine Wallet festzulegen (eigener Pool, eigene Regeln!). Bei den von uns untersuchten Varianten haben wir jedoch festgestellt, dass die Domains des Miners nicht mit dem DNS von Google aufgelöst wurden. Daher können wir unsere Theorie nicht wirklich beweisen oder weitere Daten aus dem Pool sammeln, da die uns vorliegenden Domains nicht mehr auflösbar sind. Wir haben in letzter Zeit keine Vorfälle beobachtet, bei denen der Miner abgelegt wird. Es könnte daher also auch sein, dass die Angreifer sich entschieden haben, aussichtsreichere Wege zu beschreiten.
Mirai ist zu alt und hat etwas Rost angesetzt
Bei aktuell beobachteten Vorfällen waren auch Varianten von P2PInfect vertreten – Ein Peer-to-Peer-Wurm, der sich selbst repliziert und in Rust programmiert wurde. P2PInfect wurde erstmals im Juli 2023 entdeckt, NoaBot-Aktivitäten werden hingegen seit Januar 2023 beobachtet. NoaBot ist also etwas älter als P2PInfect. Warum also der Umstieg von Mirai auf etwas anderes? Etwas, das womöglich sogar nutzerdefiniert ist? Es gibt dazu keine klare Antwort, wir haben jedoch ein paar Vermutungen.
Erstens ist das Reverse Engineering von nutzerdefiniertem Code schwieriger als wiederverwendeter Code, da dieser verändert wird. Zweitens scheinen die Angreifer technisch ziemlich versiert zu sein, sodass sie die Entwicklung von Malware möglicherweise aus Neugier oder aus Langeweile (oder aus beiden Gründen) betreiben. Da P2PInfect auf Redis-Server abzielt, könnte es sich um verschiedene Tools für unterschiedliche Zwecke handeln.
Woher wissen wir, dass es sich um dieselben Bedrohungsakteure und nicht um eine wie auch immer geartete Kooperation handelt? Wir sind uns nicht zu 100 % sicher, aber wir sind nahe dran. Alles läuft auf die technische Professionalität der Malware hinaus, gepaart mit dem Reifegrad eines Teenagers, der aus Insider-Witzen wie dem Einfügen von Obszönitäten in den Namen des Miners, dem Einbetten von Pop-Liedtexten in Malware-Binärdateien und der Begrüßung mit „Hi“ beim Scannen nach offenen Ports ersichtlich wird.
P2PInfect setzt diese Tradition fort. Es scheint ein ausgeklügeltes Tool zu sein, doch es verwendet einen Unix-Socket und nennt ihn „NunzombiE“ (Abbildung 8). Und auch wenn NunzombiE während der Laufzeit verschleiert und decodiert wird, weist der Wurm auch eingebettete Zeichenfolgen für „fast_vuln_file“ und „slow_vuln_file“ auf – völlig legitime Zeichenfolgen für eine ausführbare Datei, die keinerlei Verdacht erwecken.
Abb. 8: Strace des P2PInfect-Wurms, der einen Unix-Socket namens NunzombiE erstellt
Analyse der Geschädigten
Unsere Honeypots wurden 2023 über 849 verschiedene Quell-IPs angegriffen. Betracht man deren geografische Lage, lässt sich eine ziemlich gleichmäßige weltweite Verteilung der Aktivitäten erkennen. Das ergibt Sinn, da die Malware wurmfähig ist, sodass jedes neue Opfer selbst zum Angreifer wird. Es gibt jedoch einen auffallenden Aktivitäts-Hotspot in China. Dieser zeichnet für fast 10 % aller Angriffe verantwortlich, die im Jahr 2023 beobachtet wurden – es handelt sich um hellsten Punkt in Abbildung 9.
Abb. 9: Globale Heatmap der Standorte von NoaBot-Angriffsquellen
Abwehr, Erkennung, Emulation
Die von der Malware angewendete Methode der lateralen Bewegung erfolgt über gewöhnliche Angriffe auf SSH-Credential-Wörterbücher.
Die Einschränkung des beliebigen SSH-Internetzugriffs auf Ihr Netzwerk verringert das Infektionsrisiko erheblich. Darüber hinaus trägt auch die Verwendung starker (anstelle standardmäßiger oder zufällig generierter) Passwörter zur Verbesserung der Sicherheit Ihres Netzwerks bei, da die Malware eine einfache Liste von einfach zu erratenden Passwörtern verwendet. Wir haben die von der Malware verwendeten Anmeldeinformationen in unserem freigegebenen GitHub-Repository geteilt.
Zur Erkennung der Malware gibt es abgesehen von der Suche nach ihrem Binärnamen kaum etwas zu sagen. Sie wird von einem zufällig generierten Ordner unter /lib ausgeführt, daher bieten sich wahrscheinlich Prozessnamen an. Es sollte auch möglich sein, den Cron-Job zu ermitteln, falls ein solcher installiert wurde. In unserem Repository sind auch eine IOC-CSV-Datei sowie einige YARA-Signaturen für die Mine verfügbar.
Falls Sie Ihre Umgebung mit dem SSH-Spreader des Botnets testen möchten, haben wir eine Konfigurationsdatei für den Infection Monkey– unsere Open-Source-Plattform zur Emulation von Gegnern – erstellt (im Anhang finden Sie eine kurze Erklärung zur Verwendung von Infection Monkey). Beachten Sie bitte, dass es für uns schwer möglich ist, sämtliche Anmeldedaten zu testen, da die Malware einen sehr großen Satz verwendet (der Malware sind die DV-Kosten und die nötige Zeit im Gegensatz zu uns egal). Stattdessen haben wir uns entschieden, nur die gebräuchlicheren Anmeldedaten in die Konfiguration aufzunehmen. Wenn Sie weitere (oder andere) Anmeldedaten hinzufügen möchten, können Sie diese Konfiguration zu Grunde legen und Ihre eigenen Änderungen ergänzen.
Diese Infection-Monkey-Konfiguration fügt auch eine Zeichenfolge zur Maskierung hinzu, die dazu führt, dass unsere YARA-Signaturen auf der Payload des Monkey-Agenten ausgelöst werden, so dass Sie diese auch verwenden können, um eine Erkennung zu testen.
Sobald der Infection Monkey Ihre Umgebung getestet hat, erstellt er einen Bericht über alle Computer, in die er einbrechen konnte. Sie können auch das Kryptojacking-Plug-in des Monkeys verwenden, wenn Sie einen weitergehenden Angriff simulieren und anhand stärkerer Anmeldedaten testen möchten.
Zusammenfassung
Auf den ersten Blick ist NoaBot keine besonders ausgeklügelte Kampagne – es handelt sich „lediglich“ um eine Mirai-Variante und einen XMRig-Kryptominer, die heutzutage im Dutzend vorkommen. Die Verschleierungen, die der Malware hinzugefügt wurden, und die Erweiterungen des ursprünglichen Quellcodes vermitteln jedoch einen völlig anderen Eindruck von der Raffinesse der Angreifer. Trotz der technischen Fähigkeiten der Angreifer scheinen sie einige unausgereifte Namenskonventionen zu verwenden (zum Beispiel ein Unix-Socket namens „NunzombiE“), die bei verschiedenen Malware-Varianten und Binärdateien beobachtet wurden. Wir haben diese Eigenschaft genutzt, um NoaBot mit P2PInfect zu verknüpfen, und vielleicht wird dieses Erkennungsmerkmal auch für zukünftige Malware-Kampagnen seine Gültigkeit behalten.
Anhang: Verwendung von Infection Monkey zum Test Ihrer Umgebung
Installieren Sie den Infection Monkey, basierend auf Ihrem Betriebssystem:
Folgen Sie den Anweisungen zur Einrichtung.
Laden Sie das SSH-Exploiter-Plug-in auf der Seite Plug-ins in der Nutzeroberfläche von Infection Monkey.
Abb. 10: Der Bildschirm des Infection-Monkey-Plug-ins. Verwenden Sie die Suchleiste, um nach dem SSH-Exploiter-Plug-in zu suchen und dieses herunterzuladen.
Importieren Sie die Konfigurationsdatei zur Emulation von NoaBot.
Abb. 11: Der Konfigurationsbildschirm für den Infection Monkey. Sie können die von uns bereitgestellte Konfiguration importieren, indem Sie auf die Schaltfläche „Konfiguration importieren“ klicken.
Konfigurieren Sie auf der Konfigurationsseite in der Registerkarte "Netzwerkanalyse" die Ziele, auf die ein Angriff versucht werden soll.
Führen Sie den Monkey aus.
Gehen Sie auf die Kartenseite, um den Angriff zu beobachten.
Wenn Sie die Simulation zu irgendeinem Zeitpunkt stoppen möchten, drücken Sie einfach die Taste "Kill all monkeys" (Alle Affen töten), um den Angriff zu beenden.
