D3-PCSV Process Code Segment Verification: Catching Tampered Code in Running Processes

Once an exploit or injector has rewritten the executable code of a running process, every file on disk can still look clean, so the only place the change shows is in memory. MITRE D3FEND names the countermeasure Process Code Segment Verification (D3-PCSV) and defines it as "Comparing the "text" or "code" memory segments to a source of truth." It sits under the Detect tactic as a child of Process Analysis, beside siblings such as Process Spawn Analysis and Process Self-Modification Detection. This card explains how D3-PCSV works, which ATT&CK techniques D3FEND relates to it, where it is implemented, how to prove it works and where it can be bypassed. It is written for detection engineers, EDR owners and incident responders who already know the injection basics in the T1055 Process Injection Defensive Guide.

Key takeaways

• It compares memory with a reference. D3-PCSV checks the loaded code segment of a process (the "text" section, including the import table) against a system of record such as the on-disk binary, a remote checksum or an embedded checksum.
• D3FEND relates it to exploitation and injection. Through the Process Code Segment artefact, D3FEND links it to Process Hollowing (T1055.012), Credential API Hooking (T1056.004) and the exploitation techniques T1068, T1203, T1210, T1211 and T1212.
• The verifier is part of the attack surface. D3FEND's own considerations note that local verification logic, periodic checks and a modifiable source of truth can all be defeated.
• Relocation and legitimate patching cause false positives. Address randomisation, rebasing and security products that hook APIs all change code bytes, so the verifier must account for relocations and known hooks.
• Detection should lead to eviction. D3FEND names Process Termination and Executable Denylisting as follow-on actions when a code segment is found altered.

D3-PCSV at a glance

How it works

D3FEND describes a process code segment as the executable portion of a process's virtual address space that corresponds to the loaded image code segment. D3-PCSV compares that segment with an expected value. The design has three choices.

• Timing: verify once when the application starts, or repeatedly while it runs. A start-up check catches a patched image on disk or a loader that was tampered with; only a continuous check catches code rewritten after start, which is where hollowing, hooking and exploit payloads act.
• Placement of the verifier: D3FEND lists three options. An external process (an EDR sensor or a memory scanner) is harder for the target to tamper with. Logic embedded at compile time is the anti-tamper "guard" model described in the Arxan and Purdue patents D3FEND cites. Dynamically linked logic sits between the two.
• Source of truth: the on-disk binary is convenient but is the same file an attacker may already have replaced. A remote checksum or a signed embedded value is harder to forge. D3FEND warns that verification based on a system of record that a malicious user can modify may fail.

When the comparison fails, D3FEND points to Eviction techniques: Process Termination (D3-PT) to end the process, and Executable Denylisting (D3-EDL) to stop the executable launching again. In practice most implementations raise an alert first, collect the altered memory region for analysis, and terminate only where a high-confidence rule is in place. Termination is covered in D3-PT Process Termination.

What a mismatch usually means

• Hollowing or image replacement: the process name and path are legitimate but the mapped code is a different program. Sysmon records this pattern as Event ID 25, ProcessTampering, which Microsoft describes as generated "when process hiding techniques such as "hollow" or "herpaderp" are being detected."
• Inline hooks: a few bytes at the start of an exported function are overwritten with a jump, the pattern behind Credential API Hooking (T1056.004).
• Exploit payload residue: code pages altered during exploitation of the process itself, the pattern D3FEND links to the exploitation techniques.
• Legitimate change: a security product's own hooks, a compatibility shim or a debugger breakpoint. These are the main source of noise.

ATT&CK techniques D3FEND relates to D3-PCSV

Relationship type: inferred only. Every row below is inferred by D3FEND through the shared Process Code Segment artefact: D3-PCSV verifies Process Code Segment, and these ATT&CK techniques modify or may modify it (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.

The D3FEND ontology also relates the same artefact to four ATT&CK for ICS techniques: Exploitation for Evasion (T0820), Exploitation of Remote Services (T0866), Hooking (T0874) and Exploitation for Privilege Escalation (T0890). Treat all rows as a placement guide, not a coverage claim: verification detects a technique only if it runs after the change, against the right process, with a trustworthy reference. Defensive detail for the exploitation rows is in T1068 Exploitation for Privilege Escalation, MITRE ATT&CK T1203 Exploitation for Client Execution and MITRE ATT&CK T1211 Exploitation for Stealth.

Where it is implemented

Prevention controls work on the same artefact and pair well with verification. Windows exploit protection's Arbitrary code guard prevents memory being marked executable after load, and Code integrity guard blocks mapping of binaries not signed by Microsoft; both offer an Audit only mode. These sit closer to D3FEND's Process Segment Execution Prevention than to D3-PCSV, but they reduce how much a verifier has to find. Endpoint sensor choices are covered in the EDR Guide.

Implementation steps

1. Choose the processes that matter. Start with processes that hold credentials or run with high privilege (lsass.exe, authentication services, the EDR sensor itself), then internet-facing clients and services that D3FEND's exploitation rows describe.
2. Confirm the verifier runs continuously. Check whether your EDR performs periodic or event-driven memory scans and on which processes. A start-up-only check misses hollowing and hooking.
3. Collect the supporting events. If Sysmon is deployed, include Event IDs 8, 10 and 25 in the configuration, filtered as Microsoft advises for Event ID 10 to avoid volume from diagnostic tools. The Sysmon Guide covers configuration.
4. Model legitimate change. List the products that hook or patch code in your estate: other security agents, application compatibility shims, DRM and performance profilers. Record their modules so alerts can be tagged rather than suppressed blindly.
5. Pilot in alert-only mode. Run on one business unit for two to four weeks, review every mismatch and fix noise at its source. Keep termination off until false positives are understood.
6. Enable eviction for high-confidence patterns. Hollowed system processes and unsigned code inside credential processes are good candidates for automatic termination. Roll back by returning the policy to alert-only, not by removing the sensor.

How to verify it works

• Authorised emulation: in a lab or approved test window, run a process hollowing and an API hooking test from an adversary emulation framework your red team already uses, and confirm the alert, the process context and any memory dump reach the SOC.
• Reference integrity check: confirm where the verifier gets its source of truth and that it is protected from local modification (signed, remote or read-only).
• Coverage audit: list hosts where memory scanning is disabled by exclusion, policy or sensor health. EDR exclusions often remove exactly the processes that matter; see the EDR Tuning and Exclusions Management Guide.
• Offline cross-check: after a real or simulated incident, run memory forensics on a captured image and compare with what live tooling reported.

Limits, bypasses and failure patterns

• Local verifier tampering: D3FEND notes that verification run only locally can be defeated by altering the local verification logic. Protect the sensor against tampering, as described in Securing the EDR and XDR platform itself.
• Race windows: a check that runs only on a schedule can be evaded if the alteration completes, and possibly reverts, between runs.
• Copy-and-check evasion: D3FEND notes that verification which operates on a subset of the code segment can be evaded by performing the operation on a copy of the relevant bytes.
• Code outside the image: a payload in newly allocated memory leaves the original code segment untouched. Unbacked executable memory needs its own analysis, which many tools perform alongside code segment checks.
• Relocation noise: address randomisation and module rebasing change bytes legitimately. D3FEND's guidance is to feed the relocation data into the verifier rather than to ignore the module.
• Self-modifying software: packers and some protection products rewrite their own code, which overlaps with D3-PSMD Process Self-Modification Detection.

Framework mapping

The mapping above is an NHI Mgmt Group view; D3FEND itself does not map D3-PCSV to NIST controls.

Related countermeasures

• Process Self-Modification Detection (D3-PSMD): watches the API calls that rewrite code rather than comparing the result. See D3-PSMD Process Self-Modification Detection.
• Process Spawn Analysis (D3-PSA) and Process Lineage Analysis (D3-PLA): flag the unusual parent and child relationships that often accompany hollowing. See D3-PSA Process Spawn Analysis and D3-PLA Process Lineage Analysis.
• Shadow Stack Comparisons (D3-SSC): another Process Analysis child that checks control flow rather than code bytes. See D3-SSC Shadow Stack Comparisons.
• Segment Address Offset Randomization (D3-SAOR): the hardening technique whose relocations a verifier must account for.

Practitioner checklist

• List the high-value processes whose code must be verified continuously.
• Confirm your EDR verifies code segments during execution, not only at start-up.
• Collect Sysmon Event IDs 8, 10 and 25 where Sysmon is deployed.
• Protect the verifier and its source of truth from local modification.
• Record every product that legitimately hooks or patches code and tag its alerts.
• Pilot in alert-only mode before enabling automatic termination.
• Review exclusions that remove credential and security processes from memory scanning.
• Test with authorised hollowing and hooking emulation every quarter.
• Keep a memory forensics capability to cross-check live findings after incidents.

Standards and references

• MITRE D3FEND: Process Code Segment Verification (D3-PCSV)
• MITRE ATT&CK: T1055.012 Process Hollowing
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-7, SI-16)
• Microsoft Learn: Sysmon (Event IDs 8, 10 and 25)
• Microsoft Learn: Exploit protection reference (Arbitrary code guard, Code integrity guard)
• GitHub: PE-sieve
• Volatility Foundation: Volatility 3 malfind plugin

Related NHI Mgmt Group resources: MITRE D3FEND Guide · T1055 Process Injection Defensive Guide · EDR Evasion and Defence Guide · Sysmon Guide · D3-PSA Process Spawn Analysis