Threat Hunting for LOLBins: A Practical EDR Guide to Detecting Suspicious Living-Off-the-Land Activity

Living-off-the-land activity is difficult to assess because familiar software can appear in both ordinary administration and an intrusion. An EDR event for rundll32.exe or PowerShell is a starting observation, not a conclusion. The defender’s job is to explain why that process ran, what it touched and whether the sequence fits the environment.

This guide presents a repeatable approach for SOC analysts, threat hunters and incident responders working in authorised Windows environments. It contains defensive searches and fictional examples, with no payloads or instructions to compromise systems.

In this guideUnderstand the contextBuild the hunting workflowSix utilities to investigateFalcon / LogScale sample queriesTune and validateDocument and improve detectionsRelated articles and references

What are LOLBins and LOLBAS?

LOLBins is shorthand for legitimate binaries whose capabilities can be misused as part of an attack. LOLBAS broadens that lens to binaries, scripts and libraries. The software may be trusted or signed, but that does not make every invocation trustworthy. Conversely, appearing in a hunting list does not make a utility malicious.

The public LOLBAS project maintains a catalogue of documented capabilities and associated ATT&CK mappings. Use it to inform investigation coverage, not as a list of process names to block indiscriminately. A technique mapping should reflect observed behaviour, not merely the executable present in an event.

01 · Same utility, different context

Expected workflowApproved management process↓ Known utility and approved input↓ Expected destination and timingConfirm against change records

Investigate furtherUnexpected document parent↓ Utility references unfamiliar input↓ Unexplained network or file activityCorrelate before deciding

Original diagram: context changes the investigative priority. Neither column proves a verdict by itself.

Build a hypothesis before writing a query

Start with a bounded statement: “On ordinary office workstations, a document application starting a native utility and producing unexplained network activity may indicate an unapproved workflow.” Define the device group, time range, expected business uses and evidence that would weaken that hypothesis.

03 · A repeatable hunting loop

1 · Telemetry →Verify coverage and time range

2 · Hypothesis →Define an unexpected behaviour

3 · Query →Find a manageable candidate set

4 · Enrichment →Add endpoint and business context

5 · Validation →Test benign and suspicious explanations

6 · Improve ↺Document, tune and review coverage

Original workflow diagram. A visibility gap is a valid outcome and should feed the next iteration.

1. Identify candidate utilities. Choose a small set relevant to your estate. Include their legitimate owners and workflows in the hunt plan.
2. Establish a baseline. Compare use by device role, parent process, account and change window. A maintenance server and a finance workstation should not share one undifferentiated baseline.
3. Examine ancestry. Review the direct parent and surrounding process tree. Establish whether an approved tool explains the chain.
4. Read the arguments. Review paths, input files and destinations in context. Unfamiliar arguments merit investigation but are not proof; do not execute a captured command to find out what it does.
5. Correlate evidence. Connect process activity with network, file, registry, identity and persistence events using stable identifiers where available.
6. Enrich and validate. Check change records, file provenance, approved software inventories and relevant intelligence. Keep competing explanations visible.
7. Document the result. Record an explained benign workflow, a supported escalation or a coverage gap. Turn only validated patterns into detection candidates.

02 · Read the process tree as a story

Approved installer

↓

regsvr32.exe

↓

Known component registration
Documented update

winword.exe

↓

powershell.exe

↓

Unexpected child process
Business reason not established

Original conceptual example, not a vendor screenshot. Parent-child relationships are leads to investigate, not automatic maliciousness labels.

Six utilities: legitimate use and investigative context

PowerShell

Expected use: administration, configuration and approved automation. Investigate: an unusual parent, an unexplained script location, unexpected child processes or network destinations outside the normal workflow. An approved job, known script provenance and matching change record reduce concern; a document-origin chain with corroborating anomalies increases it. ATT&CK reference: T1059.001.

rundll32.exe

Expected use: invoking functionality exposed by DLLs, including system and application components. Investigate: unfamiliar referenced modules, unusual execution ancestry and related file or network activity. Verify the module path and provenance as well as the utility itself. A known component in a documented workflow supports a benign explanation; an unexplained module in a user-writable location warrants closer review. ATT&CK: T1218.011.

regsvr32.exe

Expected use: registering and unregistering supported components during installation or maintenance. Investigate: execution outside deployment windows, unexpected parents and unfamiliar component references. Correlate the installation record and module origin. The binary’s valid signature does not establish the legitimacy of the content it is asked to handle. ATT&CK: T1218.010.

mshta.exe

Expected use: running legacy HTML applications where an organisation still depends on them. Investigate: use on devices without an identified business need, unrecognised input, unusual child processes and related network events. Confirm whether a legacy application explains the activity before deciding. ATT&CK: T1218.005.

certutil.exe

Expected use: certificate-related administration and other diagnostic operations. Investigate: activity whose file inputs, outputs or destinations do not fit a certificate or support workflow. Check what was produced and whether another process subsequently used it. A documented certificate task lowers concern; an unexplained transfer followed by further execution raises it. Map evidence to T1105 for adversary tool transfer or T1140 for relevant decoding behaviour, rather than mapping every invocation.

bitsadmin.exe

Expected use: management of Background Intelligent Transfer Service jobs, including legacy administrative workflows. Investigate: unexpected job owners, destinations, transferred files or follow-on activity. Check job metadata and the service context: the network connection may be recorded under a service process, not the command-line utility. Approved software delivery can explain transfers; unknown jobs with unexplained follow-on behaviour deserve escalation. ATT&CK: T1197.

04 · Build an evidence chain

Process instance + device + time window

↔ Command lineInput, path and stated purpose

↔ NetworkDestination, outcome and timing

↔ FilesOrigin, hash and subsequent use

↔ RegistryWhat changed and who initiated it

↔ IdentityUser, session and expected role

↔ PersistenceTasks, services and autorun evidence

Original correlation diagram. A nearby event is not necessarily caused by the process being investigated.

Defensive Falcon / LogScale sample queries

Read this before using the examples.

These examples target CrowdStrike Query Language (CQL) in Falcon environments using LogScale-style search. They are not legacy Splunk-style Event Search queries. Field names, event schemas and syntax vary by deployment, sensor version and source. The examples were reviewed against public documentation, not executed in a Falcon tenant. Test and adapt them in an authorised environment.

Start with a short time range in the console, such as 24 hours, and a known device group. Confirm that process and network events exist. Check whether your dataset uses tagged #event_simpleName, whether parent names and user fields are populated, and whether paths use the expected separator. Empty results can mean missing telemetry, parser differences or an overly narrow scope.

Query 1 — inventory the selected utilities

#event_simpleName=ProcessRollup2 event_platform=Win
| ImageFileName=/\\(powershell|pwsh|rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName,
    ImageFileName, CommandLine, TargetProcessId])

This establishes a candidate set from full image paths. It is not a malicious-activity detector. Confirm the returned fields, inspect representative events and compare with known administrative activity. Renamed binaries and execution outside this list are outside its coverage.

Query 2 — inspect unusual document parents

#event_simpleName=ProcessRollup2 event_platform=Win
| ImageFileName=/\\(powershell|pwsh|rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
| ParentBaseFileName=/^(winword|excel|powerpnt|outlook)\.exe$/i
| table([@timestamp, aid, ComputerName, ParentBaseFileName,
    ImageFileName, CommandLine, TargetProcessId])

This looks for a specific parent-child pattern. Investigate the document workflow and full ancestry. It misses intermediate processes and legitimate integrations can match. Use the process-tree view to test the hypothesis rather than treating every returned row as an incident.

Query 3 — find low-frequency parent and image combinations

#event_simpleName=ProcessRollup2 event_platform=Win
| ImageFileName=/\\(rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
| groupBy([ParentBaseFileName, ImageFileName], function=count(as=Executions), limit=10000)
| Executions <= 3
| sort(Executions, order=asc)

The threshold of three is illustrative. Counts refer to matching events in the selected scope and period, not global prevalence or unique hosts. Choose a baseline appropriate to your estate and account for duplicate events, collection gaps and new deployments. Check aggregation limits and partial-result warnings; rare results are not automatically suspicious.

Query 4 — correlate utility processes with IPv4 network events

#event_simpleName=NetworkConnectIP4 event_platform=Win
| join(query={
    #event_simpleName=ProcessRollup2 event_platform=Win
    | ImageFileName=/\\(rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
  }, field=[aid, ContextProcessId], key=[aid, TargetProcessId],
  include=[ImageFileName, CommandLine, ParentBaseFileName], mode=inner)
| table([@timestamp, aid, ComputerName, ImageFileName,
    ParentBaseFileName, CommandLine, RemoteAddressIP4, ContextProcessId])

The association uses device ID aid plus Falcon process identifiers: network ContextProcessId and process TargetProcessId. Do not substitute a raw operating-system PID without validating its semantics. Review both event times and the connection outcome in your schema.

This query excludes unmatched network events. Join limits or an insufficient process-search window can hide matches, especially when a process started before the selected period. It covers IPv4 only and does not capture every DNS, IPv6, proxy, child-process or service-mediated action. A BITS transfer may therefore need job and service telemetry instead. Query matches show correlation, not proof of command-and-control or data theft.

How to tune this query set

Build exceptions from verified workflows, not convenient labels. For an approved deployment, record the owning team, expected parent, component or script identity, relevant device group, account and change window. Review exceptions periodically and retain a way to investigate deviations.

• Scope known deployment tools to their expected paths, publishers and activity; avoid an unconditional allowlist for every child they launch.
• Validate approved scripts and inputs. A trusted interpreter does not make an arbitrary script trusted.
• Use expected service accounts as context, not a blanket exclusion. Investigate interactive or out-of-pattern use.
• Separate server, workstation and administrative baselines, and revisit them after migrations or software changes.
• Test known benign records and safe, labelled lab records. Measure noise and missed coverage before scheduling a detection.

A fictional triage example

A document application starts a listed utility on a workstation. The event is uncommon, but the owner identifies a reporting add-in. A matching change record, known input and consistent peer-device behaviour support closing it as an explained workflow. In a second case, there is no matching workflow, the input is unfamiliar and correlated file activity remains unexplained. Preserve the timeline and escalate the evidence; do not label the case confirmed compromise solely because the utility appears in LOLBAS.

Turn a hunt into an improvement

A useful report records the hypothesis, scope, data coverage, query version, relevant evidence, competing explanations and final disposition. Keep sensitive command lines and customer details in approved internal systems rather than public examples.

Before promoting a hunt to a detection, establish an owner, review thresholds, test representative benign activity and define what an analyst should do with the result. Sometimes the best outcome is a logging improvement or a clarified software inventory, not another alert. If containment is warranted, follow the organisation’s approved incident-response process.

Related articles

• PowerShell Threat Hunting: Two Practical KQL Examples
• PSIRT interview preparation: communicating evidence and risk
• Explore the Knowledge Base Articles

References and further reading

• LOLBAS project — maintained capability catalogue.
• MITRE ATT&CK — individual technique references are linked in the utility sections.
• LogScale join documentation and groupBy documentation — verify syntax and limits for your version.
• CrowdStrike public LogScale community content — event-correlation examples and schema context.

Text and four conceptual diagrams created for Hack Invasion. No vendor-console screenshots or third-party graphics are reproduced.

PowerShell Threat Hunting: Two Practical KQL Examples

PowerShell threat hunting works best when a query tests a specific question. A PowerShell process alone is not evidence of compromise: administrators and management tools use it every day. The useful question is whether its parent process, user, timing and network activity fit the device’s normal role.

This guide uses hypothesis-driven threat hunting to investigate two patterns with Microsoft Defender XDR advanced hunting. The examples are fictional teaching scenarios, not accounts of real incidents. The queries are read-only starting points; they have not been executed against a live tenant and need validation against your environment.

The technique: start with a testable hypothesis

A hypothesis states what suspicious behaviour might look like and what evidence would support or weaken that explanation. Write it before searching, define the devices and time range, then compare the results with normal activity.

1. Define: describe the behaviour and the business context in which it would be unexpected.
2. Collect: check that the necessary endpoint events exist for the devices and period.
3. Investigate: connect process, account and network evidence instead of treating a query match as a verdict.
4. Conclude: record a supported finding, an explained benign result, or an unresolved visibility gap.

MITRE ATT&CK maps adversary use of PowerShell to T1059.001. That mapping describes a behaviour; it does not establish that an individual PowerShell execution is malicious.

Before running the queries

You need access to advanced hunting and relevant Defender for Endpoint telemetry. Microsoft documents DeviceProcessEvents for process activity and DeviceNetworkEvents for network activity. Check the in-portal schema and event coverage before interpreting results.

The queries use a seven-day window as a starting point. Adjust it to your retention, permissions and investigation scope. If the tables return no recent events for a known active device, resolve that visibility gap first. An empty result is not proof that a device is clean.

Example 1: an Office application launches PowerShell

Hypothesis: a document application launching PowerShell may indicate unexpected script execution on a workstation where that workflow is not normally used.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
    "winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")
| project Timestamp, DeviceId, DeviceName, AccountName,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    FileName, ProcessCommandLine, ProcessId, ProcessCreationTime
| order by Timestamp desc

This finds direct parent-child relationships. It will miss chains with an intermediate process, renamed executables and execution not captured by the sensor. Expand the investigation through the device timeline rather than assuming this query covers every PowerShell technique.

A fictional investigation

On FIN-LAPTOP-07, Word launches PowerShell shortly after a user opens a document. The parent relationship is unusual for this device, but it is only the starting observation.

• Review the full process tree and command line. Establish which document and workflow preceded the process where telemetry allows.
• Check the user’s role, relevant support activity and whether an approved document integration explains the behaviour.
• Look for nearby file creation, child processes and network events associated with the same process instance.
• Compare with similar workstations and earlier activity. Ask whether this is a new pattern or a known business workflow.

If an unapproved document launch is followed by an unexplained script and related external communication, preserve the evidence and escalate through the incident-response process. If a verified reporting add-in explains the chain and the activity matches an approved change, document that explanation. Neither the parent name nor the user’s recollection is sufficient on its own.

False positives and tuning

Reporting tools, document automation and support workflows can produce legitimate matches. Use narrow exceptions tied to a verified workflow and review date. Avoid excluding every PowerShell process launched by an entire user group: that would hide unrelated activity.

Example 2: PowerShell makes an unfamiliar network connection

Hypothesis: PowerShell network activity deserves closer review when the destination and initiating command do not fit the device’s expected administrative tasks.

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
| where isnotempty(RemoteIP) or isnotempty(RemoteUrl)
| project Timestamp, DeviceId, DeviceName, ActionType,
    RemoteUrl, RemoteIP, RemotePort,
    InitiatingProcessAccountName, InitiatingProcessCommandLine,
    InitiatingProcessId, InitiatingProcessCreationTime
| order by Timestamp desc

This returns observed network events, not a list of malicious destinations. Review ActionType to distinguish the recorded outcomes; do not assume every row represents a successful connection. A blank RemoteUrl also does not mean the destination was harmless or that no network activity occurred.

A fictional investigation

On OPS-WS-12, PowerShell contacts a destination absent from the team’s approved automation inventory. Its unfamiliarity makes it worth investigating; it does not prove command-and-control activity.

1. Identify the exact process instance using the device, process ID and process creation time. A process ID by itself can be reused.
2. Inspect its parent process and full command line in the endpoint timeline. Determine whether a scheduled task, management agent or interactive user initiated it.
3. Review the destination in approved DNS, proxy and threat-intelligence tools. Treat reputation as one signal, not a final verdict.
4. Compare the timing with change records and other devices performing the same task. Correlate relevant file and child-process events.

Suppose the endpoint owner supplies an approved inventory job and its destination and timing match the evidence. That supports a benign conclusion. If the command, destination and process chain remain unexplained, record the uncertainty and escalate with the supporting timeline. Do not open a suspicious destination from a normal workstation just to investigate it.

False positives and coverage limits

Software maintenance and cloud administration can legitimately use PowerShell networking. This query does not automatically calculate rarity, prove data transfer or identify what was sent. Connections made by a child process may appear under that child instead. Use an appropriate historical baseline and additional telemetry to answer those questions.

What a useful hunt report should contain

• Scope: hypothesis, dates, devices and data sources checked.
• Evidence: timestamps, process relationships and relevant events, with sensitive details handled under your organisation’s rules.
• Assessment: what supports the finding, what weakens it and what remains unknown.
• Disposition: escalate, close with a documented benign explanation, or assign a follow-up for missing visibility.
• Improvement: a logging fix, a narrowly scoped exception or a candidate detection to validate.

Validate a candidate detection with labelled benign and suspicious examples in an authorised environment before turning a hunt into an alert. Review the query’s coverage and false positives with the SOC; these examples are not ready-made production detection rules.

Common questions

Does unusual PowerShell activity always mean compromise?

No. Investigate the complete sequence and business explanation. Suspicion becomes more useful when several independent observations support it.

What if the hunt returns no results?

Confirm device onboarding, permissions, event availability and the time range. Then record that this specific search found no matches within its coverage, rather than claiming there was no malicious activity.

Can I use this technique with another SIEM?

Yes. Map the same questions to your process and network logs. The KQL shown here depends on the Defender schema and will need adaptation for other datasets.

For more defensive learning, browse the Knowledge Base Articles. To practise communicating evidence and risk, read the PSIRT interview preparation guide.