Unterschrieben. Seitlich geladen. Kompromittiert!

Zusammenfassung

Während eines Vorfalls, der vom Cyber Defence Centre (CDC) von Ontinue beobachtet wurde, identifizierte das Team einen ausgeklügelten mehrstufigen Angriff, der die vishing, Werkzeuge für den Fernzugriff, und Techniken für das Leben auf dem Land um einen ersten Zugang zu erhalten und die Persistenz herzustellen.

Der Bedrohungsakteur nutzte ungeschützte Kommunikationskanäle aus, indem er eine bösartige PowerShell-Nutzlast über eine Microsoft Teams-Nachricht übermittelte, gefolgt von der Verwendung von Schnell-Hilfe um aus der Ferne auf die Umgebung zuzugreifen. Dies führte zum Einsatz von signierten Binärdateien (z. B., TeamViewer.exe), eine seitlich geladene bösartige DLL (TV.dll), und schließlich eine JavaScript-basierte C2-Hintertür über Node.js ausgeführt.

Diese Angriffskette zeigt, wie eine relativ einfache Vishing-basierte Social-Engineering-Taktik kann zu einem umfassenden Kompromiss eskalieren, wenn er mit bewährte Werkzeuge, signierte Binärdateien, und getarnte Nutzlasten der zweiten Stufe. Dieser Bericht dient zwar in erster Linie dazu, technische Erkenntnisse weiterzugeben, doch unterstreicht der Vorfall auch die reale Auswirkungen von Social-Engineering-Bedrohungen, insbesondere wenn Benutzerschulung Lücken bestehen.

Intelligente Bedrohung

Die in dieser Kampagne beobachteten Techniken stimmen stark mit denen überein, die zuvor Storm-1811 zugeschrieben wurden, einem von Microsoft identifizierten Bedrohungsakteur, der dafür bekannt ist, Vishing, Quick Assist und Social-Engineering-Taktiken einzusetzen, um sich Zugang zu verschaffen. Obwohl wir die Zuordnung nicht mit hoher Sicherheit bestätigen können, deuten mehrere TTP-Überschneidungen auf mögliche Ähnlichkeiten in der Vorgehensweise hin.

Dazu gehören:

• Missbrauch legitimer Fernsupport-Tools (z. B. Quick Assist)

• Erster Zugang über Microsoft Teams Social Engineering

• Bereitstellung von signierten Binärdateien für DLL-Sideloading

• Verwendung von "living-off-the-land"-Binärdateien (LOLBins) und BITS-Jobs für Stealth und Persistenz

Dieses Muster stimmt mit der öffentlichen Berichterstattung überein, einschließlich Microsofts Hinweis zum Missbrauch von Quick Assist und eine neuere Analyse von Sophos MDR, in der Ransomware-Kampagnen beschrieben werden, bei denen Teams Vishing und Remote Support ausnutzen (Sophos, Jan 2025).

MITRE-Techniken:

Die folgenden Techniken wurden nach der Kompromittierung ermittelt.

• T1105 - Ingress Tool Transfer | Angreifer überträgt Tools auf das Zielsystem

• T1656 - Impersonation | Der Angreifer gibt sich als IT-/Helpdesk-Mitarbeiter aus

• T1018 - Remote System Discovery | Verwendung von nltest und net user zur Aufzählung von Domänencontrollern.

• T1219 - Fernzugriffssoftware | Fernunterstützungstools (z. B. QuickAssist oder TeamViewer)

• T1218 - Signed Binary Proxy Execution | Missbraucht vertrauenswürdige, signierte Binärdateien

• T1197 - BITS Jobs | Wird für verdeckte Datenübertragungen oder Staging über Background Intelligent Transfer Service verwendet.

• T1555.003 - Anmeldeinformationen von Webbrowsern | Zugriff auf Browser-Passwortdateien (Anmeldedaten)

• T1021.002 - SMB/Windows Admin Shares | Verwendung von psexec.exe für seitliche Bewegung und Ausführung über SMB.

• T1570 - Lateraler Tooltransfer | Kopieren und Bereitstellen von Tools wie psexec.exe über mehrere Systeme hinweg.

• T1090 - C2 via Reverse Proxy | Nutzung von PsExec zum Exfiltrieren von Daten.

Beispiel-Infos

Erste Etappe

SHA256: 904280f20d697d876ab90a1b74c0f22a83b859e8b0519cb411fda26f1642f53e

Dateiname: TeamViewer.exe

SHA256: 782e997382734a4c80b6f2c6aef51a55c9434457f5ee125a3cf5938ec7a72f55

Dateiname: TV.dll

Zweite Stufe

Dateiname: Index.js

Beschreibung: C2-Backdoor über JavaScript

SHA256: 67199aaa4c7c9a7002958588b1bd1b81deecec871933f7c88d5838deb1c47e92

Analyse des Lebenszyklus von Angriffen

Erster Zugang

Bevor ich auf die Analyse der Proben und die von dem/den Bedrohungsakteur(en) durchgeführten Aktivitäten eingehe, ist es wichtig, die anfängliche Zugriffsphase der Angriffskette zu überdenken. Unsere Untersuchung ergab, dass der Akteur Social-Engineering-Taktiken einsetzte, um einen Vishing-Angriff durchzuführen. Dazu wurde über Microsoft Teams eine Nachricht an die Zielperson gesendet, indem ein externer Chat erstellt wurde. Der Täter übermittelte einen PowerShell-Befehl direkt über die Teams-Nachricht und nutzte außerdem das QuickAssist-Remote-Tool, um aus der Ferne Zugriff auf das Zielgerät zu erhalten.

Die Aktivitätsanalyse zeigt, dass der Bedrohungsakteur zu einem bestimmten Zeitpunkt während der Ausführung des PowerShell-Befehls wie erwartet QuickAssist verwendet hat. Dadurch konnten sie aus der Ferne auf das Zielgerät zugreifen, nachdem sie den Zielbenutzer erfolgreich gecheckt hatten, um die Bereitstellung der PowerShell zu gewährleisten, die kurz darauf erfolgte.

Ausführung

Bei der ersten Ausführung beobachtete ich, dass der Bedrohungsakteur einen PowerShell-Befehl vom Zielendpunkt aus ausführte, der den Download der Malware der ersten Stufe ermöglichte. Das Skript ruft eine ZIP-Datei von einer verdächtigen IP-Adresse ab, extrahiert deren Inhalt und führt anschließend eine Datei namens “TeamViewer.exe“ aus einem verborgenen Verzeichnis (C:\ProgrammDaten\TV). Außerdem verwendet es “AutoHotkey” als User-Agent, was auf eine mögliche Beteiligung von AutoHotkey-basierter Malware hindeutet. Dies deutet darauf hin, dass die heruntergeladene Nutzlast ein AutoHotkey-Skript (.ahk) oder eine kompilierte ausführbare AutoHotkey-Datei (.exe) enthalten könnte, die für die Durchführung weiterer bösartiger Aktivitäten vorgesehen ist.

Beim Ausführen von TeamViewer.exe lädt die Anwendung das Modul TV.dll, was ich als einen Fall von DLL (Dynamic-Link Library) Sideloading identifiziert habe. Dieses Modul stellt anschließend erneut eine Verbindung zu derselben IP-Adresse her, von der zuvor die Malware der ersten Stufe heruntergeladen wurde.

Persistenz

Anschließend erstellt die Malware einen Persistenzmechanismus, indem sie eine LNK-Datei im Start-Ordner erzeugt, die die Ausführung beim Neustart des Systems sicherstellt. Die erstellte Verknüpfungsdatei befindet sich unter:

C:\Benutzer\Benutzer\AppDaten\Roaming\Microsoft\Windows\Startmenü\Programme\Startup\GPU_Scv_Pack.lnk

C:\Benutzer\Benutzer\AppDaten\Roaming\Microsoft\Windows\Startmenü\Programme\Startup\GPU_Scv_Pack.lnk

C:\Benutzer\Benutzer\AppDaten\Roaming\Microsoft\Windows\Startmenü\Programme\Startup\GPU_Scv_Pack.lnk

C:\Benutzer\Benutzer\AppDaten\Roaming\Microsoft\Windows\Startmenü\Programme\Startup\GPU_Scv_Pack.lnk

Die LNK-Datei verweist auf “TeamViewer.exe”, das sich im Verzeichnis “C:\ProgramData\TV” befindet.

Verteidigung Ausweichen

Sobald die Persistenz hergestellt ist, fährt die Malware fort, neun bestimmte Prozesse zu beenden, wahrscheinlich mit der Absicht, Sicherheitstools zu deaktivieren.

Der Bedrohungsakteur hat auch einen BITS-Job eingerichtet, der es ihm ermöglicht, Tools auf den Zielendpunkt zu übertragen. BITS-Jobs können auch als Persistenz verwendet werden, da sie eine Dauer von 90 Tage.

Außerdem habe ich Fälle von Prozessinjektionsaktivitäten festgestellt, bei denen PowerShell den Prozess ‘PING.exe’ initiierte. Anschließend nutzte ‘PING.exe’ Prozessaushöhlungstechniken, um bösartigen Code in ‘dllhost.exe’ zu injizieren.

Entdeckung

Dann bemerkte ich mehrere zusätzliche Discovery-Befehle, die die Verwendung von WMI beinhalteten. Ich bin auf die WMI-Befehle gestoßen und habe auch ihr Vorhandensein in Strings beobachtet.

Sammlung von Systeminformationen

• Win32_OperatingSystem - Betriebssystemversion, Architektur, Betriebszeit.

• Win32_Prozessor - CPU-Modell, Architektur.

• Win32_LogicalDisk - Festplattenlayout, Speicherkapazität.

• Win32_VideoController - GPU-Informationen (häufig bei der VM-Erkennung verwendet).

• Win32_NetworkAdapterKonfiguration - Aktive Netzwerkschnittstellen und IPs.

Aufzählung der Sicherheitsprodukte

• FirewallProdukt, AntiSpywareProdukt, AntiVirusProdukt - Prüfung auf Sicherheitssoftware

Darüber hinaus habe ich im Rahmen dieser Tätigkeit auch beobachtet, dass‘nltest.exe‘Dies ist ein integriertes Windows-Befehlszeilentool, das von einem Akteur zur Domänen- und Netzwerkerkundung verwendet werden kann. Das Tool ermöglicht Folgendes:

• Abrufen einer Liste von Domänencontrollern

• Erzwingen einer Fernabschaltung

• Abfrage des Status des Vertrauens

• Testen von Vertrauensbeziehungen und des Status der Domänencontroller-Replikation in einer Windows-Domäne

• Erzwingen der Synchronisierung einer Benutzerkontodatenbank auf Domänencontrollern der Windows NT-Version 4.0 oder früher

Seitliche Bewegung

Durch die Prozessinjektion hat der Angreifer erfolgreich ein Tool auf den Zielhost übertragen, das den Versuch einer Seitwärtsbewegung ermöglicht.

Zugang zu Anmeldeinformationen

In letzter Zeit habe ich bei bestimmten Malware-Familien eine häufige Bedrohung festgestellt, die den Diebstahl von Anmeldedaten über Webbrowser beinhaltet. Diese Art von Malware versucht, Anmeldedaten zu erfassen, die anschließend in einer lokalen SQL-Datenbank gespeichert werden, bevor sie exfiltriert werden.

Zweite Stufe der Analyse

Während der Ausführung erstellt TeamViewer.exe eine komprimierte Datei namens hcmd.zip. Dieses Archiv wird dann mit 7-Zip entpackt, das in dem von a.zip heruntergeladenen Toolset enthalten war. Die extrahierte Datei hcmd.exe (ehemals Node.exe) wird ausgeführt und startet index.js, die eine C2-JavaScript-Hintertür enthält, die zum Aufbau eines Befehls- und Kontrollkanals dient.

Code-Analyse

In der zweiten Phase des Angriffs habe ich eine JavaScript-basierte Backdoor beobachtet, die mit Node (umbenannt in hcmd.exe) ausgeführt wurde. Bei näherer Betrachtung ist das Skript so konzipiert, dass es eine dauerhafte Verbindung mit einem C2-Server herstellt, die es dem Angreifer ermöglicht, beliebige Befehle auf dem angegriffenen Rechner auszuführen.

Socket IO Verbindung

Das Skript importiert und verwendet die Socket-Bibliothek, um die Fernverbindung zwischen dem kompromittierten Rechner und dem Angreifer zu ermöglichen.

Befehlsausführung über Node.js

Das Skript verwendet ‘node-cmd’ zur Ausführung der Systembefehle

• Dadurch wird ein versteckter CMD-Prozess (cmd.exe) gestartet, der es dem Angreifer ermöglicht, Windows-Befehle aus der Ferne zu senden und auszuführen.

• Die Referenz (processRef) wird später zur Interaktion mit dieser Shell verwendet.

Festcodierte Anmeldeinformationen und C2-Server

Das Skript enthält eine fest kodierte:

• Hardware-ID (hwid) zur Verfolgung infizierter Systeme

• Kennwort: (AutoHotkey)

• C2 Server IP: 5.252.153[.]81

Statische und dynamische Analyse

Wenn man sich die Zeitleiste der Aktivitäten ansieht, könnte man zunächst annehmen, dass der Angreifer TeamViewer als Remote Management Tool (RMT) nutzt, um einen ersten Fuß in die Tür zu bekommen. Die Entscheidung, ein separates Beispiel herunterzuladen, hat jedoch mein Interesse geweckt. Bei der Datei TeamViewer.exe handelte es sich um eine signierte Binärdatei, was zwar typisch für das Signieren von Code ist, aber dennoch einige Fragen aufwirft.

Bei weiteren Untersuchungen verglich ich es mit einer älteren Version von TeamViewer 5, die mit UPX gepackt worden war. Im Gegensatz dazu wies das von mir analysierte Beispiel keine UPX-Packung auf. Dies ist eine gängige Technik, um die Signatur und die Metadaten zu erhalten und gleichzeitig die wahre Natur der Datei zu verschleiern.

Meine erste Analyse konzentrierte sich darauf, herauszufinden, wie die Datei TV.dll geladen wurde. Zunächst konnte ich keine Hinweise darauf finden, dass die Datei TV.dll entweder durch LoadLibraryA oder LoadLibraryW, die Funktionen sind, die das angegebene Modul in den Adressraum des aufrufenden Prozesses laden. Das Fehlen von Verweisen deutet darauf hin, dass TV.dll möglicherweise dynamisch zur Laufzeit geladen wurde.

Außerdem habe ich einen indirekten Lademechanismus über die Funktion “FUN_004be74b“ aufgedeckt, die “LoadLibraryW“ während der Laufzeit dynamisch auflöst. Ein String, der auf “TV.dll“ verweist, befand sich in einer Datenstruktur, was bestätigt, dass die Binärdatei die Verfügbarkeit der DLL erwartet.

Durch Setzen eines Haltepunkts bei “LoadLibraryW” konnte ich die Ausführung von TV.dll verfolgen und das dynamische Laden zur Laufzeit bestätigen. Bei diesem Vorgang wird das Modul geladen und im Speicher abgebildet. Nachdem das Modul geladen wurde, wurde ihm nach dem Ladevorgang der DLL ein neuer EntryPoint zugewiesen, was durch einen TLS-Callback erleichtert wurde. Der “INT3-Haltepunkt ‘TLS Callback 1 (tv.dll)’ bei tv.0317A748” bestätigt, dass dieser Callback vor der Ausführung von DLLMain aufgerufen wurde.

Anhand der Speicherkartenansicht kann ich das erfolgreiche Laden der DLL bestätigen und sicherstellen, dass die Speicheradresse genau mit den in EDX angezeigten Daten übereinstimmt.

Wie wird die TV.dll geladen?

• TeamViewer.exe beginnt mit der Ausführung.

• Zur Laufzeit konstruiert es den DLL-Namen (TV.dll).

• Sie ruft LoadLibraryW (oder eine gleichwertige Funktion) über eine indirekte Referenz auf.

• TV.dll wird in den Speicher eingeblendet

• Die Ausführung wird an die TV.dll übertragen, so dass sie Code innerhalb des TeamViewer-Prozesses ausführen kann.

Bösartige DLL seitlich geladen

Anti-Virtualisierung und Debugger-Erkennung

Bei meiner Analyse ging es in erster Linie darum, festzustellen, ob in der Umgebung ein Debugger vorhanden ist. Wenn ein solcher Debugger erkannt wird, kann der Prozess beendet werden. Wie erwartet, wurde die Funktion “isDebuggerPresent” unter den statischen Importen gefunden. Ich überprüfte den Ort und analysierte den dekompilierten Code weiter.

• IsProcessorFeaturePresent(0x17) - prüft auf Hardware-Debug-Register.

• Ruft FUN_100bb403() auf - wahrscheinlich eine interne Funktion, die eine weitere Debuggerprüfung sein könnte.

• Löscht den Speicher (Memset) - um Spuren im Speicher zu vermeiden.

• Legt einen gefälschten Ausnahmesatz (0x40000015) an - ein beliebiger Ausnahmecode, den Debugger unterschiedlich behandeln können.

• IsDebuggerPresent() - Standard-API zur Erkennung angeschlossener Debugger.

• Registriert einen UnhandledExceptionFilter. Dies ist ein Trick, bei dem der Prozess eine Ausnahme auslöst.

• Wenn ein Debugger vorhanden ist, kann er die Ausnahme abfangen und den Ausführungsablauf ändern.

Eine zweite Funktion, die ich neben IsDebuggerPresent entdeckt habe, heißt “ProcessorFeatureRequest”. Ich habe die Unterroutine in “DetectVirtualisation” umbenannt. Der disassemblierte Codeabschnitt zeigt, dass es sich offenbar um CPU-Prüfungen handelt, mit denen jede Form der Virtualisierung erkannt werden soll. So wird möglicherweise das Vorhandensein von Virtualisierungs-Firmware wie Intel VT-x oder AMD-V überprüft.

Verwendet XGETBV(0) über in_XCR0: Sandbox/VMs unterstützen AVX- und XMM-Register oft nicht vollständig.

CPUID-Prüfungen: cpuid_basic_info(0) und cpuid_Version_info(1)

• CPU-Hersteller-String (GenuineIntel)

• Merkmalskennzeichen (EDX, ECX)

• Prozessorsignatur (EAX)

Dies bestätigt, dass der CPU-Hersteller Intel ist:

if (piVar1[1] == 0x756e6547 &&
    piVar1[2] == 0x49656e69 &&
    piVar1[3] == 0x6c65746e)
0x756e6547 = 'Genu'
0x49656e69 = 'ineI'
0x6c65746e = 'ntel'
→ 'GenuineIntel'

if (piVar1[1] == 0x756e6547 &&
    piVar1[2] == 0x49656e69 &&
    piVar1[3] == 0x6c65746e)
0x756e6547 = 'Genu'
0x49656e69 = 'ineI'
0x6c65746e = 'ntel'
→ 'GenuineIntel'

if (piVar1[1] == 0x756e6547 &&
    piVar1[2] == 0x49656e69 &&
    piVar1[3] == 0x6c65746e)
0x756e6547 = 'Genu'
0x49656e69 = 'ineI'
0x6c65746e = 'ntel'
→ 'GenuineIntel'

if (piVar1[1] == 0x756e6547 &&
    piVar1[2] == 0x49656e69 &&
    piVar1[3] == 0x6c65746e)
0x756e6547 = 'Genu'
0x49656e69 = 'ineI'
0x6c65746e = 'ntel'
→ 'GenuineIntel'

Vergleicht mit bekannten legitimen Intel-CPUs:

0x106c0, 0x20660, 0x20670, 0x30650, 0x30660, 0x30670

0x106c0, 0x20660, 0x20670, 0x30650, 0x30660, 0x30670

0x106c0, 0x20660, 0x20670, 0x30650, 0x30660, 0x30670

0x106c0, 0x20660, 0x20670, 0x30650, 0x30660, 0x30670

Falls übereinstimmend, setzt DAT_100f04b8 |= 1 - bedeutet “erwartete CPU”.

Userland Einhaken und Aushaken

Während unserer Analyse habe ich zwei Funktionen identifiziert, die Inline-Hooking implementierten und damit Umleitungsfunktionsaufrufe im Userland-Bereich abfingen. Unhooking bezieht sich auf den Prozess der Entfernung oder Umgehung von Hooks, wie sie von Sicherheitstools wie EDRs eingerichtet werden. Diese Technik wird häufig von Malware eingesetzt, um verdeckt in einem System zu operieren.

Die beiden beobachteten Funktionen:

• MinHookDisabled

• MinHookEnabled

Das Team benannte auch einige der im dekompilierten Code beobachteten Komponenten um, um ihn besser lesbar zu machen.

MinHookDisabled

Die Funktion, die einen zuvor platzierten Hook effektiv deaktiviert, indem sie die ursprünglichen Bytes an der Speicherstelle der Zielfunktion wiederherstellt. Dieser Vorgang macht alle durch den Hook vorgenommenen Änderungen, wie z. B. Sprung- oder Aufrufumleitungen, rückgängig.

• hookData > zeigt auf ein Array oder eine Struktur mit hakenbezogenen Metadaten.

• hookData[5] > enthält ein Flag, mit dem bestimmt wird, ob die Plattform 64-Bit oder 32-Bit.

  • Wenn die Linksverschiebung nicht nicht das Vorzeichenbit setzen, wird angenommen, dass es 64-Bit.

• Legt die Größe des Hakens wiederherzustellen:

  • 7 Bytes für 32-Bit

  • 5 Bytes für 64-Bit

• Verwendet VirtualProtect zum Ändern des Speicherschutzes an der HookLocation auf PAGE_EXECUTE_READWRITE (0x40), damit es die Bytes überschreiben kann.

• Wenn die Speicherschutzmaßnahmen erfolgreich geändert wurden:

  • Bestimmung der ursprünglichen Befehlsgröße (5 oder 7 Byte) anhand eines Bit-Flags in hookStruct[5].

• memcpy Wiederherstellung der ursprünglichen Bytes aus der Hook-Struktur (hookStruct + 3 enthält den ursprünglichen Code).

  • Wenden Sie nach der Wiederherstellung den ursprünglichen Speicherschutz wieder an.

• free(hookStruct) > Gibt den von den Hook-Metadaten verwendeten Speicher nach der Wiederherstellung frei.

MinHookEnabled

Die Funktion hat die Aufgabe, einen Hook zu installieren, der die Ausführung von einer bestimmten Zielfunktion zu einer benutzerdefinierten Umleitungsfunktion umleitet. Zusätzlich kann sie optional einen Zeiger auf die ursprüngliche Funktion, das so genannte Trampolin, beibehalten. Diese Funktionalität entspricht den Operationen der MinHook-API-Hooking-Bibliothek.

• hookData gespeichert wird:

  • hookData[0] = ursprüngliche Funktionsadresse

  • hookData[1] = Adresse der Umleitungsfunktion

  • hookData[2] = Trampolin (ursprünglicher Eintrag)

  • hookData[3+] = Sicherung der ursprünglichen Bytes, Flaggen, Metadaten

• Speichert 5 oder 7 Bytes von der Zielfunktion, um eine spätere Wiederherstellung zu ermöglichen (MinHookDisable verwendet dies).

• Ändert den Funktionsspeicher in “PAGE_EXECUTE_READWRITE” so dass er den Code im Speicher ändern kann.

• Schreibt eine relativer Sprung zur Umleitungsfunktion ab dem Beginn der ursprünglichen Funktion.

• Stellt sicher, dass der Befehlscache der CPU aktualisiert und die Schutzmechanismen wiederhergestellt werden.

• Speichert den Zeiger auf die ursprüngliche Funktion für die spätere Verwendung (z. B. um sie vom Umweg aus aufzurufen).

Indikatoren für Kompromisse