Researchers from KU Leuven and the University of Birmingham have disclosed Battering RAM, a hardware attack that defeats key confidential computing protections in Intel SGX enclaves and AMD SEV‑SNP virtual machines. While exploitation requires physical access to the server, the work exposes design limits of today’s memory‑encryption schemes and elevates concerns about insider threats and supply‑chain tampering in cloud environments.
What Battering RAM Targets in Confidential Computing
Building on their earlier BadRAM findings against SEV‑SNP, the team demonstrates that trusted execution features—intended to keep data opaque even from privileged administrators—can be subverted below the operating system and hypervisor. SGX isolates code and data inside CPU‑managed enclaves; SEV‑SNP encrypts and attests guest VM memory. Battering RAM shows that when the memory bus is manipulated, these assurances can be weakened or bypassed.
How the DRAM Interposer Attack Works
The core technique uses a stealth interposer on the DRAM channel, placed inline at the DIMM connector. According to the researchers, such a device can be assembled on a modest budget and operates transparently, evading detection by the OS and hypervisor. Once active, the interposer reroutes memory transactions, redirecting accesses that should hit protected regions to attacker‑controlled locations.
By manipulating address lines and timing on the memory bus, the attacker can undermine the assumptions of memory‑encryption engines and integrity protections during early boot. The authors report that this enables arbitrary plaintext access to SGX enclave data and can invalidate SEV‑SNP attestation even on fully patched systems. The prototype targets DDR4, and the approach is described as architecturally extensible to DDR5.
Who Is at Risk and Why Software Patches Fall Short
The attack presumes physical access—traditionally out of scope for many CPU threat models. In real‑world cloud and colocation settings, however, plausible adversaries include rogue data‑center staff, third‑party service technicians, law‑enforcement personnel during seizures, or actors compromising the memory supply chain. Because the manipulation occurs below the firmware and OS, software updates and microcode patches cannot fully address the issue.
Vendor Responses and Available Mitigations
Intel and AMD were notified in February 2025 and published advisories alongside the research release. Both vendors emphasize that physical attacks lie outside their standard security models. Intel additionally highlights Total Memory Encryption – Multi‑Key (TME‑MK) on select Xeon platforms as a risk‑reduction measure and recommends reinforced physical protections for sensitive infrastructure.
These findings align with prior academic work indicating that when an attacker can tamper with the memory interface, platform‑level encryption may not prevent redirection or substitution attacks. The lesson is clear: confidential computing must be paired with robust physical security and supply‑chain assurance.
Practical Guidance for Cloud and Data‑Center Operators
Strengthen physical security controls where confidential computing workloads run: strict access segmentation, least‑privilege procedures, video monitoring, logging, and independent audits. On the hardware layer, deploy locking racks, chassis intrusion sensors, tamper‑evident seals on DIMMs, and enforce a verifiable chain of custody for memory modules.
Architectural measures include enabling platform memory encryption where supported (for example, TME‑MK), minimizing hot‑swap operations, and formalizing SLAs with cloud providers that explicitly define the physical threat model and responsibility boundaries. Where feasible and compatible with workload performance, consider in‑line DIMM security solutions that add bus‑level protections.
Battering RAM is a timely reminder that cryptographic isolation alone does not guarantee confidentiality when attackers can touch the hardware. Organizations should revisit threat models to account for insider and supply‑chain risk, update data‑center access procedures, evaluate features such as TME‑MK, and track vendor guidance as it evolves. Taking these steps preserves the benefits of confidential computing while acknowledging and mitigating risks that operate below the software stack.
