Jobangebote locken mit zwei ausgeklügelten mehrstufigen Angriffsketten

Zusammenfassung

Zwei getrennte mehrstufige Angriffsketten nutzen jobbezogenes Social Engineering, um Malware zu verbreiten. Kampagne 1 verlässt sich auf ein ZIP-Archiv, um PureRAT über einen Python-basierten Loader zu deployen, der DLL-Sideloading und mehrere Persistenzmechanismen nutzt. Kampagne 2 liefert eine LNK-Datei, die mshta.exestartet, um ein benutzerdefiniertes In-Memory-Implantat abzurufen und auszuführen.

Untersuchung

Die Untersuchung verknüpfte Kampagne 1 mit einem in Vietnam ansässigen kriminellen Cluster mit Überschneidungen der Infrastruktur, die einer bekannten PXA Stealer-Operation zugeschrieben werden. Kampagne 2 schien eine maßgeschneiderte Kampagne ohne identifizierte öffentliche Überschneidungen zu sein. Beide Angriffsketten verwenden fortschrittliche Verschleierungstechniken, einschließlich AMSI- und ETW-Patching sowie reflektierendes Code-Loading.

Abschwächung

Verteidiger sollten auf signierte Microsoft-Binärdateien achten, die unsignierte DLLs aus benutzerbeschreibbaren Verzeichnissen laden, und mshta.exe Ausführung unter Einbeziehung von entfernten URLs erkennen. Ausgangsfilterung für nicht standardmäßige hohe Ports und das Auditieren von COM-basierten geplanten Aufgaben können helfen, diese Infektionsketten zu unterbrechen. Eine Stärkung der Speicherintegritätüberwachung ist ebenfalls wichtig.

Reaktion

Wenn bösartige Aktivitäten erkannt werden, sollte die Bereinigung mehrere Persistenzmechanismen berücksichtigen, einschließlich WMI-Abonnements und COM-Hijacking. Das Entfernen einer einzelnen Datei oder geplanten Aufgabe kann Kampagne 1 aufgrund ihres selbstreparierenden Verhaltens nicht vollständig eliminieren. Antworten sollten die Staging-Verzeichnisse untersuchen und alle identifizierten Persistenz-Artefakte vollständig entfernen.

Simulation Execution

• Angriffsgeschichte & Befehle: Ein Gegner hat sich initialen Zugang verschafft und möchte eine bösartige Nutzlast ausführen, während er sich als gewöhnliche Produktivitätsanwendung tarnt, um keinen Verdacht zu erregen. Der Angreifer kopiert die legitime mshta.exe aus System32 in einen lokalen Ordner und benennt sie in WinWord.exeum. Anschließend platziert er eine bösartige DLL im selben Ordner. Wenn WinWord.exe (das umbenannte MSHTA) ausgeführt wird, zeichnet die Image Load Telemetrie des Systems einen Prozess auf, bei dem der Image Dateiname WinWord.exe ist, aber die OriginalFileName Metadaten bleiben mshta.exe. Diese Diskrepanz ist der spezifische Auslöser für die Erkennungsregel.

• Regression Test Script:

  # Simulation des DLL-Sideloadings über Umbenennung
  $workDir = "$env:TEMPSimulation_SideLoad"
  New-Item -ItemType Directory -Force -Path $workDir
  Set-Location $workDir
  
  # 1. Kopieren der legitimen Binärdatei
  Copy-Item "C:WindowsSystem32mshta.exe" -Destination "WinWord.exe"
  
  # 2. Erstellen einer Dummy/harmlosen DLL, um sicherzustellen, dass der Prozess tatsächlich etwas 'laden' kann 
  # (Hinweis: In einem echten Angriff wäre dies die bösartige DLL. 
  # Für das Auslösen der Telemetrie müssen wir nur die umbenannte Binärdatei ausführen.)
  
  # 3. Ausführen der umbenannten Binärdatei
  # Dies löst das Sysmon-Ereignis ID 7 für den Image Load der umbenannten Datei aus
  Write-Host "[*] Umbenannte Binärdatei wird ausgeführt, um Erkennung auszulösen..."
  Start-Process ".WinWord.exe" -ArgumentList "javascript:alert('Angriff ausgelöst');close();" -Wait
  
  Write-Host "[+] Simulation abgeschlossen. Überprüfen Sie SIEM auf Bildlast-Mismatch."

• Bereinigungskommandos:

  # Bereinigen der Simulationsdateien
  $workDir = "$env:TEMPSimulation_SideLoad"
  if (Test-Path $workDir) {
      Remove-Item -Recurse -Force $workDir
      Write-Host "[+] Bereinigung erfolgreich."
  } else {
      Write-Host "[-] Bereinigung fehlgeschlagen: Verzeichnis nicht gefunden."
  }