Memory corruption exploits usually need to know where code or data sits in memory, and randomising those addresses at every process start turns a reliable exploit into a guess. MITRE D3FEND names this countermeasure Segment Address Offset Randomization (D3-SAOR), lists Address Space Layout Randomization (ASLR) as its synonym, and defines it as "Randomizing the base (start) address of one or more segments of memory during the initialization of a process." It sits under the Harden tactic as a child of Application Hardening. ASLR is on by default in current operating systems, so the practical work is finding the binaries and settings that opt out, closing the gaps, and knowing what ASLR does not stop. This card is for application security engineers, platform hardening teams and vulnerability managers; the wider family of mitigations is covered in the Exploit Mitigations Guide.
Key takeaways
- Randomisation needs cooperation from the binary. An executable or library that was built without relocation support or position independence loads at a fixed address, and one fixed module can be enough for an attacker.
- The defaults are good, the exceptions are not. The Microsoft linker sets /DYNAMICBASE by default and current Linux kernels randomise stack, mmap base and heap by default; the gaps are legacy builds, third-party binaries and settings someone turned off.
- Information leaks defeat it. D3FEND's own considerations note that each segment moves by a constant offset, so one leaked pointer reveals the rest of that segment.
- Pair it with other mitigations. ASLR is strongest with non-executable memory and control flow integrity; on its own it raises cost rather than blocking exploitation.
- D3FEND's ATT&CK links are inferred. They come from the shared Process Segment artefact and point mostly at exploitation and process injection techniques.
D3-SAOR at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-SAOR (d3f:SegmentAddressOffsetRandomization) |
| Synonyms | Address Space Layout Randomization, ASLR |
| Tactic | Harden |
| Parent technique | Application Hardening |
| Digital artefact | Process Segment (D3FEND relation: obfuscates) |
| D3FEND references | Microsoft /DYNAMICBASE documentation; a Network World article on ASLR in Linux |
| Where it lives | Operating system loader and kernel, plus compiler and linker flags in each binary |
| Effort | Low to check and enforce on new builds; medium for legacy and third-party software |
| Main limitation | Bypassed by memory disclosure bugs, low entropy on 32-bit processes and non-randomised modules |
How it works
When a process starts, the loader places the executable image, shared libraries, stack, heap and memory-mapped regions at addresses that change from run to run, or for system libraries from boot to boot. An exploit that hard-codes an address for a gadget, a function or injected data then points at the wrong place and usually crashes the process instead of running.
D3FEND's article explains the mechanism for modules: an image that supports rebasing carries relocation information, typically in a ".reloc" section, and the loader adds the chosen offset to every address listed there. Not all code is built to take part, and modules must indicate that they support rebasing. That is the operational heart of the control: the operating system can only randomise what the binary allows it to.
Platforms are listed alphabetically below as examples. This page covers Linux and Windows only; other operating systems, including macOS, implement the same idea, so confirm their settings in the vendor documentation.
| Platform | Binary-side setting | System-side setting |
|---|---|---|
| Linux (GCC toolchain) | Compile with -fpie or -fPIE and link with -pie for a position-independent executable; GCC documents -no-pie to disable and -static-pie for static builds | kernel.randomize_va_space: 0 off, 1 randomises mmap base, stack and VDSO (and code start for PIE binaries), 2 also randomises the heap; the kernel documentation describes 2 as the default when CONFIG_COMPAT_BRK is disabled |
| Windows (Microsoft C++ toolchain) | /DYNAMICBASE, on by default, marks the image as relocatable; /HIGHENTROPYVA, on by default for 64-bit images, enables 64-bit randomised addresses and needs /DYNAMICBASE and /LARGEADDRESSAWARE on the executable and every dependent module | Exploit protection settings Force randomization for images (Mandatory ASLR) and Randomize memory allocations (Bottom-up ASLR), set system-wide or per application |
Two details from Microsoft's exploit protection reference matter in practice. Mandatory ASLR rebases modules that did not opt in, but that rebase "has no entropy", so Microsoft says to pair it with Bottom-up ASLR, which adds the randomness. High entropy adds 24 bits of entropy for 64-bit applications. Neither setting has an audit mode, so test before enforcing widely.
ATT&CK techniques D3FEND relates to D3-SAOR
Relationship type: inferred only. D3FEND derives these relations because D3-SAOR obfuscates Process Segment and the techniques act on process memory; it labels them inferred and experimental (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20. Grouped by what ASLR does to them.
| Group | ATT&CK techniques | Effect of ASLR |
|---|---|---|
| Exploitation of memory corruption | T1190 Exploit Public-Facing Application; T1189 Drive-by Compromise; T1203 Exploitation for Client Execution; T1210 Exploitation of Remote Services; T1068 Exploitation for Privilege Escalation; T1212 Exploitation for Credential Access; T1211 Exploitation for Stealth | Strongest effect: hard-coded addresses fail, so the attacker needs an extra information leak or a non-randomised module |
| Code injection into processes | T1055 Process Injection; T1055.012 Process Hollowing; T1218.013 Mavinject; T1620 Reflective Code Loading | Partial: injectors resolve addresses at run time through system APIs, so ASLR adds little; behaviour monitoring matters more |
| Hooking and capture | T1056 Input Capture; T1056.004 Credential API Hooking | Partial: hooks are placed after addresses are resolved in the running process |
| Process data and discovery | T1564.010 Process Argument Spoofing; T1033 System Owner/User Discovery | Minimal: listed through the shared artefact, not because randomisation blocks them |
The defensive pages for the main exploitation techniques are T1190 Exploit Public-Facing Application Defensive Guide, MITRE ATT&CK T1203 Exploitation for Client Execution and MITRE ATT&CK T1620 Reflective Code Loading.
Implementation steps
- Confirm the system setting. On Linux, read kernel.randomize_va_space on every host image and check that no boot line carries norandmaps. On Windows, review the system-level exploit protection settings for Mandatory and Bottom-up ASLR.
- Inventory binaries that opt out. Scan executables and libraries: on Linux an ELF header type of EXEC rather than DYN means a non-PIE executable; on Windows check the DLL characteristics for the dynamic base flag and, for 64-bit images, high entropy.
- Fix your own builds first. Make PIE and /DYNAMICBASE plus /HIGHENTROPYVA part of the build baseline and fail the pipeline on a binary without them. Remove any /DYNAMICBASE:NO or -no-pie flags that crept in.
- Handle third-party binaries. Ask suppliers for rebuilt versions; where none exists on Windows, test Mandatory plus Bottom-up ASLR for that application in a pilot ring, since there is no audit mode.
- Roll out in rings. Enforce per application on a pilot group, watch for crashes and pointer truncation in 32-bit code, then widen. Rollback is removing the per-application setting.
- Move 32-bit workloads to 64-bit. The entropy available to a 32-bit process is small; D3FEND notes heap spraying can exceed ASLR coverage on 32-bit systems within seconds.
- Layer the other mitigations. Combine with non-executable memory, control flow integrity and a memory-safe language strategy for new code.
How to verify it works
- Binary checks in the pipeline: a build step reads each artefact's header flags and blocks release on any binary without PIE or dynamic base.
- Run-to-run comparison: on a test host, start the same process twice and compare the load address of the main image and the stack; they should differ.
- Configuration compliance: include randomize_va_space and Windows exploit protection settings in configuration scanning, alongside the policy that sets them.
- Crash telemetry: a spike in access violations after enabling Mandatory ASLR for an application points to a binary that cannot be rebased.
| Metric (examples, set your own targets) | What it shows |
|---|---|
| Percentage of in-house binaries built as PIE or with dynamic base and high entropy | Build baseline coverage |
| Count of third-party binaries loading at a fixed base on production hosts | Residual exposure |
| Hosts with randomize_va_space below 2 or system ASLR settings turned off | Configuration drift |
| 32-bit processes still running on internet-facing hosts | Low-entropy exposure |
Limits, bypasses and failure patterns
- Information disclosure: a bug that leaks one pointer reveals the base of its segment, because the whole segment moves by one offset. Memory disclosure bugs are often chained with corruption bugs for this reason. See the Memory Corruption Vulnerabilities Guide.
- One fixed module: a single library that does not support rebasing gives the attacker known addresses to build on, which is why the inventory step matters.
- Low entropy: 32-bit processes allow few possible positions, so brute force or heap spraying becomes practical.
- Per-boot randomisation: some system libraries are randomised once per boot, so a leak in one process can apply to others on the same host until reboot.
- Disabled for debugging: ASLR switched off on a build server or in a container profile for troubleshooting and never switched back.
- Treating it as complete: ASLR raises exploit cost; it does not remove the vulnerability, so patching still decides the outcome.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-16 Memory Protection | Controls that protect system memory from unauthorised code execution |
| NIST SP 800-53 Rev 5 | CM-6 Configuration Settings | Enforcing system ASLR settings as part of the baseline |
| NIST CSF 2.0 | PR.PS-01 | Configuration management practices are established and applied |
| MITRE ATT&CK | M1050 Exploit Protection | The ATT&CK mitigation that includes ASLR settings |
| MITRE D3FEND | D3-SAOR | Technique under Application Hardening |
Related countermeasures
- Process Segment Execution Prevention (D3-PSEP): non-executable memory, the usual partner of ASLR. See D3-PSEP Process Segment Execution Prevention.
- Control Flow Integrity (D3-CFI): limits where control can jump even when addresses are known. See D3-CFI Control Flow Integrity.
- Exploit Protection (M1050): the ATT&CK mitigation view. See M1050 Exploit Protection.
- Application Hardening: the D3FEND parent, which also covers memory-safe languages and stack protection. See the Memory-Safe Languages Guide.
Practitioner checklist
- Check kernel.randomize_va_space and boot parameters on every Linux image.
- Review system-level Mandatory and Bottom-up ASLR settings on Windows.
- Build all in-house code as PIE, or with /DYNAMICBASE and /HIGHENTROPYVA.
- Fail the build on any binary that loads at a fixed address.
- Inventory third-party binaries without relocation support and ask suppliers for fixes.
- Pilot per-application Mandatory plus Bottom-up ASLR before wide enforcement.
- Retire 32-bit processes on exposed hosts where possible.
- Pair ASLR with non-executable memory, control flow integrity and prompt patching.
Standards and references
- MITRE D3FEND: Segment Address Offset Randomization (D3-SAOR)
- Microsoft Learn: /DYNAMICBASE (Use address space layout randomization)
- Microsoft Learn: /HIGHENTROPYVA (Support 64-bit ASLR)
- Microsoft Learn: Exploit protection reference
- Linux kernel documentation: /proc/sys/kernel/ (randomize_va_space)
- GCC: Options for Linking (-pie, -no-pie, -static-pie)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-16 Memory Protection)
- MITRE ATT&CK: Exploit Protection (M1050)
Related NHI Mgmt Group resources: Exploit Mitigations Guide · Memory Corruption Vulnerabilities Guide · M1050 Exploit Protection · T1068 Exploitation for Privilege Escalation · MITRE D3FEND Guide