MITRE D3FEND Process Analysis Implementation Guide: Building Layered Runtime Detection on Hosts

Attackers rarely bring a binary that a hash list will catch; they run PowerShell, inject into trusted processes and abuse signed system tools, so the only reliable signal is what processes actually do. MITRE D3FEND groups the runtime observation of processes under Process Analysis (D3-PA), a technique in the Detect tactic that it describes as observing a running application process and analysing it for behaviours or conditions that may indicate adversary activity, either inside the process or through a third-party monitoring tool. D3-PA has eleven child techniques, from process spawn and lineage analysis through system call, script and database query analysis to hardware-assisted checks such as shadow stack comparison. This guide explains how the family fits together, which telemetry each child needs, how to sequence a rollout and how to measure it. It is written for detection engineers, endpoint owners and SOC leads. Each child has its own page on this site; this page does not repeat them. For D3FEND itself see the MITRE D3FEND Guide.

Key takeaways

• Process Analysis watches behaviour, not identity. It sits above hash and indicator checks on the Pyramid of Pain because attackers find behaviour harder to change than file names or hashes.
• The family has eleven children in two levels. Process Spawn Analysis contains Process Lineage Analysis, and System Call Analysis contains File Creation Analysis; the other nine sit directly under D3-PA.
• Telemetry decides what you can do. Spawn, lineage and file creation analysis run on standard operating system and EDR logs; memory and control-flow checks need agents or processor features.
• Start with process creation, then go deeper. Command-line and parent-child analysis gives the broadest coverage for the least effort, and most published analytics build on it.
• D3FEND's ATT&CK links are broad and inferred. They span injection, privilege escalation, credential access, discovery and persistence, and the site labels them inferred and experimental.

What D3FEND means by Process Analysis

In the D3FEND ontology D3-PA sits directly under Defensive Technique and enables the Detect tactic. Across its children D3FEND relates the family to nine digital artefacts: it analyses Process, Create Process, Process Tree, System Call, Local Resource Access, Stack Frame, Database Query and Script Application Process, and it verifies Process Code Segment. Those artefacts are a useful guide to telemetry: each one is a log source or sensor you either have or need.

Analysis can happen in two places. In-process techniques, such as script engines passing content to a scanner or an application inspecting its own database queries, see decoded content and context. Third-party techniques, such as an EDR agent, Sysmon or the Linux audit subsystem, observe from outside and are harder for the monitored process to disable. Most estates need both.

The child techniques

Every child technique in the D3FEND ontology under D3-PA, as of November 2026. Indented names are children of the row above.

The children fall into three tiers by what they need. Log-based (PSA, PLA, FCA, SCA, FAPA) run on process, file and system call telemetry. Engine-hooked (SEA, DQSA) need a hook in the script engine or the data access layer. Memory and control-flow (PSMD, PCSV, IBCA, SSC) need an agent with memory inspection or processor features, and are usually delivered by endpoint products or the platform rather than built in-house.

Telemetry by child technique

The sources below are examples, listed by platform. They are not the only options; endpoint detection products collect equivalent data.

Two details trip up many deployments. Microsoft documents that the Process Command Line field in event 4688 is empty unless the command-line policy setting is enabled. The Linux auditctl manual warns that some systems install a default -a never,task rule that stops new processes being audited, and that arch should precede -S in syscall rules. See the Sysmon Guide.

How to choose, combine and sequence the children

The order below is our recommendation, not a D3FEND requirement. It front-loads the children with the widest coverage and the most published analytics.

1. Process creation with command lines (PSA). Turn on full command-line capture on every Windows and Linux host. MITRE's Cyber Analytics Repository (CAR), which D3FEND cites heavily for PSA, provides analytics with a hypothesis, pseudocode and a unit test for each, mapped to ATT&CK.
2. Lineage (PLA). Add parent and grandparent context to every process event, keyed on a stable process identifier such as Sysmon's ProcessGUID, so you can flag office applications spawning shells or services launching command interpreters.
3. Script inspection (SEA). Make sure the script engines you allow submit content for scanning, so decoded and dynamically generated script is seen, not only the obfuscated launcher. See the T1059 Command and Scripting Interpreter Defensive Guide.
4. Sensitive system calls and file creation (SCA, FCA). Watch handle access to credential stores, remote thread creation and writes to autostart locations, filtered to remove expected access.
5. Behavioural file patterns (FAPA). Detect mass rename, overwrite or delete patterns typical of ransomware and wipers, ideally with an automatic response.
6. Memory and control-flow (PSMD, PCSV, SSC, IBCA). Turn on what your endpoint product and platform provide, and enable shadow stack support for applications built with it. These are hard to build yourself.
7. Application-specific (DQSA). Apply to internet-facing applications with databases, alongside parameterised queries in code. See the ORM Security Guide.

Testing and rollback

• Audit volume first: Sysmon's documentation warns that image load and process access logging generate large volumes and should be filtered. Pilot new collection on a small ring, measure events per host per day, then expand.
• Detect before you block: run new behavioural rules as alerts for two to four weeks, tune exclusions with named owners, then enable prevention ring by ring with a documented switch back to alert mode.
• Prove each rule fires: run the CAR unit test or a safe emulation in a test environment and confirm both the event and the alert.

ATT&CK techniques D3FEND relates to Process Analysis

D3FEND relates D3-PA to offensive techniques through the artefacts its children analyse and states that these mappings are "inferred, experimental, and will improve as the knowledge graph grows". The list is long, so the table groups representative entries by tactic using ATT&CK v20 IDs.

D3FEND's page still lists the revoked Impair Defenses entry for disabling tools; its ATT&CK v20 successor is T1685 Disable or Modify Tools, which process analysis helps detect when security agents are stopped or tampered with. For depth on the most common techniques see the T1055 Process Injection Defensive Guide, T1003 OS Credential Dumping and T1685 Disable or Modify Tools Defensive Guide.

Limits and bypasses

• Parent spoofing: T1134.004 lets an attacker set a misleading parent, so lineage rules should also check the creating process where the operating system records it (event 4688 records the Creator Process ID and, from Version 2, the Creator Process Name).
• Native API and direct calls: techniques that avoid common user-mode APIs can bypass hooks, which is why kernel or processor-level sources matter for SCA and SSC.
• Sensor tampering: an attacker with administrative rights can stop or blind a monitoring agent. Alert on sensor health and on gaps in event flow per host.
• Living off the land: signed system tools generate legitimate-looking process events; detection depends on unusual arguments and lineage, not the binary name. See the Living off the Land Guide.

Where identity fits

Every process runs as an identity, and many of the most useful D3-PA detections are really identity detections: a service account spawning an interactive shell, a CI runner starting credential-dumping tools, a web server process running reconnaissance commands. Record the user and logon session on every process event, baseline what each service account normally launches, and alert on departures. Process access to credential stores (SCA) is also the main way stolen machine credentials are harvested from hosts. See the Credential Dumping Guide.

Detection and measurement

Metrics we suggest at NHI Mgmt Group:

1. Command-line coverage: percentage of hosts sending process creation events with full command lines.
2. Lineage completeness: percentage of process events with resolvable parent context.
3. Child coverage: number of the eleven D3-PA children with a working data source and at least one tested rule.
4. Emulation pass rate: percentage of tested ATT&CK behaviours that produced both telemetry and an alert.
5. Sensor health: percentage of hosts with no unexplained telemetry gap over 24 hours.
6. Noise: alerts closed as benign per rule per week, tracked to drive tuning.

Framework mapping

Common failure patterns

• Process events without command lines. The executable name alone cannot separate legitimate PowerShell from malicious PowerShell.
• Collecting everything, analysing nothing. Unfiltered process access and image load logging overwhelms storage and analysts, and rules are never written.
• Lineage keyed on reused process IDs. Without a stable identifier, parent-child joins link unrelated processes and produce wrong conclusions.
• Exclusions that never expire. Broad path or process exclusions added to cut noise become blind spots attackers use. See the EDR Tuning and Exclusions Management Guide.
• Linux and servers left out. Coverage on workstations only misses web servers and build hosts, where web shells and supply chain attacks run.
• No sensor health monitoring. A stopped agent looks identical to a quiet host.

Practitioner checklist

• Enable command-line capture in process creation events on all Windows and Linux hosts.
• Correlate process events on a stable process identifier and keep parent context.
• Map each of the eleven D3-PA children to a data source, rule set and owner.
• Make allowed script engines submit content for scanning.
• Filter process access and file creation telemetry to sensitive targets before scaling.
• Run new rules in alert mode, tune with owners, then enable prevention in rings.
• Test each rule with a CAR unit test or safe emulation and record the result.
• Baseline what each service account launches and alert on new process types.

Standards and references

• MITRE D3FEND: Process Analysis
• MITRE: Cyber Analytics Repository (CAR)
• Microsoft Learn: 4688(S) A new process has been created
• Microsoft Learn: Sysmon
• Microsoft Learn: Antimalware Scan Interface (AMSI)
• Linux man-pages: auditctl(8)
• Linux kernel documentation: Control-flow Enforcement Technology (CET) Shadow Stack
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: MITRE D3FEND Guide · EDR Guide · Sysmon Guide · Detection Engineering Guide · Memory Forensics Guide