Fileless Malware Guide: Living off the Land, Detection and Prevention

Fileless malware runs in memory, in the registry or through tools the operating system already trusts, so a defence built around scanning files on disk will often see nothing at all. Government agencies including CISA, NSA, the FBI and NCSC-UK published joint guidance on living-off-the-land techniques in February 2024 because state actors used them to stay hidden in critical infrastructure networks for long periods. This guide explains the concept from a defender's point of view, where visibility actually comes from, how to prevent and harden, and how to respond. It is written for SOC analysts, endpoint engineers and incident responders, mainly on Windows estates, with notes for Linux and macOS.

Key takeaways

• Fileless is about where code lives, not how clever it is. The payload sits in process memory, the registry or the WMI repository, and execution is handed to trusted tools such as PowerShell, WMI and signed system binaries.
• File scanning is necessary but not sufficient. Detection shifts to behaviour: script content, command lines, parent and child process relationships, memory telemetry and persistence locations.
• Logging must be switched on before the incident. PowerShell script block logging (event 4104), command-line process auditing (event 4688), Sysmon and WMI activity logging are off or partial by default and cannot be recovered after the fact.
• Application control is the strongest preventive control. App Control for Business (formerly WDAC) restricts what can run and pushes PowerShell into Constrained Language Mode; attack surface reduction rules close specific abuse paths.
• Memory is the evidence. Responders should capture volatile memory before rebooting or reimaging, and treat credentials used on the host as compromised.

How the attack works

Microsoft's security research team describes fileless threats as a spectrum. At one end nothing is ever written to disk; in the middle a file exists only as a trigger (for example a shortcut, a scheduled task or a registry value) that launches an interpreter; at the other end ordinary files are used but the malicious logic runs from memory. Living off the land (LOTL) is the closely related practice of using the administrative tools already present on a system, so that malicious activity looks like routine administration. See the Living off the Land Guide.

At concept level, a fileless intrusion usually combines four building blocks:

• Initial execution through a trusted host: a document macro, script host or exploited service starts a built-in interpreter rather than dropping an executable.
• In-memory code: code is loaded or injected into a running process instead of being installed, which ATT&CK tracks as Process Injection (T1055) and Reflective Code Loading (T1620).
• Non-file storage: configuration or payload data is stored in the registry or other non-file locations (Fileless Storage, T1027.011; Modify Registry, T1112).
• Persistence through system features: WMI event subscriptions (T1546.003), scheduled tasks (T1053.005) or registry autostart values relaunch the chain at boot or logon.

Traditional antivirus inspects files when they are written or opened. If the only files involved are signed Microsoft binaries such as powershell.exe, wmic.exe or rundll32.exe, there is nothing malicious on disk to match, and blocking those binaries outright would break administration. The joint LOTL guidance notes that this activity blends with legitimate behaviour, so defenders need behavioural baselines rather than blanket allow rules for administrative tools.

Where it shows up

• Enterprise intrusions by state actors: the 2024 joint guidance was informed by the response to Volt Typhoon, which relied on built-in tools such as wmic, ntdsutil, netsh and PowerShell rather than custom malware.
• Financially motivated intrusions: Kaspersky reported in 2017 that it had found PowerShell code stored in the registry across more than 100 enterprise networks, with a Meterpreter payload recovered only from the physical memory of a domain controller. Evidence existed only in RAM, network traffic and the registry.
• Commodity malware: Microsoft documented families that kept a PowerShell command in a registry Run key and the payload itself in the registry, and worm-like campaigns that placed a backdoor in kernel memory through an exploited SMB vulnerability.
• Ransomware pre-deployment: discovery, lateral movement and backup tampering are frequently carried out with built-in tools before any encryptor is dropped. See the Ransomware Prevention Guide.
• Linux and macOS: the joint guidance names curl, systemctl and Python on Linux, and osascript and launchctl on macOS.

Impact

Fileless techniques rarely define the end goal; they extend dwell time, which means more credential theft and lateral movement before anyone notices.

• Delayed detection: without behavioural telemetry the first signal may be the business impact itself, such as encryption or a data leak.
• Weak forensic record: a reboot or reimage destroys memory-resident code. If logging was not enabled, investigators may be unable to establish scope, which complicates breach notification decisions.
• Credential exposure: in the Kaspersky cases, attackers harvested credentials from administrator service accounts. Any privileged account that logged on to an affected host must be treated as compromised, and passwords must be changed after cleanup, not before.

Detection

Visibility for fileless activity comes from five sources. None is sufficient alone, and the joint guidance recommends forwarding logs to a centralised, write-once store outside the reach of administrators on the monitored hosts.

PowerShell logging and AMSI

• Script block logging: enable the Group Policy setting "Turn on PowerShell Script Block Logging" (Administrative Templates, Windows Components, Windows PowerShell). It records the content of script blocks as event 4104 in Microsoft-Windows-PowerShell/Operational, including code that was generated at runtime and never touched disk.
• Module logging: "Turn on Module Logging" records pipeline execution details (event 4103) for the modules you specify; use * to cover all modules.
• Protected Event Logging: script blocks can contain secrets. Microsoft documents encrypting them with a CMS certificate so only the log collection tier can decrypt them.
• AMSI: the Antimalware Scan Interface lets PowerShell, Windows Script Host and Office VBA pass content to the installed antimalware product before execution, after de-obfuscation. This is how memory-only scripts can be scanned at all. Alert on any loss of AMSI telemetry from a host. See the PowerShell Security Guide.

Process, WMI and memory telemetry

EDR sensors add what logs cannot: memory scanning of running processes, detection of unbacked executable memory, and process lineage across the whole estate. See the Sysmon Guide and the EDR Guide.

Analytics worth building

• Unusual parent and child pairs: Office applications, browsers or the WMI provider host (WmiPrvSE.exe) spawning interpreters. D3FEND classes this as Process Spawn Analysis (D3-PSA).
• Script content signals: 4104 events flagged at Warning level, very long encoded blocks, or content that downloads and runs code in one step.
• New WMI subscriptions: any Sysmon 19 to 21 event outside a known management tool deserves triage.
• Admin tools out of context: ntdsutil, vssadmin or netsh run by unusual accounts or hosts.
• LSASS access: processes other than known security tooling opening lsass.exe.

Defenders should also expect attempts to blind these sensors. ATT&CK v20 tracks this under Disable or Modify Tools (T1685) and Clear Windows Event Logs (T1685.005); a host that suddenly stops sending telemetry is itself an alert. See the Top 10 EDR Evasion Techniques.

Metrics

• Telemetry coverage: percentage of Windows endpoints and servers sending 4104, 4688 with command line and Sysmon 1, 10, 13 and 19 to 21 events (target close to 100%).
• Application control coverage: percentage of endpoints with App Control or AppLocker enforced, not just in audit.
• ASR rule state: number of priority rules in block mode versus audit across the estate.
• Silent host rate: endpoints with a telemetry gap over 24 hours, and time to investigate each.

Prevention and hardening

The Microsoft research team's advice is explicit: do not disable PowerShell, because defenders lose its logging and administrators move to tools with less visibility. Restrict and observe it instead.

Phased rollout

1. Turn on telemetry first: script block and module logging, 4688 with command line, Sysmon with a maintained configuration, and central collection. It has no user impact.
2. Remove what is not needed: disable the Windows PowerShell 2.0 optional feature, block internet macros, and inventory script hosts and runtimes on servers.
3. Deploy ASR rules in audit mode: review audit events for two to four weeks, add narrow exclusions for named management tools, then move rules to block in pilot rings before broad rollout.
4. Introduce application control in audit: build a base App Control policy from a reference image, collect audit events (CodeIntegrity Operational log, event 3076 for audit blocks), then enforce on a pilot ring. Confirm that PowerShell reports Constrained Language Mode for non-approved scripts.
5. Tighten privilege: remove standing local administrator rights, rotate local admin passwords with LAPS, and enable LSA protection.
6. Roll back safely: keep every ASR rule and App Control policy change reversible through the same management channel (Intune or Group Policy), switching back to audit mode rather than removing the policy, and document a break-glass process for blocked business-critical tools.

For the wider Windows baseline see the Windows Endpoint Hardening Guide.

Decision guidance

• Small organisations: start with the built-in pieces: script block logging, ASR rules in block mode for Office and LSASS, PowerShell 2.0 removed, macros blocked, and an EDR with managed detection.
• Large organisations: enforce App Control on servers and privileged access workstations first, where software change is slower, then expand to general endpoints.
• AppLocker or App Control: choose App Control where you can manage it, because it is the feature that drives Constrained Language Mode and kernel-level enforcement; use AppLocker for per-user or per-group rules that App Control does not express.

Where identity fits

Most fileless intrusions are ultimately after credentials. Service accounts and shared local administrator accounts that log on interactively to many hosts leave reusable secrets in LSASS memory, and management frameworks such as WMI and PowerShell remoting are only as safe as the accounts allowed to use them. Unique local admin passwords and tiered administration limit what an in-memory foothold becomes. See the LAPS Guide.

Response and memory forensics

1. Isolate, do not power off: use EDR network containment so the process and its memory survive.
2. Capture volatile memory first: acquire a full memory image with an approved tool before any remediation, then collect the event logs, registry hives and WMI repository.
3. Analyse memory: frameworks such as Volatility 3 analyse Windows, Linux and macOS images; process listing and tree plugins reveal unusual lineage, and injected-code plugins highlight executable memory not backed by a file on disk. See the Memory Forensics Guide.
4. Hunt for persistence across the estate: WMI subscriptions, Run keys with unusually large values, scheduled tasks and services created during the intrusion window.
5. Reset credentials after cleanup: rotate passwords and secrets for every account that touched affected hosts, starting with privileged and service accounts.

Framework mapping

Practitioner checklist

• Enable PowerShell script block and module logging estate-wide, with Protected Event Logging where secrets may appear.
• Enable Audit Process Creation with command-line capture and forward 4688 events centrally.
• Deploy Sysmon with a maintained configuration that includes events 1, 8, 10, 13 and 19 to 21.
• Remove Windows PowerShell 2.0 and block macros from the internet.
• Run priority ASR rules in audit, tune, then enforce in rings.
• Pilot App Control for Business on servers and privileged workstations and confirm Constrained Language Mode applies.
• Remove standing local admin rights and rotate local admin passwords with LAPS.
• Add memory capture to the incident response runbook before any reimage step.
• Test detections quarterly with purple-team exercises mapped to the ATT&CK techniques above.

Standards and references

• CISA, NSA, FBI and partners: Identifying and Mitigating Living Off the Land Techniques
• CISA: Identifying and Mitigating Living Off the Land Techniques (resource page)
• Microsoft Learn: about_Logging_Windows
• Microsoft Learn: How the Antimalware Scan Interface helps you defend against malware
• Microsoft Learn: Attack surface reduction rules reference
• Microsoft Learn: Sysmon
• Microsoft Security Blog: Now you see me, exposing fileless malware
• Kaspersky Securelist: Fileless attacks against enterprise networks

Related NHI Mgmt Group resources: EDR Evasion and Defence Guide · Threat Hunting Guide · Incident Response Guide · Malware Guide