Most memory corruption exploits end the same way: a return address on the call stack points somewhere the program never put code, and execution follows it. MITRE D3FEND names the detection of that moment Memory Boundary Tracking (D3-MBT) and defines it as "Analyzing a call stack for return addresses which point to unexpected memory locations." It is a Detect technique under Operating System Monitoring, and its digital artefact is the Process Code Segment. This card explains how the technique works, which ATT&CK techniques D3FEND relates to it, where defenders already have it (Windows exploit protection, hardware shadow stacks, EDR call stack analysis), how to verify it is switched on and producing signal, and where it can be bypassed. It is written for detection engineers and endpoint security teams who already run exploit mitigations and want to know what they actually detect.
Key takeaways
- It checks where code returns to. D3FEND's description is that a return address outside memory previously allocated for an object (a function, module, process or thread) is treated as pointing at malicious code.
- The ATT&CK links are inferred. D3FEND relates D3-MBT to seven enterprise techniques, including exploitation for privilege escalation (T1068), client execution (T1203) and process hollowing (T1055.012), because those techniques modify the same artefact, the process code segment. They are not hand-mapped.
- You probably own an implementation already. Windows exploit protection mitigations such as Validate API invocation (CallerCheck) and Validate stack integrity (StackPivot), and CPU shadow stacks (Intel CET, AMD shadow stack), all perform forms of return address or stack boundary checking.
- Audit mode is the safe way in. The Windows mitigations write odd-numbered audit events and even-numbered block events in the Security-Mitigations log, so you can measure compatibility before enforcing.
- Kernel attackers can blind it. D3FEND's own consideration is that kernel malware can manipulate memory and pointers, so the allocation data the check depends on can be falsified.
D3-MBT at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-MBT (d3f:MemoryBoundaryTracking) |
| Tactic | Detect |
| Parent technique | Operating System Monitoring (D3-OSM) |
| Digital artefact | Process Code Segment (D3FEND relation: analyzes). D3FEND defines it as the part of a program's virtual address space that holds executable instructions, also called the text segment |
| What it inspects | Return addresses on the call stack and whether they fall inside memory allocated to a known object |
| D3FEND reference | CrowdStrike patent US10216934B2, "Inferential exploit attempt detection" |
| Typical implementations | OS exploit mitigations, hardware shadow stacks, EDR sensors that inspect call stacks at sensitive API calls |
| Main limitation | Relies on memory allocation data that kernel-level malware can tamper with; sees only the code paths it is invoked on |
How it works
When a function is called, the processor pushes the address to return to onto the stack. Memory corruption exploits, and in particular return-oriented programming (ROP), overwrite or fabricate those return addresses so that execution flows into attacker-chosen code or short instruction sequences. Memory Boundary Tracking asks a simple question at chosen moments: does this return address point into memory that the system knows was allocated for code belonging to a legitimate module, function or thread?
The reference D3FEND cites, the CrowdStrike patent on inferential exploit attempt detection, describes a security agent that detects an "action of interest" that may indicate an exploit, works out the context in which it occurred, and determines that the action is an exploit attempt if, among other tests, the return address is outside memory previously allocated for an object. Code at that address is then treated as malicious.
In practice there are three ways a defender gets this check:
- Software checks at sensitive API calls: when a process calls an API commonly abused by exploits (memory protection changes, process creation, library loading), the mitigation inspects the call stack and the stack pointer. Windows exploit protection implements this as CallerCheck, StackPivot and, for 32-bit processes, Simulate execution (SimExec).
- Hardware shadow stacks: the CPU keeps a second copy of every return address in memory the program cannot write directly. On return it compares the two and raises a control-protection fault on mismatch. This covers every return, not just those near sensitive APIs.
- EDR telemetry analysis: endpoint sensors capture call stacks for selected events and flag frames that resolve to no loaded module (unbacked or private executable memory). This is the closest match to the patent's agent model. Capabilities and naming differ by product, so check your sensor's documentation.
ATT&CK techniques D3FEND relates to D3-MBT
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-MBT. Each row is inferred because the ATT&CK technique modifies, or may modify, the Process Code Segment that D3-MBT analyzes (D3FEND 1.6.0, checked November 2026). D3FEND labels these relations "inferred, experimental". Every ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation to Process Code Segment | What return address checking can see |
|---|---|---|---|
| T1068 | Exploitation for Privilege Escalation | modifies | A ROP chain or shellcode that calls privileged APIs from an address outside any loaded module |
| T1203 | Exploitation for Client Execution | modifies | A browser or document reader exploit pivoting the stack or returning into injected code |
| T1055.012 | Process Hollowing | modifies | Execution in a process whose code no longer matches its mapped image |
| T1056.004 | Credential API Hooking | may-modify | Hooks that divert calls through attacker code, leaving return addresses in unexpected regions |
| T1210 | Exploitation of Remote Services | may-modify | A network service exploit that hijacks control flow inside the service process |
| T1211 | Exploitation for Stealth | may-modify | Exploits used to bypass security software, which still need a corrupted control flow |
| T1212 | Exploitation for Credential Access | may-modify | Exploits against authentication components that run attacker code in process |
D3FEND's ontology also links ATT&CK for ICS techniques to the same artefact: T0820 Exploitation for Evasion, T0866 Exploitation of Remote Services, T0874 Hooking and T0890 Exploitation for Privilege Escalation. These apply where Windows or Linux engineering workstations and servers in OT run the same mitigations. Read the rows as "where the check can help", not as coverage: an exploit that never reaches a monitored call, or that uses only legitimate code paths, produces no signal. Defensive detail for the main techniques is in T1068 Exploitation for Privilege Escalation, MITRE ATT&CK T1203 Exploitation for Client Execution and T1055 Process Injection Defensive Guide.
Where it is implemented
| Implementation | What it checks | Signal | Notes |
|---|---|---|---|
| Windows exploit protection: Validate API invocation (CallerCheck) | That sensitive APIs are called from a valid caller, to defend against ROP | Security-Mitigations events 21 (audit) and 22 (enforce) | Per-application setting; audit mode available |
| Windows exploit protection: Validate stack integrity (StackPivot) | That the stack pointer is within the thread's stack bounds during intercepted API calls | Events 19 (audit) and 20 (enforce) | Per-application; audit mode available |
| Windows exploit protection: Simulate execution (SimExec) | Simulates sensitive API calls to confirm they return to legitimate callers | Events 23 (audit) and 24 (enforce) | 32-bit processes only |
| Windows Hardware-enforced Stack Protection (user mode) | Every return against a hardware shadow stack | Process terminated on mismatch; recorded as an exploit protection event | Needs Intel CET or AMD shadow stack hardware; "compatible modules" or "all modules" option |
| Windows Kernel-mode Hardware-enforced Stack Protection | Every kernel return against a shadow stack | Bug check on mismatch; incompatible drivers blocked from loading | Off by default; requires VBS and memory integrity (HVCI); enforcement mode only |
| Linux user-space shadow stack (x86) | Every user-space return against a shadow stack | Control-protection fault in the process | Kernel option X86_USER_SHADOW_STACK, enabled per process by the C library through arch_prctl(); binaries must be built with CET markers |
| EDR call stack analysis | Return addresses in call stacks captured at selected events, resolved against loaded modules | Vendor alerts and telemetry | Depth and naming vary by product; confirm in vendor documentation |
Compiler and runtime controls such as stack canaries and pointer authentication protect the same control flow at a different point. See D3-SFCV Stack Frame Canary Validation and D3-PAN Pointer Authentication. The ATT&CK mitigation that groups all of these is covered in M1050 Exploit Protection.
Implementation steps
- Inventory the hardware. List endpoints and servers with CET-capable or AMD shadow stack CPUs (on Linux, /proc/cpuinfo shows user_shstk when kernel and hardware support it). Hardware shadow stacks give the broadest coverage, so this decides how much you lean on software checks.
- Pick the exposed applications first. Browsers, document readers, email clients, scripting hosts and internet-facing services are where T1203 and T1210 land. Start the per-application mitigations there rather than system-wide.
- Turn on audit mode. Set CallerCheck, StackPivot and, for 32-bit applications, SimExec to audit for the chosen applications through Intune, Group Policy or the exploit protection XML. For user-mode hardware stack protection, start with compatible modules only.
- Collect the events. Forward the Security-Mitigations log (events 19 to 24 for these mitigations) to the SIEM, or query the equivalent exploit protection events in your EDR or SIEM.
- Pilot and tune. Run a pilot ring for two to four weeks (an example period, not a standard). Applications that use code obfuscation, packers, JIT engines or third-party hooking can trip these checks. Record each hit, confirm it is benign with the application owner, and exclude that application from that one mitigation only.
- Enforce in rings. Move to enforce for the pilot, then wider rings. For kernel-mode stack protection, check the Windows Security app's list of incompatible drivers first: the feature fails to enable while a blocklisted driver is installed.
- Keep a rollback. Keep the previous exploit protection XML and policy version. Rolling back one mitigation for one application is the normal response to a breaking change; disabling the whole feature is the last resort.
How to verify it works
- Configuration check: export the effective exploit protection settings from a sample of devices (Get-ProcessMitigation in PowerShell) and compare with the intended baseline. On Linux, read /proc/<pid>/status and check x86_Thread_features shows shstk for processes that should have it.
- Binary readiness: on Linux, readelf -n on a binary shows whether it carries the SHSTK marker; unmarked binaries run without shadow stack even on capable hardware.
- Controlled test: in a lab, run a vendor-supplied or open test harness that triggers the mitigation for a test process, and confirm the audit or block event reaches the SIEM with host, process and mitigation name. Use authorised test tools only.
- Telemetry health: alert when a device that normally emits Security-Mitigations events or ExploitGuard actions stops reporting, since a disabled sensor and a quiet estate look the same.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| High-exposure applications with return address checks in enforce mode | Rising each quarter towards all | Coverage where exploits land |
| Capable devices with hardware stack protection on | Tracked per hardware generation | Uses the broadest check available |
| Open per-application exclusions older than 90 days | Reviewed and justified | Exclusions are where coverage quietly erodes |
| Enforce-mode block events triaged within one working day | 100% | A block may be a stopped exploit or a broken app |
| Devices reporting mitigation telemetry | Matches managed device count | Detects silent sensor or policy loss |
Limits, bypasses and failure patterns
- Kernel-level tampering: D3FEND notes that kernel malware can manipulate memory, for example modifying pointers to hide processes, which undermines the allocation information the check uses. Vulnerable signed drivers are a common route; see the Bring Your Own Vulnerable Driver and EDR Killers Guide.
- Checks only at chosen moments: software checks run at intercepted API calls. Exploits that avoid those APIs, or reach them through legitimate code, can pass unseen. Hardware shadow stacks close much of this gap for returns but not for forward-edge (indirect call and jump) hijacks, which need Control Flow Guard or indirect branch tracking.
- Data-only and logic attacks: exploits that change data or abuse legitimate functions without diverting returns never trip a return address check.
- Exclusions that outlive their reason: one broken plug-in leads to an exclusion for the whole browser, and nobody revisits it.
- Audit mode forever: audit events are collected but never acted on, so the control detects in theory and stops nothing in practice.
- Old builds and missing markers: software compiled without CET support, or 32-bit processes excluded from newer mitigations, keep running without the protection.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-16 Memory Protection | Controls that protect memory from unauthorised code execution |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring that turns mitigation events into alerts |
| NIST SP 800-53 Rev 5 | SC-51 Hardware-based Protection | Hardware mechanisms such as shadow stacks |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring computing hardware, software and runtime environments; analysing adverse events |
| MITRE ATT&CK | M1050 Exploit Protection | ATT&CK's mitigation grouping for these controls |
| MITRE D3FEND | D3-OSM, D3-MBT | Parent and technique |
Related countermeasures
- Process Code Segment Verification (D3-PCSV): verifies the same artefact by comparing code in memory to the image on disk.
- Shadow Stack Comparisons (D3-SSC): the D3FEND technique for hardware and software shadow stacks specifically.
- Stack Frame Canary Validation (D3-SFCV) and Pointer Authentication (D3-PAN): compile-time and hardware controls that stop the same corruption earlier.
- System Call Analysis (D3-SCA): another Operating System Monitoring view of the same process behaviour. See D3-SCA System Call Analysis.
Practitioner checklist
- Inventory CET or AMD shadow stack capable hardware and plan to use it.
- Apply CallerCheck and StackPivot (and SimExec for 32-bit) to internet-facing and document-handling applications.
- Start every mitigation in audit mode and forward Security-Mitigations events 19 to 24 to the SIEM.
- Exclude by application and by mitigation, never globally, and review exclusions on a schedule.
- Check for incompatible drivers before enabling kernel-mode stack protection.
- On Linux, confirm kernel support, CET-marked binaries and shstk in process status.
- Alert on loss of mitigation telemetry from managed devices.
- Pair return checks with forward-edge controls (CFG or indirect branch tracking) and driver blocklisting.
Standards and references
- MITRE D3FEND: Memory Boundary Tracking (D3-MBT)
- Google Patents: US10216934B2 Inferential exploit attempt detection
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-16 Memory Protection)
- Microsoft Learn: Exploit protection reference
- Microsoft Learn: Protect devices from exploits (event IDs)
- Microsoft Learn: Kernel-mode Hardware-enforced Stack Protection
- Linux kernel documentation: Control-flow Enforcement Technology (CET) Shadow Stack
Related NHI Mgmt Group resources: M1050 Exploit Protection · EDR Guide · Memory-Safe Languages Guide · MITRE D3FEND Guide