CyphrQ
Menu

Fileless Malware and Living off the Land: How to Detect It

Fileless attacks run through tools already on your systems, such as PowerShell and WMI. Why antivirus misses them, and how to detect and respond.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

10 min read

Fileless malware is an attack that runs through software already on your computers, such as PowerShell or Windows Management Instrumentation, instead of dropping an obvious malicious program on disk. "Living off the land" is the wider habit of using those built-in tools for every stage of an intrusion. Antivirus that looks for bad files has little to find. Detection depends on logging what the built-in tools do and spotting behaviour that does not fit.

The term "fileless" is slightly misleading. An attack can still touch disk somewhere; MITRE notes PowerShell can run downloaded code "from disk or in memory". The point is that the tools doing the damage are signed, trusted parts of the operating system that your administrators also use every day.

What is fileless malware, and what does living off the land mean?

Picture a burglar who brings no tools and uses the ladder, the keys and the toolbox already in your garage. Nothing they carry looks suspicious, because they carry nothing.

In computing, the "ladder and toolbox" are utilities built into Windows, macOS and Linux:

  • PowerShell, Windows' scripting and administration shell.
  • WMI (Windows Management Instrumentation), used to query and manage Windows machines, including remotely.
  • LOLBins (living-off-the-land binaries), legitimate system programs that can be misused to run code, move files or collect information. Examples include certutil, rundll32, mshta and regsvr32.

MITRE ATT&CK, the public catalogue of attacker techniques, documents how PowerShell can download and run code "from disk or in memory without touching disk" in T1059.001. It describes the misuse of trusted, typically Microsoft-signed, system binaries to run malicious content in T1218 System Binary Proxy Execution.

How do fileless attacks get in and spread?

The stages look like any intrusion. What changes is the toolkit at each stage.

  1. Getting in. Usually through a phishing message, stolen credentials, or an unpatched internet-facing device such as a VPN or firewall. The ZTNA vs VPN guide covers why those devices are targeted.
  2. Running code. A script runs in PowerShell or through a LOLBin. Some payloads live only in memory, or hide in places like the registry or WMI, rather than as a normal file.
  3. Stealing credentials. The attacker copies password hashes from memory or from the Active Directory database, often with built-in tools.
  4. Moving sideways. With valid credentials, they connect to other machines using remote management features that administrators use too.
  5. Staying in. They create scheduled tasks or WMI subscriptions, or simply keep re-using stolen passwords.

Because each step uses legitimate tools and valid accounts, the activity can look like an administrator doing their job.

Why does antivirus miss living-off-the-land attacks?

Traditional antivirus asks "is this file known to be bad?" Living-off-the-land attacks avoid giving it a file to judge.

  • The programs are trusted. PowerShell and WMI are signed by Microsoft and needed for administration. Blocking them outright breaks IT operations.
  • Payloads may never be saved as files. A script that runs in memory leaves nothing for a file scan.
  • Valid accounts look normal. Once the attacker logs in with a real admin's password, each action is permitted.
  • Many organisations lack the logs. The joint guidance from CISA and partners, Identifying and Mitigating Living Off the Land Techniques (7 February 2024), says the technique "continues to be effective with little to no investment in tooling" by attackers because many organisations lack the security capabilities to detect it. It adds that even mature organisations find it hard to separate malicious activity from legitimate behaviour.

What did Volt Typhoon show about living off the land?

The clearest documented case is Volt Typhoon, a group that CISA, the NSA and the FBI attribute to the People's Republic of China. Their joint advisory AA24-038A, published on 7 February 2024 with US and international partners, reports:

  • Targets. US critical infrastructure in communications, energy, transportation, and water and wastewater, including territories such as Guam.
  • Dwell time. The agencies observed access in some victim environments "for at least five years".
  • Way in. Exploiting known or zero-day flaws in internet-facing routers, VPNs and firewalls, from vendors including Fortinet, Ivanti, NETGEAR, Citrix and Cisco.
  • Tools. Heavy reliance on built-in tools instead of malware. The advisory names ntdsutil to copy the Active Directory database, vssadmin to create shadow copies, WMIC to run commands remotely, PowerShell for targeted event log queries, and netsh to set up port proxies.
  • Goal. The agencies assess with high confidence that the actors were pre-positioning on IT networks for disruptive or destructive attacks.

The lesson for everyone, not only infrastructure operators: an attacker who uses your own tools and your own accounts can stay for years unless you are watching how those tools are used.

How common are malware-free intrusions?

One vendor's telemetry gives a sense of scale. CrowdStrike's 2026 Global Threat Report findings (24 February 2026, covering 2025) states that "82% of detections were malware-free". It reports an average eCrime breakout time, from initial access to moving onto another system, of 29 minutes, and a fastest observed breakout of 27 seconds.

Read that as one company's view of the intrusions it saw, not a census of all attacks. CrowdStrike's post does not say exactly which dataset the 82% covers. It is consistent with the Volt Typhoon advisory above: a serious intrusion need not depend on a malicious file.

How do you detect fileless attacks?

Detection moves from "what file is this?" to "is this behaviour normal here?"

  1. Turn on the right logs. PowerShell script block logging, process creation logging with command lines, and Windows security event logs, sent to a central place the attacker cannot easily erase.
  2. Know your normal. Which admins use PowerShell, from which machines, at what times? Which servers ever run WMIC? A baseline turns a sea of legitimate activity into a short list of exceptions.
  3. Alert on unusual combinations. An office application launching PowerShell. Encoded PowerShell commands. certutil downloading from the internet. WMI starting processes on a remote machine from a workstation that never does that.
  4. Watch identity. Logons at odd hours, from unusual places, or admin accounts touching systems they never touch.
  5. Use endpoint detection and response (EDR). EDR records process behaviour, not only files, so it can link a chain of legitimate tools into a suspicious story.

The infostealers guide covers a related problem: theft that needs no malware persistence at all once a session is copied.

How should you respond to a suspected fileless intrusion?

  1. Preserve memory and logs before rebooting. If the payload lives in memory, a reboot can destroy the evidence.
  2. Isolate affected machines from the network, using EDR isolation where possible so you keep remote visibility.
  3. Assume credentials are stolen. If the attacker reached a domain controller, treat it as full domain compromise. AA24-038A advises resetting credentials, including the krbtgt account twice.
  4. Hunt for persistence: scheduled tasks, WMI event subscriptions, new services, registry run keys, new accounts.
  5. Check the way in. Patch or rebuild the edge device or account that gave first access.
  6. Follow your incident process and notification duties. The ISO/IEC 27035 guide covers structure; the breach notification guide covers deadlines.

Going deeper: for security and IT teams

Threat model. The actor ranges from state groups like Volt Typhoon to commodity eCrime operators. They need initial code execution or valid credentials. With built-in tooling they get discovery, credential access and lateral movement while generating telemetry that resembles administration. The defender's leverage is context: who ran it, from where, with what parent process, and whether that combination has ever occurred before.

ATT&CK mapping. - Execution: T1059.001 PowerShell and T1047 Windows Management Instrumentation. MITRE notes remote WMI uses DCOM on port 135 or WinRM on 5985 (HTTP) and 5986 (HTTPS), and that wmic.exe is deprecated. Microsoft's WMIC removal notice gives the timeline: disabled by default in Windows 11 versions 23H2 and 24H2 in 2024, removed on upgrade to 25H2 in 2025, and removed from 24H2 and 25H2 with the August 2026 preview update, with no option to add it back. Only the command-line tool is gone; WMI itself remains supported, and PowerShell CIM cmdlets are Microsoft's replacement. Older Windows versions and servers may still have wmic.exe, so keep watching for it. - Stealth: T1218 System Binary Proxy Execution, which ATT&CK lists under tactic TA0005, with sub-techniques including T1218.005 Mshta, T1218.010 Regsvr32 and T1218.011 Rundll32. - Credential access: T1003 OS Credential Dumping, notably T1003.001 LSASS Memory, T1003.003 NTDS and T1003.006 DCSync.

Controls with specifics. - PowerShell. MITRE's T1059.001 mitigations include M1045 Code Signing (execution policy limited to signed scripts), M1042 removing PowerShell where not needed and restricting WinRM, M1026 Just Enough Administration (JEA) for remote sessions, and M1038 application control with Constrained Language mode. MITRE notes execution policy can be bypassed, so treat it as a speed bump, not a control. - Script block logging. Per Microsoft Learn, script block logging records the content of every script block PowerShell processes, as event ID 4104. On PowerShell 7 it is written to the PowerShellCore/Operational log once the event provider is registered, and enabled through the "Turn on PowerShell Script Block Logging" Group Policy setting or the EnableScriptBlockLogging registry value. Microsoft recommends Protected Event Logging when using it beyond diagnostics, because scripts may write credentials into the log; the private key belongs on the central collector, not the endpoints. Windows PowerShell 5.1 logs to its own channel, documented separately. - WMI. T1047 mitigations include M1040 Attack Surface Reduction rules to block processes created by WMI commands (test for false positives first), M1038 application control to block wmic.exe where not required, and M1018 restricting remote WMI to administrators, which is the default. - Credential theft. T1003 mitigations include M1043 Credential Guard, M1025 Protected Process Light for LSA, M1040 ASR rules protecting LSASS, and M1028 restricting NTLM and disabling WDigest.

Detection and evidence from AA24-038A. The Volt Typhoon advisory gives concrete hunts: - Review Windows ESENT Application log event IDs 216, 325, 326 and 327, which may indicate NTDS.dit copying. These persist longer than Security logs. - Investigate every event ID 1102 (audit log cleared). - Look for unusual files in C:\Windows\Temp and C:\Users\Public, such as a copy of comsvcs.dll in a non-standard folder, used for LSASS dumping. - Pair those host hunts with the remote access log review covered in the ZTNA guide, since this group came in through edge devices.

MITRE's detection strategy for PowerShell, DET0455 (Windows analytic AN1252), looks for PowerShell launched with encoded commands, unusual parent processes or suspicious modules, followed by network connections or child processes, including indirect invocation through .NET without powershell.exe. For WMI, DET0364 (Windows analytic AN1031) chains process creation, command execution and, for remote use, the matching network connection.

Testing that it works. In a lab, with permission, run benign PowerShell and WMI activity from a non-admin workstation and confirm the 4104 events and process-creation events arrive centrally, with command lines, within your alerting window. Repeat after any logging policy change.

Questions for your team and EDR provider. - Is script block logging on for every Windows endpoint and server, and does it reach the SIEM? - Do we capture full command lines for process creation? - Which accounts legitimately run PowerShell remoting or WMI against servers, and is that list current? - Does our EDR flag encoded PowerShell and Office-spawned shells by default, or only with tuning? - How long do we keep endpoint telemetry, and is it long enough to investigate a dwell time measured in months?

A fileless malware defence checklist

  1. Turn on PowerShell script block logging and process command-line logging everywhere, and forward them centrally.
  2. Use Protected Event Logging so logs do not leak credentials.
  3. Restrict PowerShell remoting and WMI to named admin accounts and admin workstations.
  4. Deploy application control and Attack Surface Reduction rules in audit mode, then enforce.
  5. Turn on Credential Guard and LSA protection where supported.
  6. Patch internet-facing devices fast, because they are a common way in.
  7. Build a baseline of normal admin tool use and review the exceptions weekly.
  8. Write the response step: preserve memory, isolate, assume stolen credentials, reset krbtgt twice if a domain controller was touched.

Key takeaways

  • Fileless malware and living off the land use trusted built-in tools such as PowerShell, WMI and LOLBins, so file-based antivirus has little to catch.
  • CISA and partners' February 2024 joint guidance says the technique keeps working with little investment by attackers because many organisations lack the capability to detect it.
  • Volt Typhoon used built-in tools such as ntdsutil, WMIC, PowerShell and netsh, and kept access to some US critical infrastructure networks for at least five years.
  • One vendor, CrowdStrike, reports that 82% of its detections in 2025 were malware-free.
  • Detection depends on logging (script block logging, event ID 4104, command lines), baselines of normal admin activity, and EDR that sees behaviour.
  • In response, preserve memory first and assume credentials are stolen.

Sources