What Is Fileless Malware?

Fileless malware operates without writing a malicious executable to disk. It runs in memory, or uses tooling already present on the system, which means file-based scanning has nothing to examine.

It is not a niche technique. A large share of serious intrusions now involve little or no distinctive malicious file, which is the reason endpoint security shifted from scanning to behavioural monitoring.

The techniques

Script execution in memory, where an interpreter already installed runs code retrieved from elsewhere and never saved. Code injection into a legitimate running process, so the malicious activity appears under a trusted name.

Persistence in configuration rather than files — registry entries, scheduled tasks, management subscriptions. And abuse of built-in administrative tooling, which is living off the land.

Why detection has to change shape

There is no hash to match and no file to quarantine. What remains is behaviour: which process started which, with what command line, reaching which destination.

A document process spawning a scripting engine that makes an outbound connection is anomalous regardless of what files exist. The command line is frequently the single most informative artefact, and it exists only in process telemetry.

Logging is the precondition

Script block logging, which records what a script actually executed after any obfuscation is resolved. Process creation logging including full command lines. Module loading events.

None of these are on by default at useful verbosity in most estates. Without them the activity is not merely undetected but unreconstructable afterwards, which turns an investigation into guesswork. See security logging.

Persistence without files

Because there is no executable, persistence lives in configuration: a scheduled task that downloads and runs code, a registry value containing an encoded script, a management subscription that triggers on an event.

That is why eradication requires more than removing a file. Reviewing scheduled tasks, startup entries and management subscriptions is a necessary step, and one that is routinely omitted.

Investigation depends on volatile evidence

Since the payload exists in memory, powering the machine off destroys the primary evidence. Isolate the network and capture memory before doing anything else — see memory forensics.

This is the specific reason the general advice against powering off a suspect system matters so much: for this category, the machine holds the only copy of the thing you are investigating.

Constraining the interpreters themselves

Much of this category depends on scripting engines and management frameworks already present on the system. Those can be constrained rather than merely monitored: restricted execution modes that limit what a script may do, signing requirements for scripts, and removing or blocking interpreters that have no business being on a given system.

A workstation that has no legitimate need for a scripting engine or a remote management framework is considerably harder to operate in. That is a hardening decision rather than a detection one, and it is available on most platforms already.

Where to start

Turn on process creation logging with command lines, and script block logging. Without those two, this entire category is invisible to you both live and retrospectively.

See living off the land. GuardsArm delivers managed detection and response.