Stop Fileless Malware & PowerShell Attacks

A script ran on the machine. It lived for two seconds, loaded a payload into memory, executed it, and vanished. There was never a file to find, never a hash to publish, and never anything for a traditional antivirus to quarantine. That two-second window is how a growing share of breaches begin.

This is the world of fileless malware — attacks that exploit the scripts and tools Windows already trusts. To understand what it is, how it works, and how to actually stop PowerShell attacks, you have to stop thinking of malware as something you download. The most dangerous payloads today are something you never see at all.

What is fileless malware, exactly?

Fileless malware is an attack that does not store its malicious code as an executable file on disk. Instead it operates in states a file scanner cannot reach:

• In memory. Shellcode is loaded directly into the address space of a legitimate process and executed from RAM.
• In scripts. PowerShell, VBScript, JScript and macros run the payload as code, using the engine that is already installed and trusted.
• In the registry and WMI. Payloads are stored in registry values, in WMI class properties or in scheduled-task definitions — not in .exe files.

Because nothing suspicious ever lands on disk, the detection logic that defined antivirus for two decades — “scan the filesystem and match signatures” — has nothing to look at. The malware works, the machine behaves, and the console reports a clean bill of health.

The delivery chain: how a fileless attack runs

Fileless attacks are rarely one step. They are a chain of small, individually innocent actions:

1. Entry. A spear-phish document, a poisoned macro, a cracked tool or an exposed service provides the first foothold.
2. Script. PowerShell or WMI is used to pull the next stage — very often from a URL, using built-in web capabilities.
3. In-memory execution. The payload is reflected into memory of a running process or loaded via .NET. No drop-to-disk, no execution of a new file.
4. Persistence without files. The tool registers a Run key, a WMI event consumer or a scheduled task so the recollection survives a reboot.

Every step is visible to the right telemetry — but only to telemetry that watches behavior, not files.

Notice something important about the chain: no single action is obviously malicious in isolation. A document spawning a script is normal office traffic. A process making an HTTP request is normal software behavior. Even a scheduled task can look like routine maintenance. The chain becomes obviously dangerous only when the events are correlated — a script process, spawned by a document, that allocates executable memory and registers a new auto-start in the same ninety seconds. That is the sequence, and sequences are what fileless detection scores.

AMSI: how Windows was supposed to close the window

Microsoft’s answer is the Anti-Malware Scan Interface. AMSI asks the script engines — PowerShell, VBScript, Office and more — to hand every script buffer to registered security providers before and during execution. Instead of waiting for a file, the scanner sees the actual content the engine is about to run, including obfuscated content after it is de-obfuscated.

That is genuinely powerful. Your antivirus or EDR registers as an AMSI provider and receives the plain-text script; if it looks malicious, the buffer is blocked before a single command executes. AMSI is why modern malware bothers to check for its presence before running.

AMSI bypass prevention: what attackers do

Attackers fight back, typically in three ways:

• Memory patching. Modifying the AMSI runtime functions in memory so they skip content scans — a classic reason a scanner that only trusts AMSI can be defeated by the payload itself.
• Abusing the plumbing. Manipulating the interfaces or registry values that a provider relies on, so the scanning step is silently skipped.
• Scoring evasion. Splitting or lightly transforming script content so the buffer given to the scanner differs from the buffer that actually executes.

The lesson: AMSI is a doorway, not the whole defense. The defense has to watch the door — and the room.

What stops fileless malware: behavior over files

Detection that survives AMSI bypasses does not depend on a single buffer. It correlates the whole sequence — a script process is created, the script tries to patch a security function, the process allocates memory with write-then-execute permissions, a remote thread appears in an unrelated process. Each event alone is ambiguous; the sequence is not.

On Windows the right view comes from two layers working together:

• ETW provides the raw operational telemetry — process creation, memory allocation and thread injection straight from the kernel tracing subsystem.
• AMSI provides the script content itself, flagged before execution so the EDR can both block it and enrich its behavioral picture.

This ETW + AMSI pairing is the design at the heart of MalwareProof’s Real-Time Autorun Shield on Windows. The agent consumes kernel telemetry locally, sees the memory-patch and injection indicators that a signature engine cannot, and blocks the script before it runs. Fileless malware removal, in practice, becomes prevention: there is nothing to clean up, because the sequence was stopped at event one.

What you can do today

1. Constrain the script engines. Enable Constrained Language Mode where you can, restrict PowerShell from the network, and require script-signing in admin contexts.
2. Watch what parents spawn. Office spawning PowerShell, or PowerShell spawning nothing it should — legitimacy checks kill most chains early.
3. Use an EDR with AMSI registration and kernel monitoring. A real advanced threat protection stack watches the buffer and the behavior, so bypass attempts become signals instead of blind spots.

FAQ

Next in the field notes: why legacy AV fails against these attacks, hidden crypto miners on your PC and Windows malware protection in practice.