A malicious process often looks ordinary by name and path, but its parent rarely does: Word does not normally start a command shell, and lsass.exe is not normally started by anything except wininit.exe. MITRE D3FEND calls this countermeasure Process Lineage Analysis (D3-PLA), synonym Process Tree Analysis, and defines it as "Identification of suspicious processes executing on an end-point device by examining the ancestry and siblings of a process, and the associated metadata of each node on the tree, such as process execution, duration, and order relative to siblings and ancestors." It sits under the Detect tactic as the child of Process Spawn Analysis (D3-PSA), which is itself under Process Analysis. This card covers how lineage analysis works, the ATT&CK techniques D3FEND relates to it, the telemetry it needs on Windows and Linux, how to verify it and how attackers get around it. It is written for detection engineers and SOC analysts who already use the parent-level D3-PSA Process Spawn Analysis page.
Key takeaways
- Context beats names. D3-PLA judges a process by its ancestors, siblings, order and duration, so it catches trusted binaries started in untrusted ways.
- MITRE CAR supplies ready analytics. D3FEND cites more than a dozen Cyber Analytics Repository entries, including Processes Started From Irregular Parent (CAR-2020-11-004) and Processes Spawning cmd.exe (CAR-2013-02-003).
- Telemetry decides coverage. On Windows you need Sysmon Event ID 1 or Security event 4688 with the creator process name; on Linux, audit records carrying ppid and exe.
- Parent spoofing is the classic bypass. D3FEND's own considerations note that a spoofed parent PID renders after-the-fact lineage analysis ineffective; ATT&CK tracks this as Parent PID Spoofing (T1134.004).
- Blocking is possible for known bad lineages. D3FEND gives the example of Word blocking subprocesses outside approved paths; attack surface reduction rules apply that idea to Office and PDF readers.
D3-PLA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-PLA (d3f:ProcessLineageAnalysis) |
| Synonym | Process Tree Analysis |
| Tactic | Detect |
| Parent technique | Process Spawn Analysis (D3-PSA), under Process Analysis (D3-PA) |
| Digital artefacts | Process and Process Tree (D3FEND relation: analyzes) |
| Typical data sources | Sysmon Event ID 1, Windows Security event 4688, Linux audit SYSCALL records, EDR process telemetry |
| Effort | Low to start with published analytics; medium to maintain environment-specific baselines |
| Main limitation | Spoofed parents, hidden processes and parents that exit before telemetry is recorded |
How it works
D3FEND describes process tree analysis as gathering information on how a process was initiated to decide whether it is malicious. Its examples: a process not initiated from boot or by another process is suspicious, and a process started before a boot-time process and not initiated by a user is suspicious. In practice detections fall into four patterns.
- Irregular parent of a system process: core Windows processes have fixed parents. CAR-2020-11-004 lists them, for example lsass.exe expected from wininit.exe or winlogon.exe, services.exe from wininit.exe, and spoolsv.exe from services.exe. A mismatch can indicate process hollowing.
- Unusual child of an application: an office application, PDF reader or mail client starting cmd.exe, PowerShell or a script host. CAR-2013-02-003 hunts cmd.exe children and names Adobe Reader and Outlook as unusual parents.
- Service and server process children: a web server worker or a mail transport process starting shells, the lineage signature of Web Shell (T1505.003) and Transport Agent (T1505.002) abuse.
- Remote execution lineage: children of WMI provider hosts or remote service creation, which CAR-2014-12-001 Remotely Launched Executables via WMI addresses.
Duration and sibling order add precision. A child process that runs for under a second after its parent opened a document, or a burst of discovery commands in quick succession from one parent (CAR-2013-04-002), is more telling than a single event.
Telemetry you need
| Platform | Source | Lineage fields | Notes |
|---|---|---|---|
| Windows | Sysmon Event ID 1, Process creation | Image and parent image, command lines for current and parent process, ProcessGuid | Microsoft describes ProcessGUID as unique across a domain to make correlation easier, which avoids PID reuse errors |
| Windows | Security event 4688 | New Process ID, Creator Process ID, Creator Process Name, Process Command Line | Requires the Audit Process Creation subcategory; Creator Process Name is in event version 2 (Windows 10 and later); command line needs the policy "Include command line in process creation events" |
| Linux | Audit SYSCALL records for execve | pid, ppid, auid, uid, comm, exe | auid (login UID) survives user switches, which ties a process tree back to the person or service that logged in |
| Any | EDR process telemetry | Full tree with timestamps, often with original parent and creator recorded separately | The easiest route to sibling order and duration |
Collection details are in the Sysmon Guide.
Where identity fits
Lineage tells you which identity really launched an action. A service account running a scheduled task, a CI runner spawning shells or a web application pool identity starting cmd.exe are all non-human identities whose normal process trees are narrow and predictable, which makes deviations easy to see. Baseline the trees per service account rather than per host, and watch for credential dumping children under them: the inferred T1003 rows below are the path from a compromised process to stolen credentials, covered in T1003 OS Credential Dumping.
ATT&CK techniques D3FEND relates to D3-PLA
Relationship type: inferred only. D3FEND derives these rows through the shared Process artefact: D3-PLA analyzes Process, and the techniques below act on a Process (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | Lineage signal to look for |
|---|---|---|---|
| T1003.001 | LSASS Memory | accesses Process | Tools or utilities opening lsass.exe that descend from a shell, script host or remote session |
| T1003.002 | Security Account Manager | may-access Process | reg.exe or similar launched from a command shell to save registry hives (compare CAR-2013-03-001) |
| T1003.004 | LSA Secrets | may-access Process | Same pattern as SAM, targeting the SECURITY hive |
| T1505.003 | Web Shell | produces Process | Web server worker processes spawning shells or discovery commands |
| T1546.007 | Netsh Helper DLL | produces Process | Unexpected children of netsh.exe |
| T1553.006 | Code Signing Policy Modification | may-create Process | Boot configuration tools run from a shell (compare CAR-2021-05-003, BCDEdit failure recovery modification) |
| T1564.011 | Ignore Process Interrupts | creates Process | Processes launched under nohup or similar wrappers from unexpected parents |
The D3FEND web page also lists further techniques reached through related artefacts, including Scheduled Task (T1053.005), Transport Agent (T1505.002), Modify Authentication Process (T1556), Multi-Factor Authentication Request Generation (T1621), Exploitation for Credential Access (T1212), System Owner/User Discovery (T1033) and Use Alternate Authentication Material (T1550). It also lists Disable or Modify Tools under an ID that ATT&CK v20 has revoked; the v20 successor is T1685 Disable or Modify Tools. Treat these rows as hunting leads, not as coverage claims. For web shell lineage in depth, see the Web Shell Response Playbook.
Where it is implemented
| Implementation class | What it provides | Fits when |
|---|---|---|
| SIEM analytics on process creation logs | Rules on parent and child pairs from Sysmon, 4688 or audit records; MITRE CAR gives pseudocode and Splunk and LogPoint implementations | You already centralise process creation logs |
| EDR process tree analytics | Full trees with timing and sibling context, behavioural detections and analyst tree views | You run an EDR and want tree context without building it |
| Endpoint blocking rules on lineage | Attack surface reduction rules such as "Block all Office applications from creating child processes" (GUID d4f940ab-401b-4efc-aadc-ad5f3c50688a), "Block Adobe Reader from creating child processes" and "Block process creations originating from PSExec and WMI commands" | Windows estates where a known bad lineage can be blocked outright |
| Linux audit and host agents | execve auditing with ppid and auid, forwarded to a SIEM | Linux servers, especially web and CI hosts |
Microsoft notes the Office child process rule is enforced only when Office is installed in %ProgramFiles% or %ProgramFiles(x86)%. Rollout of those rules is covered in How to Deploy Attack Surface Reduction Rules.
Implementation steps
- Turn on process creation telemetry everywhere. Windows: Sysmon Event ID 1, or 4688 with the command line policy. Linux: an execve audit rule. Confirm parent fields are populated in the SIEM, not only on the host.
- Start with fixed-parent rules. Deploy the CAR-2020-11-004 parent table for core Windows processes. These rules rarely need tuning beyond the agent exclusions CAR itself mentions.
- Add application child rules. Office, PDF readers, mail clients, browsers and web server workers spawning shells or script hosts. Run in alert-only or audit mode first.
- Baseline service accounts and servers. For each server role and service account, record the normal set of child processes over two to four weeks, then alert on new pairs.
- Block where audit data supports it. Move clean rules to block mode on a pilot ring, then widen. Roll back by switching the rule to audit, which keeps visibility.
- Link to response. A lineage alert should open the full tree in the analyst view, including the grandparent and siblings, so triage does not start from a single event.
How to verify it works
- Unit tests from CAR: CAR analytics include simple tests, for example running cmd.exe from a command prompt for CAR-2013-02-003. Run the benign test and confirm the event and the parent field reach the SIEM.
- Authorised emulation: in an approved window, open a test document that starts a harmless child process, and run a scheduled task and a WMI remote launch from a test host. Confirm each produces the expected lineage alert.
- Parent field completeness: sample process creation events daily and measure the share with a populated parent image. CAR notes the irregular parent analytic fails if the parent exits before Sysmon processes the event.
- Spoofing test: include a Parent PID Spoofing test in purple team exercises and confirm whether your tooling records the real creator as well as the claimed parent.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Process creation events with parent image populated | Above 99% | Without the parent, lineage rules cannot fire |
| Endpoints and servers sending process creation telemetry | Above 95% of managed assets | Coverage gaps hide whole trees |
| Lineage emulation tests detected | 100% per quarter | Proves rules and pipeline work end to end |
| Lineage alerts closed as benign after tuning | Falling month on month | Shows baselines reflect real behaviour |
| Service accounts with a recorded process baseline | Rising quarter on quarter | Non-human identities are where lineage is most predictable |
Limits, bypasses and failure patterns
- Parent PID spoofing: D3FEND names this as the main weakness. An attacker can create a process that reports a chosen parent, defeating rules that trust the parent field. ATT&CK tracks this as T1134.004; see MITRE ATT&CK T1134 Access Token Manipulation.
- Hidden processes: D3FEND notes that on Linux a rootkit may remove a process's entries from /proc, so tools reading /proc never see the node.
- Short-lived and zombie processes: D3FEND lists zombie processes as a consideration, and CAR notes that a parent that exits early can leave the parent field empty.
- Breaking the chain on purpose: scheduled tasks, WMI and services re-parent execution under system processes, so the attacker's original shell no longer appears as the ancestor. Rules on those launchers (CAR-2014-12-001) close part of the gap.
- Over-broad allowlists: excluding a parent such as a management agent because it is noisy hides every child it ever starts, including attacker commands sent through it.
- Single-event triage: analysts reviewing the child without the grandparent miss the real entry point; fix this in the alert template, not in the rule.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring the system to detect attacks and indicators, which lineage analytics implement |
| NIST SP 800-53 Rev 5 | AU-12 Audit Record Generation | Generating the process creation records lineage depends on |
| NIST SP 800-53 Rev 5 | CM-7 Least Functionality | Blocking unneeded child processes from applications |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring software and runtime environments; analysing adverse events |
| MITRE D3FEND | D3-PA, D3-PSA, D3-PLA | Grandparent, parent and technique |
The NIST mapping above is an NHI Mgmt Group view; D3FEND does not map D3-PLA to NIST controls.
Related countermeasures
- Process Spawn Analysis (D3-PSA): the parent technique, which looks at process creation more broadly.
- Script Execution Analysis (D3-SEA): inspects what script hosts run once lineage has flagged them. See D3-SEA Script Execution Analysis.
- Process Code Segment Verification (D3-PCSV): confirms whether a process with an irregular parent has been hollowed. See D3-PCSV Process Code Segment Verification.
- Process Termination (D3-PT): the eviction step when a lineage alert is confirmed. See D3-PT Process Termination.
Practitioner checklist
- Collect process creation with parent fields on every Windows and Linux asset.
- Enable the 4688 command line policy or deploy Sysmon Event ID 1.
- Deploy fixed-parent rules for core Windows processes first.
- Alert on shells and script hosts started by office, PDF, mail and web server processes.
- Baseline child processes per service account and server role.
- Move clean rules to block mode through pilot rings, keeping audit as the rollback.
- Show grandparent and siblings in every lineage alert.
- Test Parent PID Spoofing in purple team exercises.
- Review allowlisted parents quarterly.
Standards and references
- MITRE D3FEND: Process Lineage Analysis (D3-PLA)
- MITRE CAR: CAR-2020-11-004 Processes Started From Irregular Parent
- MITRE CAR: CAR-2013-02-003 Processes Spawning cmd.exe
- MITRE ATT&CK: T1134.004 Parent PID Spoofing
- Microsoft Learn: Sysmon
- Microsoft Learn: Event 4688, a new process has been created
- Microsoft Learn: Attack surface reduction rules reference
- Red Hat: Auditing the system (RHEL 9)
Related NHI Mgmt Group resources: MITRE D3FEND Guide · D3-PSA Process Spawn Analysis · Sysmon Guide · T1505 Server Software Component Defensive Guide · EDR Guide