Stealth Falcon fällt mit Deadglyph über den Nahen Osten her

Seit Jahren hat der Nahe Osten den Ruf, ein fruchtbarer Boden für Advanced Persistent Threats (APTs) zu sein. Bei der routinemäßigen Überwachung verdächtiger Aktivitäten auf den Systemen hochrangiger Kunden, von denen einige in dieser Region ansässig sind, ist ESET Research auf eine sehr ausgeklügelte und unbekannte Backdoor gestoßen, die wir Deadglyph genannt haben. Wir haben den Namen von Artefakten abgeleitet, die in der Backdoor gefunden wurden (wie z. B. 0xDEADB001, die auch in Tabelle 1 zu sehen sind ), in Verbindung mit dem Vorhandensein eines Homoglyph-Angriffs. Soweit wir wissen, ist dies die erste öffentliche Analyse dieser bisher nicht dokumentierten Backdoor, die von einer Gruppe verwendet wird, die ein beachtliches Maß an Raffinesse und Fachwissen aufweist. Aufgrund der gezielten Angriffe und zusätzlicher Beweise schreiben wir Deadglyph mit hoher Wahrscheinlichkeit der APT-Gruppe Stealth Falcon zu.

Die Architektur von Deadglyph ist ungewöhnlich, da sie aus kooperierenden Komponenten besteht. Eine davon ist eine native x64-Binärdatei, die andere eine .NET-Assembly. Diese Kombination ist ungewöhnlich, da Malware normalerweise nur eine Programmiersprache für ihre Komponenten verwendet. Dieser Unterschied könnte auf eine getrennte Entwicklung dieser beiden Komponenten hindeuten, wobei auch die einzigartigen Merkmale der verschiedenen Programmiersprachen, die sie verwenden, genutzt werden. Unterschiedliche Sprachen können auch dazu genutzt werden, die Analyse zu erschweren, da gemischter Code schwieriger zu navigieren und zu debuggen ist.

Die traditionellen Backdoor-Befehle sind nicht in der Backdoor-Binärdatei implementiert, sondern werden in Form von zusätzlichen Modulen dynamisch vom Command and Control (C&C)-Server empfangen. Diese Backdoor verfügt außerdem über eine Reihe von Fähigkeiten, um nicht entdeckt zu werden.

In diesem Blogpost werfen wir einen genaueren Blick auf Deadglyph und bieten eine technische Analyse dieser Backdoor, ihren Zweck und einige der zusätzlichen Komponenten, die wir erhalten haben. Wir werden unsere Erkenntnisse über Deadglyph auch auf der Konferenz LABScon 2023 vorstellen.

Die wichtigsten Punkte des Blogposts:

• ESET Research hat eine ausgeklügelte Backdoor mit ungewöhnlicher Architektur entdeckt, die wir Deadglyph genannt haben.
• Die Hauptkomponenten sind mit einem maschinenspezifischen Schlüssel verschlüsselt.
• Traditionelle Backdoor-Befehle werden über zusätzliche Module implementiert, die von ihrem C&C-Server empfangen werden.
• Wir haben drei von vielen Modulen erhalten - Process Creator, File Reader und Info Collector.
• Wir ordnen Deadglyph der Stealth Falcon-Gruppe zu.
• Außerdem fanden wir einen verwandten Shellcode-Downloader; wir vermuten, dass er möglicherweise für die Installation von Deadglyph verwendet wird.

Das Opfer der analysierten Infiltration ist eine Regierungsbehörde im Nahen Osten, die zu Spionagezwecken kompromittiert wurde. Ein ähnliches Sample, das auf VirusTotal gefunden wurde, wurde ebenfalls aus dieser Region, genauer gesagt aus Katar, auf die Dateisuchplattform hochgeladen. Die Zielregion ist auf der Karte in Abbildung 1 dargestellt.

Stealth Falcon (auch bekannt als Project Raven oder FruityArmor) ist laut MITRE eine Bedrohungsgruppe mit Verbindungen zu den Vereinigten Arabischen Emiraten. Stealth Falcon ist seit 2012 aktiv und dafür bekannt, dass sie politische Aktivisten, Journalisten und Dissidenten im Nahen Osten ins Visier nimmt. Sie wurde erstmals von Citizen Lab entdeckt und beschrieben, das 2016 eine Analyse einer Kampagne von Spyware-Angriffen veröffentlichte.

Im Januar 2019 veröffentlichte Reuters einen Untersuchungsbericht über Project Raven, eine Initiative, die angeblich ehemalige NSA-Mitarbeiter beschäftigt und auf die gleichen Arten von Zielen wie Stealth Falcon abzielt. Auf der Grundlage dieser beiden Berichte, die sich auf dieselben Ziele und Angriffe beziehen, ist Amnesty International zu dem Schluss gekommen (siehe Abbildung 2), dass es sich bei Stealth Falcon und Project Raven tatsächlich um dieselbe Gruppe handelt.

Im September 2019 veröffentlichten wir Untersuchungen zu einer Backdoor, die Stealth Falcon zugeschrieben wird und eine ungewöhnliche Technik, den Background Intelligent Transfer Service, für die C&C-Kommunikation verwendet. Jetzt enthüllen wir das Ergebnis unserer eingehenden Analyse dessen, was vermutlich die neueste Ergänzung zum Spionage-Toolset von Stealth Falcon ist.

Deadglyph-Backdoor

Die Ladekette von Deadglyph besteht aus mehreren Komponenten, wie in Abbildung 3 dargestellt. Die erste Komponente ist ein Shellcode-Loader, der Shellcode aus der Registry lädt. Dieser extrahierte Shellcode lädt wiederum den nativen x64-Teil der Backdoor - den Executor. Der Executor lädt anschließend den .NET-Teil der Backdoor - den Orchestrator. Die einzige Komponente, die sich als Datei auf der Festplatte des Systems befindet, ist die ursprüngliche Komponente in Form einer Dynamic Link Library (DLL). Die übrigen Komponenten sind verschlüsselt und in einem binären Registrierungswert gespeichert.

Obwohl die genaue Methode des anfänglichen Kompromittierungsvektors noch nicht bekannt ist, vermuten wir, dass eine Installationskomponente an der Bereitstellung weiterer Komponenten und der Einrichtung der Persistenz im System beteiligt ist.

Im weiteren Verlauf dieses Abschnitts werden die einzelnen Komponenten analysiert.

Shellcode-Loader für die Registry

Die erste Komponente von Deadglyph ist eine winzige DLL mit einem einzigen Export namens 1. Diese Komponente wird mithilfe der Windows Management Instrumentation (WMI) als Ereignisabonnement persistiert und dient als Shellcode-Loader für die Registry. Sie wird über die Befehlszeile rundll32 C:\WINDOWS\System32\pbrtl.dll,#1 ausgeführt .

Der Registry-Shellcode-Loader beginnt seine Arbeit mit der Entschlüsselung des Pfads zum verschlüsselten Shellcode, der in der Windows-Registrierung gespeichert ist, unter Verwendung von RC4. Wir vermuten, dass der Pfad für jedes Opfer einzigartig ist. In dem hier analysierten Fall war der Registrierungspfad:

Software\Classes\CLSID\{5abc7f42-1112-5099-b082-ce8d65ba0c47}\cAbRGHLg

Der Root-Registrierungsschlüssel ist entweder HKLM oder HKCU, je nachdem, ob der aktuelle Prozess mit erhöhten Rechten ausgeführt wird oder nicht. Die gleiche Logik findet sich auch in weiteren Komponenten wieder.

Anschließend leitet der Loader einen maschinenspezifischen RC4-Schlüssel aus der System-UUID ab, die er aus der SMBIOS-Firmware-Rohtabelle abruft. Mit diesem Schlüssel wird der Shellcode geladen, entschlüsselt und dann ausgeführt. Es ist wichtig zu betonen, dass dieser Ansatz der Schlüsselableitung sicherstellt, dass eine ordnungsgemäße Entschlüsselung nicht erfolgt, wenn der Loader auf einem anderen Computer ausgeführt wird.

Interessanterweise kann der Loader durch ein Flag in seinem .data-Abschnitt auch so konfiguriert werden, dass er einen fest kodierten Schlüssel zur Entschlüsselung des Shellcodes anstelle des maschinenspezifischen Schlüssels verwendet.

Wir haben in der VERSIONINFO-Ressource dieser und anderer PE-Komponenteneinen Homoglyph-Angriff entdeckt, der die Microsoft Corporation imitiert. Bei dieser Methode werden bestimmte Unicode-Zeichen verwendet, die den Originalzeichen optisch ähneln, aber in diesem Fall nicht mit ihnen identisch sind, insbesondere der griechische Großbuchstabe San (U+03FA, Ϻ) und der kyrillische Kleinbuchstabe O (U+043E, о).

Shellcode für die Registry

Der Registry-Shellcode besteht aus zwei Teilen, einer Entschlüsselungsroutine und einem verschlüsselten Body. Zunächst dreht die Entschlüsselungsroutine jedes Byte des verschlüsselten Bodys um eins nach links (ROL 0x01). Anschließend wird die Kontrolle auf diesen entschlüsselten Body übertragen. Der entschlüsselte Body besteht aus einem PE-Loader und einer PE-Datei, wobei letztere der Executor ist, der den nativen Teil der Backdoor darstellt. Dieser Loader ist für das Parsen und Laden der zugehörigen PE-Datei verantwortlich.

Executor

Der Executor ist der native x64-Teil der Deadglyph-Backdoor, der Folgendes tut:

• er lädt seine Konfiguration,
• initialisiert die .NET-Laufzeitumgebung,
• lädt den eingebetteten .NET-Teil der Backdoor (den Orchestrator), und
• fungiert als Bibliothek für den Orchestrator.

Zunächst werden zwei in den .data-Abschnitt eingebettete Standardkonfigurationen mit AES entschlüsselt. Die Konfigurationen umfassen verschiedene Parameter, darunter Verschlüsselungsschlüssel, Sicherheits- und Umgehungseinstellungen sowie den Einstiegspunkt der nachfolgenden Komponente.

Bei der ersten Ausführung werden diese beiden Standardkonfigurationen in der Windows-Registrierung gespeichert, von wo aus sie bei späteren Durchläufen geladen werden, was die Implementierung von Aktualisierungen ermöglicht. Der Registrierungspfad für jede Konfiguration wird in folgendem Format erstellt:

{HKCU|HKLM}\Software\Classes\CLSID\{<variable_GUID>}\(Default)

<variable_GUID> ist eine generierte GUID, die für jedes Opfer eindeutig ist.

Anschließend wird die .NET-Laufzeitumgebung initialisiert, und der Executor entschlüsselt den .NET-Teil der als Orchestrator bekannten Backdoor mit RC4. Der Orchestrator befindet sich in der.rsrc-Sektion des Executors. In der Konfiguration wird die Ausführungsmethode des Orchestrators als Einstiegspunkt angegeben. Außerdem wird eine eigene Struktur bereitgestellt, um den Zugriff auf die Funktionen des Executors durch den Orchestrator zu erleichtern.

Nach dem Start des Orchestrators fungiert der Executor als Support-Bibliothek für den Orchestrator. Der Executor enthält viele interessante Funktionen, von denen wir einige im folgenden Abschnitt im Zusammenhang mit ihrer Nutzung durch den Orchestrator und weitere geladene Module beschreiben.

Orchestrator

Der in .NET geschriebene Orchestrator ist die Hauptkomponente der Deadglyph-Backdoor. Die Hauptaufgabe dieser Komponente besteht darin, die Kommunikation mit dem C&C-Server herzustellen und Befehle auszuführen, was häufig durch die Vermittlerrolle des Executors erleichtert wird. Im Gegensatz zu den vorangegangenen Komponenten ist der Orchestrator verschleiert und verwendet .NET Reactor. Intern wird die Backdoor als Agent bezeichnet, was in verschiedenen Post-Exploitation-Frameworks ein gängiger Name für den Client-Teil ist.

Initialisierung

Der Orchestrator lädt zunächst seine Konfiguration und zwei eingebettete Module, die jeweils von einem eigenen Satz von Konfigurationen begleitet werden, aus Ressourcen. Diese Ressourcen sind Deflate-komprimiert und AES-verschlüsselt. Sie werden durch eine ID referenziert, die mit SHA-1 in einen Ressourcennamen gehasht ist. Eine Übersicht über diese Ressourcen finden Sie in Tabelle 1 .

Tabelle 1. Orchestrator-Ressourcen

Die Konfiguration des Orchestrators und der eingebetteten Module wird im XML-Format gespeichert. Ein Beispiel für eine Orchestrator-Konfiguration finden Sie in Abbildung 4.

Die Beschreibung der Orchestrator-Konfigurationseinträge ist in Tabelle 2 zufinden .

Tabelle 2. Orchestrator-Konfigurationseinträge

Nachdem die Ressourcenkomponenten geladen sind, werden mehrere Threads erstellt, die unterschiedliche Aufgaben ausführen. Einer dieser Threads ist für die Durchführung von Umgebungsprüfungen zuständig, eine Funktion, die im Executor implementiert ist. Ein weiterer Thread ist für die regelmäßige Kommunikation mit dem C&C-Server zuständig, um Befehle abrufen zu können. Ein Satz von drei Threads schließlich dient der Ausführung der empfangenen Befehle und der anschließenden Übermittlung der erzeugten Ausgaben an den C&C-Server.

Der Thread zur Umgebungsüberprüfung überwacht laufende Prozesse, um unerwünschte Prozesse zu identifizieren. Dieser Thread arbeitet mit zwei verschiedenen Listen von Prozessnamen. Wenn ein Prozess auf der ersten Liste entdeckt wird, werden die Kommunikation mit dem C&C-Server und die Ausführung von Befehlen angehalten, bis der unerwünschte Prozess nicht mehr existiert. Wenn ein Prozess auf der zweiten Liste übereinstimmt, wird die Backdoor sofort beendet und deinstalliert sich selbst.

Keine der beiden Listen war in der analysierten Instanz konfiguriert, so dass wir nicht wissen, nach welchen Prozessen typischerweise gesucht wird. Wir glauben, dass dies wahrscheinlich dazu dient, Analysetools zu umgehen, die verdächtige Aktivitäten erkennen und zur Entdeckung der Backdoor führen könnten.

Kommunikation

Der Orchestrator verwendet zwei eingebettete Module für die C&C-Kommunikation - Timer und Network. Wie der Orchestrator sind auch diese Module mit .NET Reactor verschleiert. Die Konfiguration für beide Module wird vom Orchestrator bereitgestellt. Im Orchestrator ist eine voreingestellte Konfiguration für die Module enthalten; optional kann der Orchestrator auch eine aktualisierte Konfigurationsversion aus der Registry laden:

{HKCU|HKLM}\Software\Classes\CLSID\{<variable_GUID>}\<mod_cfg_res_ID>

Die Hintertür enthält eine interessante Sicherheitsmaßnahme im Zusammenhang mit der Kommunikation. Wenn die Backdoor nicht in der Lage ist, die Kommunikation mit dem C&C-Server für eine gewisse Dauer herzustellen, die einen vordefinierten Schwellenwert überschreitet, der im Executor konfiguriert wird, wird ein Mechanismus zur Selbst-Deinstallation ausgelöst. Dieser Zeitschwellenwert wird in Stunden angegeben und wurde im untersuchten Fall auf eine Stunde festgelegt.

Dieser Ansatz dient einem doppelten Zweck. Zum einen wird verhindert, dass redundante Netzwerkanfragen an einen nicht erreichbaren Server gestellt werden. Zum anderen verringert es die Wahrscheinlichkeit einer späteren Entdeckung, wenn die Betreiber die Kontrolle über die Backdoor verlieren.

Timer-Modul

Dieses kleine Modul führt den angegebenen Callback in einem konfigurierbaren Intervall aus. Es wird vom Orchestrator in Kombination mit dem Network-Modul verwendet, um in regelmäßigen Abständen mit dem C&C-Server zu kommunizieren. Um zu verhindern, dass erkennbare Muster in den Netzwerkprotokollen entstehen, wird das Ausführungsintervall nach dem Zufallsprinzip anhand eines in der Konfiguration festgelegten Prozentsatzes bestimmt. Im untersuchten Fall wurde das Intervall auf fünf Minuten festgelegt, wobei eine Schwankung von ±20 % für die Zufälligkeit eingeführt wurde.

Eine weitere Methode zur Vermeidung von erkennbaren Netzwerkmustern in der periodischen Kommunikation findet sich in der Generierung der an den C&C-Server gesendeten Anfragen. Dieser Mechanismus, der im Executor implementiert ist, beinhaltet die Einfügung von Auffüllungen unterschiedlicher Länge, die aus zufälligen Bytes bestehen, in die Anfragen, was zu Anfragen unterschiedlicher Größe führt.

Network-Modul

Das Network-Modul implementiert die Kommunikation mit den in seiner Konfiguration angegebenen C&C-Servern. Es kann Daten über HTTP(S)-POST-Anfragen an einen C&C-Server senden. Insbesondere bietet es mehrere Mechanismen, um Details zur Proxy-Konfiguration zu erhalten. Diese Funktion deutet darauf hin, dass er sich möglicherweise auf Umgebungen konzentriert, in denen kein direkter Internetzugang verfügbar ist.

Ein Beispiel für eine entschlüsselte (und verschönerte) Konfiguration ist in Abbildung 5 zu sehen.

Die Konfigurationseinträge enthalten Details zur Netzwerkkommunikation - C&C-URLs, HTTP User-Agent und optional eine Proxy-Konfiguration.

Bei der Kommunikation mit dem C&C-Server wird ein benutzerdefiniertes Binärprotokoll mit verschlüsseltem Inhalt unterhalb von HTTPS verwendet.

Befehle

Der Orchestrator empfängt Befehle vom C&C-Server in Form von Aufgaben, die zur Ausführung in eine Warteschlange gestellt werden. Es gibt drei Arten von Aufgaben, die verarbeitet werden:

• Orchestrator-Aufgaben,
• Executor-Aufgaben und
• Upload-Aufgaben.

Die ersten beiden Arten werden vom C&C-Server empfangen und die dritte wird intern erstellt, um die Ausgabe von Befehlen und Fehlern hochzuladen.

Orchestrator-Aufgaben

Orchestrator-Aufgaben bieten die Möglichkeit, die Konfiguration der Network- und Timer-Module zu verwalten und ausstehende Aufgaben abzubrechen. Eine Übersicht über die Orchestrator-Aufgaben finden Sie in Tabelle 3.

Tabelle 3. Orchestrator-Aufgaben

Executor-Aufgaben

Executor-Tasks bieten die Möglichkeit, die Backdoor zu verwalten und zusätzliche Module auszuführen. Es ist bemerkenswert, dass die traditionellen Backdoor-Funktionen nicht in der Binärdatei selbst enthalten sind. Stattdessen werden diese Funktionen vom C&C-Server in Form von PE-Dateien oder Shellcode bezogen. Das volle Ausmaß des Potenzials der Backdoor bleibt ohne diese zusätzlichen Module, die die wahren Fähigkeiten der Backdoor freischalten, unbekannt. Einen Überblick über die Aufgaben der Module gibt Tabelle 4, in der auch Einzelheiten zu den wenigen identifizierten Modulen aufgeführt sind. In ähnlicher Weise bietet Tabelle 5 einen Überblick über die Verwaltungsaufgaben im Zusammenhang mit dem Executor.

Tabelle 4. Executor-Aufgaben - Module

Tabelle 5. Executor-Aufgaben - Verwaltung

Der Befehl, der die Executor-Konfiguration festlegt, kann folgendes verändern:

• Liste unerwünschter Prozesse,
• Zeitschwelle für den Ausfall der C&C-Kommunikation und
• das Zeitlimit für die Ausführung von zusätzlichen Modulen.

Module

Es ist uns gelungen, drei einzigartige Module vom C&C-Server zu erhalten, die jeweils einem anderen Executor-Aufgabentyp entsprechen, wie in Tabelle 4 zusehen ist. Anhand der verfügbaren Informationen schätzen wir, dass es insgesamt neun bis vierzehn Module gibt. Da es sich bei den Modulen in Wirklichkeit um Backdoor-Befehle handelt, müssen sie nur eine grundlegende Operation ausführen und dann optional ihre Ausgabe zurückgeben. Die Module, die wir erhalten haben, sind DLLs mit einem unbenannten Export (Ordnungszahl 1), in dem sie notwendige API-Funktionen auflösen und die Hauptfunktion aufrufen.

Bei der Ausführung werden die Module mit einer API-Auflösungsfunktion versehen, die Windows-APIs und benutzerdefinierte Executor-APIs auflösen kann. Die Windows-APIs werden durch einen DWORD-Hash referenziert, der aus dem Namen der API und ihrer DLL berechnet wird. Kleine Hash-Werte (<41) werden speziell behandelt und verweisen auf die Executor-API-Funktion. Die Executor-API umfasst insgesamt 39 Funktionen, die den Modulen zugänglich sind. Diese Funktionen beziehen sich auf eine Vielzahl von Operationen, darunter:

• Dateioperationen,
• Verschlüsselung und Hashing,
• Komprimierung,
• PE-Laden,
• Zugangstoken-Impersonation und
• Dienstprogramm.

Im weiteren Verlauf dieses Abschnitts beschreiben wir die erhaltenen Module.

Prozess-Erzeuger

Modul 0x69 führt die angegebene Befehlszeile als neuen Prozess aus und gibt die resultierende Ausgabe an den Orchestrator zurück. Der Prozess kann unter einem anderen Benutzer erstellt werden, und seine Ausführungszeit kann begrenzt werden. Für die Funktionalität dieses Moduls wird eine ungewöhnliche Job-API verwendet.

Dieses Modul wurde mit der Befehlszeile cmd.exe /c tasklist /v bedient .

Wir gehen davon aus, dass es als Leerlaufbefehl dient, der automatisch ausgeführt wird, während die Anwender darauf warten, dass auf dem kompromittierten Computer etwas Interessantes passiert.

Info-Kollektor

Modul 0x6C sammelt über WMI-Abfragen umfangreiche Informationen über den Computer und gibt sie an den Orchestrator zurück. Es werden Informationen zu folgenden Punkten gesammelt:

• Betriebssystem,
• Netzwerkadapter,
• Installierte Software,
• Laufwerke,
• Dienste,
• Treiber,
• Prozesse,
• Benutzer,
• Umgebungsvariablen und
• Sicherheitssoftware.

Datei-Leser

Modul 0x64 liest die angegebene Datei und gibt den Inhalt an den Orchestrator zurück. Optional kann es die Datei nach dem Lesen löschen.

Wir haben gesehen, wie dieses Modul verwendet wurde, um die Outlook-Datendatei des Opfers abzurufen

c:\Users\<redacted>\AppData\Local\Microsoft\Outlook\outlook.ost.

Kette mit Shellcode-Downloader

Bei der Untersuchung von Deadglyph stießen wir auf eine dubiose CPL-Datei, die mit einem abgelaufenen Zertifikat und ohne Gegensignatur mit Zeitstempel signiert war und von Katar aus auf VirusTotal hochgeladen worden war. Bei näherer Betrachtung stellte sich heraus, dass diese CPL-Datei als mehrstufiger Shellcode-Downloader fungierte und gewisse Code-Ähnlichkeiten mit Deadglyph aufwies. Die Ladekette ist in Abbildung 6dargestellt .

In ihrer ursprünglichen Form, die als erste Stufe dient, hat diese Datei eine .cpl-Erweiterung (Systemsteuerungsdatei) und soll durch einen Doppelklick ausgeführt werden. Bei dieser Ausführung wird der eingebettete Shellcode einer XOR-Entschlüsselung unterzogen, und die laufenden Prozesse werden überprüft, um einen geeigneten Host-Prozess für die anschließende Injektion zu finden.

Wenn avp.exe (ein Kaspersky-Prozess) ausgeführt wird, wird %windir%\system32\UserAccountBroker.exe verwendet. Andernfalls wird der Standardbrowser verwendet. Dann wird der Host-Prozess in einen angehaltenen Zustand versetzt, der Shellcode durch Hijacking des Haupt-Threads injiziert und der Thread wieder aufgenommen.

Die zweite Phase, der Shellcode, besteht aus zwei Teilen. Der erste Teil des Shellcodes löst API-Hashes auf, wobei er dieselbe einzigartige Hash-Berechnungstechnik wie Deadglyph verwendet, und entschlüsselt Zeichenketten mit Prozessnamen. Er startet einen Selbstlösch-Thread, der die Aufgabe hat, die Datei der ersten Stufe zu überschreiben und anschließend zu löschen. Anschließend untersucht der Shellcode die derzeit aktiven Prozesse und zielt auf die jeweilige Sicherheitslösung ab.

Wenn einer der angegebenen Prozesse gefunden wird, erstellt der Shellcode einen Schläfer-Thread mit der niedrigsten Priorität (THREAD_PRIORITY_IDLE) und lässt ihn 60 Sekunden lang aktiv bleiben, bevor er seine Tätigkeit beendet. Dieses Intervall ist wahrscheinlich als Vorsichtsmaßnahme implementiert, um bestimmte Erkennungsmechanismen zu umgehen, die von Sicherheitslösungen eingesetzt werden. Schließlich ruft der Shellcode den zweiten Teil seines Codes auf.

Der zweite Teil des Shellcodes lädt eine eingebettete PE-Datei mit der dritten Stufe und ruft ihren Export mit der Ordnungszahl 1 auf.

Die dritte Stufe, eine DLL, dient als .NET-Lader und enthält die Payload in ihrem .rsrc-Abschnitt.

Um die Payload zu laden, wird die .NET-Laufzeit initialisiert. Während der .NET-Initialisierung werden zwei verblüffende Techniken ausgeführt, die offenbar dazu dienen, das Windows Antimalware Scan Interface (AMSI) zu umgehen:

• Der .NET-Lader hookt vorübergehend den GetModuleHandleW-Import in der geladenen clr.dll, während er ICorRuntimeHost::Start aufruft . Der Hook verfälscht den Rückgabewert, wenn GetModuleHandleW mit NULL aufgerufen wird. Er gibt einen Zeiger auf ein Dummy-PE ohne Abschnitte zurück.
• Anschließend wird die Zeichenfolge für den Importnamen AmsiInitialize im Abschnitt .rdata der geladenen clr.dll auf subtile Weise auf amsiinitialize geändert.

Die vierte Stufe ist eine .NET-Assembly, die mit ConfuserEx verschleiert wird und als Shellcode-Downloader dient. Zunächst wird die Konfiguration im XML-Format durch XOR-Decodierung aus den Ressourcen entschlüsselt. Eine verschönerte Version der extrahierten Konfiguration ist in Abbildung 7 dargestellt . Die Konfigurationseinträge enthalten Details zur Netzwerkkommunikation und zu den in der Blockliste aufgeführten Prozessen.

Bevor der Shellcode-Downloader fortfährt, überprüft er die laufenden Prozesse anhand einer Liste der in der Konfiguration aufgeführten blockierten Prozesse. Wenn eine Übereinstimmung festgestellt wird, wird die Ausführung angehalten. Es ist wichtig, darauf hinzuweisen, dass im analysierten Fall diese Blockliste nicht eingerichtet war.

Als Nächstes wird eine HTTP-GET-Anfrage an den C&C-Server gesendet, um einen Shellcode abzurufen, wobei die in der Konfiguration angegebenen Parameter (URL, User-Agent und optional Proxy) verwendet werden. Bedauerlicherweise konnten wir während unserer Untersuchung keinen Shellcode vom C&C-Server abrufen. Wir gehen jedoch davon aus, dass die abgerufenen Inhalte möglicherweise als Installationsprogramm für Deadglyph dienen könnten.

Anschließend wird der abgerufene Shellcode in einem neu erstellten Thread ausgeführt. Nachdem er gewartet hat, bis der Shellcode-Thread die Ausführung beendet hat, löscht der Shellcode-Downloader alle Dateien im Verzeichnis %WINDIR%\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV.

Schließlich versucht er, sich nach einem Intervall von 20 Sekunden selbst zu löschen, indem er den folgenden Befehl verwendet, bevor er seine Operation abschließt und sich beendet:

cmd.exe choice /C Y /N /D Y /T 20 & Del /f /q <current_process_exe_path>

Diese Selbstlöschung ist in dieser Kette nicht sinnvoll. Das liegt daran, dass der Shellcode-Downloader nach dem Einschleusen innerhalb eines Browsers oder Systemprozesses ausgeführt wird und nicht als eigenständige ausführbare Datei fungiert. Außerdem wurde die ursprüngliche Datei bereits in der zweiten Phase gelöscht. Diese Beobachtung deutet darauf hin, dass der Shellcode-Downloader möglicherweise nicht ausschließlich als PAyload dieser Kette dient, sondern auch separat für andere Vorgänge verwendet wird.

Schlussfolgerung

Wir haben eine hochentwickelte Backdoor entdeckt und analysiert, die von der Stealth Falcon-Gruppe verwendet wird und die wir Deadglyph genannt haben. Sie hat eine ungewöhnliche Architektur, und ihre Backdoor-Fähigkeiten werden von ihrem C&C in Form von zusätzlichen Modulen bereitgestellt. Es ist uns gelungen, drei dieser Module zu beschaffen, wodurch wir einen Bruchteil der vollen Fähigkeiten von Deadglyph aufdecken konnten.

Deadglyph verfügt über eine Reihe von Mechanismen zur Abwehr von Angriffen, darunter die kontinuierliche Überwachung von Systemprozessen und die Implementierung von zufälligen Netzwerkmustern. Außerdem ist die Backdoor in der Lage, sich selbst zu deinstallieren, um die Wahrscheinlichkeit ihrer Entdeckung in bestimmten Fällen zu minimieren.

Darüber hinaus haben wir bei unserer Untersuchung eine überzeugende mehrstufige Shellcode-Downloader-Kette auf VirusTotal entdeckt. Wir vermuten, dass diese Downloader-Kette wahrscheinlich bei der Installation von Deadglyph eingesetzt wird.

Wenn Sie Fragen zu unserer auf WeLiveSecurity veröffentlichten Forschung haben, kontaktieren Sie uns bitte unter threatintel@eset.com.
ESET Research bietet private APT Intelligence Reports und Datenfeeds an. Wenn Sie Fragen zu diesem Service haben, besuchen Sie die ESET Threat Intelligence Seite.

IoCs

Dateien

Zertifikate

C&C-Server

MITRE ATT&CK-Techniken

Diese Tabelle wurde mit der Version 13 des MITRE ATT&CK Frameworks erstellt.