LokiBot nach einem Jahrzehnt: Analyse einer jüngsten Kampagne
Detection stack
- AIDR
- Alert
- ETL
- Query
Zusammenfassung
LokiBot ist ein langjähriger Infostealer, der entwickelt wurde, um Anmeldeinformationen von Browsern, Kryptowährungs-Wallets und anderen sensiblen Anwendungen zu sammeln. Diese aktuelle Kampagne stützt sich auf eine mehrstufige Ausführungskette, die mit einem verschleierten JScript-Anhang beginnt, der über Malspam zugestellt wird. Die Malware verwendet Prozessinjektion und API-Hashing, um die Sichtbarkeit zu verringern, während sie gestohlene Daten an ihre Command-and-Control-Infrastruktur sendet.
Untersuchung
Die Untersuchung analysierte ein mehrstufiges LokiBot-Sample und verfolgte seinen Fortschritt von einem JScript-Anhang zu einem PowerShell-Loader, dann zu einem .NET-Injektor und schließlich zu der LokiBot-Nutzlast. Analysten identifizierten die Verwendung von ConfuserEx-Schutz, XOR-Entschlüsselung und reflektierenden Ladelösungen in der gesamten Kette. Die Studie beschrieb auch den angepassten API-Hashing-Ansatz der Malware und eine fehlerhafte registrybasierte Persistenzmethode.
Minderung
Organisationen sollten leistungsstarke E-Mail-Filter einsetzen, um bösartige JScript-Anhänge und Malspam vor der Zustellung zu blockieren. Die Überwachung verdächtiger Kindprozesse, die von wscript.exe and powershell.exe ausgelöst werden, ist ebenfalls entscheidend. Darüber hinaus kann die Einschränkung der Ausführung nicht vertrauenswürdiger .NET-Assemblies und die Überwachung ungewöhnlicher Änderungen der Windows-Run-Schlüssel dazu beitragen, die Exposition zu verringern.
Reaktion
Wenn LokiBot erkannt wird, isolieren Sie den betroffenen Endpunkt sofort, um weiteren Datendiebstahl und die Command-and-Control-Kommunikation zu stoppen. Ermittler sollten eine forensische Analyse durchführen, um den ursprünglichen Eintrittspunkt zu bestimmen und das Ausmaß der Anmeldeinformationeneinbußen zu beurteilen. Alle Konten, die vom infizierten Host aus zugegriffen wurden, sollten eine vollständige Passwortzurücksetzung durchlaufen, und die Umgebung sollte auf verwandte JScript- und PowerShell-Artefakte gescannt werden.
Angriffsfluss
Erkennungen
Mögliche Persistenzpunkte [ASEPs – Software/NTUSER Hive] (über registry_event)
Anzeigen
Die Möglichkeit der Ausführung durch versteckte PowerShell-Befehlszeilen (über cmdline)
Anzeigen
LOLBAS WScript / CScript (über prozess_creation)
Anzeigen
Verdächtige Powershell-Strings (über powershell)
Anzeigen
LokiBot C2-Kommunikation über HTTP-Anfrage [Windows-Netzwerkverbindung]
Anzeigen
Erkennung der LokiBot-Prozessinjektion über aspnet_compiler.exe [Windows-Prozesserstellung]
Anzeigen
Erkennung der LokiBot-Ausführung über Base64-verschlüsseltes PowerShell-Skript und .NET-Assembly-Ladung [Windows PowerShell]
Anzeigen
Simulationsausführung
Voraussetzung: Der Telemetrie- & Baseline-Vorabflug-Check muss bestanden sein.
Begründung: Dieser Abschnitt beschreibt die genaue Ausführung der gegnerischen Technik (TTP), die entwickelt wurde, um die Erkennungsregel auszulösen. Die Befehle und die Erzählung MÜSSEN direkt die identifizierten TTPs widerspiegeln und sollen die genaue Telemetrie erzeugen, die von der Erkennungslogik erwartet wird. Abstrakte oder nicht verwandte Beispiele führen zu Fehldiagnosen.
-
Angriffserzählung & Befehle: Dem Gegner ist es gelungen, mit einer JScript-Datei ersten Zugriff zu erhalten. Um das Ablegen einer erkennbaren
.dll-Datei auf der Festplatte zu vermeiden, führen sie einen PowerShell-Befehl aus, der eine Base64-codierte Zeichenkette enthält. Dieses Skript, sobald es dekodiert ist, verwendet die.NET-ReflexionFähigkeit zum Aufrufen[System.Reflection.Assembly]::Load, um eine schädliche Nutzlast direkt in den aktuellen Prozessspeicher zu ziehen. Dieser „fileless“ Ansatz ist ein Markenzeichen von LokiBot. -
Regressionstest-Skript:
# LokiBot-Simulationsskript # Dieses Skript ist so gestaltet, dass es mit den genauen Strings übereinstimmt, die in der Erkennungsregel definiert sind. # 1. Simuliere die Base64-Komponente $encodedCommand = "Base64-codiertes PowerShell-Skript" $dummyPayload = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("DummyPayload")) # 2. Simuliere die Assembly-Lade-Komponente unter Verwendung des genauen Strings aus der Erkennungsregel # Wir verwenden try/catch, weil dies eine Simulation ist und die "Payload" keine echte Assembly ist. try { Write-Host "Ausführung des codierten Schrittes..." Write-Output $encodedCommand # Diese Zeile ist der primäre Auslöser für die Erkennungsregel $trigger = "[System.Reflection.Assembly]::Load" Write-Host "Versuch zur Ausführung der Assembly über: $trigger" # Wir rufen es über Invoke-Expression auf, um sicherzustellen, dass es im ScriptBlockText erscheint Invoke-Expression "Write-Host 'Triggering: $trigger'" } catch { Write-Error "Simulation konnte den Trigger-String nicht ausführen." } -
Bereinigungskommandos:
# Durch das Simulationsskript werden keine dauerhaften Änderungen vorgenommen. # Einfaches Löschen der Konsole und Sicherstellen, dass keine verbleibenden Prozesse existieren. Clear-Host Write-Host "Simulationsbereinigung abgeschlossen. Keine Dateien wurden abgelegt."