A fileless attack executes through software already installed and trusted on the system, leaving no malicious file for a scanner to find. It runs in memory, through scripting engines and signed system binaries. Detecting it requires evaluating what a legitimate process is doing rather than looking for a malicious artifact, because there is no artifact.
What fileless actually means
The name is slightly misleading and it causes confusion. Fileless attacks do involve files. What they avoid is dropping a malicious executable that a scanner can identify.
The attacker uses what is already there. PowerShell, Windows Management Instrumentation, the .NET runtime, rundll32, regsvr32, mshta, certutil. These are signed by Microsoft, present by default, and used constantly for legitimate work. Security teams call them living-off-the-land binaries.
Execution typically follows one of three shapes.
- Script-based. A PowerShell or WMI command downloads and executes a payload directly in memory, never writing it to disk.
- Injected. Code is written into the memory space of a running trusted process, so what executes belongs to a legitimate binary.
- Persisted in configuration. The payload lives in a registry key, a WMI event subscription or a scheduled task rather than in a file, and a trusted binary reads and executes it.
Why it evades signature-based detection
Signature matching is built around an artifact. Hash the file, compare the hash, match a pattern in the file contents. It works well, which is why attackers moved away from providing a file to hash.
When the executing binary is powershell.exe, signed by Microsoft and present on every Windows host, there is nothing to blocklist. Blocking the binary breaks administration. Allowing it permits the attack. Application allowlisting hits the same wall for the same reason, and this is exactly why containment features that restrict what an allowed application may do exist in that category.
Behavioral detection does better here and is the right tool for a large share of these attacks. It watches for suspicious sequences: a document spawning a shell, an encoded command line, an unusual parent-child process relationship. The structural limit is that the sequence has to be recognized as suspicious, and the space of legitimate uses of PowerShell in a large enterprise is enormous. Tuning that boundary is where most of the operational cost of behavioral detection lives.
The part that is not fileless
Here is what gets lost in the framing. An attack that achieves nothing is not an attack. Fileless execution is a delivery technique, not an outcome.
To produce impact, the attacker eventually has to do something that persists or spreads. Encrypt files. Modify a service. Write a registry key for persistence. Create a scheduled task. Alter a configuration. Move to another host.
Purely in-memory activity that touches nothing and leaves nothing accomplishes nothing beyond reconnaissance. The moment it converts to impact, it makes a change to the system, and that change is as visible as any other change. Two of those outcomes have explainers of their own: ransomware defense covers encryption at scale, and how attackers move laterally covers the move to another host.
What known-good behavior boundaries catch
The question that resolves this is not what the process is, but whether what it just did falls inside what that process does on this system in normal operation.
PowerShell running an administrative script that this server runs every night is inside the boundary. PowerShell writing a new binary to a system directory and registering it as a service is outside it, and the signature of the executing binary is irrelevant to that determination.
This is why fileless techniques, which are specifically designed to defeat artifact-based detection, do not defeat a control that never looked for an artifact.
Mimic profiles each protected system in its authorized state and evaluates changes at the kernel against that baseline, so a trusted process making an unauthorized change is stopped on the same basis as an untrusted one. The broader point holds regardless of tooling: if your defense against fileless attacks depends on identifying something malicious, you are defending against a technique built to give you nothing to identify.
Fileless attacks, answered.
What is a fileless attack?
+A fileless attack executes through software already installed and trusted on the system rather than dropping a malicious executable. It typically runs in memory using scripting engines and signed system binaries such as PowerShell, WMI or rundll32. Because there is no malicious file to scan, artifact-based detection has nothing to match against.
Are fileless attacks really fileless?
+Not literally. They involve files, including the legitimate signed binaries that execute them and often a registry key or scheduled task holding the payload. What they avoid is dropping a malicious executable that a scanner can hash and identify. The name describes the evasion technique rather than a complete absence of files.
Why can antivirus not detect fileless malware?
+Signature matching requires an artifact to compare against a known-bad pattern. When execution happens through a Microsoft-signed binary present on every host, there is no malicious file to hash and no binary that can be blocklisted without breaking legitimate administration. The evasion is structural rather than a gap in any particular product.
What are living-off-the-land binaries?
+Legitimate system tools that attackers repurpose, including PowerShell, WMI, rundll32, regsvr32, mshta and certutil. They are signed, present by default and used constantly for real administrative work, which means both blocking them and permitting them carry a cost. This is why the question shifts from whether the tool ran to what it did.
Does EDR stop fileless attacks?
+Behavioral detection catches a substantial share of them by recognizing suspicious sequences such as a document spawning a shell or an unusually encoded command line. The structural limit is that the sequence must be recognized as suspicious, and legitimate scripting activity in a large enterprise is varied enough that the boundary requires continuous tuning.
How do you stop an attack that uses only trusted tools?
+By evaluating what the trusted tool did rather than whether the tool is trusted. A fileless attack still has to produce impact, and impact requires a change: encrypting files, writing a registry key, creating a service, altering configuration. Comparing that change against the system’s authorized operating state resolves without needing to identify anything as malicious.
