Living Off the Land Attacks: Fileless Techniques That Evade Traditional Defenses
Living off the land (LOTL) is a fileless attack technique in which intruders abuse native, legitimate system tools and binaries to conduct intrusions, persistence, and data theft without installing custom malware. Because these utilities—PowerShell, Windows Management Instrumentation (WMI), and the credential-dumping tool Mimikatz—are already present in the environment, signature-based antivirus and file-scanning defenses frequently miss the activity entirely, allowing attackers to dwell undetected for weeks, months, or even years.
This article examines how LOTL attacks work, identifies the native binaries most commonly abused, and provides a defensible framework—derived from guidance published by CISA and its partners—for detecting, mitigating, and hunting these techniques in on-premises, cloud, hybrid, Windows, Linux, and macOS environments.
Key Findings Summary
| Metric / Dimension | Finding |
|---|---|
| Attack classification | Fileless / Living Off the Land (LOTL) — abuses native system tools rather than installing custom malware |
| Primary detection gap | Traditional signature-based tools search for known malware files or scripts; LOTL leaves no unique file to match |
| Typical dwell time when undetected | Weeks, months, or even years |
| Environments affected | On-premises, cloud, hybrid, Windows, Linux, and macOS |
| Threat actor profile | State-sponsored cyber threat actors, including PRC and Russian Federation actors, conduct LOTL operations against critical infrastructure |
| High-priority LOLBins | ntdsutil.exe, psexec.exe, vssadmin.exe |
| Highest-impact credential path | Volume Shadow Copy + ntdsutil.exe snapshot → extraction of ntds.dit (Active Directory database) |
| Recommended defender strategy | Apply joint agency guidance to detect and hunt for LOTL activity |
What Are Living Off the Land Attacks and Why Are They Fileless?
Living off the land is a fileless malware technique in which a cybercriminal uses native, legitimate tools within the victim's system to sustain and advance an attack. The defining characteristic is the absence of attacker-installed code: instead of dropping a malicious binary, the adversary leverages tools already present in the environment—PowerShell, WMI, or Mimikatz—so the malicious action is carried by trusted software.
That distinction matters for defenders. Traditional malware attacks leverage signature files to carry out the attack plan. A signature is a unique fingerprint—a hash, byte pattern, or known file behavior—that security tools match against. LOTL activity provides no such fingerprint because the tools being executed are the same ones administrators use every day. The attack surface is the trusted toolset, not a malicious payload.
A useful mental model: think of LOTL as a locksmith using the homeowner's own keys. The doors are not broken; they are opened legitimately. Detection must therefore focus on context—who ran a tool, when, on what system, and with what arguments—rather than on the tool itself.
Which Native Tools Do Attackers Abuse Most?
Analysts across the security community group these abused binaries under a common term: LOLBins (Living Off the Land Binaries)—legitimate executable files built into an operating system or installed management tooling that adversaries repurpose for malicious ends. The joint guidance from CISA and its authoring agencies singles out several high-risk LOLBins, including ntdsutil.exe and psexec.exe, which are frequently used by state-sponsored advanced persistent threat (APT) actors in compromised environments. Because these binaries are signed, trusted, and expected in most enterprise environments, blocklisting them outright is rarely operationally viable—a constraint that helps explain why they remain effective attack tools.
Why Is NTDSUtil.exe a Priority Target for Defenders?
Let me explain this carefully, because ntdsutil.exe is the single most consequential LOLBin on the list. Given its ability to create snapshots of the Active Directory database, ntdsutil.exe is a priority target in LOTL tactics due to the access it provides to sensitive user data and system configurations.
Active Directory is the identity backbone of most Windows enterprises—it holds account records, password hashes, group memberships, and trust relationships. A tool that can snapshot and export the AD database effectively hands an adversary the keys to the entire domain. That is why the joint guidance identifies a hallmark technique in this category.
According to the joint guidance, a hallmark TTP used by a state-sponsored APT group includes creating a volume shadow copy followed by dumping the ntds.dit file, involving both vssadmin.exe and ntdsutil.exe. The sequence proceeds in stages:
- The actors create a volume shadow copy of the system drive using
vssadmin.exe Create Shadow /for=C:, establishing a snapshot of the system state, including the Active Directory database. - They then employ
ntdsutil.exewith the command sequencentdsutil snapshot "activate instance ntds" create quit quitto interact with that shadow copy. - Finally, they access the shadow copy to extract the
ntds.ditfile.
The elegance of this attack—from the adversary's perspective—is that every command is a legitimate administrative operation. Backup software creates shadow copies. Administrators legitimately run ntdsutil.exe for snapshots. The maliciousness lives entirely in the sequence, timing, and identity of the operator.
The Broader LOLBin Landscape
The joint guidance states that cyber threat actors abuse native tools and processes on systems, often using living off the land binaries, and they use LOTL in multiple IT environments, including on-premises, cloud, hybrid, Windows, Linux, and macOS environments. That cross-platform reach is a critical planning assumption: LOTL is not a Windows-only problem. Any environment with rich native tooling—which is to say, essentially every modern operating system and cloud platform—offers material for LOTL tradecraft.
This is also where LOTL intersects with other threat categories. Understanding how advanced persistent threats (APTs) operate across long timelines helps defenders recognize that LOTL is the persistence and lateral-movement method of choice for actors who prioritize stealth over speed.
Why Do Traditional Defenses Fail Against Fileless Attacks?
Traditional security tools fail against LOTL because their core detection model—matching known-bad files and scripts—has no malicious artifact to match. The CrowdStrike analysis is direct on this point: using native tools makes LOTL attacks far more difficult to detect, especially if the organization is leveraging traditional security tools that search for known malware scripts or files.
Because of this gap in the security toolset, the hacker is often able to dwell undetected in the victim's environment for weeks, months or even years. The dwell time is not a minor detail—it is the entire strategic payoff. Long dwell time enables credential harvesting, privilege escalation, data exfiltration, and pre-positioning for high-impact events.
Adversaries also blend techniques. They do not limit themselves to one type of attack; they use any technology that will help them capture their payload. Notably, ransomware attackers are using fileless techniques to embed malicious code in documents. That combination is significant: a document-borne initial access followed by LOTL execution means defenders cannot rely on a single control layer. Organizations that treat the evolving ransomware landscape as a separate problem from fileless tradecraft are missing where these attacks converge.
A Concrete Attack Chain
Consider a hypothetical mid-size enterprise. An employee opens a document containing embedded code. Rather than dropping a dropper binary to disk, the embedded code invokes a native scripting engine through a trusted parent process. The attacker then uses that foothold to query WMI for system and user context, escalates via a trusted management utility, creates a shadow copy, and exports the AD database through ntdsutil.exe. No file on disk is uniquely malicious. No antivirus signature fires. The only anomalies are behavioral: an unusual parent-child process relationship, an off-hours shadow copy, and ntdsutil.exe invoked interactively rather than by a backup service account.
That example is generic, but the logic mirrors the documented vssadmin.exe → ntdsutil.exe → ntds.dit pattern. The lesson is that detection engineering must shift from artifact matching to behavior and context analysis.
How Should Defenders Detect and Hunt for LOTL Activity?
Detection should be built around anomaly and context, not signatures. The joint guidance recommends that network defenders—including threat hunters—apply its guidance to detect and hunt for LOTL activity. That guidance is derived from incident response engagements, red team assessments that used LOTL for undetected persistent access, and industry collaboration. In other words, it reflects observed attacker behavior in real environments.
A practical detection program for LOTL has four layers. First, baseline legitimate use. Know which accounts and service identities normally run ntdsutil.exe, vssadmin.exe, and psexec.exe, and from which hosts. Second, instrument process creation. Capture full command lines, parent-child process relationships, and user context. Third, alert on sequence. A shadow copy created by a non-backup identity followed by ntdsutil.exe snapshot commands is a high-fidelity indicator; neither event alone is conclusive. Fourth, hunt proactively. The joint guidance explicitly treats threat hunting as part of the defender's mandate, not an optional extra.
One nuance worth stating plainly: this approach depends heavily on logging maturity. Organizations without robust process-creation auditing will get limited mileage from behavioral rules, and in those cases the fastest return may come from enabling the telemetry first. Detection engineering is only as good as the data feeding it.
Analysis by Category: Mapping LOTL Risk Across Attack Phases
Breaking LOTL risk down by attack phase helps prioritize defensive investment. The table below maps the categories most relevant to defenders, drawing on the observed behaviors in the joint guidance and the definitions provided by CrowdStrike.
| Attack Phase | Representative LOTL Behavior | Primary Detection Signal | Source |
|---|---|---|---|
| Initial execution | Native scripting engines and system binaries invoked by trusted processes | Unsigned or anomalous parent-child process lineage | |
| Discovery | WMI and other native query tools used to profile host and user context | Unusual query volume from a single identity | |
| Credential access | ntdsutil.exe snapshotting of the AD database for ntds.dit extraction | Shadow copy + snapshot sequence by non-backup account | |
| Lateral movement | psexec.exe used by APT actors in compromised environments | Remote service execution from unexpected hosts | |
| Persistence | Continued use of native tooling across on-prem, cloud, hybrid, and multiple OSes | Long-horizon behavioral baselines |
Three observations follow from this mapping. First, credential access is the highest-severity category because of its downstream leverage—compromising the AD database enables domain-wide impact. Second, lateral movement via psexec.exe is a well-established APT behavior, so it deserves dedicated detection content rather than generic remote-execution alerting. Third, persistence in LOTL operations is not a single technique but a posture: because the tools are native and cross-platform, defenders should assume persistence attempts will look like routine administration.
It also helps to distinguish LOTL from adjacent concepts. LOTL is not the same as a zero-day exploit—a zero-day abuses an unknown software vulnerability, whereas LOTL abuses known, functioning features of legitimate tools. That distinction matters because zero-day defenses and LOTL defenses require different controls: patch velocity for the former, behavioral monitoring for the latter. Confusing the two leads to misallocated budget.
How Does LOTL Fit Into the Broader Malware Landscape?
LOTL is best understood as a delivery and persistence philosophy rather than a malware family. Where a conventional trojan ships its own executable, a LOTL operation ships only instructions—and often not even that, since the initial access vector may be a document or a valid credential. That is why emerging malware trends in 2025 increasingly include fileless components: adversaries are optimizing for stealth, and native tooling is the stealthiest available mechanism.
For security leaders, the practical implication is that malware-focused metrics—signature coverage, detections per endpoint—can look healthy while a LOTL intrusion proceeds. A mature program tracks behavioral indicators alongside artifact-based ones. The joint guidance's emphasis on threat hunting reflects exactly this shift.
Recommendations for Reducing LOTL Exposure
The joint guidance is explicit: the authoring agencies strongly recommend network defenders apply the guidance to detect potential use of these LOLBins. Translating that into an actionable program involves both preventive hardening and detection investment.
On the prevention side, apply least privilege aggressively. If an account does not need to create shadow copies or run ntdsutil.exe, it should not have the rights to do so. Tier administrative accounts so that help-desk and workstation-admin identities cannot touch domain-controller-adjacent operations. Restrict remote execution paths that psexec.exe relies on, and monitor them where restriction is impractical.
On the detection side, build hunting hypotheses around the documented TTP: shadow copy creation followed by ntdsutil.exe snapshot activity followed by access to the resulting copy. Encode that sequence, not just the individual commands. Where detection tooling supports it, correlate process events with identity context so that a backup service account running the same commands does not generate noise.
On the governance side, treat LOTL as a standing agenda item for detection engineering reviews. The joint guidance was developed precisely because malicious use of LOTL techniques is increasingly emerging in the broader cyber threat environment, and threat actors—including PRC and Russian Federation state-sponsored actors—have used LOTL to compromise and maintain persistent access to critical infrastructure organizations. A one-time review will not keep pace.
Finally, note the tradeoff: over-tightening native tool use can break legitimate administration and backup workflows. The goal is not to eliminate LOLBins but to make their malicious use conspicuous through identity, sequencing, and context controls.
How Can Organizations Build a Practical LOTL Defense Checklist?
A checklist derived from the joint guidance and the observed TTPs gives teams a starting point. This is not exhaustive, but it covers the highest-value items.
- Inventory native tools of concern. Identify where
ntdsutil.exe,vssadmin.exe, andpsexec.exeare used legitimately, and by whom. - Enable process creation auditing with full command-line capture on servers and domain controllers.
- Baseline service-account behavior for backup and management identities so shadow-copy creation has a known-good pattern.
- Write sequence-based detections that flag shadow-copy creation followed by
ntdsutil.exesnapshot commands. - Hunt regularly using the joint guidance's detection and hunting recommendations as a source of hypotheses.
- Restrict unnecessary privileges that allow interactive shadow-copy or snapshot operations.
- Review cross-platform coverage, including cloud, hybrid, Linux, and macOS environments where LOTL also occurs.
That checklist works best when paired with a broader threat-modeling exercise. Teams that understand how cyber threats and attack vectors connect end to end will place each item in the right control layer rather than treating LOTL as a standalone problem.
Conclusion: Detection Must Move From Artifacts to Behavior
Living off the land attacks succeed because they exploit a structural blind spot in traditional defense: there is no malicious file to find. CrowdStrike's definition is unambiguous—LOTL is a fileless technique where attackers use native, legitimate tools within the victim's system, which makes detection far more difficult for organizations relying on known-malware matching, and which lets intruders dwell for weeks, months, or years.
The joint guidance from CISA and its partners confirms that this is not a theoretical concern. State-sponsored actors, including PRC and Russian Federation elements, have used LOTL to compromise and hold persistent access to critical infrastructure. The documented vssadmin.exe and ntdsutil.exe chain that dumps ntds.dit shows how much damage trusted tools can do when abused in sequence.
The strategic takeaway for defenders is that LOTL is not a tool problem—it is a visibility and context problem. Organizations that invest in behavioral baselining, process-level telemetry, sequence-based detection, and disciplined threat hunting will see LOTL activity that signature tools miss. Those that do not will keep discovering intrusions long after the adversary has already achieved its objective. The joint guidance exists to close that gap; the work now is execution.




