Detection Engineering advanced T1218

Living Off the Land in 2026: Stop Detecting the Binary, Detect the Chain

LOTL didn't add binaries. It commoditized chaining and moved to where EDR can't run. Stop detecting the binary. Detect the chain.

· 15 min read · Gowthamaraj Rajendran

Open the LOLBAS project, GTFOBins, or LOLESXi [7] and you get the same thing: a catalog of binaries. Each entry tells you a legitimate, signed, pre-installed tool can be abused, and how. It is a genuinely useful reference. It is also, quietly, the reason most living-off-the-land detection does not work, because it trains you to think about the wrong unit.

The catalog is a list of binaries. So teams build a list of binary signatures: alert when certutil downloads a file, alert when rundll32 runs from a temp path, alert when esxcli deletes snapshots. And then one of two things happens. Either the rule fires constantly, because the binary is a tool your admins use all day, and you tune it into oblivion. Or it never fires, because the attacker used the binary in a way your one signature did not anticipate, buried inside a sequence of five other legitimate tools where every individual step looks completely normal.

Living off the land did not get more dangerous in 2026 because someone found new binaries. It got more dangerous because attackers commoditized the chain and moved it to places your endpoint agent cannot see. The detection that works is not a better binary signature. It is detection of the chain.

The Catalog Is the Wrong Unit

Here is the uncomfortable structural problem. A living-off-the-land binary is, by definition, a legitimate tool. wmic, netsh, ntdsutil, esxcli, bash, certutil: every one of them exists because an administrator needs it. The execution of the binary is not the signal. It cannot be, because the same execution happens a thousand times a day for legitimate reasons.

This is why single-binary LOLBAS rules have the worst false-positive reputation in the Sigma ecosystem. The public rule repositories are full of overlapping, high-noise rules for the same technique, contributed by different people, each firing on “this binary ran with this flag”, and each one lands in your SIEM as a stream of alerts that are almost always benign. That is not a tuning failure you can fix with a better allowlist. It is the wrong detection unit. You are alerting on a thing that is legitimate the overwhelming majority of the time and asking analysts to sort it out by hand. That is exactly the manufactured-queue problem I described in Alert Fatigue Is an Offensive Technique: noise you generate on a high-volume, mostly-benign event is a gift to the attacker who wants your analysts tired.

The steelman here is EDR: “modern behavioral EDR already handles this: it graphs process relationships and command-line arguments, it doesn’t just match binary names.” That is partly true and worth taking seriously. EDR is genuinely good at catching a single binary being abused in isolation. But two things break it, and the data is not subtle.

First, EDR is a per-endpoint, largely per-process verdict engine, and it struggles on chains where each step is individually benign. Analysis of EDR performance against living-off-the-land techniques consistently shows the worst detection rates on exactly the behaviors that only make sense as a sequence: an endpoint agent without cross-event correlation cannot decide whether one legitimate step is malicious at the provenance level. The attacker is not hiding a binary. They are hiding in the relationship between binaries, and a verdict engine that scores processes one at a time is looking at the wrong thing.

Second (and this is the part that should change how you budget) the attack moved to where EDR does not run at all. More on that below.

The scale of the shift is documented. CrowdStrike’s 2026 Global Threat Report found 82% of detections in 2025 were malware-free: intrusions that moved through valid credentials and trusted, signed system tools rather than droppable, scannable payloads [1]. Sophos, across 413 incident-response cases in its 2025 Active Adversary Report, measured a 51% year-over-year increase in the abuse of living-off-the-land binaries, with PowerShell the single most common post-compromise tool [2]. The payload era is what EDR was built for. This is not that era.

What Actually Changed in 2025-26

Three shifts, and none of them is “a new binary.”

Chaining became commodity tradecraft. The technique that used to mark a patient nation-state operator (stitch together six native tools so nothing you drop is scannable) is now standard across ransomware affiliates. The catalogs of tactics converged: Volt Typhoon, APT28, and financially-motivated crews like Black Basta and FIN7 now reach for nearly identical binaries. When a ransomware affiliate uses PsExec to run a command on a remote host, the endpoint sees a legitimate administrative action, because it is one. The differentiator between the APT and the ransomware crew is no longer their tooling. It is gone.

A few genuinely under-covered binaries surfaced. Most LOLBins are noisy because they are common. The dangerous exceptions are the rare ones: obscure enough that most teams have never built a detection, legitimate enough to be signed by Microsoft. In February 2025, Trend Micro documented Mustang Panda (Earth Preta) abusing MAVInject.exe, the Microsoft Application Virtualization Injector, to inject its TONESHELL backdoor into the legitimate waitfor.exe process, but only when it detected ESET antivirus running [3]. MAVInject is obscure enough that detection coverage is thin, and it is signed, so signature tools wave it through.

This is the one honest carve-out to the “detect the chain” argument, so let me name it plainly: for a binary this rare, mere execution is high signal. Nobody’s helpdesk runs MAVInject. The same is true for ntdsutil on a finance analyst’s workstation, or netsh portproxy on a print server. Where a binary has near-zero legitimate use in a given context, a single-binary rule earns its keep. That set is small, and you should enumerate it deliberately: the rare-binary allowlist-inverse is real, high-value detection. Everything outside that small set needs the chain.

The attack relocated to where EDR cannot run. This is the big one. In 2025, Scattered Spider (UNC3944) industrialized ransomware deployment straight from the VMware ESXi hypervisor, using the native esxcli and vim-cmd tools to terminate every VM, delete their snapshots, and encrypt the datastore [4]. The reason this works is not cleverness. It is that the ESXi hypervisor and the vCenter appliance cannot host an EDR agent. There is no endpoint sensor at the virtualization layer. The attacker who reaches the hypervisor is operating in a place your entire endpoint detection strategy is structurally blind to, and they are using only the hypervisor’s own built-in commands to do it. LOLESXi exists as a catalog for the same reason LOLBAS does, but the stakes are higher because there is no agent watching.

The same visibility gap exists on Linux, where telemetry usually comes from auditd rather than a rich EDR sensor, and in cloud control planes, where the “binary” is an API call. The GTFOBins problem is the LOLBAS problem in an environment where your instrumentation is thinner to begin with.

The Chain Is the Detectable Unit

If the binary is the wrong unit, the chain is the right one. And a chain is not one field. It is three, joined: the sequence (which tools, in what order), the ancestry (what spawned what), and the context (which user, at what time, on what kind of host, doing what). Five Eyes guidance says the same thing in operational terms: separate malicious from routine living-off-the-land use with heuristics like process ancestry, user role, and time-of-day [5]. No single one of those is a detection. Their intersection is.

Make it concrete with a real, fully-documented chain. Volt Typhoon’s Active Directory theft, as detailed in the joint CISA advisory, runs like this [6]:

wmic  ─spawns─▶  cmd.exe  ─runs─▶  ntdsutil.exe "ac i ntds"
                                    "ifm create full C:\Windows\Temp\tmp\temp.dit"
        then, separately:
netsh interface portproxy add v4tov4 ...   (on a PRTG server → C2 proxy)

Look at what is and is not detectable here. wmic is legitimate. cmd.exe is legitimate. ntdsutil is legitimate. It is the tool administrators use to maintain the AD database. netsh is legitimate. Every binary passes a single-binary review. What does not pass is the relationship: ntdsutil spawned by cmd.exe spawned by wmic, doing an ifm create full that writes the entire AD database (every hash in the domain) to a temp directory. And separately, a netsh portproxy rule turning a monitoring server into a network proxy, which that server has no business being. The ancestry is the tell. The target path (ntds.dit to C:\Windows\Temp) is the tell. The role mismatch (a PRTG box becoming a proxy) is the tell. The binaries are all innocent.

That is the shape of every LOLBin detection worth writing: not “did this binary run,” but “did this sequence run, with this ancestry, in a context where it makes no sense.” You are looking for a grammar, not a word.

Instrument Where EDR Cannot

Detecting the chain assumes you can see the chain. On the endpoint, you mostly can: process-creation events with parent-child fields (Sysmon Event ID 1, Windows 4688 with parent process auditing enabled, or your EDR’s raw telemetry piped to the SIEM) give you ancestry and command line. The gap is everywhere EDR does not run, which is precisely where the attack went.

Closing that gap is a telemetry job, and it belongs to the SIEM, not the endpoint team:

  • ESXi and vCenter. Forward the ESXi shell logs and vCenter events (hostd, vpxd, and the shell command audit) to your SIEM. This is the only place you will ever see esxcli and vim-cmd abuse, because there is no agent on the box. When someone confirms this is aspirational in their shop, they are usually right, and that is the finding, not an excuse. If your hypervisors are dark, your most business-critical assets have no detection at all.
  • Linux. auditd (or a modern eBPF-based collector) shipping execve records with parent PID and UID gives you the ancestry and role context GTFOBins abuse requires. Thin, but real.
  • Cloud control planes. CloudTrail, Azure activity logs, and their equivalents are where the “binary” is an API call: the same chain logic, applied to control-plane actions.

This is the coverage-versus-reality gap from The Detection Funnel in its sharpest form: your ATT&CK coverage report can show green for a technique your telemetry physically cannot observe, because the sensor does not exist on the asset. And once the telemetry is flowing, the chain rules that run on it are exactly the kind of tested, versioned, correlation-heavy logic that belongs in a detection-as-code pipeline: because a chain rule with process ancestry and a time window is not something you hand-edit in a console and hope.

One Rule: A Chain, Not a Binary

Here is the ESXi ransomware-precursor chain as a Sigma rule. It is deliberately not a single-binary detection. It fires only when the sequence closes on one host in a short window. Every individual action in it is something a legitimate administrator might do; the three of them together, fast, are what a ransomware operator does right before they encrypt.

# Detection rationale: ransomware on ESXi is deployed with the hypervisor's own
# native tools (esxcli, vim-cmd), on a host that cannot run EDR. No single command
# is malicious: enabling SSH, disabling lockdown mode, and removing snapshots are
# all legitimate admin actions in isolation. The ATTACK is the SEQUENCE, an
# operator preparing a host for encryption performs all three in quick succession,
# which no routine maintenance does. This keys on the chain closing per-host in a
# short window, not on any one binary. It runs on forwarded ESXi shell / vCenter
# logs precisely because there is no endpoint agent at the virtualization layer.
title: ESXi Ransomware Precursor Chain: SSH Enabled, Lockdown Disabled, Snapshots Purged
status: experimental
logsource:
  product: vmware
  service: esxi          # forwarded ESXi shell audit / vCenter (vpxd, hostd) syslog
detection:
  enable_ssh:
    action:
      - 'vim-cmd hostsvc/enable_ssh'
      - 'TSM-SSH*Enabled'          # ESXi service-state change to SSH running
  disable_lockdown:
    action:
      - 'vim-cmd hostsvc/lockdown_disable'
      - 'Lockdown mode disabled'
  purge_snapshots:
    action:
      - 'vim-cmd vmsvc/snapshot.removeall*'
      - 'esxcli*snapshot*remove*'
  # The chain is the detection: all three legs on ONE host inside the window.
  # In deployment this is a Sigma correlation rule (or a SIEM stats-by-host join),
  # not a flat AND: grouping and timespan are what make it precise.
  condition: enable_ssh and disable_lockdown and purge_snapshots
  correlation_scope:
    group_by: [ 'esxi_host' ]
    timespan: 30m
falsepositives:
  - Genuine maintenance or a backup job that legitimately clears snapshots, but the
    SSH-enable + lockdown-disable pair alongside it is unusual; baseline your change
    windows and allowlist known maintenance operators
  - A vSphere admin troubleshooting over SSH: confirm against a change ticket; the
    snapshot purge is the leg that separates troubleshooting from staging
level: high
tags:
  - attack.impact
  - attack.t1490          # Inhibit System Recovery (snapshot/backup destruction)
  - attack.t1562.001      # Impair Defenses (disable lockdown mode)

Living-off-the-land does not map to a single ATT&CK technique. That is the point. This chain alone touches Impair Defenses (T1562.001) and Inhibit System Recovery (T1490); the Volt Typhoon example above spans System Binary Proxy Execution (T1218), OS Credential Dumping via ntdsutil, and Proxy via netsh. Tag the chain by what its legs actually do, and let the rule roll up across tactics instead of forcing it into one technique ID that undersells it.

One rule does not cover the space. It shows the shape: a per-host, per-window correlation across legitimate actions, keyed on the sequence and its context rather than any binary you could name.

The Bigger Ask: Shrink the Surface, Then Watch It

You cannot uninstall the operating system’s own tools. That is what makes this hard and it is also why prevention here is about reducing availability and context, not removing binaries:

  • Application control and allowlisting (WDAC, AppLocker) and PowerShell Constrained Language Mode shrink which LOLBins can run where. A certutil or rundll32 that is blocked on a workstation that never needed it is one fewer leg available for a chain.
  • ESXi lockdown mode and execInstalledOnly, plus disabling SSH by default, make the hypervisor chain above harder to even start, which is why an operator disables lockdown as their first move, and why that disable is such a good detection leg.
  • Close the EDR-blind spots by forwarding logs. The single highest-value LOTL project most teams have not done is getting hypervisor and Linux telemetry into the SIEM. You cannot detect a chain on a host you receive nothing from.

Detection and prevention reinforce each other here in a specific way: the same act that shrinks the attack surface (disabling SSH, enforcing lockdown, allowlisting binaries) also creates the high-signal event when an attacker undoes it. A control you enforce is a tripwire when someone turns it off. That is the prevention-first spine I keep coming back to, from the identity kill chain onward: you shift left to stop what you can, and the leftover (the attacker stepping over the control you set) becomes your cleanest detection.

Closing

The catalog told you which binaries can be abused. It was never going to tell you which sequences mean you are being robbed, because the danger was never in the binary. ntdsutil is not malicious. esxcli is not malicious. wmic spawning cmd spawning ntdsutil writing the domain’s password hashes to a temp folder is malicious, and you can only see that if you are looking at the chain instead of the link.

So stop scoring binaries. Enumerate the rare ones where execution alone is signal, and for everything else (which is almost everything) detect the sequence, the ancestry, and the context. Then go get telemetry off the hypervisors and the Linux hosts your endpoint agents were never going to reach, because that is where the attacker went specifically to be unseen. The binary was always legitimate. The chain is the tell.

Resources

  1. CrowdStrike 2026 Global Threat Report. CrowdStrike, 2026 (82% of 2025 detections were malware-free, using valid credentials and trusted system tools).
  2. It Takes Two: The 2025 Sophos Active Adversary Report. Sophos, April 2025 (413 IR cases; 51% year-over-year increase in living-off-the-land binary abuse; PowerShell the most common post-compromise tool).
  3. Earth Preta Mixes Legitimate and Malicious Components to Sidestep Detection. Trend Micro, February 2025 (Mustang Panda abuses signed MAVInject.exe to inject TONESHELL into waitfor.exe).
  4. Defending vSphere from UNC3944. Google Cloud / Mandiant, 2025 (Scattered Spider deploys ransomware from the ESXi hypervisor using native esxcli and vim-cmd, bypassing EDR).
  5. Identifying and Mitigating Living Off the Land Techniques. CISA and Five Eyes joint guidance (heuristics: process ancestry, user role, time-of-day to separate malicious from routine LOTL use).
  6. AA24-038A: PRC State-Sponsored Actors Compromise US Critical Infrastructure (Volt Typhoon). CISA, 2024 (documented wmic → cmd → ntdsutil AD-dump chain and netsh portproxy C2 proxy).
  7. LOLBAS Project. The reference catalog of Windows living-off-the-land binaries and scripts; see also GTFOBins (Linux/Unix) and LOLESXi (VMware ESXi).