Detecting living-off-the-land binaries with Sysmon process events

Living-off-the-land binaries, often shortened to LOLBins, are legitimate Windows executables that attackers abuse to carry out malicious activity while blending in with normal administration. The binaries themselves are not the problem. The issue is that tools such as PowerShell, cmd.exe, wscript.exe, mshta.exe, rundll32.exe, regsvr32.exe, schtasks.exe, certutil.exe, bitsadmin.exe, and msiexec.exe can be used to download content, execute scripts, stage payloads, or persist on a host without introducing an obviously malicious new file.

For UK SMEs, the practical challenge is not defining the threat. It is separating normal administrative use from suspicious use at scale, with limited analyst time. That is where Sysmon process creation telemetry becomes valuable. If you already have a detection capability in place, Sysmon can provide the extra context needed to spot abuse patterns that native Windows logging may miss. If you are still building that capability, this article focuses on the process event data that gives you the best return first.

This is also why living-off-the-land detection should be treated as part of a wider endpoint visibility strategy rather than a standalone control. If you want a broader view of the threat model, it is worth pairing this article with our guide to fileless malware and living-off-the-land attacks, which covers the attack pattern at a higher level, and with what security logs you actually need and why for the logging foundations underneath it.

What living-off-the-land binaries are and why they matter

LOLBins are trusted binaries already present on the operating system or installed as part of common software. Because they are signed, widely used, and often allowed through application control or endpoint protection policies, they can be a convenient way for an attacker to avoid dropping custom tooling. In practice, they are often used in intrusion chains for initial execution, payload staging, persistence, or defence evasion.

In MITRE ATT&CK terms, this behaviour commonly maps to techniques such as command and scripting interpreter abuse, scheduled task abuse, signed binary proxy execution, and system binary proxy execution. The important point for defenders is that the binary name alone is rarely enough to make a decision. A legitimate admin may use PowerShell to manage endpoints, while an intruder may use the same binary to decode an encoded command, fetch a script from a remote host, and launch a second-stage process. The detection problem is therefore contextual, not purely signature-based.

That context is where process telemetry helps. If you can see the parent process, command line, image path, and hashes, you can build rules around behaviour rather than just names. That approach is more resilient and usually produces better triage outcomes than trying to block every use of a given binary.

Why Sysmon process events are useful for LOLT detection

Sysmon Event ID 1, which records process creation, gives you more useful detail than the default Windows Security log in many environments. It can capture the full command line, parent process information, hashes, user context, integrity level, and the image path. For detection engineering, that combination is often enough to distinguish a normal administrative action from a suspicious execution chain.

Native Windows process auditing can show that a process started, but Sysmon usually gives you the richer metadata needed to answer the next questions: what launched it, with what arguments, under which account, and from where on disk. That matters because many LOLBin detections depend on combinations such as Office spawning PowerShell, a browser spawning cmd.exe, or a script host launching a downloader utility.

Sysmon is not perfect, though. If the configuration is too broad, you will drown in noise. If it is too narrow, you will miss the very process chains you want to detect. The telemetry gaps usually come from poor tuning rather than from Sysmon itself. Common issues include missing command line capture, weak filtering of known-good administrative activity, and inconsistent deployment across endpoints. If you are still shaping your endpoint logging baseline, endpoint hardening using CIS Benchmarks and reducing attack surface using system hardening techniques are useful complements because they reduce the amount of unnecessary activity you need to monitor.

Preparing Sysmon for high-value process telemetry

For most SMEs, the first goal is not to collect everything. It is to collect the process data that supports reliable detection and investigation. A sensible starting point is to deploy a known-good Sysmon configuration, then tune it for your environment. The Sysmon community configuration by SwiftOnSecurity is still widely used as a starting point, but it should not be treated as a final state. Whatever baseline you choose, validate it against your own software estate, admin workflows, and remote management tooling.

At minimum, ensure process creation logging is enabled and that command line capture is switched on. In Sysmon configuration terms, that means the process creation event should be included, and the command line field should be collected. You also want parent process relationships preserved, because the parent-child chain is often the strongest signal in LOLBin detection. Image hashes are useful too, especially when you need to confirm whether a binary has been replaced, tampered with, or launched from an unusual location.

A practical deployment pattern is to start with broad process visibility on a pilot group, then add exclusions only after you have seen the normal administrative and software deployment patterns. Keep exclusions explicit and documented. Avoid over-filtering by user or process name alone, because that can hide abuse that uses the same account or binary as routine work. If you are centralising telemetry into a SIEM, make sure the Sysmon schema is mapped consistently so that fields such as Image, ParentImage, CommandLine, User, IntegrityLevel, and Hashes are searchable and available for correlation.

Which binaries and behaviours to watch first

Not every LOLBin deserves the same level of attention. Start with the binaries that are most often seen in abuse chains and that are most likely to create useful alerts when used in unusual ways. PowerShell, cmd.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, regsvr32.exe, schtasks.exe, certutil.exe, bitsadmin.exe, and msiexec.exe are common starting points. Each has legitimate uses, so the detection focus should be on suspicious execution context.

Examples of high-value behavioural patterns include Office applications spawning script interpreters, script interpreters spawning download utilities, browsers or email clients spawning command shells, and service processes launching interactive tools. Another useful pattern is chaining, where one LOLBin launches another. For example, a document viewer or script host launching PowerShell, which then launches cmd.exe or rundll32.exe, is often more interesting than a single isolated process event.

Command line content matters as much as the binary name. Suspicious indicators include encoded commands, unusual URL handling, references to remote content, script download and execution patterns, and execution from user-writable paths. Parent process context matters too. A binary launched by explorer.exe is not automatically benign, but a binary launched by winword.exe, outlook.exe, or a temporary script host deserves closer inspection. The same applies to binaries running from paths that are not the standard system locations, especially if the image name matches a trusted Windows tool but the path does not.

Detection logic for Sysmon process events

Good detection logic is usually a combination of allow-listing, behavioural conditions, and context-aware exceptions. A simple rule that alerts on every PowerShell execution will be unusable in most environments. A better rule looks for PowerShell with suspicious command line characteristics, unusual parent processes, or execution from an unexpected path. The same approach applies to the other LOLBins.

Useful detection dimensions include:

• Parent process, especially Office applications, browsers, archive tools, and script hosts spawning command interpreters or download utilities.
• Command line content, including encoded commands, download-and-execute patterns, remote URLs, or references to obfuscated scripts.
• Image path, especially binaries running from user profile directories, temp locations, or other non-standard paths.
• User context, such as service accounts, local administrators, or accounts that should not normally launch the binary in question.
• Execution frequency and timing, such as a binary appearing for the first time on a host or running outside normal maintenance windows.

When building rules, prefer conditions that combine at least two signals. For example, a rule for mshta.exe is more useful if it triggers when mshta.exe is launched by a document editor, runs from an unusual path, or includes a remote script reference. Similarly, certutil.exe is more interesting when it is used outside certificate management workflows and when the command line suggests file retrieval or decoding rather than normal administrative use.

Noise reduction is essential. Software deployment tools, remote support platforms, patching systems, and endpoint management agents can all generate legitimate LOLBin activity. Build exceptions around known management servers, approved service accounts, and documented maintenance windows. Keep those exceptions narrow. If you exempt an entire binary without context, you will lose the value of the detection.

Building detections in practice

Sigma is a good portable format for expressing Sysmon process detections because it lets you describe the logic once and translate it into different SIEMs. A practical Sigma rule for LOLBin abuse might target a specific binary, require a suspicious parent process, and include command line keywords associated with encoded execution or remote retrieval. The value of Sigma is not just portability. It also forces you to be explicit about the fields and conditions that matter.

For Microsoft Sentinel, the same logic can be expressed in KQL against the Sysmon process table or a normalised endpoint table. A simple pattern is to filter on the process name, then add parent process and command line conditions. For example, you might look for PowerShell launched by Office processes, or mshta.exe launched with a URL-like argument. In KQL, that usually means combining fields such as DeviceProcessEvents, InitiatingProcessFileName, FileName, ProcessCommandLine, and AccountName, then grouping by host and user to reduce duplicate alerts.

Whatever SIEM you use, keep the rule output actionable. An alert should tell the analyst which binary ran, what launched it, what the command line contained, and whether the process chain is new on that host. If the alert does not support a quick triage decision, it will be ignored. This is one reason why centralised visibility across endpoint, identity, and network telemetry is so valuable, especially when paired with centralised security visibility and achieving centralised visibility across endpoints, identity, and network.

Tuning and validation

Before you rely on any LOLBin detection, baseline normal administrative use. That means observing how your IT team, managed service provider, patching platform, and line-of-business applications actually use these binaries. In many SMEs, the biggest source of false positives is not malicious activity. It is routine automation that was never documented well enough for detection engineering.

Once you have a baseline, validate the detection with benign simulations. You do not need exploit instructions to do this safely. A purple-team style exercise can use harmless command lines that mimic the structure of suspicious activity without performing malicious actions. The goal is to confirm that the rule fires, the right fields are captured, and the alert contains enough context for triage. If you already run detection validation exercises, this should fit neatly into your existing process alongside purple teaming for small security teams and measuring detection quality and false positives.

Track the practical metrics: alert volume, true positive rate, false positive rate, and time to triage. If a rule is noisy, tune it by adding context rather than by weakening the core condition. For example, add known-good parent processes, approved management hosts, or specific service account exceptions. Avoid broad exclusions that remove the very telemetry you need for investigations.

Common false positives and how to handle them

False positives are normal in this area because the same binaries are used by administrators, software vendors, and attackers. Common examples include software deployment tools using cmd.exe or PowerShell to install packages, remote administration tools launching scripts, and scheduled maintenance jobs invoking certutil.exe or msiexec.exe for legitimate reasons.

Service accounts are another frequent source of noise. A service account may legitimately run a scheduled task, update a certificate store, or execute a script from a management server. The answer is not to ignore those events. It is to classify them. Build a small set of approved patterns for known automation, then alert on deviations from those patterns. If a service account starts launching a LOLBin from a new host, with a new parent process, or at an unusual time, that is still useful signal.

Vendor maintenance workflows deserve the same treatment. Many third-party tools use generic Windows binaries under the hood, which can look suspicious if you only inspect the process name. Ask for documentation from suppliers where possible, and record the expected parent-child chains. That makes future tuning faster and reduces the temptation to suppress alerts globally.

Operational response when a LOTL alert fires

When a LOLBin alert fires, triage should begin with the endpoint context. Confirm the process tree, command line, user account, host name, and time of execution. Check whether the process is part of a known management workflow. If not, look for adjacent activity such as new child processes, file writes, network connections, or persistence artefacts.

Identity context is just as important. Determine whether the account is a standard user, local administrator, service account, or privileged operator. Review recent sign-ins, privilege changes, and unusual logon locations if that data is available. A suspicious process launched by an account that has recently been used from an unexpected source is more concerning than the same process launched by a well-understood admin account during a maintenance window.

If the alert suggests active abuse, escalate quickly enough to preserve evidence and contain the host if needed. That may mean isolating the endpoint, disabling the account, or collecting volatile data before remediation. If the activity appears benign but unusual, keep it in the hunting queue and correlate it with other telemetry. The key is to avoid treating every LOLBin alert as either a confirmed incident or a harmless admin action. Most cases sit somewhere in between and need context.

How this detection supports broader endpoint visibility

Sysmon process telemetry is strongest when it is part of a layered detection stack. Windows Event Logs can add authentication and logon context. Defender for Endpoint can add behavioural and memory-based signals. Network telemetry can show whether a suspicious process reached out to the internet or an internal staging host. Together, those sources help you move from a single process event to a coherent incident narrative.

This is also where MITRE ATT&CK mapping becomes useful operationally. If you map your LOLBin detections to ATT&CK techniques, you can see where coverage is strong and where there are blind spots. For example, you may have good visibility on PowerShell abuse but weak coverage for signed binary proxy execution. That helps prioritise tuning work and makes it easier to justify improvements to stakeholders who want to know what the detections actually cover.

For SMEs, the practical goal is not perfect coverage. It is enough high-quality visibility to detect suspicious use early, investigate efficiently, and reduce the time spent on low-value alerts. That is a realistic and worthwhile target, especially when you are balancing security work with day-to-day IT operations.

Practical implementation checklist for small security teams

If you are starting from scratch, a sensible sequence is:

• Enable Sysmon process creation logging with command line capture and parent process context.
• Deploy a tested baseline configuration to a pilot group before rolling out wider.
• Normalise the fields you need for detection, especially image, parent image, command line, user, and hashes.
• Build a small set of high-signal rules for the most abused LOLBins first.
• Document approved administrative and vendor workflows so you can tune exceptions safely.
• Route alerts into a SIEM or case management workflow where they can be triaged quickly.
• Validate rules with benign simulations and review them after each major environment change.
• Retain enough process history to support investigations and trend analysis.

If you want to improve this further, treat the detections as living content. Review them after software rollouts, new remote management tools, or changes to your endpoint hardening baseline. That is usually more effective than waiting for a major incident to reveal the gaps.

For teams that want help turning Sysmon telemetry into usable detections, or want to align endpoint visibility with a broader risk-based security programme, speak to a consultant. Practical support can help you tune the logging, reduce noise, and make sure the detections fit the way your environment actually works.

Frequently asked questions

What is the difference between fileless malware and living-off-the-land attacks?

Fileless malware describes malicious activity that relies heavily on memory, scripts, or built-in tooling rather than writing a traditional payload to disk. Living-off-the-land attacks use legitimate binaries already present on the system to execute malicious actions. The two often overlap, but they are not identical: a fileless attack may use LOLBins, and a LOLBin-based attack may still leave files behind.

Can Sysmon alone reliably detect living-off-the-land binaries?

No. Sysmon process events are a strong starting point, but reliable detection usually needs supporting context from identity logs, Windows event data, endpoint protection, and sometimes network telemetry. Sysmon can tell you what ran and how it was launched, but it cannot always tell you whether the activity was malicious without surrounding evidence.