Die Geschichte von Zwei INC Erpresserbriefen

Zusammenfassung

Eine Organisation wurde von INC-Ransomware angegriffen, nachdem ein anfänglicher Kompromiss wahrscheinlich von einem Initial Access Broker durchgeführt wurde. Der Angriff nutzte Techniken zur Verbringung eines eigenen anfälligen Treibers (BYOVD), um Sicherheitskontrollen zu deaktivieren, und setzte mehrere Erpresserbriefe ein, um den Druck auf das Opfer zu erhöhen. Der Eindringling entwickelte sich über mehrere Wochen im August, mit einer bemerkenswerten Pause zwischen dem anfänglichen Zugriff und der endgültigen Ransomware-Bereitstellung.

Untersuchung

Huntress-Analysten rekonstruierten den Einbruch mithilfe von Rest-EDR-Telemetrie und Windows-Ereignisprotokollen, nachdem das Ransomware-Ereignis bereits stattgefunden hatte. Die Untersuchung deckte eine frühe Phase mit verschleierten PowerShell-Implantaten und lateraler Bewegung über RDP auf, gefolgt von einer späteren Phase mit AnyDesk und einem BYOVD-Angriff. Analysten identifizierten spezifische geplante Aufgaben, umbenannte ausführbare Dateien und den anfälligen Treiber, der verwendet wurde, um den EDR/AV-Killer zu aktivieren.

Minderung

Organisationen sollten Remote-Zugriffstools einschränken und eng überwachen, während sie Multi-Faktor-Authentifizierung (MFA) für alle privilegierten Konten durchsetzen. Selbstsignierte oder unerwartete Treiberdienste zu blockieren und verdächtige geplante Aufgaben zu überwachen, sind wichtige Verteidigungsmaßnahmen. Es ist auch wichtig, getestete Offline-Backups und einen gut eingeübten Incident-Response-Plan für eine schnelle Eindämmung zu pflegen.

Reaktion

Wenn INC-Ransomware-Aktivität erkannt wird, sollten betroffene Endpunkte sofort isoliert werden, um weitere laterale Bewegungen zu verhindern. Responder sollten nicht autorisierte Remote-Verwaltungstools wie AnyDesk identifizieren und beenden sowie neu installierte oder verdächtige Kernel-Modus-Treiber untersuchen. Geplante Aufgaben sollten auch auf Persistenz überprüft werden, während kompromittierte Benutzerkonten auf nicht autorisierte RDP-Sitzungen überprüft werden sollten.

Simulationsausführung

• Angriffsnarrative & Befehle: Der Angreifer zielt darauf ab, Persistenz zu erreichen oder Privilegien durch Sideloading einer bösartigen DLL zu eskalieren. Um die Erkennung durch grundlegende Datei-Integritätsmonitore zu vermeiden, wählen sie ein häufig übersehenes, aber global beschreibbares Verzeichnis: C:UsersPublic. Der Angreifer wird zuerst eine Dummy-DLL in diesem Pfad ablegen und dann ein PowerShell-Skript verwenden, um das Laden dieses Moduls in einen neuen Prozess auszulösen, wobei die Ausführung einer bösartigen Nutzlast simuliert wird, die darauf ausgelegt ist, die standardmäßige Überprüfung auf Benutzerprofilbasis zu umgehen.

• Regressionstest-Skript:

  # 1. Pfade definieren
  $targetDir = "C:UsersPublic"
  $dllName = "malicious_sim.dll"
  $dllPath = Join-Path $targetDir $dllName
  
  # 2. Erstelle eine Dummy-DLL-Datei (mit einem kleinen Byte-Array zur Simulation einer Datei)
  # In einem realen Szenario wäre dies eine kompilierte DLL.
  $dummyContent = [byte[]](0x4D, 0x5A, 0x90, 0x00, 0x03, 0x00, 0x00, 0x00) # MZ Header
  [System.IO.File]::WriteAllBytes($dllPath, $dummyContent)
  
  Write-Host "[+] Dummy-DLL wurde bei $dllPath erstellt"
  
  # 3. Simuliere das Laden der DLL über PowerShell
  # Dies löst das Sysmon-Ereignis ID 7 aus
  try {
      Write-Host "[+] Versuch, die DLL zu laden..."
      Write-Host "[+] DLL erfolgreich geladen (Simulation vollständig)."
  }
  catch {
      Write-Host "[-] DLL-Laden fehlgeschlagen (Erwartet, wenn Datei kein gültiges PE ist): $($_.Exception.Message)"
  }

• Bereinigungskommandos:

  # Entferne die simulierte bösartige Datei
  $dllPath = "C:UsersPublicmalicious_sim.dll"
  if (Test-Path $dllPath) {
      Remove-Item -Path $dllPath -Force
      Write-Host "[+] Bereinigung: $dllPath entfernt"
  } else {
      Write-Host "[-] Bereinigung: Datei nicht gefunden."
  }