How do fileless malware attacks work and how do you detect them?

Fileless malware avoids writing a conventional executable to disk. It runs inside memory, or it abuses tools already on the system, such as PowerShell and Windows Management Instrumentation. Because no new file exists to scan, defenders detect it through behaviour, script logging and restrictions on which tools may run.

What does fileless actually mean?

The word is loose. Very little attack code is truly without files: there is usually a document, a link or a script that starts the chain. "Fileless" describes the stage where the harmful payload runs without a normal program file on disk to inspect.

MITRE ATT&CK has no single "fileless" technique. Instead it documents the building blocks, and three of them show the pattern.

Which techniques make it work?

Scripting engines. T1059.001 describes adversaries abusing PowerShell, a command line and scripting environment included in Windows. ATT&CK notes it can be used to download and run executables from the internet, which can run from disk or in memory without touching disk. It can also be invoked without calling the powershell.exe binary, through interfaces to its underlying .NET assembly.

Reflective code loading. T1620 describes loading code into a process by allocating memory and executing a payload directly inside the process, instead of creating a thread or process backed by a file path on disk. The payload can be position-independent code that exists only in memory.

WMI event subscriptions. T1546.003 describes using Windows Management Instrumentation to install event filters and consumers that run code when an event occurs, such as a login or a time. This gives persistence without a startup file in the usual places.

ATT&CK also lists Process Injection (T1055) and System Binary Proxy Execution (T1218), where trusted system programs are used to run attacker content.

Why do signature scanners struggle?

A file scanner needs a file. In-memory payloads and script text give it little to match, and the programs involved are signed, legitimate parts of the operating system. Blocking PowerShell outright would break administration, so defenders need rules about how it is used, not whether it exists.

What does a constructed example look like?

A user opens an email attachment that runs a short script. The script launches PowerShell with a long, encoded argument. PowerShell downloads a payload and loads it directly into memory. Later, a WMI subscription is created so the same script reruns after each reboot. At no point did a new executable land in the downloads folder.

The signals are in the sequence: an Office application starting a script engine, an unusual command line, a new WMI subscription on a workstation that has never had one.

What controls help?

• Script logging. Turn on PowerShell script block logging and module logging, and forward the logs to a store the attacker cannot reach from the host.
• Constrained use. Limit PowerShell to those who need it, and use application allowlisting where practical. CISA's DarkSide advisory lists allowlisting and disabling Office macros as mitigations for unauthorised execution.
• Behaviour monitoring. Alert on parent-child process chains such as a document spawning a shell.
• Patch the entry points. Many chains start with an exploited application or a malicious document.
• Review WMI persistence. Periodically list event subscriptions and investigate unknown ones.

How to check or apply this

1. Confirm script block logging is enabled on a sample of Windows machines, and that the events reach central storage.
2. List who can run PowerShell and remove it where nobody needs it.
3. Disable macros in files from the internet by policy.
4. Query a few endpoints for WMI event consumers and record what is normal.
5. Write two detections: Office app starting a script engine, and a script engine making an outbound connection.
6. Run a harmless test, such as a benign script launched from a document, and confirm your tooling raises it.

Quick check

Sources

• MITRE ATT&CK T1059.001, PowerShell
• MITRE ATT&CK T1620, Reflective Code Loading
• MITRE ATT&CK T1546.003, WMI Event Subscription
• MITRE ATT&CK T1055, Process Injection
• MITRE ATT&CK T1218, System Binary Proxy Execution
• CISA AA21-131A

Last reviewed: 18 October 2026.