Definition
Preventing execution of any address in a memory region other than the code segment.
How it works
During execution of a process, the instruction pointer register should only point to addresses in a code segment (also called the .text segment), as this is the sole segment which should contain program code.
When this technique detects an attempt to execute something that has been designated as non-executable, other techniques such as those in **Process Eviction** might be invoked, such as **Process Termination** to end the current process, or **Executable Blacklisting** to blacklist the potentially vulnerable or malfunctioning executable.
Software-based implementations
The software-based implementation in Windows XP SP2 might not check that every time the instruction pointer is changed, and does not check on each jump or return. Before calling an exception handler, Windows XP SP2 software-enforced DEP checks whether the exception handler is located in a memory region marked as executable. If the program was also built with SafeSEH, this implementation also checks before changing control to the exception handler whether it is a registered exception handler in the program's file on disk.
Hardware-based implementations
The NX (No Execute) or XD (Execute Disable) bit on the processor specifies whether a certain part of memory is executable. Early implementations set this bit by the memory segment, while modern implementations which are built on the flat memory model often store this bit in each entry of the page table, to control execution by the page.
Considerations
Non-hardware process data segment execution prevention is more susceptible to being able to be turned off for a page of memory.
Different implementations of this defense have been in place since the 1980s, but implementation stalled when larger 16-bit programs began stuffing code in the segments usually reserved for data. Many modern programs follow the best practice of separation of code and data, are able to run under this defense.
ROP or ret2libc/return-to-function attacks could bypass this defense, as although they may pass attacker-controlled data or stack frames to a function, they abuse functions that are legitimately located in the .text segment (code segment) of the program. For those, more advanced defenses such as a table of valid jump addresses, function call analysis, or return depth analysis could be used.
Implementation perspective
Process Segment Execution Prevention should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes Process Segment.
Use the technique to increase the effort, prerequisites, or constraints an adversary must overcome before exploitation or misuse succeeds.
Questions to ask
- Which component, configuration, credential, interface, or behavior is being hardened?
- What secure baseline or policy defines the intended state?
- How are exceptions approved, time-limited, and reviewed?
- How is the hardened state verified after deployment and significant change?
Evidence and validation
- Approved hardening standards and configuration baselines
- Automated configuration or integrity assessment results
- Exception records with owners, rationale, and expiration dates
- Test results demonstrating that the intended restriction is enforced
Common failure patterns
- A secure setting is documented but not enforced consistently across the environment.
- Hardening breaks required functions and is permanently weakened through undocumented exceptions.
- Teams measure deployment of a product rather than verification of the hardened condition.
This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.
Technique hierarchy
Top-level family
Parent techniques
Direct child techniques
None listed at this level.
Artifacts and ontology entities
These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.
Explicit technique relationships
Show inferred artifact relationship paths (1)
ATT&CK Enterprise mitigation relationships
These links come from the D3FEND ontology’s ATT&CK mitigation mapping. They help users navigate between the knowledge bases and do not guarantee mitigation effectiveness.
Offensive-technique relationships
These relationships are generated from D3FEND graph paths and are explicitly experimental. They should be treated as hypotheses for defensive analysis—not as proof that the technique prevents, detects, or removes an offensive behavior.
ATT&CK Enterprise (12)
ATT&CK for ICS (5)
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- Mitigate threats by using Windows 10 security features: Data Execution Prevention ↗Microsoft · Nick Schonning, Daniel Simpson, Marty Hernandez Avedon, Trond B. Krokli, jreeds, jcaparas, Andres Mariano Gorzelany, Tina Burden, Thomas Raya, Justin Hall, justanotheranonymoususer, Liza Poggemeyer, Dani Halfin, imba-tjd (Authors for entire page) · UserManualReference
- What is NX/XD feature? ↗Red Hat · Red Hat · InternetArticleReference
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.