Living Off the Land: Detecting Attackers Who Use Your Own Tools

There is a category of intrusion that produces no malware sample. No dropped executable, nothing for the endpoint agent to quarantine, no hash to submit anywhere. The adversary achieves execution, persistence, discovery and exfiltration using programs that shipped with the operating system, are signed by the vendor, and appear on every allowlist in the building.

This is living off the land, and it is the default tradecraft of competent intruders for an obvious reason: it works, and it defeats the entire category of controls built around identifying bad files.

Why the technique is so effective

Traditional endpoint defence answers the question “is this file malicious?” Living off the land makes that question meaningless. The file is certutil.exe. It is genuinely Microsoft’s, genuinely signed, and genuinely present on every Windows host for legitimate certificate work. Neither the hash nor the signature nor the path is anomalous, because nothing about the binary is.

What is anomalous is the usage. A certificate utility that suddenly downloads a file from the internet and decodes it is doing something no administrator ever intended it to do, even though every individual attribute of the process looks impeccable.

Three properties make these binaries attractive. They are pre-installed, so nothing must be delivered to disk. They are trusted, so allowlisting and reputation checks pass. And their execution is often proxied through a signed Microsoft process, which means the malicious behaviour is attributed to a binary defenders are reluctant to block outright.

The binaries that matter most

The community catalogues these as LOLBAS — living off the land binaries, scripts and libraries. The list is long, but a small set accounts for most real-world abuse.

powershell.exe — the most flexible option available. In-memory execution, remoting, and full .NET access, all without touching disk.
certutil.exe — intended for certificate management, routinely abused to download remote files and to Base64-decode payloads.
rundll32.exe and regsvr32.exe — proxy execution of arbitrary DLLs and scriptlets through a signed binary.
mshta.exe — executes HTML applications, meaning script content wrapped in markup, frequently fetched remotely.
wmic.exe — discovery, and process creation on remote hosts, making it a lateral movement staple.
bitsadmin.exe — transfers files using the Background Intelligent Transfer Service, so the download survives reboots and blends with update traffic.
msbuild.exe — compiles and executes C# embedded in a project file, on a developer tool present far more widely than most teams realise.

Notice what these have in common: every one of them has a narrow legitimate purpose and a much broader capability that the legitimate purpose never requires.

The detection shift

Because the binary is not the signal, detection must rest on context. Four dimensions carry nearly all of it.

Parent-child relationships

Process lineage is the highest-value signal available, because legitimate software has stable, boring ancestry. winword.exe spawning powershell.exe is not a subtle indicator; it is a document executing code, and outside a handful of documented macros it has no innocent explanation. The same applies to outlook.exe spawning a script interpreter, or a web server process spawning cmd.exe, which is very often the moment a web shell was used.

Command-line arguments

The arguments distinguish administration from abuse. certutil managing a certificate store looks nothing like certutil passed a URL. PowerShell running a signed script from a known path looks nothing like PowerShell with execution policy bypassed, its window hidden and an encoded command supplied. Capturing command lines is the single highest-value logging change most Windows estates can make, and it is off by default.

Network behaviour

Some of these binaries have no business making outbound connections at all. A network connection originating from regsvr32.exe or mshta.exe is worth investigating on its own, independent of arguments, because the legitimate use cases are overwhelmingly local.

Frequency

Most LOLBins are rare in a healthy environment. Stack the execution counts across the estate and the outliers surface quickly. A binary that runs on four hosts out of six thousand is either a niche administrative task or an intrusion, and either way you want to know which.

Getting the telemetry right

None of this works without process creation events that include the full command line. On Windows, that means enabling Audit Process Creation and the accompanying policy that appends command-line arguments to Security event 4688, or deploying Sysmon and using event ID 1, which additionally records the parent image, hashes and the originating user.

For PowerShell specifically, enable script block logging, which records the actual code executed after any layers of encoding or obfuscation are resolved. This matters enormously: an adversary can encode, concatenate, and format-string their way past any rule that inspects only the command line, but script block logging captures what the engine ultimately ran.

# Example shape of a high-signal detection
process_create
WHERE image ENDSWITH \\certutil.exe
  AND (command_line CONTAINS -urlcache
       OR command_line CONTAINS -decode
       OR command_line CONTAINS http)

# Lineage rule, no argument inspection required
process_create
WHERE parent_image IN (winword.exe, excel.exe, outlook.exe)
  AND child_image IN (powershell.exe, cmd.exe, mshta.exe,
                      wscript.exe, cscript.exe, rundll32.exe)

// try it live

Encoded PowerShell payloads are Base64 of UTF-16LE text. Decode one safely, entirely in your browser.

Base64 Decoder

Baselining, and why it is not optional

Every rule above will fire on legitimate activity in some environment. Software deployment tools invoke wmic. Backup agents call unusual binaries. Vendor installers do genuinely alarming things. Deploying these detections without baselining produces an alert storm, and an alert storm produces a disabled rule.

The disciplined approach is to run each detection in monitoring mode first, catalogue what fires, and investigate the top talkers until each has a documented explanation. That catalogue — this parent-child pair is our patch management tool, this scheduled task belongs to the backup agent — becomes an asset in its own right. It is also what lets you write narrow exclusions scoped to a specific parent process and path, rather than the blunt exclusion of an entire binary that quietly removes your coverage.

Be sceptical of exclusions by binary name. Excluding powershell.exe because it is noisy does not reduce false positives; it deletes visibility into the most abused execution mechanism on the platform.

Reducing the surface

Detection is the fallback. Where the capability is genuinely unnecessary, removing it is better.

Application control. WDAC or AppLocker policies can block specific binaries for non-administrative users. Microsoft publishes recommended block rules covering binaries with well-known bypass potential.
Constrained Language Mode substantially limits what PowerShell can do for standard users while leaving ordinary scripting intact.
Attack surface reduction rules directly address the highest-value case: blocking Office applications from creating child processes removes an entire initial-access pattern.
Remove what is unused. Not every workstation needs msbuild.exe, and few need bitsadmin.

The strategic point

Living off the land is not a trick to memorise a list for. It reflects a structural reality: any sufficiently capable operating system ships with enough functionality to be abused, and no allowlist can distinguish intent from binary identity. That is why the durable answer is behavioural.

Detections built on process lineage, argument patterns and frequency survive an adversary swapping certutil for bitsadmin, because they describe what the attacker is trying to accomplish rather than which tool they reached for. Building that way costs more up front in baselining and tuning. It is also the only version of this work that is still effective a year later.

Detection recipes worth deploying

Abstract advice is easy to agree with and hard to action. These are concrete starting points, each of which should be run in monitoring mode and baselined before it alerts.

Signed binaries reaching the internet

Several system utilities have no legitimate reason to make outbound connections on a typical workstation. A network connection attributed to mshta.exe, regsvr32.exe, rundll32.exe or certutil.exe is worth surfacing on its own merits, no argument parsing required. Sysmon event ID 3 provides this directly, attributed to the initiating process.

Interpreters spawned by document handlers

The single highest-value lineage rule in most environments. Office applications, PDF readers and mail clients spawning shells or scripting engines represents document-borne execution, and outside a documented macro estate it has few benign explanations.

Encoded and obfuscated command lines

Long Base64 strings, the -EncodedCommand parameter and its abbreviations, execution-policy bypass combined with a hidden window, and download cradles invoking DownloadString or Invoke-WebRequest are all high-signal. Match on the behaviour rather than an exact string, since parameter names can be abbreviated to any unambiguous prefix — -enc, -ec and -e are all valid.

Remote execution artefacts

Service creation events on workstations, wmic invoked with process call create and a remote node, and scheduled tasks registered against another host all indicate lateral movement. These are individually rare in healthy estates.

# Download cradle, expressed behaviourally
process_create
WHERE image ENDSWITH \\powershell.exe
  AND command_line MATCHES (DownloadString|DownloadFile|Invoke-WebRequest|IWR|Net.WebClient)

# Remote process creation via WMI
process_create
WHERE image ENDSWITH \\wmic.exe
  AND command_line CONTAINS /node:
  AND command_line CONTAINS process call create

Obfuscation, and why script block logging wins

Every command-line detection above can be evaded. PowerShell in particular offers an enormous obfuscation surface: string concatenation, format operators, backtick escapes, character-code arrays, environment-variable substring tricks and case randomisation can all reconstruct a command at runtime that appears nowhere in the literal arguments.

This is why detections resting solely on command-line strings degrade over time against a motivated adversary. Script block logging changes the economics, because it records the code the engine actually executes after those layers resolve. An operator can obfuscate what appears on the command line; they cannot obfuscate what PowerShell ultimately runs, because the engine must deobfuscate it to execute it.

The Antimalware Scan Interface exists for the same reason, providing security products with the deobfuscated content of scripts and macros at execution time. Attempts to disable or tamper with AMSI are themselves a strong detection opportunity, and worth alerting on directly.

Beyond binaries: WMI and scheduled tasks as living-off-the-land

The concept extends past executables to the operating system’s own management infrastructure. WMI event subscriptions provide fileless persistence: a filter defines a trigger condition, a consumer defines the action, and a binding ties them together. Nothing lands on disk, nothing appears in the usual autostart locations, and the persistence survives reboot. Detection means monitoring subscription creation specifically, since it is invisible to tooling that only inspects run keys and startup folders.

Scheduled tasks serve the same purpose with a lower skill requirement, and the Task Scheduler operational log records the full task definition at registration. Both are worth treating as first-class persistence mechanisms rather than afterthoughts, because both are used constantly and neither involves a malicious file.

What good tuning looks like

The difference between a detection that survives and one that gets disabled is almost always the quality of its exclusions. Some principles that hold up in production:

Exclude narrowly. Scope to the specific parent process, path and account that explain the benign activity — never to the binary name alone.
Document why. An exclusion without a recorded justification becomes permanent through nobody daring to remove it.
Review on a schedule. Software changes. An exclusion written for a deployment tool three versions ago may now be a blind spot.
Prefer enrichment to suppression. Where volume permits, downgrade severity rather than dropping the event entirely, so the data remains available for hunting even when it is not alerting.
Watch for exclusion abuse. Adversaries who can read your rules will operate inside them. Exclusions built around a path an unprivileged user can write to are worse than no rule at all.

Where this fits in a defensive strategy

Living off the land is best understood as the natural consequence of successful defence elsewhere. As file-based detection improved, tradecraft migrated to what could not be blocked without breaking the platform. That migration is complete: for competent intruders, custom malware is now the exception during the post-exploitation phase, reserved for objectives the built-in tooling cannot achieve.

The defensive implication is that endpoint protection cannot be the whole answer, because the relevant question is no longer whether a file is malicious. It is whether this usage, by this account, from this parent, on this host, is consistent with how the environment normally behaves. That question can only be answered with context, which is why process lineage, command-line capture and a documented baseline are worth more than any additional signature feed.

References

« The First Hour: A Practical… Threat Hunting: From Hypothesis to… »