Inside Vidar 2026: Von Infektion zur Speicherausführung

Zusammenfassung

Der Bericht untersucht, wie sich Vidar zu einem mehrstufigen, dateilosen Angriffsframework entwickelt hat, das Go-basierte Loader, VBS, PowerShell und Living-off-the-Land-Binärdateien kombiniert, um bösartigen Inhalt abzurufen, der in JPEG- und TXT-Dateien versteckt ist, die auf einer Remote-IP-Adresse gehostet werden. Die eingebetteten Nutzlasten werden extrahiert, decodiert und direkt im Speicher über RegAsm.exeausgeführt, um eine Festplattenerkennung zu vermeiden. Der erste Zugriff erfolgt durch Social-Engineering-Täuschungen wie gefälschte GitHub-Repositories, kompromittierte WordPress-Seiten und gefälschte CAPTCHA-Seiten. Die Kampagne nutzt auch Telegram und Cloudflare-Front-Domains für Kommando und Kontrolle sowie Datenexfiltration.

Untersuchung

Point-Wild-Forscher verfolgten die vollständige Infektionskette vom initialen Go-kompilierten Dropper bis zur finalen Vidar-Nutzlast und dokumentierten jede Schicht der Verschleierung unterwegs. Ihre Analyse hob die Verwendung von benutzerdefinierten Base64-Markern, umgekehrten Zeichenfolgen und reflektierender .NET-Assembly-Ladung hervor, um die Ausführung zu verschleiern. Die Forscher beschrieben auch, wie WScript, PowerShell und RegAsm.exe als Ausführungsproxies missbraucht wurden, um der Malware das Dekodieren und Starten einer versteckten DLL vollständig im Speicher zu ermöglichen. Der Netzwerkverkehr bestätigte außerdem den HTTP-basierten Abruf von gestuften JPEG- und TXT-Nutzlasten von einer fest codierten IP-Adresse.

Abschwächung

Verteidiger sollten sich darauf konzentrieren, die frühen VBS- und PowerShell-Stufen der Infektionskette zu erkennen, einschließlich des verdächtigen Gebrauchs von RegAsm.exe, Abrufen von JPEG- oder TXT-Dateien von der bösartigen IP und erkennbaren Base64-Marker-Mustern. Das Blockieren bekannter bösartiger Domains und IP-Adressen, das Überwachen von ausgehendem Verkehr zu Telegram und die Anwendung von Ausführungskontrollen auf gängige LOLBin-Dienstprogramme können helfen, die Exposition zu reduzieren. Verhaltenserkennung, die auf dateilose Ausführung und In-Memory-Ladetechniken abgestimmt ist, wird ebenfalls dringend empfohlen.

Antwort

Wenn Indikatoren im Zusammenhang mit der Vidar-Infektionskette identifiziert werden, trennen Sie den betroffenen Host sofort, beenden verdächtige Prozesse wie WScript, PowerShell und RegAsm.exe, und erfassen Speicherabbildungen für eine forensische Überprüfung. Die identifizierte IP-Adresse und die zugehörigen Domains sollten blockiert werden, und alle Startverknüpfungen oder geplanten Aufgaben, die für Persistenz verwendet werden, sollten entfernt werden. Sicherheitsteams sollten auch eine vollständige Überprüfung der Anmeldeinformationen durchführen, die sich auf exponierte Browserdaten, Erweiterungen und Kryptowährungs-Wallets konzentriert.

Simulation der Ausführung

Voraussetzung: Der Telemetrie- & Baseline-Pre‑Flight-Check muss bestanden sein.

Begründung: Dieser Abschnitt beschreibt die präzise Umsetzung der Angreifer-Technik (TTP), die darauf abzielt, die Erkennungsregel auszulösen. Die Befehle und Erzählung MÜSSEN die identifizierten TTPs direkt widerspiegeln und darauf abzielen, die genaue Telemetrie zu erzeugen, die von der Erkennungstrias erwartet wird.

• Angriffsbericht & Befehle:

  1. Initialer Dropper (WScript): Der Angreifer liefert eine bösartige JScript-Datei (payload.js), die über WScript.exegestartet wird. Das Skript lädt eine base64-enkodierte PowerShell-Nutzlast von einem C2-Server herunter und schreibt sie in %TEMP%.
  2. PowerShell-Phase: Die heruntergeladene Nutzlast wird mit -ExecutionPolicy Bypass -NoProfile -WindowStyle Hiddenausgeführt, führt reflektive DLL-Ladung (T1620) einer bösartigen .NET-Assembly (evil.dll) in den Speicher aus und legt die Assembly auf der Festplatte ab.
  3. RegAsm Proxy: Um native PowerShell-Erkennung zu vermeiden, ruft der Angreifer RegAsm.exe auf evil.dll unter Verwendung der /codebase Option, was dazu führt, dass der .NET-Loader den bösartigen Einstiegspunkt ausführt (T1574.014).

  Die Kette erzeugt drei unterschiedliche Sysmon-Ereignisse – jede entspricht dem Regel-Selektor Image|endswith – und löst damit den Alarm aus.

• Regression Test Skript: Das folgende Skript reproduziert die obige Kette in einer sicheren, abgeschirmten Weise, indem es harmlose echo-Befehle und eine Dummy-DLL (eine einfache Textdatei) verwendet, um echte bösartige Aktivitäten zu vermeiden und dennoch die gleichen Prozess-Erstellungsereignisse zu generieren.

  <#  
  Vidar-ähnliche mehrstufige Ausführungssimulation  
  - Stufe 1: WScript startet ein JScript, das ein PowerShell-Skript auf %TEMP% schreibt  
  - Stufe 2: PowerShell führt das Skript aus, erstellt eine Dummy-DLL und startet RegAsm  
  #>
  
  # ---------- Stufe 1: WScript ----------
  $jsPath = "$env:TEMPstage1.js"
  $psPayloadPath = "$env:TEMPstage2.ps1"
  $dummyDllPath = "$env:TEMPevil.dll"
  
  # JScript, das eine einfache PowerShell-Nutzlast auf die Festplatte schreibt
  $jsContent = @"
  var fso = new ActiveXObject("Scripting.FileSystemObject");
  var ts = fso.OpenTextFile("$psPayloadPath", 2, true);
  ts.WriteLine('Write-Host "[Stage 2] PowerShell ausgeführt"');
  ts.WriteLine('Set-Content -Path "$dummyDllPath" -Value "Dies ist eine Dummy-DLL"');
  ts.WriteLine('Start-Process -FilePath "$env:SystemRootMicrosoft.NETFramework64v4.0.30319RegAsm.exe" -ArgumentList "`"$dummyDllPath`" /codebase" -NoNewWindow');
  ts.Close();
  "@
  
  Set-Content -Path $jsPath -Value $jsContent -Encoding ASCII
  
  # Führe das JScript über WScript aus
  Write-Host "`n[Stufe 1] WScript starten..."
  & "$env:SystemRootSystem32WScript.exe" $jsPath
  
  # ---------- Stufe 2: PowerShell ----------
  Write-Host "`n[Stufe 2] Generierte PowerShell-Nutzlast ausführen..."
  & powershell.exe -NoProfile -ExecutionPolicy Bypass -File $psPayloadPath
  
  # ---------- Bereinigung ----------
  Write-Host "`nBereinige temporäre Dateien..."
  Remove-Item -Path $jsPath, $psPayloadPath, $dummyDllPath -Force -ErrorAction SilentlyContinue

• Bereinigungsbefehle: Zusätzlich zur Bereinigung am Ende des Skripts führen Sie Folgendes aus, um sicherzustellen, dass keine verbleibenden Prozesse oder Dateien vorhanden sind.

  # Beenden Sie gewaltsam alle verbliebenen RegAsm- oder PowerShell-Instanzen, die durch den Test gestartet wurden
  Get-Process -Name regasm, powershell -ErrorAction SilentlyContinue | Stop-Process -Force
  
  # Entfernen Sie alle verbleibenden Dateien in %TEMP%, die dem Testmuster entsprechen
  Get-ChildItem -Path $env:TEMP -Filter "stage*.*" -File | Remove-Item -Force