# Living Off The Land

"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|GTFOBins]] ("a compendium about how to live off the land when you only have certain executables available") and its Windows equivalent [LOLBAS](https://lolbas-project.github.io/).

## 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|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.

## Related

- [[gtfobins]] — the canonical Unix-side catalog
- [[long-lived-keys]] — the credential half of the same threat space
- [[ephemeral-credentials]] — structural mitigation for the credential half
- [[supply-chain-security]] — adjacent: pre-runtime version of the same "use trusted plumbing" attack