SOC Prime Bias: Hoch

01 Jul 2026 06:50 UTC

LokiBot nach einem Jahrzehnt: Analyse einer jüngsten Kampagne

Author Photo
SOC Prime Team linkedin icon Folgen
LokiBot nach einem Jahrzehnt: Analyse einer jüngsten Kampagne
shield icon

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

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-Reflexion Fä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."