← All posts

Kernel DMA Protection: Stopping Evil-Maid and Drive-By DMA Attacks

Thunderbolt and PCIe peripherals can read your RAM directly, bypassing the lock screen. Here is how Kernel DMA Protection stops drive-by DMA attacks and how to audit it.

Full-disk encryption feels like the end of the physical-security conversation. If the laptop is stolen, BitLocker keeps the attacker out — right? Mostly. But there is a whole class of attacks that never touch the disk at all. They go straight for the RAM, where your BitLocker keys, session tokens, and decrypted secrets are sitting in the clear while the machine is powered on. And the doorway they use is a feature you probably think of as convenient, not dangerous: the high-speed peripheral port on the side of your laptop.

Direct Memory Access, and why it is a gift to attackers

Direct Memory Access (DMA) is a performance feature. Instead of routing every byte through the CPU, high-throughput devices — GPUs, network cards, Thunderbolt docks, external drives — are allowed to read and write system memory directly. That is what makes a Thunderbolt SSD fast and an eGPU usable. The catch is that a device with unrestricted DMA can read any physical memory page, not just the buffers it was handed.

An attacker who can plug a malicious PCIe or Thunderbolt device into a running-but-locked machine can therefore:

The tooling is off-the-shelf. Projects like PCILeech and the Thunderclap research demonstrated fully weaponized DMA memory scraping over commodity FPGA boards and Thunderbolt hardware. This is not theoretical; it is a documented technique (MITRE ATT&CK T1200, Hardware Additions).

The two threat models: evil-maid and drive-by

People conflate these, but they matter separately.

Evil-maid

The classic scenario: you leave a locked laptop in a hotel room or at a conference. Someone with a few minutes of physical access attaches a DMA device, dumps memory, and walks away with your keys. No password needed, no login attempted — the machine stays locked the whole time.

Drive-by DMA

The subtler one: you plug in what looks like an ordinary dock, charger, or presentation dongle. The moment the peripheral enumerates, it has DMA. A malicious USB-C dock at a shared desk or a "borrowed" charging cable is enough. The victim chose to plug it in, which is exactly why it works — the attack rides in on a device the user trusts.

What Kernel DMA Protection actually does

Kernel DMA Protection (introduced in Windows 10 1803 and standard on modern Secured-core PCs) puts the Input/Output Memory Management Unit (IOMMU) in front of every DMA-capable external device. Instead of handing a peripheral the whole memory map, the IOMMU sandboxes the device into only the memory pages the OS has explicitly mapped for it. A rogue Thunderbolt board can no longer wander through physical RAM — it sees only its own tiny window.

Crucially, this happens without requiring the old, clumsy mitigation of disabling all new DMA devices at the lock screen. With Kernel DMA Protection on, a user can hot-plug a legitimate dock while the machine is locked and the device just works — inside its IOMMU sandbox.

Two things must be true for it to be active:

How to check it on your machine

The fastest built-in check is msinfo32. Run it and look at the System Summary for the Kernel DMA Protection line:

msinfo32
# System Summary → "Kernel DMA Protection"  →  On / Off

If it reads Off, work through the causes in order — they are not all the same fix:

You can also confirm DMA remapping policy on individual devices in PowerShell:

Get-PnpDevice -PresentOnly |
  Get-PnpDeviceProperty -KeyName 'DEVPKEY_PciDevice_DmaRemappingCapable' -ErrorAction SilentlyContinue |
  Where-Object { $_.Data -ne $null }

If your hardware can't do it: the fallback

On platforms without Kernel DMA Protection, you are not defenceless — but the mitigations are blunter:

Kernel DMA Protection and pre-boot PIN are complementary, not redundant. The first stops a device from reading RAM while you're logged in and locked; the second protects the key material around boot. Secured-core PCs ship with both.

Where WinSentinel fits

Physical-layer settings like this are exactly the sort of thing that silently drifts: a firmware update resets a UEFI toggle, a re-image forgets the lock-screen DMA policy, a new laptop model ships with virtualization off. You will not notice until an audit — or an incident.

WinSentinel's Encryption module checks Kernel DMA Protection status as part of its evil-maid / drive-by DMA posture review, alongside BitLocker per-volume state, TPM availability, DPAPI protection, Credential Guard, and TLS/DH key-exchange strength. Every finding is local, runs on a single machine, and is free forever — no fleet or account required:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit

It reports whether Kernel DMA Protection is On, why it is Off when it isn't, and maps the finding to the CIS control so it lands in your compliance rollup. For a fleet of laptops, WinSentinel Pro aggregates that posture across every node so you can prove that none of your travelling machines are exposed to a hotel-room DMA dump — not just spot-check one.

Encryption at rest is only half the story. Encryption of the RAM that holds the keys is the other half, and it lives at the port on the side of the laptop.

Read next: What a full Windows encryption audit covers →