Skip to content
  • There are no suggestions because the search field is empty.
PROTECTING OVER $1B IN DAILY TRADES
DEFENDING ENERGY FOR 32+M U.S. USERS
SECURING NETWORKS FOR 52K+ TRANSPORT VEHICLES
DEFENDING $10T+ IN MANAGED ASSETS
SECURING 16+M ANNUAL PATIENT VISITS
+1(888) 547-9497
Home/Resources/Glossary/

Living off the land (LOTL) attacks: How they work and how to detect them

Living off the land (LOTL) attacks abuse trusted admin tools. Learn why endpoint-only defenses miss them and how to detect them across the network.

Living off the land (LOTL) is an evasive technique where attackers carry out an intrusion using an organization's legitimate administrative tools, including PowerShell, WMI, RDP, and dozens of others, instead of custom malware. Because these tools are already trusted, there's usually no suspicious file for antivirus or endpoint detection and response (EDR) to flag. That's why nation-state actors like Volt Typhoon have built entire campaigns around LOTL, operating inside U.S. critical infrastructure for years while appearing to conduct routine IT administration.

For security operations center (SOC) analysts, threat hunters, and security leaders, LOTL attacks are among the hardest intrusions to catch, since they're built to defeat the tools most organizations rely on daily. This guide covers what LOTL attacks are, the tools attackers abuse, why endpoint-only defenses struggle against them, and how to detect them and reduce exposure using both endpoint and network evidence.

What is a living off the land (LOTL) attack?

A living off the land attack uses an organization's own legitimate administrative tools, scripting engines, and trusted system binaries, also known as LOLBins (living-off-the-land binaries), to achieve an attacker's objectives, rather than deploying custom malware. Instead of writing a new executable that antivirus might catch, the attacker simply uses what's already there: PowerShell to run commands, WMI to move between systems, RDP to log in remotely, all with valid or stolen credentials.

The name comes from the idea that the attacker "lives off" the resources already present in the environment, blending malicious actions into the stream of ordinary administrative activity. Because no new or unknown executable is introduced, there's typically nothing for a traditional antivirus or EDR signature to match against, which is the core reason LOTL techniques are so effective at evading detection.

LOTL is especially common in long-dwell, stealth-first operations: espionage, pre-positioning inside critical infrastructure, and the early stages of ransomware intrusions, where the goal is to look like routine IT work for as long as possible rather than announce the attacker's presence.

How LOTL techniques fit into the attack chain

LOTL isn't a single technique confined to one stage of an intrusion; it shows up across nearly the entire attack chain. Attackers use native tools for:

  • Execution: Running commands or scripts through PowerShell, WMI, or scripting engines already present on the system
  • Persistence: Scheduled tasks or registry modifications that don't require dropping a new binary
  • Privilege escalation and credential access: Native utilities used to harvest credentials or access memory
  • Lateral movement: RDP, SSH, WinRM, or PsExec to move between systems using valid accounts
  • Command-and-control (C2): Traffic blended into normal outbound administrative or DNS traffic
  • Exfiltration: Native tools used to package and move data out

LOTL concentrates in the "quiet middle" of an intrusion, after initial access but before any visible impact. This is exactly where signature-based tools have the fewest detections and where behavior over time matters most.

Corelight_Infographic_LOTLIntrusion

Later in this piece, we'll map this same attack chain against what endpoint and network tools actually see at every step.

Common living off the land techniques and tools

Most LOTL activity revolves around a fairly small set of tools commonly called LOLBins that already exist in nearly every Windows and Linux environment. The challenge is that the same tool used maliciously can look identical to legitimate administration; what differs is the context and behavior surrounding it. 

Tool Legitimate purpose How attackers abuse it Detection signal

PowerShell

Windows administration and automation  

 Downloads payloads, runs encoded/obfuscated commands, and executes in-memory  Encoded command-line flags, unusual script block content, abnormal parent process 

WMI 

Remote system management 

 Remote process execution and lateral movement without dropping a file  WMI activity between hosts that don't normally communicate 

PsExec (and similar) 

Remote admin execution

 Lateral movement and remote command execution using stolen credentials 

New service creation tied to remote logon; off-hours use 

certutil 

Certificate management 

 Downloads and decodes payloads disguised as routine certificate operations  certutil invoked with cache or decode flags 

RDP 

Remote desktop administration 

 Lateral movement and hands-on-keyboard access using valid accounts  RDP sessions from atypical source IPs, times, or account/asset pairings 

SSH 

Remote administration (Linux/network gear) 

 Lateral movement and pivoting through compromised edge or network devices  SSH sessions between unexpected hosts or through edge/VPN devices 

RMM software 

Legitimate remote IT support 

 Installs or abuses an RMM tool that already looks like sanctioned software  Unrecognized or duplicate RMM agents; RMM traffic to unexpected destinations 

WinRM 

Remote PowerShell management 

 Remote command execution that blends with normal admin traffic  WinRM sessions outside normal administrative baselines 

None of these tools are inherently malicious, and that's the point. Effective detection depends on behavior and context, not on the tool itself. 

LOTL vs. fileless malware vs. traditional malware

These three terms get used interchangeably, but they aren't the same thing, and the distinction matters for what you can realistically detect and where.

Fileless malware and LOTL frequently occur together, but LOTL specifically refers to abusing legitimate, already-trusted tools. In contrast, fileless malware refers to malicious code that executes primarily in memory and leaves little or no conventional file footprint, regardless of whether it uses native tools or a custom in-memory payload.

Characteristic Traditional malware Fileless malware Living off the land (LOTL)

Uses native/trusted tools 

Rarely

 Sometimes Always, by definition

Files written to disk 

Yes, a new executable 

 No, or minimal/temporary artifacts  Rarely. Activity runs through existing binaries 

Typical artifacts 

New/unknown file hash, AV/EDR signature match 

 In-memory indicators, registry, WMI repository 

Command-line history, process lineage, network sessions 

Detection considerations 

Signature and hash matching are often sufficient 

 Requires memory forensics and behavioral endpoint detection  Requires behavioral detection across both endpoint and network evidence 

Why LOTL attacks evade signature-based and endpoint-only defenses

Signature-based tools work by matching known-bad files, hashes, or byte patterns. LOTL uses legitimate, signed binaries that already have a valid reason to run on the system. There's simply nothing for a signature to match, no matter how sophisticated the signature engine is.

EDR runs into two separate structural problems here. First, it can't be installed everywhere: unmanaged, legacy, IoT/OT, and edge/network devices routinely have no agent at all. Second, even where EDR is installed correctly, it can still be evaded through tactics that broadly fall into blinding, blocking, or hiding the agent's visibility into what's actually happening on the host.

This gap isn't theoretical. Verizon's 2025 Data Breach Investigations Report found that edge devices and VPNs jumped from 3% to 33% of vulnerability-exploitation breaches in a single year, an almost eightfold increase. This is precisely the class of device where EDR coverage typically doesn't reach at all.

The same pattern appears in incident-response findings from government-led assessments of critical infrastructure. In a red-team engagement against a critical infrastructure organization, the first lesson learned was that the organization had leaned too heavily on host-based EDR without implementing equivalent protections at the network layer.

Why NDR matters here
Because LOTL commonly moves over remote admin protocols and between systems, that activity is often observable only as it crosses the wire. Network detection and response (NDR) is essential because it covers exactly what EDR structurally cannot see, especially on unmanaged and edge devices.

Signature-based detection matches activity against what's already known to be malicious, such as a file hash, a byte pattern, or a known-bad indicator. Behavior-based detection instead looks at how a tool, account, or connection is actually being used, such as the sequence of actions, timing, and relationships between systems, and flags deviations from what's normal, even when every individual action is technically legitimate.

Signature-based detection and behavior-based detection aren't competing approaches so much as complementary ones: one catches known threats efficiently, the other catches the unknown behavior LOTL depends on. LOTL is a category of attack specifically built to slip through the gap between them, evading signatures because it runs through trusted tools, and evading behavioral detection wherever there isn't enough endpoint or network telemetry in place to establish a baseline in the first place.

Real-world living off the land attack examples, including Volt Typhoon

Volt Typhoon. CISA, the FBI, NSA, and international partners confirmed that this Chinese state-sponsored actor pre-positioned itself inside U.S. critical infrastructure for years, relying almost exclusively on built-in operating system tools rather than deploying malware. Much of its traffic was proxied through compromised small-office/home-office and edge routers, further reducing the odds that any endpoint tool would ever see it. Volt Typhoon matters as an example because it's a documented, high-confidence case of a sophisticated actor choosing LOTL specifically to defeat endpoint-centric defenses.

Salt Typhoon. A related campaign, also attributed to Chinese state-sponsored actors, targeted network infrastructure at major U.S. telecommunications providers, focusing on routers and edge devices rather than user endpoints. Together, Volt Typhoon and Salt Typhoon show that LOTL activity aimed squarely at network infrastructure isn't an isolated incident; it's a deliberate, repeated pattern from the same category of actor.

Why NDR matters here
Both campaigns specifically targeted unmanaged and unmanageable devices, from the SOHO routers, Volt Typhoon proxied through to the provider and edge routers Salt Typhoon struck, where EDR cannot be deployed at all. This is the direct, documented reason the CISA red-team lesson called out over-reliance on host-based EDR without network-layer protection.

How to detect LOTL activity on endpoints and across the network

Detecting LOTL activity requires two complementary lenses, not a choice between them. Endpoint telemetry establishes what ran and how; network evidence establishes who talked to whom, over what protocol, how much data moved, and whether that pattern is normal for the environment.

Endpoint signals to watch for:

  • Unusual parent-child process relationships (for example, an Office application spawning PowerShell)
  • Encoded, obfuscated, or unusually long command lines
  • LOLBins invoked with flags that don't match typical admin usage
  • Script block logging and AMSI (Antimalware Scan Interface) anomalies

Network signals to watch for:

  • Remote admin protocol usage (RDP, SSH, WinRM) outside an established baseline, such as unusual source, time, or host pairing
  • Lateral movement and east-west traffic anomalies between systems that don't normally communicate
  • Beaconing patterns hidden inside otherwise normal-looking outbound traffic
  • DNS anomalies and encrypted-traffic behavioral analysis that doesn't require decryption
  • Evidence from unmanaged, edge, IoT, and OT devices that carry no endpoint agent at all

Why NDR matters here
"Normal versus abnormal" for LOTL activity can usually only be established by baselining real network behavior over time, something no endpoint agent can do on its own, and is needed for the assets no agent even covers. This is why network evidence functions as a required layer in LOTL detection, not an optional complement.

A quick detection checklist:

Endpoint logging: Command-line auditing, script block logging, process lineage
Network telemetry: Coverage across on-prem, cloud, and unmanaged/edge assets
Baselining: Established "normal" admin-tool and remote-protocol activity per asset or segment
Privileged access controls: Least privilege and monitored use of admin tools and protocols

Mapping EDR and NDR to the attack chain

Coming back to the attack chain walkthrough from earlier, it's worth showing exactly where each detection layer earns its keep, and why LOTL is built to exploit whichever one is missing.

Attack chain step What EDR sees What NDR sees Why you need both

1. Initial access (edge/VPN exploit) 

Usually nothing; edge and VPN devices rarely run an agent 

 Anomalous external connections and exploit traffic hitting the edge device NDR is often the only telemetry that exists on this asset class at all 

2. Recon (net, nltest, ipconfig, whoami) 

Command-line and process logging capture exactly what ran 

 Internal scanning and service-discovery traffic patterns EDR confirms intent on the host; NDR shows the same recon spreading across the network 

3. Credential access (LSASS, or Local Security Authority Subsystem Service, access; ntdsutil)

Process-level access to LSASS and memory-dump behavior

 Limited direct visibility, though abnormal SMB/RPC calls to a domain controller can surface

EDR is the primary detector here since the access itself is host-local, but NDR adds confirmation when the dump reaches out over the wire (e.g., abnormal SMB/RPC calls to a domain controller), catching cases where the EDR agent is missing, disabled, or blinded 

4. Lateral movement (WMI, PsExec, RDP, WinRM) 

New service creation and remote-execution artifacts, but only on hosts running an agent 

 Sessions between hosts that don't normally communicate; protocol usage outside baseline, agent, or no agent  NDR keeps working on unmanaged hosts in the path, where EDR coverage simply stops 

5. Persistence (scheduled tasks, registry) 

Registry modification and scheduled-task creation events 

 Little direct signal, beyond any resulting periodic callback traffic  EDR captures the persistence artifact as it's created, which is usually the only way to catch it before it fires. NDR adds value after the fact: Recurring beacon traffic tied to a reboot or logon cycle is often the first sign a persistence mechanism is active again, especially when the EDR alert was missed, or the agent was tampered with. 

6. Command-and-control (blended traffic) 

The originating process and destination for each connection (e.g., PowerShell or a signed binary making an outbound call), but no way to judge whether that single connection is malicious, since the process itself is legitimate 

 The pattern across many connections: beacon regularity, TLS/JA3 fingerprint anomalies, DNS query entropy, and destinations with no reputation history, signals that only emerge by watching traffic over time

EDR identifies which process is talking, which narrows the response once C2 is suspected; NDR is what actually surfaces the suspicion in the first place, since the traffic pattern, not the process identity, is what gives blended C2 away.

This keeps EDR meaningfully in the row (attribution/response) while being honest that detection-first credit goes to NDR, and it answers the "what does NDR see that EDR can't" question directly: it's not a visibility gap, it's a pattern-analysis capability EDR's architecture doesn't have.

7. Objective (collection, staging, exfiltration) 

File access and staging activity on the source host 

 Unusual data-volume and destination anomalies as data actually leaves  EDR identifies which files were staged; NDR confirms that data actually left. Together, they establish both what happened and whether data got out.

LOTL is built to exploit whichever layer is missing. EDR tends to lead on host-local steps like credential access and persistence; NDR tends to lead on cross-system and traffic-only steps like initial access into unmanaged devices, lateral movement, and command-and-control. Neither one alone covers the full chain. 

How to reduce your exposure to LOTL techniques

  • Constrain and monitor LOLBin usage where feasible: application control, constrained language mode, and script block logging, without resorting to blanket bans that break legitimate administration (more on this in the FAQs below).
  • Harden and patch internet-facing edge devices and VPN appliances: the entry point in both the Volt Typhoon case and the broader edge-device breach-vector trend.
  • Enforce least privilege and privileged access management for admin tools and remote protocols.
  • Segment networks to limit how far lateral movement can travel if an account or host is compromised.
  • Establish and maintain behavioral baselines for admin-tool and remote-protocol activity.
  • Continuously validate detections against current LOTL tactics with purple-team exercises or breach-and-attack simulation, rather than assuming deployed rules still fire.
  • Layer network visibility alongside endpoint tools deliberately: treat this as defense-in-depth, not redundant spend.

How Corelight helps expose living off the land activity

LOTL is a visibility problem, not a malware problem, and Corelight's Open NDR Platform is built to close exactly the blind spots this technique is designed to exploit.

Detection
Multi-layered detection, natively: Signature/IOC, behavioral/TTP, supervised ML, and anomaly detection combined in one platform, not bolted on top of a signature engine. The platform is designed to catch both known LOLBin abuse and unknown, evolving behavior.
agent-icon

Agentless coverage where EDR can't reach: Unmanaged devices, IoT/OT, legacy systems, and edge routers/VPN appliances, the exact asset classes Volt Typhoon and Salt Typhoon targeted because no agent could see them. Corelight's Performance and Asset Visibility module also passively classifies unmanaged and IoT assets by device type, OS, and network role, adding asset context to those investigations.

encrypted-icon
Sees through encryption: Purpose-built ML analyzes behavior in encrypted sessions without decryption, so C2 and lateral movement hidden in encrypted traffic don’t get a free pass. 
download-icon
Tamper-resistant ground truth: Network evidence that's harder to disable than endpoint logs, used to validate alerts from other tools (e.g., CrowdStrike Charlotte AI confirming host behavior with Corelight evidence) and directly countering EDR blinding.
Response-icon
Built-in response: One-click containment (e.g., CrowdStrike Falcon Network Contain, Microsoft Entra) plus Agentic Triage, which auto-investigates high-risk entities with evidence-backed verdicts. 

LOTL succeeds by hiding inside legitimate tools and traffic, exploiting whichever defense layer, endpoint or network, is missing across the attack chain. Corelight's Open NDR Platform closes those structural blind spots across devices and traffic patterns that endpoint tools were never built to see.

FAQs