Integrating LOL Binaries with LimaCharlie

The hard part of living-off-the-land detection is that the binary itself is innocent. Every Windows host runs bitsadmin, and the operating system invokes it constantly in the background. The question is never whether it ran but how. That is the tension this session keeps circling: the signal you need to find is buried inside activity that is supposed to be there. Matt frames the whole problem around it, and his answer is not a better blocklist but a better way of thinking about what separates routine execution from abuse.

The catalog is a starting point, not an answer

Matt widens the definition of living off the land before touching any tooling. The instinct is to picture an adversary directly invoking a native binary, but he points out the more common case is one step removed. A post-exploitation toolkit like Cobalt Strike ships a custom beacon for command and control while leaning heavily on built-in operating system functionality to stay quiet. The attacker may be living off the land without thinking of it that way.

That breadth is why he spends time on the community reference projects first. For Windows there is LOLBAS, the living-off-the-land binaries, scripts, and libraries project, which he counts as 198 binaries, each annotated with abusable functions, expected paths, required privileges, the MITRE ATT&CK techniques they map to, and the OS versions where a given capability exists. He notes that bitsadmin's download and alternate data stream capabilities were ported forward to Windows 11, while copy and execute stopped at Windows 10, which can itself become a limiter on what an adversary can do. There is a companion LOLDrivers project for vulnerable Windows drivers, keyed on SHA-256 hashes. For Unix-based systems there is GTFOBins, aimed largely at privilege escalation and shell escapes, and for macOS there is LOLbin, which Matt notes stands for living off the Orchard and is organized by tactic.

He is deliberate about how to treat these. They are taxonomies and references, not a compliance checklist, and he is explicit that he does not think "MITRE ATT&CK compliance" is a real thing. The value is operational. A shared vocabulary lets an analyst say an adversary used bitsadmin and have everyone in the room pivot immediately to how it has been abused and by whom, instead of burning several pages of an incident report defining a single tool. But a catalog only tells you a binary can be abused. It does not tell you whether the instance in front of you is abuse. That gap is where the engineering begins.

Detection lives in the differentiator, not the name

The bitsadmin work is the argument made concrete. Bitsadmin manages the Background Intelligent Transfer Service, something the operating system does quietly all the time, so a rule that matches the string "bitsadmin" in a command line catches exactly that: the operating system breathing. Matt's method is to mine the reference material for properties that separate routine execution from abuse, then encode only those.

Path is the first lever. The legitimate 64-bit binary sits in System32 and the 32-bit version in SysWOW64 (Windows reverses what the names imply), so a bitsadmin running anywhere else suggests a renamed payload hoping to hide in the noise. Parameters are the second lever, but only the ones that discriminate. Matt shows that /create appears in every abuse example, which means filtering on it changes nothing. If a flag is always present, it is not a signal. The download capability is different, because download is the one function that reaches outward, so pairing a bitsadmin file-path match with a command line containing HTTP isolates likely ingress or download activity and labels it for the analyst. He refuses to oversell this. He anticipates the obvious objection, that an attacker could use a raw IP instead of an HTTP string, and his answer is honest: yes, and the rule can be widened to look for an IP, an EXE, or a DLL in the command line. The point is not a perfect rule. The point is a defensible pivot.

The same logic transfers cleanly off Windows. For ditto on macOS, a utility that compresses files into a zip, the interesting pivot is not how the command was invoked but what it produced, so the detection watches the output file rather than the parameters. The technique generalizes because the thinking does.

The loop matters more than any single rule

What makes this repeatable is the workflow underneath it. Matt writes a rule, replays it against existing telemetry, reads what comes back, and tightens. He runs the benign bitsadmin download example, which fetches autoruns from sysinternals.com, inside an isolated test VM with LimaCharlie installed, never against a production or sensitive host, then confirms the rule fires. Watching the result set fall from three broad bitsadmin hits to the single download event is the whole method in miniature, and he is blunt that a 3-to-1 reduction only sounds unremarkable until you scale it. Knock 300 false positives down to 100 with one inclusion clause and the analyst-time math changes. He also defends shipping an imperfect rule on purpose. It is acceptable to catch both legitimate and malicious activity at first and whittle the noise down, rather than over-constraining a rule before it has ever seen real data.

For an MSSP or MDR, the leverage is less in any one detection than in the parts of the platform that absorb the repetitive engineering. LimaCharlie has folded the LOLDrivers data set into a lookup keyed on SHA-256, so a code identity event (which fires whenever a binary is recognized on a host, distinct from a process execution) can be checked against known-bad drivers automatically, with a ready example in the add-ons marketplace. Matt expects similar integrations for GTFOBins and LOLbin as those projects expose APIs, and notes LOLbin already has one. The built-in Sigma rule set already covers much of this ground, and LOLBAS links straight to the relevant Sigma content, which he uses as confirmation that his HTTP pivot lines up with what others look for. The rule author's job, then, is mostly judgment: deciding whether the artifact will surface as a process event, a code identity event, or a command-line string, and targeting accordingly. The SANS blue poster, which catalogs what default Windows binaries should look like when they run, is the same kind of input from the other direction.

Frequency is itself a detector. Four bitsadmin events across three weeks in his demo environment is anomalous on its face, and a tool like ditto that none of an organization's Mac users know how to operate may justify a rule on mere presence. Deprecation is the same signal from another angle. Windows Server 2016 reported bitsadmin as deprecated in favor of BITS PowerShell cmdlets, which means a LOL detection can also surface legacy or out-of-policy tooling that stands out against a team that has standardized elsewhere. None of these depend on a binary being inherently bad. They depend on knowing what normal looks like in a specific environment, which is exactly what a provider running detection across many tenants is positioned to know.