A DMA attack abuses Direct Memory Access, the feature that lets some peripherals read and write system RAM directly, without asking the CPU for each byte, because that is faster. A malicious device plugged into a Thunderbolt or PCIe port can ride that same channel to read and write memory behind the operating system’s back. It can scrape secrets straight out of RAM, or patch the code that checks the lock screen, while the machine sits locked on a desk. The login prompt never mattered here, because the attack never went near the keyboard.
What is Direct Memory Access and why does it exist?
Moving data through the CPU is slow. If a disk controller, a network card, or a graphics card had to interrupt the processor for every chunk of data it copied, the processor would spend most of its time shuffling bytes instead of running programs. Direct Memory Access solves that. The device is handed the ability to talk to main memory on its own, so it reads and writes RAM while the CPU gets on with other work. When the transfer finishes, the device raises one interrupt to say it is done.
This is a deliberate design and a good one. A high speed capture card writing video frames, or a network card receiving packets, needs to place data in memory fast. The point to remember is what the feature grants: a device that can do DMA is trusted to reach into system memory directly. On a machine that hands out that trust freely, the port becomes a door into RAM.
How a DMA attack turns a plugged in device into a memory reader
Thunderbolt is the part that surprises people. A Thunderbolt port is not only a data port. It carries PCI Express, the internal bus that expansion cards sit on, out to a socket on the side of the laptop. A device on that bus is treated much like a card installed inside the case, which means it can be granted the same DMA rights an internal card has.
So the attacker does not need to break a password. They build or buy a small device that presents itself as a normal peripheral, plug it into the exposed port, and ask the bus for memory. If nothing restricts the request, the device reads whatever addresses it likes.
With direct reach into RAM, two moves open up:
- Read secrets out of memory. Disk encryption keys, session tokens, cached passwords, and private data all live in RAM while the machine is on. A device that can read arbitrary memory can copy them out, even though the screen is locked.
- Write memory to change behavior. The routine that decides whether your password is correct is just bytes in RAM. Overwrite the check so it always returns success, and the lock screen accepts anything you type.
The lock screen is a question the operating system asks itself in memory. A device that can rewrite that memory gets to answer the question for it.
A locked laptop on an open desk
Picture an invented machine, the Acme laptop, left locked on a desk while its owner steps away for coffee. The screen shows a password prompt. Everything looks safe. But a Thunderbolt port on the side is open and active.
An attacker walks up, plugs a prepared device into that port, and the device requests a sweep of system memory. Because the machine grants DMA to the device without restriction, the request succeeds. In one path the attacker copies the region holding the disk encryption key and walks away with it. In another the attacker locates the password check and patches it in place, then types any password and is let in. The owner returns to a laptop that looks exactly as they left it. Nothing was typed at the prompt, and no keyboard log would show a thing, because the keyboard was never used.
This is close in spirit to the evil maid attack, where brief physical access to an unattended machine is enough to tamper with it. It also overlaps with the cold boot attack, another route to reading secrets out of memory, though that one chills and reboots the RAM rather than riding a live bus.
Why the login prompt was never the barrier
It helps to compare this with a threat that looks similar and is not. In juice jacking, a hostile charging port pushes power and data over USB and tries to trick the operating system into mounting the device or accepting a payload. That attack still goes through the software stack. It knocks on the front door.
A DMA attack skips the door. It does not send input the operating system will read and validate. It reaches under the operating system and touches memory directly, so the checks that guard the login path are never consulted. That is why a strong password does not help here on its own. The password matters only if something forces the attacker’s device to go through the code that checks it, and raw DMA does not.
How do you defend against it?
The fix is to stop trusting a plugged in device with unrestricted memory, and to time that distrust for the moment the machine is most exposed.
- Turn on the IOMMU. The IOMMU, called Intel
VT-don Intel platforms and given an equivalent name by AMD, sits between devices and memory and translates the addresses a device may use. With it configured, a device sees only the small window it was assigned, not all of RAM. It is the single most important control here, so confirm it is enabled in firmware and used by the operating system. - Enable Kernel DMA Protection. On modern systems this feature blocks DMA from Thunderbolt and similar ports until a user has logged in, and keeps blocking newly attached devices while the screen is locked. That closes the exact window in the Acme example, the locked and unattended desk.
- Set Thunderbolt security levels and require approval. Thunderbolt can be told to require a human to approve each new device before it is granted access, rather than trusting anything inserted. Set the security level so an unknown device gets nothing until someone says yes.
- Deny DMA before login and while locked. The dangerous moments are the ones with no user present: before boot finishes and whenever the machine is locked. Configure the system so external DMA is refused in both states, and only allowed once an authenticated user is active.
- Disable ports you do not use. If a laptop never needs Thunderbolt or an external PCIe path, turn it off in firmware. A port that grants no access is not a door at all.
The theme across all of these is the same. Speed features are safe until they are handed to an untrusted device at an unguarded moment, and the defense is to narrow both what a device can reach and when it is trusted at all.
This class of problem is about an assumption the machine makes, that a device on the bus is allowed in memory, rather than about a malformed input. That is the kind of hidden assumption an autonomous researcher built to test assumptions, rather than to match known payloads, is meant to probe. You can read more about how we think about that on our about page.
Frequently asked questions
What is a DMA attack?
It is an attack that abuses Direct Memory Access, the feature that lets some peripherals read and write system RAM directly without going through the CPU. A malicious device plugged into a Thunderbolt or PCIe port uses that channel to read secrets out of memory or to patch the lock screen check, all while the machine sits locked.
Can a DMA attack work while my laptop is locked?
Yes. That is the point of it. The attack reaches memory directly and never sends input through the login path, so the lock screen is not consulted. A device with unrestricted DMA can copy encryption keys out of RAM or overwrite the password check even though the screen shows a locked prompt.
Why is Thunderbolt a risk when USB feels safe?
A Thunderbolt port carries PCI Express out to the side of the machine, so a device on it is treated much like an expansion card inside the case and can be granted the same direct memory rights. Threats like juice jacking still go through the software stack over USB, while a DMA attack goes under the operating system entirely.
How do I defend against a DMA attack?
Enable the IOMMU so a device sees only the memory window it was assigned, turn on Kernel DMA Protection so external ports are blocked before login and while locked, set Thunderbolt to require approval for each new device, and disable ports you never use. The goal is to narrow both what a device can reach and when it is trusted at all.
Put an autonomous researcher on your own systems
UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.