Untersuchung des Wiederauflebens der Mexals-Kampagne
Zusammenfassung
Redaktion und weitere Kommentare von Tricia Howard
Akamai Security Research hat das Wiederaufleben von Mexals verfolgt und analysiert – einer wahrscheinlich rumänischen Cryptojacking-Kampagne.
Die Kampagne ist seit mindestens 2020 aktiv und wurde zuvor in einem Bericht von Bitdefender vom Juli 2021 behandelt.
Die neueste Welle von Malware-Angriffen und -Verbesserungen scheint im Oktober 2022 begonnen zu haben. Die Gruppe nennt sich jetzt Diicot, was auch der Name der rumänischen Agentur zur Bekämpfung von Terrorismus und organisierter Kriminalität ist.
Nach der Erkennung schädlicher DNS‑Inhalte bei einem Akamai-Kunden begannen die Sicherheitsforscher von Akamai damit, die Kampagne zu analysieren. Alle betroffenen Akamai-Kunden wurden umgehend benachrichtigt und es wurden entsprechende Gegenmaßnahmen ergriffen.
Die Angreifer nutzen eine lange Kette von Payloads, bevor sie schließlich einen Monero-Cryptominer installieren.
Zu den neuen Funktionen gehören die Verwendung eines SSH‑Wurmmoduls (Secure Shell Protocol), verbessertes Reporting, bessere Payloadverschlüsselung und ein neues LAN-Spreader-Modul.
Anhand einer Analyse des Miner-Pools schätzen wir, dass die Angreifer XMR-Coins im Wert von etwa 10.000 US-Dollar gemint haben.
Wir bieten Abwehrstrategien, Erkennungstools und ein vollständiges Repository mit Indicators of Compromise (IoCs). Vor der Veröffentlichung dieses Blogs haben wir außerdem Kontakt zu den Opfern dieser Tools aufgenommen.
Einführung
Die Sicherheitsforscher von Akamai haben eine aktive Cryptojacking-Kampagne untersucht, die unserer Meinung nach ein Wiederaufleben der von Bitdefender behandelten Kampagne aus dem Jahr 2021 ist. Zwar gibt es mehrere Übereinstimmungen mit dem ursprünglichen Bericht, doch diese Malware wurde seither verbessert .
Eine der Änderungen zwischen den beiden Kampagnen ist der Name: Die Gruppe, die sich früher „Mexals“ nannte (siehe Webseite in Abbildung 1), nennt sich jetzt Diicot und eines ihrer Tools trägt den gleichen Namen. Diicot ist auch der Name der rumänischen Anti-Terror-Behörde – um Verwirrung zu vermeiden, werden wir die Bedrohungsgruppe im Folgenden als „Mexals“ bezeichnen. Bei der Analyse des Modus Operandi, der Payloadkette und der IoCs wurde deutlich, dass diese beiden Kampagnen trotz der Namensänderung miteinander in Zusammenhang stehen.
Abb. 1: Die Standardwebseite, die bei der Domain der Angreifer angezeigt wird, die auch ihre Payloads hostet
In dieser Kampagne haben wir eine verbesserte Verschleierung, unauffälligere Dateinamen und nutzerdefinierte Mining-Pool-Proxys gefunden, die in der vorherigen Iteration nicht vorhanden waren. Die Angriffskette beginnt mit dem Brute Forcing der SSH-Anmeldedaten. Dann kommt eine lange Kette verdeckter Payloads, die schließlich einen XMRig-Cryptominer installieren. Eine der installierten Payloads ist ein Wurmmodul, von dem wir glauben, dass es bei diesem Wiederaufleben aktiv beteiligt war.
Wir glauben auch, dass die Angriffsserver der Gruppe in einem niederländischen VPS gehostet werden und dass ihre Opfer über den ganzen Globus verteilt sind. Wir schätzen, dass die Angreifer mehr als 10.000 US-Dollar in XMR-Coins minen konnten.
Andere Hacker haben ein Toolkit, diese Gruppe hat eine Kette
In unserer Analyse der Infektionskette der Angreifer fanden wir acht ausführbare Dateien. Diese ausführbaren Dateien scheinen sich nicht wesentlich von dem zu unterscheiden, was Bitdefender damals gefunden hat – abgesehen von den Dateinamen und Pfaden und ein paar neuen Funktionen (Abbildung 2).
Payloadname |
Nutzung |
|---|---|
History |
Ein Bash-Skript. Überprüft, ob Update ausgeführt wird. Führt es aus, wenn das nicht der Fall ist. |
Update |
Ein kompiliertes Bash-Skript. Benachrichtigt die Angreifer über einen Discord-Webhook und führt einen Netzwerkscan in einem zufälligen IP-Netzwerk der Klasse B durch, um Maschinen mit offenem SSH zu finden. Liefert die Ergebnisse an aliases. |
Chrome/ps |
Ein Netzwerkscanner. Akzeptiert einen Netzwerkbereich der Klasse B (255.255.0.0) und einen Port. Durchsucht den Netzwerkbereich nach Maschinen mit diesem Port und speichert die Ergebnisse in einer Datei. |
Ein in Golang geschriebenes SSH-Wurmmodul. Führt payload aus. |
|
Das Hauptmodul nach dem Eindringen. Basierend auf den Ressourcen, die dem Opfer zur Verfügung stehen, installiert es entweder eine Backdoor, einen Cryptominer oder einen LAN-SSH-Wurm. |
|
.diicot |
Ein kompiliertes Bash-Skript. Lädt den Cryptominer Opera herunter. Außerdem wird eine weitere Backdoor in Form eines neuen Nutzers und SSH-Schlüssels installiert. |
Opera |
Ein XMRig-Cryptominer. |
Ein kompiliertes Bash-Skript. Startet das LAN-Spreader-Modul. Führt einen SSH-Port-Scanner im internen LAN-IP-Bereich aus und ruft dann Network auf, um zu versuchen, in Maschinen mit SSH einzudringen. |
|
Network |
Eine weitere Variante von aliases mit weniger Funktionen. Führt einen SSH-Wörterbuchangriff auf das lokale LAN durch und speichert Informationen zu gehackten Maschinen (samt der funktionierenden Anmeldedaten) in einer Textdatei. |
Abb. 2: Eine Zusammenfassung der verschiedenen Payloads, die von den Angreifern genutzt werden
Generierung und Verschleierung der Binärdateien
Die bedeutendste Veränderung, die wir ermittelt haben, ist die Verschleierung der Payload. Bisher waren die meisten ausführbaren Payloads Bash-Skripte, die mit shc kompiliert wurden. Doch jetzt waren auch diese kompilierten Bash-Skripte mit UPX gepackt und der UPX-Header wurde entfernt, um die Analyse und das Entpacken zu behindern (Abbildung 3).
Abb. 3: Eine gepackte ausführbare Datei kann aufgrund eines entfernten Headers nicht von UPX entpackt werden.
Glücklicherweise konnten wir uns auf ein Tool verlassen, das Akamai-Forscher Larry Cashdollar im Rahmen eines vorherigen SIRT-Alarms entwickelt hatte. Dadurch konnten wir den UPX-Header einfach wiederherstellen, die ausführbaren ELF-Dateien entpacken und die Bash-Skripte darin extrahieren.
Damit bleibt uns eine vollständig isolierte, statisch kompilierte Binärdatei, ohne die Möglichkeit, zwischen dem Malware-Code und dem glibc-Code zu unterscheiden (Abbildung 4).
Abb. 4: Einstiegspunkt der reduzierten Binärdatei
Wir können den glibc-Quellcode nutzen, um zu verstehen, wie der Einstiegspunkt aussieht. Die eigentliche Hauptfunktion ist die Funktion, die in rdi geladen wird. Wenn wir uns das genauer ansehen, finden wir eine ziemlich spezifische Fehlerzeichenfolge: E: Weder argv[0] noch $_ funktioniert.Nach dieser Zeichenfolge können wir im Internet suchen. Das führt uns zu shc. Leider gibt es keinen einfach verfügbaren Decompiler. Statt Reverse Engineering und der Erstellung eines Decryptors, was zu mühsam wäre, können wir die Payload debuggen und die Ausführung nach einer Sekunde anhalten. Das entschlüsselte Shell-Skript wird sich im Arbeitsspeicher der Malware befinden, den wir dann ausgeben und analysieren können.
Infektionskette
Abb. 5: Die gesamte Payloadkette
Die einzelnen Payloads sind relativ einfach miteinander verbunden – mit verschiedenen Methoden zur Einrichtung des nächsten Glieds in der Kette, zum Beispiel das Beenden von Konkurrenz-Minern oder CPU-intensiven Prozessen, die Bereinigung des Bash-Verlaufs, die Installation von Persistenz und das Herunterladen und Ausführen der nächsten Payload (Abbildung 5).
Technische Analyse der wichtigsten Payloads
aliases
Dies ist eine Golang-Binärdatei, die nicht entfernt wurde, sodass wir die gesamte Logik der Malware leicht finden konnten. Die Malware liest zwei Dateien, die in den vorherigen Schritten erstellt wurden: protocols (Nutzer-Passwort-Wortliste, die von Updategespeichert wird) und bios.txt (Ziel-IP-Liste der Maschinen mit offenem SSH, die von Chrome erstellt wird). Anschließend wird ein Wörterbuchangriff auf jedes Ziel durchgeführt und nach erfolgreicher Authentifizierung werden payload und andere Befehle ausgeführt, um ein Profil des angegriffenen Systems zu erstellen.
Der letzte auszuführende Befehl ist uname -s -v -n -r -m – seine Ausgabe wird geparst. Dieser Befehl sucht nach bestimmten Betriebssystemnamen, die auf interessante Ziele hindeuten können. Bei den meisten Betriebssystemnamen, nach denen gesucht wird, bleibt der Befehl inaktiv. Wenn jedoch auf dem Zielcomputer OpenWrt ausgeführt wird, führt der Befehl einen weiteren Bash-Befehl aus, um ein weiteres Shell-Skript von 107.182.129.219 herunterzuladen und auszuführen, das wiederum eine Mirai-Variante installiert. Wir denken, dass der Fokus auf OpenWrt liegt, weil es auf Embedded-Geräten installiert ist und als erster Zugangsvektor zu Unternehmensnetzwerken dienen könnte. Damit zeigen die Angreifer, dass sie an mehr als nur einer weiteren Cryptomining-Kampagne interessiert sind und aktiv nach neuen Möglichkeiten suchen.
Nachdem die Malware ihren Angriff beendet hat, informiert sie Angreifer über einen Discord-Webhook (eine Angriffspraxis, die immer beliebter wird). Es gibt vier verschiedene Webhooks für unterschiedliche Zwecke (Abbildung 6).
Abb. 6: Abgefangene Discord-Webhooks, die von der Malware aufgerufen werden
Der erste Webhook stammt aus einer Funktion namens toDiscord. Er entfernt die Ergebnisse der verschiedenen Profiling-Befehle, die auf dem Zielrechner ausgeführt wurden. Die nächsten beiden Webhooks werden über die Funktionen toAPIlogs und toDisc aufgerufen. Sie entfernen beide die gleichen Informationen: die IP des Ziels sowie den Nutzer und das Passwort, mit denen die Authentifizierung bei diesem Ziel möglich ist.
Schließlich – wenn das Opfer OpenWrt ausführt – wird eine weitere Funktion namens toMirai aufgerufen. Sie sendet die gleichen Informationen an einen weiteren Webhook. Es besteht also eine gewisse Redundanz. Möglicherweise ist der Grund hierfür, dass Angreifer so einfacher verschiedene Metriken verfolgen können. Die Redundanz könnte jedoch auch zur Trennung verschiedener Teile der Angriffskampagne dienen (Mirai als Botnet/IAB im Gegensatz zur normalen Verwendung von Mirai als Cryptominer).
payload
Obwohl es sich um ein kompiliertes Bash-Skript handelt, ist payload interessant, da es mit Kommentaren und Fortschrittsmeldungen durchzogen ist, die uns etwas über die Denkprozesse der Malware-Betreiber lehren können.
Die Kommentare und Fortschrittsmeldungen sind in rumänischer Sprache – das unterstützt die Vermutung, dass die Angreifer aus Rumänien stammen (die Command-and-Control-/Download-Domain der Malware lässt sich buchstäblich mit „Archiv des Hackers“ übersetzen).
Das Skript prüft auch, ob andere bekannte Cryptominer vorhanden sind, und beendet deren Prozesse – darunter auch dhpcd und ksmdx. Das zeigt, dass sich die Angreifer ihres Ökosystems bewusst sind und nicht einfach nur ihr Glück in der Cryptomining-Welt versuchen.
Nachdem Konkurrenten und andere CPU-intensive Prozesse beendet wurden, prüft das Skript, wie viele CPU-Kerne der Computer hat – sind es weniger als vier, installiert das Skript nur History und Update sowie einen Cron-Job für die beiden. (Die beiden ausführbaren Dateien sind für das Herunterladen der Payload aliases verantwortlich und werden nach einem Neustart des betroffenen Computers ausgeführt.) Wenn vier oder mehr Kerne vorhanden sind, lädt das Skript auch .diicot herunter und installiert es. Hierbei handelt es sich um ein kompiliertes Bash-Skript, das einen XMRig-Cryptominer herunterlädt und ausführt.
Wenn acht oder mehr CPU-Kerne vorhanden sind, lädt das Skript auch den LAN-Spreader retea herunter und führt ihn aus.
retea
Das LAN-Spreader-Modul stellt eine neue Fähigkeit in der Kette der Angreifer dar. Es handelt sich um ein weiteres kompiliertes Shell-Skript, das alle im System konfigurierten Nutzer extrahiert und eine Datei namensusrs erstellt. Die Datei wird für einen SSH-Wörterbuchangriff verwendet und wird mit den extrahierten Nutzern und einer hartcodierten Liste mit Standardpasswörtern gefüllt. Anschließend wird ein Netzwerkscanner im LAN-Netzwerk heruntergeladen und ausgeführt, der Maschinen mit offenen SSH-Ports erkennt und die Ausgabe in eine Datei schreibt. Als Nächstes lädt die Datei Network herunter und führt es aus. Hierbei handelt es sich um eine kleinere Version von aliases, die weniger Funktionen bietet. Anstatt eine schädliche Payload zu installieren oder Berichte an einen Discord Webhook zu erstellen, werden die Ausgaben der betroffenen Computer in einer Datei gespeichert, die später von den Angreifern aufgespürt werden kann.
Das sind die Opfer
Oder doch nicht?
Da die Angreifer eine Wurm-Payload verwenden, lässt sich nur schwer unterscheiden, welche Quell-IPs, die in unseren Bedrohungssensoren erkannt wurden, zur Infrastruktur der Angreifer gehören – und bei welchen es sich um Opfer handelt. In diesem Abschnitt versuchen wir, die Infrastruktur der Angreifer zu analysieren und die tatsächlichen Opfer zu ermitteln.
Wir haben alle angegriffenen IP-Adressen (50 eindeutige IPs) abgerufen und sie ihrem weltweiten geografischen Standort zugeordnet. Zusätzlich zu den angreifenden IPs fanden wir bei einigen Kunden von Akamai auch Anzeichen für eine Infektion, sodass auch sie in unsere Opferliste aufgenommen wurden. Die geografische Verteilung der Opfer/Infrastruktur ist in Abbildung 7 dargestellt.
Abb. 7: Weltkarte mit Standort der angreifenden IPs
Zwar zeigen die meisten Standorte nur wenig Aktivität, doch es gibt einige Hotspots in Westeuropa. Der Anstieg der Aktivität (Abbildung 8) führt uns zu der Hypothese, dass die Hotspots eigentlich von Angreifern kontrollierte Maschinen sind, während es sich bei den anderen Vorkommen um Opfermaschinen handelt, die vom Wurmmodul übernommen wurden. Es scheint, dass das Wurmmodul nicht besonders aktiv ist, da wir nur sehr wenige Maschinen gleichzeitig sehen. Das ergibt Sinn, da aliases nur einmal pro Cron-Jobausführung ausgeführt wird, in einer zufälligen B‑Klasse. Die Cron-Ausführung ist für Neustarts des Computers geplant, was aufgrund der Art der betroffenen Computer (meist Linux-Server, die mit dem Internet verbunden sind) wahrscheinlich nur selten geschieht.
Abb. 8: Anzahl der IPs, die unsere Bedrohungssensoren gleichzeitig angreifen
Wenn wir uns die IP-Adressen ansehen, die am häufigsten in unseren Honeypots registriert wurden (und von denen wir annehmen, dass sie zur Infrastruktur der Angreifer gehören), können wir eine klare Verteilung der Hosts erkennen (Abbildung 9). Ältere IP-Adressen wurden mit DigitalOcean gehostet. Neuere Adressen (im Rahmen des jüngsten Wiederauflebens) scheinen in Serverion gehostet worden zu sein, einem VPS- und Webhosting-Anbieter aus den Niederlanden (dessen ASN unter seiner Muttergesellschaft, der Immobilienagentur Des Capital B.V. registriert ist, was uns zunächst verwirrt hat).
Angriffsdatum |
Anzahl der Angriffe |
Angreifer-IP |
Name der Hosting-Organisation |
|---|---|---|---|
1. Februar 2023 |
14 |
185.225.74.231 |
Des Capital B.V. |
1. Oktober 2022 |
72 |
45.139.105.222 |
Des Capital B.V. |
1. Oktober 2022 |
62 |
212.193.30.11 |
Des Capital B.V. |
1. März 2022 |
22 |
195.133.40.157 |
Des Capital B.V. |
1. Dezember 2021 |
43 |
134.209.95.47 |
DigitalOcean, LLC (DO-13) |
1. Dezember 2021 |
37 |
134.209.195.231 |
DigitalOcean, LLC (DO-13) |
1. Dezember 2021 |
34 |
104.248.85.104 |
DigitalOcean, LLC (DO-13) |
1. Dezember 2021 |
27 |
134.209.198.229 |
DigitalOcean, LLC (DO-13) |
1. Dezember 2021 |
27 |
167.71.48.128 |
DigitalOcean, LLC (DO-13) |
1. Dezember 2021 |
74 |
188.166.60.8 |
DigitalOcean, LLC |
Abb. 9: IP-Adressen, von denen wir annehmen, dass sie nicht nur zu Opfern, sondern auch zur Infrastruktur der Angreifer gehören
Vor der Veröffentlichung dieses Blogbeitrags haben wir uns mit den betroffenen Akamai-Kunden in Verbindung gesetzt und Informationen zu den Angriffen sowie zu den ausgenutzten E-Mails erhalten, die für jede angreifende IP-Adresse registriert wurden.
So kommen Angreifer an ihr Geld
Es scheint, dass die Angreifer ihre Mining-Konfiguration seit der letzten Kampagne geändert haben. In der Vergangenheit wiesen sie ihre Miner an, direkt mit supportxmr.com zu arbeiten. Doch die Miner wurden kürzlich analysiert, was ergab, dass sie mit IP-Adressen kommunizieren, die sich wahrscheinlich unter der Kontrolle der Angreifer befinden. Wir hatten befürchtet, dass es sich hierbei um private Pools handelt. Denn das würde bedeuten, dass wir die Zahlungen nicht verfolgen können. Doch unsere Befürchtungen waren unbegründet: supportxmr trackte weiterhin die Mining-Zahlungen ans Wallet. Deshalb gehen wir davon aus, dass Angreiferserver nur Proxys zu dem Pool sind, der von supportxmr gehostet wird. Hierdurch können Angreifer möglicherweise die DNS-Blockierung und -Erkennung umgehen, indem nicht direkt auf den Pool zugegriffen wird.
Wir konnten zwei verschiedene Adressen aus den XMRig-Payloads extrahieren, die wir bei der Untersuchung der Kampagne gefunden haben. Diese Adressen unterscheiden sich von denen, die Bitdefender damals gefunden hatte. Doch laut Zahlungsverlauf scheinen sie auch während dieser Zeit aktiv gewesen zu sein.
Wir können sehen, dass die Zahlungsbeträge vor November 2021 stark variierten (und sogar zweimal einen ganzen XMR erreichten), jedoch danach viel häufiger und beständiger wurden (Abbildung 10). Das kann auf eine Änderung des Auszahlungsschemas oder auf das Hinzufügen weiterer Miner zurückzuführen sein. Der Zeitpunkt entspricht anderen Spitzen bei Malware-Aktivitäten, die wir entdeckt haben.
Abb. 10: Der Mining-Zahlungsverlauf zum Wallet der Angreifer, wie aus supportxmr extrahiert
Alles in allem haben die Angreifer es geschafft, während ihrer gesamten Kampagne XMR im Wert von über 10.000 US-Dollar zu minen – über 75 % davon seit dem Wiederaufleben. Der tatsächlich geminte Betrag ist wahrscheinlich sogar noch höher als unsere Schätzung – gemessen an der von supportxmr gemeldeten Zahl eindeutiger Worker haben wir nur die Hälfte der XMRig-Payloads und -Konfigurationen gesehen (Abbildung 11).
Abb. 11: Miner, die mit einem Wallet der Angreifer in Verbindung stehen
Zusammenfassung
Die Payloadkette, die von den Angreifern eingesetzt wird, ist sicherlich beeindruckend und lässt auf einen ziemlich raffinierten Bedrohungsakteur schließen. Außerdem sehen wir in der Regel keine Payloadketten dieser Länge – wir glauben, dass es mehrere Gründe gibt, warum die Angreifer sich für so viele Payloads entschieden haben.
Verschleierung: Je mehr Komponenten ein System aufweist, desto schwieriger ist es, es zu analysieren und nachzuverfolgen. Die Tatsache, dass die Binärdateien verschleiert sind, verstärkt diese Hypothese.
Hinter der Bedrohungsgruppe stecken mehrere Personen: Obwohl uns keine tatsächlichen Informationen über die Bedrohungsakteure hinter der Kampagne vorliegen, haben wir auffällige Codeunterschiede zwischen verschiedenen Mustern der gleichen Skripte gefunden, die wir nur darauf zurückführen können, dass sie von verschiedenen Personen entwickelt wurden.
Die Malware-Kampagne entwickelt sich im Laufe der Zeit weiter: Das zeigt sich an den neuen Funktionen und der stärkeren Verschleierung, die hinzugefügt wurden, sowie an einigen Redundanzen im Code, die als Grundlage für die zukünftige Verwendung erstellt wurden.
Verbesserungen und Ergänzungen der vorherigen Kampagne
Packen per UPX und Entfernen des UPX-Headers
Automatische Updatefunktion wurde aus der Payload in externe Skripte verschoben (History und Update)
Unauffälligere Dateinamen, die Browser nachahmen (Chrome, Opera )
Zusätzliche Malware-Berichte über Discord
OpenWRT-spezifisches Verhalten (und wahrscheinlich kommt noch mehr)
Einsatz nutzerdefinierter Mining-Pool-Proxys anstelle öffentlicher Pools
Archiv für Verteidiger
Schutz Ihres Netzwerks
Die Malware verfügt über keine neuartige oder ausgeklügelte Technik, um sich selbst zu verbreiten. Sie verwendet einfach einen SSH-Wörterbuchangriff. Daher sind nur Maschinen gefährdet, die über das Internet zugängliche, offene SSH-Ports aufweisen. Das Blockieren von SSH am Netzwerkrand oder das Verschieben hinter ein VPN kann die Risiken solcher Angriffe erheblich verringern.
Darüber hinaus wird durch die Verwendung nicht standardmäßiger Anmeldedaten oder komplizierter Passwörter das Risiko eines Wörterbuchangriffs – wie er von dieser Malware ausgeführt wird – erheblich verringert. Wir empfehlen auch die Verwendung von SSH-Schlüsseln für die Authentifizierung, da diese noch sicherer sind als Passwörter (sie sind unmöglich zu erraten und geheime Schlüssel werden niemals über die Verbindung übertragen).
Zu guter Letzt müssen wir auch das LAN-Spreader-Modul berücksichtigen. Da es SSH für laterale Netzwerkbewegungen verwendet, kann eine Segmentierung Ihres Netzwerks das Risiko sicher mindern. Wenn wir Server, die über das Internet zugänglich sind, als DMZ betrachten, ist es logisch, SSH-Traffic (und im Allgemeinen auch anderen Traffic, der für laterale Netzwerkbewegungen verwendet werden kann, wie RDP, MS-RPC oder WinRM) von der DMZ zum Rest des Netzwerks zu verhindern. Wenn Sie aus irgendeinem Grund einen dieser Server benötigen, um SSH-Zugriff auf das interne Netzwerk zu erhalten (weil er beispielsweise als Jumpbox dient), sollten Sie ihn außerhalb der DMZ und hinter ein VPN verschieben. Achten Sie nur darauf, dass Server nicht über das Internet zugänglich sind, und ermöglichen Sie Angreifern, intern von ihnen zu springen – so reduzieren Sie den Auswirkungsradius und die Ausbreitungspfade.
Erkennung von Infektionen
Wir haben ein GitHub-Repository für Tools erstellt, die Ihnen bei der Erkennung von Infektionen durch diese schädliche Kampagne helfen können. Dort finden Sie ein Bash-Skript, eine vollständige Liste der IoCs und osquery-Abfragen, die Kunden mit Akamai Guardicore Segmentation verwenden können. Sie finden außerdem am Ende dieses Beitrags das Erkennungsskript und eine unvollständige Liste der IoCs .
Zusätzlich zu diesen Tools möchten wir auch eine allgemeine Methode zur Erkennung von Cryptominern empfehlen, die in diesem Fall angewendet werden kann: die Erkennung ausgehenden Traffics zu Mining-Pools durch Untersuchung des Zielports. Die Standardports für Mining-Pools sind manchmal ziemlich eindeutig, weshalb es sich empfiehlt, nach ihnen Ausschau zu halten. Beispiel:
TCP-Port 4242 ist der Standard-Port für diese Pool-Implementierung.
TCP-Ports 3333, 5555, 7777, 9000 sind die Standardports in der nodejs-Pool-Implementierung.
Natürlich können Miner auch über HTTP und HTTPS mit ihrem Pool kommunizieren. In diesem Fall wäre die Erkennung viel schwieriger. Trotzdem lohnt es sich, nach diesen Ports Ausschau zu halten.
Erkennungsskript
Das Erkennungsskript sucht nach verschiedenen IoCs, die auf vergangene oder aktuelle Präsenz der Angriffskampagne hinweisen können. Es sucht in Crontab nach Artefakten, nach Dateipfaden und ausgeführten Prozessen sowie nach der SSH-Schlüssel-Backdoor. Um es zu verwenden, laden Sie es einfach auf den Computer herunter, den Sie prüfen möchten, und führen Sie es aus. Daraufhin scannt es die Maschine und gibt das Ergebnis aus:
Abbildung 12: Das Erkennungsskript wird ausgeführt, um nach Mexals-Artefakten zu suchen.
Indicators of Compromise
Die folgende Liste enthält nur einen Teil der IoCs. Die vollständige Liste wird in unserem GitHub-Repository bereitgestellt.
Pfade
/var/tmp/.update-logs/
/var/tmp/Documents/
/var/tmp/.ladyg0g0/
/dev/shm/.x/
/dev/shm/.magic/
Dateinamen
protocols
bios.txt
Update
History
aliases
payload
retea
.usrs
IPs
107.182.129.219
45.139.105.222
185.225.74.231
212.193.30.11
Domains und URIs
arhivehaceru[.]com
discord[.]com/api/webhooks/954295081765072926/Zu7Vu-LpfgRqSmCyFvz3BCkR1Lt7clYOJeayCFzZwtPmZlVn9og_6mPS_BJY-374m5Y3
discord[.]com/api/webhooks/1036206037373571082/9bs01KrT-TrcbSAPI_i-adV1Bhn56A4X4fxzCYEw3zMq95H1mFvlKWb6-KYzvEoVfTnS
Discord[.]com/API/Webhooks/1036205058456563722/1_saZM0fE7nLgYG668LmDfNmSvrWpD-6Z8nIXljm0qlm6YyMxAyYuZIu4LhN2gHsgSQy
Discord[.]com/API/Webhooks/965651135102865479/PFdU4u8yZrn0XhzIKShcaxL3_IaBjsstYmFEXlThF2_1XCnwXSAjKos3ptwKYpPyGqvI
Discord[.]com/API/Webhooks/848592916951203860/WeWBGYSVreTlE0aO_6alVN3Qrj6_aRxnaDpq4_6wD04V2aHlMFvgik2Z2h78Dstg9fZY
discord[.]com/api/webhooks/1036225255049531422/qyOrT3SxHaOC-9yS2NQiPxlSMYmRFFIpU-rMKzmcDv9pQyP4uaZEiZXDXioUtf0DJLUB
