Larva-26005: Rückverfolgung der Verbindung von Xctdoor zu CRAT-Angriffen
Detection stack
- AIDR
- Alert
- ETL
- Query
Zusammenfassung
Der Bedrohungsakteur Larva-26005 verbreitet aktiv die Xctdoor-Malware an Benutzer in Südkorea. Die Kampagne stützt sich auf mehrere Verbreitungsmethoden, einschließlich bösartiger LNK-Dateien, Spear-Phishing und als legitime Sicherheitssoftware getarnte Malware wie Veraport und SoftCamp. Xctdoor fungiert als Backdoor, die in der Lage ist, Befehle auszuführen, Dateien zu manipulieren und sensible Informationen zu stehlen.
Untersuchung
ASEC untersuchte die Verbindungen zwischen der aktuellen Larva-26005-Aktivität und früheren CRAT-Malware-Kampagnen. Die Analyse deckte gemeinsame Verschleierungsroutinen auf, ähnliche Installationspfade innerhalb der AppX-Pakete und Verbindungen zur Lazarus-Gruppe. Forscher dokumentierten auch eine mehrstufige Ausführungskette, die VBS-, BAT- und PowerShell-Skripte umfasst.
Minderung
Benutzer sollten vorsichtig sein, wenn sie E-Mail-Anhänge öffnen oder ausführbare Dateien von unbekannten oder nicht verifizierten Quellen herunterladen. Sicherheitssoftware-Installationsprogramme sollten vor der Ausführung validiert werden, um sicherzustellen, dass sie legitim sind. Organisationen sollten auch Endpunktsicherheitsprodukte wie V3 auf die neuesten Versionen aktualisieren, um bekannte Malware-Signaturen zu erkennen.
Reaktion
Wenn verdächtige LNK-Dateien oder unautorisierte RegSvr32 Aktivitäten entdeckt werden, sollte der betroffene Host sofort vom Netzwerk isoliert werden. Die Reaktionskräfte sollten %PUBLIC% and %LOCALAPPDATA% auf nicht autorisierte Skripte, DLLs oder verwandte Artefakte untersuchen. Ein umfassender Scan der gesamten Umgebung sollte auch nach Indikatoren erfolgen, die mit XcLoader und Xctdoor in Verbindung stehen.
Angriffsablauf
Erkennungen
Mögliche Ausnutzung eines Webservers oder einer Webanwendung [Windows] (via cmdline)
Proof of Value
LOLBAS WScript / CScript (via process_creation)
Proof of Value
Verdächtige Ausführung aus dem öffentlichen Benutzerprofil (via process_creation)
Proof of Value
Verdächtige Powershell-Strings (via powershell)
Proof of Value
Rufe verdächtige .NET-Methoden aus Powershell auf (via powershell)
Proof of Value
Verdächtige Dateien im öffentlichen Benutzerprofil (via file_event)
Proof of Value
IOCs (HashMd5) zum Erkennen: Analyse der Verbindung zwischen Xctdoor und vergangenen CRAT-Angriffsfällen (Larva-26005)
Proof of Value
Xctdoor-Ausführung mit Regsvr32 für Persistenz [Windows-Prozess-Erstellung]
Proof of Value
VBS- und PowerShell-Indikatoren von Xctdoor und XcLoader [Windows-Registry-Ereignis]
Proof of Value
Simulationsausführung
Voraussetzung: Der Telemetrie- & Baseline-Pre-Flight-Check muss bestanden haben.
Begründung: Dieser Abschnitt beschreibt die präzise Ausführung der gegnerischen Technik (TTP), die entwickelt wurde, um die Erkennungsregel auszulösen. Die Befehle und Erzählungen MÜSSEN die identifizierten TTPs direkt reflektieren und darauf abzielen, die genau erwartete Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird. Abstrakte oder nicht zusammenhängende Beispiele führen zu Fehldiagnosen.
-
Angriffserzählung & Befehle: Der Angreifer versucht, Persistenz auf dem Rechner des Opfers zu etablieren, um Neustarts zu überstehen. Sie platzieren eine bösartige DLL, die als Sperrdatei getarnt ist (
settings.Lock) in einem Unterverzeichnis vonMicrosoft.MicrosoftOffice365Hubpaket. Um einer Erkennung zu entgehen, verwenden sieregsvr32.exeum diese Datei zu laden. Daregsvr32.exeein digital signiertes Microsoft-Binary ist, umgeht es oft grundlegende Sicherheitskontrollen. Der Befehl ist darauf ausgelegt, speziell den im Bedrohungsanalysebericht identifizierten Pfad anzugreifen, was die Ausführung der Xctdoor-Backdoor über COM-Interface-Entführung erleichtert. -
Regressionstestskript:
# Simulationsskript für die Erkennung von Xctdoor-Persistenz # Hinweis: Dieses Skript erstellt eine Dummy-Datei, um die Nutzlast zu simulieren und die tatsächliche Malwareausführung zu vermeiden. $targetDir = "$env:LOCALAPPDATAPackagesMicrosoft.MicrosoftOffice365Hub_8wekyb3d8bbweSettings" $targetFile = Join-Path $targetDir "settings.Lock" # 1. Erstellen Sie die Verzeichnisstruktur, falls sie nicht existiert if (!(Test-Path $targetDir)) { New-Item -Path $targetDir -ItemType Directory -Force | Out-Null } # 2. Erstellen Sie eine Dummy-"bösartige" Datei (in Wirklichkeit wäre dies eine DLL) # Wir verwenden eine Null-Byte-Datei für die Sicherheit in dieser Simulation New-Item -Path $targetFile -ItemType File -Force | Out-Null Write-Host "[+] Dummy-Nutzlast erstellt unter: $targetFile" # 3. Führen Sie regsvr32 aus, um die Erkennungsregel auszulösen Write-Host "[+] Führe regsvr32 aus, um die Erkennung auszulösen..." Start-Process "regsvr32.exe" -ArgumentList "/s `"$targetFile`"" -Wait Write-Host "[+] Simulation abgeschlossen. Überprüfen Sie SIEM auf Warnmeldungen." -
Bereinigungsbefehle:
# Bereinigungsskript $targetDir = "$env:LOCALAPPDATAPackagesMicrosoft.MicrosoftOffice365Hub_8wekyb3d8bbweSettings" $targetFile = Join-Path $targetDir "settings.Lock" if (Test-Path $targetFile) { Remove-Item -Path $targetFile -Force Write-Host "[+] Simulationsdatei bereinigt." } else { Write-Host "[!] Zieldatei nicht gefunden, nichts zu bereinigen."