„Operation Endgame“: ESET beteiligt sich an der Abschaltung von Amadey und Stealc

Vor einem Jahr war ESET Research an zwei groß angelegten Operationen beteiligt, durch die einige der damals führenden cyberkriminellen Netzwerke – Lumma Stealer und Danabot – zerschlagen wurden. In jüngster Zeit arbeiten unsere Forscher erneut mit privaten Partnern und Strafverfolgungsbehörden zusammen, diesmal jedoch mit dem Ziel, das Amadey-Botnetz und den Stealc-Infostealer zu bekämpfen, die beide über Malware-as-a-Service-Angebote (MaaS) bereitgestellt werden. Die Operation „Endgame“ – koordiniert von der Microsoft Digital Crimes Unit (DCU), BitSight, Lumen, Mitsui Bussan Secure Directions (MBSD) und weiteren Partnern – richtete sich gegen die gesamte bekannte Netzwerkinfrastruktur, die von Amadey- und Stealc-Akteuren genutzt wurde, um deren kriminelle Aktivitäten lahmzulegen.

ESET trug zu diesen Bemühungen bei, indem es technische Analysen, statistische Informationen, bekannte Command-and-Control-Server (C&C), Verschlüsselungsschlüssel, Kampagnen- und Build-Identifikatoren sowie weitere Bedrohungsinformationen bereitstellte, die im Rahmen unserer langfristigen Beobachtung beider Malware-Familien gesammelt wurden.

Kernpunkte dieses Blogbeitrags:

• ESET beteiligte sich an der koordinierten, weltweiten „Operation Endgame“, um Amadey und Stealc zu zerschlagen.
• Die „Operation Endgame“ betraf rund 50 Domains und fast 200 aktive IP-basierte C&C-Server, die mit Amadey und Stealc in Verbindung standen.
• ESET stellte technische Analysen, statistische Informationen, bekannte C&C-Server, Verschlüsselungsschlüssel, Kampagnen-Identifikatoren und weitere Erkenntnisse zur Verfügung.
• Wir geben einen Überblick über das MaaS-Ökosystem auf Affiliate-Ebene für beide Malware-Familien.
• Wir beschreiben, wie wir die Aktivitäten von Amadey und Stealc in Cluster unterteilt haben.
• Wir fassen die für die Nachverfolgung und Störung relevantesten technischen Eigenschaften zusammen, darunter C&C-Kommunikation, eingebettete Identifikatoren und Verschlüsselungsschlüssel.
• Wir gehen detailliert auf Überschneidungen zwischen den Aktivitäten von Amadey und den Affiliates von Lumma Stealer ein.

Beitrag zur Bekämpfung

ESET Research verfolgt seit drei Jahren sowohl das Amadey-Botnetz als auch den Stealc-Infostealer. Für diese Bekämpfungsmaßnahme haben wir Statistiken für den Zeitraum vom 4. Quartal 2025 bis zum 1. Halbjahr 2026 sowie technische Indikatoren und Konfigurationsdaten bereitgestellt, die aus analysierten Malware-Proben extrahiert wurden.

Unsere automatisierten Systeme haben Amadey- und Stealc-Proben analysiert und die für eine groß angelegte Nachverfolgung relevantesten Felder identifiziert. Dazu gehören C&C-Server, Build-Identifikatoren, Verschlüsselungsschlüssel, URL-Pfade, Kampagnen-Identifikatoren und andere eingebettete Werte, die von den Malware-Familien bei der Kommunikation mit der von Angreifern kontrollierten Infrastruktur verwendet werden.

Ein Schwerpunkt unserer Arbeit lag auf der Suche nach zuverlässigen Methoden, um die große Menge an verarbeiteten Proben zu bewältigen und zu clustern. Dies war besonders nützlich, da sowohl Amadey als auch Stealc als Dienste verkauft werden. Daher werden die Malware-Proben von Partnern vertrieben, die oft ihre eigene Infrastruktur betreiben, ihre eigenen Builds generieren oder anfordern und ihre eigenen Kampagnen orchestrieren. Die Identifizierung von Aktivitätsclustern in solchen Ökosystemen ermöglicht es uns, Ziele mit hoher Priorität für Störmaßnahmen wie diese zu erkennen.

Der Austausch von technischen Analysen, statistischen Informationen und Bedrohungsdaten – wie C&C-Serverlisten, Identifikatoren von Partnern und Verschlüsselungsschlüsseln – ermöglicht es Strafverfolgungsbehörden, Infrastrukturen mit hoher Sicherheit zu identifizieren, zu priorisieren und gegen sie vorzugehen. IoCs helfen zudem dabei, zwischen einzelnen Clustern, gemeinsam genutzter Infrastruktur und Botnetzen mit großer Reichweite zu unterscheiden, deren Störung wahrscheinlich die größten Auswirkungen auf die gesamte Bedrohungslandschaft hat. Letztendlich betraf die Störung rund 50 Domains und fast 200 aktive IP-Adressen, die entweder für Amadey oder Stealc als C&C-Server genutzt wurden.

Zerstörte Malware-Familien

Amadey ist ein modularer Malware-Loader. Sein Hauptzweck besteht darin, zusätzliche Malware auf kompromittierte Systeme zu verteilen, obwohl er auch Module für Datenexfiltration und Fernzugriff bietet.

Stealc hingegen ist ein typischer „Infostealer as a Service“. Er zielt auf Anmeldedaten, Cookies, Kryptowährungs-Wallets, Browser-Erweiterungen und Dateien ab, deren Namen den von den Partnern definierten Mustern entsprechen.

Beide Malware-Familien werden als Dienste verkauft und in Darknet-Foren beworben. Um Einblick in Darknet-Foren zu erhalten, nutzten wir Flare.io, eine Threat-Intelligence-Plattform, die Untergrund-Communities überwacht. In beiden Ökosystemen erhalten Partner ein selbst gehostetes Administrationspanel, das auf ihrer eigenen Serverinfrastruktur bereitgestellt werden muss. Dies erfordert ein gewisses Maß an technischem Know-how seitens der Partner und gibt ihnen zudem direkte Kontrolle über die Daten der Opfer sowie die Verteilung der Payloads.

Dieses Modell unterscheidet sich von anderen MaaS-Ökosystemen. So können beispielsweise Danabot- Partner C&C-Infrastruktur als Dienstleistung mieten, während Lumma Stealer ein Exfiltrationsnetzwerk nutzte, das vollständig von seinen Betreibern verwaltet wurde. Im Fall von Amadey und Stealc sind die Partner für die Bereitstellung und den Betrieb ihrer eigenen Infrastruktur verantwortlich, was Maßnahmen zur Störung erschwert – weshalb der Clustering-Ansatz unerlässlich war.

Zwar hängen die Verbreitungsmethoden letztendlich von jedem einzelnen Partner ab, doch die Telemetriedaten von ESET zeigten durchweg, dass beide Malware-Familien über eine Vielzahl von Kanälen verbreitet wurden. Zu den gängigsten Methoden gehörten gefälschte Software-Updates, Installationsprogramme für geknackte Software und Malware-Loader von Drittanbietern.

Amadey nutzte ein Pay-per-Rebuild-Modell. Partner erwarben eine Lizenz und zahlten anschließend jedes Mal eine zusätzliche Gebühr, wenn sie einen neuen Build generieren mussten, beispielsweise bei der Umstellung auf einen neuen C&C-Server. Mit anderen Worten: Die Amadey-Betreiber stellten den Partnern kein Builder-Tool zur Verfügung; stattdessen wurden die Samples auf Anfrage für jeden Partner kompiliert.

Stealc verfolgte einen partnerfreundlicheren Ansatz und bot im Rahmen seines Abonnements die unbegrenzte Erstellung von Builds an (Abbildung 1). Dies senkte die Betriebskosten für die Rotation der C&C-Infrastruktur und erleichterte es den Partnern, bei Bedarf neue Samples zu generieren.

Um Identitätsbetrug zu vermeiden, wiesen die Betreiber beider Dienste potenzielle Partner in Darknet-Foren ausdrücklich an, sich ausschließlich über offizielle Kanäle an sie zu wenden. Amadey verwies Käufer auf private Nachrichten im Darknet-Forum, in dem für den Dienst geworben wurde, während Stealc private Nachrichten in Darknet-Foren oder über Telegram nutzte.

Amadey

Amadey ist ein modularer Malware-Loader, der seit Oktober 2018 unter dem Accountnamen „InCrease“ in Darknet-Foren beworben wird. Im Laufe der Zeit hat er sich zu einer der stabileren und aktiv gepflegten Malware-Familien entwickelt, für die über Darknet-Forenkanäle fortlaufender Support bereitgestellt wird.

Unsere in Abbildung 2 dargestellte Telemetrie-Erkennungsrate zeigt, dass Amadey weltweit ohne spezifischen regionalen Schwerpunkt beobachtet wurde, wobei die höchsten Erkennungsraten in Indien, der Türkei, Ägypten, Mexiko und Spanien verzeichnet wurden.

Die Hauptfunktion von Amadey besteht darin, zusätzliche Malware an die Opfer zu verbreiten. Darüber hinaus bietet es drei Module für die weitere Datenexfiltration und den Zugriff: Überwachung der Zwischenablage, Diebstahl von Anmeldedaten und VNC-basierter Fernzugriff.

Der Preis für den Dienst beträgt 600 US-Dollar pro Einzellizenz, zahlbar in Bitcoin, wobei pro Neuerstellung zusätzlich 50 US-Dollar berechnet werden. Das bedeutet, dass den Partnern jedes Mal Kosten entstehen, wenn sie eine neue Version erstellen, beispielsweise bei der Umstellung auf einen neuen C&C-Server. Diese Preisgestaltung ist seit den frühesten beworbenen Versionen weitgehend unverändert geblieben, was auf einen stabilen und etablierten Kundenstamm hindeutet.

Im Laufe der Jahre haben wir fortlaufende Versionsaktualisierungen (Abbildung 3) und eine aktive Weiterentwicklung von Amadey beobachtet. Der bedeutendste Meilenstein in der Entwicklung von Amadey erfolgte im August 2020 (v1.99.5), als die gesamte Codebasis komplett neu geschrieben wurde. Die zweite große Weiterentwicklung erfolgte mit der Veröffentlichung von v5.03 im Oktober 2024, die eine Vielzahl neuer Funktionen mit sich brachte: hVNC mit Reverse-Connect, Unterstützung für den MSI-Silent-Installer, RDP-Aktivierung, Ausführung von cmd.exe mit SYSTEM-Rechten sowie integrierte Unterstützung für verschlüsselte Payloads. Insgesamt dienten die meisten der anderen, eher geringfügigen Updates einem impliziten, aber beständigen Zweck: der Umgehung von Antiviren-Erkennungen, sobald diese auftraten.

Technischer Überblick

Jedes Amadey-Sample enthält mindestens eine fest codierte C&C-Server-URL, wobei die Konfiguration bis zu drei Einträge unterstützt. Die Samples enthalten zudem einen RC4-Schlüssel, der zur Verschlüsselung der Kommunikation mit dem C&C-Server verwendet wird.

Unsere Analyse ergab, dass der aus jedem Sample extrahierte RC4-Schlüssel als zuverlässiger Cluster-Identifikator dient, wodurch wir Samples in einzelne Botnetze gruppieren können, worauf wir im Abschnitt„Clustering“ näher eingehen.

Ein zweiter fest codierter Wert, intern als „sd“ bezeichnet, ist eine zufällig anmutende sechsstellige Hexadezimalzeichenfolge, die dem Muster [0-9a-f]{6} entspricht. Er wird während des anfänglichen C&C-Handshakes übertragen und identifiziert höchstwahrscheinlich einen bestimmten Build innerhalb der Bereitstellung eines Partners. Obwohl er von Forschern manchmal als Kampagnen-ID oder Amadey-ID bezeichnet wird, lässt das Pay-per-Build-Geschäftsmodell von Amadey vermuten, dass es sich dabei eher um eine Build-Kennung handelt.

Jedes Sample enthält zudem eine Versionsnummer. Unsere Analyse konzentriert sich auf die Version v5.x, die seit Anfang 2025 die dominierende Variante in der ESET-Telemetrie ist.

Dieser Bot überprüft zudem das Tastaturlayout des Opfers. Stimmt es mit einem Layout überein, das einem GUS-Land zugeordnet ist, wird die gesamte Netzwerkkommunikation stillschweigend abgelehnt. Bedrohungsakteure, die von Osteuropa aus operieren, nutzen häufig diese Art von integrierter Sicherheitsvorkehrung, um Unternehmen und staatliche Einrichtungen in der Region nicht zu beeinträchtigen und so das Risiko zu verringern, von lokalen Behörden ins Visier genommen oder strafrechtlich verfolgt zu werden. Darüber hinaus befolgen diese Betreiber oft solche Vorgehensweisen, um mögliche Gegenreaktionen ihrer Kollegen zu vermeiden, weil sie „ihre eigenen Leute“ ins Visier nehmen oder gegen die Regeln von Darknet-Foren verstoßen, in denen ihre Dienste beworben werden.

Dieser Abschnitt bietet lediglich einen allgemeinen Überblick über Amadey, da eine eingehende technische Analyse bereits im Swisscom-Bericht veröffentlicht wurde.

C&C-Kommunikation

Amadey kommuniziert mit seinem C&C-Server über HTTP mithilfe von POST-Anfragen. Im Großen und Ganzen folgt die Kommunikation einem dreistufigen Lebenszyklus:

• Erstes Signal – Der Bot sendet eine minimale HTTP-POST-Anfrage mit dem Parameter „st=s“ an den C&C-Server. Der Server antwortet mit einem Warteintervall, zum Beispiel <c>10<d>, und weist den Bot an, zwischen aufeinanderfolgenden Check-ins 10 Minuten zu warten.
• Registrierung – Der Bot übermittelt RC4-verschlüsselte Systeminformationen, die als flache Schlüssel-Wert-Zeichenkette kodiert sind. Diese Daten umfassen die Betriebssystemversion, den Benutzernamen, den PC-Namen, das installierte Antivirenprodukt, Administratorrechte, den „sd“-Wert sowie weitere Host-Informationen. Bemerkenswert ist, dass der RC4-Schlüssel selbst niemals über das Netzwerk übertragen wird. Basierend auf unseren Telemetriedaten wurde kein Server beobachtet, der Aufgaben für mehr als einen RC4-Schlüssel gleichzeitig bereitstellte, was darauf hindeutet, dass jede Instanz mit einem C&C-Server kommunizieren muss, der genau diesen RC4-Schlüssel bereits kennt und erwartet. Der Server antwortet mit einer Aufgabenliste.
• Auftragsvergabe – Aufgaben werden als strukturierte Befehlszeichenfolgen übermittelt, die durch die Tags <c> und <d> begrenzt sind, wobei einzelne Befehle durch #-Zeichen getrennt sind, wie in Abbildung 4 dargestellt. Jede Aufgabe kodiert einen Befehlstyp, wie beispielsweise das Herunterladen und Ausführen einer EXE-Datei, das Starten von VNC oder das Ausführen eines Stealer-Plugins. Aufgaben enthalten zudem Parameter wie ein Flag zur Rechteausweitung, ein Zielverzeichnis und eine Payload-URL.

Jede Aufgabe verfügt über eine eigene Verarbeitungslogik, die von einfachen Befehlen zum Herunterladen und Ausführen bis hin zur komplexeren Ausführung von hVNC- oder Proxy-Komponenten reicht. Die inneren Abläufe wurden in früheren technischen Berichten dokumentiert.

Clusterbildung

Bei der Verfolgung von MaaS-Malware besteht eine zentrale Herausforderung darin, einen zuverlässigen Weg zu finden, um Samples zu gruppieren, die demselben Bedrohungsakteur zuzuordnen sind. Das Verständnis des Geschäftsmodells und der Verteilung der Netzwerkinfrastruktur ist daher für eine erfolgreiche Bekämpfung unerlässlich, da es Verteidigungsexperten und Strafverfolgungsbehörden ermöglicht, die kritischen Punkte zu identifizieren, an denen Maßnahmen die größte Wirkung erzielen. In diesem Abschnitt erläutern wir unsere Methodik.

Amadey-Proben enthalten drei wichtige fest codierte Konfigurationswerte:

• C&C-URLs,
• RC4-Schlüssel für die C&C-Kommunikation sowie
• den „sd “-Wert, der während des anfänglichen C&C-Handshakes übertragen wird.

Im Laufe unserer Nachverfolgung haben wir festgestellt, dass Amadey-C&C-URLs einem einheitlichen Muster folgen:

http(s)?://<C&C>/<random_path>/index.php

Zudem wurde derselbe URL-Teil <random_path> bei verschiedenen C&C-Servern verwendet (siehe Abbildung 5). Da es sich bei diesem Wert offenbar um eine zufällige Zeichenfolge handelt, schien die Tatsache, dass er im Laufe der Zeit mit mehreren C&C-Servern in Verbindung stand, ein starker Hinweis darauf zu sein, dass die C&C-Server als Teil desselben Clusters betrieben werden. Daher haben wir die C&C-URL weiter in diese beiden Teile zerlegt: die IP-Adresse oder Domain und den URL-Teil <random_path>.

Anhand von Werten aus der Konfiguration der Samples und in Verbindung mit unserem Verständnis ihres Zwecks nutzten wir Graphmodellierung, um Einblicke in die Struktur des Amadey-Ökosystems zu gewinnen. Auf den ersten Blick in Abbildung 6 wird deutlich, dass es tatsächlich keine gemeinsame Infrastruktur gibt, sondern vielmehr mehrere kleinere Sub-Botnetze, von denen eines eindeutig dominiert. Im nächsten Abschnitt gehen wir näher auf diesen größten Cluster ein.

Zusammenfassend lassen sich folgende wichtige Erkenntnisse festhalten:

1. Wir haben insgesamt 53 einzigartige Cluster innerhalb des Amadey-Ökosystems identifiziert.
2. Jeder sd -Wert ist genau einem RC4-Schlüssel zugeordnet.
3. RC4-Schlüssel sind wahrscheinlich ein nützlicher Identifikator für Affiliate-Server, da bei einer Neuerstellung der Schlüssel beibehalten wird, während der sd -Wert geändert wird.
4. Der Teil <random_path> der C&C-URL wird bei der Rotation von C&C-Servern gelegentlich wiederverwendet und dient als zuverlässiger Hinweis darauf, dass solche C&C-Server zum selben Cluster gehören.

Der größte Amadey-Botnetz-Cluster

Ein Cluster sticht als der größte hervor und trug fast 34 % aller verarbeiteten Amadey-Proben bei. Dieser Cluster war zudem der einzige, der während des gesamten analysierten Zeitraums aktiv war, wie in unserer Zeitleiste in Abbildung 7 dargestellt.

Das größte Botnetz dominierte auch hinsichtlich der durchschnittlichen Anzahl der pro Ausführung an die Opfer verteilten Payloads. Basierend auf unserer Clustering-Methodik lieferten Amadey-Proben, die zum größten Botnetz gehörten, im Durchschnitt etwa 14 Payloads gleichzeitig an jedes Opfer (Abbildung 8).

Die Bandbreite und Vielfalt der verbreiteten Malware-Familien war groß und reichte von Infostealern und RATs bis hin zu Malware mit komplexen Code-Schutzmechanismen. Abbildung 9 gibt einen Einblick in die Payloads, deren Verteilung wir während des gesamten Beobachtungszeitraums festgestellt haben.

Darüber hinaus konnten ESET-Forscher Belege dafür finden, dass oft mehrere Lumma-Stealer-Samples an ein einzelnes Opfer übermittelt wurden, wobei jedes einem anderen Partner zugeordnet war (siehe unsere frühere Untersuchung zu Lumma Stealer). Dies führt dazu, dass mehrere Lumma-Stealer-Partner letztendlich über dieselben gestohlenen Daten verfügen. Diese Beobachtung lässt uns zu dem Schluss kommen, dass die Angreifer, die diesen größten Cluster kontrollieren, wahrscheinlich ein eigenes Pay-per-Install-Modell (PPI) betrieben haben, um ihre Bots weiter zu monetarisieren.

Stealc

Im Gegensatz zu Amadey ist Stealc ein typischer Vertreter eines Infostealers. Er zielt auf eine breite Palette von Datenquellen ab, darunter Anmeldedaten, die von Webbrowsern, E-Mail-Clients, FTP-Clients, Spieleplattformen, Kryptowährungs-Wallet-Dateien und Browser-Erweiterungen gespeichert werden.

Stealc wurde im Februar 2023 in einem Darknet-Forum vorgestellt, und wir haben kurz darauf begonnen, es zu verfolgen. Unsere in Abbildung 10 dargestellte Telemetrie-Erkennungsrate zeigt, dass Stealc weltweit verbreitet war, ohne einen spezifischen regionalen Schwerpunkt. Die höchsten Erkennungsraten wurden in den Vereinigten Staaten, Polen und Italien beobachtet.

Stealc wird von einem Angreifer unter dem Pseudonym „plymouth“ beworben. Die Betreiber haben Stealc aktiv gepflegt; jedes Mal, wenn eine neue Version veröffentlicht wurde, haben sie die Versionshinweise in einem Beitrag in einem Darknet-Forum bekannt gegeben. In den vergangenen drei Jahren gab es 37 solcher Veröffentlichungen. Stealc wird als monatliches Abonnement verkauft, wobei sich die Preisgestaltung nur geringfügig verändert hat:

• 300 US-Dollar pro Monat
• 700 US-Dollar für drei Monate
• 1.000 US-Dollar für sechs Monate

Im März 2025 erhielt Stealc mit Version 2 ein umfangreiches Architektur-Update, das wesentliche Änderungen am Netzwerkprotokoll und an der Konfigurationsstruktur mit sich brachte – seitdem dominiert diese Version in unseren Telemetriedaten. Bis Juni 2026 hatte sie die Version 2.22.1 erreicht, wie in Abbildung 11 dargestellt.

Neben seinen Hauptzielen verfügt Stealc über einen konfigurierbaren Dateigrabber, mit dem Partner benutzerdefinierte Muster festlegen können, um Dateien zu bestimmen, die von kompromittierten Rechnern exfiltriert werden sollen. Seine C&C-Kommunikation und eingebetteten Zeichenfolgen sind durch RC4-Verschlüsselung mit build-spezifischen Schlüsseln geschützt.

Stealc stützt sich nicht auf eine einzige, standardisierte Verbreitungsmethode – jeder Partner ist für seine eigenen Verbreitungsmechanismen verantwortlich. Ähnlich wie bei Amadey deuten unsere Telemetriedaten jedoch darauf hin, dass bestimmte Vektoren immer wieder hervorstechen – insbesondere mit Trojanern versehene Software-Installer und etablierte Malware-Loader (wie Amadey).

Technischer Überblick

Eine detaillierte technische Analyse von Stealc v2 wurde bereits von Lumma-Labs veröffentlicht. In diesem Abschnitt konzentrieren wir uns auf die für das Clustering nutzbaren Eigenschaften.

Aktuelle Versionen von Stealc enthalten pro Sample zwei unterschiedliche RC4-Schlüssel:

• einen zur Entschlüsselung verschleierter Zeichenfolgen zur Laufzeit und
• einen zweiten zur Verschlüsselung der C&C-Netzwerkkommunikation.

Zusätzlich zu den beiden RC4-Schlüsseln haben wir die Build-Kennung aus den Stealc-Samples extrahiert. Dieser Wert steht für eine einzelne Stealc-Kampagne und ist im Gegensatz zu anderen Zeichenfolgen in der Binärdatei nicht geschützt. Der Wert ist wichtig, da er als Teil des C&C-Handshakes übertragen wird (siehe Abbildung 12).

Die für die Kommunikation verwendete C&C-Serveradresse und der URL-Pfad sind beide in den RC4-verschlüsselten Zeichenfolgen gespeichert und wurden im Rahmen unserer automatisierten Pipeline zum Entpacken der Konfigurationsdaten extrahiert.

C&C-Kommunikation

Stealc kommuniziert mit seinem C&C-Server über HTTP unter Verwendung von RC4-verschlüsselten JSON-Objekten. Die an den C&C-Server gesendete Erstanfrage enthält drei Werte:

• eine Build-Kennung (build),
• einen Fingerabdruck des kompromittierten Rechners (hwid) und
• den Anfragetyp (diese erste Anfrage ist vom Typ „create“).

Der Fingerabdruck des Rechners wird aus der Seriennummer des Systemvolumes abgeleitet und als UUIDv4-Zeichenkette formatiert. Ein Beispiel für ein JSON-Objekt dieser Erstanfrage ist in Abbildung 12 dargestellt.

Der C&C-Server antwortet mit einem komplexen JSON-Objekt, das definiert, welche Funktionen Stealc ausführen soll. Darüber hinaus enthält die Antwort einen zufällig generierten „access_token“-Wert, der als Sitzungsschlüssel dient und in allen nachfolgenden Anfragen verwendet werden muss; andernfalls werden diese vom Server abgelehnt. Neben den komplexen Definitionen der Ziele legt das JSON-Objekt auch fest, ob ein Screenshot erstellt, das Programm nach Abschluss der Aufgabe selbst zerstört oder anschließend eine zusätzliche Nutzlast heruntergeladen und ausgeführt werden soll. Ein Beispiel für ein JSON-Objekt als Antwort ist in Abbildung 13 dargestellt.

Jede Serverantwort enthält zudem ganz am Anfang ein zufällig generiertes Schlüssel-Wert-Paar – keine der beiden Hexadezimalzeichenfolgen wird jemals in nachfolgenden C&C-Kommunikationen wiederverwendet. Laut Untersuchungen von Zscaler verhindert dies statische Erkennungssignaturen bei RC4-verschlüsseltem Datenverkehr, selbst wenn derselbe Verschlüsselungsschlüssel wiederholt verwendet wird. In Abbildung 13 lautet der zufällig generierte Nonce „bf66e52“: „03030ac3e9a8cebf“.

Nach der Erstregistrierung nutzt Stealc drei weitere Operationstypen mit selbsterklärenden Namen, um seine Funktionen auszuführen:

• upload_file – gesammelte Daten exfiltrieren,
• loader – Abrufen und Ausführen einer Folge-Payload sowie
• done – Signalisierung des Abschlusses.

Clustering

Wie bereits erwähnt, stellen die Betreiber von Stealc ihren Partnern – anders als bei Lumma Stealer – keine gemeinsame Infrastruktur zur Verfügung. Ähnlich wie bei unserem Clustering-Ansatz für Amadey haben wir die aus den Stealc-Konfigurationen extrahierten Werte einer Graphmodellierung unterzogen und mit unserem Verständnis ihres Zwecks kombiniert, um die Struktur des Stealc-Ökosystems besser zu erfassen. Das Ergebnis war ein Graph, der zeigt, dass Stealc tatsächlich in viele kleine Cluster aufgesplittert ist (siehe Abbildung 14). Jeder Cluster konzentriert sich auf eine kleine Anzahl von C&C-Servern (oft nur einen) und ist in der Regel nur mit wenigen Build-IDs oder C&C-URL-Pfaden verknüpft. Die Störung einer solchen Infrastruktur ist daher aufgrund des Fehlens einer Schwachstelle eine schwierige Aufgabe. Insgesamt haben wir seit März 2025 insgesamt 73 verschiedene Cluster (siehe Abbildung 14) identifiziert, die Stealc betreiben.

Fazit

Für globale Störmaßnahmen wie die „Operation Endgame“ gegen Amadey und Stealc ist eine langfristige, automatisierte Verfolgung von Malware erforderlich. Dieser Blogbeitrag präsentiert auf diese Weise gesammelte Informationen, liefert aber auch Details zum spezifischen MaaS-Geschäftsmodell hinter jeder Malware-Familie und wie sich dies in einer oft fragmentierten Netzwerkinfrastruktur niederschlägt, dokumentiert deren wichtigste statische Identifikatoren und C&C-Kommunikationsprotokolle und skizziert, wie ESET-Forscher dazu beigetragen haben, kritische Punkte für die Störung zu identifizieren. Unsere Bedrohungsinformationen zu Amadey und Stealc bildeten in Kombination mit den von unseren Partnern bereitgestellten Daten eine solide Grundlage sowohl für die Störungsoperation als auch für die Strafverfolgungsmaßnahmen.

Die Operation „Endgame“ zielte darauf ab, alle bekannten Amadey- und Stealc-C&C-Server zu beschlagnahmen oder außer Betrieb zu setzen, wodurch die Infrastruktur, auf die sich die Partner beider MaaS-Angebote stützten, direkt gestört wurde. ESET wird beide Familien weiterhin überwachen und alle Versuche verfolgen, die operative Infrastruktur nach dieser Störung wieder aufzubauen.

IoCs

Eine umfassende Liste von Indikatoren für Kompromittierung (IoCs) sowie Beispieldateien finden Sie in unserem GitHub-Repository.

Dateien

Netzwerk

MITRE ATT&CK-Techniken

Diese Tabelle wurde unter Verwendung der Version 19 des MITRE ATT&CK-Frameworks erstellt.