UAT-10147 Verwendet SPECTRE für plattformübergreifende Persistenz und Umgehung
Detection stack
- AIDR
- Alert
- ETL
- Query
Zusammenfassung
UAT-10147 ist ein chinesischsprachiger Bedrohungsakteur, der ein ausgeklügeltes plattformübergreifendes Post-Exploitation-Ökosystem betreibt. Sein Toolkit umfasst das plattformübergreifende Backdoor SPECTRE, das Specter Linux Rootkit und SEO-Betrugstools wie BadIIS. Der Akteur setzt auch fortgeschrittene Techniken ein, darunter das eigene Mitbringen von Schwachstellen (BYOVD), um EDR-Schutzmaßnahmen zu deaktivieren, und integriert KI-unterstützte Entwicklungs-Workflows.
Untersuchung
Cisco Talos analysierte wiederhergestellten Quellcode und Malware-Proben, um die Entwicklung der Werkzeuge von UAT-10147 nachzuverfolgen. Die Untersuchung identifizierte Anzeichen für KI-unterstützte Codegenerierung innerhalb des Linux-Rootkits und charakteristische Entwicklungsartefakte in der BadIIS-Malware. Forscher dokumentierten auch die Befehlstrukturen, Injektionstechniken und Abwehrmechanismen auf Kernel-Ebene des SPECTRE-Implantats.
Minderung
Organisationen sollten IIS- und Linux-Server mit Internetzugang sichern und die Bereitstellung bekannter anfälliger Treiber wie RTCore64.sys and DBUtil_2_3.sys. Starke EDR-Konfigurationen sollten durchgesetzt werden, mit Überwachung auf unautorisierte Kernelmodul-Ladungen und verdächtige systemd-Dienst-Erstellungen. Server-Abwehrmaßnahmen sollten auch die Überprüfung auf unautorisierte ASHX-Handler und unerwartete HTTP-Header wie X-ID.
Reaktion
Wenn Aktivitäten von UAT-10147 festgestellt werden, sollten kompromittierte IIS- oder Linux-Server sofort isoliert werden, um die seitliche Bewegung einzuschränken. Responder sollten eine forensische Analyse der Kernel-Integrität durchführen und nach unautorisierten NTFS-Alternaten Datenströmen suchen. Systemprotokolle sollten ebenfalls auf verdächtige Dienst-Installationen und potenziellen Anmeldeinformationsdiebstahl durch Registry-Hive-Dumping oder Credential-Manager-Auflistung überprüft werden.
Angriffsfluss
Wir aktualisieren diesen Teil noch.
Erkennungen
Verdächtige Cmdkey-Nutzung (via cmdline)
Verdächtiger Command-and-Control durch ungewöhnliche Top-Level-Domain (TLD) DNS-Anfrage (via dns)
Versteckte Datei wurde auf Linux-Host erstellt (via file_event)
Erkennung der SPECTRE-Registrierungsänderung zur Persistenz [Windows Registrierungsereignis]
Erkennung der SPECTRE-DLL- und Prozess-Injektion [Windows Prozess-Erstellung]
Erkennung der Shell-Befehlsausführung und Kernelmodul-Ladung der SPECTRE-Linux-Variante [Linux Prozess-Erstellung]
Simulation Execution
Voraussetzung: Die Telemetrie- & Baseline-Vorflugkontrolle muss bestanden sein.
Begründung: Dieser Abschnitt beschreibt die präzise Ausführung der Adversary-Technik (TTP), die entwickelt wurde, um die Erkennungsregel auszulösen. Die Befehle und Narrative MÜSSEN die identifizierten TTPs direkt widerspiegeln und darauf abzielen, die erwartete Telemetrie exakt zu erzeugen, die von der Erkennungslogik erwartet wird. Abstrakte oder nicht verwandte Beispiele führen zu Fehldiagnosen.
-
Angreifergeschichte & Befehle: Der Angreifer hat über eine Web-Schwachstelle Initialzugriff erlangt. Um tiefe Persistenz zu schaffen und Erkennung zu verhindern, beabsichtigen sie, ein Rootkit bereitzustellen. Der Angreifer startet zuerst eine Shell, um seine Sitzung zu stabilisieren. Dann führen sie
psaus, um zu sehen, ob Überwachungsprozesse laufen. Schließlich verwenden sieinsmod, um ein Dummy-Kernelmodul zu laden, indem das Verfahren der SPECTRE-Variante zur Änderung des Kernelverhaltens im Fernzugriff nachgeahmt wird. -
Regressionstest-Skript:
#!/bin/bash # SPECTRE-Linux-Varianten-Simulationsskript echo "[+] Starten der SPECTRE-Linux-Varianten-Simulation…" # 1. Shellausführung simulieren (selection_shell) echo "[+] Schritt 1: Shell-Befehl ausführen..." /bin/sh -c "echo 'Shell-Zugriff hergestellt'" # 2. Prozessentdeckung simulieren (selection_ps) echo "[+] Schritt 2: Prozessentdeckung durchführen..." ps -ef | grep "simulation" # 3. Kernelmodul-Ladung simulieren (selection_kernel_module) # Hinweis: Dies erfordert sudo. Wir werden versuchen, ein Dummy-Modul zu laden oder den Befehl zu simulieren. # Um ein Systemabsturz zu vermeiden, verwenden wir einen nicht vorhandenen Modulnamen # der dennoch 'insmod'-Befehlszeilen-Telemetrie erzeugt. echo "[+] Schritt 3: Versuch, Kernelmodul über insmod zu laden..." sudo insmod spectre_rootkit_test.ko || echo "[!] insmod fehlgeschlagen wie erwartet (Modul nicht gefunden), aber Telemetrie sollte generiert werden." echo "[+] Simulation abgeschlossen." -
Bereinigungskommandos:
# Bereinigung ist minimal, da wir einen nicht vorhandenen Modulnamen verwendet haben, um Systeminstabilität zu vermeiden. # Wenn ein echtes Modul geladen wurde, verwenden Sie: # sudo rmmod spectre_rootkit_test echo "[+] Bereinigung: Keine dauerhaften Änderungen am Kernel vorgenommen."