DDRop Hardware Attack on Intel TDX and AMD SEV-SNP: Defending Confidential Computing From DRAM Write-Drop Replay

Executive summary

Researchers have disclosed DDRop, a hardware attack that weakens the core promise of confidential computing on Intel Trust Domain Extensions (TDX) and AMD SEV-SNP. The technique is not a conventional software bug and no CVE identifier is provided in the source material. Instead, DDRop uses a small physical circuit inserted into the memory path to silently drop selected DDR writes. The processor continues to read the previous ciphertext from DRAM as if it were fresh state. In plain terms: the attacker causes time to stand still for chosen memory locations while the rest of the system keeps running.

The reason this matters is operational, not academic. TDX and SEV-SNP are being adopted to protect regulated workloads, multi-tenant AI pipelines, financial models, key custody, and sensitive analytics from a compromised hypervisor or cloud operator. DDRop does not make those deployments useless, but it does prove that ciphertext confidentiality without freshness can be replayed. If your control plane, attestation workflow, secrets handling, or application state assumes that encrypted memory also implies tamper-evident memory under physical access, you need to correct that assumption this quarter.

The mitigating factor is the access model. The reported attack requires an adversary who already controls server software and can get brief physical access to install an interposer-like circuit. That is an insider, evil-maid, compromised maintenance channel, malicious colocation technician, supply-chain implant, or cloud-edge exposure scenario. It is less likely than a remotely exploitable VM escape, but the blast radius in bare-metal confidential computing and edge AI is high because those environments often carry the most sensitive workloads and the weakest physical monitoring.

What is at risk

Affected platforms called out in the reporting are systems using Intel TDX and AMD SEV-SNP for hardware-isolated confidential virtual machines or trust domains. The vulnerable property is not the CPU instruction set by itself; it is the deployment assumption that DRAM encryption alone prevents rollback when an attacker can influence the memory bus. A write that never reaches DRAM leaves stale encrypted data visible to later reads. If the guest, host, or application interprets that stale block as current, the attacker can induce replay of old state: old counters, old session state, old policy decisions, old nonces, old ledger entries, old model metadata, or old authentication results.

Practical impact depends on workload design:

• High risk: systems that keep monotonic counters, anti-replay state, revocation lists, feature flags, payment state, enrollment status, or audit decisions only inside confidential VM memory.
• High risk: confidential AI inference nodes at edge sites where physical inspection is intermittent and a technician can open a chassis without generating an alarm.
• Medium risk: cloud confidential VMs where the provider controls hardware custody, because a malicious or coerced operator with software control plus brief rack access could target a small number of high-value tenants.
• Lower risk: workloads that verify launch attestation continuously, keep rollback state in an external tamper-evident service, rotate secrets aggressively, and treat any attestation or telemetry discontinuity as fatal.

As of the source item, there is no CVE identifier, no CVSS score, no vendor patch version, no CISA KEV entry, and no confirmed widespread in-the-wild exploitation provided. Treat this as a disclosed research capability with credible prerequisites. Do not wait for a KEV entry to fix architecture mistakes: KEV is optimized for remotely exploitable software defects, not physical supply-chain or evil-maid attacks.

Technical analysis

Affected products and platforms

• Intel platforms using TDX for confidential VMs/trust domains.
• AMD EPYC platforms using SEV-SNP for confidential VMs.
• Linux/KVM/QEMU stacks are the common denominator in many deployments, but the exposure is architectural rather than tied to one hypervisor build.
• Bare-metal confidential computing nodes, edge AI servers, telco MEC hosts, HPC enclaves, HSM-adjacent services, and regulated data-clean-room nodes deserve priority review.

Attack chain from a defender's perspective

1. Software control first: The attacker already controls host software, firmware-adjacent tooling, management plane access, or a privileged tenant path sufficient to know where target guest memory is mapped and when sensitive writes occur.
2. Brief physical access: The attacker opens the chassis and installs a small circuit on or near the DDR path. The reporting characterizes this as a compact interposer-style modification rather than a full bus analyzer implant.
3. Selective write suppression: During operation, chosen DRAM writes are dropped. The CPU's later reads return the previous encrypted contents.
4. Replay/rollback condition: The platform continues executing with stale state. Because the data remains encrypted, simple confidentiality checks may still pass while freshness is violated.
5. Impact materializes when state is trusted: Anti-rollback counters, sequence numbers, policy versions, authentication attempts, ledger entries, nonce caches, quote freshness, key-usage state, or model/version gating can be coerced backward if the application does not independently verify freshness.

The key defensive lesson is precise: memory encryption protects confidentiality; it does not automatically guarantee freshness, completeness, or write acknowledgment under active physical manipulation. Confidential computing reduces trust in the hypervisor; it does not eliminate the need for physical custody controls, attestation governance, external state anchoring, and application-level replay resistance.

Exploitation status

• Public PoC/research: disclosed by researchers, per the news summary.
• Confirmed mass exploitation: none provided in the source.
• CISA KEV: no entry identified from the provided material.
• Patch status: no fixed version or CVE-specific remediation is included in the source. Track Intel and AMD security advisories directly and require your OEM or cloud provider to state whether DDR interposer detection, memory-controller telemetry, platform firmware updates, or architectural guidance changes apply to your exact motherboard, BMC, BIOS, microcode, memory population, and confidential computing firmware.

Detection and response

Honest constraint: a production OS will usually not log 'DDRop happened.' The highest-value telemetry is therefore correlation around prerequisites and consequences: chassis opening, BMC/SEL anomalies, unexpected power or reboot events, EDAC/RAS/memory-controller errors, DIMM population or SPD changes, attestation verification failures, quote freshness failures, and discontinuities in external counters. A single one of these can be noise. Several on the same confidential computing host inside a short window should be treated as a potential physical compromise.

Use these controls as hunting hypotheses, not as proof of compromise by themselves.

---
title: Confidential Computing Attestation Failure Burst
tid: 2f7f6a11-9dd8-4f7f-9a3d-ddrop0000001
status: experimental
description: Detects bursts of TDX or SEV-SNP attestation, quote, launch measurement, or freshness verification failures that may indicate rollback, replay, tampering, or a broken trust chain after maintenance or physical access.
references:
  - https://thehackernews.com/2026/09/new-ddrop-attack-breaks-intel-tdx-and.html
author: Security Arsenal
date: 2026/09/10
tags:
  - attack.defense_evasion
  - attack.impact
logsource:
  product: linux
  category: syslog
detection:
  selection_terms:
    Message|contains:
      - 'TDX'
      - 'SEV-SNP'
      - 'SEV SNP'
      - 'SNP guest'
      - 'trust domain'
      - 'confidential guest'
  selection_fail:
    Message|contains:
      - 'attestation failed'
      - 'quote verification failed'
      - 'measurement mismatch'
      - 'freshness failed'
      - 'nonce mismatch'
      - 'launch digest mismatch'
      - 'report data mismatch'
  condition: selection_terms and selection_fail
falsepositives:
  - Broken attestation agent after upgrade
  - Expired certificates or clock skew
level: high
---
title: Physical Chassis or DIMM Tamper Telemetry on Confidential Hosts
tid: 2f7f6a11-9dd8-4f7f-9a3d-ddrop0000002
status: experimental
description: Detects BMC, IPMI, SEL, EDAC, RAS, or kernel telemetry consistent with chassis opening, DIMM change, memory error storm, or physical maintenance immediately before trust failures on confidential computing hosts.
references:
  - https://thehackernews.com/2026/09/new-ddrop-attack-breaks-intel-tdx-and.html
author: Security Arsenal
date: 2026/09/10
tags:
  - attack.initial_access
  - attack.impact
logsource:
  product: linux
  category: syslog
detection:
  selection_physical:
    Message|contains:
      - 'chassis intrusion'
      - 'cover open'
      - 'intrusion switch'
      - 'DIMM removed'
      - 'DIMM population changed'
      - 'SPD mismatch'
      - 'SEL entry'
      - 'power supply inserted'
      - 'unexpected reboot'
  selection_memory:
    Message|contains:
      - 'EDAC'
      - 'machine check'
      - 'uncorrected memory error'
      - 'memory controller'
      - 'rasdaemon'
      - 'row remapping'
  condition: selection_physical or selection_memory
falsepositives:
  - Authorized data center maintenance
  - Known bad DIMM replacement
level: medium

// Hunt: correlate physical tamper, memory/RAS errors, reboots, and confidential-computing attestation failures in Sentinel Syslog/CEF
let window = 4h;
let terms = dynamic(['TDX','SEV-SNP','SEV SNP','SNP guest','confidential guest','trust domain','attestation failed','quote verification failed','measurement mismatch','freshness failed','nonce mismatch','chassis intrusion','cover open','intrusion switch','DIMM','SPD mismatch','EDAC','machine check','uncorrected memory error','rasdaemon','unexpected reboot','SEL entry']);
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has_any (terms)
| extend Signal = case(
    SyslogMessage has_any (dynamic(['attestation failed','quote verification failed','measurement mismatch','freshness failed','nonce mismatch','launch digest mismatch'])), 'attestation-failure',
    SyslogMessage has_any (dynamic(['chassis intrusion','cover open','intrusion switch','DIMM removed','SPD mismatch','power supply inserted'])), 'physical-tamper',
    SyslogMessage has_any (dynamic(['EDAC','machine check','uncorrected memory error','memory controller','rasdaemon'])), 'ras-memory',
    SyslogMessage has_any (dynamic(['unexpected reboot','boot','shutdown'])), 'power-reboot',
    'other')
| summarize Count=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Signals=make_set(Signal), Samples=make_set(SyslogMessage, 5) by Computer, HostName, Facility, SeverityLevel
| extend SignalCount = array_length(Signals)
| where SignalCount >= 2 or Count >= 25
| order by SignalCount desc, Count desc;

-- Hunt Linux confidential computing hosts for trust tooling, memory/RAS telemetry access, and recent physical-maintenance indicators
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'snpguest|tdx|sev-snp|sev_snp|qemu|kvm|attestation|rasdaemon|edac|ipmitool|dmidecode'
   OR Exe =~ 'snpguest|tdx|rasdaemon|edac|ipmitool|dmidecode'

#!/usr/bin/env bash
# DDRop readiness verifier for Intel TDX / AMD SEV-SNP hosts. Reports exposure; changes only conservative local auditing and RAS telemetry.
set -euo pipefail

say(){ printf '[%s] %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$*"; }
need_root(){ [ "$(id -u)" -eq 0 ] || { echo 'run as root'; exit 1; }; }
need_root

say 'Collecting platform identity and confidential computing exposure'
uname -a
(command -v dmidecode >/dev/null && dmidecode -t system -t memory | egrep -i 'Manufacturer|Product|Serial|Memory Device|Locator|Size|Speed' || true)
[ -d /sys/firmware/tdx ] && say 'Intel TDX firmware interface present: /sys/firmware/tdx' || say 'No /sys/firmware/tdx interface found'
ls /sys/module/kvm_amd/parameters 2>/dev/null | egrep -i 'sev|snp' || true
[ -e /dev/sev-guest ] && say 'AMD SEV guest device present: /dev/sev-guest' || true
[ -e /dev/tdx-guest ] && say 'Intel TDX guest device present: /dev/tdx-guest' || true

say 'Checking RAS and memory error telemetry services'
(systemctl is-enabled rasdaemon 2>/dev/null || true)
(systemctl is-active rasdaemon 2>/dev/null || true)
(command -v edac-util >/dev/null && edac-util --status || true)
(command -v ras-mc-ctl >/dev/null && ras-mc-ctl --summary || true)

say 'Recent kernel, EDAC, MCE, boot, and attestation-adjacent messages'
journalctl -k --since '7 days ago' | egrep -i 'EDAC|machine check|mce|uncorrected|memory controller|tdx|sev|snp|attestation|quote|measurement|reset|reboot' | tail -n 300 || true

say 'BMC/SEL physical events when ipmitool is locally available'
if command -v ipmitool >/dev/null; then
  ipmitool sel elist 2>/dev/null | egrep -i 'chassis|intrusion|cover|dimm|memory|power|boot|fru|sel' | tail -n 200 || true
  ipmitool chassis status 2>/dev/null || true
else
  say 'ipmitool not installed locally; pull SEL from out-of-band management instead'
fi

say 'Enabling local audit watches for direct memory and platform mutation paths'
AUDIT_RULES=/etc/audit/rules.d/90-confidential-computing-physical.rules
cat > "$AUDIT_RULES" <<'EOF'
-w /dev/mem -p wa -k ddrop_direct_memory_access
-w /proc/kcore -p r -k ddrop_kcore_read
-w /dev/kmem -p wa -k ddrop_kmem_access
-w /dev/sev-guest -p wa -k ddrop_sev_guest_device
-w /dev/tdx-guest -p wa -k ddrop_tdx_guest_device
-a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k ddrop_module_change
EOF
augenrules --load 2>/dev/null || service auditd restart 2>/dev/null || systemctl restart auditd 2>/dev/null || true

say 'Recommended host hardening checks - review before applying in production'
cat <<'EOF'
1. Require attestation before secret release and re-verify after any reboot, migration, BMC event, or maintenance window.
2. Bind secret release to fresh report data, policy version, external monotonic counter, and short TTL.
3. Anchor rollback-sensitive state outside the VM: HSM, TPM NVRAM policy, KMS audit log, ledger, or replicated tamper-evident service.
4. Disable unauthenticated local BMC access, restrict IPMI-over-LAN, require signed firmware updates, and alert on every SEL clear.
5. Alert on chassis intrusion, DIMM population change, unexpected power events, EDAC storms, and SEL timestamp gaps.
6. Do not store long-lived anti-replay counters only in guest memory.
7. For edge sites: tamper-evident chassis, locked racks, two-person maintenance, camera retention, and post-maintenance attestation re-baseline.
EOF

say 'Done. No kernel, firmware, memory, KVM, TDX, or SNP setting was changed by this script.'

Detection engineering guidance

Do not deploy a rule that merely looks for the word 'TDX' or 'SEV'; it will drown your analysts. The detection unit that matters is the host identity plus time window plus maintenance context. Build an allowlist of approved work orders from your DCIM, ITSM, or cloud-provider maintenance feed, then alert when confidential hosts produce physical or trust telemetry outside that window.

Recommended correlation:

1. Trigger: chassis intrusion, DIMM/SPD change, SEL clear, unexpected reboot, EDAC storm, or BMC login from a new source.
2. Enrich: host is TDX/SNP-capable, hosts confidential guests, has no approved ticket, or is in an edge/telco site.
3. Escalate if: within 15-120 minutes there is an attestation failure, quote freshness failure, measurement mismatch, external counter rollback, KMS unwrap anomaly, or unexpected guest migration.
4. Contain: freeze secret release, revoke session material derived after the earliest suspicious event, require re-attestation, snapshot BMC/SEL before clearing, preserve EDAC logs, and remove the node from the trust pool pending physical inspection.

Remediation and risk reduction

There is no source-provided patch version to install. Your remediation plan should therefore be architectural and operational.

• Confirm vendor posture in writing. Ask Intel, AMD, OEM, motherboard vendor, cloud provider, and managed hoster whether your exact CPU stepping, chipset, memory controller, BIOS, BMC, TDX module, SEV firmware, microcode, DIMM type, and chassis are within DDRop scope and what detection or firmware mitigations are planned. Require dates and advisory URLs in the ticket.
• Make attestation continuous and consequence-based. Do not attest once at boot and forget. Re-attest after reboot, migration, BMC event, maintenance, SEL clear, memory error storm, or time-source anomaly. Fail closed for secret release.
• Move freshness out of the guest. Keep anti-rollback state in an external service with monotonic counters, signed transcripts, HSM-backed keys, KMS audit, or a ledger. Guest memory must never be the sole source of truth for sequence numbers, revocation state, policy versions, quotas, or balances.
• Shorten secret lifetime. Release secrets only after fresh attestation, use short TTLs, rotate after suspicious telemetry, and zeroize keys on transitions. Assume stale memory can be presented again.
• Instrument the physical layer. Enable chassis intrusion where supported, tamper-evident seals, locked DIMM/latch procedures, rack access logs, cameras for edge sites, two-person maintenance, and automated comparison of DIMM population/SPD before and after tickets.
• Protect BMC and maintenance paths. Disable IPMI-over-LAN where not required, require MFA and separate credentials, alert on SEL clears, log firmware update attempts, and isolate management networks.
• Harden the host software prerequisite. Because the attacker needs software control first, keep the hypervisor, host kernel, QEMU, OVMF/SEV/TDX firmware, agents, and orchestration plane patched; restrict local root; use measured boot where available; monitor module loads and /dev/mem, /proc/kcore, and guest-device access.
• Design applications for replay resistance. Use nonces, sequence numbers anchored externally, request IDs, idempotency keys, signed monotonic timestamps from a trusted time source, and explicit rejection of counter rollback.
• Segment high-value confidential workloads. Do not place key custody, payment authorization, regulated clean rooms, and model-weight protection on the same bare-metal nodes with weak physical custody unless the incremental controls above are implemented.
• Incident response for suspected DDRop: treat as physical compromise plus cryptographic-state rollback. Preserve power state if safe, capture BMC SEL before clear, image host firmware settings, collect EDAC/RAS and journal logs, photograph DIMM slots and labels, chain-of-custody any suspected interposer, rotate all secrets that could have been exposed after earliest suspicious event, and rebuild from known-good firmware after motherboard/DIMM inspection.

Bottom line

DDRop is a reminder that confidential computing changes the adversary model; it does not abolish physics. If a motivated insider can open the box and already run code on the host, encrypted DRAM can still be manipulated at the edges of the trust boundary. Defenders should respond by tightening custody, making attestation fresh and continuous, anchoring anti-replay state outside the VM, and treating RAS, BMC, DIMM, and attestation telemetry as one correlated detection surface.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub