What Is Fileless Malware?

The antivirus scan comes back clean, and the machine is still talking to a server it has no business knowing. Nothing on the disk looks wrong, because nothing on the disk is the attack. That is fileless malware: code that runs from memory and borrowed system tools instead of a file a scanner can hash.

What Fileless Malware Means

Microsoft's own definition starts with a caveat: "there's no one definition for fileless malware." The term covers any attack where the malicious part never sits on disk as a file you could scan, delete or quarantine. The payload lives in RAM, in the registry, in a WMI database entry, or in a command line, and it runs inside a program Windows already trusts.

Microsoft sorts fileless threats into three types by how much they touch the file system. Type I never writes a file at all, like a network exploit that plants a backdoor in kernel memory. Type II uses files only indirectly, like a PowerShell command stored in the WMI repository. Type III still needs a file to get going, but the file is junk and the real work happens elsewhere, which is how the Kovter family used a registry key and a script to run through mshta.exe.

In practice, the attacks a small IT team meets are Type II and Type III. They start with a click, and they end with a script that runs in memory. That makes fileless malware a subset of malware in general, one that is defined by where it hides rather than what it steals.

How a Fileless Attack Runs

The chain is short, and each step uses a component Windows ships with. A phishing email or a fake CAPTCHA page gets the user to run something. That something is a one-line launcher: a script host such as wscript.exe or mshta.exe, or a PowerShell command with an encoded argument. The launcher pulls the next stage from a remote server straight into memory and runs it there. No installer, no .exe in Downloads, no file for the scanner to open.

Trellix documented a chain like this in March 2026: a Remcos remote-access trojan delivered through phishing, staged in several steps, and executed as memory-resident code. The tooling was ordinary. The lure was ordinary. The only unusual part was that nothing landed on disk for long enough to matter.

The numbers say this is now the norm rather than the exception. CrowdStrike's 2026 Global Threat Report counts 82% of the detections it saw in 2025 as malware-free, meaning no malicious file was involved. Red Canary's 2026 Threat Detection Report puts PowerShell second among all techniques, seen in 19.6% of its customers' environments, because, in the report's words, PowerShell's "versatility and ubiquitousness minimize the need for adversaries to customize payloads or download overtly malicious tools on a target system."

Living Off the Land: The Tools It Borrows

Security teams call this living off the land. The attacker doesn't bring tools, they use yours. The LOLBAS project catalogues the Windows binaries, scripts and libraries that can be turned to that purpose, and the list runs past 200 entries: PowerShell, mshta.exe, rundll32.exe, regsvr32.exe, msiexec.exe, certutil.exe and the rest. MITRE ATT&CK tracks the same idea as System Binary Proxy Execution, technique T1218, with 14 sub-techniques for individual binaries.

Every one of those files is signed by Microsoft and present on every Windows machine. An allowlist that trusts signed Microsoft binaries trusts all of them. Microsoft's own fileless threats page makes the point: scripts run inside interpreters such as wscript.exe and powershell.exe, "a clean and legitimate component," so there is no binary for an antivirus to condemn.

In February 2024, CISA, the NSA, the FBI and their Five Eyes partners published joint guidance on living off the land techniques, prompted by the Volt Typhoon intrusions into US critical infrastructure. Their assessment is blunt: "Many organizations do not implement security best practice capabilities that support detection of living off the land (LOTL), so this technique continues to be effective with little to no investment in tooling by malicious cyber actors." The tooling is free. The defence is configuration.

Where It Hides Between Reboots

Memory is wiped on restart, so fileless malware needs a way back in. It has three favourites, and none of them is a file in the usual sense.

The registry can hold a script as a value, with an autorun key or a file-type handler that feeds it to a script host at logon. Kovter used a random file extension and a registry verb, so opening a junk file triggered mshta.exe with a script read from another key. Scheduled tasks can carry an encoded PowerShell command in the task action itself. And the WMI repository can store an event filter, a consumer and a binding, so that a chosen event, such as a time of day or a process start, runs a command through WmiPrvSE.exe with SYSTEM rights. MITRE tracks that last one as T1546.003, and lists APT29, Turla and the POSHSPY backdoor among its users.

All three survive a reboot. None of them shows up as a new program in Add or Remove Programs. Remove the memory-resident payload and it comes back at the next trigger, which is why cleaning a trojan infection means finding the persistence, not only killing the process.

Why Signature Scanning Misses It

A classic scanner works on files. It hashes them, compares the hash to a list of known bad files, and looks for byte patterns inside. Fileless malware gives it nothing to hash. The launcher is a legitimate Windows binary, the script is encoded or obfuscated, and the payload only exists as bytes in a process's memory.

Obfuscation is cheap. A PowerShell command can be Base64-encoded with the -EncodedCommand switch, split into string fragments, or padded with characters that mean nothing to the interpreter. Each variation defeats a pattern that matched the last one. Microsoft's engineers put it well back in 2018: "a script can hide its code, but it cannot hide its behavior."

That line is the whole defence strategy. The interpreter has to decode the script before it runs it, and the payload has to make the same API calls whatever it looked like on the way in. Modern antivirus software adds behaviour monitoring and memory scanning for exactly this reason, and Windows exposes the decoded script to it through AMSI, the Antimalware Scan Interface. AMSI hooks PowerShell, Windows Script Host, JScript, VBScript and Office VBA macros, and hands the content to whatever antimalware engine is registered at the moment it runs.

How to Detect Fileless Malware

You can't detect what you don't log, and the default Windows install logs almost none of this. Four switches change that, and three of them are free.

Turn on PowerShell script block logging. Group Policy has it under Administrative Templates as "Turn on PowerShell Script Block Logging," and the registry key is EnableScriptBlockLogging under HKLM\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging. Once enabled, every script block PowerShell processes is written to the Microsoft-Windows-PowerShell/Operational log as event 4104, decoded, whatever obfuscation wrapped it. Add module logging for the pipeline detail. Microsoft recommends pairing both with protected event logging, since a logged script can contain a credential.

This r/sysadmin thread from September 2025 is the usual starting point: the poster had module and script block logging on and wanted to know who ran what and when. The replies are worth reading for the edge cases, from users pasting scripts straight into a PowerShell window to scripts with passwords hard-coded in them.

Install Sysmon. It's a free Microsoft tool that logs process creation with the full command line and the parent process (event 1), network connections (event 3), threads injected into other processes (event 8), and the three WMI events that catch persistence being planted: filter (19), consumer (20) and binding (21). Event 25 flags process hollowing. With Sysmon and script block logging feeding a log management pipeline, the hunt becomes a set of searches.

The searches themselves are well known. Red Canary's detection guidance lists the ones that keep paying: PowerShell launched with any spelling of -EncodedCommand, Base64 blobs on a command line, commands heavy in ^ + $ and % characters, cmdlets like Invoke-Expression, iex and .DownloadString, and script hosts started by Outlook, Word, a browser or a PDF reader. Any of those with a network connection right after is a ticket. If you run PowerShell across a fleet, our PowerShell commands guide covers the queries; OpenFrame can run the same Get-WinEvent query as a script across a client's devices and collect the output, so you see which machines are logging encoded commands at all.

Hardening That Shrinks the Surface

Detection tells you it happened. Hardening makes it harder to happen, and MITRE's mitigations for PowerShell abuse read like a checklist for a small team. Put PowerShell into Constrained Language Mode for standard users, so scripts can't reach the .NET methods most payloads depend on. Enforce signed scripts through the execution policy, knowing it's a guardrail rather than a wall. Remove PowerShell 2.0, which predates all of this logging. Use application control to block mshta.exe, wscript.exe and cscript.exe for users who never need them.

Block Office macros from the internet, which Microsoft now does by default, and keep it that way. Give admins Just Enough Administration endpoints instead of a full remote shell. And answer the question the r/sysadmin thread kept circling back to: does a standard user need to run scripts at all? One reply had a Group Policy that disables script execution for non-admins. For plenty of desks, that is the right default.

The r/blueteamsec community posts the fresh research as it lands. This thread from March 2026 links the Trellix write-up of the Remcos chain above, and it is a good habit to follow the subreddit for the next one.

For a five-minute version of the whole problem, Archer's Cybersecurity 101 episode on fileless malware covers the idea without the jargon:

Fileless Malware, in Short

Fileless malware is an attack that runs from memory and borrowed Windows tools, so a file scanner has nothing to find. It gets in through a click, runs through PowerShell or a script host, and survives reboots in the registry, a scheduled task or a WMI subscription. Signatures miss it; behaviour, logs and AMSI catch it.

Start with the free switches: script block logging, Sysmon and the handful of saved searches for encoded commands. Then take the tools away from the users who don't need them. If a search turns something up, our incident response guide covers what to do in the first hour.

And if nothing has turned up yet, the threat hunting guide covers how to go looking before an alert does.