Writing detections for LOLBins without drowning in noise

Living-off-the-land binaries are useful to attackers precisely because they're useful to admins. A detection that fires on rundll32.exe execution alone will bury a SOC in false positives within a day. The fix isn't a smarter binary list — it's scoping on process lineage, command-line entropy, and the parent-child relationships that don't show up in normal admin activity.

Why the binary list approach doesn't scale

The LOLBAS project catalogs several hundred built-in Windows binaries that can be abused for execution, persistence, or defense evasion — rundll32, regsvr32, mshta, certutil, bitsadmin, and many more. Treating that list as a detection strategy on its own means either alerting on binaries that run constantly for legitimate reasons, or maintaining an ever-growing exception list that rots the moment a new admin tool ships. The list is a starting point for hypothesis generation, not something to alert on directly.

Lineage is the signal that actually discriminates

What separates malicious LOLBin use from routine admin activity is almost never the binary itself; it's what invoked it and what it was asked to do. rundll32.exe spawned by explorer.exe from a user double-clicking a shortcut is unremarkable. The same binary spawned by winword.exe moments after a document was opened is a very different story, and that difference is entirely visible in the parent-child relationship.

detection:
  selection:
    Image|endswith: '\rundll32.exe'
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\outlook.exe'
  condition: selection
      

Pair that lineage constraint with a command-line length or entropy threshold and the false-positive rate drops sharply without losing coverage on the technique — legitimate Office automation rarely spawns rundll32 with a long, high-entropy argument string, which is exactly what a packed or obfuscated payload tends to produce.

A second example: regsvr32 and signed-binary proxying

regsvr32.exe supports a /i scriptlet execution flag that can pull and execute a remote COM scriplet with no file ever touching disk — a technique documented widely enough that it has its own ATT&CK ID (T1218.010). The discriminating signal here is different again: legitimate regsvr32 usage almost never includes a URL in the command line.

detection:
  selection:
    Image|endswith: '\regsvr32.exe'
    CommandLine|contains:
      - 'http://'
      - 'https://'
      - 'scrobj.dll'
  condition: selection
      

That's a narrow, high-confidence rule precisely because the legitimate use case (registering a local COM DLL by path) looks nothing like the abuse case (fetching a remote scriptlet). Not every LOLBin technique offers that clean a split, which is why lineage and behavioral context matter more than command-line pattern matching for the noisier cases like plain rundll32 invocation.

Testing against the real thing

LOLBAS entries for each technique typically link to a working proof-of-concept command, and Atomic Red Team has tests for most of the well-known ones. Run both the malicious test case and a week of normal endpoint activity through any new rule before trusting it — a rule that only gets tested against the attack and never against a clean baseline is a rule you're finding out about in production.

The broader lesson carries across every LOLBin technique: the binary tells you what's possible, but lineage, arguments, and signing context tell you what's actually happening. Detections built only on the first will always be either too broad or perpetually out of date.

Related reading:

• Alert fatigue is a detection engineering problem
• Hunting for living-off-the-land persistence