No Laughing Matter: Detecting LOLs with LimaCharlie

The most defensible binary detection in the world still fires on cmd.exe, and cmd.exe runs ten thousand times a day on a healthy network. That is the trap living off the land sets for a detection team. Matt at LimaCharlie built this session around a joint advisory that CISA co-authored with partner agencies across the Five Eyes on identifying and mitigating living off the land techniques, but the advisory is really a setup for a harder question. Once you accept that the adversary is using software you cannot block, signed, trusted, and shipped with the operating system, what is left to detect? His answer is that you stop hunting the binary and start hunting the context around it, and the only honest way to find that context is to look at telemetry before you write a single rule.

Why the binary is the wrong thing to watch

Living off the land works because it inverts every assumption endpoint protection rests on. The standard checks ask whether a file is signed, whether the publisher is recognized, whether the thing can be validated. A binary that ships with Windows passes all of those, because it is not malware. It is a legitimate tool put to a malicious purpose, and that distinction is exactly what the metadata-driven checks cannot see. Matt is careful to widen the frame past Windows binaries. The advisory covers Linux and macOS, drivers, and built-in scripting languages, and it spends real attention on cloud and hybrid environments, the cases he thinks most teams overlook. He singles out persistence achieved through cloud automation services, where an adversary creates a trigger that fires on an event, as living off the land in a setting most people never associate with the term.

The hybrid case produces his sharpest point. A developer's own cloud CLI tools, sitting on a host with API keys linked and credentials cached in memory, are not living off the land when the developer uses them. The moment an adversary lands on that host, they are. The land belongs to the developer, and the intruder inherits it. That reframing matters for anyone defending a fleet, because it means the inventory of what an attacker can abuse is not a fixed list of OS binaries. It changes with whatever each machine happened to have installed.

Telemetry first, rules second

The method Matt argues for runs against the usual instinct, which is to open the rule editor and start pivoting on executable names. Process events are a reasonable place to start, but he refuses to write detections speculatively. Instead he enables the Atomic Red Team extension from the LimaCharlie marketplace, picks an atomic mapped to a known ATT&CK ID (he starts with an mshta technique, then a BITS jobs test), and runs it against a Windows Server 2016 lab host wired with a LimaCharlie EDR sensor. The job runs in the background with its progress visible in the platform. The purpose is not to imitate an adversary convincingly. It is to generate real events so a rule can be modeled against what the technique actually produces in his own environment, rather than against what he imagines it produces.

This is where his framing for service providers lands without being forced. The loop is fast. Run the test, watch the telemetry fill the timeline, bring the event of interest into the rule editor with one click, tighten it, and validate it against the very event that triggered it before it ever touches a client tenant. He keeps returning to that validation step, the look-back capability that tests a draft rule against the captured telemetry and tells him whether it would have fired. For a team writing detections that will run across many customers, the ability to prove a rule works before deployment is the difference between confidence and hope.

Fidelity lives in variability, not in indicators

Because the binary is legitimate, a single-indicator rule is useless. A detection that fires on every cmd.exe would drown a SOC. Matt walks the timeline second by second around each test, the way an analyst works a window of activity during an incident, and the fidelity comes from what sits next to the suspicious process: the command line, the process chain, the temporal proximity of related events. He marries two telemetry sources on the same host, LimaCharlie's native new_process event and the Windows event log entry (Sysmon event ID 1, or 4688 if you ingest security logs instead), to get more context per event.

The craft, as he demonstrates it, is deciding what to hold loose and what to pin. Ephemeral values betray you. A temp .bat filename dropped by one test will change on the next run, so matching it exactly gives a rule that fires once and never again. He proves this by rerunning the same test and watching the value change. So he leans on contains rather than exact matches, pivots on the more stable parts of a command line, and uses nested and and or logic so one rule can absorb the many ways a single binary gets abused. He pulls up the MITRE entry for mshta.exe and points at the spread: executing scripts, DLLs, VBScript, an HTA inside an LNK, HTML pages. His argument is to refuse the temptation to write a separate rule for each. The flip side he warns against, writing one detection per adversary variation, is the trap that turns a ruleset into something nobody can maintain.

Path matters too. There are two cmd.exe copies on Windows, one in System32 and one in SysWOW64, and an adversary can deliberately run the unexpected one to dodge a rule pinned to a single location. Matching where a file path ends in cmd.exe covers both, and also a binary the attacker relocates. On Linux and macOS the problem is worse, since tools install almost anywhere, so for interpreters like Python, Perl, and Ruby he pins the more static interpreter while staying flexible on install location. Through all of it he holds one line: a process-execution rule still needs a real qualifier. Strip out the command-line pattern and what remains just says "a process ran," which matches everything and detects nothing.

That discipline is the whole point of the session, and Matt says as much when a viewer asks whether to combine new_process and event log events in one rule with an or. He advises against it by reflex. If you have one source you generally have the other, and the new_process event already captures nearly everything Sysmon event ID 1 does and more than 4688. Pick the source that carries the pivot you need (the event log when you want parent-user context or process cascades, the EDR event for straightforward command-line work) and reserve combined logic for the rare indicator that is unambiguously bad every way it appears. He never shows how to write fifty rules because writing fifty would not teach anyone how to write the fifty-first. The leverage, for a one-host lab or a thousand-tenant operation, is the same: build one rule well enough that the next hundred become mechanical.