Zwei Malware-Loader im Vergleich: Von ClickFix-Zustellung zu C2
Detection stack
- AIDR
- Alert
- ETL
- Query
Zusammenfassung
Bedrohungsakteure verlassen sich zunehmend auf ClickFix- und TerminalFix-Techniken, um Malware-Loader wie Lorem Ipsum Loader und Axolotl Loader bereitzustellen. Diese Loader dienen oft als Vorläufer für Ransomware-Bereitstellungen durch DLL Sideloading, MSI-Installationen und Node.js-Ausführung. Die Kampagnen integrieren auch fortschrittliche Ausweichtechniken wie ntdll Unhooking und verschlüsselte Nutzlasten, die in benutzerdefinierten DLL-Bereichen eingebettet sind.
Untersuchung
Forscher analysierten Lorem Ipsum- und Axolotl-Loader-Proben, um ihre Bereitstellungsketten und technischen Merkmale zu untersuchen. Die Untersuchung ergab trojanisierte MSI-Installationsprogramme, mehrstufige PowerShell-Skripte und einen markanten .cpoc -Abschnitt innerhalb von DLLs, die für die Ressourcenspeicherung verwendet werden. Vergleichende Analysen zeigten auch Unterschiede in C2-Kommunikation, Ausweichmechanismen und Persistenztechniken zwischen den beiden Loader-Familien.
Minderung
Organisationen sollten Sysmon-Telemetrie auf DLL Sideloading und verdächtige übergeordnete und untergeordnete Prozessbeziehungen überwachen, einschließlich PowerShell, die Batch-Dateien startet. Es wird empfohlen, strikte Kontrollen über die Ausführung von MSI-Installationsprogrammen durchzusetzen und nicht signierte DLLs in benutzerbeschreibbaren Verzeichnissen zu erkennen. Sicherheitsteams sollten auch den Netzwerkverkehr auf ungewöhnliche User-Agents, wie z.B. Firefox/143, und verdächtige C2-Registrierungsmuster im Zusammenhang mit aktiven Infektionen untersuchen.
Reaktion
Wenn böswillige Aktivitäten erkannt werden, isolieren Sie betroffene Hosts und führen Sie eine forensische Analyse von benutzerbeschreibbaren Verzeichnissen wie C:WindowsTemp oder C:UsersPublic durch. Jagen Sie nach geplanten Aufgaben und Registrierungsausführungsschlüsseln mit zufälligen Namen. Führen Sie retrospektive Suchen über DNS- und Proxy-Protokolle für bekannte C2-Domänen und IP-Adressen durch, um den Umfang der Kompromittierung zu bestimmen.
Angriffsfluss
Wir aktualisieren diesen Teil noch.
Erkennungen
Mögliche Persistenzpunkte [ASEPs – Software/NTUSER Hive] (via registry_event)
Mögliche Ausführung durch Verwendung eines kurzen Skript-Namens (via cmdline)
Schtasks zeigt auf verdächtiges Verzeichnis/Binary/Skript (via cmdline)
Verdächtige PowerShell-Strings (via powershell)
Verdächtige Windows-API-Funktionen aus PowerShell aufrufen (via powershell)
Verdächtige Dateien im öffentlichen Benutzerprofil (via file_event)
Verdächtige geplante Aufgabe (via audit)
IOCs (HashSha256) zur Erkennung: Von ClickFix zu C2: Vergleichsanalyse von zwei Malware-Loadern Teil 2
IOCs (HashSha256) zur Erkennung: Von ClickFix zu C2: Vergleichsanalyse von zwei Malware-Loadern Teil 1
IOCs (HashMd5) zur Erkennung: Von ClickFix zu C2: Vergleichsanalyse von zwei Malware-Loadern
IOCs (SourceIP) zur Erkennung: Von ClickFix zu C2: Vergleichsanalyse von zwei Malware-Loadern
IOCs (DestinationIP) zur Erkennung: Von ClickFix zu C2: Vergleichsanalyse von zwei Malware-Loadern
Host-Sideload startet sich selbst neu mit UUID benannten Mutex [Windows Prozesserstellung]
Erkennung von böswilligen Anfragen und Command-and-Control-Mustern mit letsdiskuss.com [Windows-Netzwerkverbindung]
DLL Sideloading und Registrierung-Ablaufschlüssel-Persistenz über signierte Microsoft-Executables [Windows Sysmon]
Erkennung von böswilliger PowerShell- und DLL-Aktivität [Windows PowerShell]
Simulationsausführung
-
Angriffserzählung & Befehle: Ein Gegner hat initialen Zugriff erlangt und versucht, einen modularen Malware-Loader bereitzustellen. Um einfache signaturbasierte AV zu umgehen, verwenden sie PowerShell, um einen benutzerdefinierten Loader aufzurufen. Der Loader nutzt spezifische Laufzeitbibliotheken (
libgcc_s_seh-1.dll) und erfordert spezifische Flags (-AgentDll), um die Nutzlast im Speicher zu initialisieren. Das Ziel des Angreifers ist es, eine persistente C2-Verbindung aufzubauen, indem diese Komponenten durch eine PowerShell-gesteuerte Ausführungskette geladen werden. -
Regressionstest-Skript:
# Simulationsskript zur Erkennungsvalidierung # Dieses Skript imitiert das Verhalten, das in der Sigma-Regel definiert ist $workingDir = $env:TEMP $dllName = "libgcc_s_seh-1.dll" $dllPath = Join-Path $workingDir $dllName Write-Host "[+] Erstellen von Dummy-DLL für die Simulation..." New-Item -Path $dllPath -ItemType File -Force | Out-Null Write-Host "[+] Ausführung des PowerShell-Befehls, um Auswahl1 zu triggern (DLL-Name in der Befehlszeile)..." Start-Process powershell.exe -ArgumentList "-Command `& {Write-Output 'Loading $dllPath'}`" -NoNewWindow Write-Host "[+] Ausführung des PowerShell-Befehls, um Auswahl2 zu triggern (AgentDll-Flag)..." Start-Process powershell.exe -ArgumentList "-AgentDll -DepsDir C:Temp -Shim" -NoNewWindow Write-Host "[+] Simulation abgeschlossen." -
Aufräumbefehle:
# Aufräumskript $workingDir = $env:TEMP $dllName = "libgcc_s_seh-1.dll" $dllPath = Join-Path $workingDir $dllName if (Test-Path $dllPath) { Remove-Item -Path $dllPath -Force Write-Host "[+] Dummy-DLL bereinigt." } else { Write-Host "[!] DLL nicht gefunden, nichts zu bereinigen." }