Map

Living Off The Land

Wiki conceptsecurityred-teamdetectionlateral-movement ↳ show in map Markdown
title
Living Off The Land
type
concept
summary
Attack pattern where an intruder uses legitimate, pre-installed system tools (shells, interpreters, package managers, debuggers) instead of dropping malware — harder to detect because every individual command is normal
tags
security, red-team, detection, lateral-movement
created
2026-04-30
updated
2026-04-30

"Living off the land" (LotL) is the security-industry term for an attack pattern where the intruder uses only tools already present on the target system rather than dropping their own binaries. The phrase has been in common red-team / IR vocabulary since the mid-2010s and is the explicit framing of GTFOBins ("a compendium about how to live off the land when you only have certain executables available") and its Windows equivalent LOLBAS.

Why attackers prefer LotL when they can

Three structural advantages:

Detection signal is lower. Antivirus and EDR tools build signatures and behavioral models around malicious binaries. A shell pipeline using find, awk, nc, and bash looks like every sysadmin script ever written — there's no novel binary to flag, no unusual file hash, no suspicious code-signing chain. The malicious instance is statistically indistinguishable from benign use without much higher-context analysis.

Forensic footprint is smaller. No new files written to disk (or only standard cache locations). No modifications to /usr/bin. Evidence lives in process trees, command history, and short-lived network connections — exactly the data sources that have the worst retention in most defender environments.

Capability transfer is cheap. The same awk one-liner works on basically every Linux distribution. Tooling that lives off the land is portable across environments without per-target compilation or compatibility shims. Compare with custom-malware development, which is high-cost and per-target.

Why this is hard for defenders

The defender's problem is that legitimate use of these tools is overwhelming. Every CI runner, every operator's terminal, every cron job, every Ansible playbook is using bash, find, python, tar, curl, jq. You can't alert on "someone ran find" — the false-positive rate would be uncountable. So defense reduces to:

  • Behavioral detection on suspicious combinations — find followed by nc followed by an outbound connection to an unfamiliar IP, in a service account that doesn't normally run those commands.
  • Limit what binaries are even available. Hardened images strip interpreters, debuggers, network tools (nc, curl, wget) from production runtime images. If python isn't installed, the LotL playbook for python doesn't apply.
  • Audit sudo and SUID grants against GTFOBins. When a sysadmin grants sudo find to a developer for one specific reason, that's effectively a shell. The catalog makes the implicit capability explicit; ignoring it is a self-inflicted wound.
  • Restricted shell environments are not security boundaries. rbash, lshell, and similar restrict argv, but if any of the GTFOBins-catalogued binaries are reachable, the restriction is bypassable. Treat them as ergonomic constraints, not access controls.

Where LotL meets credentials

The other half of LotL is using the credentials already present. SSH keys in ~/.ssh, browser cookies, kerberos tickets, kubeconfig files, AWS credentials in ~/.aws, GitHub tokens, IDE auth caches. The attacker doesn't need to phish — the credentials are already on the box, and the threat model in long-lived-keys applies.

This makes ephemeral-credentials a structural defense: short-lived credentials minimize the window in which any captured credential is useful, even if the LotL pattern lets the attacker bypass binary detection entirely.

Linked from