D3-HBPI Hardware-based Process Isolation: How It Contains Attacks and How to Verify It

If one process can read or write another process's memory, an attacker who lands in any process can steal credentials from the most sensitive one. MITRE D3FEND names the countermeasure Hardware-based Process Isolation (D3-HBPI) and defines it as "Preventing one process from writing to the memory space of another process through hardware based address manager implementations." It sits under the Isolate tactic as a child of Execution Isolation, with the relations isolates Process and restricts Create Process. This card explains the hardware mechanisms behind it (MMU, IOMMU and virtualisation extensions), the operating system features that use them, how to prove they are running and where they stop. It is written for endpoint, platform and detection engineers who need to switch these features on and evidence them.

Key takeaways

• Three hardware building blocks. D3FEND names the MMU (per-process virtual address spaces), the IOMMU (per-device address spaces for DMA) and DMA itself as the mechanisms behind this technique.
• Virtualisation is the modern form. D3FEND lists "Virtualization" as a synonym and names Intel VT-d and Firecracker as implementations; Windows virtualisation-based security (VBS) is the most widely deployed example on endpoints.
• The ATT&CK links are inferred. D3FEND relates D3-HBPI to more than 30 ATT&CK techniques through the Process artefact, from LSASS Memory (T1003.001) to discovery techniques; treat the list as a starting point, not a guarantee of coverage.
• State is provable. Win32_DeviceGuard, msinfo32 and Linux kernel IOMMU messages show whether isolation is actually running, not just configured.
• Isolation has edges. Credential Guard does not protect the SAM or the Active Directory database, Kernel DMA Protection does not cover boot time, and a compromised host can still reach its guests.

D3-HBPI at a glance

How it works

D3FEND describes process isolation here as address space separation: "Process A address space is different from process B address space, which prevents process A from writing to process B." The hardware enforces that separation in three places.

• Memory Management Unit (MMU): translates each process's virtual addresses to physical memory and acts as an access control, so a process cannot address pages it was not given.
• Input-Output Memory Management Unit (IOMMU): gives each I/O device its own virtual address space. On Intel this is VT-d, described by the DMAR ACPI table; on AMD it is AMD-Vi, described by the IVRS table. Without it, a device performing DMA can read or write any physical page.
• Hardware virtualisation: the processor's virtualisation extensions let a hypervisor run code in a separate trust level that the normal kernel cannot inspect. This is how Windows VBS isolates secrets and kernel code integrity, and how microVM managers such as Firecracker contain guest workloads.

D3FEND's own consideration is direct: "Private hosts may be vulnerable to DMA attack if they have a PCI or PCI Express port that connects attached devices directly to physical address space." That is why the IOMMU matters as much as the MMU.

The two common deployment patterns

• Protect a secret from the host operating system: Windows Credential Guard uses VBS so that, in Microsoft's words, "Malware running in the operating system with administrative privileges can't extract secrets that are protected by VBS." Credential material moves into the isolated LSAIso.exe process. Memory integrity (hypervisor-protected code integrity, HVCI) uses the same boundary to run kernel-mode code integrity checks outside the reach of the normal kernel.
• Protect the host from a workload: Firecracker's design treats "all vCPU threads" as "running malicious code as soon as they have been started" and contains them with the KVM virtualisation boundary, then adds seccomp filters, cgroups, namespaces and a jailer process that drops privileges. This is the pattern for multi-tenant compute and for running untrusted code, including AI agent tool execution.

ATT&CK techniques D3FEND relates to D3-HBPI

D3FEND labels these relationships as inferred and experimental: they come from shared digital artefacts (Process, Create Process), not from testing that isolation blocks each technique. They are grouped by ATT&CK tactic. Where D3FEND still lists a revoked ATT&CK ID, its ATT&CK v20 successor is shown.

For the attacker side of the strongest mappings, see the T1003 OS Credential Dumping and the T1055 Process Injection Defensive Guide.

Where it is implemented

The live guides go deeper on the Windows features: see Credential Guard and VBS and the Thunderbolt, DMA and Peripheral Attack Protection Guide. The ATT&CK mitigation views are in M1043 Credential Access Protection and M1048 Application Isolation and Sandboxing.

Implementation steps

1. Inventory hardware capability: collect AvailableSecurityProperties from Win32_DeviceGuard across Windows estates, and check for DMAR or IVRS tables on Linux hosts. Older processors without MBEC or GMET run memory integrity through slower emulation, so note them.
2. Turn on firmware features: enable virtualisation (VT-x or AMD-V), the IOMMU (VT-d or AMD-Vi) and Secure Boot through the hardware vendor's management tooling, then lock firmware settings with an administrator password.
3. Pilot ring: enable Kernel DMA Protection, memory integrity and Credential Guard on a pilot group that includes devices with specialist drivers, docking stations and any Hyper-V VMs. Microsoft warns that incompatible drivers can cause malfunctions or, rarely, a boot failure.
4. Check driver compatibility: in Device Manager, the DMA Remapping Policy property should read 2; 0, 1 or a missing value means the driver does not support DMA remapping and its devices will be blocked until a user signs in (the default enumeration policy).
5. Broad rollout: deploy by policy (Intune, Group Policy or the registry key under HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity). Windows 11 22H2 and later enable Credential Guard by default on qualifying, licensed devices without UEFI lock.
6. Decide on UEFI lock: UEFI lock stops an attacker switching protection off through the registry, but recovery then requires access to firmware. Use it on high-value devices once the pilot is stable.
7. Isolate untrusted workloads: on servers that run third-party or generated code, use microVM or hypervisor-isolated sandboxes, and run the virtual machine monitor itself with least privilege (Firecracker's jailer, seccomp and cgroups).
8. Rollback: keep the documented Windows RE recovery path ready (set the HypervisorEnforcedCodeIntegrity Enabled value to 0 after removing the policy) and know which devices have UEFI lock, because those also need Secure Boot changes to recover.

How to verify it works

• Windows state, not intent: query Win32_DeviceGuard in the root\Microsoft\Windows\DeviceGuard namespace. VirtualizationBasedSecurityStatus 2 means enabled and running; SecurityServicesRunning containing 1 means Credential Guard is running and 2 means memory integrity is running.
• DMA protection: msinfo32 shows Kernel DMA Protection as On. If it is Off and "Hyper-V - Virtualization Enabled in Firmware" is No, firmware virtualisation is switched off.
• Linux IOMMU: kernel messages such as "PCI-DMA: Using DMAR IOMMU" (Intel) or "iommu: Default domain type: Translated" (AMD) confirm translation is active. DMAR or AMD-Vi fault lines show blocked device accesses, which are worth forwarding to the SIEM.
• Behavioural test: in a lab, run an authorised credential-access test against LSASS on a protected and an unprotected device. On the protected device, NTLM hashes and TGTs held by Credential Guard should not be recoverable from LSASS memory.
• Drift: alert when a device that previously reported SecurityServicesRunning with 1 or 2 stops doing so, which can indicate a firmware change, a policy conflict or tampering.

Metrics (examples, not standards)

Limits, bypasses and failure patterns

• Assuming Credential Guard covers every credential: Microsoft states it "doesn't provide protections for the Active Directory database or the Security Accounts Manager (SAM)" and adds no security to domain controllers. Local administrator passwords and service account secrets need separate controls.
• Configured but not running: VBS can show as enabled but not running, for example on platforms that lack a prerequisite. Reporting the policy instead of the running state hides the gap.
• Trusting the host: Credential Guard "doesn't provide protection from privileged system attacks originating from the host", and the same applies to any guest whose hypervisor host is compromised. Host administrators are part of the trust boundary.
• Boot-time and legacy ports: Kernel DMA Protection does not protect during boot (a firmware responsibility) and does not cover 1394, PCMCIA, CardBus or ExpressCard.
• Isolating the wrong thing: isolation protects memory, not the decisions of the code inside the boundary. A sandboxed workload with broad network egress or long-lived cloud credentials can still cause damage; Firecracker's design notes it does not filter network traffic itself.
• Disabling for compatibility and never returning: a driver problem during the pilot often leads to a permanent exclusion. Track exclusions with an owner and an expiry date.

Where identity fits

The highest-value data inside isolated processes is identity material: Kerberos tickets, NTLM hashes, and the tokens and keys that service accounts and workloads use. Hardware isolation narrows how those secrets can be stolen from memory, but it does not shorten their life or limit their scope. Pair it with short-lived credentials and secrets that never sit in ordinary process memory for longer than needed. For workloads that run untrusted code, give the sandbox its own narrowly scoped identity rather than the host's. See the AI Agent Sandboxing and Code Execution Guide.

Framework mapping

This mapping is NHI Mgmt Group's view, except the ATT&CK mitigations, which come from D3FEND.

Related countermeasures

• Kernel-based Process Isolation (D3-KBPI) and Application-based Process Isolation (D3-ABPI): sibling techniques under Execution Isolation that use operating system and application boundaries instead of hardware. See D3-KBPI Kernel-based Process Isolation and D3-ABPI Application-based Process Isolation.
• System Call Filtering (D3-SCF): limits what an isolated process can ask the kernel for, as Firecracker's seccomp filters do. See D3-SCF System Call Filtering.
• System Call Analysis (D3-SCA): detects behaviour that isolation does not block. See D3-SCA System Call Analysis.

Practitioner checklist

• Enable virtualisation, IOMMU and Secure Boot in firmware and lock firmware settings.
• Report Win32_DeviceGuard running state for every Windows device, not policy state.
• Run Credential Guard on all capable non-domain-controller devices.
• Turn on memory integrity after a driver compatibility pilot.
• Confirm Kernel DMA Protection is On for laptops with Thunderbolt or USB4 ports.
• Protect the SAM, AD database and local admin accounts with separate controls.
• Run untrusted and generated code in microVM or hypervisor-isolated sandboxes with minimal egress.
• Keep a tested recovery path and track every exclusion with an owner and expiry.

Standards and references

• MITRE D3FEND: Hardware-based Process Isolation (D3-HBPI)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-39, SC-49)
• Microsoft Learn: Credential Guard overview
• Microsoft Learn: Enable memory integrity
• Microsoft Learn: Kernel DMA Protection
• Linux kernel documentation: x86 IOMMU Support
• Firecracker: Design

Related NHI Mgmt Group resources: Credential Guard and VBS · Thunderbolt, DMA and Peripheral Attack Protection Guide · M1048 Application Isolation and Sandboxing · T1003 OS Credential Dumping