OysterLoader Enthüllt: Einblick in einen Mehrstufigen Tarnlader

Zusammenfassung

OysterLoader ist ein C++-Multi-Stage-Loader, der verwendet wird, um Ransomware und generische Malware wie Vidar bereitzustellen. Er verbreitet sich über kompromittierte Websites, die legitime Softwareinstallationsprogramme imitieren, und wird als Microsoft Installer (MSI) geliefert. Um die Analyse zu erschweren, verwendet er API-Call-Flooding, eine benutzerdefinierte dynamische API-Auflösung, Anti-Debug-Checks und eine benutzerdefinierte LZMA-Dekomprimierungsroutine. Der Loader kommuniziert mit einer gestaffelten HTTPS C2-Infrastruktur unter Verwendung verschleierter HTTP-Header und einer proprietären Base64-ähnlichen Kodierung.

Untersuchung

Der Bericht skizziert vier Stufen: einen gepackten Verschleierer (TextShell), eine Shellcode-Ebene, die Inhalte mit LZMA entpackt, einen Downloader, der Umgebungsprüfungen durchführt und ein Mutex erstellt, und eine letzte Phase, die eine DLL ablegt und eine geplante Aufgabe installiert. C2-Kommunikation basiert auf fest codierten IPs/Domains, benutzerdefinierten User-Agents und steganografischer Payload-Übertragung über PNG-Icons. Persistenz wird durch eine geplante Aufgabe aufrechterhalten, die alle 13 Minuten ausgeführt wird.

Abschwächung

Blockieren Sie nicht signierte MSI-Installationsprogramme aus unzuverlässigen Quellen und überwachen Sie die Erstellung bekannter Mutex-Muster. Alarmieren Sie bei bekannten Mustern von geplanten Aufgabennamen und der Verwendung von rundll32.exe, um DLLs aus %APPDATA% zu laden. Wo möglich, erzwingen Sie TLS-Inspektion, um die benutzerdefinierten HTTP-Header und User-Agents des Loaders zu identifizieren.

Reaktion

Wenn erkannt, isolieren Sie den Host, beenden Sie die geplante Aufgabe und entfernen Sie die abgelegte Datei COPYING3.dll. Suchen Sie nach zusätzlichen Payloads, listen Sie Prozesse auf, die zu den Mutex-Werten passen, blockieren Sie die aufgelisteten C2-Domains/IPs und aktualisieren Sie die Erkennungen für das Verhalten des API-Floodings und die benutzerdefinierte Base64-Kodierung.

Simulation Ausführung

Voraussetzung: Der Telemetrie & Baseline Pre‑flight Check muss erfolgreich gewesen sein.

Begründung: Dieser Abschnitt beschreibt die präzise Ausführung der gegnerischen Technik (TTP), die zur Auslösung der Erkennungsregel entwickelt wurde. Die Befehle und Erzählungen MÜSSEN die identifizierten TTPs direkt widerspiegeln und darauf abzielen, genau die Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird. Abstrakte oder nicht relevante Beispiele führen zu Fehldiagnosen.

• Angriffserzählung & Befehle:
  Der Gegner, der einen ersten Zugriff auf den Endpunkt erlangt hat, setzt die OysterLoader-Payload ein.

  1. DLL-Registrierung über Rundll32 – Der Loader kopiert eine bösartige DLL (COPYING3.dll) in das temporäre Verzeichnis und registriert sie mit rundll32.exe mit dem DllRegisterServer Einstiegspunkt, was zu einer Befehlszeile führt, die übereinstimmt mit Auswahl1.
  2. Anti-Debug-Prüfung – Um einer Analyse zu entgehen, lädt die Payload ntdll.dll und ruft IsDebuggerPresentauf. Dies erzeugt einen Prozessdatensatz, bei dem Image enthält ntdll.dll und die Befehlszeile enthält IsDebuggerPresent, was mit Auswahl2.
  3. Speicherzuweisung – Für die im Speicher ausgeführte Ausführung ruft der Loader NtAllocateVirtualMemory via ntdll.dllauf. Das daraus resultierende Ereignis der Prozesserstellung enthält NtAllocateVirtualMemory in der Befehlszeile, was mit Auswahl3.

• Regressionstest-Skript:

  # OysterLoader-Erkennungsvalidierungsskript – PowerShell
  # ----------------------------------------------------
  # 1. Erstellen Sie eine Dummy-schädliche DLL (leere Datei zur Simulation)
  $dllPath = "$env:TEMPCOPYING3.dll"
  New-Item -Path $dllPath -ItemType File -Force | Out-Null
  
  # 2. Auswahl1 auslösen – rundll32 mit DllRegisterServer
  Write-Host "Ausführung von Auswahl1 (rundll32 DLL-Registrierung)..."
  Start-Process -FilePath "rundll32.exe" -ArgumentList "`"$dllPath`" DllRegisterServer" -NoNewWindow
  
  # 3. Auswahl2 auslösen – ntdll mit IsDebuggerPresent
  Write-Host "Ausführung von Auswahl2 (IsDebuggerPresent)..."
  $scriptBlock = {
      Add-Type -MemberDefinition @"
          [DllImport("ntdll.dll", SetLastError = true)]
          public static extern bool IsDebuggerPresent();
  "@ -Namespace WinAPI -Name NativeMethods
      [WinAPI.NativeMethods]::IsDebuggerPresent() | Out-Null
  }
  Start-Job -ScriptBlock $scriptBlock | Wait-Job | Receive-Job
  
  # 4. Auswahl3 auslösen – ntdll mit NtAllocateVirtualMemory
  Write-Host "Ausführung von Auswahl3 (NtAllocateVirtualMemory)..."
  $scriptBlock2 = {
      Add-Type -MemberDefinition @"
          [DllImport("ntdll.dll", SetLastError = true)]
          public static extern int NtAllocateVirtualMemory(
              IntPtr ProcessHandle,
              ref IntPtr BaseAddress,
              IntPtr ZeroBits,
              ref UIntPtr RegionSize,
              uint AllocationType,
              uint Protect);
  "@ -Namespace WinAPI -Name NativeMethods
      $process = [System.Diagnostics.Process]::GetCurrentProcess()
      $handle = $process.Handle
      $base = [IntPtr]::Zero
      $size = [UIntPtr]::Zero
      [WinAPI.NativeMethods]::NtAllocateVirtualMemory($handle, [ref]$base, [IntPtr]::Zero, [ref]$size, 0x1000, 0x04) | Out-Null
  }
  Start-Job -ScriptBlock $scriptBlock2 | Wait-Job | Receive-Job
  
  # Bereinigung
  Remove-Item -Path $dllPath -Force
  Write-Host "Simulation abgeschlossen."

• Bereinigung Befehle:

  # Stellen Sie sicher, dass verbliebene rundll32- oder Jobprozesse beendet werden
  Get-Process -Name "rundll32" -ErrorAction SilentlyContinue | Stop-Process -Force
  Get-Job | Remove-Job -Force
  # Löschen Sie die temporäre DLL, falls noch vorhanden
  $tempDll = "$env:TEMPCOPYING3.dll"
  if (Test-Path $tempDll) { Remove-Item $tempDll -Force }