D3-PSA Process Spawn Analysis: What It Detects, Which ATT&CK Techniques It Counters and How to Verify It

Most attacker activity on a host eventually needs a new process, and Process Spawn Analysis is the D3FEND countermeasure that inspects each one as it is created. MITRE D3FEND defines D3-PSA as "analyzing spawn arguments or attributes of a process to detect processes that are unauthorized." It sits in the Detect tactic under the parent technique Process Analysis, and it analyses two digital artefacts: the Create Process event and the resulting Process. This card explains how it works, which ATT&CK techniques D3FEND links it to, how to build and verify it, and where it fails. It is written for detection engineers and SOC leads; the parent technique, Process Analysis, covers the wider family.

Key takeaways

• It judges a process at birth. D3-PSA compares spawn attributes (user, process name, image path, security context, arguments, parent) against expected values or patterns.
• Telemetry decides coverage. Without command-line capture in Windows event 4688, Sysmon Event ID 1 or Linux execve auditing, most of the mapped techniques are invisible.
• The D3FEND page relates it to 20 ATT&CK techniques by inference. They cluster around proxy execution (T1218.*), injection, persistence via DLL loading and credential access; D3FEND still lists one of them, Disable or Modify Tools, under an ID that ATT&CK v20 revoked, so this page shows its successor, T1685.
• Spoofable attributes are the main weakness. Parent PID spoofing (T1134.004) and use of a legitimately compromised account defeat checks that trust a single attribute.
• Service identities make strong baselines. Service accounts and workload identities spawn a narrow, predictable set of processes, so a deviation is high signal.

D3-PSA at a glance

How it works

D3FEND's knowledge base article states that process attributes are established when the operating system spawns a new process, and that these attributes are analysed "to look for the presence or absence of specific values or patterns". In practice the analysis runs as rules or models over a stream of process creation records:

• Allow and deny patterns: a known proxy-execution binary such as mshta.exe or rundll32.exe launched with a remote URL or an unusual DLL export is flagged regardless of parent.
• Parent and child pairing: an office application or web server worker spawning a shell is unusual for most estates. Deeper ancestry is the job of the child technique, Process Lineage Analysis.
• Image path checks: a binary named like a system file but running from a user-writable folder. D3FEND notes that if the full image path is not checked, path resolution can pick an executable that appears earlier in the search order.
• Security context: unexpected elevation (Windows token elevation type %%1937 indicates an elevated token from "Run as administrator"), unusual integrity level, or a SYSTEM-owned process launched from an interactive tool.
• Rarity: MITRE CAR analytic CAR-2020-05-003, which D3FEND links to D3-PSA, counts command lines per Living-off-the-Land binary and returns those more than 1.5 standard deviations below the mean. MITRE describes it as best suited to hunting because the threshold needs tuning.

Where identity fits

The user field in a spawn record is an identity signal. Non-human identities are where this pays off most: a SQL Server service account should run sqlservr.exe and a few helpers, not cmd.exe or powershell.exe, and a Kubernetes service account's pod should run its entrypoint, not a package manager. Baseline the process set per service identity and alert on anything new. See the How to detect interactive logons by service accounts guide for the logon side of the same signal, and the How to audit SQL Server service accounts and logins guide for building that inventory.

ATT&CK techniques D3FEND relates to D3-PSA

Relationship type: inferred, not a direct mapping. D3FEND does not map ATT&CK techniques to D3-PSA directly; it infers each relationship because the technique and the countermeasure involve the same digital artefact (Create Process and Process). An inferred relationship shows relevance, not coverage.

The table lists the related offensive techniques shown on the D3FEND D3-PSA page (checked November 2026), each verified against ATT&CK v20. Rows are grouped by ATT&CK v20 tactic. D3FEND still lists Disable or Modify Tools under its pre-v20 ID, which ATT&CK v20 revoked; the table shows the current technique, T1685 Disable or Modify Tools.

The D3FEND ontology also links the Create Process artefact to discovery techniques that may invoke a new process, including T1007 System Service Discovery, T1016 System Network Configuration Discovery, T1018 Remote System Discovery, T1033 System Owner/User Discovery, T1057 Process Discovery and T1082 System Information Discovery, plus T1047 Windows Management Instrumentation. These rarely justify alerts alone, but bursts of them from one session are a useful correlation.

Telemetry sources

Implementation steps

1. Turn on collection. Enable 4688 with command line or deploy Sysmon Event ID 1 on Windows, and execve auditing on Linux servers. Forward to the SIEM with host, user and logon session fields intact.
2. Protect the logs. Command lines can carry secrets passed as arguments. Restrict SIEM access to process data and treat any token seen in a command line as exposed and due for rotation.
3. Build baselines. For each server role and each service identity, record the normal parent and child pairs and image paths over two to four weeks.
4. Write high-confidence rules first. Web server, database engine and office application parents spawning shells; proxy binaries with URLs; system binary names outside system directories.
5. Add rarity hunting. Run a CAR-2020-05-003 style analytic weekly and promote stable findings into rules.
6. Run in alert-only mode. Tune for a sprint before any automated response. If you later wire responses such as process termination, keep a per-rule switch to roll back to alert-only.
7. Map and record coverage. Tag every rule with the ATT&CK IDs from the table so coverage gaps are visible.

How to verify it works

• Emulation tests: run benign, authorised emulations for each mapped technique in a test host (for example a scheduled task that launches a harmless binary, or rundll32 calling a test DLL export) and confirm the matching rule fires within your target time.
• Field checks: sample events and confirm command line, user and full image path are populated on every OS build you run. Empty command lines usually mean the policy did not apply.
• Spoofing check: test that a parent PID spoofing emulation produces an alert or at least an event where reported and real creator differ.

Metrics that show the control is working:

• Percentage of endpoints and servers sending process creation events with command lines (target close to 100%).
• Number of mapped ATT&CK techniques with at least one tested rule, against the 20 listed by D3FEND.
• Median time from process creation to alert in the SIEM.
• True positive rate per rule over 90 days, and the number of rules retired or tuned.
• Share of service identities with a recorded process baseline.

Limits, bypasses and failure patterns

• PPID spoofing: D3FEND notes attackers can spoof the parent process identifier to make a malicious process appear to come from an arbitrary parent. Use sensors that record the real creator.
• Legitimate attributes: an attacker with a stolen admin or service credential produces records with a valid user. Correlate with logon source and time.
• Parsing traps: D3FEND warns that the raw shell command and the actual call can differ; unquoted Windows service paths with spaces are resolved token by token. Normalise on the image path the OS actually loaded.
• Spawn without fork: some operating systems can spawn processes without forking, so Linux rules that only watch fork patterns miss them; watch execve.
• Noise: software deployment tools, installers, IT scripts and developer workstations generate most false positives. Scope rules by host role rather than suppressing whole binaries.
• Silent loss: attackers who disable logging (ATT&CK T1685.001 Disable or Modify Windows Event Log) leave gaps, so alert on missing heartbeat from a host as well as on events.

Framework mapping

For prevention, pair D3-PSA with application control and endpoint behaviour blocking, and see the EDR Guide.

Related countermeasures

• D3-PLA Process Lineage Analysis: the child technique, which follows ancestry beyond the immediate parent.
• D3-SEA Script Execution Analysis: inspects script content that a spawned interpreter runs.
• D3-SCA System Call Analysis: watches behaviour after the process starts.
• D3-PCSV Process Code Segment Verification: checks that a running image matches what was loaded, relevant to Process Doppelgänging.

Practitioner checklist

• Enable Audit Process Creation with command-line capture, or Sysmon Event ID 1, on every Windows host.
• Add execve audit rules with explicit arch fields on Linux servers.
• Restrict access to process telemetry and rotate any secret seen in a command line.
• Baseline processes per server role and per service identity.
• Ship high-confidence parent and child rules before rarity analytics.
• Tag rules with ATT&CK IDs and test each with an authorised emulation.
• Check that your sensor records the real creator to counter PPID spoofing.
• Alert on hosts that stop sending process events.

Standards and references

• MITRE D3FEND: Process Spawn Analysis (D3-PSA)
• MITRE CAR: CAR-2020-05-003 Rare LolBAS Command Lines
• MITRE ATT&CK: T1134.004 Parent PID Spoofing
• Microsoft Learn: 4688 A new process has been created
• Microsoft Sysinternals: Sysmon
• Linux man-pages: audit.rules(7)
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: MITRE D3FEND Guide · Sysmon Guide · EDR Guide · Identity Threat Hunting Guide