Direct Memory Access Attacks and Mitigations

DMA Attacks, And How to Prevent Them

Someone gaining unauthorised access to a personal computer by injecting code into its memory may sound a little far-fetched. However, the reality is that this method of PC intrusion – known as a Direct Memory Access (DMA) attack – can be easily achieved by using open-source hardware and software, readily available to members of the public.

What are DMA attacks?

Before diving into how we can prevent a DMA attack, it’s important to first understand just how simple this process can be for someone with the right tools and know-how.

‘Direct Memory Access’ is a mechanism that allows a computer peripheral – such as an external device or internal add-in card – to access system memory without requiring the CPU’s involvement for every data transfer. This is used to optimise data transfers and free up the CPU to perform other necessary tasks.

DMA attacks are an attack vector that is based on this mechanism, where a threat actor uses a specialised device that has direct access to a computer’s memory, bypassing security controls to extract data or inject malicious code. The ‘PCIe Screamer Squirrel’ created by ‘LambdaConcept’ – used within the game hacking community to bypass cheat detection software – is one example of a hardware device capable of performing these attacks.

Figure 1: The ‘PCIe Scream Squirrel’ DMA Tool

An employee losing a company laptop, which then falls into the hands of a threat actor is the ideal scenario for a potential DMA attack. In this situation, an organisation would be immediately at risk with the threat actor able to connect a DMA device to an available internal port on the laptop, and then run system commands directly in memory resulting in the total compromise of the victim’s laptop.

The below terminal output is a good illustration of how a DMA attack can be achieved.

> pcileech.exe kmdload -kmd WIN10_X64_3

KMD: Code inserted into the kernel - Waiting to receive execution.
KMD: Execution received - continuing ...
KMD: Successfully loaded at address: 0x7ffff000

> pcileech.exe wx64_pscmd -kmd 0x7ffff000

EXEC: SUCCESS! shellcode should now execute in kernel!
Please see below for results.

PROCESS CREATOR - AUTOMATICALLY SPAWN CMD.EXE ON TARGET!
================================================================
Automatically spawn a CMD.EXE on the target system. This utility
only work if the target system is locked and the login screen is
visible. If it takes time waiting - then please touch any key on
the target system.   If the utility fails multiple times, please
try wx64_pscreate instead.
===== DETAILED INFORMATION AFTER PROCESS CREATION ATTEMPT ======
NTSTATUS        : 0x00000000
ADDITIONAL INFO : 0x0000
================================================================
Microsoft Windows [Version 10.0.19045.5011]
(c) Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32> whoami
whoami
nt authority\system

I was able to spawn a full administrator-level shell on a client-provided laptop by injecting a custom kernel module using the ‘PCIe Screamer Squirrel’, which was connected to the target-laptop motherboard’s M.2 PCIe slot. This shows just how straightforward it would be for a threat actor to gain full unauthorised system access once they have physical access to a target computer.

Enabling IOMMU and its Pitfall

One of the main recommendations to prevent DMA attacks is to enable the Input–Output Memory Management Unit (IOMMU) within the computer’s BIOS or UEFI settings.

“enabling this setting alone does not entirely prevent DMA attacks from occurring”

This module provides a hardware-based mechanism to restrict direct memory access by devices, ensuring they can only interact with memory regions explicitly assigned to them, thus enhancing system security. Depending on the CPU brand, this feature may be known as Intel’s ‘Virtualization Technology for Directed I/O’ (VT-d) or AMD’s ‘I/O Virtualization Technology’ (AMD-Vi).

However, enabling this setting alone does not entirely prevent DMA attacks from occurring. Several key settings need to be enabled for the IOMMU to properly provide protection for a computer running Windows, which is discussed in further detail in the following section.

What Else Can Be Done?

Physical Security

A good first step to mitigate DMA attacks is to disable any ports or interfaces you’re not actively using in your system’s UEFI. To be effective, this also requires restricting the UEFI with a password so an attacker cannot easily re-enable these ports.

It’s worth noting that this is not a complete mitigation on most devices, as some DMA ports are often required for normal operation (M.2 hard drives, WiFi cards, and more…).

Kernel DMA Protection

One feature in Windows that helps prevent DMA attacks is ‘Kernel DMA Protection’, shown here as set to ‘Off’ within the ‘System Information’ panel.

Figure 2: Kernel DMA Protection

Despite enabling many of the common DMA protection recommendations, this setting may not be correctly set due to other factors such as older hardware limitations or other BIOS settings that remain unadjusted. In order to have ‘Kernel DMA Protection’ set to ‘On’, the following requirements must be met:

Use a UEFI BIOS

Note that this may be a physical limitation that older devices do not support. However, most modern devices should support a UEFI BIOS.

Enable Secure Boot
The exact steps for this vary between device vendors, but typically the steps are similar to:

  1. Boot into the device UEFI/BIOS settings
  2. Navigate to the “Boot” or “Security” section
  3. Enable “Secure Boot” option
  4. Save changes and exit
Figure 3: The Secure Boot setting within a UEFI BIOS

Enable Virtualisation/IOMMU (VT-d or AMD-Vi).
The exact steps for this vary between device vendors, but typically the steps are similar to:

  1. Boot into the device UEFI/BIOS settings
  2. Navigate to “Advanced” > “CPU Configuration” or similar
  3. Enable “Intel Virtualization Technology for Directed I/O” (VT-d) or “AMD-Vi”
  4. Save changes and exit
Figure 4: The Virtualisation settings within a UEFI BIOS

 

Enable Additional Virtualisation-Based Security 
These following steps can be applied as a ‘Group Policy’ in Windows:

  1. Open Group Policy Editor
  2. Navigate to “Computer Configuration” > “Administrative Templates” > “System” > “Device Guard”
  3. Find and enable “Turn On Virtualization Based Security”
  4. Set “Select Platform Security Level” to “Secure Boot and DMA Protection”
  5. Click “Apply” and “OK”
  6. Restart
Figure 5: Kernel DMA, Virtualization, and VT-d Settings on Lenovo

With ‘Kernel DMA Protection’ enabled, DMA attempts will result in the operating system freezing or crashing before compromise can occur. This is illustrated by the following photo where a DMA attack failed on a laptop with ‘Kernel DMA Protection’ set to ‘On’. (Note the ‘DRIVER_VERIFIER_DMA_VIOLATION’ BSOD stop code shown in the picture.)

Figure 6: Blue Screen of Death

For more information on ‘Kernal DMA Protection’, see the following resource:

Conclusion and Summary

DMA attacks might seem like an unreasonable attack path for an organisation to worry about. However, cyber security experience has proven that by having the correct BIOS and operating system settings on every workstation, a motivated threat actor can be effectively restricted from performing a DMA attack, which can help prevent a motivated threat actor from compromising sensitive company or personal data.

The following features should be configured in combination to help prevent DMA attacks and secure system booting:

  1. Enable Kernel DMA Protection
  2. Enable UEFI boot.
  3. Enable Secure Boot.
  4. Enable Virtualisation/IOMMU (VT-d or AMD-Vi).

Support From Division 5

At Division 5, we specialise in simulating real-world physical security threats through our in-depth hardware security assessment services. These include:

  • Lost/Stolen Device Scenarios: We simulate what happens when devices fall into the wrong hands, testing full disk encryption, hardware security modules, and anti-tampering measures.
  • DMA Attack Simulation: We perform controlled DMA attacks against your systems to identify memory access vulnerabilities and confirm if security configurations are effective.
  • Cold Boot Attacks: Our team can demonstrate how remnant data in RAM can be extracted even after power loss, and help you understand the attack feasibility and potential mitigations.

Our security team brings years of experience in device security testing to every engagement. We don’t just identify vulnerabilities—we provide practical, implementable recommendations tailored to your specific environment and security requirements.

Chat to us to discuss our approach to simulating lost/stolen device attacks and ensure your organisation is protected against even the most sophisticated physical attacks.

Leave us a message