Attackers have largely stopped bringing their own malware. In its 2025 Active Adversary Report, built from 413 real-world incident-response and managed-detection cases, Sophos measured a 126% year-over-year rise in the abuse of unique living-off-the-land binaries, the signed operating-system and administrative tools already present on every Windows estate. The same shift shows up in other telemetry: CrowdStrike found 82% of 2025 detections were malware-free, and Red Canary ranks PowerShell and the Windows Command Shell as the #2 and #3 most-observed techniques across nearly 60,000 confirmed threats. The pattern is consistent: adversaries sign in, blend in, and use the tools that are already trusted, which is exactly why the classic "block the bad file" model no longer decides the fight.
That is why living off the land (LOTL) is the defining detection challenge of 2026, and why it needs its own playbook. Four forces make the point. The abuse of legitimate binaries is climbing fast, up 126% in a year (Sophos). Speed leaves almost no time to react: the average eCrime breakout time fell to 29 minutes, roughly 65% faster than the year before, with the fastest observed at 27 seconds (CrowdStrike). The catalog of abusable tools is enormous and cannot be wished away: the community LOLBAS project documents more than 150 Windows binaries, plus scripts and libraries, that can be repurposed. And AI is accelerating the trend, with an 89% increase in AI-enabled adversary activity year over year (CrowdStrike). This post is written for CISOs, SOC and blue-team leads, detection engineers, and threat hunters who need to answer a specific question: if you cannot block these tools, how do you catch their abuse?
This is the Stingrai research team's canonical 2026 reference on detecting living off the land, and it is a deliberate companion to our broader piece on EDR evasion, which treats LOTL as one of four evasion categories. Here we go deep on LOTL and LOLBins specifically: what they are, why they defeat blocklists and signatures, and the detection and validation practices that actually work. It draws on primary telemetry and government guidance from CISA, NSA and FBI, Sophos, CrowdStrike, Red Canary, MITRE ATT&CK, Microsoft, and the LOLBAS project. Lead data is full-year 2024 and 2025 telemetry, the freshest available, with the CISA joint guidance dated February 2024 and the MITRE framework current to April 2026. Every figure links back to its primary publisher so any claim can be audited inline. This article stays conceptual on the offensive side and detailed on the defensive side by design: it explains the behavior and the telemetry, and spends most of its length on detection and defense.
TL;DR: what defenders need to know
LOLBin abuse is surging (2024): unique living-off-the-land binaries abused rose 126% year over year across 413 real-world cases (Sophos 2025 Active Adversary Report).
Malware-free is the majority (2025): 82% of detections involved no malware, up from 79% in 2024 (CrowdStrike 2026 Global Threat Report).
The abused tools are the everyday ones: cmd.exe topped managed-detection cases and Remote Desktop Protocol topped incident-response cases, with PowerShell, wevtutil.exe and vssadmin.exe close behind (Sophos).
Native scripting leads the technique charts: PowerShell and the Windows Command Shell rank #2 and #3 across nearly 60,000 confirmed threats over 1,000-plus customers (Red Canary 2026 Threat Detection Report).
You cannot blocklist trusted tools: the LOLBAS project catalogs more than 150 signed Windows binaries, plus scripts and libraries, that your business depends on (LOLBAS Project).
There is no IOC list to match: CISA, NSA and FBI note "there is no conventional list of indicators of compromise (IOCs) associated with LOTL activities" (CISA joint guidance).
Signed does not mean safe: MITRE catalogs System Binary Proxy Execution (T1218) with 14 sub-techniques for bypassing signature defenses "by proxying execution of malicious content with signed, or otherwise trusted, binaries" (MITRE ATT&CK).
Attackers log in more than they break in: External Remote Services paired with Valid Accounts in 78% of cases, and RDP appeared in 84% (Sophos).
The detection is behavioral: CISA recommends maintaining behavioral baselines and using automation "to continually review all logs to compare current activities against established behavioral baselines and alert on specified anomalies" (CISA).
Speed forces automation: with breakout times of 29 minutes, manual triage cannot keep pace (CrowdStrike).
Key takeaways
Living off the land is now the mainstream approach, not an advanced-actor flourish. With LOLBin abuse up 126% and 82% of detections malware-free, blending into normal activity with trusted tools is the default operating mode (Sophos, CrowdStrike). Any detection strategy centered on catching malicious files is defending a perimeter attackers have already walked around.
The reason blocklists fail is structural, not a tuning problem. LOLBins are legitimate, signed, and often required for the business to run. Blocking cmd.exe, PowerShell, or Remote Desktop wholesale would break administration, deployment, and support. CISA states the core problem plainly: there is no conventional IOC list for this activity, because the activity uses tools that are supposed to be there (CISA).
The signal moved from what a file is to what a process does. A signed binary is not suspicious on its own. A signed binary invoked by an unusual parent, followed by a scripting engine, followed by an outbound connection to a new destination, is a suspicious sequence even when every individual step is allowed. Process lineage, command-line intent, and sequence anomalies are the durable detections.
Detection depends on knowing your own normal. You cannot alert on deviation from a baseline you never built. CISA's headline recommendation is to establish and continuously maintain behavioral baselines and to automate the comparison of live activity against them (CISA). The organizations that catch LOTL are the ones that profiled how their own administrators use sensitive tools.
No LOTL detection is real until it is tested under realistic attack. Coverage on a slide is a hypothesis. The only way to know whether your telemetry, analytics, and analysts catch living-off-the-land tradecraft is to safely emulate it and measure what fires. Detection engineering plus red and purple teaming, mapped to ATT&CK, turns assumptions into evidence.
Methodology
This explainer draws on primary telemetry reports, government guidance, and framework and vendor documentation published between February 2024 and June 2026, with a research cutoff of July 1, 2026. The sources and their data windows: the Sophos 2025 Active Adversary Report, built from 413 incident-response and managed-detection cases in 2024; CrowdStrike's 2026 Global Threat Report, covering full-year 2025 telemetry; the Red Canary 2026 Threat Detection Report, covering nearly 60,000 confirmed threats across 1,000-plus customers in 2025; the CISA, NSA and FBI joint guidance "Identifying and Mitigating Living Off the Land Techniques," dated February 7, 2024; MITRE ATT&CK, including technique T1218 and the April 2026 v19 update; Microsoft's App Control for Business documentation; and the community-maintained LOLBAS project catalog.
Every numeric claim was verified against the named primary publisher during the research pass, and each source URL was confirmed reachable. Figures that could not be confirmed against a primary source were dropped rather than estimated, which is why the LOLBAS figure is stated as "more than 150 binaries" rather than a precise total the project does not publish. This article intentionally stays at the concept-and-defense level on offensive detail: it names the tools and the behaviors, describes which telemetry each targets, and explains how to detect them, without operational instructions or abuse recipes. Attribution is inline throughout and consolidated in the References section.
What living off the land actually means
Living off the land is the practice of accomplishing attacker goals with the legitimate tools already present on a system rather than with custom malware. The tools themselves are called LOLBins, short for living-off-the-land binaries, and the community effort that catalogs them is the LOLBAS project, for living-off-the-land binaries, scripts, and libraries. To qualify, a binary has to be a native, Microsoft-signed part of the operating system or a common Microsoft application, and it has to be usable for something beyond its intended purpose, such as executing code, downloading a file, or bypassing a control. The catalog runs to more than 150 Windows binaries, plus scripts and libraries, and each entry is mapped to the MITRE ATT&CK techniques it enables.
The names are unremarkable, and that is the point. The Windows Command Shell and PowerShell are scripting engines every administrator uses. Remote Desktop is how support teams reach machines. Utilities for querying the network, managing volume shadow copies, or reading the event log exist because operators need them. Sophos found that the most-abused Microsoft binaries in 2024 were exactly these everyday tools: cmd.exe topped its managed-detection cases and Remote Desktop Protocol topped its incident-response cases, with PowerShell, wevtutil.exe, and vssadmin.exe among the leaders, and a 70% overlap between the two datasets (Sophos). The abuse extends to trusted third-party software too, with legitimate tools such as SoftPerfect Network Scanner, AnyDesk, WinRAR, and Advanced IP Scanner frequently repurposed.
MITRE gives this behavior a formal home. System Binary Proxy Execution (T1218) describes how adversaries "bypass process and/or signature-based defenses by proxying execution of malicious content with signed, or otherwise trusted, binaries," and it lists 14 sub-techniques covering utilities like Rundll32, Mshta, Regsvr32, and Msiexec (MITRE ATT&CK). In the broader picture, LOTL is one of the four evasion categories we cover in our companion piece on EDR evasion in 2026; this article zooms into that one category because it is the hardest to block and the most common to encounter.
The reason LOTL keeps growing is that it works, and it is cheap. It requires no malware development, it leaves few scannable artifacts, and it rides on the same shift toward logging in rather than breaking in. Sophos saw External Remote Services paired with Valid Accounts in 78% of cases, with Remote Desktop present in 84% (Sophos). Once an adversary holds valid credentials and uses trusted tools, they look, to most controls, exactly like a busy administrator.
Why you cannot just blocklist LOLBins
The intuitive first reaction to a list of dangerous binaries is to block them. It does not work, for a chain of reasons that compound.
They are legitimate and required. You cannot remove the Windows Command Shell, PowerShell, Remote Desktop, or the utilities your operations depend on without breaking the business. A blocklist that includes the tools administrators use every day is a blocklist that gets an exception the same afternoon. The utility is not malware you can quarantine; it is infrastructure.
They are signed and trusted, so signatures and reputation pass. LOLBins are Microsoft-signed and native, which means signature validation, allowlisting, and reputation services all return "trusted," because the tool genuinely is. This is the exact property MITRE describes in T1218: proxying malicious content through a signed binary lets it "execute on Windows systems protected by digital signature validation" (MITRE ATT&CK). The check is not broken. It is answering the wrong question. It confirms the tool is trusted, not that this particular use of it is benign.
There is no indicator to match. Traditional detection compares observed artifacts against known-bad indicators. LOTL produces almost none. CISA, NSA, and FBI put it directly in their joint guidance: "there is no conventional list of indicators of compromise (IOCs) associated with LOTL activities" (CISA). When the file hash is a legitimate Windows binary and the process name is one your fleet runs thousands of times a day, indicator matching has nothing distinctive to grab.
Default logging often misses it, and the noise buries what remains. The same guidance notes that "system logs are generally left in default configuration, which means that LOTL techniques may not be logged, and logging information may be insufficiently detailed to allow differentiation and detection," and that defenders face "the sheer volume of relevant log data compared to the small number of logged malicious activities" (CISA). Even when the activity is technically recorded, the malicious sequence is a handful of events hiding inside millions of identical benign ones. CISA also warns that "security teams often rely primarily on endpoint detection systems, which are unlikely to alert to LOTL activities" out of the box.
Put together, these are why a static, block-the-bad-thing model loses to LOTL. The tool is allowed, the signature is valid, there is no IOC, and the evidence is either not logged or drowned in noise. Blocking is the wrong verb. The right verb is detecting, and detecting means changing what you look at.
How detection shifted from signatures to behavior
You cannot identify LOTL by what the file is, so you identify it by what the process does and in what order. That is the shift, from static signatures to behavior and sequence analytics, and it is where defenders regain the advantage.
Modern endpoint detection does not just ask whether a binary is known-bad. It reconstructs the story of execution: which process spawned which, with what command line, touching which files, opening which network connections, in what sequence. Three properties of that story carry most of the detection value against LOTL.
Process lineage. The parent-child relationship between processes is one of the strongest tells. A signed scripting engine is normal. A signed scripting engine spawned by a document viewer, or by a service that has no business launching it, is a lineage anomaly. The individual process is trusted; the ancestry is not.
Command-line intent. The same binary is benign or hostile depending on what it is told to do. Analytics that parse command-line arguments can distinguish routine administrative invocations from ones whose parameters indicate download, remote execution, credential access, or log tampering. This is why detailed command-line logging is a prerequisite for LOTL detection, and why default logging is not enough.
Sequence and baseline. The highest-value signal is the chain. A trusted utility running from an unusual parent, at an unusual time, on a host that never uses it, feeding a step that ends in credential access or an unfamiliar outbound connection, is an anomalous sequence even though every step is individually allowed. Scoring that requires a baseline: a model of what normal administrative use of each sensitive tool looks like in your environment.
This is exactly what CISA recommends. Its guidance tells defenders to "establish and continuously maintain baselines" of network, user, administrative, and application activity, and to "build or acquire automation (such as machine learning models) to continually review all logs to compare current activities against established behavioral baselines and alert on specified anomalies" (CISA). It is also where AI-augmented detection earns its place. The same machine-learning capability that lets attackers iterate faster lets defenders learn the normal shape of activity per host and per user and surface deviations at machine speed, which matters when breakout times are measured in minutes (CrowdStrike). AI-augmented EDR increasingly flags LOTL through sequence-of-operation anomalies rather than static rules, precisely because a signed binary in an untrusted order is something a behavior model can score even when no signature applies.
How to detect and defend against living off the land
This is the heart of the piece. The practices below form a program, not a product purchase, and they map directly onto the reasons blocklists fail. Each one turns a property attackers rely on into a detection or a cost.
Baseline normal usage of every sensitive tool
You cannot blocklist the tools your administrators rely on, so profile them instead. For each sensitive dual-use utility, learn what normal looks like: which hosts use it, which parent processes invoke it, at what times, by which accounts, and toward what ends. Then alert on the outliers. A utility running on a host that never uses it, spawned by an unexpected parent, or feeding a chain that touches credentials or an unfamiliar network is the deviation worth paging on. This is the single most important move, because it converts the attacker's advantage, that the tool is allowed, into your detection, that this use of the tool is abnormal. CISA places baselining at the center of its LOTL guidance for exactly this reason (CISA).
Invest in behavior, lineage, and sequence analytics
Prioritize detections that reason over relationships and order, not just single events. Process lineage, the chain from a document open to a scripting engine to a network connection, and command-line intent are what catch an operation that uses only trusted tools in an untrusted sequence. Content rules that match known indicators remain useful for cheap, high-confidence catches, but they cannot be the center of gravity against activity that produces no distinctive indicator. This is also where AI-augmented analytics pays off, by scoring anomalies no static rule anticipated.
Fix logging first, then centralize it out of band
LOTL detection is impossible without the right telemetry, and default configurations do not capture it. Turn on detailed process-creation and command-line logging, script-block logging for scripting engines, and the event sources that record how sensitive utilities are used. Then aggregate those logs, as CISA advises, "in an out-of-band, centralized location that is write-once, read-many to avoid the risk of attackers modifying or erasing logs" (CISA). Treat the integrity of that telemetry as a control in its own right: a log source that unexpectedly goes quiet is itself a signal, a theme we develop further in our companion piece on EDR evasion. Then reduce alert noise by fine-tuning on priority so the small number of malicious events is not lost in the volume.
Apply application control where it is feasible
You cannot remove the operating system's own tools, but you can constrain how untrusted code and scripts run around them. Microsoft frames application control as a fundamental shift: it "changes Windows from a place where all code runs unless your AV solution confidently predicts it's bad, to one where code runs only if your policy says so," and it extends beyond apps to scripts, installers, batch files, and PowerShell in Constrained Language Mode (Microsoft). Government bodies including the Australian Signals Directorate cite application control as one of the most effective controls against executable file-based malware. It is not a replacement for endpoint detection or antivirus, and it will not by itself stop the abuse of a tool your policy already trusts, but constrained scripting modes and curated block rules raise the cost of the on-ramp and narrow what an adversary can run.
Enforce least privilege and segment the network
LOTL rides on valid accounts and lateral movement. Sophos found External Remote Services paired with Valid Accounts in 78% of cases (Sophos). Least privilege limits what a single compromised identity can reach, and network segmentation limits how far a trusted tool can carry an adversary. Because attackers now log in more than they break in, identity monitoring belongs alongside endpoint monitoring; our breakdown of device code phishing and session theft shows how a stolen session becomes the foothold that LOTL then extends.
Assume breach and shrink the response window
With breakout times around 29 minutes and the fastest at 27 seconds, the plan cannot depend on catching everything at the front door (CrowdStrike). Assume an adversary will get a foothold and design to detect and contain fast: tested incident-response playbooks, the ability to isolate a host and revoke sessions quickly, and detections tuned for the post-foothold behaviors, lateral movement, credential access, and discovery, that LOTL is used to perform.
Validate everything with red team and purple teaming mapped to ATT&CK
Detection you have never tested is a belief, not a control. Map your LOTL detections onto the MITRE ATT&CK techniques your telemetry can actually observe, find the blind spots, and then prove the rest fires by safely emulating the tradecraft. Red team and adversary-simulation engagements exercise the full chain, from a quiet on-ramp through living-off-the-land movement with trusted binaries to attempts at credential access, and measure exactly what your sensors saw and what your analysts alerted on. Purple teaming closes the loop by pairing that offensive test with your defenders and detection engineers in real time, so every gap becomes a new or tuned detection before the exercise ends. Done against the ATT&CK map, this converts "we log command lines" into measured, evidence-backed coverage of the techniques that matter.
How Stingrai helps
The uncomfortable truth about living off the land is that a healthy-looking dashboard does not tell you whether your analytics would catch a real operator using your own tools against you. A baseline can look complete and still miss the one host, parent process, or sequence your environment never trained on. A command-line logging policy can be set and still leave a segment or a service account unmonitored. The only way to know is to test it under realistic attack.
Stingrai is an offensive security and PTaaS firm founded in 2021, headquartered in Toronto with a London office, and a firm-level CREST-accredited penetration testing service provider. For living-off-the-land detection we lead with our human red team. Our red team and adversary simulation engagements safely emulate modern LOTL tradecraft, the quiet initial-access on-ramp, movement with trusted signed binaries, and the credential-access steps that follow, then measure precisely whether your telemetry, analytics, and SOC detect it. Our purple teaming work pairs that offensive test with your defenders and detection engineers so each gap becomes a tuned detection mapped to MITRE ATT&CK, not just a finding in a report. Our adversary simulation case study shows what that full-chain validation looks like in practice. Snipe, our autonomous AI agent, covers the web-application layer by hunting complex authorization and business-logic flaws, while the human red team owns the endpoint, Active Directory, and living-off-the-land detection work that this topic demands.
The output is evidence you can act on and evidence your auditors accept. Stingrai's penetration testing, red team, and purple team assessments support your SOC 2, ISO 27001, PCI DSS, and HIPAA compliance programs by demonstrating that your detection and response controls hold under realistic attack. For engagement scoping and pricing, see the Stingrai pricing page.
Frequently asked questions
What is living off the land and what are LOLBins?
Living off the land is the practice of achieving attacker goals with the legitimate, signed tools already present on a system rather than with custom malware. LOLBins are those living-off-the-land binaries, the native operating-system and administrative utilities that can be repurposed, and the community LOLBAS project catalogs more than 150 Windows binaries, plus scripts and libraries, mapped to the MITRE ATT&CK techniques they enable (LOLBAS, MITRE ATT&CK). It matters because LOTL is now mainstream: Sophos measured a 126% year-over-year rise in unique LOLBins abused, and CrowdStrike found 82% of 2025 detections were malware-free (Sophos, CrowdStrike).
Why can't you just blocklist LOLBins?
Because they are legitimate tools your business depends on, they are Microsoft-signed so signature and reputation checks pass, and there is no distinctive indicator to match. CISA, NSA, and FBI note that "there is no conventional list of indicators of compromise (IOCs) associated with LOTL activities," and that default logging often does not capture the abuse in the first place (CISA). Removing cmd.exe, PowerShell, or Remote Desktop would break administration, so the answer is detecting abnormal use, not blocking the tool.
How do you detect living-off-the-land attacks?
You baseline normal use of each sensitive utility, then alert on deviations using behavior, lineage, and sequence analytics. The contextual tells are an unusual parent process, an unusual host or time, or a chain that ends in credential access or an unfamiliar network connection. CISA recommends maintaining behavioral baselines and automating the comparison of live activity against them to alert on anomalies, which is why baselining plus sequence analytics beats static rules against activity that produces no distinctive indicator (CISA).
What logging do I need to catch LOTL?
You need detailed process-creation and command-line logging, script-block logging for scripting engines, and the event sources that record how sensitive utilities are used, because default configurations frequently miss LOTL activity. CISA advises aggregating those logs in an out-of-band, centralized location that is "write-once, read-many" so an attacker cannot modify or erase them, and then reducing alert noise so the few malicious events are not buried in the volume (CISA).
Does application control stop LOLBin abuse?
Application control helps but does not solve it alone. Microsoft's App Control for Business shifts Windows to run "only if your policy says so" and extends to scripts, installers, and PowerShell in Constrained Language Mode, and government bodies rate application control among the most effective controls against executable malware (Microsoft). It raises the cost of running untrusted code, but it will not by itself stop the abuse of a tool your policy already trusts, so it belongs alongside behavior-based detection rather than instead of it.
How do we prove our SOC actually detects LOTL?
You test it. Red team and adversary-simulation engagements safely emulate the full living-off-the-land chain and measure exactly what your telemetry and analysts detected, and purple teaming turns each gap into a tuned detection in real time, mapped to MITRE ATT&CK. This is the work Stingrai does to convert "we log command lines" into measured, evidence-backed detection coverage of the techniques that matter.
References
Sophos. It Takes Two: The 2025 Sophos Active Adversary Report. April 2025. https://www.sophos.com/en-us/blog/2025-sophos-active-adversary-report. Analysis of 413 incident-response and MDR cases: a 126% year-over-year rise in unique LOLBins abused, cmd.exe and RDP as the top abused binaries, and RDP present in 84% of cases.
CrowdStrike. 2026 Global Threat Report: findings. 2026. https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-global-threat-report-findings/. Full-year 2025 telemetry: 82% malware-free detections, a 29-minute average eCrime breakout time, and an 89% increase in AI-enabled adversary activity.
Red Canary. 2026 Threat Detection Report. 2026. https://redcanary.com/threat-detection-report/techniques/. Nearly 60,000 confirmed threats across 1,000-plus customers; PowerShell and Windows Command Shell rank as the second and third most-observed techniques.
CISA, NSA, and FBI. Identifying and Mitigating Living Off the Land Techniques (Joint Guidance). February 7, 2024. https://www.cisa.gov/sites/default/files/2025-03/Joint-Guidance-Identifying-and-Mitigating-LOTL508.pdf. Why LOTL evades conventional detection and the recommended baselining, anomaly-detection, logging, and hardening practices, informed by Volt Typhoon incident response.
MITRE ATT&CK. System Binary Proxy Execution, Technique T1218 (Enterprise). 2026. https://attack.mitre.org/techniques/T1218/. Definition of proxying execution through signed, trusted binaries to bypass signature defenses, with 14 sub-techniques.
LOLBAS Project. Living Off The Land Binaries, Scripts and Libraries. 2026. https://lolbas-project.github.io/. Community-maintained catalog of more than 150 legitimate, signed Windows binaries, plus scripts and libraries, mapped to MITRE ATT&CK.
Microsoft. Application Control for Windows (App Control for Business). March 2026. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/appcontrol. How application control shifts Windows to run only policy-approved code and extends to scripts and Constrained Language Mode, and why it complements rather than replaces antivirus.
MITRE ATT&CK. Updates: April 2026 (v19). April 28, 2026. https://attack.mitre.org/resources/updates/updates-april-2026/. Split of the Defense Evasion tactic into Stealth and Defense Impairment, useful context for mapping LOTL detection coverage.
