Living Off the Land: A Valid Signature Is Not a Business Reason

An attacker gets into your environment, opens PowerShell and goes to work with software your own people use every day. Somewhere, a perfectly legitimate binary is helping somebody rob you, and its digital signature is still impeccable.

We supplied the tools. Very generous of us.

Living off the land exploits that uncomfortable overlap between the capabilities an administrator needs and the capabilities an intruder would love to borrow. PowerShell, WMI, netsh and ntdsutil all have legitimate jobs. Give the wrong person sufficient access and those same capabilities can support discovery, credential theft, lateral movement or collection without requiring a new executable for each task.

The interesting question starts after you recognize the program. I want to know what it was asked to do, how the account running it got there, and whether the activity makes sense on that particular machine. Then I want to follow what happened next, including the parts that never earned an alert.

What Volt Typhoon made painfully clear

Microsoft’s May 2023 reporting described Volt Typhoon using valid credentials, creating domain controller installation media with ntdsutil, and configuring traffic forwarding with netsh portproxy. Familiar utilities, useful capabilities, ugly consequences in the wrong hands. Microsoft also published behavioral detections and hunting queries, which matters because this activity leaves evidence defenders can use. (Microsoft, May 2023)

The February 2024 joint advisory from CISA, NSA, FBI and partners reported indications that the actor had maintained access and footholds for at least five years in some victim IT environments. The agencies assessed that Volt Typhoon was positioning itself for potential disruption of critical infrastructure. Five years describes particular observed compromises, not an average across every victim. It is disturbing enough without inflating it. (Joint advisory AA24-038A, February 2024)

There is a temptation to turn that reporting into a sweeping claim that legitimate tools defeat EDR. Modern endpoint products can detect their abuse. Whether yours does depends on the behavior, the evidence it collects and the detections you actually have running. A logo on the architecture diagram settles none of that.

And living off the land can coexist with malware. It describes techniques within an intrusion, not a promise that the attacker traveled light for the entire visit.

Follow the work the account is doing

A matching hash helps identify a binary. A valid signature helps establish its provenance and integrity. Neither supplies a business reason for what someone just did with it.

I have no objection to a good rule catching a specific credential theft pattern. Keep it. What wears people out is a rule that treats every PowerShell launch as a five alarm fire, while the analyst has to discover, for the hundredth time, that the endpoint management team still exists.

Consider a hypothetical hunt. An account signs in remotely to a server it rarely touches, starts enumerating domain systems, then reaches a domain controller and uses ntdsutil to create installation media containing the directory database. Some of that could belong to legitimate administration. The authentication route, the account’s usual responsibilities and the location of the output start to narrow the possibilities. An unexplained transfer afterward deserves a closer look.

Now do the less glamorous part. Establish which sessions and processes connect those events. Check the approved work. Look for evidence that would make your attack theory wrong, because a plausible story can be very convincing when you stop asking awkward questions.

Two events sharing an IP address do not establish a common operator. Several suspicious actions occurring near each other do not automatically establish a compromise. Correlation earns its keep when it makes the evidence clearer. It becomes a liability when it manufactures certainty.

Open the logs before admiring the model

Before debating which model understands malicious commands best, pull actual events from the systems you care about. Check the fields. Check the timestamps. Find out whether the records are reaching the SOC before the incident review meeting does.

Windows Security Event 4688 needs Audit Process Creation enabled, plus the separate setting to include the command line in process creation events. Miss the second setting and you can know that a process started while losing the arguments that would have explained why. Those arguments can contain passwords or other sensitive information, so access to the collected logs needs protection too. (Microsoft process auditing documentation)

Sysmon Event ID 1 or suitable EDR telemetry can supply process details and parent relationships. Verify what you retain. Sysmon’s network connection logging, Event ID 3, is disabled by default. Installing it and collecting the evidence you think you are collecting are separate accomplishments. (Microsoft Sysmon documentation)

PowerShell Script Block Logging, including Event 4104 in the applicable operational channel, can reveal script content that a process command line misses. It helps with investigation; it does not guarantee that every obfuscation layer or action becomes visible. Exercise the PowerShell versions and execution paths your administrators actually use. (Microsoft PowerShell logging documentation)

Do the same for WMI. Run a controlled action and see whether you can connect the initiating activity to the resulting process, then join that evidence to authentication and network records. If a piece is missing, preserve the uncertainty. Silence from a sensor you never configured is a remarkably weak alibi.

Keep the history somewhere the compromised endpoint cannot casually rewrite it. The joint LOTL guidance recommends centralized logging outside the affected environment’s normal control path, with storage that allows records to be written once and read repeatedly without modification. Separate administrative control, appropriate retention and monitoring for collection failures all belong in that conversation. (Joint guidance on living off the land, February 2024)

Familiar activity can still be wrong

The joint advisory recommends maintaining baselines for installed tools, account behavior and network traffic. Useful advice, provided we remember that an average has no idea what anybody was authorized to do. (Joint advisory AA24-038A, February 2024)

A developer laptop and a domain controller should not be judged against the same expectations. Neither should a service account and the administrator who owns the deployment process. Compare the right peers, then examine the parents, arguments and destinations that distinguish the expected job from an unexpected use of the same utility.

Document approved automation closely enough to notice when it changes. A management server launching a familiar deployment does not justify allowing every command from every process on that server. Likewise, a maintenance window is context, not diplomatic immunity.

The awkward baseline problem is the attacker who arrived before you started learning. Enough repetition can make their behavior look ordinary. That is a measurement problem, and automatically absorbing every repeated action into normal can make it worse. Review what the baseline is learning. When history is thin, say so.

Accuracy can be an expensive distraction

Command text is slippery. Depending on the interpreter, encoding, escaping and string construction can change how an instruction looks while preserving what it does. Retain the raw evidence and extract decoded or structured content where possible. Even then, obfuscation deserves investigation rather than an automatic guilty verdict, because legitimate software uses it too.

There is useful research here. LOTLDetector combines command text with expert rule tags and similarity features. SENTINEL combines semantic encoding, character processing, relationships between commands and anomaly scoring. The SENTINEL authors report 92.0 percent accuracy on documented attack commands and 91.2 percent on obfuscated variants in a balanced benchmark derived from Volt Typhoon advisory material. It is an arXiv preprint, and those figures describe the authors’ benchmark. They do not tell you the protection rate in your environment. (LOTLDetector, Cybersecurity, January 2026) (SENTINEL preprint, September 2026)

Outrata and colleagues examine command obfuscation under extreme class imbalance, where positive examples are scarce beside ordinary activity. Their production evaluation reviews flagged commands. That can establish precision for those detections, but it cannot establish how many obfuscated commands went undetected. Useful work, with a boundary around what the evidence supports. (Outrata and colleagues, NLPAICS 2026)

Here is an illustrative calculation that makes the operational problem harder to hide. Give a detector one million benign commands and ten malicious ones. It catches all ten attacks, but also flags 0.1 percent of the benign commands. The SOC receives 1,000 false positives alongside ten real detections, while overall accuracy sits at approximately 99.9 percent.

Put that number on a slide and somebody will want to buy lunch. Put those alerts in the queue and somebody will miss lunch.

Fewer than one percent of the alerts in that example are correct. I want the detection rate, the misses and the workload together, followed by how quickly a hunter can reach a conclusion they can defend. Test unfamiliar variants and legitimate administration, separating data by time and environment where practical. Near copies appearing in both training and testing can flatter a model considerably.

Give the detection something concrete to prove

Choose a path that matters in your environment, such as unusual remote access followed by directory installation media creation on a domain controller. Identify the records needed to establish access, execution and output, including any subsequent movement of that output. Keep strong individual rules and add correlations where the surrounding behavior changes the meaning.

Keep enough history to investigate activity spread over days as well as minutes. Your correlation window may close after an hour. The attacker has probably not put that deadline on their calendar.

Run an authorized exercise that includes the malicious sequence and a legitimate administrative counterpart. Measure the time from the first observable malicious action to a useful detection, then inspect what the investigator actually received. If a critical record never arrived, fix collection before adjusting the model. If routine administration produces the same accusation, find out which distinction your detection failed to make.

At ThreatHunter.ai, I want us to be able to explain what happened and put the evidence in front of the person who has to act. That means following familiar software into unfamiliar behavior, questioning our own assumptions and staying with the investigation when the first answer is convenient but incomplete.

The binary can be perfectly legitimate while somebody uses it to steal from you. We need to catch the theft.