AMD SEV-SNP exists for one reason: to keep the cloud operator out of your virtual machine. This week, researchers publicly disclosed two attacks — Mior and Skyfall — that punch holes in exactly that guarantee. A malicious host with control of the hypervisor can extract secrets from inside an SEV-SNP-protected guest. Mior goes further: with control of the host's BIOS/firmware, it can write to guest memory and forge the signed attestation report that proves which software the VM is actually running.
If you are running regulated workloads — healthcare records, payment data, financial analytics, AI training sets — on confidential VMs in Azure, Google Cloud, AWS Nitro-adjacent AMD fleets, or on-prem private clouds, this is not an academic exercise. The trust boundary SEV-SNP was designed to enforce has been demonstrated as bypassable by the very party it was designed to defend against: the host.
The prerequisite is high — a fully rogue hypervisor (and, for Mior, firmware) — but that is precisely the threat model confidential computing was sold on. Defenders need to reassess what SEV-SNP actually protects in their architecture, harden the host layers beneath it, and build detection for the precondition states these attacks require.
Technical Analysis
What SEV-SNP Is Supposed to Guarantee
AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) encrypts VM memory with a per-VM key managed by the AMD Secure Processor (AMD-SP) and adds integrity protection so the hypervisor cannot replay or remap guest pages. Crucially, SEV-SNP generates a signed attestation report — rooted in the AMD-SP's certificate chain — that lets a guest (or a remote relying party) verify the firmware version and the exact software measurement the VM launched with. This is the mechanism that lets a tenant trust a VM running on hardware they don't own.
The Attacks
Skyfall — requires control of the host hypervisor. It enables the host to read plaintext data from inside an SEV-SNP-protected guest. Confidentiality of in-memory secrets (keys, PHI, credentials, model weights) is lost.
Mior — requires control of the hypervisor and the host BIOS/UEFI. It enables the host to:
- Read guest memory (same impact as Skyfall)
- Modify guest memory — integrity violation, enabling arbitrary in-guest code/data manipulation
- Forge the signed attestation report — the crown jewel. The attestation mechanism that lets tenants verify their VM's software stack can be subverted, meaning a tenant's verification pipeline can be told exactly what it wants to hear while the VM has been tampered with.
Why the Attestation Forgery Matters Most
Every control you build on top of SEV-SNP — remote attestation before secret release, key release policies in a KMS/HSM, "only decrypt if measurement matches" gates — depends on the attestation report being trustworthy. Mior demonstrates that report can be fabricated by the host. Any architecture that treats "attestation succeeded" as a binary trust decision is now provably vulnerable when the host itself is the adversary.
Affected Platforms
Per the disclosure, AMD SEV-SNP-protected VMs are affected. Organizations running SEV-SNP confidential VMs — including AMD EPYC-based confidential computing offerings in public clouds and on-prem KVM/QEMU hosts with SEV-SNP enabled — fall within the affected population. Firmware (AGESA/AMD-SP microcode) and host hypervisor stacks should be treated as in-scope for updates until vendor advisories complete the picture.
Exploitation Requirements and Status
- Prerequisites (Skyfall): full control of the host hypervisor — i.e., the attacker already owns the host OS/hypervisor layer.
- Prerequisites (Mior): hypervisor control plus control of the host BIOS/UEFI firmware.
- Status: publicly disclosed research attacks as of this week. No confirmed in-the-wild campaign has been reported at time of writing, and no CVE identifier has been published in the source material. Treat this as a research-validated break of a security boundary — historically, PoCs for this class of attack follow disclosure quickly, and cloud threat actors (and any insider with host access) are the natural audience.
Defender's Threat Model Shift
These attacks are not exploitable by a random external actor — they are exploitable by a compromised or malicious host layer. That reframes your defense priorities: the hypervisor and firmware of any host running SEV-SNP guests are now formally part of the attack surface for guest confidentiality. Host compromise is no longer just an availability problem; it is a guest-secrets problem.
Detection & Response
You cannot detect Mior or Skyfall from inside the guest — the guest is the victim, and its view can be manipulated. Detection must live at the host layer and target the precondition states: rogue hypervisor modification, firmware tampering, and hypervisor configuration manipulation around SEV/SNP launch.
The rules below target the observable precursors: BIOS/firmware flashing tool execution on Linux hosts, SEV-related kernel module and IOMMU tampering, and QEMU/KVM launch anomalies. Tune them to your gold-image host baselines — these should be near-silent on a properly managed virtualization fleet, which is exactly why they matter.
---
title: BIOS/UEFI Firmware Flashing Tool Execution on Virtualization Host
id: 3c8f1a2e-7b4d-4e91-a2c6-9f0d5b7e1a34
status: experimental
description: Detects execution of firmware flashing utilities on Linux hosts. Mior requires control of the host BIOS/UEFI; use of flashrom, fwupd with raw flags, or vendor flashing tools on a production hypervisor is a strong precondition indicator.
references:
- https://thehackernews.com/2026/11/new-mior-and-skyfall-attacks-let-rogue.html
- https://attack.mitre.org/techniques/T1542/001/
author: Security Arsenal
date: 2026/11/06
tags:
- attack.persistence
- attack.defense_evasion
- attack.t1542.001
logsource:
category: process_creation
product: linux
detection:
selection_img:
Image|endswith:
- '/flashrom'
- '/afuwin'
- '/afudos'
- '/afulnx'
- '/spi-flash'
selection_name:
Image|contains:
- 'flashrom'
- 'biosupdate'
selection_cli:
CommandLine|contains:
- 'flashrom -w'
- 'flashrom --write'
- 'fwupdtool install-blob'
- '--programmer internal'
condition: selection_img or selection_name or selection_cli
falsepositives:
- Scheduled firmware maintenance windows by platform engineering
level: high
---
title: SEV/SNP Kernel Module or IOMMU Tampering on AMD Host
id: 6d2e9b41-1f5a-4c83-b7d2-8e3a4c6f2091
status: experimental
description: Detects attempts to unload or modify SEV-related kernel modules, disable IOMMU protection, or alter secure boot / SNP kernel parameters on AMD virtualization hosts. Rogue-hypervisor attacks against SEV-SNP guests require manipulation of these layers.
references:
- https://thehackernews.com/2026/11/new-mior-and-skyfall-attacks-let-rogue.html
- https://attack.mitre.org/techniques/T1562/001/
author: Security Arsenal
date: 2026/11/06
tags:
- attack.defense_evasion
- attack.t1562.001
logsource:
category: process_creation
product: linux
detection:
selection_mod:
Image|endswith:
- '/rmmod'
- '/modprobe'
CommandLine|contains:
- 'ccp'
- 'kvm_amd'
- 'sev'
- 'iommu'
selection_params:
CommandLine|contains:
- 'amd_iommu=off'
- 'iommu=off'
- 'iommu=pt'
- 'sev=0'
- 'sev_snp=0'
- 'kvm_amd.sev=0'
selection_sysrq:
CommandLine|contains:
- 'mem_sleep'
- '/dev/mem'
- '/dev/kmem'
condition: selection_mod or selection_params or selection_sysrq
falsepositives:
- Kernel debugging by platform engineers
- Boot parameter changes during OS upgrades
level: high
---
title: Anomalous QEMU/KVM Launch Options for SEV-SNP Guests
id: 9a4c7e15-3d8b-4f62-a1e9-5c2d7b0f8436
status: experimental
description: Detects QEMU launches with manual SEV/SNP object configuration, debug monitor attachment, or memory backend overrides that deviate from orchestrator-managed launches. A rogue hypervisor operator modifying guest launch parameters can indicate preparation for memory introspection against confidential VMs.
references:
- https://thehackernews.com/2026/11/new-mior-and-skyfall-attacks-let-rogue.html
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/11/06
tags:
- attack.execution
- attack.collection
logsource:
category: process_creation
product: linux
detection:
selection:
Image|contains: 'qemu-system'
CommandLine|contains:
- 'sev-snp-guest'
- 'sev-guest'
filter_orchestrator:
ParentImage|endswith:
- '/libvirtd'
- '/virtqemud'
- '/kubelet'
filter_debug:
CommandLine|contains:
- '-S'
- '-gdb'
- 'guest-debug'
- '-mem-path'
- 'memory-backend-file'
condition: selection and not filter_orchestrator and not filter_debug
falsepositives:
- Manual VM launches by virtualization administrators for recovery operations
level: medium
// Hunt: Firmware flashing, SEV/IOMMU tampering, and anomalous SEV-SNP guest launches
// across Linux hypervisor hosts ingested via Syslog/CEF into Sentinel
let lookback = 14d;
let firmwareTools = dynamic(["flashrom", "afuwin", "afulnx", "biosupdate", "spi-flash", "fwupdtool install-blob"]);
let snpTamper = dynamic(["amd_iommu=off", "iommu=off", "sev=0", "sev_snp=0", "kvm_amd.sev=0", "rmmod ccp", "rmmod kvm_amd", "/dev/mem", "/dev/kmem"]);
union
(
Syslog
| where TimeGenerated > ago(lookback)
| where ProcessName in~ ("flashrom","rmmod","modprobe","afuwin","afulnx","fwupdtool")
or SyslogMessage has_any (firmwareTools) or SyslogMessage has_any (snpTamper)
| project TimeGenerated, Computer, HostName, ProcessName, SyslogMessage, SeverityLevel
| extend IndicatorType = "FirmwareOrSNPTamper"
),
(
CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where Message has "qemu-system" and (Message has "sev-snp-guest" or Message has "sev-guest")
| where Message has_any ("-S", "-gdb", "guest-debug", "memory-backend-file", "-mem-path")
| project TimeGenerated, DeviceName = Computer, SourceUserName, Message
| extend IndicatorType = "AnomalousSEVSNPLaunch"
)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), EventCount = count()
by Computer, IndicatorType
| order by LastSeen desc
-- Hunt for firmware manipulation tooling and SEV/SNP tampering indicators on Linux hypervisor hosts
-- Deploy as a hunt scoped to hosts running SEV-SNP guests (KVM/QEMU fleet)
SELECT Pid,
Name,
Exe,
CommandLine,
Username,
CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(flashrom|afuwin|afulnx|fwupdtool install-blob|biosupdate|spi-flash)'
OR CommandLine =~ '(?i)(amd_iommu=off|iommu=off|sev_snp=0|kvm_amd.sev=0|rmmod (ccp|kvm_amd))'
OR CommandLine =~ '/dev/(k)?mem'
OR (Exe =~ 'qemu-system' AND CommandLine =~ 'sev-snp-guest|sev-guest'
AND CommandLine =~ '-S|-gdb|guest-debug|memory-backend-file')
#!/bin/bash
# sev_snp_host_verify.sh — Host integrity verification for AMD SEV-SNP hypervisors
# Run on each KVM host or via configuration management. Exit 1 on failure.
set -u
FAIL=0
echo "=== [1] SEV-SNP enablement and firmware state ==="
# Verify SNP is active and the kernel sees the expected features
if [ -f /sys/module/kvm_amd/parameters/sev_snp ]; then
SNP=$(cat /sys/module/kvm_amd/parameters/sev_snp)
[ "$SNP" = "Y" ] && echo "[OK] sev_snp=Y" || { echo "[FAIL] sev_snp=$SNP"; FAIL=1; }
else
echo "[WARN] kvm_amd sev_snp parameter not exposed — verify kernel/AGESA support"
fi
echo "=== [2] IOMMU must be enforced (not passthrough/off) ==="
CMDLINE=$(cat /proc/cmdline)
echo "$CMDLINE" | grep -Eq 'iommu=off|amd_iommu=off|iommu=pt' \
&& { echo "[FAIL] IOMMU weakened in cmdline: $CMDLINE"; FAIL=1; } \
|| echo "[OK] IOMMU enforced"
echo "=== [3] Secure Boot state ==="
if command -v mokutil >/dev/null 2>&1; then
mokutil --sb-state | grep -qi 'enabled' \
&& echo "[OK] Secure Boot enabled" \
|| { echo "[FAIL] Secure Boot disabled/unknown"; FAIL=1; }
else
[ -d /sys/firmware/efi ] && echo "[INFO] EFI present; install mokutil to verify SB state" || echo "[FAIL] Not UEFI boot"
fi
echo "=== [4] BIOS write protection / flashing tools present ==="
for tool in flashrom afuwin afulnx spi-flash; do
command -v "$tool" >/dev/null 2>&1 \
&& { echo "[FAIL] Flashing tool installed on prod host: $tool ($(command -v $tool))"; FAIL=1; }
done
echo "[OK] No known firmware flashing tools found (if nothing printed above)"
echo "=== [5] AMD-SP / SEV firmware version — baseline against AMD advisory ==="
# snphost (AMD's SEV tooling) reports platform and firmware state
if command -v snphost >/dev/null 2>&1; then
snphost show version 2>/dev/null || snphost ok 2>/dev/null || true
snphost show config 2>/dev/null || true
else
dmesg 2>/dev/null | grep -i 'SEV API' | tail -n 3 || echo "[WARN] Install snphost to enumerate SEV firmware versions"
fi
echo "=== [6] Loaded SEV-related modules — alert on unexpected changes ==="
lsmod | grep -E 'ccp|kvm_amd' || echo "[WARN] Expected ccp/kvm_amd modules not loaded"
echo "=== [7] Recent firmware/NVRAM write attempts in audit log ==="
if [ -f /var/log/audit/audit.log ]; then
grep -E 'flashrom|/dev/mem|/dev/kmem|efivars' /var/log/audit/audit.log 2>/dev/null | tail -n 20 \
|| echo "[OK] No firmware-write artifacts in audit log"
fi
echo "=== [8] Pending security updates (firmware + kernel) ==="
if command -v apt >/dev/null 2>&1; then
apt list --upgradable 2>/dev/null | grep -Ei 'linux-image|linux-firmware|amd64-microcode' || echo "[OK] No pending kernel/firmware/microcode updates"
elif command -v dnf >/dev/null 2>&1; then
dnf check-update --security 2>/dev/null | grep -Ei 'kernel|linux-firmware|microcode' || echo "[OK] No pending security updates for kernel/firmware"
fi
echo "=== RESULT: $([ $FAIL -eq 0 ] && echo PASS || echo FAIL) ==="
exit $FAIL
Remediation
1. Apply AMD firmware and microcode updates immediately. Monitor AMD's security bulletin portal and your OEM/cloud provider advisories for AGESA and AMD-SP firmware updates addressing these disclosures. On-prem fleets: schedule emergency firmware maintenance windows for all EPYC hosts running SEV-SNP guests. Cloud tenants: open a ticket with your provider demanding their remediation timeline and firmware version disclosure for the host class running your confidential VMs.
2. Harden the firmware layer (Mior's prerequisite). Mior needs BIOS control — deny it:
- Enable BIOS write protection and hardware root-of-trust features available on your platform (vendor-specific boot guard / hardware-validated boot equivalents).
- Enforce UEFI Secure Boot on every host and verify it in configuration management (the script above does this).
- Remove all firmware flashing utilities from production host images; require out-of-band (BMC/iDRAC/iLO) firmware update paths with signed images only.
- Restrict and alert on BMC access — BMC compromise is the most realistic path to BIOS control.
3. Harden the hypervisor layer (both attacks' prerequisite).
- Enforce IOMMU (never
iommu=ptoriommu=off) and kernel lockdown mode. - Treat any hypervisor-level compromise as a guest-confidentiality incident, not just a host incident. Update your IR runbooks: host compromise on an SEV-SNP fleet now triggers guest secret rotation (keys, credentials, certificates that were ever in guest memory).
4. Fix your attestation architecture. Because Mior forges the signed attestation report, do not rely on a single attestation check as your trust decision:
- Bind attestation to runtime measurement where possible, not just launch-time.
- Combine attestation with independent signals: workload identity from an out-of-band control plane, network-layer mutual TLS with short-lived certs, and behavioral baselining of the guest.
- If you gate KMS secret release on SEV-SNP attestation, add a second release condition your host operator cannot forge.
5. Reassess workload placement. For crown-jewel workloads where the host operator is genuinely untrusted (multi-tenant private cloud, outsourced infrastructure), evaluate whether bare-metal or single-tenant dedicated hosts are the appropriate control until firmware fixes land and are verified.
6. Hunt now. Deploy the Sigma rules, KQL query, and VQL artifact above across your virtualization fleet. On a properly managed fleet these detections should be near-zero-noise — any hit warrants investigation.
There is no CISA KEV entry or CVE assignment in the source disclosure at time of writing; track AMD's security advisory feed and this research for published identifiers and PoC releases, and treat the window between disclosure and patch as your highest-risk period.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.