Living Off the Land: Detecting Execution That Uses Nothing but Trusted Binaries

Why this defeats file-centric detection#

Every layer of a traditional endpoint stack asks a version of the same question: is this file bad? Hash reputation, static analysis, signature matching and code signing checks all depend on the presence of an artifact that can be judged.

In an intrusion built from native tooling, that artifact does not exist. The interpreter is signed by the platform vendor. The transfer utility ships with the operating system. The scheduling mechanism is a documented administrative feature. Each component is not merely benign — it is required, and blocking it outright breaks legitimate administration.

Where the signal actually lives#

Three telemetry sources carry most of the detection value:

• Process lineage. The binary is unremarkable; its parent frequently is not. A document viewer or a web server worker spawning a command interpreter is a strong signal in almost any environment.
• Command-line arguments. Encoded payloads, download flags, and execution policy overrides appear in arguments rather than in files.
• Frequency and distribution. A utility that runs on four hundred hosts nightly is administration. The same utility running once, on one host, at an unusual hour, is worth a look.

A worked example of intent#

# Detection intent, not a production rule
process_creation
| where parent_image in~ ('document_viewer', 'web_worker', 'mail_client')
| where child_image in~ ('script_host', 'command_shell', 'management_shell')
| where command_line has_any ('-enc', 'downloadstring', '-nop', 'iex')
| summarize count() by host, user, bin(timestamp, 1h)

The final aggregation matters as much as the filter. Alerting on every match produces volume that a team will eventually mute; alerting on rarity within a baseline produces something an analyst can act on.

Building the baseline#

Baselining is where most of these detections succeed or fail, and it is not glamorous work:

1. Collect thirty days of process telemetry without alerting.
2. Rank parent-child pairs by frequency and host spread.
3. Move pairs that appear on a large share of hosts into an explicit allow set, with an owner recorded for each entry.
4. Alert on the remainder, tuned by host count rather than event count.
5. Re-run the ranking quarterly, because deployment tooling changes and stale allow entries become blind spots.

Assessment#

Confidence is assessed as moderate rather than high, for a specific reason: the techniques themselves are well established and not in dispute, but detection efficacy varies substantially with environment size, telemetry retention and administrative practice. A rule that performs well in a homogeneous estate may be unusable in one with heavy local automation.

The realistic goal is not to detect native tooling. It is to make unusual use of native tooling expensive enough to surface, which requires the boring, ongoing work of knowing what normal looks like in one specific environment.