What Is Fileless Malware?

An incident responder pulls the disk image of a host that is clearly compromised, it is beaconing to a known-bad address every few minutes, and starts hunting for the malware. There is no malicious executable. No suspicious file dropped in a temp folder, no new program installed, nothing the antivirus flagged, nothing that looks out of place on disk at all. The disk is clean. The compromise is real, the malware is running, but it was never a file. It is living in memory, launched by a PowerShell command stored in a registry value, using a program Windows ships with. Searching the disk for it was always going to come up empty. That is the entire point of fileless malware.

Fileless malware is malicious code that operates primarily in memory and abuses legitimate, trusted system tools rather than dropping its own executable on disk. By avoiding the file that traditional defenses are built to scan, it sidesteps signature-based antivirus and leaves far less for disk forensics to find. It is not magic, it still has to run somewhere, but it deliberately runs in the places defenders look at last.

This guide covers what fileless malware is, how it works, the living-off-the-land technique behind it, why it evades traditional antivirus, how it compares to file-based malware, and how defenders actually detect and prevent it. It is written for blue teamers who have to catch an attack that refuses to leave a file behind.

What is fileless malware?

Fileless malware is a class of attack that achieves its goals while writing little or nothing to disk, executing in memory and operating through tools and features already present on the system. The name is slightly misleading: there is often a file somewhere in the chain (a malicious document, a script), and "fileless" really means "no traditional malware executable for antivirus to catch." The defining trait is the absence of the persistent malicious binary that file-based defenses are designed to find.

Instead of bringing its own program, fileless malware borrows the system's. It uses the legitimate, signed, trusted utilities that ship with the operating system, PowerShell, Windows Management Instrumentation (WMI), the scripting host, and others, to do its work. Because those tools are supposed to be there and are supposed to run, their activity blends into normal administration. The malware is not a foreign object on the system; it is the system's own tools turned against it.

This is why fileless techniques have become so common in serious intrusions and a frequent focus of malware analysis work. They raise the cost of detection dramatically: there is no file to hash, no signature to match, and the activity looks, at a glance, like a busy administrator doing their job.

Living off the land

The core idea behind fileless malware has a name: living off the land. An attacker "lives off the land" by using the tools already installed on the target rather than bringing their own, and those tools are called LOLBins (living-off-the-land binaries).

The workhorse is PowerShell. It is powerful, present on every modern Windows host, trusted, and able to download and execute code entirely in memory, which makes it the single most abused tool in fileless attacks. MITRE ATT&CK catalogs this abuse under Command and Scripting Interpreter (T1059), which covers adversaries using PowerShell, the Windows command shell, and other interpreters to execute their code. Other common LOLBins include WMI for execution and persistence, mshta and rundll32 and regsvr32 for running code through trusted binaries, and the scripting host for VBScript and JScript.

The reason living off the land works is trust. These binaries are signed by the operating system vendor, allow-listed by default, and used constantly for legitimate administration. A defense that blocks unknown executables does nothing against powershell.exe, because powershell.exe is known and trusted. The attacker's code rides inside a process no one wants to block.

How a fileless attack works

A typical fileless intrusion follows a recognizable chain, even though it leaves little on disk.

1. Delivery. The entry point is often a phishing email with a malicious document or link. The document contains a macro or script, not an attached executable.
2. Execution via a trusted tool. When the victim enables the macro, it launches a LOLBin, commonly PowerShell, with an encoded command. No malware file is written; the instructions are passed directly to the interpreter.
3. In-memory payload. That command downloads the actual payload and runs it directly in memory, reflectively loading code into a running process so it never touches the filesystem as an executable.
4. Action and persistence. From memory, the malware does its work, establishing command-and-control, stealing credentials, moving laterally, and it often establishes persistence in a fileless way too: a WMI event subscription or a registry value that re-launches the PowerShell loader on boot or logon.

The result is the scenario from the opener: a fully functional compromise whose only on-disk traces might be a benign-looking document and a registry value containing an encoded script, with the actual malicious code existing only in RAM. Reboot the machine and the in-memory payload is gone, which is precisely why the registry or WMI persistence is there to bring it back.

Why fileless malware evades antivirus

Traditional antivirus is built around a file: it scans files on disk, matches them against signatures of known malware, and quarantines the ones that match. Fileless malware breaks every assumption in that model.

There is no file to scan. The payload lives in memory, not on disk, so a file-scanning engine has nothing to examine. The malicious logic never exists as a file it can hash or quarantine.

The tools it uses are trusted. Even when the activity is visible, it is powershell.exe or wmic.exe doing it, signed Microsoft binaries that no allow-list blocks and no signature flags. The malware hides inside legitimacy.

Its on-disk traces are not executables. A macro-enabled document and an encoded registry value do not look like malware to a signature scanner, and may be individually benign. The maliciousness is in the behavior, not in any single artifact.

Memory-only code disappears on reboot. Because the payload is in RAM, it can vanish without a trace when the system restarts, which complicates both detection and forensic recovery unless memory was captured while the system was live.

The takeaway is that catching fileless malware requires watching behavior, not files. The detection signal is not "this file is bad" but "this trusted tool is doing something it should not."

Fileless vs. traditional malware

The two are not entirely separate categories, many real attacks blend them, but the contrast clarifies what is different.

The practical lesson: defenses and investigations tuned for file-based malware (disk scanning, file hashing) are exactly the ones fileless techniques are designed to defeat, which is why the detection toolkit has to shift toward behavior and memory.

How to detect fileless malware

Because there is no file to find, detection means watching how trusted tools behave and capturing the evidence they leave in places other than the disk.

• Log and inspect command lines. The single highest-value source. A PowerShell process launched with an encoded command, a hidden window, and a download cradle is a strong signal even though no file is involved. Process-creation logging that captures full command lines is essential.
• Enable PowerShell script block logging. This records the actual script content PowerShell executes, including deobfuscated code, turning the most-abused LOLBin from a blind spot into a rich detection source.
• Watch process lineage and behavior. A document opening a command shell, an office application spawning PowerShell, or rundll32 making network connections are behavioral anomalies. Endpoint detection and response tooling is built to flag exactly these parent-child and behavioral patterns that signature antivirus misses.
• Do memory forensics. Because the payload lives in RAM, analyzing a memory image is often the only way to recover it. Tools like Volatility let an analyst pull malicious processes, injected code, and command lines from a memory capture, which is the core skill for investigating these attacks.
• Monitor fileless persistence locations. WMI event subscriptions and registry values holding encoded scripts are favored persistence spots; baselining and watching them catches the mechanism that survives reboot.

The unifying principle is behavioral: capture what processes do and how they relate, not just what files exist, and the fileless attack that was invisible to the disk scan becomes visible in the command line and the memory image. These traces also become the indicators of compromise that drive the rest of an investigation.

How to prevent fileless malware

Prevention focuses on constraining the trusted tools that fileless attacks abuse and reducing the entry points that deliver them.

• Constrain PowerShell. Use Constrained Language Mode, application control, and execution policies to limit what PowerShell can do, and log everything it does. The goal is to keep legitimate administrative use while making malicious use hard and noisy.
• Reduce the attack surface. Disable or restrict scripting tools and macros where they are not needed. Blocking Office macros from the internet removes one of the most common delivery routes in a single step.
• Enforce least privilege. Fileless attacks still benefit from elevated rights for persistence and lateral movement; limiting privileges contains what a compromise can achieve.
• Patch and harden. Keep systems patched so attackers cannot pair fileless execution with an exploit, and remove or restrict LOLBins that the environment does not legitimately need.
• Keep memory and logs available. Ensure command-line and script logging is on and centralized, and that memory can be captured during response, because these are the only places the evidence lives.

Layered, these do not make fileless attacks impossible, but they shrink the tools available, raise the noise the attacker generates, and ensure that when one gets through, you can actually see it.

Getting started with fileless malware analysis

If you want to build the skill, learn to investigate where fileless malware actually lives: memory and behavioral logs.

1. Learn the LOLBins. Understand what PowerShell, WMI, mshta, rundll32, and regsvr32 legitimately do, so you can recognize when their use is not legitimate.
2. Read command lines and script logs. Practice spotting encoded commands, download cradles, and obfuscation in process-creation and PowerShell logs. Most fileless detection lives here.
3. Do memory forensics. Learn Volatility and practice pulling malicious processes, injected code, and command lines from a memory image.
4. Trace a full chain. Follow an attack from a malicious document through a LOLBin to an in-memory payload and its persistence, so the whole pattern is familiar.

The bottom line

Fileless malware is the attacker's answer to file-scanning defenses: run in memory, abuse the trusted tools the system already has, and leave almost nothing on disk to find. It works by living off the land, using PowerShell and other signed, allow-listed binaries to execute and persist, so there is no malicious file to hash and the activity looks like administration. That defeats traditional antivirus and disk forensics entirely, which is why catching it means shifting to behavior: full command-line logging, PowerShell script block logging, process-lineage analysis, and memory forensics. The malware that leaves nothing on disk still leaves itself in memory and in the logs of the tools it abused. The defender who looks there, instead of at the disk, is the one who finds it.