[EXP] KVM Guest-to-Host Escape and Multi-Tenant Virtualization Boundary Compromise Risk

Report Type: EXP
Threat Category: KVM Guest-to-Host Escape and Multi-Tenant Virtualization Boundary Compromise
Assessment Date: July 09, 2026
Primary Impact Domain: Compute Trust and Tenant Separation
Secondary Impact Domains: VM Artifact Exposure, Storage and Backup Integrity, Credential Exposure, Control-Plane Resilience, Post-Remediation Assurance
Affected Asset Class: KVM Compute Hosts, Linux Virtualization Hosts, Nested-Virtualization-Enabled Guest Workloads, Multi-Tenant Compute Infrastructure, OpenStack / Private Cloud / Hosting Virtualization Environments
Threat Objective Classification: Guest-to-Host Escape, Virtualization Boundary Compromise, Host Integrity Degradation, Tenant-Boundary Exposure, Infrastructure Expansion from Compute-Host Context

Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: July 09, 2026
Publication Type: Cybersecurity Research Report / White Paper

BLUF

‍  KVM guest-to-host escape and multi-tenant virtualization boundary compromise behavior create material business risk because untrusted, tenant-controlled, customer-managed, CI-controlled, sandboxed, or high-risk guest workloads may be able to influence the integrity of x86 KVM compute hosts that support downstream tenants, storage, backup, identity, orchestration, and management services. The core risk is whether guest-side privileged virtualization activity, nested virtualization behavior, or exploit-attempt behavior aligned with host-side KVM instability, compute-node failure, host artifact access, control-plane interaction, storage access, credential exposure, cross-tenant exposure, or lateral movement before the organization could validate host integrity and tenant blast radius. Immediate executive action is required to confirm exposed KVM hosts, nested virtualization state, untrusted guest placement, kernel patch and reboot status, host-fault evidence, VM placement history, compute-node recovery activity, storage and backup access, management-plane access, outbound communication, credential exposure, and the organization’s ability to distinguish routine virtualization operations from guest-to-host boundary compromise behavior.

Executive Risk Translation

KVM guest-to-host escape shifts the business risk from a single Linux kernel or hypervisor exposure to uncertainty over whether the organization can still trust the virtualization layer that separates guests, tenants, compute hosts, storage, control-plane services, backups, identity paths, and management infrastructure. If the organization cannot reliably connect suspicious guest-side virtualization behavior to host-side KVM instability, compute-node failure, VM placement, post-fault host activity, storage access, credential exposure, outbound communication, or cross-tenant behavior, leadership may need to assume that the affected compute host and dependent virtualization trust relationships were exposed until proven otherwise. That response can expand into emergency patch validation, reboot confirmation, nested virtualization restriction, compute-host quarantine, VM placement reconstruction, tenant impact review, storage and backup review, credential rotation, control-plane access review, forensic preservation, legal and compliance assessment, cyber-insurance coordination, executive reporting, and customer or partner trust management.

S3 — Why This Matters Now

·        KVM guest-to-host escape behavior creates a direct concern for public cloud, private cloud, hosting-provider, OpenStack-style, Kubernetes virtualization, CI runner, sandbox, malware-analysis, developer lab, and multi-tenant compute environments where untrusted guests can exercise virtualization functionality.

·        Nested virtualization increases urgency because guest workloads may be able to trigger low-level virtualization paths, memory-management behavior, shadow paging behavior, reverse-map handling, VM lifecycle transitions, or host-side KVM fault conditions.

·        The durable enterprise concern is not limited to a named CVE, vulnerable-kernel finding, scanner result, public proof-of-concept reference, or isolated crash event; it is whether guest-controlled activity can be correlated to host instability and post-fault infrastructure behavior.

·        Host-side KVM instability, kernel oops events, soft lockups, watchdog events, panics, compute-node resets, hypervisor faults, or emergency host evacuation can create uncertainty about whether the virtualization boundary remained intact.

·        The highest-risk condition occurs when suspicious guest-side virtualization behavior is followed by host-level access to VM disks, snapshots, memory artifacts, metadata paths, cloud-init data, libvirt or QEMU artifacts, storage connectors, backup systems, identity services, orchestration services, or tenant networks.

·        Patching alone is not sufficient containment when exposed hosts were unstable, reboot validation is incomplete, nested virtualization remained enabled for untrusted workloads, placement history is unclear, or post-fault host behavior was not reviewed.

·        Cloud, hosted, managed, or sealed virtualization environments can make confirmation difficult because customers may lack host-side KVM telemetry while providers may have limited guest visibility.

·        Missing host kernel logs, rotated KVM logs, unavailable crash dumps, incomplete VM placement history, weak tenant mapping, limited storage attribution, incomplete control-plane records, or poor outbound telemetry can force broader investigation because the organization cannot quickly prove whether host or tenant exposure occurred.

S4 — Key Judgments

·        KVM guest-to-host escape and virtualization boundary compromise should be treated as a compute trust-boundary risk, not only as a vulnerability-management ticket, kernel patch event, or host stability issue.

·        The primary enterprise risk is reduced ability to determine whether untrusted guest activity influenced host-side KVM behavior and created exposure to compute hosts, tenant workloads, storage, backup, identity, control-plane services, management networks, or downstream infrastructure.

·        Suspicious guest-side nested virtualization activity followed by KVM host instability, compute-node failure, host evacuation, storage access, outbound communication, credential exposure, control-plane interaction, or repeated tenant-linked host faults is the strongest executive risk signal.

·        A single vulnerable-kernel finding, nested virtualization setting, public proof-of-concept reference, guest root condition, KVM log string, host reboot, kernel panic, or compute-node failure should not be treated as confirmed compromise without guest, host, placement, post-fault behavior, or time-window correlation.

·        Business exposure increases sharply when affected compute hosts support multi-tenant workloads, regulated workloads, customer-managed guests, CI execution, malware-analysis environments, sandboxed workloads, storage access paths, backup repositories, identity integrations, or management-plane services.

·        Incomplete telemetry increases cost because the organization may need to reconstruct guest activity, host fault sequences, VM placement history, tenant ownership, compute-node recovery, storage access, backup access, identity access, outbound communication, and control-plane actions across separate systems.

·        The most damaging outcome occurs when suspected or confirmed guest-to-host compromise results in cross-tenant exposure, VM artifact access, credential exposure, storage or backup access, control-plane interaction, management-network access, tenant data exposure, service disruption, legal and compliance review, cyber-insurance scrutiny, or board-level concern about virtualization resilience.

S5 — Executive Risk Summary

Business Risk

KVM guest-to-host escape can weaken the organization’s ability to trust the compute layer that separates guests, tenants, workloads, storage, identity, backups, orchestration, and management infrastructure. Risk increases when affected KVM hosts support public cloud services, private cloud platforms, hosting environments, OpenStack-style deployments, Kubernetes virtualization, CI runners, sandbox systems, malware-analysis environments, developer labs, regulated workloads, partner workloads, customer-managed workloads, or high-availability business services. The business impact is not limited to a vulnerable kernel or unstable host; it can expand into uncertainty about whether adversaries triggered host-side KVM instability, accessed VM artifacts, reached storage or backup systems, exposed credentials, interacted with control-plane services, crossed tenant boundaries, initiated outbound communication, or retained host-level access after apparent remediation.

Technical Cause

The risk is driven by untrusted guest control, nested virtualization exposure, guest-side privileged virtualization activity, host-side KVM memory-management fault behavior, incomplete isolation of high-risk workloads, insufficient placement governance, and limited ability to correlate guest actions with host instability and post-fault infrastructure activity. Technical exposure becomes material when guest-side nested virtualization behavior, kernel module loading, nested VM lifecycle manipulation, low-level virtualization activity, or abnormal state transitions align with KVM host warnings, MMU fault patterns, shadow paging behavior, reverse-map handling, kernel oops events, panics, soft lockups, watchdog events, compute-node resets, host quarantine, VM evacuation, storage access, backup access, metadata access, identity access, orchestration activity, or unusual outbound communication. Exposure increases when KVM host inventory, nested virtualization state, kernel version, reboot validation, VM placement history, tenant ownership, approved nested virtualization use, host logs, crash telemetry, storage mapping, backup mapping, control-plane mapping, and maintenance context are incomplete or poorly coordinated.

Threat Posture

The threat posture is elevated because KVM guest-to-host escape can turn a guest-controlled workload into a path toward host-level access, compute-node disruption, VM artifact exposure, credential access, storage access, backup access, control-plane interaction, tenant-boundary compromise, or lateral movement from the virtualization host. Exploitation may not begin with endpoint malware, phishing, or traditional credential theft because the initial path can be a guest workload exercising nested virtualization, privileged virtualization behavior, or low-level host interaction from inside a tenant-controlled environment. The posture becomes critical when suspicious host instability affects compute infrastructure tied to multi-tenant service delivery, regulated workloads, customer-managed workloads, shared storage, backup repositories, identity services, orchestration systems, management networks, or environments where multiple downstream tenants and services depend on the same virtualization layer.

Executive Decision Requirement

Executives must require measurable assurance that exposed KVM compute hosts are inventoried, nested virtualization exposure is documented, untrusted guest placement is understood, kernel patch state and reboot completion are validated, host logs and crash evidence are preserved, suspicious guest-side virtualization behavior is reviewed, VM placement and tenant ownership are reconstructed, compute-node recovery actions are explained, storage and backup access is examined, identity and metadata access is reviewed, outbound communication is analyzed, host configuration is compared against known-good baselines, and post-remediation monitoring is operational. Leadership should also require evidence that legal, compliance, cyber insurance, infrastructure, cloud operations, SOC, incident response, platform engineering, application owners, communications, and business owners can support rapid decisions if host compromise, cross-tenant exposure, credential exposure, storage access, backup access, control-plane impact, or customer-facing disruption cannot be ruled out.

S6 — Executive Cost Summary

KVM guest-to-host escape creates financial exposure because the organization must determine whether a workload that should have remained inside a guest boundary affected the integrity of the compute host and its downstream trust relationships. The cost profile is different from a routine kernel update because affected hosts may support tenants, customer-managed workloads, regulated services, CI execution, sandboxed analysis, storage mounts, backup connectors, orchestration agents, identity paths, metadata services, monitoring systems, management networks, and high-availability infrastructure. Response cost is driven by the work required to validate exposed KVM assets, confirm nested virtualization state, preserve host logs and crash evidence, reconstruct VM placement, review tenant ownership, inspect host configuration, compare kernel and reboot state, analyze storage and backup access, review identity and metadata access, validate outbound communication, coordinate workload evacuation, rotate credentials where needed, and prove that compute-host and tenant trust have been restored.

Cost increases materially when host KVM logs rotate quickly, crash dumps are unavailable, guest telemetry is inaccessible, VM placement history is incomplete, tenant mapping is unreliable, nested virtualization inventory is inaccurate, patch tools report installation without reboot validation, storage and backup logs lack host attribution, metadata access is poorly logged, management-plane actions are distributed across separate systems, approved maintenance windows are incomplete, cloud-provider telemetry is limited, or incident responders cannot quickly distinguish routine failover from exploit-aligned instability. The highest-cost cases occur when suspected or confirmed compromise affects multi-tenant hosts, shared storage, backup repositories, identity services, orchestration systems, control-plane services, management networks, regulated workloads, customer-managed tenants, cross-tenant access paths, or compute clusters supporting critical business operations.

Low Impact Scenario

Rapid investigation confirms suspicious guest-side virtualization behavior, nested virtualization misuse, or public exploit-attempt activity without evidence of successful host compromise, VM artifact access, storage access, backup access, credential exposure, control-plane interaction, outbound communication, tenant-boundary exposure, persistence-like host changes, or post-remediation activity. Activity may involve guest-side kernel module loading, nested hypervisor activity, failed nested VM lifecycle manipulation, abnormal KVM warnings, isolated host instability, scanner-driven exploit attempts, or limited compute-node recovery, but host logs, crash telemetry, placement history, tenant mapping, storage logs, network telemetry, change records, and host configuration review support a failed, contained, or non-impacting event. Response is limited to targeted patch validation, reboot confirmation, nested virtualization restriction, host-fault preservation, focused placement review, tenant impact check, outbound communication review, short-term monitoring, and executive assurance that compute-host trust was not materially affected. Estimated impact $500K - $4M.

Moderate Impact Scenario

Confirmed or strongly suspected guest-to-host boundary stress affects one or more KVM compute hosts where suspicious guest-side virtualization behavior aligns with host-side KVM instability, compute-node failure, repeated tenant-linked faults, host evacuation, host quarantine, VM artifact access, storage access, backup access, metadata access, rare outbound communication, administrative changes, or control-plane interaction. The organization cannot immediately determine whether adversaries obtained host-level access, exposed guest artifacts, accessed VM disks or snapshots, reached credentials, manipulated host configuration, accessed storage or backup systems, interacted with identity or orchestration services, or crossed tenant boundaries. Response requires enterprise-focused KVM host review, nested virtualization inventory validation, VM placement reconstruction, tenant ownership review, crash and kernel log preservation, compute-node quarantine, host configuration comparison, storage and backup access review, credential and token review, control-plane analysis, outbound traffic analysis, legal and compliance review, cyber-insurance coordination, executive reporting, and strengthened monitoring for post-remediation activity. Estimated impact $5M - $30M.

High Impact Scenario

KVM guest-to-host escape becomes an enterprise-impact event when suspected or confirmed host compromise results in cross-tenant exposure, VM disk or snapshot access, memory artifact exposure, credential access, storage or backup repository access, identity service interaction, orchestration abuse, management-network access, lateral movement from a compute host, multi-host instability, tenant data exposure, service disruption, or incomplete containment. The organization may need to assume that affected compute hosts, tenant workloads, storage backends, backup systems, metadata paths, orchestration agents, identity integrations, management services, and dependent workloads were exposed until audit evidence proves otherwise. Response may require extended host forensics, emergency workload evacuation, compute-host rebuilds, nested virtualization disablement, broad credential and token rotation, storage and backup validation, tenant impact assessment, customer or partner notification analysis, legal and privacy escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal validation that affected compute infrastructure can safely return to service. Estimated impact $40M - $180M+.

S6A — Key Cost Drivers

·        Number and sensitivity of affected KVM compute hosts, virtualization hosts, OpenStack compute nodes, private cloud nodes, hosting-provider nodes, CI runners, sandbox hosts, malware-analysis systems, developer lab hosts, and multi-tenant compute pools.

·        Scope of nested virtualization exposure, including Intel or AMD nested virtualization settings, compute-pool policy, untrusted guest placement, customer-managed workloads, externally provisioned workloads, CI-controlled workloads, sandboxed workloads, and high-risk guest images.

·        Availability and retention of Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, systemd journals, compute-agent logs, crash dumps, host health records, VM placement records, tenant ownership records, storage logs, backup logs, identity logs, metadata logs, orchestration logs, firewall logs, DNS logs, proxy logs, NDR telemetry, endpoint telemetry, change-management records, and incident-response records.

·        Whether response must reconstruct guest activity, host-side KVM instability, compute-node failure, host evacuation, VM migration, host quarantine, storage access, backup access, metadata access, identity access, outbound communication, control-plane interaction, and tenant-boundary exposure across separate telemetry sources.

·        Whether nested virtualization can be restricted to approved hosts, approved tenants, approved images, approved CI pipelines, approved labs, and documented business requirements without disrupting operations.

·        Scope of sensitive material potentially exposed, including VM disks, snapshots, memory artifacts, cloud-init data, metadata files, libvirt artifacts, QEMU artifacts, host logs, crash dumps, SSH keys, storage credentials, backup credentials, orchestration credentials, monitoring credentials, tenant secrets, and control-plane tokens.

·        Size and complexity of the affected virtualization environment, including public cloud, private cloud, hosted compute, multi-region clusters, OpenStack environments, Kubernetes virtualization environments, high-availability compute pools, shared storage, backup repositories, and multiple downstream tenants depending on the same compute layer.

·        Ability to distinguish legitimate patching, live migration, host evacuation, failover testing, kernel testing, CI execution, sandbox testing, malware-analysis activity, storage maintenance, backup operations, monitoring activity, vendor support, and incident-response cleanup from attacker-driven behavior.

·        Need to rotate or review compute-host credentials, storage credentials, backup credentials, orchestration credentials, monitoring credentials, tenant-exposed credentials, SSH keys, API tokens, metadata credentials, service accounts, vendor support accounts, deployment secrets, and reused passwords.

·        Business disruption caused by emergency patching, reboot validation, nested virtualization shutdown, workload evacuation, compute-node quarantine, host rebuilds, storage access review, backup validation, credential rotation, control-plane review, tenant impact analysis, and customer-facing service interruption.

·        Legal, privacy, regulatory, cyber-insurance, communications, customer, partner, executive, or board-level obligations triggered by suspected cross-tenant exposure, regulated workload impact, credential exposure, storage or backup access, management-plane compromise, service disruption, incomplete containment, or inability to prove non-exposure.

S6B — Compliance and Risk Context

Figure 1

KVM guest-to-host escape and multi-tenant virtualization boundary compromise executive risk model showing how untrusted guest-side virtualization activity can escalate from nested virtualization exposure and host instability into compute-host compromise, VM artifact exposure, storage and backup access, credential exposure, control-plane interaction, cross-tenant exposure, service disruption, and enterprise-level business exposure.

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

KVM Guest-to-Host Escape and Multi-Tenant Virtualization Boundary Compromise Risk

Risk Description

Adversaries may exploit or attempt to exploit KVM guest-to-host escape behavior, nested virtualization exposure, or virtualization boundary weaknesses to move from guest-controlled activity into host-side KVM instability, compute-node failure, host-level access, VM artifact exposure, storage access, backup access, credential exposure, control-plane interaction, management-network access, tenant-boundary compromise, or lateral movement from the virtualization host. This may increase business interruption, customer or tenant trust concern, regulated workload exposure, credential and token exposure, storage and backup integrity concerns, cloud or private cloud governance issues, legal and compliance review, cyber-insurance scrutiny, customer or partner notification analysis, and board-level concern around virtualization resilience. Compliance exposure should be driven by local evidence of host compromise, VM artifact access, cross-tenant exposure, credential access, storage access, backup access, identity access, control-plane impact, regulated data exposure, service disruption, or post-remediation activity, not by vulnerable-kernel status, nested virtualization presence, scanner traffic, public proof-of-concept availability, or isolated host instability alone.

Likelihood

High

Impact

Severe

Risk Rating

Critical

Annualized Risk Exposure

Estimated $5M - $40M+ for materially exposed enterprise environments with nested-virtualization-enabled KVM hosts, untrusted or customer-managed guest workloads, multi-tenant compute pools, incomplete host-fault logging, incomplete crash evidence, weak VM placement history, limited tenant mapping, incomplete reboot validation, limited storage and backup attribution, weak outbound monitoring, incomplete management-plane records, or poor host-to-workload mapping. Exposure may exceed $40M - $180M+ where KVM guest-to-host compromise results in confirmed or suspected host-level access, cross-tenant exposure, VM disk or snapshot access, credential exposure, storage or backup repository access, identity or orchestration interaction, management-network access, multi-host instability, regulated workload exposure, customer-facing service disruption, incomplete containment, cyber-insurance review, legal escalation, communications response, or board-level reporting.

S7 — Risk Drivers

·        KVM compute hosts can concentrate tenant separation, workload execution, storage connectivity, backup access, identity paths, metadata access, orchestration dependencies, monitoring services, and management-network trust inside a single virtualization layer.

·        Nested virtualization creates high-risk conditions when untrusted, customer-managed, externally provisioned, CI-controlled, sandboxed, malware-analysis, or high-risk guest workloads can exercise low-level virtualization behavior.

·        Guest-side privileged virtualization activity can create a path toward host-side KVM instability, compute-node failure, host artifact access, credential exposure, storage access, backup access, control-plane interaction, tenant-boundary exposure, or lateral movement.

·        Vulnerable-kernel status, public proof-of-concept availability, nested virtualization exposure, and exploit reporting can create urgency, but they cannot prove compromise or non-compromise without correlated guest, host, placement, fault, post-fault behavior, or time-window evidence.

·        Patch completion can create false closure when reboot validation, livepatch effectiveness, host instability review, VM placement analysis, storage access review, credential review, control-plane activity, outbound communication, or post-remediation monitoring has not been completed.

·        KVM administration, live migration, host evacuation, patching, kernel testing, CI execution, sandbox testing, malware-analysis activity, backup jobs, storage maintenance, monitoring activity, vendor support, and incident-response actions can resemble suspicious behavior without strong baselines.

·        Business exposure increases when affected hosts support public cloud platforms, private cloud services, hosting environments, regulated workloads, customer-managed tenants, partner workloads, CI runners, sandbox environments, malware-analysis infrastructure, shared storage, backup repositories, identity integrations, or high-availability applications.

·        Missing or inconsistent host logs, KVM logs, crash dumps, VM placement records, tenant ownership mapping, storage logs, backup logs, identity logs, metadata records, control-plane logs, endpoint telemetry, DNS logs, proxy logs, firewall logs, NDR telemetry, configuration baselines, or change-management records can increase investigation scope and cost.

·        Limited ability to rapidly identify exposed hosts, disable nested virtualization, validate reboot completion, quarantine compute nodes, preserve forensic artifacts, reconstruct placement history, review storage access, rotate credentials, and confirm tenant impact can extend operational disruption.

·        Host compromise, cross-tenant exposure, credential access, storage or backup access, orchestration abuse, management-plane access, regulated workload exposure, customer-facing disruption, and incomplete containment can transform a virtualization vulnerability into legal, regulatory, communications, cyber-insurance, customer, partner, executive, and board-level exposure.

S8 — Bottom Line for Executives

KVM guest-to-host escape and multi-tenant virtualization boundary compromise should be treated as a high-priority compute trust, tenant-separation, storage exposure, credential exposure, control-plane resilience, and business-continuity risk because an untrusted guest workload may create uncertainty over whether the host virtualization layer remained intact. The executive question is not only whether the kernel was patched, whether nested virtualization was enabled, whether a scanner or public PoC touched the environment, or whether a compute host rebooted; it is whether the organization can prove that suspicious guest-side virtualization behavior did not lead to host-level access, VM artifact exposure, storage access, backup access, credential exposure, control-plane interaction, management-network access, cross-tenant exposure, rare outbound communication, or continued access after remediation. Response must focus on validating exposed KVM hosts, nested virtualization state, untrusted guest placement, patch and reboot completion, host-fault evidence, VM placement history, tenant ownership, storage and backup access, identity and metadata access, outbound activity, host configuration integrity, and post-remediation monitoring before leadership can rely on the affected virtualization layer.

S9 — Board-Level Takeaway

KVM guest-to-host escape turns virtualization integrity into a board-level issue involving tenant separation, compute trust, storage and backup exposure, credential protection, control-plane resilience, customer confidence, and business-continuity assurance. The risk is not simply that a host was vulnerable, a patch was required, nested virtualization was enabled, or a crash occurred; it is the possibility that adversaries used guest-controlled behavior to affect host-side KVM execution, expose VM artifacts, reach storage or backup systems, access credentials, interact with orchestration or identity services, cross tenant boundaries, disrupt compute availability, or retain host-level access on infrastructure that downstream workloads and business services depend on. Leadership should require evidence that KVM asset inventory, nested virtualization restriction, patch and reboot validation, host-fault preservation, VM placement reconstruction, tenant mapping, storage and backup review, credential rotation readiness, control-plane review, incident-response readiness, legal readiness, and business-continuity planning can support rapid, defensible decisions when virtualization boundary exposure is suspected.

S10 — Threat Overview

KVM guest-to-host escape and multi-tenant virtualization boundary compromise describes adversary behavior in which untrusted, tenant-controlled, customer-managed, externally provisioned, CI-controlled, sandboxed, malware-analysis, or high-risk guest workloads may influence host-side KVM execution, trigger virtualization fault behavior, affect compute-node stability, or create uncertainty around the integrity of the virtualization boundary. The durable enterprise risk is broader than a single CVE identifier, vulnerable-kernel finding, public proof-of-concept, scanner result, crash string, or kernel package state because the business concern is whether guest-side virtualization activity can align with host-level KVM instability, host artifact access, storage access, backup access, identity access, control-plane interaction, cross-tenant exposure, or lateral movement from the affected compute host.

·        This is not only a vulnerable-kernel, scanner, public-PoC, crash-log, nested-virtualization, guest-root, single-host-reboot, package-version, or IOC-only model.

·        The core threat behavior is movement from guest-controlled or guest-influenced virtualization activity into host-side KVM instability, compute-node failure, host artifact access, VM disk or snapshot exposure, memory artifact exposure, storage access, backup access, credential exposure, identity access, orchestration access, control-plane interaction, tenant-boundary compromise, or lateral movement from the virtualization host.

·        Public cloud, private cloud, hosting-provider, OpenStack-style, Kubernetes virtualization, self-managed KVM cloud, CI runner, sandbox, malware-analysis, developer lab, and multi-tenant compute environments are the relevant exposure class when untrusted guests can exercise nested virtualization or low-level virtualization behavior.

·        The primary risk is reduced ability to determine whether KVM instability remained routine host failure, approved kernel testing, CI behavior, sandbox activity, maintenance, patching, live migration, evacuation, failover, or hardware instability, or crossed into guest-to-host boundary compromise.

·        Host kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent records, VM placement records, tenant mapping, crash dumps, storage logs, backup logs, identity logs, orchestration records, network telemetry, and change-management records may be incomplete or difficult to reconcile during active investigation.

·        The behavior can create uncertainty around tenant separation, compute-host trust, storage and backup integrity, credential exposure, control-plane resilience, regulated workload exposure, customer confidence, cyber-insurance posture, legal exposure, and business continuity.

·        Public reporting, proof-of-concept availability, vulnerable-kernel awareness, and related CVE metadata should support urgency and prioritization, but they should not narrow the report into an actor-only, IOC-only, scanner-only, crash-only, exploit-string-only, or single-CVE-only report.

S11 — Threat Classification and Type

Threat Type

KVM guest-to-host escape and multi-tenant virtualization boundary compromise risk.

Threat Sub-Type

Nested virtualization exposure, guest-controlled virtualization boundary stress, host-side KVM instability, KVM memory-management fault behavior, shadow paging fault behavior, reverse-map handling fault behavior, compute-node failure, guest-linked host crash behavior, VM artifact exposure, snapshot exposure, memory artifact exposure, cloud-init or metadata exposure, libvirt and QEMU artifact exposure, storage access, backup access, credential exposure, identity service access, orchestration access, management-plane access, cross-tenant exposure, host-originated outbound communication, lateral movement from the virtualization host, and multi-host compute-pool compromise risk.

Operational Classification

Virtualization boundary compromise, compute-host trust failure, tenant-separation exposure, and post-fault infrastructure expansion pathway.

Primary Function

Abuse or attempt to abuse guest-controlled virtualization behavior, nested virtualization exposure, privileged guest activity, low-level memory-management behavior, or repeated VM lifecycle activity to move from a guest workload into host-side KVM instability, compute-node failure, host artifact access, storage access, backup access, credential exposure, control-plane interaction, tenant-boundary compromise, outbound communication, or lateral movement from the virtualization host, creating uncertainty around compute integrity, tenant separation, storage trust, host containment, and post-remediation assurance.

S12 — Campaign or Activity Overview

Figure 2

KVM guest-to-host escape and multi-tenant virtualization boundary compromise activity model showing untrusted guest placement, nested virtualization exposure, guest-side privileged virtualization activity, host-side KVM instability, compute-node failure, VM artifact exposure, storage and backup access, credential exposure, control-plane interaction, cross-tenant exposure, and post-remediation trust validation.

This report assesses KVM guest-to-host escape and comparable virtualization boundary compromise as a durable behavior class rather than a single product advisory, scanner wave, exploit string, public proof-of-concept, actor cluster, kernel package finding, or crash event. The activity pattern involves adversaries, researchers, automated exploit infrastructure, tenant-controlled workloads, or high-risk guest environments exercising privileged virtualization behavior that may align with KVM host instability, compute-node failure, host fault telemetry, VM placement anomalies, storage access, backup access, identity access, orchestration access, rare outbound communication, or tenant-boundary exposure.

·        The activity is best understood as a compute trust, tenant-separation, virtualization-boundary, storage exposure, credential exposure, and control-plane resilience threat rather than a routine host crash, generic kernel warning, isolated nested virtualization event, or standard vulnerability-management issue.

·        Adversaries may target KVM environments supporting public cloud services, private cloud platforms, hosting-provider infrastructure, OpenStack compute nodes, Kubernetes virtualization, CI runners, sandbox hosts, malware-analysis environments, developer labs, customer-managed workloads, regulated workloads, or high-risk tenant workloads.

·        The behavior may involve guest-side nested hypervisor activity, nested VM creation, repeated nested VM lifecycle changes, privileged virtualization tooling, virtualization-extension use, low-level memory-management behavior, repeated VM state transitions, or workload patterns that precede host instability.

·        The activity may remain limited to exposure validation, exploit-attempt behavior, guest-side virtualization testing, failed boundary-stress attempts, host instability, kernel warnings, panics, oops events, soft lockups, watchdog events, compute-node resets, or automated recovery, or it may progress into host artifact access, VM disk access, snapshot access, memory artifact access, metadata access, storage access, backup access, credential exposure, outbound communication, control-plane interaction, or tenant-boundary compromise.

·        The activity becomes highest risk when suspicious host instability affects compute infrastructure that supports multi-tenant workloads, regulated workloads, customer-managed guests, partner workloads, shared storage, backup repositories, identity integrations, orchestration systems, management networks, or environments where multiple downstream services depend on the same compute layer.

·        Actor names, exploit-attempt reporting, CVE references, public proof-of-concept references, scanner fingerprints, vulnerable-kernel state, or crash signatures may increase urgency, but they should enrich the report rather than replace local behavior-led evidence of guest activity, host-fault behavior, placement context, post-fault access, control-plane interaction, or tenant impact.

S13 — Targets and Exposure Surface

The exposure surface includes x86 KVM compute hosts, Linux KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, self-managed KVM cloud hosts, Kubernetes virtualization hosts, CI KVM runners, sandbox KVM hosts, malware-analysis virtualization hosts, developer lab hosts, and multi-tenant virtualization hosts where untrusted or high-risk guest workloads can exercise nested virtualization or low-level virtualization behavior. It also includes nested virtualization settings, kernel version and reboot state, KVM modules, QEMU and libvirt services, virtqemud services, compute agents, storage agents, backup agents, orchestration agents, VM placement records, tenant ownership records, VM disks, snapshots, memory artifacts, metadata files, cloud-init data, libvirt and QEMU artifacts, host logs, crash dumps, storage connectors, backup repositories, identity services, metadata services, orchestration APIs, migration networks, management networks, tenant networks, and monitoring or logging systems connected to the compute layer.

·        x86 KVM hosts where nested virtualization is enabled for untrusted, tenant-controlled, customer-managed, externally provisioned, partner-managed, CI-controlled, sandboxed, malware-analysis, or high-risk guest workloads.

·        Public cloud, private cloud, hosting-provider, OpenStack-style, Kubernetes virtualization, self-managed KVM cloud, CI, sandbox, malware-analysis, developer lab, staging, production, and multi-tenant compute environments.

·        Guest workloads capable of nested hypervisor activity, nested VM lifecycle manipulation, privileged virtualization tooling, virtualization-extension use, low-level memory-management behavior, repeated VM state transitions, fuzzing activity, kernel testing, or virtualization test-harness behavior.

·        Host-side KVM, QEMU, libvirt, virtqemud, compute-agent, storage-agent, backup-agent, monitoring-agent, migration-service, metadata-service, and orchestration-service components that may expose host-side behavior after guest-linked instability.

·        VM artifacts, including VM disks, snapshots, memory dumps, guest configuration files, metadata files, cloud-init data, image repositories, backup archives, libvirt artifacts, QEMU artifacts, host logs, crash dumps, diagnostic files, and temporary staging paths.

·        Credential and trust material, including SSH keys, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, API tokens, cloud-init secrets, deployment credentials, and reusable administrative credentials exposed to the compute host.

·        Control-plane and infrastructure dependencies, including OpenStack control-plane services, Kubernetes virtualization services, orchestration APIs, identity services, metadata services, storage backends, backup repositories, image repositories, snapshot repositories, migration networks, monitoring services, logging services, tenant networks, and management networks.

·        Network and outbound communication paths from compute hosts, including DNS, proxy, firewall, NDR, NetFlow, VPC flow, data-center flow, host network telemetry, SSH, SMB, NFS, object storage, raw-IP communication, tunneling, file-transfer behavior, update paths, monitoring paths, logging paths, migration paths, metadata access, and command-and-control-like communication.

·        Environments with incomplete KVM inventory, unknown nested virtualization state, weak guest trust classification, incomplete VM placement history, weak tenant mapping, missing crash dumps, rotated host logs, limited storage attribution, weak backup visibility, incomplete control-plane records, poor outbound monitoring, or insufficient post-fault host review.

S14 — Sectors / Countries Affected

Sectors Affected

·        Cloud service providers, hosting providers, managed service providers, colocation providers, telecommunications providers, SaaS providers, platform engineering organizations, and technology companies operating multi-tenant or customer-managed KVM compute infrastructure.

·        Financial services, insurance, healthcare, life sciences, legal, professional services, public-sector, education, and regulated service organizations using private cloud, OpenStack-style platforms, Kubernetes virtualization, self-managed KVM systems, or hosted compute services for sensitive workloads.

·        Technology, software, DevOps, CI/CD, security research, malware-analysis, sandboxing, testing, and developer platform teams that run nested virtualization, untrusted guest workloads, kernel testing, low-level virtualization testing, or externally controlled build workloads.

·        Retail, e-commerce, transportation, logistics, manufacturing, energy, utilities, media, and business-services organizations using private cloud, managed hosting, virtualized infrastructure, or shared compute environments for customer-facing, partner-facing, operational, or regulated services.

·        Large enterprises, distributed organizations, hybrid cloud organizations, managed hosting customers, regional service providers, and organizations with shared storage, backup repositories, identity integrations, orchestration systems, or multi-region compute pools connected to KVM hosts.

·        Organizations using KVM hosts for tenant separation, virtual desktop infrastructure, application hosting, security testing, malware detonation, CI execution, sandboxing, developer labs, regulated workloads, partner workloads, or high-availability business services.

Countries Affected

·        Global.

·        Exposure is not limited to a single country or region because KVM, Linux virtualization, OpenStack-style compute, private cloud platforms, hosting-provider infrastructure, CI runners, sandbox systems, malware-analysis environments, and self-managed cloud deployments are used globally across enterprise, public-sector, technology, hosting, healthcare, finance, education, manufacturing, and service environments.

·        Countries with large populations of cloud providers, hosting providers, managed service providers, research labs, public-sector private cloud environments, regional service providers, CI infrastructure, and externally managed workloads may face elevated operational exposure.

·        Country-specific impact should be assessed by KVM exposure, nested virtualization state, untrusted guest placement, tenant sensitivity, host patch and reboot status, VM placement quality, storage and backup dependency, control-plane dependency, telemetry availability, regulatory obligations, and incident-response maturity rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate to High

Technical Sophistication

Adversaries require enough technical capability to understand KVM virtualization behavior, identify exposed or reachable guest environments, exercise nested virtualization or privileged guest behavior, and determine whether guest-side activity can affect host-side KVM stability, memory-management behavior, compute-node integrity, or post-fault access opportunities. Lower-complexity activity may involve commodity proof-of-concept execution, automated exploit replay, opportunistic testing against known vulnerable kernels, generic nested virtualization stress, scanner-driven validation, repeated VM lifecycle activity, or publicly described exploit primitives. Higher-capability activity may involve selective targeting of multi-tenant compute infrastructure, custom guest workloads, nested virtualization trigger refinement, low-level memory-management manipulation, crash-signature analysis, host recovery observation, VM placement abuse, post-fault host artifact access, storage or backup access, credential discovery, control-plane interaction, tenant-boundary exploration, cleanup, and attempts to blend with legitimate CI, sandbox, kernel testing, live migration, or incident-response activity.

Infrastructure Maturity

Moderate

Infrastructure maturity varies by activity pattern. Lower-maturity activity may rely on direct guest access, commodity exploit tooling, public proof-of-concept code, automated scanner infrastructure, disposable cloud systems, exposed CI workloads, or externally provisioned test guests. Higher-maturity activity may use staged guest images, controlled tenant accounts, rotating infrastructure, partner-managed access, CI pipelines, low-and-slow test patterns, workload migration timing, separate exploit and callback infrastructure, infrastructure designed to resemble research or validation activity, and post-fault behavior that blends with patching, host evacuation, kernel testing, sandbox analysis, malware detonation, backup operations, storage maintenance, or platform engineering workflows.

Operational Scale

Single exposed KVM host to multi-host compute-pool and tenant-boundary exposure

Operational scale ranges from suspicious activity against one nested-virtualization-enabled KVM host to broader enterprise or provider exposure when multiple compute hosts, guests, tenants, images, workload families, compute pools, shared storage systems, backup repositories, identity services, orchestration platforms, management networks, and dependent workloads are connected. Within one organization, scale can expand from a single guest-triggered host fault to host artifact access, VM disk or snapshot exposure, credential access, storage access, backup access, control-plane interaction, cross-tenant exposure, multi-host instability, and post-remediation trust validation.

Escalation Likelihood

Moderate to High

Escalation likelihood is moderate to high when suspicious guest-side virtualization behavior is followed by KVM host instability, repeated host faults, compute-node failure, host evacuation, host quarantine, service restarts, VM artifact access, storage access, backup access, metadata access, identity access, orchestration interaction, rare outbound communication, administrative changes, host configuration changes, cross-tenant access, or lateral movement from the compute host. Escalation likelihood increases when affected hosts support multi-tenant workloads, regulated workloads, customer-managed guests, externally provisioned guests, CI-controlled workloads, sandbox environments, malware-analysis systems, shared storage, backup repositories, identity integrations, orchestration systems, management networks, high-availability compute pools, incomplete logs, or limited host telemetry.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High

Targeting Drivers

·        KVM compute hosts can sit beneath public cloud, private cloud, hosting-provider, OpenStack-style, Kubernetes virtualization, CI, sandbox, malware-analysis, developer lab, and multi-tenant environments where a successful boundary failure may expose multiple tenants or downstream services.

·        Nested virtualization creates attractive targeting conditions when untrusted guests can exercise low-level virtualization behavior, nested hypervisor activity, VM lifecycle manipulation, memory-management paths, or virtualization-extension use.

·        Public exploit knowledge, proof-of-concept availability, vulnerable-kernel awareness, and repeatable virtualization fault patterns can lower the barrier for opportunistic adversaries once guest-to-host behavior becomes public.

·        Host-side KVM instability can provide an operational signal that adversaries may use to refine exploit attempts, test reliability, identify affected kernels, or determine whether a guest workload is influencing the host boundary.

·        Successful host-level access can provide a path to VM artifacts, snapshots, memory dumps, metadata files, cloud-init data, storage credentials, backup credentials, orchestration credentials, identity services, control-plane services, tenant networks, and management networks.

·        Attackers benefit from environments where KVM inventory, nested virtualization state, guest trust classification, VM placement records, tenant mapping, host logs, crash dumps, storage logs, backup logs, identity logs, outbound telemetry, and change-management context are incomplete.

·        Normal KVM administration, patching, reboot activity, live migration, host evacuation, kernel testing, CI execution, sandboxing, malware analysis, backup operations, storage maintenance, vendor support, and incident-response cleanup can make attacker-driven activity harder to classify without strong baselines.

·        Targeting probability should be assessed through KVM exposure, nested virtualization state, untrusted guest placement, affected kernel and reboot status, compute-pool sensitivity, tenant sensitivity, storage and backup dependency, control-plane dependency, telemetry maturity, and local evidence of guest-to-host-to-impact behavior rather than actor names, crash labels, or scanner terms alone.

Most Likely Targets

·        Nested-virtualization-enabled x86 KVM hosts running untrusted, tenant-controlled, customer-managed, externally provisioned, partner-managed, CI-controlled, sandboxed, malware-analysis, or high-risk guest workloads.

·        Public cloud, private cloud, hosting-provider, OpenStack-style, Kubernetes virtualization, self-managed KVM cloud, CI runner, sandbox, malware-analysis, developer lab, staging, production, and multi-tenant compute environments.

·        KVM hosts with incomplete kernel patching, missing reboot validation, unclear livepatch effectiveness, limited host logs, unavailable crash dumps, weak VM placement history, incomplete tenant mapping, or poor nested virtualization inventory.

·        Guest workloads capable of nested hypervisor execution, nested VM lifecycle manipulation, privileged virtualization tooling, low-level memory-management activity, repeated VM state transitions, kernel testing, fuzzing, or virtualization test-harness behavior.

·        Compute hosts connected to shared storage, backup repositories, image repositories, snapshot repositories, metadata services, identity providers, orchestration APIs, monitoring systems, logging systems, migration networks, tenant networks, and management networks.

·        Organizations with self-managed KVM infrastructure, hosted KVM platforms, high-value tenant workloads, regulated workloads, customer-managed guest environments, shared compute pools, weak placement governance, limited outbound monitoring, reused credentials, or incomplete post-fault investigation capability.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Exposure Identification

The adversary identifies KVM compute environments, nested-virtualization-enabled hosts, tenant-controlled guests, CI runners, sandbox systems, or high-risk guest workloads where guest-side virtualization behavior may affect host integrity.

·        T1595 — Active Scanning.

Stage 2 — Guest-to-Host Escape Attempt

The adversary uses guest-side privileged virtualization behavior, nested virtualization activity, or low-level virtualization behavior to attempt movement from guest context toward the KVM host boundary.

·        T1068 — Exploitation for Privilege Escalation.

·        T1611 — Escape to Host.

Stage 3 — Host Instability and Boundary Stress

The adversary’s guest-side activity aligns with KVM host instability, kernel fault behavior, compute-node failure, host evacuation, service restart behavior, or other virtualization-boundary stress signals.

·        T1499 — Endpoint Denial of Service.

Stage 4 — Host Access and Artifact Exposure

The adversary uses suspected or achieved host-level access to reach VM disks, snapshots, memory artifacts, guest configuration files, metadata files, cloud-init data, host logs, crash artifacts, credentials, or other trust material exposed to compute-host context.

·        T1005 — Data from Local System.

·        T1552 — Unsecured Credentials.

Stage 5 — Infrastructure Expansion

The adversary uses host-level context, exposed credentials, or compute-host trust relationships to reach storage, backup, metadata, identity, orchestration, management, tenant, or sibling compute infrastructure.

·        T1021 — Remote Services.

·        T1071 — Application Layer Protocol.

S18 — Attack Path Narrative (Signal-Aligned Execution Flow)

KVM guest-to-host escape and multi-tenant virtualization boundary compromise begins when adversaries identify KVM compute environments where untrusted, tenant-controlled, customer-managed, externally provisioned, CI-controlled, sandboxed, malware-analysis, or high-risk guest workloads can exercise nested virtualization or low-level virtualization behavior. The attacker’s objective is to move from guest-side virtualization activity into host-side KVM instability, compute-node failure, host artifact access, credential exposure, storage or backup access, control-plane interaction, tenant-boundary exposure, outbound communication, or lateral movement from compute-host context. The core attack path is defined by exposure identification, guest-to-host escape attempts, host instability and boundary stress, host artifact exposure, and infrastructure expansion, with post-remediation trust validation treated as the containment and assurance phase. Broader cloud compromise, ransomware deployment, enterprise identity compromise, destructive activity, or large-scale data theft should be treated as conditional amplification unless supporting telemetry confirms those behaviors.

Stage 1: Exposure Identification

The adversary identifies KVM compute environments, nested-virtualization-enabled hosts, tenant-controlled guests, CI runners, sandbox systems, malware-analysis systems, or high-risk guest workloads where guest-side virtualization behavior may affect host integrity. This may involve internet-facing workload discovery, tenant-controlled workload access, CI job access, sandbox or lab access, exposed guest provisioning paths, vulnerable-kernel awareness, nested virtualization discovery, guest image selection, compute-pool targeting, or identification of hosts that run untrusted workloads. This stage is not sufficient by itself to establish compromise because KVM environments may legitimately host CI, sandbox, testing, malware-analysis, developer, or customer-managed workloads. It becomes material when exposure activity aligns with nested virtualization exposure, untrusted guest placement, vulnerable or unvalidated kernel state, guest-side virtualization behavior, host-side KVM instability, or later post-fault infrastructure activity.

Stage 2: Guest-to-Host Escape Attempt

The adversary uses guest-side privileged virtualization behavior, nested virtualization activity, low-level virtualization behavior, repeated VM lifecycle activity, or workload behavior intended to stress the KVM host boundary. Observable evidence may include nested hypervisor execution, nested VM creation, repeated nested VM lifecycle changes, privileged virtualization tooling, virtualization-extension use, low-level memory-management behavior, abnormal VM state transitions, virtualization test-harness behavior, or guest activity that precedes host-side KVM instability. This stage changes the event from routine workload execution into possible boundary exploitation when guest-side behavior aligns with KVM host warnings, MMU fault behavior, shadow paging fault behavior, reverse-map handling issues, kernel oops events, soft lockups, watchdog events, panics, compute-node resets, or repeated instability tied to a guest, tenant, image, workload family, or compute pool.

Stage 3: Host Instability and Boundary Stress

The adversary’s guest-side activity aligns with KVM host instability, kernel fault behavior, compute-node failure, host evacuation, service restart behavior, or other virtualization-boundary stress signals. Observable evidence may include KVM warnings, kernel oops events, panics, soft lockups, watchdog events, kernel crashes, unexplained host reboots, compute-node failures, KVM MMU fault patterns, nested virtualization fault behavior, shadow paging fault behavior, reverse-map handling issues, unexpected role handling, invalid page state, memory corruption indicators, QEMU instability, libvirt instability, virtqemud instability, compute-agent restarts, host quarantine, live migration, failed migration, emergency host disablement, or workload evacuation. This stage is materially significant because it connects guest-side virtualization activity to host-side boundary uncertainty and may require the organization to preserve volatile evidence, reconstruct VM placement, validate tenant ownership, and determine whether the host remained trustworthy.

Stage 4: Host Access and Artifact Exposure

The adversary uses suspected or achieved host-level access to reach VM disks, snapshots, memory artifacts, guest configuration files, metadata files, cloud-init data, libvirt artifacts, QEMU artifacts, host logs, crash artifacts, credentials, or other trust material exposed to compute-host context. Observable evidence may include access to VM disk images, snapshot repositories, memory dumps, guest configuration files, metadata paths, cloud-init data, image repositories, backup archives, host logs, crash dumps, SSH keys, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, deployment credentials, or temporary staging paths. This stage increases business risk because host-level artifact access can extend the incident beyond instability and into tenant exposure, credential exposure, storage trust, backup integrity, and cross-workload confidentiality.

Stage 5: Infrastructure Expansion

The adversary uses host-level context, exposed credentials, or compute-host trust relationships to reach storage, backup, metadata, identity, orchestration, management, tenant, or sibling compute infrastructure. Observable evidence may include compute-host access to storage backends, backup repositories, image repositories, snapshot repositories, metadata services, identity providers, orchestration APIs, cloud control-plane services, OpenStack services, Kubernetes virtualization services, migration services, monitoring systems, logging systems, management networks, tenant networks, sibling compute hosts, or external destinations. This stage becomes high priority when infrastructure access follows suspicious KVM instability and aligns by compute node, guest, tenant, image, workload, compute pool, host-fault window, storage object, destination, administrative action, or bounded time window.

Stage 6: Post-Remediation Trust Validation and Containment Risk

The adversary may retain access or leave uncertainty through altered host state, exposed credentials, accessed VM artifacts, storage or backup access, control-plane interaction, outbound communication, host configuration drift, incomplete reboot validation, incomplete livepatch validation, deleted crash artifacts, deleted logs, tenant-boundary uncertainty, or repeated compute-node instability after patching or apparent remediation. Observable evidence may include post-remediation host faults, continued rare egress, unexplained host configuration changes, repeated service restarts, unexpected storage or backup access, identity or metadata access, suspicious orchestration actions, VM placement anomalies, incomplete log retention, missing crash dumps, recurring instability tied to the same tenant or image, or post-patch activity that does not match approved maintenance, incident-response, kernel-testing, live-migration, failover, CI, sandbox, or platform-engineering records. This stage becomes high priority when activity continues after patching, reboot validation, nested virtualization restriction, host quarantine, workload evacuation, credential rotation, storage review, or control-plane validation.

S19 — Attack Chain Risk Amplification Summary

KVM guest-to-host escape and multi-tenant virtualization boundary compromise amplifies risk because it targets infrastructure that may concentrate tenant separation, workload execution, compute-host trust, storage connectivity, backup access, identity paths, metadata access, orchestration dependencies, migration services, monitoring systems, management networks, and high-availability infrastructure. The chain becomes materially more dangerous when suspicious guest-side virtualization behavior is followed by host-side KVM instability, compute-node failure, VM artifact access, credential exposure, storage access, backup access, control-plane interaction, outbound communication, cross-tenant exposure, or activity that continues after remediation.

·        Nested virtualization exposure increases risk because untrusted or high-risk guest workloads may exercise low-level virtualization behavior that reaches sensitive KVM execution paths.

·        Untrusted guest placement increases risk when tenant-controlled, customer-managed, externally provisioned, CI-controlled, sandboxed, malware-analysis, or high-risk workloads run on compute hosts that also support sensitive tenants or shared infrastructure dependencies.

·        Host-side KVM instability increases concern because kernel oops events, panics, soft lockups, watchdog events, compute-node resets, KVM MMU fault behavior, shadow paging fault behavior, or reverse-map handling issues may indicate boundary stress rather than routine host failure.

·        Repeated tenant-linked or image-linked faults amplify risk when the same guest, tenant, image, workload family, compute pool, or automation pattern is associated with recurring host instability.

·        VM placement uncertainty increases business exposure because the organization may not be able to quickly determine which guests, tenants, workloads, images, storage paths, and compute pools were affected.

·        Host artifact access amplifies impact when exposed material includes VM disks, snapshots, memory dumps, guest configuration files, metadata files, cloud-init data, libvirt artifacts, QEMU artifacts, host logs, crash dumps, image repositories, or tenant-related files.

·        Credential exposure increases risk when compute-host context provides access to SSH keys, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, deployment credentials, or reusable administrative credentials.

·        Storage and backup access increase scope because affected compute hosts may have trusted paths into storage backends, backup repositories, image repositories, snapshot repositories, migration paths, or recovery infrastructure.

·        Control-plane interaction increases risk when host-level access, exposed credentials, or compute-host trust relationships reach OpenStack services, Kubernetes virtualization services, orchestration APIs, identity services, metadata services, migration services, monitoring systems, logging systems, or management-plane infrastructure.

·        Cross-tenant exposure becomes a high-priority business concern when host-level access may affect sibling guests, adjacent tenants, shared storage, image repositories, backup systems, tenant networks, or management networks.

·        Rare outbound communication increases concern when a compute host initiates unusual DNS, HTTPS, SSH, SMB, NFS, object storage, raw-IP, tunneling, file-transfer, callback-like, tool-retrieval, or command-and-control-like behavior after suspicious KVM instability.

·        Post-remediation activity becomes a high-priority containment signal when host faults, rare egress, storage access, backup access, credential use, control-plane activity, host configuration drift, tenant-boundary uncertainty, or repeated instability continues after patching, reboot validation, nested virtualization restriction, quarantine, or credential rotation.

·        Business exposure increases when affected hosts support regulated workloads, customer-managed tenants, partner workloads, high-value workloads, CI execution, sandboxed analysis, malware detonation, shared storage, backup repositories, identity services, or high-availability business services.

·        Incomplete host logs, KVM logs, crash dumps, VM placement history, tenant mapping, storage logs, backup logs, identity logs, metadata records, orchestration logs, endpoint telemetry, network telemetry, configuration baselines, or change-management records can force broader investigation because the organization cannot quickly prove whether host or tenant exposure occurred.

·        Response burden increases because teams must validate KVM asset exposure, nested virtualization state, kernel patch and reboot status, guest placement, tenant ownership, host-fault evidence, compute-node recovery actions, VM artifact access, storage and backup access, credential exposure, control-plane interaction, outbound communication, legal obligations, and executive assurance.

S20 — Tactics, Techniques, and Procedures

Figure 3

KVM guest-to-host escape and multi-tenant virtualization boundary compromise attack-chain model showing exposure identification, guest-to-host escape attempt, host instability and boundary stress, host artifact exposure, infrastructure expansion, and post-remediation trust validation.

Exposure Identification

Adversaries may identify KVM compute environments, nested-virtualization-enabled hosts, tenant-controlled guests, CI runners, sandbox systems, malware-analysis systems, developer labs, customer-managed workloads, high-risk guest images, or compute pools where guest-side virtualization behavior may affect host integrity. This behavior becomes risk-relevant when exposed or reachable guest environments align with nested virtualization exposure, vulnerable or unvalidated kernel state, untrusted tenant placement, weak compute-pool governance, incomplete placement records, or later host-side instability.

Guest-to-Host Escape Attempt

Adversaries may use guest-side privileged virtualization behavior, nested virtualization activity, low-level virtualization behavior, repeated VM lifecycle activity, or workload behavior intended to stress the KVM host boundary. This behavior becomes high priority when nested hypervisor activity, nested VM lifecycle changes, virtualization-extension use, memory-management stress, or abnormal VM state transitions align with KVM host warnings, kernel oops events, panics, soft lockups, watchdog events, compute-node resets, or repeated instability tied to the same guest, tenant, image, workload, or compute pool.

Host Instability and Boundary Stress

Adversaries may trigger or align with KVM host instability, kernel fault behavior, compute-node failure, host evacuation, host quarantine, service restart behavior, or virtualization-boundary stress signals. This behavior becomes materially significant when KVM MMU fault patterns, shadow paging fault behavior, reverse-map handling issues, nested virtualization faults, unexpected role handling, invalid page state, memory corruption indicators, kernel crashes, QEMU instability, libvirt instability, virtqemud instability, compute-agent restarts, or emergency recovery actions occur near suspicious guest-side activity.

Host Artifact and Credential Exposure

Adversaries may use suspected or achieved host-level access to access VM disks, snapshots, memory artifacts, guest configuration files, metadata files, cloud-init data, image repositories, backup archives, libvirt artifacts, QEMU artifacts, host logs, crash dumps, SSH keys, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, deployment credentials, or other trust material exposed to compute-host context. This behavior becomes materially significant when sensitive artifact access follows suspicious KVM instability and cannot be tied to approved backup, storage maintenance, migration, monitoring, kernel testing, CI, sandboxing, malware-analysis, vendor-support, or incident-response activity.

Infrastructure Expansion

Adversaries may use host-level context, exposed credentials, or compute-host trust relationships to reach storage backends, backup repositories, image repositories, snapshot repositories, metadata services, identity providers, orchestration APIs, cloud control-plane services, OpenStack services, Kubernetes virtualization services, migration services, monitoring systems, logging systems, management networks, tenant networks, sibling compute hosts, or external infrastructure. This behavior becomes high risk when access follows suspicious KVM instability, reaches sensitive dependencies, crosses tenant or management boundaries, uses rare destinations, or cannot be tied to approved platform, storage, backup, monitoring, migration, failover, incident-response, or maintenance workflows.

Operational Blending With Virtualization Administration and Support Workflows

Adversaries may blend malicious activity into normal KVM administration, kernel patching, reboot validation, live migration, host evacuation, failover testing, kernel testing, CI execution, sandbox activity, malware-analysis workflows, backup jobs, storage maintenance, monitoring activity, vendor support, emergency remediation, or incident-response cleanup. This blending is effective because virtualization environments routinely generate host faults, service restarts, VM movement, storage activity, backup access, metadata access, orchestration actions, and management-plane events. Detection and response require correlating guest activity, host-fault behavior, VM placement, tenant ownership, post-fault artifact access, network activity, storage access, control-plane interaction, and approved operational context rather than relying on one artifact in isolation.

Post-Remediation Access and Trust Validation Failure

Adversaries may continue accessing compute-host context, exposed credentials, VM artifacts, storage paths, backup systems, metadata services, identity services, orchestration services, management networks, tenant networks, external infrastructure, or altered host state after patching, reboot validation, nested virtualization restriction, host quarantine, workload evacuation, credential rotation, storage review, or control-plane validation. This behavior becomes high priority when post-remediation activity includes recurring host instability, rare egress, unexplained configuration drift, storage access, backup access, credential use, control-plane activity, deleted logs, missing crash artifacts, VM placement anomalies, or tenant-boundary uncertainty that cannot be tied to approved business, platform, maintenance, or incident-response activity.

S20A — Adversary Tradecraft Summary

KVM guest-to-host escape and multi-tenant virtualization boundary compromise targets the trust relationship between guest workloads, host-side KVM execution, compute-node stability, VM placement, tenant separation, storage access, backup access, credential exposure, control-plane interaction, management infrastructure, outbound communication, and post-remediation assurance. The adversary objective is to convert guest-side virtualization behavior into host-level access, host instability, VM artifact exposure, storage or backup access, credential exposure, control-plane reach, cross-tenant exposure, infrastructure expansion, or containment uncertainty while blending into normal virtualization administration, kernel testing, CI, sandboxing, live migration, host recovery, and platform-engineering workflows.

·        The core tradecraft pattern is suspicious guest-side virtualization behavior followed by KVM host instability, compute-node failure, host artifact access, credential exposure, storage access, backup access, control-plane interaction, rare outbound communication, cross-tenant exposure, or post-remediation activity.

·        The behavior is not dependent on a single CVE name, exploit string, actor name, scanner fingerprint, public proof-of-concept, vulnerable-kernel finding, package version, crash string, host reboot, nested virtualization setting, guest root condition, or static IOC.

·        Adversaries may use nested virtualization activity, guest-side privileged tooling, repeated VM lifecycle manipulation, low-level virtualization behavior, kernel testing patterns, staged guest images, CI-controlled workloads, sandboxed workloads, exploit replay, host-fault observation, VM placement awareness, post-fault artifact access, credential discovery, rare egress, and infrastructure expansion from compute-host context.

·        The strongest operational risk occurs when suspicious activity affects KVM hosts that support multi-tenant workloads, regulated workloads, customer-managed guests, partner workloads, CI execution, sandboxed analysis, malware detonation, shared storage, backup repositories, identity integrations, orchestration systems, management networks, or high-availability business services.

·        Detection requires visibility into the guest activity that begins the chain and the host-fault, placement, tenant, artifact, storage, backup, identity, orchestration, network, and post-remediation evidence that confirms or disproves impact.

·        Response requires treating suspected KVM guest-to-host escape as a compute trust, tenant-separation, storage exposure, credential exposure, control-plane resilience, and containment-validation incident, not a routine host crash, isolated kernel warning, single vulnerable-kernel finding, or patch-management task.

·        The behavior remains durable because the adversary objective is to convert guest-side virtualization control into host-level trust failure, VM artifact exposure, credential exposure, storage or backup access, control-plane interaction, cross-tenant exposure, or containment uncertainty regardless of the specific kernel version, exploit variant, guest image, scanner label, source infrastructure, or campaign branding used.

S21 — Detection Strategy Overview

Detection Philosophy

Detect KVM guest-to-host escape, host kernel exposure, and multi-tenant virtualization boundary compromise through correlated behavior across guest activity, host KVM telemetry, nested virtualization configuration, compute-node instability, control-plane events, VM placement, storage access, network activity, and post-fault host behavior, not through CVE names, vulnerable-kernel status, proof-of-concept availability, scanner findings, exploit nicknames, or isolated crash events alone. The durable detection model is untrusted guest control or guest-side privileged virtualization activity followed by host-side KVM instability, compute-node failure, host-level artifact access, tenant-boundary exposure, control-plane interaction, storage access, credential exposure, or lateral movement from the affected virtualization host.

Primary Detection Anchors

·        Nested virtualization enabled on x86 KVM hosts that run untrusted, tenant-controlled, externally provisioned, customer-managed, CI-controlled, sandboxed, or high-risk guest workloads.

·        Guest-side privileged activity involving kernel module loading, nested hypervisor execution, virtualization-extension use, nested VM lifecycle manipulation, low-level memory-management behavior, or repeated VM state transitions.

·        Guest workloads that trigger or precede KVM host instability, kernel oops events, kernel panics, soft lockups, watchdog events, compute-node resets, hypervisor faults, or unexplained host failure.

·        Host-side KVM telemetry referencing MMU behavior, shadow paging, reverse-map handling, nested virtualization, memory corruption, unexpected role handling, invalid page reuse, or abnormal virtualization fault behavior.

·        Host instability concentrated around the same tenant, VM instance, guest image, compute pool, automation pattern, nested virtualization workload, or scheduling placement.

·        VM placement, migration, evacuation, or compute-node disablement activity that occurs shortly after suspicious guest-side virtualization behavior or KVM host instability.

·        Post-fault host activity involving VM disks, snapshots, memory artifacts, metadata paths, cloud-init data, libvirt/QEMU artifacts, host networking, storage connectors, backup repositories, orchestration agents, or management-plane services.

·        Host-originated outbound communication, internal service access, storage access, identity service access, backup access, metadata access, or control-plane traffic after suspicious KVM instability.

·        Unexpected administrative, orchestration, maintenance, logging, patching, host-isolation, or workload-migration actions near the suspected guest-to-host event.

·        Multiple KVM hosts showing similar instability, nested virtualization activity, guest scheduling patterns, host fault telemetry, or tenant-linked compute failures within a bounded time window.

Detection Prioritization Model

Prioritize activity where untrusted guest workloads can influence host-side KVM behavior and where host compromise would create cross-tenant, control-plane, storage, backup, identity, or management-platform exposure. Highest priority applies to public cloud, private cloud, hosting provider, OpenStack-style, Kubernetes virtualization, CI execution, malware-analysis, sandboxing, developer lab, and multi-tenant compute environments where nested virtualization is enabled or where guest workloads can exercise virtualization extensions. Treat vulnerable-kernel status, public proof-of-concept awareness, and nested virtualization exposure as urgency inputs, not compromise proof. Treat guest-side nested virtualization activity as high-risk only when it is unexpected, untrusted, not allowlisted, or temporally aligned with host-side KVM instability, compute-node failure, or post-fault host behavior.

Correlation Strategy (Strict Enforcement)

Do not promote a single nested virtualization event, vulnerable-kernel finding, public PoC reference, guest root condition, kernel module load, host reboot, compute-node crash, KVM log entry, scanner result, or cloud control-plane event to high-confidence compromise without correlation by host, guest, tenant, VM instance, image, compute pool, nested virtualization setting, KVM fault pattern, process context, placement history, migration event, storage object, destination, maintenance window, or bounded time window. High-confidence detection requires a sequence that connects guest-side privileged virtualization activity to host-side KVM instability, host kernel exposure, compute-node failure, host artifact access, control-plane interaction, credential exposure, storage access, tenant-boundary compromise, or lateral movement.

Telemetry Prioritization

Prioritize host-side KVM and compute-node telemetry because the reportable risk is a guest-controlled workload affecting host integrity. Guest telemetry is useful where available, but it should not be assumed in tenant-controlled or customer-managed environments. Control-plane telemetry is required to map affected guests to hosts, identify tenant ownership, reconstruct placement and migration history, and determine blast radius.

Detection Design Constraints

Avoid detection designs based only on CVE identifiers, exploit names, vulnerable-kernel status, public proof-of-concept availability, kernel package versions, scanner findings, guest root access, nested virtualization presence, isolated host crashes, single KVM log strings, single kernel warnings, or cloud control-plane events. Detection must remain useful across KVM guest-to-host escape variants that differ in memory-management primitive, nested virtualization trigger, CPU vendor exposure, exploit reliability, crash signature, host kernel version, guest workload type, telemetry depth, and post-exploitation sequence.

Baseline and Deployment Requirements

Baseline KVM host inventory, CPU architecture, nested virtualization configuration, kernel version, patch state, reboot completion, guest ownership, workload purpose, tenant trust level, compute pool membership, VM placement history, migration behavior, approved nested virtualization use cases, storage mappings, backup mappings, orchestration dependencies, management network access, and normal compute-node maintenance behavior. Validate host-to-guest, guest-to-tenant, host-to-storage, host-to-control-plane, and compute-pool-to-workload mappings before promoting correlation logic to alert mode.

Variant Resilience Requirements

Rules should remain effective for future KVM, hypervisor, nested virtualization, and guest-to-host escape variants that produce the same operational behavior: untrusted guest control, nested virtualization or hypervisor-adjacent activity, host-side KVM instability, compute-node failure, host kernel exposure, management-plane interaction, storage access, credential exposure, cross-tenant access, or lateral movement from the virtualization host.

Operational Detection Model

Run detections in exposure-validation mode first, confirm nested virtualization inventory, validate KVM host log collection, map VM placement and tenant ownership, tune approved nested virtualization use cases, verify crash and reboot telemetry, validate joins between guest activity and host events, confirm compute-node to control-plane mapping, and then promote high-confidence logic to alert mode. Use escalating confidence: exposed nested virtualization host, exposed host with untrusted guest workload, suspicious guest-side virtualization behavior, suspicious guest-side behavior plus KVM host instability, suspicious guest-side behavior plus compute-node failure, KVM instability plus repeated tenant-linked host failures, and KVM instability plus post-fault host, storage, control-plane, credential, or cross-tenant activity.

Explicit Non-Deployment Guardrails

·        Do not deploy vulnerable-kernel findings as compromise detections.

·        Do not claim confirmed guest-to-host escape from public PoC availability alone.

·        Do not claim confirmed compromise from nested virtualization being enabled by itself.

·        Do not claim confirmed compromise from guest root access alone.

·        Do not claim confirmed compromise from a single host reboot, kernel panic, oops event, soft lockup, or compute-node failure without guest, KVM, placement, or time-window correlation.

·        Do not classify approved CI, lab, sandbox, malware-analysis, developer, or kernel-testing workloads as suspicious unless they deviate from expected behavior or align with host-side instability.

·        Do not treat package installation as remediation unless reboot or livepatch effectiveness has been validated.

·        Do not rely on CVE naming as the primary detection anchor.

·        Do not deploy high-confidence alerts without guest-to-host, host-to-control-plane, host-to-storage, host-to-network, or host-to-tenant correlation.

S22 — Primary Detection Signals

Figure 4

Primary Detection Signals

·        Nested virtualization enabled on x86 KVM hosts that run untrusted, tenant-controlled, customer-managed, externally provisioned, CI-controlled, sandboxed, or high-risk guest workloads.

·        Guest workloads initiating nested hypervisor activity, nested VM creation, repeated nested VM lifecycle changes, kernel module loading, privileged virtualization tooling, or virtualization-extension use outside approved baselines.

·        Guest-side activity involving low-level virtualization state transitions, memory-management stress, nested paging behavior, or repeated operations that precede host-side KVM instability.

·        Host kernel logs showing KVM, MMU, shadow paging, reverse-map, nested virtualization, unexpected role, memory corruption, page fault, panic, oops, soft lockup, watchdog, or crash behavior near guest-side activity.

·        Compute-node failure, unexplained reboot, service crash, emergency host disablement, hypervisor instability, or host evacuation after suspicious guest-side virtualization behavior.

·        Repeated host instability tied to the same tenant, guest image, VM instance, workload family, compute pool, host group, or automation pipeline.

·        VM migration, evacuation, rescheduling, host quarantine, or compute-node maintenance actions that occur shortly after suspicious guest-side activity or host KVM faults.

·        Host-level access to VM disks, snapshots, memory artifacts, metadata files, cloud-init data, libvirt/QEMU artifacts, guest configuration files, host logs, storage paths, or orchestration agent files after KVM instability.

·        Host-originated network communication to management, storage, backup, identity, metadata, migration, monitoring, orchestration, tenant, or administrative services after suspicious KVM instability.

·        Administrative activity on virtualization hosts, compute pools, storage mappings, tenant networks, or orchestration systems that is temporally aligned with suspicious host instability.

·        Multiple KVM hosts or compute pools showing similar guest-linked instability, nested virtualization behavior, host faults, or post-fault network activity within a bounded time window.

Supporting Detection Signals

·        Guest workload changes that introduce nested virtualization tooling, kernel modules, hypervisors, emulator tooling, fuzzing tools, virtualization test harnesses, kernel development artifacts, or low-level CPU virtualization access.

·        Guest administrative activity from unusual users, automation accounts, source paths, time windows, images, tenants, or build pipelines before host-side KVM instability.

·        Host kernel version, patch state, reboot state, livepatch state, and mitigation status indicating exposure during the suspicious window.

·        High CPU, memory, VM-exit, nested virtualization, or hypervisor service stress around affected compute hosts.

·        VM placement history showing the same guest, tenant, image, or workload family moving across hosts that later show instability.

·        Control-plane logs showing host evacuation, live migration, failed migration, host disablement, compute service restart, emergency maintenance, or workload rescheduling after a KVM fault.

·        Storage, backup, metadata, identity, or orchestration logs showing access from a compute host shortly after suspicious KVM instability.

·        Host process telemetry showing unusual QEMU, libvirt, virtqemud, compute-agent, storage-agent, backup-agent, or orchestration-agent behavior after a host fault.

·        SIEM, ITSM, change-management, patch-management, and incident-response records confirming no approved host maintenance, kernel testing, failover testing, or vulnerability validation occurred during the suspicious window.

·        External reporting, proof-of-concept awareness, and vulnerable-kernel inventory used as prioritization context rather than detection proof.

Exploit Attempt and Instability Signals

·        Guest-side nested virtualization activity on exposed x86 KVM hosts where nested virtualization is not expected for the tenant, image, workload, or compute pool.

·        Guest-side kernel module loading, privileged execution, nested hypervisor execution, repeated nested guest creation, or virtualization test behavior immediately before host instability.

·        KVM host kernel warnings, oops events, panics, soft lockups, watchdog events, kernel crashes, unexplained reboots, or compute-node failures near guest-side virtualization activity.

·        KVM logs referencing MMU behavior, shadow paging, nested virtualization, reverse-map handling, invalid page state, unexpected role handling, or memory-management faults.

·        Repeated host faults when a specific guest is launched, restarted, migrated, resumed, or scheduled.

·        Compute-node instability that follows guest activity rather than patching, approved maintenance, workload migration, capacity pressure, hardware failure, or administrative change.

·        Host instability occurring after public exploit-attempt testing, internal validation, scanner activity, or tenant-side low-level virtualization behavior.

·        Crash dump, kernel trace, host log, or virtualization service evidence showing KVM failure patterns within the suspicious activity window.

·        Failed-to-recover compute services, repeated virtualization service restarts, or host quarantine events following guest-side nested virtualization activity.

·        Public PoC-like activity treated as exploit-attempt evidence only when locally observable through guest behavior, host KVM telemetry, crash artifacts, or control-plane correlation.

Outbound Communication Signals

·        DNS, proxy, firewall, NDR, EDR, NetFlow, VPC flow, data-center flow, or host network activity from KVM compute hosts to rare, newly seen, suspicious, unknown, unapproved, or geographically unusual destinations after suspicious host instability.

·        Compute-host connections to identity, metadata, storage, backup, orchestration, migration, monitoring, logging, database, tenant, or management services after KVM faults.

·        Host-originated outbound HTTPS, DNS, SSH, SMB, NFS, object storage, raw-IP, tunneling, file-transfer, paste-site, or command-and-control-like communication after suspected guest-triggered host fault behavior.

·        Network activity from compute hosts inconsistent with approved update, monitoring, storage, backup, orchestration, migration, metadata, logging, NTP, DNS, or management behavior.

·        Repeated callbacks from the same compute host after suspicious KVM instability.

·        Unusual east-west traffic from a compute node to tenant networks, sibling compute hosts, management networks, storage networks, backup systems, or cloud control-plane services.

·        Outbound activity temporally aligned with access to VM artifacts, storage paths, metadata, credentials, orchestration files, or host configuration data.

Persistence and Post-Exploitation Signals (Conditional)

·        New or modified host users, SSH keys, scheduled tasks, systemd units, cron entries, kernel modules, startup scripts, service files, management agents, monitoring agents, or virtualization host configuration after suspicious KVM instability.

·        Modified QEMU, libvirt, virtqemud, compute-agent, storage-agent, backup-agent, cloud-agent, or orchestration-agent configuration near the suspicious window.

·        Access to VM disk images, snapshots, memory dumps, guest configuration files, metadata files, cloud-init data, tenant secrets, host logs, backup paths, or storage credentials after host instability.

·        Creation, modification, deletion, compression, staging, or exfiltration of VM artifacts, host logs, crash dumps, configuration files, tenant metadata, or credential-bearing files.

·        Host log clearing, crash dump deletion, timestamp anomalies, service restarts, package changes, unexpected host reboot, or configuration rollback after suspected guest-triggered instability.

·        New access paths from a compute host into management, storage, backup, identity, orchestration, monitoring, migration, or tenant environments.

·        Changes to host firewall rules, bridge interfaces, tap devices, virtual networking, storage mounts, migration settings, or management access restrictions after suspicious host behavior.

·        Administrative actions that appear to normalize or conceal a host fault without an approved maintenance, incident-response, or patch-validation record.

Lateral Movement and Expansion Signals (Conditional)

·        Use of compute-host credentials, orchestration credentials, storage credentials, backup credentials, monitoring credentials, or tenant-exposed credentials against internal services after suspicious KVM instability.

·        Compute-host access to storage backends, backup repositories, identity providers, orchestration APIs, cloud control-plane services, metadata services, management networks, tenant networks, or sibling compute hosts.

·        Access to adjacent tenants, sibling VM disks, cross-tenant snapshots, shared storage, management databases, image repositories, backup platforms, migration services, or host inventory systems.

·        Lateral movement from an affected compute host into cloud management, private cloud control-plane, OpenStack, Kubernetes virtualization, storage, backup, monitoring, identity, deployment, or logging infrastructure.

·        Multiple guests, tenants, compute hosts, or pools showing similar instability, storage access, control-plane activity, or management-network access after suspicious guest-side behavior.

·        Downstream access patterns suggesting that host-level compromise was used to reach tenant workloads, management services, credentials, or virtualization infrastructure dependencies.

·        Expansion from a compromised guest into the host and then into storage, backup, identity, orchestration, monitoring, or tenant environments using trust relationships exposed through the virtualization layer.

Signal Usage Constraints

Do not treat any single signal as compromise confirmation. Promote confidence only when signals align by KVM host, guest, tenant, VM instance, image, compute pool, nested virtualization setting, KVM fault pattern, host process, storage object, control-plane action, destination, maintenance window, or bounded time window. Treat vulnerable-kernel status, public proof-of-concept availability, Januscape reporting, and related CVE metadata as urgency inputs, not detection proof.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

·        EDR, Linux audit, host syslog, virtualization host telemetry, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, orchestration-agent logs, storage-agent logs, backup-agent logs, monitoring-agent logs, or equivalent process and service-context telemetry from KVM compute hosts.

·        Parent process, child process, process user, command line, current directory, executable path, hash where available, timestamp, host name, compute pool, VM mapping, tenant mapping, workload mapping, and management-network context.

·        QEMU, libvirt, virtqemud, KVM helper process, compute service, cloud agent, storage connector, backup agent, monitoring agent, migration service, metadata service, and orchestration service mapping.

·        Detection of shell, scripting, transfer, archive, discovery, credential-access, storage-access, metadata-access, VM-artifact access, service-control, kernel-module, persistence-like, and network tooling executed from compute-host context.

·        Compute-host grouping for public cloud, private cloud, hosting, CI, sandbox, malware-analysis, lab, staging, production, managed-service, and single-tenant deployments.

·        Approved administrative-user, approved automation, approved patching, approved migration, approved kernel testing, approved nested virtualization, approved host maintenance, approved backup, approved monitoring, approved incident-response, and approved vendor-support exceptions.

·        Guest telemetry where available for kernel module loading, privileged command execution, nested virtualization tooling, nested guest lifecycle activity, and abnormal virtualization-extension use.

Memory and Execution Telemetry

·        Host kernel crash dump, kernel trace, oops, panic, soft lockup, watchdog, and virtualization fault telemetry where available.

·        KVM execution context involving MMU handling, shadow paging behavior, reverse-map handling, nested virtualization behavior, invalid page state, unexpected role handling, or memory-management faults where available.

·        Runtime evidence linking guest-side nested virtualization activity to host-side KVM instability, host process behavior, or compute-node failure.

·        QEMU, libvirt, virtqemud, compute-agent, storage-agent, backup-agent, and orchestration-agent execution context where available.

·        Runtime command execution, child-process spawning, host shell activity, service manipulation, storage interaction, metadata access, VM artifact access, or outbound connection behavior from compute-host context.

·        Process lineage linking host fault recovery, service restart, crash handling, host maintenance, VM migration, storage access, or control-plane interaction after suspected KVM instability.

·        Memory telemetry is conditional and may be unavailable in production compute environments.

·        Kernel crash and fault telemetry should be treated as high-value enrichment when available, but detection must still support environments where crash dumps are not retained.

Crash and Fault Telemetry

·        Host kernel logs from KVM compute nodes.

·        KVM logs.

·        QEMU logs.

·        Libvirt and virtqemud logs.

·        Compute-agent logs.

·        Systemd journal records.

·        Kernel panic, oops, soft lockup, watchdog, crash dump, reboot, and service restart records.

·        Host health, failover, evacuation, migration, compute-node disablement, and recovery events.

·        KVM fault patterns involving MMU behavior, shadow paging, reverse-map handling, nested virtualization, unexpected role handling, invalid page reuse, memory corruption, or abnormal page state behavior.

·        Host hardware telemetry, capacity telemetry, storage telemetry, and maintenance records used to separate exploit-aligned instability from hardware failure, capacity exhaustion, planned maintenance, or routine failover.

·        Hypervisor service instability, QEMU process crash behavior, libvirt instability, compute service restart behavior, and host quarantine activity.

·        SIEM, ITSM, change-management, vulnerability-management, patch-management, and incident-response records for context around suspicious instability.

File and Persistence Telemetry

·        File creation, modification, rename, write, read, delete, permission, ownership, timestamp, compression, staging, export, backup, and configuration artifact telemetry for KVM compute hosts where available.

·        Coverage for VM disks, snapshots, memory dumps, guest configuration files, metadata files, cloud-init data, libvirt artifacts, QEMU artifacts, host logs, crash dumps, kernel modules, service files, systemd units, cron entries, SSH keys, storage credentials, orchestration credentials, backup credentials, and monitoring credentials.

·        Detection of unexpected shell scripts, command output files, compressed archives, credential-bearing files, host configuration changes, VM artifact access, metadata access, snapshot access, backup access, and suspicious temporary files.

·        Known-good host configuration baseline.

·        Approved VM placement inventory.

·        Approved tenant-to-host mapping.

·        Approved storage mapping.

·        Approved backup mapping.

·        Approved control-plane service mapping.

·        Approved host networking, bridge, tap device, firewall, migration, metadata, monitoring, logging, and management-access inventories.

·        Configuration-change records for host users, SSH keys, compute services, storage connectors, backup agents, monitoring agents, orchestration agents, firewall rules, virtual networking, storage mounts, and management access.

·        Backup comparison data, host configuration exports, SIEM records, ITSM records, cloud control-plane records, OpenStack records, Kubernetes virtualization records, and incident-response collection artifacts.

Network and Outbound Communication Telemetry

·        DNS logs.

·        Proxy logs.

·        Firewall logs.

·        NDR metadata.

·        EDR network telemetry where available.

·        NetFlow, VPC flow, data-center flow, cloud network flow, or host network telemetry where available.

·        Destination domain, destination IP, destination port, protocol, process context where available, source compute host, source interface, host role, tenant context where available, timestamp, action, and reputation enrichment.

·        Recently seen domain enrichment.

·        Newly registered domain enrichment.

·        Destination country and ASN enrichment where available.

·        Approved egress-destination lookup.

·        Approved update, telemetry, monitoring, license-validation, storage, backup, migration, metadata, DNS, NTP, syslog, and orchestration destination lookups.

·        Management, identity, metadata, storage, backup, migration, tenant, monitoring, logging, and orchestration service destination mapping.

·        Network segmentation records for tenant networks, storage networks, backup networks, management networks, migration networks, metadata services, and orchestration services.

·        Internal service access telemetry to identify compute-host communication that exceeds normal host role requirements.

Web and Application Telemetry (Conditional Availability)

·        Cloud control-plane logs with VM placement, migration, host evacuation, compute-node disablement, maintenance, tenant, project, image, and workload metadata.

·        OpenStack, Kubernetes virtualization, private cloud, hosting platform, or internal provisioning logs where deployed.

·        Metadata service logs, image repository logs, storage service logs, backup service logs, identity service logs, monitoring service logs, and orchestration API logs where available.

·        Tenant workload metadata, VM image metadata, VM lifecycle records, scheduling decisions, live migration events, host assignment history, and compute pool membership.

·        Guest telemetry from EDR, syslog, auditd, workload logs, CI logs, sandbox logs, or customer-provided monitoring where available.

·        API method, host ID, VM ID, tenant ID, project ID, image ID, compute pool, migration state, scheduling action, actor, timestamp, source IP, destination, and administrative identity where available.

·        KVM host inventory.

·        Kernel version and patch inventory.

·        Nested virtualization exposure inventory.

·        VM placement and tenant inventory.

·        Storage, backup, management, identity, metadata, and orchestration dependency inventory.

·        Change-management, maintenance, patch-validation, incident-response, and approved nested virtualization records.

Telemetry Availability Requirements

·        Minimum viable coverage requires KVM host inventory, nested virtualization configuration state, kernel version and patch state, reboot validation, VM placement mapping, tenant ownership mapping, and host kernel log collection.

·        Strong coverage requires host KVM telemetry joined to guest activity where available, control-plane placement logs, crash and reboot telemetry, compute service logs, network telemetry, storage access logs, backup access logs, identity access logs, and approved maintenance records.

·        Highest confidence requires correlation across untrusted guest activity, nested virtualization exposure, KVM host instability, crash or fault telemetry, compute-node failure, VM placement history, post-fault host activity, network communication, storage access, control-plane activity, and tenant-boundary review.

·        Cloud, managed, hosted, or sealed virtualization environments require compensating evidence from provider logs, control-plane records, host health telemetry, VM placement data, migration history, network flows, storage logs, backup logs, and incident-response artifacts.

·        Guest-only visibility is not sufficient to confirm host compromise.

·        Host-only visibility is stronger but may still require control-plane and placement data to determine guest origin and tenant blast radius.

·        Cloud control-plane logs alone are not sufficient to prove guest-to-host exploitation without host-side KVM, crash, network, storage, or post-fault behavior.

Telemetry Limitations and Gaps

·        Guest telemetry may be unavailable for tenant-controlled, customer-managed, externally provisioned, or privacy-restricted workloads.

·        Host KVM logs may rotate quickly.

·        Kernel crash dumps may not be enabled.

·        Host reboots may erase volatile evidence.

·        Live migration, evacuation, or automated recovery may disrupt timeline reconstruction.

·        KVM fault strings may differ across kernel versions, distributions, logging configurations, and crash conditions.

·        Nested virtualization may be enabled without accurate inventory.

·        Patch tools may report installation without confirming reboot into the fixed kernel.

·        Livepatch state may be difficult to validate without kernel-specific evidence.

·        Cloud customers may not have access to host-side KVM telemetry.

·        Cloud providers may have host telemetry but limited guest visibility.

·        Storage, backup, metadata, identity, and orchestration logs may not attribute access to a specific host process.

·        VM placement history may be incomplete after migration, evacuation, disaster recovery, or autoscaling.

·        Host instability may be caused by hardware failure, capacity exhaustion, driver defects, storage failure, planned maintenance, or unrelated kernel issues.

·        Vulnerable-kernel status cannot prove compromise or non-compromise.

S24 — Detection Opportunities and Gaps

Detection Opportunities

·        Nested virtualization exposure can be identified through KVM host configuration, kernel module settings, compute-pool policy, and virtualization platform inventory.

·        Guest-side nested virtualization activity can be correlated with host-side KVM warnings, panics, oops events, soft lockups, watchdog events, crashes, or compute-node resets.

·        VM placement history can identify whether the same tenant, guest image, workload family, or automation pattern is repeatedly associated with host instability.

·        Host kernel logs can reveal KVM, MMU, shadow paging, reverse-map, unexpected role, nested virtualization, or memory-management fault patterns after suspicious guest activity.

·        Compute control-plane logs can show host disablement, evacuation, live migration, failed migration, emergency maintenance, or rescheduling after suspicious KVM instability.

·        Crash dumps, kernel traces, and system journals can preserve evidence of host-side fault behavior when guest telemetry is unavailable.

·        Host process telemetry can reveal unusual QEMU, libvirt, virtqemud, compute-agent, storage-agent, backup-agent, monitoring-agent, or orchestration-agent behavior after a fault.

·        Network telemetry can identify unusual compute-host communication to management, identity, metadata, storage, backup, migration, monitoring, orchestration, tenant, or external destinations after suspected KVM instability.

·        Storage and backup logs can identify access to VM disks, snapshots, memory artifacts, tenant data, image repositories, or backup repositories after host compromise indicators.

·        Known-good host configuration baselines can reveal unauthorized changes to services, users, SSH keys, systemd units, cron entries, host networking, storage mounts, firewall rules, or management access.

·        SIEM, ITSM, change-management, patch-management, vulnerability-management, and incident-response records can separate approved host maintenance from suspicious fault-driven activity.

·        Multi-host correlation can identify repeated exploitation attempts across compute pools, tenants, guest images, CI runners, sandbox environments, hosting clusters, or cloud regions.

Detection Gaps

·        Guest telemetry may be unavailable, untrusted, incomplete, or inaccessible in tenant-controlled environments.

·        Host kernel logs may not preserve the full KVM fault sequence.

·        Crash dumps may be disabled, overwritten, or unavailable after automated recovery.

·        Nested virtualization exposure may not be accurately inventoried across all compute pools.

·        VM placement and migration records may be incomplete or difficult to join to host crash timelines.

·        Host instability may be misclassified as hardware failure, resource exhaustion, storage failure, maintenance activity, driver instability, or unrelated kernel defects.

·        Cloud customers may lack host-side KVM visibility and must rely on provider telemetry or incident notifications.

·        Managed or hosted virtualization platforms may not expose QEMU, libvirt, kernel, crash, or host process telemetry.

·        Storage, backup, identity, metadata, and orchestration logs may not preserve enough context to prove post-escape activity.

·        Attackers may trigger host instability without immediately performing observable post-exploitation behavior.

·        Attackers may delete logs, crash artifacts, temporary files, VM artifacts, or host evidence after obtaining host-level access.

·        Patch status may be misleading when hosts have installed fixed packages but have not rebooted into the fixed kernel.

·        Public PoC activity may produce crash behavior without matching a full escape path, creating ambiguity between exploit attempt, denial-of-service impact, and host compromise.

Compensating Controls

·        Preserve host kernel logs, crash dumps, system journals, KVM logs, QEMU logs, libvirt logs, control-plane logs, and network telemetry during exposure review.

·        Inventory all x86 KVM hosts where nested virtualization is enabled.

·        Identify all untrusted, tenant-controlled, externally provisioned, customer-managed, CI-controlled, sandboxed, and high-risk workloads on nested virtualization-enabled hosts.

·        Validate kernel patch state and reboot completion across all exposed compute hosts.

·        Disable nested virtualization for untrusted guests where operationally feasible during the remediation window.

·        Restrict nested virtualization to approved hosts, approved tenants, approved images, approved CI pipelines, approved labs, and documented business requirements.

·        Correlate VM placement, tenant ownership, image lineage, guest lifecycle events, host faults, compute-node recovery, and post-fault host activity.

·        Review compute-host outbound communication to management, storage, backup, identity, metadata, migration, monitoring, orchestration, tenant, and external destinations after suspicious instability.

·        Review storage, backup, image repository, metadata, and identity logs for access from affected compute hosts after suspected KVM faults.

·        Compare host configuration against known-good baselines for users, SSH keys, services, systemd units, cron entries, host networking, storage mounts, firewall rules, and management access.

·        Quarantine affected hosts, preserve forensic artifacts, evacuate workloads carefully, and rotate credentials or tokens exposed to the compute host when compromise cannot be ruled out.

·        Use vulnerable-kernel status, public PoC awareness, and exploit reporting as prioritization inputs, not standalone proof of compromise.

Non-Coverage Conditions

·        Vulnerable-kernel status without guest-side activity, KVM fault telemetry, host instability, or post-fault host behavior.

·        Nested virtualization enabled on an approved lab or CI host with no suspicious guest behavior or host instability.

·        Guest root access without nested virtualization, privileged virtualization behavior, host instability, or host impact.

·        Host reboot or compute-node failure with no KVM fault signal, guest correlation, placement correlation, or suspicious follow-on behavior.

·        Scanner findings that do not align with guest-side virtualization activity, KVM host instability, or post-fault host behavior.

·        Generic Linux privilege escalation activity that remains inside the guest and does not affect the host virtualization boundary.

·        Container escape behavior, Kubernetes control-plane compromise, cloud identity compromise, storage compromise, VPN compromise, or management-plane compromise that does not involve KVM guest-to-host escape behavior.

·        Cloud-only anomalies, identity-only anomalies, storage-only anomalies, network-only anomalies, backup-only anomalies, or tenant-only anomalies without KVM host, guest, placement, fault, process, destination, or time-window correlation.

·        Benign host maintenance, approved kernel testing, approved nested virtualization validation, approved CI execution, approved sandbox testing, approved live migration, approved failover testing, approved patch validation, approved host evacuation, or approved incident-response cleanup.

S25 Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

NDR and Network Behavioral Analytics are viable for this threat when the platform can identify KVM compute hosts, nested-virtualization-enabled hosts, management and storage network zones, metadata and orchestration services, approved compute-host egress, host-fault context from SIEM or infrastructure telemetry, and east-west traffic from virtualization hosts. NDR cannot directly observe KVM shadow MMU corruption, guest-to-host memory corruption, or in-kernel exploit execution. Its value is detecting network-visible behavior after suspicious KVM host instability, including compute-host access to management, identity, metadata, storage, backup, migration, orchestration, tenant, or external destinations.

Rule

KVM Compute Host Post-Fault Network Expansion After Guest-to-Host Escape Indicators

Rule Format

Behavioral correlation rule for NDR and Network Behavioral Analytics platforms.

Detection Purpose

Detect suspicious network activity from KVM compute hosts after guest-to-host escape indicators, host-side KVM instability, or compute-node failure. The rule identifies compute-host communication that could indicate post-escape expansion, artifact access, credential use, storage access, control-plane access, metadata access, tenant-boundary exposure, or outbound command-and-control-like behavior after a suspected virtualization boundary event.

Detection Logic

Identify KVM compute hosts that are associated with nested virtualization exposure, untrusted guest workloads, host-side KVM instability, compute-node crash behavior, evacuation activity, quarantine activity, or emergency recovery events. Correlate those hosts with unusual outbound or east-west communication to management, storage, backup, identity, metadata, migration, monitoring, orchestration, tenant, or external destinations within a bounded post-fault window.

The rule should prioritize cases where the compute host communicates with destinations that are rare, newly observed, unapproved, sensitive, cross-tenant, or inconsistent with the host’s normal role. Higher confidence should apply when the network activity follows KVM fault context, host reboot behavior, compute-node disablement, emergency evacuation, host quarantine, crash recovery, or repeated instability tied to a tenant, VM image, workload family, or compute pool.

Required Telemetry

·        NDR, NetFlow, VPC Flow Logs, data-center flow telemetry, firewall logs, DNS logs, proxy logs, or equivalent network metadata from KVM compute hosts.

·        Asset inventory identifying KVM compute hosts, compute pools, virtualization hosts, management interfaces, storage networks, migration networks, metadata services, backup services, identity services, orchestration services, monitoring services, and tenant networks.

·        Host-fault context from SIEM, Linux kernel logs, KVM logs, QEMU logs, libvirt logs, compute-agent logs, crash telemetry, incident-response notes, or infrastructure health systems.

·        Nested virtualization exposure inventory for x86 KVM hosts.

·        VM placement, tenant, project, image, workload, and compute-pool mapping where available.

·        Approved compute-host egress destinations.

·        Approved compute-host east-west service mappings.

·        Approved maintenance, patching, migration, failover, evacuation, kernel-testing, CI, sandbox, malware-analysis, and incident-response windows.

·        Destination enrichment for domain age, first-seen status, ASN, geography, reputation, service category, protocol, and internal zone.

Engineering Implementation Instructions

Deploy this rule in hunt mode before alert mode. Validate KVM compute-host asset mapping, nested virtualization exposure mapping, sensitive service mapping, management network mapping, storage network mapping, metadata service mapping, orchestration service mapping, and approved compute-host egress baselines before production use. Tune approved live migration, storage replication, backup, monitoring, logging, DNS, NTP, update, vulnerability validation, incident-response, host evacuation, and maintenance workflows.

The rule should not fire on routine compute-host communication to approved storage, backup, monitoring, metadata, migration, or orchestration services unless the activity follows host-fault context or deviates from approved host role behavior. Require a bounded post-fault window and at least one sensitive, rare, unapproved, or cross-zone network condition before promoting to alert mode. Use host-fault context as a correlation input, not as a standalone network detection.

DRI Assessment

The rule has strong detection resilience because it focuses on post-fault compute-host network behavior rather than a single CVE name, exploit string, or proof-of-concept artifact. It remains useful across KVM guest-to-host escape variants that produce host instability followed by network-visible host activity. Its main weakness is that NDR cannot observe guest-side memory corruption or kernel exploitation directly.

DRI

8.6

TCR Assessment

Operational telemetry coverage is moderate to strong when KVM compute hosts are mapped correctly and network telemetry covers management, storage, backup, identity, metadata, orchestration, migration, and tenant networks. Full-telemetry coverage is stronger when NDR events can be joined with host KVM logs, crash telemetry, VM placement history, tenant context, nested virtualization exposure, and incident-response artifacts.

Operational TCR

7.8

Full-Telemetry TCR

8.8

Limitations

·        This rule does not detect KVM shadow MMU corruption directly.

·        This rule does not prove guest-to-host escape without host-fault, placement, or post-fault correlation.

·        This rule requires accurate KVM compute-host inventory.

·        This rule requires accurate sensitive-service and network-zone mapping.

·        This rule can miss activity that remains local to the host and produces no network-visible behavior.

·        This rule can generate noise during approved live migration, backup, failover, storage maintenance, patching, kernel testing, incident response, or compute-node evacuation.

·        This rule is weaker where cloud providers, managed hosting services, or sealed virtualization platforms do not expose host identity, host-fault context, or compute-host network telemetry.

·        This rule should not be used as a managed-cloud hypervisor escape detector unless the organization has self-managed KVM host telemetry or provider-supplied host-context evidence.

Detection Query Pattern

Use this pattern as an implementation guide for NDR and Network Behavioral Analytics platforms that support KVM compute-host asset mapping, nested-virtualization exposure awareness, host-fault context ingestion, VM placement joins, tenant and image joins, management-zone mapping, storage-zone mapping, backup-zone mapping, metadata-service mapping, orchestration-service mapping, east-west baselining, destination enrichment, approved egress context, maintenance-window context, and sequence logic.

LET KVM_COMPUTE_HOSTS =
ENV_KVM_COMPUTE_HOSTS
OR ENV_LINUX_KVM_HOSTS
OR ENV_OPENSTACK_COMPUTE_NODES
OR ENV_PRIVATE_CLOUD_COMPUTE_NODES
OR ENV_HOSTING_PROVIDER_KVM_NODES
OR ENV_SELF_MANAGED_KVM_CLOUD_HOSTS
OR ENV_CI_KVM_RUNNERS
OR ENV_SANDBOX_KVM_HOSTS
OR ENV_MALWARE_ANALYSIS_KVM_HOSTS
OR ENV_MULTI_TENANT_VIRTUALIZATION_HOSTS

LET KVM_NESTED_VIRTUALIZATION_EXPOSED_HOSTS =
ENV_KVM_INTEL_NESTED_ENABLED_HOSTS
OR ENV_KVM_AMD_NESTED_ENABLED_HOSTS
OR ENV_NESTED_VIRTUALIZATION_ENABLED_COMPUTE_POOLS
OR ENV_KVM_HOSTS_EXPOSING_VIRTUALIZATION_EXTENSIONS
OR ENV_APPROVED_NESTED_VIRTUALIZATION_HOSTS
OR ENV_UNTRUSTED_GUEST_NESTED_VIRTUALIZATION_HOSTS

LET UNTRUSTED_OR_HIGH_RISK_GUEST_CONTEXT =
ENV_UNTRUSTED_TENANT_GUESTS
OR ENV_CUSTOMER_MANAGED_GUESTS
OR ENV_EXTERNALLY_PROVISIONED_GUESTS
OR ENV_PARTNER_MANAGED_GUESTS
OR ENV_CI_CONTROLLED_GUESTS
OR ENV_SANDBOXED_GUESTS
OR ENV_MALWARE_ANALYSIS_GUESTS
OR ENV_HIGH_RISK_GUEST_IMAGES
OR ENV_GUESTS_WITH_NESTED_HYPERVISOR_ACTIVITY
OR ENV_GUESTS_WITH_KERNEL_MODULE_ACTIVITY

LET KVM_HOST_FAULT_CONTEXT =
ENV_KVM_KERNEL_PANIC_EVENTS
OR ENV_KVM_OOPS_EVENTS
OR ENV_KVM_SOFT_LOCKUP_EVENTS
OR ENV_KVM_WATCHDOG_EVENTS
OR ENV_KVM_CRASH_DUMP_EVENTS
OR ENV_KVM_COMPUTE_NODE_REBOOT_EVENTS
OR ENV_KVM_HOST_QUARANTINE_EVENTS
OR ENV_KVM_COMPUTE_NODE_DISABLEMENT_EVENTS
OR ENV_KVM_HOST_EVACUATION_EVENTS
OR ENV_KVM_SERVICE_RESTART_EVENTS
OR ENV_KVM_MMU_FAULT_EVENTS
OR ENV_KVM_SHADOW_PAGING_FAULT_EVENTS
OR ENV_KVM_NESTED_VIRTUALIZATION_FAULT_EVENTS

LET SENSITIVE_VIRTUALIZATION_DEPENDENCIES =
ENV_VIRTUALIZATION_MANAGEMENT_SERVICES
OR ENV_CLOUD_CONTROL_PLANE_SERVICES
OR ENV_OPENSTACK_CONTROL_PLANE_SERVICES
OR ENV_KUBERNETES_VIRTUALIZATION_SERVICES
OR ENV_ORCHESTRATION_API_SERVICES
OR ENV_METADATA_SERVICES
OR ENV_IDENTITY_SERVICES
OR ENV_STORAGE_BACKENDS
OR ENV_BACKUP_REPOSITORIES
OR ENV_IMAGE_REPOSITORIES
OR ENV_SNAPSHOT_REPOSITORIES
OR ENV_MIGRATION_NETWORKS
OR ENV_MONITORING_SERVICES
OR ENV_LOGGING_SERVICES
OR ENV_TENANT_NETWORKS
OR ENV_MANAGEMENT_NETWORKS

LET APPROVED_KVM_COMPUTE_EGRESS =
ENV_APPROVED_KVM_UPDATE_DESTINATIONS
OR ENV_APPROVED_KVM_DNS_DESTINATIONS
OR ENV_APPROVED_KVM_NTP_DESTINATIONS
OR ENV_APPROVED_KVM_SYSLOG_DESTINATIONS
OR ENV_APPROVED_KVM_MONITORING_DESTINATIONS
OR ENV_APPROVED_KVM_STORAGE_DESTINATIONS
OR ENV_APPROVED_KVM_BACKUP_DESTINATIONS
OR ENV_APPROVED_KVM_MIGRATION_DESTINATIONS
OR ENV_APPROVED_KVM_METADATA_DESTINATIONS
OR ENV_APPROVED_KVM_ORCHESTRATION_DESTINATIONS
OR ENV_APPROVED_KVM_PACKAGE_REPOSITORIES
OR ENV_APPROVED_VENDOR_SUPPORT_DESTINATIONS
OR ENV_APPROVED_BUSINESS_DOMAINS

LET APPROVED_KVM_CONTEXT_EXCEPTIONS =
ENV_APPROVED_KVM_MAINTENANCE_WINDOWS
OR ENV_APPROVED_KVM_PATCH_WINDOWS
OR ENV_APPROVED_KVM_REBOOT_WINDOWS
OR ENV_APPROVED_KVM_LIVE_MIGRATION_WINDOWS
OR ENV_APPROVED_KVM_EVACUATION_WINDOWS
OR ENV_APPROVED_KVM_FAILOVER_TEST_WINDOWS
OR ENV_APPROVED_KVM_BACKUP_WINDOWS
OR ENV_APPROVED_KVM_KERNEL_TESTING_WINDOWS
OR ENV_APPROVED_KVM_CI_WINDOWS
OR ENV_APPROVED_KVM_SANDBOX_TEST_WINDOWS
OR ENV_APPROVED_KVM_INCIDENT_RESPONSE_WINDOWS
OR ENV_APPROVED_VENDOR_SUPPORT_WINDOWS

LET kvm_host_fault_or_escape_context =
infrastructure_or_siem_context_events
WHERE (
host_id IN KVM_COMPUTE_HOSTS
OR host_name IN KVM_COMPUTE_HOSTS
OR asset_id IN KVM_COMPUTE_HOSTS
OR compute_node IN KVM_COMPUTE_HOSTS
)
AND (
host_id IN KVM_NESTED_VIRTUALIZATION_EXPOSED_HOSTS
OR host_name IN KVM_NESTED_VIRTUALIZATION_EXPOSED_HOSTS
OR compute_pool IN KVM_NESTED_VIRTUALIZATION_EXPOSED_HOSTS
OR nested_virtualization_enabled = true
)
AND (
guest_id IN UNTRUSTED_OR_HIGH_RISK_GUEST_CONTEXT
OR tenant_id IN ENV_UNTRUSTED_OR_EXTERNAL_TENANTS
OR image_id IN ENV_HIGH_RISK_GUEST_IMAGES
OR workload_id IN ENV_HIGH_RISK_VIRTUALIZATION_WORKLOADS
OR guest_nested_virtualization_activity = true
OR guest_kernel_module_activity = true
OR host_fault_event IN KVM_HOST_FAULT_CONTEXT
)
AND event_time NOT IN APPROVED_KVM_CONTEXT_EXCEPTIONS

LET suspicious_compute_host_network_activity =
dns_proxy_firewall_flow_or_ndr_events
WHERE (
source_host IN KVM_COMPUTE_HOSTS
OR source_ip IN KVM_COMPUTE_HOSTS
OR source_asset_id IN KVM_COMPUTE_HOSTS
OR source_interface IN ENV_KVM_COMPUTE_HOST_INTERFACES
OR source_workload_identity IN KVM_COMPUTE_HOSTS
)
AND (
destination_domain IS NOT NULL
OR destination_ip IS NOT NULL
OR destination_service IS NOT NULL
OR destination_zone IS NOT NULL
)
AND event_time NOT IN APPROVED_KVM_CONTEXT_EXCEPTIONS
AND (
destination_domain IS NULL
OR destination_domain NOT IN APPROVED_KVM_COMPUTE_EGRESS
)
AND (
destination_ip IS NULL
OR destination_ip NOT IN APPROVED_KVM_COMPUTE_EGRESS
)
AND (
destination_service IN SENSITIVE_VIRTUALIZATION_DEPENDENCIES
OR destination_zone IN ENV_MANAGEMENT_ZONES
OR destination_zone IN ENV_STORAGE_ZONES
OR destination_zone IN ENV_BACKUP_ZONES
OR destination_zone IN ENV_METADATA_ZONES
OR destination_zone IN ENV_IDENTITY_ZONES
OR destination_zone IN ENV_ORCHESTRATION_ZONES
OR destination_zone IN ENV_TENANT_ZONES
OR destination_first_seen_status IN ("new", "rare")
OR destination_domain_age_days < ENV_NEW_DOMAIN_AGE_DAYS
OR destination_reputation IN ("unknown", "suspicious", "malicious")
OR destination_asn IN ENV_SUSPICIOUS_ASNS
OR destination_geo NOT IN ENV_KVM_EXPECTED_EGRESS_GEOS
OR destination_port IN ENV_UNUSUAL_KVM_COMPUTE_EGRESS_PORTS
OR protocol IN ("ssh", "smb", "nfs", "object_storage", "raw_ip", "unknown", "tunnel", "file_transfer")
OR proxy_action IN ("allowed", "proxied", "connected")
OR firewall_action IN ("allowed", "connected")
OR ndr_behavior IN ("callback_like", "beacon_like", "tool_retrieval_like", "unusual_internal_service_access", "rare_external_connection", "cross_zone_access", "sensitive_service_access")
)

LET suspicious_compute_host_east_west_activity =
east_west_flow_or_ndr_events
WHERE (
source_host IN KVM_COMPUTE_HOSTS
OR source_ip IN KVM_COMPUTE_HOSTS
OR source_asset_id IN KVM_COMPUTE_HOSTS
OR source_interface IN ENV_KVM_COMPUTE_HOST_INTERFACES
)
AND (
destination_host IN ENV_SIBLING_COMPUTE_HOSTS
OR destination_host IN ENV_TENANT_WORKLOADS
OR destination_host IN ENV_MANAGEMENT_SYSTEMS
OR destination_host IN ENV_STORAGE_SYSTEMS
OR destination_host IN ENV_BACKUP_SYSTEMS
OR destination_host IN ENV_IDENTITY_SYSTEMS
OR destination_host IN ENV_ORCHESTRATION_SYSTEMS
OR destination_host IN ENV_METADATA_SERVICES
OR destination_zone IN ENV_TENANT_ZONES
OR destination_zone IN ENV_MANAGEMENT_ZONES
OR destination_zone IN ENV_STORAGE_ZONES
OR destination_zone IN ENV_BACKUP_ZONES
)
AND event_time NOT IN APPROVED_KVM_CONTEXT_EXCEPTIONS
AND (
connection_first_seen_status IN ("new", "rare")
OR service_first_seen_status IN ("new", "rare")
OR destination_role NOT IN ENV_EXPECTED_KVM_COMPUTE_DESTINATION_ROLES
OR destination_port IN ENV_UNUSUAL_KVM_EAST_WEST_PORTS
OR protocol IN ("ssh", "smb", "nfs", "object_storage", "database", "api", "raw_ip", "unknown")
OR ndr_behavior IN ("lateral_movement_like", "sensitive_service_access", "cross_tenant_access", "management_plane_access", "storage_access", "backup_access", "metadata_access")
)

SEQUENCE kvm_host_fault_or_escape_context THEN suspicious_compute_host_network_activity
WHERE (
same_source_host = true
OR same_source_ip = true
OR same_source_asset_id = true
OR same_compute_node = true
OR same_compute_pool = true
)
AND (
same_tenant_id = true
OR same_guest_id = true
OR same_image_id = true
OR same_workload_id = true
OR same_compute_pool = true
OR same_host_fault_window = true
)
WITHIN ENV_KVM_FAULT_TO_NETWORK_EXPANSION_WINDOW
OR
SEQUENCE kvm_host_fault_or_escape_context THEN suspicious_compute_host_east_west_activity
WHERE (
same_source_host = true
OR same_source_ip = true
OR same_source_asset_id = true
OR same_compute_node = true
OR same_compute_pool = true
)
AND (
same_tenant_id = true
OR same_guest_id = true
OR same_image_id = true
OR same_workload_id = true
OR same_host_fault_window = true
)
WITHIN ENV_KVM_FAULT_TO_EAST_WEST_EXPANSION_WINDOW

OUTPUT
source_host,
source_ip,
source_asset_id,
source_interface,
compute_node,
compute_pool,
host_id,
host_name,
guest_id,
tenant_id,
project_id,
image_id,
workload_id,
nested_virtualization_enabled,
guest_nested_virtualization_activity,
guest_kernel_module_activity,
host_fault_event,
host_fault_type,
host_fault_time,
kvm_fault_family,
destination_host,
destination_ip,
destination_domain,
destination_port,
destination_protocol,
destination_service,
destination_zone,
destination_role,
destination_reputation,
destination_domain_age_days,
destination_first_seen_status,
connection_first_seen_status,
service_first_seen_status,
destination_asn,
destination_geo,
proxy_action,
firewall_action,
ndr_behavior,
same_compute_node,
same_compute_pool,
same_tenant_id,
same_guest_id,
same_image_id,
same_workload_id,
first_seen,
last_seen,
time_delta

SentinelOne

Detection Viability Assessment

SentinelOne is viable for this threat when deployed on Linux KVM compute hosts, self-managed virtualization hosts, private cloud compute nodes, hosting-provider KVM nodes, CI KVM runners, sandbox hosts, malware-analysis virtualization hosts, or cloud-hosted self-managed KVM systems. SentinelOne cannot directly prove KVM shadow MMU corruption or guest-to-host escape from endpoint telemetry alone. Its value is detecting suspicious host-side process, file, service, credential, artifact, persistence, and network behavior after KVM host instability, compute-node failure, nested virtualization exposure, or suspected virtualization boundary stress.

Rule

KVM Compute Host Post-Fault Artifact Access and Persistence After Virtualization Boundary Stress Indicators

Rule Format

Behavioral correlation rule for SentinelOne Deep Visibility or STAR logic.

Detection Purpose

Detect suspicious endpoint activity on KVM compute hosts after virtualization boundary stress indicators, host-side KVM instability, compute-node crash behavior, evacuation activity, or suspected guest-to-host boundary failure. The rule identifies access to VM artifacts, snapshots, metadata files, libvirt/QEMU paths, host logs, crash artifacts, storage credentials, orchestration files, service configurations, persistence locations, and suspicious outbound activity from compute-host context.

Detection Logic

Identify Linux KVM compute hosts that are tagged as virtualization infrastructure, nested-virtualization-enabled hosts, self-managed KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, or multi-tenant virtualization hosts. Correlate suspicious process, file, service, persistence, credential, artifact, or network activity with KVM host-fault context, nested virtualization exposure, untrusted guest context, or post-fault recovery activity.

The rule should prioritize activity involving unexpected access to VM disk images, snapshots, memory dumps, cloud-init data, metadata files, libvirt/QEMU artifacts, host logs, crash dumps, SSH keys, service files, kernel modules, storage credentials, backup credentials, orchestration credentials, monitoring credentials, or virtualization service configuration. Higher confidence should apply when suspicious activity is performed by unusual users, unexpected parent processes, shell interpreters, scripting tools, transfer tools, archive tools, discovery tools, service-control utilities, or non-baselined compute-host processes.

Required Telemetry

·        SentinelOne Deep Visibility or STAR telemetry from Linux KVM compute hosts.

·        Endpoint tags identifying KVM compute hosts, self-managed KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, multi-tenant virtualization hosts, and nested-virtualization-enabled hosts.

·        Process telemetry with process name, parent process, command line, user, process path, hash where available, and timestamp.

·        File telemetry covering read, write, create, modify, copy, archive, rename, delete, permission, ownership, and timestamp activity.

·        Network telemetry covering outbound and east-west communication from compute-host context where available.

·        Host-fault context from SIEM, Linux kernel logs, KVM logs, QEMU logs, libvirt logs, crash telemetry, incident-response records, infrastructure health systems, or downstream XDR enrichment.

·        Path mappings for VM disks, snapshots, memory files, cloud-init data, metadata paths, libvirt artifacts, QEMU artifacts, host logs, crash dumps, kernel modules, SSH keys, service files, storage credentials, backup credentials, orchestration credentials, monitoring credentials, and temporary staging directories.

·        Approved administrative users, approved service accounts, approved backup users, approved storage users, approved orchestration users, approved monitoring users, approved vendor-support users, and approved incident-response users.

·        Approved maintenance, patching, reboot, live migration, evacuation, failover, backup, kernel-testing, CI, sandbox, malware-analysis, vendor-support, and incident-response windows.

Engineering Implementation Instructions

Deploy this rule in hunt mode before alert mode. Validate endpoint tags, KVM compute-host groupings, nested virtualization exposure tags, sensitive path mappings, approved user context, approved service context, approved process baselines, approved command patterns, approved maintenance windows, and downstream host-fault enrichment before production use. SentinelOne should detect host-side artifact access and post-fault behavior, while KVM fault confirmation, VM placement, tenant ownership, crash context, and control-plane correlation should occur through downstream SIEM, XDR, or incident-response workflow.

The rule should not alert on normal QEMU, libvirt, backup, migration, monitoring, storage, patching, kernel testing, incident-response, or CI activity unless the process, file, network, user, parent process, command line, path, or timing deviates from approved baselines. Require suspicious access context, sensitive file activity, persistence-like behavior, transfer behavior, or rare outbound activity before promoting to alert mode.

DRI Assessment

The rule has strong detection resilience because it focuses on host-side post-fault behavior and sensitive virtualization artifact access rather than a single CVE name, exploit string, crash string, or proof-of-concept artifact. It remains useful across guest-to-host escape variants where successful or suspected boundary stress leads to host artifact access, persistence attempts, credential access, transfer activity, or unusual compute-host behavior. Its main weakness is that SentinelOne cannot independently prove the in-kernel exploit path without host-fault, placement, or downstream correlation.

DRI

8.7

TCR Assessment

Operational telemetry coverage is strong when SentinelOne is deployed on KVM compute hosts with endpoint tags, process telemetry, file telemetry, command-line capture, and network telemetry. Full-telemetry coverage is stronger when SentinelOne events are joined with KVM host logs, crash telemetry, VM placement history, tenant context, nested virtualization exposure, storage logs, control-plane records, and NDR or SIEM context.

Operational TCR

8.0

Full-Telemetry TCR

8.9

Limitations

·        This rule does not detect KVM shadow MMU corruption directly.

·        This rule does not prove guest-to-host escape without host-fault, placement, or downstream correlation.

·        This rule requires SentinelOne coverage on KVM compute hosts or self-managed virtualization hosts.

·        This rule requires accurate endpoint tagging for KVM compute hosts and nested-virtualization-enabled hosts.

·        This rule requires reliable sensitive path mappings for VM artifacts, libvirt/QEMU artifacts, storage credentials, orchestration files, and host logs.

·        This rule can generate noise during approved backup, migration, patching, kernel testing, CI, sandboxing, malware analysis, incident response, or vendor support activity.

·        This rule may miss activity performed entirely in kernel space or activity that does not touch observable files, processes, services, or network telemetry.

·        This rule is weaker where compute hosts are sealed, provider-managed, unmanaged, or unavailable to endpoint telemetry.

·        This rule should not be treated as a managed-cloud hypervisor escape detector unless the organization has SentinelOne coverage on self-managed KVM hosts or provider-supplied endpoint-context evidence.

Detection Query Pattern

Use this pattern as an implementation guide for SentinelOne Deep Visibility or STAR logic that supports endpoint tags, process telemetry, parent-process telemetry, command-line telemetry, file telemetry, user context, network telemetry, path mapping, archive detection, transfer-tool detection, service-control detection, approved workflow exceptions, and downstream SIEM or XDR enrichment. KVM host-fault context, VM placement, tenant ownership, nested virtualization exposure, control-plane correlation, storage correlation, and NDR correlation should occur in the SIEM, XDR, or downstream investigation workflow.

LET KVM_RELATED_ENDPOINTS =
EndpointTags CONTAINS ANY (
"ENV_KVM_COMPUTE_HOSTS",
"ENV_LINUX_KVM_HOSTS",
"ENV_OPENSTACK_COMPUTE_NODES",
"ENV_PRIVATE_CLOUD_COMPUTE_NODES",
"ENV_HOSTING_PROVIDER_KVM_NODES",
"ENV_SELF_MANAGED_KVM_CLOUD_HOSTS",
"ENV_CI_KVM_RUNNERS",
"ENV_SANDBOX_KVM_HOSTS",
"ENV_MALWARE_ANALYSIS_KVM_HOSTS",
"ENV_MULTI_TENANT_VIRTUALIZATION_HOSTS",
"ENV_NESTED_VIRTUALIZATION_ENABLED_HOSTS"
)

LET KVM_SENSITIVE_FILE_PATHS =
FilePath STARTS_WITH ANY (
ENV_KVM_VM_DISK_PATH_PREFIXES,
ENV_KVM_SNAPSHOT_PATH_PREFIXES,
ENV_KVM_MEMORY_DUMP_PATH_PREFIXES,
ENV_KVM_CLOUD_INIT_PATH_PREFIXES,
ENV_KVM_METADATA_PATH_PREFIXES,
ENV_LIBVIRT_CONFIG_PATH_PREFIXES,
ENV_LIBVIRT_STORAGE_PATH_PREFIXES,
ENV_QEMU_CONFIG_PATH_PREFIXES,
ENV_QEMU_RUNTIME_PATH_PREFIXES,
ENV_KVM_HOST_LOG_PATH_PREFIXES,
ENV_KVM_CRASH_DUMP_PATH_PREFIXES,
ENV_KVM_KERNEL_MODULE_PATH_PREFIXES,
ENV_KVM_SERVICE_FILE_PATH_PREFIXES,
ENV_KVM_SSH_KEY_PATH_PREFIXES,
ENV_KVM_STORAGE_CREDENTIAL_PATH_PREFIXES,
ENV_KVM_BACKUP_CREDENTIAL_PATH_PREFIXES,
ENV_KVM_ORCHESTRATION_CREDENTIAL_PATH_PREFIXES,
ENV_KVM_MONITORING_CREDENTIAL_PATH_PREFIXES,
ENV_KVM_TEMP_STAGING_PATH_PREFIXES
)

LET KVM_SENSITIVE_FILE_ACTIVITY =
KVM_SENSITIVE_FILE_PATHS = true
AND EventType IN (
"file_opened",
"file_read",
"file_created",
"file_modified",
"file_copied",
"file_archived",
"file_deleted",
"file_renamed",
"file_written",
"permission_modified",
"ownership_modified"
)
AND (
FileName MATCHES ANY (
ENV_KVM_VM_DISK_FILE_PATTERNS,
ENV_KVM_SNAPSHOT_FILE_PATTERNS,
ENV_KVM_MEMORY_DUMP_FILE_PATTERNS,
ENV_KVM_CLOUD_INIT_FILE_PATTERNS,
ENV_KVM_METADATA_FILE_PATTERNS,
ENV_LIBVIRT_CONFIG_FILE_PATTERNS,
ENV_LIBVIRT_STORAGE_FILE_PATTERNS,
ENV_QEMU_CONFIG_FILE_PATTERNS,
ENV_QEMU_RUNTIME_FILE_PATTERNS,
ENV_KVM_HOST_LOG_FILE_PATTERNS,
ENV_KVM_CRASH_DUMP_FILE_PATTERNS,
ENV_KVM_KERNEL_MODULE_FILE_PATTERNS,
ENV_KVM_SERVICE_FILE_PATTERNS,
ENV_KVM_SSH_KEY_FILE_PATTERNS,
ENV_KVM_STORAGE_CREDENTIAL_FILE_PATTERNS,
ENV_KVM_BACKUP_CREDENTIAL_FILE_PATTERNS,
ENV_KVM_ORCHESTRATION_CREDENTIAL_FILE_PATTERNS,
ENV_KVM_MONITORING_CREDENTIAL_FILE_PATTERNS,
ENV_KVM_TEMP_STAGING_FILE_PATTERNS
)
OR FilePath MATCHES ANY (
ENV_KVM_VM_DISK_FILE_PATTERNS,
ENV_KVM_SNAPSHOT_FILE_PATTERNS,
ENV_KVM_MEMORY_DUMP_FILE_PATTERNS,
ENV_KVM_CLOUD_INIT_FILE_PATTERNS,
ENV_KVM_METADATA_FILE_PATTERNS,
ENV_LIBVIRT_CONFIG_FILE_PATTERNS,
ENV_LIBVIRT_STORAGE_FILE_PATTERNS,
ENV_QEMU_CONFIG_FILE_PATTERNS,
ENV_QEMU_RUNTIME_FILE_PATTERNS,
ENV_KVM_HOST_LOG_FILE_PATTERNS,
ENV_KVM_CRASH_DUMP_FILE_PATTERNS,
ENV_KVM_KERNEL_MODULE_FILE_PATTERNS,
ENV_KVM_SERVICE_FILE_PATTERNS,
ENV_KVM_SSH_KEY_FILE_PATTERNS,
ENV_KVM_STORAGE_CREDENTIAL_FILE_PATTERNS,
ENV_KVM_BACKUP_CREDENTIAL_FILE_PATTERNS,
ENV_KVM_ORCHESTRATION_CREDENTIAL_FILE_PATTERNS,
ENV_KVM_MONITORING_CREDENTIAL_FILE_PATTERNS,
ENV_KVM_TEMP_STAGING_FILE_PATTERNS
)
)

LET KVM_SUSPICIOUS_ACCESS_CONTEXT =
ProcessUser NOT IN ENV_APPROVED_KVM_ADMIN_USERS
AND UserName NOT IN ENV_APPROVED_KVM_ADMIN_USERS
AND (
ParentProcessName IN ENV_QEMU_PROCESSES
OR ParentProcessName IN ENV_LIBVIRT_PROCESSES
OR ParentProcessName IN ENV_VIRTQEMUD_PROCESSES
OR ParentProcessName IN ENV_KVM_COMPUTE_AGENT_PROCESSES
OR ParentProcessName IN ENV_KVM_STORAGE_AGENT_PROCESSES
OR ParentProcessName IN ENV_KVM_BACKUP_AGENT_PROCESSES
OR ParentProcessName IN ENV_KVM_MONITORING_AGENT_PROCESSES
OR ParentProcessName IN ENV_KVM_ORCHESTRATION_AGENT_PROCESSES
OR ProcessName IN ENV_SHELL_INTERPRETERS
OR ProcessName IN ENV_SCRIPTING_INTERPRETERS
OR ProcessName IN ENV_TRANSFER_TOOLS
OR ProcessName IN ENV_ARCHIVE_TOOLS
OR ProcessName IN ENV_NETWORK_TOOLS
OR ProcessName IN ENV_DISCOVERY_TOOLS
OR ProcessName IN ENV_SERVICE_CONTROL_TOOLS
OR ProcessName IN ENV_PACKAGE_MANAGEMENT_TOOLS
OR ProcessName IN ENV_KERNEL_MODULE_TOOLS
OR CommandLine MATCHES ENV_KVM_SUSPICIOUS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_KVM_VM_ARTIFACT_ACCESS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_KVM_STORAGE_ACCESS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_KVM_METADATA_ACCESS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_KVM_CREDENTIAL_ACCESS_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_KVM_ARCHIVE_OR_EXFILTRATION_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_KVM_LOG_DELETION_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_KVM_PERSISTENCE_COMMAND_PATTERNS
)

LET KVM_POST_FAULT_OR_BOUNDARY_STRESS_CONTEXT =
EndpointTags CONTAINS ANY (
"ENV_KVM_RECENT_KERNEL_PANIC",
"ENV_KVM_RECENT_OOPS_EVENT",
"ENV_KVM_RECENT_SOFT_LOCKUP",
"ENV_KVM_RECENT_WATCHDOG_EVENT",
"ENV_KVM_RECENT_CRASH_DUMP",
"ENV_KVM_RECENT_COMPUTE_NODE_REBOOT",
"ENV_KVM_RECENT_HOST_QUARANTINE",
"ENV_KVM_RECENT_COMPUTE_NODE_DISABLEMENT",
"ENV_KVM_RECENT_HOST_EVACUATION",
"ENV_KVM_RECENT_KVM_SERVICE_RESTART",
"ENV_KVM_RECENT_MMU_FAULT",
"ENV_KVM_RECENT_SHADOW_PAGING_FAULT",
"ENV_KVM_RECENT_NESTED_VIRTUALIZATION_FAULT",
"ENV_KVM_RECENT_UNTRUSTED_GUEST_NESTED_ACTIVITY",
"ENV_KVM_RECENT_GUEST_KERNEL_MODULE_ACTIVITY"
)

LET RARE_KVM_TRANSFER_OR_EGRESS =
(
DestinationHost IS NOT NULL
OR DestinationIp IS NOT NULL
)
AND (
DestinationHost IS NULL
OR DestinationHost NOT IN ENV_APPROVED_KVM_EGRESS_DESTINATIONS
)
AND (
DestinationIp IS NULL
OR DestinationIp NOT IN ENV_APPROVED_KVM_EGRESS_DESTINATIONS
)
AND (
DestinationFirstSeenStatus IN ("new", "rare")
OR DestinationDomainAgeDays < ENV_NEW_DOMAIN_AGE_DAYS
OR DestinationReputation IN ("unknown", "suspicious", "malicious")
OR DestinationAsn IN ENV_SUSPICIOUS_ASNS
OR DestinationGeo NOT IN ENV_KVM_EXPECTED_EGRESS_GEOS
OR DestinationPort IN ENV_UNUSUAL_KVM_EGRESS_PORTS
OR ProcessName IN ENV_TRANSFER_TOOLS
OR CommandLine MATCHES ENV_KVM_ARCHIVE_OR_EXFILTRATION_COMMAND_PATTERNS
)

LET APPROVED_KVM_SENSITIVE_FILE_ACTIVITY =
UserName IN ENV_APPROVED_KVM_ADMIN_USERS
OR UserName IN ENV_APPROVED_KVM_BACKUP_USERS
OR UserName IN ENV_APPROVED_KVM_STORAGE_USERS
OR UserName IN ENV_APPROVED_KVM_ORCHESTRATION_USERS
OR UserName IN ENV_APPROVED_KVM_MONITORING_USERS
OR UserName IN ENV_APPROVED_KVM_VENDOR_SUPPORT_USERS
OR UserName IN ENV_APPROVED_KVM_INCIDENT_RESPONSE_USERS
OR ProcessName IN ENV_APPROVED_KVM_BACKUP_TOOLS
OR ProcessName IN ENV_APPROVED_KVM_STORAGE_TOOLS
OR ProcessName IN ENV_APPROVED_KVM_MIGRATION_TOOLS
OR ProcessName IN ENV_APPROVED_KVM_MONITORING_TOOLS
OR ProcessName IN ENV_APPROVED_KVM_UPDATE_TOOLS
OR ProcessName IN ENV_APPROVED_KVM_DIAGNOSTIC_TOOLS
OR CommandLine MATCHES ENV_APPROVED_KVM_BACKUP_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_APPROVED_KVM_STORAGE_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_APPROVED_KVM_MIGRATION_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_APPROVED_KVM_DIAGNOSTIC_COMMAND_PATTERNS
OR CommandLine MATCHES ENV_APPROVED_KVM_SUPPORT_COMMAND_PATTERNS
OR EventTime IN ENV_APPROVED_KVM_BACKUP_WINDOWS
OR EventTime IN ENV_APPROVED_KVM_STORAGE_MAINTENANCE_WINDOWS
OR EventTime IN ENV_APPROVED_KVM_MIGRATION_WINDOWS
OR EventTime IN ENV_APPROVED_KVM_PATCH_WINDOWS
OR EventTime IN ENV_APPROVED_KVM_MAINTENANCE_WINDOWS
OR EventTime IN ENV_APPROVED_KVM_KERNEL_TESTING_WINDOWS
OR EventTime IN ENV_APPROVED_KVM_CI_WINDOWS
OR EventTime IN ENV_APPROVED_KVM_SANDBOX_WINDOWS
OR EventTime IN ENV_APPROVED_KVM_VENDOR_SUPPORT_WINDOWS
OR EventTime IN ENV_APPROVED_KVM_INCIDENT_RESPONSE_WINDOWS

FROM ProcessEvents OR FileEvents OR NetworkEvents
WHERE KVM_RELATED_ENDPOINTS = true
AND APPROVED_KVM_SENSITIVE_FILE_ACTIVITY != true
AND KVM_SENSITIVE_FILE_ACTIVITY = true
AND (
KVM_SUSPICIOUS_ACCESS_CONTEXT = true
OR KVM_POST_FAULT_OR_BOUNDARY_STRESS_CONTEXT = true
OR RARE_KVM_TRANSFER_OR_EGRESS = true
OR (
FileName MATCHES ANY ENV_KVM_VM_DISK_FILE_PATTERNS
OR FileName MATCHES ANY ENV_KVM_SNAPSHOT_FILE_PATTERNS
OR FileName MATCHES ANY ENV_KVM_MEMORY_DUMP_FILE_PATTERNS
OR FileName MATCHES ANY ENV_KVM_CREDENTIAL_FILE_PATTERNS
OR FileName MATCHES ANY ENV_KVM_STORAGE_CREDENTIAL_FILE_PATTERNS
OR FileName MATCHES ANY ENV_KVM_ORCHESTRATION_CREDENTIAL_FILE_PATTERNS
OR FileName MATCHES ANY ENV_KVM_BACKUP_CREDENTIAL_FILE_PATTERNS
OR FileName MATCHES ANY ENV_KVM_CRASH_DUMP_FILE_PATTERNS
)
)
AND (
(
FilePath IS NOT NULL
AND FilePath NOT IN ENV_APPROVED_KVM_FILE_PATHS
)
OR (
CommandLine IS NOT NULL
AND CommandLine NOT IN ENV_APPROVED_KVM_COMMAND_PATTERNS
)
OR (
ProcessName IS NOT NULL
AND ProcessName NOT IN ENV_APPROVED_KVM_PROCESS_BASELINE
)
OR (
DestinationHost IS NOT NULL
AND DestinationHost NOT IN ENV_APPROVED_KVM_EGRESS_DESTINATIONS
)
OR (
DestinationIp IS NOT NULL
AND DestinationIp NOT IN ENV_APPROVED_KVM_EGRESS_DESTINATIONS
)
)
OUTPUT
EndpointName,
EndpointTags,
UserName,
ProcessUser,
ProcessName,
ParentProcessName,
CommandLine,
FilePath,
FileName,
FileExtension,
EventType,
EventTime,
DestinationHost,
DestinationIp,
DestinationPort,
DestinationDomain,
DestinationFirstSeenStatus,
DestinationReputation,
DestinationDomainAgeDays,
DestinationAsn,
DestinationGeo,
NetworkAction

Splunk

Detection Viability Assessment

Splunk is highly viable for this threat when KVM host telemetry, Linux kernel logs, KVM logs, QEMU logs, libvirt logs, compute-agent logs, VM placement records, tenant and image context, nested virtualization exposure inventory, crash telemetry, network telemetry, storage logs, backup logs, identity logs, control-plane logs, patch records, and incident-response context are normalized into searchable indexes. Splunk should be used to correlate behavior sequences rather than isolated CVE names, vulnerable-kernel findings, public proof-of-concept references, scanner results, guest root conditions, single host crashes, or standalone cloud control-plane events. The strongest Splunk detections correlate nested virtualization exposure and untrusted guest context with KVM host instability, compute-node failure, host evacuation, post-fault network activity, storage access, control-plane interaction, credential exposure, or cross-tenant exposure.

Rule

KVM Guest-Linked Host Instability and Post-Fault Compute-Node Exposure Correlation

Rule Format

Behavioral correlation rule for Splunk environments using KVM host telemetry, infrastructure logs, VM placement data, network telemetry, and control-plane enrichment.

Detection Purpose

Detect KVM compute hosts where nested virtualization exposure, untrusted guest context, or guest-side virtualization activity aligns with host-side KVM instability and post-fault behavior. The rule identifies suspicious sequences involving KVM fault telemetry, compute-node crash or reboot behavior, host evacuation, unusual compute-host network activity, storage access, metadata access, orchestration access, control-plane interaction, or repeated instability tied to a guest, tenant, image, workload, or compute pool.

Detection Logic

Normalize KVM host, guest, tenant, image, compute pool, fault, network, storage, and control-plane fields across Linux kernel logs, KVM logs, QEMU logs, libvirt logs, compute-agent logs, infrastructure health systems, NDR, firewall, DNS, proxy, flow telemetry, storage logs, backup logs, identity logs, and orchestration logs. Enrich events with KVM compute-host inventory, nested virtualization exposure, VM placement data, untrusted guest context, approved maintenance windows, approved nested virtualization context, sensitive virtualization dependencies, and destination enrichment.

The rule should identify KVM compute hosts that show host-side fault or instability behavior while hosting nested-virtualization-enabled, untrusted, customer-managed, externally provisioned, CI-controlled, sandboxed, malware-analysis, or high-risk guest workloads. It should then correlate those host-fault events with post-fault network, storage, backup, identity, metadata, orchestration, tenant, or management-plane activity within a bounded window. Higher confidence should apply when repeated instability clusters around the same guest, tenant, image, workload family, compute pool, or host group.

Required Telemetry

·        Splunk ingestion of Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, systemd journal records, infrastructure health logs, crash records, and host reboot telemetry.

·        VM placement, guest ID, tenant ID, project ID, image ID, workload ID, compute-node, compute-pool, migration, evacuation, host-disablement, and host-quarantine records.

·        Nested virtualization exposure inventory for x86 KVM hosts and compute pools.

·        Asset inventory identifying KVM compute hosts, self-managed KVM cloud hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, and multi-tenant virtualization hosts.

·        NDR, firewall, DNS, proxy, NetFlow, VPC Flow Logs, cloud flow logs, or data-center flow telemetry from compute hosts.

·        Storage, backup, metadata, image repository, identity, orchestration, monitoring, logging, migration, and management-service access logs where available.

·        Destination enrichment for first-seen status, domain age, ASN, geography, reputation, service category, protocol, and internal zone.

·        Approved KVM maintenance, patching, reboot, migration, evacuation, failover, kernel-testing, CI, sandbox, malware-analysis, vendor-support, and incident-response windows.

·        Approved nested virtualization tenants, images, workloads, compute pools, and host groups.

·        Patch state, reboot validation, livepatch state, and vulnerability-management context for KVM compute hosts.

Engineering Implementation Instructions

Deploy this rule in hunt mode first. Validate Splunk indexes, sourcetypes, field extractions, CIM mappings, accelerated data models, KVM host inventory lookups, nested virtualization lookups, VM placement joins, tenant and image enrichment, destination enrichment, approved maintenance context, and post-fault window definitions before production use. Abstract customer-specific indexes, sourcetypes, field names, macros, lookups, summary indexes, and accelerated data sources behind local macros.

The rule should not fire on vulnerable-kernel status, nested virtualization exposure, guest root access, host reboot, kernel panic, migration, evacuation, or compute-node maintenance alone. Require KVM host-fault context joined to nested virtualization exposure or untrusted guest context and at least one post-fault behavior condition involving network activity, storage access, backup access, metadata access, identity access, orchestration interaction, tenant exposure, management-plane access, or repeated guest-linked host instability.

DRI Assessment

The rule has strong detection resilience because it correlates durable infrastructure behaviors rather than relying on a single CVE name, exploit string, host crash string, scanner finding, or proof-of-concept artifact. It remains useful across KVM guest-to-host escape variants that involve nested virtualization exposure, untrusted guest control, host-side KVM instability, compute-node failure, and post-fault infrastructure activity. Its main weakness is dependence on field normalization, VM placement quality, and host-fault telemetry coverage.

DRI

8.9

TCR Assessment

Operational telemetry coverage is strong when Splunk receives KVM host logs, kernel fault telemetry, VM placement records, compute-node state changes, network telemetry, and approved maintenance context. Full-telemetry coverage is very strong when Splunk also receives storage logs, backup logs, metadata service logs, identity logs, orchestration logs, patch validation records, incident-response artifacts, guest activity context, and nested virtualization exposure inventory.

Operational TCR

8.4

Full-Telemetry TCR

9.1

Limitations

·        This rule does not directly detect KVM shadow MMU corruption or in-kernel exploit execution.

·        This rule does not prove guest-to-host escape without KVM host-fault, placement, and post-fault behavior correlation.

·        This rule requires reliable KVM host inventory and compute-node identification.

·        This rule requires usable VM placement, tenant, image, workload, and compute-pool mapping.

·        This rule requires normalized KVM fault, crash, reboot, evacuation, migration, and host-disablement fields.

·        This rule can generate noise during approved patching, live migration, host evacuation, kernel testing, CI, sandboxing, failover, backup, incident response, or vendor support activity.

·        This rule may miss activity where post-escape behavior remains local to the host and does not produce network, storage, control-plane, or file-access telemetry.

·        This rule is weaker where cloud providers, managed hosting services, or sealed virtualization platforms do not expose host-fault telemetry, compute-host identity, or VM placement context.

·        This rule should not be used as a managed-cloud hypervisor escape detector unless the organization has self-managed KVM telemetry, provider-supplied host context, or sufficient infrastructure log enrichment.

Detection Query Pattern

Use this pattern as an implementation guide for Splunk environments that support KVM compute-host grouping, Linux kernel logs, KVM logs, QEMU logs, libvirt logs, compute-agent logs, VM placement records, tenant and image enrichment, nested virtualization exposure inventory, host-fault context, crash and reboot records, host evacuation records, NDR logs, DNS logs, proxy logs, firewall logs, flow telemetry, storage logs, backup logs, metadata-service logs, identity logs, orchestration logs, maintenance-window context, approved nested-virtualization context, destination enrichment, sensitive-service joins, and post-fault correlation logic. Customer-specific indexes, sourcetypes, field names, CIM mappings, macros, accelerated data sources, summary indexes, and local enrichment should be abstracted behind macros and lookups.

kvm_virtualization_boundary_events
| eval normalized_time=coalesce(_time, event_time, EventTime, timestamp)
| eval normalized_host=coalesce(host, host_name, hostname, dvc, device_name, compute_node, hypervisor_host, source_host)
| eval normalized_host_id=coalesce(host_id, asset_id, device_id, compute_node_id, hypervisor_id, source_asset_id)
| eval normalized_compute_node=coalesce(compute_node, hypervisor_host, host, host_name, hostname, dvc)
| eval normalized_compute_pool=coalesce(compute_pool, host_group, aggregate, availability_zone, cluster_name, resource_pool)
| eval normalized_guest_id=coalesce(guest_id, vm_id, instance_id, domain_id, workload_id)
| eval normalized_tenant_id=coalesce(tenant_id, project_id, account_id, subscription_id, customer_id, org_id)
| eval normalized_project_id=coalesce(project_id, tenant_id, account_id, subscription_id)
| eval normalized_image_id=coalesce(image_id, image_name, ami_id, template_id, golden_image_id)
| eval normalized_workload_id=coalesce(workload_id, vm_id, instance_id, guest_id, job_id, pipeline_id)
| eval normalized_event_type=coalesce(event_type, EventType, signature, action, operation, activity)
| eval normalized_fault_type=coalesce(fault_type, crash_type, kernel_fault_type, panic_type, kvm_fault_type, health_event)
| eval normalized_message=coalesce(message, log_message, raw_message, event_description, description, raw)
| eval normalizedprocess=coalesce(process_name, ProcessName, process, app, service_name, daemon)
| eval normalized_parent_process=coalesce(parent_process_name, ParentProcessName, parent_process, parent_app)
| eval normalized_user=coalesce(user, UserName, username, process_user, actor, account)
| eval normalized_dest_host=coalesce(dest_host, destination_host, dest, destination, url_domain)
| eval normalized_dest_ip=coalesce(dest_ip, destination_ip, daddr, dst)
| eval normalized_dest_domain=coalesce(dest_domain, destination_domain, query, domain, url_domain)
| eval normalized_dest_port=coalesce(dest_port, destination_port, dpt)
| eval normalized_dest_service=coalesce(destination_service, service, app, application, dest_service)
| eval normalized_dest_zone=coalesce(destination_zone, network_zone, security_zone, segment, subnet_role)
| eval normalized_protocol=coalesce(protocol, transport, app_protocol)
| eval normalized_network_action=coalesce(action, firewall_action, proxy_action, network_action, verdict)
| eval normalized_storage_object=coalesce(storage_object, object, object_name, bucket, volume, datastore, path, file_path)
| eval normalized_control_plane_action=coalesce(control_plane_action, operation, activity, api_method, method)
| lookup ENV_KVM_COMPUTE_HOSTS normalized_host OUTPUT kvm_host_match kvm_host_role host_criticality compute_pool as lookup_compute_pool
| lookup ENV_KVM_COMPUTE_HOSTS normalized_host_id OUTPUT kvm_host_id_match kvm_host_id_role
| lookup ENV_KVM_NESTED_VIRTUALIZATION_EXPOSED_HOSTS normalized_host OUTPUT nested_virtualization_host_match nested_exposure_type
| lookup ENV_KVM_NESTED_VIRTUALIZATION_EXPOSED_HOSTS normalized_compute_pool OUTPUT nested_virtualization_pool_match nested_pool_exposure_type
| lookup ENV_UNTRUSTED_OR_HIGH_RISK_GUEST_CONTEXT normalized_guest_id OUTPUT untrusted_guest_match guest_risk_type
| lookup ENV_UNTRUSTED_OR_HIGH_RISK_GUEST_CONTEXT normalized_tenant_id OUTPUT untrusted_tenant_match tenant_risk_type
| lookup ENV_UNTRUSTED_OR_HIGH_RISK_GUEST_CONTEXT normalized_image_id OUTPUT high_risk_image_match image_risk_type
| lookup ENV_UNTRUSTED_OR_HIGH_RISK_GUEST_CONTEXT normalized_workload_id OUTPUT high_risk_workload_match workload_risk_type
| lookup ENV_APPROVED_KVM_CONTEXT_EXCEPTIONS normalized_time OUTPUT approved_context_window
| lookup ENV_APPROVED_NESTED_VIRTUALIZATION_CONTEXT normalized_guest_id OUTPUT approved_nested_guest
| lookup ENV_APPROVED_NESTED_VIRTUALIZATION_CONTEXT normalized_tenant_id OUTPUT approved_nested_tenant
| lookup ENV_APPROVED_NESTED_VIRTUALIZATION_CONTEXT normalized_image_id OUTPUT approved_nested_image
| lookup ENV_APPROVED_NESTED_VIRTUALIZATION_CONTEXT normalized_workload_id OUTPUT approved_nested_workload
| lookup ENV_SENSITIVE_VIRTUALIZATION_DEPENDENCIES normalized_dest_domain OUTPUT sensitive_dest_domain_match dependency_family
| lookup ENV_SENSITIVE_VIRTUALIZATION_DEPENDENCIES normalized_dest_ip OUTPUT sensitive_dest_ip_match dependency_ip_family
| lookup ENV_SENSITIVE_VIRTUALIZATION_DEPENDENCIES normalized_dest_service OUTPUT sensitive_dest_service_match dependency_service_family
| lookup ENV_SENSITIVE_VIRTUALIZATION_DEPENDENCIES normalized_dest_zone OUTPUT sensitive_dest_zone_match dependency_zone_family
| lookup ENV_APPROVED_KVM_COMPUTE_EGRESS normalized_dest_domain OUTPUT approved_dest_domain
| lookup ENV_APPROVED_KVM_COMPUTE_EGRESS normalized_dest_ip OUTPUT approved_dest_ip
| lookup ENV_DESTINATION_ENRICHMENT normalized_dest_domain OUTPUT destination_first_seen_status destination_domain_age_days destination_reputation destination_asn destination_geo
| lookup ENV_DESTINATION_ENRICHMENT normalized_dest_ip OUTPUT ip_first_seen_status ip_reputation ip_asn ip_geo
| eval kvm_compute_host=if(kvm_host_match="true" OR kvm_host_id_match="true", "true", "false")
| eval nested_virtualization_exposed=if(nested_virtualization_host_match="true" OR nested_virtualization_pool_match="true" OR nested_virtualization_enabled="true", "true", "false")
| eval untrusted_or_high_risk_guest_context=if(untrusted_guest_match="true" OR untrusted_tenant_match="true" OR high_risk_image_match="true" OR high_risk_workload_match="true" OR guest_nested_virtualization_activity="true" OR guest_kernel_module_activity="true", "true", "false")
| eval approved_nested_context=if(approved_nested_guest="true" OR approved_nested_tenant="true" OR approved_nested_image="true" OR approved_nested_workload="true", "true", "false")
| eval kvm_host_fault=if(normalized_event_type IN ("kernel_panic","kernel_oops","soft_lockup","watchdog_event","crash_dump","compute_node_reboot","host_quarantine","compute_node_disablement","host_evacuated","kvm_service_restart","qemu_crash","libvirt_restart") OR normalized_fault_type IN ("kvm_mmu_fault","shadow_paging_fault","nested_virtualization_fault","memory_management_fault","unexpected_role_fault","invalid_page_state") OR match(normalized_message,"(?i)(kvm|qemu|libvirt|virtqemud).*(panic|oops|soft lockup|watchdog|crash|fault|shadow|mmu|nested virtualization|unexpected role|invalid page|memory corruption)"), "true", "false")
| eval sensitive_dependency_access=if(sensitive_dest_domain_match="true" OR sensitive_dest_ip_match="true" OR sensitive_dest_service_match="true" OR sensitive_dest_zone_match="true", "true", "false")
| eval rare_or_unapproved_compute_egress=if((isnotnull(normalized_dest_domain) OR isnotnull(normalized_dest_ip)) AND (isnull(normalized_dest_domain) OR approved_dest_domain!="true") AND (isnull(normalized_dest_ip) OR approved_dest_ip!="true") AND (destination_first_seen_status IN ("new","rare") OR ip_first_seen_status IN ("new","rare") OR destination_domain_age_days < ENV_NEW_DOMAIN_AGE_DAYS OR destination_reputation IN ("unknown","suspicious","malicious") OR ip_reputation IN ("unknown","suspicious","malicious") OR destination_asn IN ENV_SUSPICIOUS_ASNS OR ip_asn IN ENV_SUSPICIOUS_ASNS OR destination_geo NOT IN ENV_KVM_EXPECTED_EGRESS_GEOS OR ip_geo NOT IN ENV_KVM_EXPECTED_EGRESS_GEOS OR normalized_dest_port IN ENV_UNUSUAL_KVM_COMPUTE_EGRESS_PORTS), "true", "false")
| eval control_plane_or_storage_access=if(sensitive_dependency_access="true" OR isnotnull(normalized_storage_object) OR normalized_control_plane_action IN ("host_evacuated","compute_node_disabled","live_migration_started","failed_migration","snapshot_accessed","image_accessed","backup_accessed","metadata_accessed","identity_service_accessed","orchestration_api_accessed","tenant_network_accessed"), "true", "false")
| eval post_fault_behavior=if(rare_or_unapproved_compute_egress="true" OR control_plane_or_storage_access="true" OR normalized_network_action IN ("allowed","connected","proxied") OR normalized_event_type IN ("snapshot_accessed","image_accessed","backup_accessed","metadata_accessed","storage_accessed","identity_accessed","orchestration_accessed","tenant_accessed"), "true", "false")
| where kvm_compute_host="true"
| where approved_context_window!="true"
| where nested_virtualization_exposed="true" OR untrusted_or_high_risk_guest_context="true" OR kvm_host_fault="true"
| eval host_guest_cluster_key=coalesce(normalized_compute_node, normalized_host, normalized_host_id) . "|" . coalesce(normalized_compute_pool, lookup_compute_pool, "unknown_pool") . "|" . coalesce(normalized_tenant_id, "unknown_tenant") . "|" . coalesce(normalized_guest_id, "unknown_guest") . "|" . coalesce(normalized_image_id, "unknown_image")
| stats min(normalized_time) as first_seen max(normalized_time) as last_seen dc(normalized_host) as affected_host_count dc(normalized_guest_id) as affected_guest_count dc(normalized_tenant_id) as affected_tenant_count dc(normalized_image_id) as affected_image_count values(normalized_host) as affected_hosts values(normalized_host_id) as affected_host_ids values(normalized_compute_node) as compute_nodes values(normalized_compute_pool) as compute_pools values(normalized_guest_id) as guest_ids values(normalized_tenant_id) as tenant_ids values(normalized_project_id) as project_ids values(normalized_image_id) as image_ids values(normalized_workload_id) as workload_ids values(host_criticality) as host_criticality values(nested_virtualization_exposed) as nested_virtualization_exposed values(untrusted_or_high_risk_guest_context) as untrusted_or_high_risk_guest_context values(approved_nested_context) as approved_nested_context values(kvm_host_fault) as kvm_host_fault values(normalized_fault_type) as fault_types values(normalized_event_type) as event_types values(normalized_process) as processes values(normalized_parent_process) as parent_processes values(normalized_user) as users values(normalized_dest_host) as destination_hosts values(normalized_dest_ip) as destination_ips values(normalized_dest_domain) as destination_domains values(normalized_dest_port) as destination_ports values(normalized_dest_service) as destination_services values(normalized_dest_zone) as destination_zones values(normalized_protocol) as protocols values(destination_first_seen_status) as destination_first_seen_status values(destination_reputation) as destination_reputation values(ip_first_seen_status) as ip_first_seen_status values(ip_reputation) as ip_reputation values(sensitive_dependency_access) as sensitive_dependency_access values(rare_or_unapproved_compute_egress) as rare_or_unapproved_compute_egress values(control_plane_or_storage_access) as control_plane_or_storage_access values(post_fault_behavior) as post_fault_behavior by host_guest_cluster_key
| where mvfind(kvm_host_fault,"true")>=0
| where mvfind(post_fault_behavior,"true")>=0 OR affected_guest_count>=ENV_REPEATED_GUEST_LINKED_FAULT_MINIMUM OR affected_tenant_count>=ENV_REPEATED_TENANT_LINKED_FAULT_MINIMUM OR affected_image_count>=ENV_REPEATED_IMAGE_LINKED_FAULT_MINIMUM
| where mvfind(approved_nested_context,"true")<0 OR mvfind(post_fault_behavior,"true")>=0
| eval event_kind="kvm_guest_linked_host_instability_with_post_fault_compute_node_exposure"
| table first_seen last_seen host_guest_cluster_key affected_host_count affected_guest_count affected_tenant_count affected_image_count affected_hosts affected_host_ids compute_nodes compute_pools guest_ids tenant_ids project_ids image_ids workload_ids host_criticality nested_virtualization_exposed untrusted_or_high_risk_guest_context approved_nested_context kvm_host_fault fault_types event_types processes parent_processes users destination_hosts destination_ips destination_domains destination_ports destination_services destination_zones protocols destination_first_seen_status destination_reputation ip_first_seen_status ip_reputation sensitive_dependency_access rare_or_unapproved_compute_egress control_plane_or_storage_access post_fault_behavior event_kind

Elastic

Detection Viability Assessment

Elastic is highly viable for this threat when Linux KVM host telemetry, kernel logs, KVM logs, QEMU logs, libvirt logs, compute-agent logs, VM placement records, nested virtualization exposure inventory, tenant and image context, endpoint telemetry, network telemetry, storage logs, backup logs, identity logs, control-plane logs, and infrastructure health events are normalized into searchable data streams. Elastic should be used to correlate behavior sequences rather than isolated CVE names, vulnerable-kernel findings, public proof-of-concept references, scanner results, guest root conditions, single host crashes, or cloud control-plane events alone. The strongest Elastic detections correlate nested virtualization exposure and untrusted guest context with KVM host instability, compute-node failure, host evacuation, post-fault network activity, storage access, control-plane interaction, credential exposure, or cross-tenant exposure.

Rule

KVM Guest-Linked Host Fault and Post-Fault Virtualization Dependency Access

Rule Format

Behavioral correlation rule for Elastic environments using KVM host telemetry, endpoint telemetry, infrastructure logs, control-plane enrichment, and network or storage telemetry.

Detection Purpose

Detect KVM compute hosts where nested virtualization exposure, untrusted guest context, guest-side virtualization behavior, or high-risk workload context aligns with KVM host instability and post-fault access to sensitive virtualization dependencies. The rule identifies suspicious sequences involving KVM fault telemetry, compute-node crash or reboot behavior, host evacuation, unusual compute-host network activity, storage access, metadata access, orchestration access, identity access, tenant-network access, or repeated instability tied to a guest, tenant, image, workload, or compute pool.

Detection Logic

Identify KVM compute hosts that are nested-virtualization-enabled, self-managed, multi-tenant, private cloud, hosting-provider, CI, sandbox, malware-analysis, or cloud-hosted self-managed virtualization systems. Correlate those hosts with untrusted guest context, guest-side nested virtualization behavior, host-side KVM instability, compute-node failure, emergency evacuation, host quarantine, service restart behavior, or crash telemetry.

The rule should prioritize events where a KVM host with fault or boundary-stress context shows post-fault access to sensitive virtualization dependencies, including storage backends, image repositories, snapshot repositories, backup systems, metadata services, identity services, orchestration APIs, migration networks, management networks, tenant networks, monitoring services, or logging services. Higher confidence should apply when activity is rare, newly seen, unapproved, cross-zone, cross-tenant, or clustered around the same guest, tenant, image, workload, compute pool, or host group.

Required Telemetry

·        Elastic Agent, endpoint, syslog, Filebeat, Auditbeat, custom integrations, or equivalent telemetry from Linux KVM compute hosts.

·        Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, systemd journal records, crash records, infrastructure health logs, and host reboot telemetry.

·        VM placement, guest ID, tenant ID, project ID, image ID, workload ID, compute-node, compute-pool, migration, evacuation, host-disablement, and host-quarantine records.

·        Nested virtualization exposure inventory for x86 KVM hosts and compute pools.

·        Asset inventory identifying KVM compute hosts, self-managed KVM cloud hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, and multi-tenant virtualization hosts.

·        Network telemetry from compute hosts, including DNS, proxy, firewall, NDR, NetFlow, VPC Flow Logs, cloud flow logs, data-center flow logs, or Elastic network events where available.

·        Storage, backup, metadata, image repository, identity, orchestration, monitoring, logging, migration, and management-service access logs where available.

·        Destination enrichment for first-seen status, domain age, ASN, geography, reputation, service category, protocol, and internal zone.

·        Approved KVM maintenance, patching, reboot, migration, evacuation, failover, kernel-testing, CI, sandbox, malware-analysis, vendor-support, and incident-response windows.

·        Approved nested virtualization tenants, images, workloads, compute pools, and host groups.

·        Patch state, reboot validation, livepatch state, and vulnerability-management context for KVM compute hosts.

Engineering Implementation Instructions

Deploy this rule in hunt mode before alert mode. Validate Elastic data streams, index patterns, ECS mappings, ingest pipelines, transforms, endpoint tags, enrichment policies, value lists, exception lists, nested virtualization exposure fields, VM placement joins, KVM host inventory, sensitive dependency mappings, and post-fault window definitions before production use. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally.

The rule should not fire on vulnerable-kernel status, nested virtualization exposure, guest root access, host reboot, kernel panic, migration, evacuation, endpoint tag presence, or compute-node maintenance alone. Require KVM host-fault or boundary-stress context joined to nested virtualization exposure or untrusted guest context and at least one post-fault behavior condition involving sensitive dependency access, rare compute-host egress, storage access, backup access, metadata access, identity access, orchestration interaction, tenant exposure, management-plane access, or repeated guest-linked host instability.

DRI Assessment

The rule has strong detection resilience because it correlates durable Elastic-visible infrastructure behaviors rather than relying on a single CVE name, exploit string, host crash string, scanner finding, or proof-of-concept artifact. It remains useful across KVM guest-to-host escape variants that involve nested virtualization exposure, untrusted guest control, host-side KVM instability, compute-node failure, and post-fault access to sensitive virtualization dependencies. Its main weakness is dependence on ECS mapping quality, enrichment consistency, endpoint coverage, and availability of host-fault and placement context.

DRI

8.8

TCR Assessment

Operational telemetry coverage is strong when Elastic receives Linux KVM host logs, endpoint telemetry, kernel fault telemetry, VM placement records, compute-node state changes, network telemetry, and approved maintenance context. Full-telemetry coverage is very strong when Elastic also receives storage logs, backup logs, metadata service logs, identity logs, orchestration logs, patch validation records, incident-response artifacts, guest activity context, and nested virtualization exposure inventory.

Operational TCR

8.3

Full-Telemetry TCR

9.0

Limitations

·        This rule does not directly detect KVM shadow MMU corruption or in-kernel exploit execution.

·        This rule does not prove guest-to-host escape without KVM host-fault, placement, and post-fault behavior correlation.

·        This rule requires reliable KVM host inventory and compute-node identification.

·        This rule requires usable VM placement, tenant, image, workload, and compute-pool mapping.

·        This rule requires normalized KVM fault, crash, reboot, evacuation, migration, and host-disablement fields.

·        This rule requires consistent ECS mapping or local field abstraction across host, endpoint, network, storage, and control-plane telemetry.

·        This rule can generate noise during approved patching, live migration, host evacuation, kernel testing, CI, sandboxing, failover, backup, incident response, or vendor support activity.

·        This rule may miss activity where post-escape behavior remains local to the host and does not produce endpoint, network, storage, control-plane, or file-access telemetry.

·        This rule is weaker where cloud providers, managed hosting services, or sealed virtualization platforms do not expose host-fault telemetry, compute-host identity, or VM placement context.

·        This rule should not be used as a managed-cloud hypervisor escape detector unless the organization has self-managed KVM telemetry, provider-supplied host context, or sufficient infrastructure log enrichment.

Detection Query Pattern

Use this pattern as an implementation guide for Elastic environments that support KVM compute-host grouping, Linux kernel logs, KVM logs, QEMU logs, libvirt logs, compute-agent logs, endpoint telemetry, VM placement records, tenant and image enrichment, nested virtualization exposure inventory, host-fault context, crash and reboot records, host evacuation records, DNS logs, proxy logs, firewall logs, flow telemetry, storage logs, backup logs, metadata-service logs, identity logs, orchestration logs, maintenance-window context, approved nested-virtualization context, destination enrichment, sensitive-service joins, and post-fault correlation logic. Customer-specific data streams, index names, field names, ECS mappings, transforms, enrichment policies, value lists, exception lists, and local enriched field names should be implemented locally. The field names below are neutral implementation placeholders and must be mapped to the customer’s Elastic schema.

any where
event.dataset : ENV_KVM_VIRTUALIZATION_BOUNDARY_DATASET_PATTERN and
host.kvm.compute_host == true and
exception.approved_kvm_context != true and
(
host.kvm.nested_virtualization.exposed == true or
guest.risk.untrusted_or_high_risk == true or
guest.activity.nested_virtualization == true or
guest.activity.kernel_module == true or
host.kvm.fault.present == true
) and
(
host.kvm.fault.type in (
"kernel_panic",
"kernel_oops",
"soft_lockup",
"watchdog_event",
"crash_dump",
"compute_node_reboot",
"host_quarantine",
"compute_node_disablement",
"host_evacuated",
"kvm_service_restart",
"qemu_crash",
"libvirt_restart",
"kvm_mmu_fault",
"shadow_paging_fault",
"nested_virtualization_fault",
"memory_management_fault",
"unexpected_role_fault",
"invalid_page_state"
) or
event.message : ENV_KVM_HOST_FAULT_PATTERNS
) and
(
network.kvm.rare_or_unapproved_compute_egress == true or
kvm.dependency.sensitive_access == true or
kvm.storage.object.accessed == true or
kvm.backup.object.accessed == true or
kvm.metadata.service.accessed == true or
kvm.identity.service.accessed == true or
kvm.orchestration.api.accessed == true or
kvm.management.service.accessed == true or
kvm.tenant.network.accessed == true or
kvm.control_plane.action in (
"host_evacuated",
"compute_node_disabled",
"live_migration_started",
"failed_migration",
"snapshot_accessed",
"image_accessed",
"backup_accessed",
"metadata_accessed",
"identity_service_accessed",
"orchestration_api_accessed",
"tenant_network_accessed"
)
) and
(
destination.service in ENV_SENSITIVE_VIRTUALIZATION_DEPENDENCIES or
destination.zone in ENV_KVM_SENSITIVE_ZONES or
destination.ip in ENV_SENSITIVE_VIRTUALIZATION_DEPENDENCIES or
destination.domain in ENV_SENSITIVE_VIRTUALIZATION_DEPENDENCIES or
destination.first_seen_status in ("new", "rare") or
destination.domain_age_days < ENV_NEW_DOMAIN_AGE_DAYS or
destination.reputation in ("unknown", "suspicious", "malicious") or
destination.as.number in ENV_SUSPICIOUS_ASNS or
destination.geo.country_iso_code not in ENV_KVM_EXPECTED_EGRESS_GEOS or
destination.port in ENV_UNUSUAL_KVM_COMPUTE_EGRESS_PORTS or
network.protocol in ("ssh", "smb", "nfs", "object_storage", "database", "api", "raw_ip", "unknown", "tunnel", "file_transfer") or
network.behavior in (
"callback_like",
"beacon_like",
"tool_retrieval_like",
"unusual_internal_service_access",
"rare_external_connection",
"cross_zone_access",
"sensitive_service_access",
"lateral_movement_like",
"cross_tenant_access",
"management_plane_access",
"storage_access",
"backup_access",
"metadata_access"
)
) and
(
exception.approved_nested_virtualization_context != true or
network.kvm.rare_or_unapproved_compute_egress == true or
kvm.dependency.sensitive_access == true or
kvm.storage.object.accessed == true or
kvm.backup.object.accessed == true or
kvm.metadata.service.accessed == true or
kvm.identity.service.accessed == true or
kvm.orchestration.api.accessed == true or
kvm.management.service.accessed == true or
kvm.tenant.network.accessed == true
) and
(
kvm.correlation.same_compute_node == true or
kvm.correlation.same_compute_pool == true or
kvm.correlation.same_tenant == true or
kvm.correlation.same_guest == true or
kvm.correlation.same_image == true or
kvm.correlation.same_workload == true or
kvm.correlation.repeated_guest_linked_fault_count >= ENV_REPEATED_GUEST_LINKED_FAULT_MINIMUM or
kvm.correlation.repeated_tenant_linked_fault_count >= ENV_REPEATED_TENANT_LINKED_FAULT_MINIMUM or
kvm.correlation.repeated_image_linked_fault_count >= ENV_REPEATED_IMAGE_LINKED_FAULT_MINIMUM
)

QRadar

Detection Viability Assessment

QRadar is viable for this threat when KVM host telemetry, Linux kernel logs, KVM logs, QEMU logs, libvirt logs, compute-agent events, VM placement records, nested virtualization exposure inventory, tenant and image context, infrastructure health events, network telemetry, storage logs, backup logs, identity logs, orchestration logs, patch records, and incident-response context are mapped into QRadar DSM fields, custom properties, reference sets, reference maps, building blocks, and offense rules. QRadar should be used to correlate host-fault sequences and post-fault infrastructure behavior rather than isolated CVE names, vulnerable-kernel findings, public proof-of-concept references, scanner results, guest root conditions, single host crashes, or standalone cloud control-plane events. The strongest QRadar detection correlates KVM host instability with nested virtualization exposure, untrusted guest context, VM placement context, sensitive dependency access, rare compute-host egress, storage access, control-plane interaction, or repeated instability tied to a guest, tenant, image, workload, or compute pool.

Rule

KVM Guest-Linked Host Fault and Post-Fault Infrastructure Exposure Offense

Rule Format

Behavioral correlation rule using QRadar building blocks, reference sets, reference maps, DSM fields, custom properties, asset profiles, and offense logic.

Detection Purpose

Detect KVM compute hosts where nested virtualization exposure, untrusted guest context, or guest-linked workload behavior aligns with KVM host instability and post-fault infrastructure activity. The rule identifies suspicious sequences involving KVM fault telemetry, compute-node crash or reboot behavior, host evacuation, host quarantine, unusual compute-host network activity, storage access, metadata access, identity access, orchestration access, management-plane access, tenant-network access, or repeated instability tied to a guest, tenant, image, workload, or compute pool.

Detection Logic

Map KVM host, compute node, compute pool, guest, tenant, image, workload, host-fault, destination, storage, backup, identity, metadata, orchestration, and control-plane fields into QRadar custom properties and reference data. Use one building block to identify KVM host-fault context involving nested virtualization exposure or untrusted guest context. Use a second building block to identify post-fault compute-host activity involving sensitive virtualization dependencies, rare or unapproved egress, storage access, backup access, metadata access, identity access, orchestration interaction, tenant-network access, or management-plane access.

The offense should trigger only when host-fault context and post-fault behavior align by compute node, host, host ID, compute pool, tenant, guest, image, workload, or equivalent normalized virtualization lineage within a bounded window. Higher confidence should apply when the same guest, tenant, image, workload family, compute pool, or host group is associated with repeated KVM fault behavior or when post-fault activity reaches sensitive storage, backup, metadata, identity, orchestration, management, or tenant environments.

Required Telemetry

·        QRadar ingestion of Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, systemd journal records, infrastructure health logs, crash records, and host reboot telemetry.

·        VM placement, guest ID, tenant ID, project ID, image ID, workload ID, compute-node, compute-pool, migration, evacuation, host-disablement, and host-quarantine records.

·        Nested virtualization exposure inventory for x86 KVM hosts and compute pools.

·        Asset profiles identifying KVM compute hosts, self-managed KVM cloud hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, and multi-tenant virtualization hosts.

·        Network telemetry from compute hosts, including DNS, proxy, firewall, NDR, NetFlow, VPC Flow Logs, cloud flow logs, or data-center flow logs where available.

·        Storage, backup, metadata, image repository, identity, orchestration, monitoring, logging, migration, and management-service access logs where available.

·        QRadar reference sets and reference maps for KVM compute hosts, nested virtualization exposure, untrusted guests, high-risk tenants, high-risk images, sensitive dependencies, approved maintenance windows, approved nested virtualization context, approved egress, approved service mappings, and destination enrichment.

·        Destination enrichment for first-seen status, domain age, ASN, geography, reputation, service category, protocol, and internal zone.

·        Patch state, reboot validation, livepatch state, and vulnerability-management context for KVM compute hosts.

Engineering Implementation Instructions

Deploy this rule in test or low-severity offense mode before production alerting. Validate QRadar DSM parsing, custom properties, reference sets, reference maps, asset profiles, building blocks, offense rules, time windows, and event lineage fields before deployment. Map customer-specific log sources, DSM fields, custom properties, reference data, asset profiles, and local enrichment into the placeholder logic before enabling offense generation.

The rule should not generate an offense from vulnerable-kernel status, nested virtualization exposure, guest root access, host reboot, kernel panic, migration, evacuation, endpoint tag presence, or compute-node maintenance alone. Require a KVM host-fault building block joined to nested virtualization exposure or untrusted guest context and a post-fault behavior building block involving sensitive dependency access, rare compute-host egress, storage access, backup access, metadata access, identity access, orchestration interaction, tenant exposure, management-plane access, or repeated guest-linked host instability.

DRI Assessment

The rule has strong detection resilience because it correlates durable QRadar-visible infrastructure behaviors rather than relying on a single CVE name, exploit string, host crash string, scanner finding, or proof-of-concept artifact. It remains useful across KVM guest-to-host escape variants that involve nested virtualization exposure, untrusted guest control, host-side KVM instability, compute-node failure, and post-fault infrastructure access. Its main weakness is dependence on QRadar custom-property quality, reference-data freshness, VM placement context, and host-fault telemetry coverage.

DRI

8.6

TCR Assessment

Operational telemetry coverage is moderate to strong when QRadar receives KVM host logs, kernel fault telemetry, VM placement records, compute-node state changes, network telemetry, asset profiles, and approved maintenance context. Full-telemetry coverage is strong when QRadar also receives storage logs, backup logs, metadata service logs, identity logs, orchestration logs, patch validation records, incident-response artifacts, guest activity context, and nested virtualization exposure inventory.

Operational TCR

8.0

Full-Telemetry TCR

8.8

Limitations

·        This rule does not directly detect KVM shadow MMU corruption or in-kernel exploit execution.

·        This rule does not prove guest-to-host escape without KVM host-fault, placement, and post-fault behavior correlation.

·        This rule requires reliable QRadar parsing for KVM host, VM placement, tenant, image, workload, and compute-pool fields.

·        This rule requires accurate QRadar reference sets, reference maps, custom properties, and asset profiles.

·        This rule requires normalized KVM fault, crash, reboot, evacuation, migration, and host-disablement fields.

·        This rule can generate noise during approved patching, live migration, host evacuation, kernel testing, CI, sandboxing, failover, backup, incident response, or vendor support activity.

·        This rule may miss activity where post-escape behavior remains local to the host and does not produce network, storage, control-plane, identity, or file-access telemetry.

·        This rule is weaker where cloud providers, managed hosting services, or sealed virtualization platforms do not expose host-fault telemetry, compute-host identity, or VM placement context.

·        This rule should not be used as a managed-cloud hypervisor escape detector unless the organization has self-managed KVM telemetry, provider-supplied host context, or sufficient infrastructure log enrichment.

Detection Query Pattern

Use this pattern as implementation-ready QRadar correlation pseudologic and map all custom properties, reference sets, reference maps, DSM fields, building blocks, asset profiles, offense rules, and time windows to the target QRadar environment before deployment.

BUILDING BLOCK 1: KVM Host Fault With Nested Virtualization or High-Risk Guest Context

WHEN events are detected for the same KVM_Host, same Host_ID, same Compute_Node, same Compute_Pool, same Guest_ID, same Tenant_ID, same Project_ID, same Image_ID, same Workload_ID, or equivalent normalized virtualization lineage

WITHIN ENV_KVM_HOST_FAULT_CLUSTER_WINDOW

AND KVM_Host is not null

AND KVM_Host is contained in reference set ENV_KVM_COMPUTE_HOSTS

AND Asset_Profile is contained in reference set ENV_KVM_COMPUTE_ASSET_PROFILES

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_MAINTENANCE_WINDOWS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_PATCH_WINDOWS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_REBOOT_WINDOWS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_KERNEL_TESTING_WINDOWS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_CI_WINDOWS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_SANDBOX_WINDOWS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_INCIDENT_RESPONSE_WINDOWS

AND (
KVM_Host is contained in reference set ENV_KVM_NESTED_VIRTUALIZATION_EXPOSED_HOSTS
OR Compute_Pool is contained in reference set ENV_NESTED_VIRTUALIZATION_ENABLED_COMPUTE_POOLS
OR Nested_Virtualization_Enabled equals true
OR Guest_ID is contained in reference set ENV_UNTRUSTED_TENANT_GUESTS
OR Tenant_ID is contained in reference set ENV_UNTRUSTED_OR_EXTERNAL_TENANTS
OR Image_ID is contained in reference set ENV_HIGH_RISK_GUEST_IMAGES
OR Workload_ID is contained in reference set ENV_HIGH_RISK_VIRTUALIZATION_WORKLOADS
OR Guest_Nested_Virtualization_Activity equals true
OR Guest_Kernel_Module_Activity equals true
)

AND (
Event_Type is contained in reference set ENV_KVM_HOST_FAULT_EVENT_TYPES
OR Fault_Type is contained in reference set ENV_KVM_FAULT_TYPES
OR Health_Event is contained in reference set ENV_KVM_HOST_HEALTH_FAULT_EVENTS
OR Message matches reference set ENV_KVM_HOST_FAULT_PATTERNS
OR DSM_Event_Name is contained in reference set ENV_KVM_CRASH_REBOOT_OR_SERVICE_RESTART_EVENTS
OR Compute_Node_State is contained in reference set ENV_KVM_COMPUTE_NODE_FAILURE_STATES
)

AND NOT (
Guest_ID is contained in reference set ENV_APPROVED_NESTED_VIRTUALIZATION_GUESTS
AND Tenant_ID is contained in reference set ENV_APPROVED_NESTED_VIRTUALIZATION_TENANTS
AND Image_ID is contained in reference set ENV_APPROVED_NESTED_VIRTUALIZATION_IMAGES
AND Workload_ID is contained in reference set ENV_APPROVED_NESTED_VIRTUALIZATION_WORKLOADS
AND Event_Time is contained in reference set ENV_APPROVED_NESTED_VIRTUALIZATION_WINDOWS
)

THEN mark event as Building_Block_KVM_Host_Fault_With_Nested_Virtualization_Or_High_Risk_Guest_Context

BUILDING BLOCK 2: KVM Post-Fault Sensitive Dependency or Compute-Host Expansion

WHEN events are detected for the same KVM_Host, same Host_ID, same Compute_Node, same Compute_Pool, same Guest_ID, same Tenant_ID, same Project_ID, same Image_ID, same Workload_ID, same Destination_IP, same Destination_Domain, same Destination_Service, same Destination_Zone, or equivalent normalized virtualization and destination lineage

WITHIN ENV_KVM_FAULT_TO_POST_BEHAVIOR_WINDOW

AND Building_Block_KVM_Host_Fault_With_Nested_Virtualization_Or_High_Risk_Guest_Context occurred before KVM_Post_Fault_Activity_Time

AND KVM_Post_Fault_Activity_Time occurs within ENV_KVM_FAULT_TO_POST_BEHAVIOR_WINDOW after KVM_Host_Fault_Time

AND KVM_Host is not null

AND KVM_Host is contained in reference set ENV_KVM_COMPUTE_HOSTS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_MAINTENANCE_WINDOWS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_PATCH_WINDOWS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_REBOOT_WINDOWS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_MIGRATION_WINDOWS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_BACKUP_WINDOWS

AND Event_Time is not contained in reference set ENV_APPROVED_KVM_INCIDENT_RESPONSE_WINDOWS

AND (
Destination_Domain is contained in reference set ENV_SENSITIVE_VIRTUALIZATION_DEPENDENCIES
OR Destination_IP is contained in reference set ENV_SENSITIVE_VIRTUALIZATION_DEPENDENCIES
OR Destination_Service is contained in reference set ENV_SENSITIVE_VIRTUALIZATION_DEPENDENCIES
OR Destination_Zone is contained in reference set ENV_KVM_SENSITIVE_ZONES
OR Destination_First_Seen_Status is contained in reference set ENV_NEW_OR_RARE_DESTINATION_STATES
OR Destination_Reputation is contained in reference set ENV_SUSPICIOUS_OR_MALICIOUS_DESTINATION_REPUTATION
OR Destination_ASN is contained in reference set ENV_SUSPICIOUS_ASNS
OR Destination_Geo is not contained in reference map ENV_KVM_EXPECTED_EGRESS_GEOS for KVM_Host
OR Destination_Port is contained in reference set ENV_UNUSUAL_KVM_COMPUTE_EGRESS_PORTS
OR Network_Protocol is contained in reference set ENV_UNUSUAL_KVM_COMPUTE_PROTOCOLS
OR NDR_Behavior is contained in reference set ENV_KVM_CALLBACK_OR_EXPANSION_BEHAVIORS
OR Storage_Action is contained in reference set ENV_KVM_STORAGE_ACCESS_ACTIONS
OR Backup_Action is contained in reference set ENV_KVM_BACKUP_ACCESS_ACTIONS
OR Metadata_Action is contained in reference set ENV_KVM_METADATA_ACCESS_ACTIONS
OR Identity_Action is contained in reference set ENV_KVM_IDENTITY_ACCESS_ACTIONS
OR Orchestration_Action is contained in reference set ENV_KVM_ORCHESTRATION_ACCESS_ACTIONS
OR Control_Plane_Action is contained in reference set ENV_KVM_CONTROL_PLANE_POST_FAULT_ACTIONS
OR Tenant_Network_Access equals true
)

AND (
KVM_Host equals Prior_KVM_Host
OR Host_ID equals Prior_Host_ID
OR Compute_Node equals Prior_Compute_Node
OR Compute_Pool equals Prior_Compute_Pool
OR Guest_ID equals Prior_Guest_ID
OR Tenant_ID equals Prior_Tenant_ID
OR Project_ID equals Prior_Project_ID
OR Image_ID equals Prior_Image_ID
OR Workload_ID equals Prior_Workload_ID
OR Compute_Pool is contained in Prior_Affected_Compute_Pools
OR Tenant_ID is contained in Prior_Affected_Tenants
OR Image_ID is contained in Prior_Affected_Images
)

AND NOT (
Destination_Domain is contained in reference set ENV_APPROVED_KVM_EGRESS_DESTINATIONS
OR Destination_IP is contained in reference set ENV_APPROVED_KVM_EGRESS_DESTINATIONS
OR Destination_Service is contained in reference set ENV_APPROVED_KVM_SERVICE_MAPPINGS
OR Event_Time is contained in reference set ENV_APPROVED_KVM_MAINTENANCE_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_KVM_VENDOR_SUPPORT_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_KVM_INCIDENT_RESPONSE_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_KVM_MIGRATION_WINDOWS
OR Event_Time is contained in reference set ENV_APPROVED_KVM_BACKUP_WINDOWS
)

THEN generate offense with context:

KVM_Host,

Host_ID,

Compute_Node,

Compute_Pool,

Guest_ID,

Tenant_ID,

Project_ID,

Image_ID,

Workload_ID,

Nested_Virtualization_Enabled,

Guest_Nested_Virtualization_Activity,

Guest_Kernel_Module_Activity,

KVM_Host_Fault_Type,

KVM_Host_Fault_Message,

KVM_Host_Fault_Time,

Compute_Node_State,

Host_Health_Event,

Destination_Domain,

Destination_IP,

Destination_Port,

Destination_Service,

Destination_Zone,

Destination_Reputation,

Destination_First_Seen_Status,

Destination_ASN,

Destination_Geo,

Network_Protocol,

NDR_Behavior,

Storage_Action,

Backup_Action,

Metadata_Action,

Identity_Action,

Orchestration_Action,

Control_Plane_Action,

Tenant_Network_Access,

KVM_Post_Fault_Activity_Time,

Building_Block_KVM_Host_Fault_With_Nested_Virtualization_Or_High_Risk_Guest_Context

SIGMA

Detection Viability Assessment

SIGMA is viable for this threat when the target SIEM receives locally enriched KVM host, Linux kernel, virtualization, endpoint, network, VM placement, storage, backup, identity, orchestration, and control-plane telemetry. SIGMA should not attempt to detect KVM shadow MMU corruption, in-kernel exploit execution, or confirmed guest-to-host escape directly. Its value is providing a portable event-rule template for enriched environments that can identify KVM host-fault context, nested virtualization exposure, untrusted guest context, post-fault sensitive dependency access, rare compute-host egress, and repeated instability tied to the same guest, tenant, image, workload, host, or compute pool.

Rule

KVM Host Fault With Post-Fault Virtualization Dependency Access

Rule Format

Portable SIGMA event-rule template for SIEM environments with local KVM enrichment, host-fault correlation, VM placement context, and post-fault infrastructure dependency fields.

Detection Purpose

Detect locally enriched KVM compute-host events where nested virtualization exposure or untrusted guest context aligns with KVM host instability and post-fault access to sensitive virtualization dependencies. The rule identifies suspicious enriched event patterns involving KVM host faults, compute-node failure, host evacuation, sensitive storage access, backup access, metadata access, identity access, orchestration access, management-plane access, tenant-network access, rare compute-host egress, or repeated guest-linked host instability.

Detection Logic

Use SIGMA as a portable correlation template for environments where KVM host-fault, nested virtualization exposure, VM placement, untrusted guest, destination enrichment, post-fault activity, and exception fields have already been normalized by the target SIEM. The rule requires KVM compute-host scope, host-fault or boundary-stress context, nested virtualization or high-risk guest context, post-fault behavior, and correlation lineage before generating a high-severity alert.

The rule should not alert on vulnerable-kernel status, nested virtualization exposure, guest root access, host reboot, kernel panic, live migration, host evacuation, patch validation, or compute-node maintenance alone. Approved nested virtualization context should be used for triage and tuning, but it should not suppress the rule when KVM host-fault telemetry and post-fault sensitive dependency access are both present. Higher confidence should apply when the event shows post-fault access to storage, backup, metadata, identity, orchestration, management, tenant, or rare external destinations and is correlated to the same compute node, guest, tenant, image, workload, or compute pool.

Required Telemetry

·        Locally enriched SIEM events containing KVM compute-host identity, host role, compute pool, guest ID, tenant ID, project ID, image ID, and workload ID.

·        Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, systemd journal records, infrastructure health logs, crash records, and host reboot telemetry.

·        Nested virtualization exposure fields for x86 KVM hosts and compute pools.

·        VM placement, migration, evacuation, host-disablement, and host-quarantine records.

·        Network telemetry from compute hosts, including DNS, proxy, firewall, NDR, NetFlow, VPC Flow Logs, cloud flow logs, or data-center flow logs where available.

·        Storage, backup, metadata, image repository, identity, orchestration, monitoring, logging, migration, and management-service access logs where available.

·        Local enrichment fields for sensitive virtualization dependencies, rare destinations, suspicious destinations, expected egress geographies, unusual compute-host protocols, and network behavior.

·        Exception fields for approved maintenance, patching, reboot, migration, evacuation, failover, backup, kernel testing, CI, sandbox, malware-analysis, vendor support, and incident response.

·        Approved nested virtualization context fields for tuning, severity adjustment, and triage enrichment.

·        SIEM correlation fields linking same compute node, compute pool, guest, tenant, image, workload, host-fault window, or post-fault activity window.

Engineering Implementation Instructions

Deploy this SIGMA template only after mapping all placeholder fields and local enrichment fields to the target SIEM schema. Validate that the SIEM can populate KVM compute-host scope, host-fault context, nested virtualization exposure, guest and tenant context, post-fault dependency access, rare egress, approved exception fields, approved nested virtualization context, and correlation lineage fields before enabling the rule. The target SIEM should perform correlation, enrichment, and exception handling; the SIGMA rule should not be treated as a raw log-only detector.

The rule should be tested in hunt mode before alert mode. Tune approved KVM maintenance, patching, reboot, live migration, evacuation, backup, kernel testing, CI, sandbox, malware-analysis, vendor-support, incident-response, and approved nested virtualization contexts. Approved nested virtualization should reduce severity or support triage when post-fault behavior is absent or weak, but it should not suppress events that contain KVM host-fault telemetry and post-fault sensitive dependency access. Require post-fault behavior or repeated guest-linked fault clustering before high-severity promotion.

DRI Assessment

The rule has moderate-to-strong detection resilience because it focuses on enriched KVM host-fault correlation and post-fault infrastructure behavior rather than a single CVE name, exploit string, public proof-of-concept artifact, scanner result, or vulnerable-kernel finding. It remains useful across KVM guest-to-host escape variants that produce host instability followed by sensitive dependency access, rare compute-host egress, or repeated guest-linked faults. Its main weakness is that SIGMA depends heavily on local enrichment and cannot perform deep multi-source correlation unless the target SIEM already provides the required fields.

DRI

8.2

TCR Assessment

Operational telemetry coverage is moderate when the SIEM can enrich KVM host-fault events with compute-host identity, nested virtualization exposure, guest context, exception fields, and post-fault behavior indicators. Full-telemetry coverage is strong when the SIEM also receives VM placement data, storage logs, backup logs, identity logs, metadata logs, orchestration logs, destination enrichment, patch validation records, incident-response context, and repeated guest or tenant correlation fields.

Operational TCR

7.6

Full-Telemetry TCR

8.6

Limitations

·        This rule does not directly detect KVM shadow MMU corruption or in-kernel exploit execution.

·        This rule does not prove guest-to-host escape without host-fault, placement, and post-fault behavior correlation.

·        This rule requires local enrichment before deployment.

·        This rule requires the target SIEM to populate KVM host, guest, tenant, image, workload, compute-pool, host-fault, exception, and post-fault behavior fields.

·        This rule may not work as a raw log rule without preprocessing, transforms, or SIEM-side correlation.

·        This rule can generate noise during approved patching, live migration, host evacuation, kernel testing, CI, sandboxing, failover, backup, incident response, or vendor support activity.

·        This rule may miss activity where post-escape behavior remains local to the host and does not produce endpoint, network, storage, control-plane, or file-access telemetry.

·        This rule is weaker where cloud providers, managed hosting services, or sealed virtualization platforms do not expose host-fault telemetry, compute-host identity, or VM placement context.

·        This rule should not be used as a managed-cloud hypervisor escape detector unless the organization has self-managed KVM telemetry, provider-supplied host context, or sufficient infrastructure log enrichment.

Detection Query Pattern

Use this as a Sigma event-rule template. Map all fields and local enrichment fields to the target SIEM before deployment.

title: KVM Host Fault With Post-Fault Virtualization Dependency Access
id: 8b9d6b1a-81f4-4f9e-a37c-7f4e3b98d2c1
status: experimental
description: Detects locally enriched KVM compute-host events where host-fault telemetry aligns with nested virtualization or high-risk guest context and post-fault access to sensitive virtualization dependencies, rare compute-host egress, tenant networks, or repeated guest-linked instability.
references:
• Internal CyberDax detection model for KVM guest-to-host escape, virtualization boundary stress, and multi-tenant compute-host compromise review
author: CyberDax
date: 2026-07-09
logsource:
product: linux
service: kvm
detection:
selection_scope:
kvm.host.compute: true
kvm.host.id_present: true
kvm.correlation.host_fault_window_active: true
selection_fault:
kvm.host.fault.type:
o kernel_panic
o kernel_oops
o soft_lockup
o watchdog_event
o crash_dump
o compute_node_reboot
o host_quarantine
o compute_node_disablement
o host_evacuated
o kvm_service_restart
o qemu_crash
o libvirt_restart
selection_kvm_specific_fault:
kvm.fault.family:
o kvm_mmu_fault
o shadow_paging_fault
o nested_virtualization_fault
o memory_management_fault
o unexpected_role_fault
o invalid_page_state
o memory_corruption_indicator
selection_guest_context:
kvm.host.nested_virtualization.exposed: true
selection_high_risk_guest_context:
kvm.guest.risk:
o untrusted
o customer_managed
o externally_provisioned
o partner_managed
o ci_controlled
o sandboxed
o malware_analysis
o high_risk_image
selection_guest_virtualization_activity:
kvm.guest.activity:
o nested_hypervisor_activity
o nested_vm_lifecycle_activity
o virtualization_extension_use
o guest_kernel_module_activity
selection_post_fault_dependency:
kvm.correlation.post_fault_behavior_seen: true
kvm.dependency.sensitive_access: true
selection_post_fault_storage_or_backup:
kvm.storage.action:
o snapshot_accessed
o image_accessed
o storage_accessed
o backup_accessed
o datastore_accessed
o repository_accessed
selection_post_fault_control_plane:
kvm.control_plane.action:
o metadata_accessed
o identity_service_accessed
o orchestration_api_accessed
o management_service_accessed
o tenant_network_accessed
o compute_node_disabled
o live_migration_started
o failed_migration
selection_rare_compute_host_egress:
network.kvm.rare_or_unapproved_compute_egress: true
selection_sensitive_destination_zone:
destination.zone:
o management
o storage
o backup
o metadata
o identity
o orchestration
o migration
o tenant
o monitoring
o logging
selection_suspicious_destination:
destination.reputation:
o unknown
o suspicious
o malicious
selection_new_or_rare_destination:
destination.first_seen_status:
o new
o rare
selection_unusual_compute_host_protocol:
network.protocol:
o ssh
o smb
o nfs
o object_storage
o database
o api
o raw_ip
o unknown
o tunnel
o file_transfer
selection_network_expansion_behavior:
network.behavior:
o callback_like
o beacon_like
o tool_retrieval_like
o unusual_internal_service_access
o rare_external_connection
o cross_zone_access
o sensitive_service_access
o lateral_movement_like
o cross_tenant_access
o management_plane_access
o storage_access
o backup_access
o metadata_access
selection_correlation_lineage:
kvm.correlation.same_virtualization_lineage: true
selection_same_compute_node:
kvm.correlation.same_compute_node: true
selection_same_compute_pool:
kvm.correlation.same_compute_pool: true
selection_same_guest:
kvm.correlation.same_guest: true
selection_same_tenant:
kvm.correlation.same_tenant: true
selection_same_image:
kvm.correlation.same_image: true
selection_same_workload:
kvm.correlation.same_workload: true
selection_repeated_guest_faults:
kvm.correlation.repeated_guest_linked_fault_count_threshold_met: true
selection_repeated_tenant_faults:
kvm.correlation.repeated_tenant_linked_fault_count_threshold_met: true
selection_repeated_image_faults:
kvm.correlation.repeated_image_linked_fault_count_threshold_met: true
filter_approved_kvm_maintenance:
exception.approved_kvm_maintenance_window: true
filter_approved_kvm_patch:
exception.approved_kvm_patch_window: true
filter_approved_kvm_reboot:
exception.approved_kvm_reboot_window: true
filter_approved_kvm_migration:
exception.approved_kvm_migration_window: true
filter_approved_kvm_backup:
exception.approved_kvm_backup_window: true
filter_approved_kvm_kernel_testing:
exception.approved_kvm_kernel_testing_window: true
filter_approved_kvm_ci:
exception.approved_kvm_ci_window: true
filter_approved_kvm_sandbox:
exception.approved_kvm_sandbox_window: true
filter_approved_kvm_vendor_support:
exception.approved_kvm_vendor_support_window: true
filter_approved_kvm_incident_response:
exception.approved_kvm_incident_response_window: true
condition: selection_scope and (selection_fault or selection_kvm_specific_fault) and (selection_guest_context or selection_high_risk_guest_context or selection_guest_virtualization_activity) and (selection_post_fault_dependency or selection_post_fault_storage_or_backup or selection_post_fault_control_plane or selection_rare_compute_host_egress or selection_sensitive_destination_zone or selection_suspicious_destination or selection_new_or_rare_destination or selection_unusual_compute_host_protocol or selection_network_expansion_behavior) and (selection_correlation_lineage or selection_same_compute_node or selection_same_compute_pool or selection_same_guest or selection_same_tenant or selection_same_image or selection_same_workload or selection_repeated_guest_faults or selection_repeated_tenant_faults or selection_repeated_image_faults) and not 1 of filter_approved_kvm_*
fields:
• kvm.host.id
• kvm.host.name
• kvm.host.compute
• kvm.host.role
• kvm.compute_node
• kvm.compute_pool
• kvm.guest.id
• kvm.tenant.id
• kvm.project.id
• kvm.image.id
• kvm.workload.id
• kvm.host.nested_virtualization.exposed
• kvm.guest.activity
• kvm.host.fault.type
• kvm.fault.family
• kvm.host.fault.message
• kvm.host.fault.time
• kvm.compute_node.state
• kvm.correlation.host_fault_window_active
• kvm.correlation.post_fault_behavior_seen
• kvm.correlation.same_virtualization_lineage
• kvm.correlation.same_compute_node
• kvm.correlation.same_compute_pool
• kvm.correlation.same_guest
• kvm.correlation.same_tenant
• kvm.correlation.same_image
• kvm.correlation.same_workload
• kvm.correlation.repeated_guest_linked_fault_count
• kvm.correlation.repeated_tenant_linked_fault_count
• kvm.correlation.repeated_image_linked_fault_count
• kvm.dependency.sensitive_access
• kvm.storage.action
• kvm.control_plane.action
• exception.approved_nested_virtualization_context
• destination.ip
• destination.domain
• destination.port
• destination.service
• destination.zone
• destination.reputation
• destination.first_seen_status
• destination.as.number
• destination.geo.country_name
• network.protocol
• network.behavior
falsepositives:
• Approved KVM patching, reboot, live migration, evacuation, failover, backup, storage maintenance, kernel testing, or host recovery activity
• Approved nested virtualization workflows where host-fault context and post-fault sensitive dependency access are absent or weak
• Approved CI, sandbox, malware-analysis, nested virtualization validation, red-team testing, incident-response review, or vendor-support workflow
• Provider-managed or sealed virtualization infrastructure where host-fault context is incomplete or delayed
• Host instability caused by hardware failure, storage failure, driver defects, resource exhaustion, planned maintenance, or unrelated kernel defects
level: high

YARA

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the report’s detection model is behavioral, sequence-based, virtualization-boundary driven, host-fault driven, VM-placement dependent, nested-virtualization dependent, infrastructure-correlation based, post-fault activity based, compute-node context based, egress-correlation based, storage-access based, identity-access based, orchestration-access based, and tenant-impact based rather than static-file, malware-signature, or artifact-matching based.

YARA may provide limited supporting value only if a confirmed malicious guest artifact, host-side payload, exploit harness, loader, dropper, script artifact, archive artifact, memory artifact, credential-harvesting artifact, diagnostic-bundle payload, malicious kernel module, persistence artifact, post-escape tool, or reusable malware family artifact is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

AWS

Detection Viability Assessment

AWS is viable for this threat only in constrained environments where self-managed KVM compute hosts, cloud-hosted KVM systems, nested-virtualization-enabled workloads, CI KVM runners, sandbox hosts, malware-analysis hosts, or private-cloud virtualization components run in AWS and their host telemetry is ingested into AWS analytics, Security Lake, CloudWatch, OpenSearch, a SIEM, or an equivalent correlation platform. AWS-native telemetry cannot directly detect KVM shadow MMU corruption, in-kernel exploit execution, or guest-to-host escape inside AWS-managed hypervisor infrastructure. Its value is correlating self-managed KVM host-fault context, nested virtualization exposure, guest or workload context, post-fault AWS API activity, VPC flow behavior, Route 53 activity, storage access, identity activity, security group changes, network-route changes, backup access, snapshot access, or workload expansion after suspected virtualization boundary stress.

Rule

AWS Self-Managed KVM Host Fault With Post-Fault Cloud Resource Expansion

Rule Format

Behavioral correlation rule for AWS environments using CloudTrail, AWS Config, GuardDuty, Security Hub, VPC Flow Logs, Route 53 Resolver logs, CloudWatch, Security Lake, EC2 inventory, EBS events, IAM activity, backup activity, and self-managed KVM host-context enrichment.

Detection Purpose

Detect AWS environments where self-managed KVM host-fault telemetry or virtualization-boundary stress context aligns with post-fault AWS activity involving identity, storage, snapshot, backup, network, security group, routing, metadata, workload, or cross-account exposure. The rule identifies suspicious AWS-side behavior after KVM compute-host instability, nested virtualization exposure, guest-linked fault activity, host reboot, host quarantine, failed evacuation, unusual compute-host egress, or repeated instability tied to the same EC2 instance, account, VPC, subnet, tenant, image, workload, or compute pool.

Detection Logic

Normalize self-managed KVM host telemetry with AWS account, region, VPC, subnet, EC2 instance, AMI, Auto Scaling group, security group, route table, IAM role, EBS volume, snapshot, S3 bucket, backup vault, Route 53 Resolver, and VPC Flow Log context. Correlate KVM host-fault or boundary-stress events with CloudTrail management events, AWS Config changes, GuardDuty findings, Security Hub findings, VPC Flow anomalies, Route 53 Resolver anomalies, EBS snapshot activity, backup activity, IAM activity, and network-control changes within a bounded post-fault window.

The rule should prioritize activity where a self-managed KVM host or related AWS workload shows post-fault access to sensitive storage, EBS snapshots, AMIs, backup vaults, IAM roles, metadata paths, security groups, route tables, network ACLs, load balancers, VPC peering, transit gateway paths, S3 buckets, secrets, or cross-account resources. Higher confidence should apply when activity is performed by unusual identities, unexpected roles, rare source IPs, unexpected regions, newly seen destinations, suspicious GuardDuty/Security Hub findings, or changes affecting sensitive AWS resources.

Required Telemetry

·        Self-managed KVM host telemetry ingested into AWS analytics, Security Lake, CloudWatch, OpenSearch, SIEM, or equivalent correlation tooling.

·        Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, infrastructure health logs, crash records, host reboot telemetry, and host evacuation or quarantine records from self-managed KVM systems.

·        AWS CloudTrail management and data events where available.

·        AWS Config resource-change events.

·        GuardDuty findings and Security Hub findings.

·        VPC Flow Logs, Route 53 Resolver query logs, NAT gateway logs, load-balancer logs, firewall logs, NDR logs, or proxy logs where available.

·        EC2 inventory, instance IDs, AMI IDs, Auto Scaling group membership, VPC IDs, subnet IDs, security group IDs, route table IDs, IAM role ARNs, EBS volume IDs, snapshot IDs, S3 bucket names, backup vault names, and account mappings.

·        Nested virtualization exposure inventory for self-managed KVM hosts running in AWS.

·        VM placement, guest ID, tenant ID, project ID, image ID, workload ID, compute-node, and compute-pool context for the self-managed KVM layer.

·        Approved AWS automation roles, CI/CD roles, infrastructure-as-code roles, security tooling roles, incident-response identities, backup identities, managed-service identities, source IP allowlists, expected regions, expected user agents, and maintenance windows.

·        Destination enrichment for first-seen status, domain age, ASN, geography, reputation, service category, protocol, and internal zone.

Engineering Implementation Instructions

Deploy this rule in hunt mode before alert mode. Validate that AWS telemetry can be joined with self-managed KVM host context before enabling production alerting. Map all CloudTrail fields, AWS Config fields, GuardDuty fields, Security Hub fields, VPC Flow Log fields, Route 53 Resolver fields, EC2 inventory fields, EBS fields, IAM fields, backup fields, KVM host-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, network-change baselines, and time windows to the target AWS analytics or SIEM environment before deployment.

This rule should not be used as a detector for AWS-managed hypervisor compromise. It should not fire on vulnerable-kernel status, nested virtualization exposure, EC2 reboot, EC2 stop/start, host maintenance, security group change, IAM activity, snapshot access, backup access, or VPC flow anomaly alone. Require self-managed KVM host-fault or boundary-stress context joined to suspicious AWS-side post-fault behavior, sensitive resource access, rare compute-host egress, identity deviation, network-control change, storage access, backup access, snapshot access, or repeated guest-linked instability.

DRI Assessment

The rule has moderate-to-strong detection resilience because it correlates durable AWS-side behaviors with self-managed KVM host-fault context rather than relying on a single CVE name, exploit string, public proof-of-concept artifact, scanner finding, vulnerable-kernel state, or standalone AWS control-plane event. It remains useful across KVM guest-to-host escape variants where suspected host instability is followed by AWS identity activity, storage access, snapshot access, backup access, network modification, rare egress, or workload expansion. Its main weakness is that AWS-native telemetry cannot confirm KVM in-kernel exploitation and depends on self-managed host telemetry or provider-supplied host context.

DRI

8.1

TCR Assessment

Operational telemetry coverage is moderate when CloudTrail, AWS Config, VPC Flow Logs, EC2 inventory, GuardDuty, Security Hub, and self-managed KVM host-fault context are available. Full-telemetry coverage is strong when AWS telemetry is joined with KVM host logs, VM placement context, nested virtualization exposure, EBS activity, backup logs, IAM activity, Route 53 Resolver logs, S3 data events, Security Lake, NDR, incident-response records, and approved automation baselines.

Operational TCR

7.7

Full-Telemetry TCR

8.8

Limitations

·        This rule does not detect AWS-managed hypervisor exploitation.

·        This rule does not directly detect KVM shadow MMU corruption or in-kernel exploit execution.

·        This rule does not prove guest-to-host escape without self-managed KVM host-fault, placement, and post-fault behavior correlation.

·        This rule requires self-managed KVM host telemetry, provider-supplied host context, or SIEM-normalized KVM host context joined with AWS logs.

·        This rule requires accurate AWS account, EC2, VPC, subnet, security group, IAM role, EBS, snapshot, backup, and workload mapping.

·        This rule can generate noise during approved infrastructure-as-code changes, CI/CD deployment, backup operations, incident response, patching, host migration, failover, autoscaling, or managed-service activity.

·        This rule may miss activity where post-escape behavior remains local to the KVM host and does not produce AWS API, network, storage, identity, or flow telemetry.

·        This rule is weaker where AWS logs are incomplete, CloudTrail data events are disabled, VPC Flow Logs are unavailable, self-managed host telemetry is absent, or KVM placement context is not retained.

·        This rule should not be treated as a managed-cloud hypervisor escape detector unless AWS or the provider supplies relevant host-level evidence.

Detection Query Pattern

Use this pattern as implementation-ready AWS correlation pseudologic and map all CloudTrail fields, AWS Config fields, GuardDuty fields, Security Hub fields, VPC Flow Log fields, Route 53 Resolver fields, EC2 inventory fields, EBS fields, IAM fields, backup fields, KVM host-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, network-change baselines, and time windows to the target AWS analytics or SIEM environment before deployment.

kvm_aws_context represents a normalized correlation view derived from self-managed KVM host telemetry, Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, infrastructure health logs, crash records, host reboot records, nested virtualization exposure inventory, VM placement data, guest and tenant context, workload mappings, EC2 inventory, AWS account mapping, VPC mapping, subnet mapping, security group mapping, IAM role mapping, EBS volume mapping, snapshot mapping, backup vault mapping, Route 53 Resolver mapping, VPC Flow Log context, AWS Config records, CloudTrail records, GuardDuty findings, Security Hub findings, destination enrichment, and approved maintenance context. Local teams must create, map, or enrich this view before deploying the AWS cloud correlation pattern.

FROM aws_cloudtrail_management_events,
aws_cloudtrail_data_events,
aws_config_events,
aws_guardduty_findings,
aws_securityhub_findings,
aws_vpc_flow_logs,
aws_route53_resolver_logs,
aws_ec2_inventory,
aws_ebs_events,
aws_backup_events,
aws_s3_data_events,
kvm_aws_context

WHERE aws.account_id IS NOT NULL

AND kvm_aws_context.event_time IS NOT NULL

AND aws.event_time BETWEEN kvm_aws_context.event_time AND kvm_aws_context.event_time + ENV_KVM_TO_AWS_POST_FAULT_WINDOW

AND kvm_aws_context.kvm_host_id IS NOT NULL

AND kvm_aws_context.self_managed_kvm_host = true

AND kvm_aws_context.aws_account_id = aws.account_id

AND (
kvm_aws_context.ec2_instance_id = aws.ec2_instance_id
OR kvm_aws_context.instance_id = aws.instance_id
OR kvm_aws_context.private_ip = aws.source_ip
OR kvm_aws_context.private_ip = aws.destination_ip
OR kvm_aws_context.vpc_id = aws.vpc_id
OR kvm_aws_context.subnet_id = aws.subnet_id
OR kvm_aws_context.security_group_id = aws.security_group_id
OR kvm_aws_context.route_table_id = aws.route_table_id
OR kvm_aws_context.iam_role_arn = aws.role_arn
OR kvm_aws_context.ebs_volume_id = aws.volume_id
OR kvm_aws_context.snapshot_id = aws.snapshot_id
OR kvm_aws_context.backup_vault_name = aws.backup_vault_name
OR kvm_aws_context.s3_bucket_name = aws.bucket_name
OR kvm_aws_context.workload_id = aws.workload_id
OR kvm_aws_context.destination_ip = aws.source_ip
OR kvm_aws_context.destination_domain = aws.domain_name
)

AND kvm_aws_context.type IN (
"kvm_host_fault_after_untrusted_guest_activity",
"kvm_host_fault_after_nested_virtualization_activity",
"kvm_shadow_paging_or_mmu_fault_context",
"kvm_compute_node_reboot_after_guest_activity",
"kvm_host_quarantine_or_eviction_after_fault",
"kvm_failed_migration_or_evacuated_host_context",
"kvm_post_fault_rare_compute_host_egress",
"kvm_post_fault_sensitive_dependency_access",
"kvm_repeated_guest_linked_host_faults",
"kvm_repeated_tenant_linked_host_faults",
"kvm_repeated_image_linked_host_faults"
)

AND (
aws.event_name IN ENV_AWS_IDENTITY_ACCESS_EVENTS
OR aws.event_name IN ENV_AWS_SECURITY_GROUP_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_NETWORK_ACL_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_ROUTE_TABLE_MODIFICATION_EVENTS
OR aws.event_name IN ENV_AWS_EC2_INSTANCE_CONTROL_EVENTS
OR aws.event_name IN ENV_AWS_EBS_VOLUME_OR_SNAPSHOT_ACCESS_EVENTS
OR aws.event_name IN ENV_AWS_AMI_OR_IMAGE_ACCESS_EVENTS
OR aws.event_name IN ENV_AWS_BACKUP_ACCESS_EVENTS
OR aws.event_name IN ENV_AWS_S3_SENSITIVE_DATA_EVENTS
OR aws.event_name IN ENV_AWS_SECRETS_OR_PARAMETER_ACCESS_EVENTS
OR aws.event_name IN ENV_AWS_CLOUDWATCH_LOG_ACCESS_EVENTS
OR aws.event_name IN ENV_AWS_CROSS_ACCOUNT_ACCESS_EVENTS
OR aws.guardduty_finding_type IN ENV_RELEVANT_KVM_POST_FAULT_GUARDDUTY_FINDINGS
OR aws.securityhub_finding_type IN ENV_RELEVANT_KVM_POST_FAULT_SECURITYHUB_FINDINGS
OR aws.vpc_flow_anomaly_type IN ENV_RELEVANT_KVM_POST_FAULT_VPC_FLOW_ANOMALIES
OR aws.route53_query_risk IN ENV_RELEVANT_KVM_POST_FAULT_ROUTE53_QUERY_RISKS
)

AND (
aws.source_ip NOT IN ENV_APPROVED_AWS_ADMIN_SOURCE_IPS
OR aws.user_agent NOT IN ENV_EXPECTED_AWS_USER_AGENTS_BY_ROLE
OR aws.aws_region NOT IN ENV_EXPECTED_AWS_REGIONS_BY_ROLE
OR aws.role_arn NOT IN ENV_EXPECTED_AWS_ROLES_BY_USER
OR aws.user_identity_arn NOT IN ENV_EXPECTED_AWS_IDENTITIES_BY_WORKLOAD
OR aws.security_group_id IN ENV_SENSITIVE_AWS_SECURITY_GROUPS
OR aws.route_table_id IN ENV_SENSITIVE_AWS_ROUTE_TABLES
OR aws.subnet_id IN ENV_SENSITIVE_AWS_SUBNETS
OR aws.vpc_id IN ENV_SENSITIVE_AWS_VPCS
OR aws.volume_id IN ENV_SENSITIVE_AWS_EBS_VOLUMES
OR aws.snapshot_id IN ENV_SENSITIVE_AWS_SNAPSHOTS
OR aws.backup_vault_name IN ENV_SENSITIVE_AWS_BACKUP_VAULTS
OR aws.bucket_name IN ENV_SENSITIVE_AWS_BUCKETS
OR aws.secret_id IN ENV_SENSITIVE_AWS_SECRETS
OR aws.parameter_name IN ENV_SENSITIVE_AWS_PARAMETERS
OR aws.vpc_flow_anomaly_type IN ENV_HIGH_RISK_KVM_POST_FAULT_VPC_FLOW_ANOMALIES
OR aws.route53_query_risk IN ENV_HIGH_RISK_KVM_POST_FAULT_ROUTE53_QUERY_RISKS
OR aws.event_name IN ENV_HIGH_RISK_AWS_KVM_POST_FAULT_EVENTS_REQUIRING_REVIEW
)

AND NOT (
aws.role_arn IN ENV_APPROVED_CICD_OR_IAC_ROLES
AND aws.source_ip IN ENV_APPROVED_CICD_OR_IAC_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_CICD_OR_IAC_AWS_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
aws.user_identity_arn IN ENV_APPROVED_AWS_AUTOMATION_IDENTITIES
AND aws.source_ip IN ENV_APPROVED_AWS_AUTOMATION_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_AWS_AUTOMATION_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
aws.user_identity_arn IN ENV_APPROVED_SECURITY_TOOLING_IDENTITIES
AND aws.source_ip IN ENV_APPROVED_SECURITY_TOOLING_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_SECURITY_TOOLING_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
aws.user_identity_arn IN ENV_APPROVED_INCIDENT_RESPONSE_IDENTITIES
AND aws.source_ip IN ENV_APPROVED_INCIDENT_RESPONSE_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_INCIDENT_RESPONSE_AWS_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
aws.role_arn IN ENV_APPROVED_MANAGED_SERVICE_OR_PLATFORM_ROLES
AND aws.source_ip IN ENV_APPROVED_MANAGED_SERVICE_OR_PLATFORM_SOURCE_IPS
AND aws.event_name IN ENV_APPROVED_MANAGED_SERVICE_OR_PLATFORM_AWS_EVENTS
AND aws.resource_id NOT IN ENV_SENSITIVE_AWS_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
aws.event_time IN ENV_APPROVED_KVM_AWS_PATCH_WINDOWS
OR aws.event_time IN ENV_APPROVED_KVM_AWS_MAINTENANCE_WINDOWS
OR aws.event_time IN ENV_APPROVED_KVM_AWS_BACKUP_WINDOWS
OR aws.event_time IN ENV_APPROVED_KVM_AWS_MIGRATION_WINDOWS
OR aws.event_time IN ENV_APPROVED_KVM_AWS_INCIDENT_RESPONSE_WINDOWS
)

AND aws.user_identity_arn NOT IN ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS

GROUP BY aws.account_id,
aws.normalized_user_id,
aws.user_identity_arn,
aws.role_arn,
aws.source_ip,
aws.user_agent,
aws.aws_region,
aws.event_name,
aws.resource_id,
aws.ec2_instance_id,
aws.vpc_id,
aws.subnet_id,
aws.security_group_id,
aws.route_table_id,
aws.volume_id,
aws.snapshot_id,
aws.backup_vault_name,
aws.bucket_name,
aws.secret_id,
aws.parameter_name,
kvm_aws_context.kvm_host_id,
kvm_aws_context.kvm_host_name,
kvm_aws_context.compute_node,
kvm_aws_context.compute_pool,
kvm_aws_context.guest_id,
kvm_aws_context.tenant_id,
kvm_aws_context.image_id,
kvm_aws_context.workload_id,
kvm_aws_context.type

EMIT alert WHEN

count_distinct(aws.event_name) >= ENV_MIN_DISTINCT_AWS_KVM_POST_FAULT_EVENTS

OR aws.event_name IN ENV_HIGH_RISK_AWS_KVM_POST_FAULT_EVENTS_REQUIRING_REVIEW

OR aws.guardduty_finding_type IN ENV_RELEVANT_KVM_POST_FAULT_GUARDDUTY_FINDINGS

OR aws.securityhub_finding_type IN ENV_RELEVANT_KVM_POST_FAULT_SECURITYHUB_FINDINGS

OR aws.vpc_flow_anomaly_type IN ENV_HIGH_RISK_KVM_POST_FAULT_VPC_FLOW_ANOMALIES

OR aws.route53_query_risk IN ENV_HIGH_RISK_KVM_POST_FAULT_ROUTE53_QUERY_RISKS

Azure

Detection Viability Assessment

Azure is viable for this threat only in constrained environments where self-managed KVM compute hosts, cloud-hosted KVM systems, nested-virtualization-enabled workloads, CI KVM runners, sandbox hosts, malware-analysis hosts, or private-cloud virtualization components run in Azure and their host telemetry is ingested into Microsoft Sentinel, Log Analytics, Defender for Cloud, Azure Monitor, a SIEM, a data lake, or an equivalent correlation platform. Azure-native telemetry cannot directly detect KVM shadow MMU corruption, in-kernel exploit execution, or guest-to-host escape inside Azure-managed hypervisor infrastructure. Its value is correlating self-managed KVM host-fault context, nested virtualization exposure, guest or workload context, post-fault Azure activity, NSG flow behavior, Azure Firewall behavior, DNS activity, storage access, identity activity, route changes, network security changes, Key Vault access, backup access, disk or snapshot access, or workload expansion after suspected virtualization boundary stress.

Rule

Azure Self-Managed KVM Host Fault With Post-Fault Resource and Network Expansion

Rule Format

Behavioral correlation rule for Azure environments using Azure Activity logs, Azure Resource Manager events, Defender for Cloud alerts, Sentinel incidents, Network Security Group flow logs, Azure Firewall logs, DNS logs, Key Vault logs, Storage logs, VM inventory, managed identity context, role assignment activity, disk or snapshot activity, backup activity, and self-managed KVM host-context enrichment.

Detection Purpose

Detect Azure environments where self-managed KVM host-fault telemetry or virtualization-boundary stress context aligns with post-fault Azure activity involving identity, storage, disk, snapshot, backup, Key Vault, network security groups, route tables, DNS, firewall policy, workload, or cross-subscription exposure. The rule identifies suspicious Azure-side behavior after KVM compute-host instability, nested virtualization exposure, guest-linked fault activity, host reboot, host quarantine, failed evacuation, unusual compute-host egress, or repeated instability tied to the same VM, tenant, subscription, resource group, VNet, subnet, guest, image, workload, or compute pool.

Detection Logic

Normalize self-managed KVM host telemetry with Azure tenant, subscription, resource group, VM, image, managed identity, service principal, role assignment, VNet, subnet, network security group, route table, firewall policy, disk, snapshot, Storage account, Key Vault, backup vault, DNS zone, and NSG flow context. Correlate KVM host-fault or boundary-stress events with Azure Activity logs, Azure Resource Manager events, Defender for Cloud alerts, Sentinel incidents, Network Security Group flow anomalies, Azure Firewall activity, DNS query risk, Key Vault access, Storage access, disk or snapshot activity, backup activity, identity activity, and network-control changes within a bounded post-fault window.

The rule should prioritize activity where a self-managed KVM host or related Azure workload shows post-fault access to sensitive disks, snapshots, Storage accounts, backup vaults, Key Vault secrets, managed identities, service principals, role assignments, network security groups, route tables, firewall policies, DNS zones, private endpoints, VNets, subnets, or cross-subscription resources. Higher confidence should apply when activity is performed by unusual identities, unexpected service principals, unexpected managed identities, rare source IPs, unexpected tenants or subscriptions, unusual user agents, suspicious Defender for Cloud or Sentinel findings, or changes affecting sensitive Azure resources.

Required Telemetry

·        Self-managed KVM host telemetry ingested into Sentinel, Log Analytics, Azure Monitor, Defender for Cloud, SIEM, data lake, or equivalent correlation tooling.

·        Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, infrastructure health logs, crash records, host reboot telemetry, and host evacuation or quarantine records from self-managed KVM systems.

·        Azure Activity logs and Azure Resource Manager events.

·        Defender for Cloud alerts and Sentinel incidents where available.

·        Network Security Group flow logs, Azure Firewall logs, DNS logs, private endpoint logs, proxy logs, NDR logs, or data-center flow logs where available.

·        Azure VM inventory, VM IDs, image IDs, managed identity IDs, service principal IDs, tenant IDs, subscription IDs, resource group names, VNet IDs, subnet IDs, network security group IDs, route table IDs, firewall policy IDs, disk IDs, snapshot IDs, Storage account names, Key Vault names, backup vault names, DNS zone IDs, and workload mappings.

·        Nested virtualization exposure inventory for self-managed KVM hosts running in Azure.

·        VM placement, guest ID, tenant ID, project ID, image ID, workload ID, compute-node, and compute-pool context for the self-managed KVM layer.

·        Approved Azure automation identities, CI/CD identities, infrastructure-as-code identities, security tooling identities, incident-response identities, backup identities, platform or managed-service identities, source IP allowlists, expected tenants, expected subscriptions, expected roles, expected user agents, and maintenance windows.

·        Destination enrichment for first-seen status, domain age, ASN, geography, reputation, service category, protocol, and internal zone.

Engineering Implementation Instructions

Deploy this rule in hunt mode before alert mode. Validate that Azure telemetry can be joined with self-managed KVM host context before enabling production alerting. Map all Azure Activity fields, Azure Resource Manager fields, Defender for Cloud fields, Sentinel fields, Network Security Group flow fields, Azure Firewall fields, DNS fields, Key Vault fields, Storage fields, VM inventory fields, disk and snapshot fields, backup fields, identity fields, KVM host-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, network-change baselines, and time windows to the target Sentinel, SIEM, data-lake, or analytics environment before deployment.

This rule should not be used as a detector for Azure-managed hypervisor compromise. It should not fire on vulnerable-kernel status, nested virtualization exposure, Azure VM reboot, Azure VM stop/start, platform maintenance, NSG change, role assignment activity, disk access, snapshot access, backup access, Key Vault access, Storage access, or NSG flow anomaly alone. Require self-managed KVM host-fault or boundary-stress context joined to suspicious Azure-side post-fault behavior, sensitive resource access, rare compute-host egress, identity deviation, network-control change, storage access, backup access, disk or snapshot access, Key Vault access, or repeated guest-linked instability.

DRI Assessment

The rule has moderate-to-strong detection resilience because it correlates durable Azure-side behaviors with self-managed KVM host-fault context rather than relying on a single CVE name, exploit string, public proof-of-concept artifact, scanner finding, vulnerable-kernel state, or standalone Azure control-plane event. It remains useful across KVM guest-to-host escape variants where suspected host instability is followed by Azure identity activity, Storage access, disk or snapshot access, backup access, Key Vault access, network modification, rare egress, or workload expansion. Its main weakness is that Azure-native telemetry cannot confirm KVM in-kernel exploitation and depends on self-managed host telemetry or provider-supplied host context.

DRI

8.1

TCR Assessment

Operational telemetry coverage is moderate when Azure Activity logs, Azure Resource Manager events, NSG flow logs, VM inventory, Defender for Cloud, Sentinel, and self-managed KVM host-fault context are available. Full-telemetry coverage is strong when Azure telemetry is joined with KVM host logs, VM placement context, nested virtualization exposure, disk and snapshot activity, backup logs, Key Vault logs, Storage logs, identity activity, DNS logs, Azure Firewall logs, NDR, incident-response records, and approved automation baselines.

Operational TCR

7.7

Full-Telemetry TCR

8.8

Limitations

·        This rule does not detect Azure-managed hypervisor exploitation.

·        This rule does not directly detect KVM shadow MMU corruption or in-kernel exploit execution.

·        This rule does not prove guest-to-host escape without self-managed KVM host-fault, placement, and post-fault behavior correlation.

·        This rule requires self-managed KVM host telemetry, provider-supplied host context, or SIEM-normalized KVM host context joined with Azure logs.

·        This rule requires accurate Azure tenant, subscription, resource group, VM, VNet, subnet, NSG, route table, identity, disk, snapshot, Storage, Key Vault, backup, and workload mapping.

·        This rule can generate noise during approved infrastructure-as-code changes, CI/CD deployment, backup operations, incident response, patching, host migration, failover, autoscaling, platform maintenance, or managed-service activity.

·        This rule may miss activity where post-escape behavior remains local to the KVM host and does not produce Azure Activity, network, storage, identity, Key Vault, disk, snapshot, backup, or flow telemetry.

·        This rule is weaker where Azure logs are incomplete, NSG flow logs are unavailable, diagnostic settings are incomplete, self-managed host telemetry is absent, or KVM placement context is not retained.

·        This rule should not be treated as a managed-cloud hypervisor escape detector unless Azure or the provider supplies relevant host-level evidence.

Detection Query Pattern

Use this pattern as implementation-ready Azure correlation pseudologic and map all Azure Activity fields, Azure Resource Manager fields, Defender for Cloud fields, Sentinel fields, Network Security Group flow fields, Azure Firewall fields, DNS fields, Key Vault fields, Storage fields, VM inventory fields, disk and snapshot fields, backup fields, identity fields, KVM host-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, network-change baselines, and time windows to the target Sentinel, SIEM, data-lake, or analytics environment before deployment.

kvm_azure_context represents a normalized correlation view derived from self-managed KVM host telemetry, Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, infrastructure health logs, crash records, host reboot records, nested virtualization exposure inventory, VM placement data, guest and tenant context, workload mappings, Azure VM inventory, Azure tenant mapping, Azure subscription mapping, resource group mapping, VNet mapping, subnet mapping, NSG mapping, route table mapping, managed identity mapping, service principal mapping, disk mapping, snapshot mapping, Storage account mapping, Key Vault mapping, backup vault mapping, DNS mapping, NSG flow context, Azure Resource Manager records, Azure Activity logs, Defender for Cloud alerts, Sentinel incidents, destination enrichment, and approved maintenance context.

azure_kvm_resource_activity represents a normalized Azure resource, identity, network, storage, and workload-access view derived from Azure Activity logs, Azure Resource Manager events, Defender for Cloud alerts, Sentinel incidents, Network Security Group flow logs, Azure Firewall logs, DNS logs, Key Vault logs, Storage logs, VM activity, disk activity, snapshot activity, backup activity, managed identity context, service principal context, role assignment activity, network context, proxy context, endpoint context, and source-enrichment context.

Local teams must create, map, or enrich both views before deploying the Azure KVM post-fault resource and network correlation pattern.

FROM azure_kvm_resource_activity,
kvm_azure_context

WHERE azure_kvm_resource_activity.normalized_identity_id IS NOT NULL

AND kvm_azure_context.event_time IS NOT NULL

AND azure_kvm_resource_activity.event_time BETWEEN kvm_azure_context.event_time AND kvm_azure_context.event_time + ENV_KVM_TO_AZURE_POST_FAULT_WINDOW

AND kvm_azure_context.kvm_host_id IS NOT NULL

AND kvm_azure_context.self_managed_kvm_host = true

AND kvm_azure_context.tenant_id = azure_kvm_resource_activity.tenant_id

AND kvm_azure_context.subscription_id = azure_kvm_resource_activity.subscription_id

AND (
kvm_azure_context.vm_id = azure_kvm_resource_activity.vm_id
OR kvm_azure_context.instance_id = azure_kvm_resource_activity.vm_id
OR kvm_azure_context.private_ip = azure_kvm_resource_activity.source_ip
OR kvm_azure_context.private_ip = azure_kvm_resource_activity.destination_ip
OR kvm_azure_context.vnet_id = azure_kvm_resource_activity.vnet_id
OR kvm_azure_context.subnet_id = azure_kvm_resource_activity.subnet_id
OR kvm_azure_context.network_security_group_id = azure_kvm_resource_activity.network_security_group_id
OR kvm_azure_context.route_table_id = azure_kvm_resource_activity.route_table_id
OR kvm_azure_context.managed_identity_id = azure_kvm_resource_activity.managed_identity_id
OR kvm_azure_context.service_principal_id = azure_kvm_resource_activity.service_principal_id
OR kvm_azure_context.disk_id = azure_kvm_resource_activity.disk_id
OR kvm_azure_context.snapshot_id = azure_kvm_resource_activity.snapshot_id
OR kvm_azure_context.storage_account_name = azure_kvm_resource_activity.storage_account_name
OR kvm_azure_context.key_vault_name = azure_kvm_resource_activity.key_vault_name
OR kvm_azure_context.backup_vault_name = azure_kvm_resource_activity.backup_vault_name
OR kvm_azure_context.workload_id = azure_kvm_resource_activity.workload_id
OR kvm_azure_context.destination_ip = azure_kvm_resource_activity.source_ip
OR kvm_azure_context.destination_domain = azure_kvm_resource_activity.domain_name
)

AND kvm_azure_context.type IN (
"kvm_host_fault_after_untrusted_guest_activity",
"kvm_host_fault_after_nested_virtualization_activity",
"kvm_shadow_paging_or_mmu_fault_context",
"kvm_compute_node_reboot_after_guest_activity",
"kvm_host_quarantine_or_eviction_after_fault",
"kvm_failed_migration_or_evacuated_host_context",
"kvm_post_fault_rare_compute_host_egress",
"kvm_post_fault_sensitive_dependency_access",
"kvm_repeated_guest_linked_host_faults",
"kvm_repeated_tenant_linked_host_faults",
"kvm_repeated_image_linked_host_faults"
)

AND (
azure_kvm_resource_activity.event_name IN ENV_AZURE_IDENTITY_ACCESS_EVENTS
OR azure_kvm_resource_activity.event_name IN ENV_AZURE_ROLE_ASSIGNMENT_OR_PRIVILEGE_EVENTS
OR azure_kvm_resource_activity.event_name IN ENV_AZURE_NETWORK_SECURITY_MODIFICATION_EVENTS
OR azure_kvm_resource_activity.event_name IN ENV_AZURE_ROUTE_TABLE_MODIFICATION_EVENTS
OR azure_kvm_resource_activity.event_name IN ENV_AZURE_FIREWALL_OR_POLICY_MODIFICATION_EVENTS
OR azure_kvm_resource_activity.event_name IN ENV_AZURE_VM_CONTROL_EVENTS
OR azure_kvm_resource_activity.event_name IN ENV_AZURE_DISK_OR_SNAPSHOT_ACCESS_EVENTS
OR azure_kvm_resource_activity.event_name IN ENV_AZURE_IMAGE_OR_GALLERY_ACCESS_EVENTS
OR azure_kvm_resource_activity.event_name IN ENV_AZURE_BACKUP_ACCESS_EVENTS
OR azure_kvm_resource_activity.event_name IN ENV_AZURE_STORAGE_ENUMERATION_OR_ACCESS_EVENTS
OR azure_kvm_resource_activity.event_name IN ENV_AZURE_KEY_VAULT_ACCESS_EVENTS
OR azure_kvm_resource_activity.event_name IN ENV_AZURE_CROSS_SUBSCRIPTION_ACCESS_EVENTS
OR azure_kvm_resource_activity.defender_for_cloud_alert_type IN ENV_RELEVANT_KVM_POST_FAULT_DEFENDER_FOR_CLOUD_ALERTS
OR azure_kvm_resource_activity.sentinel_incident_type IN ENV_RELEVANT_KVM_POST_FAULT_SENTINEL_INCIDENT_TYPES
OR azure_kvm_resource_activity.network_flow_anomaly_type IN ENV_RELEVANT_KVM_POST_FAULT_AZURE_NETWORK_FLOW_ANOMALIES
OR azure_kvm_resource_activity.dns_query_risk IN ENV_RELEVANT_KVM_POST_FAULT_AZURE_DNS_QUERY_RISKS
)

AND (
azure_kvm_resource_activity.source_ip NOT IN ENV_APPROVED_AZURE_ADMIN_SOURCE_IPS
OR azure_kvm_resource_activity.user_agent NOT IN ENV_EXPECTED_AZURE_USER_AGENTS_BY_ROLE
OR azure_kvm_resource_activity.tenant_id NOT IN ENV_EXPECTED_TENANTS_BY_USER_OR_APP
OR azure_kvm_resource_activity.subscription_id NOT IN ENV_EXPECTED_SUBSCRIPTIONS_BY_USER_OR_APP
OR azure_kvm_resource_activity.role_definition_id NOT IN ENV_EXPECTED_AZURE_ROLES_BY_IDENTITY
OR azure_kvm_resource_activity.normalized_identity_id NOT IN ENV_EXPECTED_AZURE_IDENTITIES_BY_WORKLOAD
OR azure_kvm_resource_activity.network_security_group_id IN ENV_SENSITIVE_AZURE_NETWORK_SECURITY_GROUPS
OR azure_kvm_resource_activity.route_table_id IN ENV_SENSITIVE_AZURE_ROUTE_TABLES
OR azure_kvm_resource_activity.vnet_id IN ENV_SENSITIVE_AZURE_VNETS
OR azure_kvm_resource_activity.subnet_id IN ENV_SENSITIVE_AZURE_SUBNETS
OR azure_kvm_resource_activity.disk_id IN ENV_SENSITIVE_AZURE_DISKS
OR azure_kvm_resource_activity.snapshot_id IN ENV_SENSITIVE_AZURE_SNAPSHOTS
OR azure_kvm_resource_activity.storage_account_name IN ENV_SENSITIVE_STORAGE_ACCOUNTS
OR azure_kvm_resource_activity.key_vault_name IN ENV_SENSITIVE_KEY_VAULTS
OR azure_kvm_resource_activity.backup_vault_name IN ENV_SENSITIVE_AZURE_BACKUP_VAULTS
OR azure_kvm_resource_activity.network_flow_anomaly_type IN ENV_HIGH_RISK_KVM_POST_FAULT_AZURE_NETWORK_FLOW_ANOMALIES
OR azure_kvm_resource_activity.dns_query_risk IN ENV_HIGH_RISK_KVM_POST_FAULT_AZURE_DNS_QUERY_RISKS
OR azure_kvm_resource_activity.event_name IN ENV_HIGH_RISK_AZURE_KVM_POST_FAULT_EVENTS_REQUIRING_REVIEW
)

AND NOT (
azure_kvm_resource_activity.service_principal_id IN ENV_APPROVED_CICD_OR_IAC_SERVICE_PRINCIPALS
AND azure_kvm_resource_activity.source_ip IN ENV_APPROVED_CICD_OR_IAC_SOURCE_IPS
AND azure_kvm_resource_activity.event_name IN ENV_APPROVED_CICD_OR_IAC_AZURE_EVENTS
AND azure_kvm_resource_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
azure_kvm_resource_activity.normalized_identity_id IN ENV_APPROVED_AZURE_AUTOMATION_IDENTITIES
AND azure_kvm_resource_activity.source_ip IN ENV_APPROVED_AZURE_AUTOMATION_SOURCE_IPS
AND azure_kvm_resource_activity.event_name IN ENV_APPROVED_AZURE_AUTOMATION_EVENTS
AND azure_kvm_resource_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
azure_kvm_resource_activity.normalized_identity_id IN ENV_APPROVED_SECURITY_TOOLING_IDENTITIES
AND azure_kvm_resource_activity.source_ip IN ENV_APPROVED_SECURITY_TOOLING_SOURCE_IPS
AND azure_kvm_resource_activity.event_name IN ENV_APPROVED_SECURITY_TOOLING_AZURE_EVENTS
AND azure_kvm_resource_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
azure_kvm_resource_activity.normalized_identity_id IN ENV_APPROVED_INCIDENT_RESPONSE_IDENTITIES
AND azure_kvm_resource_activity.source_ip IN ENV_APPROVED_INCIDENT_RESPONSE_SOURCE_IPS
AND azure_kvm_resource_activity.event_name IN ENV_APPROVED_INCIDENT_RESPONSE_AZURE_EVENTS
AND azure_kvm_resource_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
azure_kvm_resource_activity.normalized_identity_id IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_IDENTITIES
AND azure_kvm_resource_activity.source_ip IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_SOURCE_IPS
AND azure_kvm_resource_activity.event_name IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_AZURE_EVENTS
AND azure_kvm_resource_activity.resource_id NOT IN ENV_SENSITIVE_AZURE_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
azure_kvm_resource_activity.event_time IN ENV_APPROVED_KVM_AZURE_PATCH_WINDOWS
OR azure_kvm_resource_activity.event_time IN ENV_APPROVED_KVM_AZURE_MAINTENANCE_WINDOWS
OR azure_kvm_resource_activity.event_time IN ENV_APPROVED_KVM_AZURE_BACKUP_WINDOWS
OR azure_kvm_resource_activity.event_time IN ENV_APPROVED_KVM_AZURE_MIGRATION_WINDOWS
OR azure_kvm_resource_activity.event_time IN ENV_APPROVED_KVM_AZURE_INCIDENT_RESPONSE_WINDOWS
)

AND azure_kvm_resource_activity.normalized_identity_id NOT IN ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS

GROUP BY azure_kvm_resource_activity.tenant_id,
azure_kvm_resource_activity.subscription_id,
azure_kvm_resource_activity.resource_group,
azure_kvm_resource_activity.normalized_identity_id,
azure_kvm_resource_activity.source_ip,
azure_kvm_resource_activity.user_agent,
azure_kvm_resource_activity.application_id,
azure_kvm_resource_activity.service_principal_id,
azure_kvm_resource_activity.managed_identity_id,
azure_kvm_resource_activity.role_definition_id,
azure_kvm_resource_activity.event_name,
azure_kvm_resource_activity.resource_id,
azure_kvm_resource_activity.vm_id,
azure_kvm_resource_activity.vnet_id,
azure_kvm_resource_activity.subnet_id,
azure_kvm_resource_activity.network_security_group_id,
azure_kvm_resource_activity.route_table_id,
azure_kvm_resource_activity.disk_id,
azure_kvm_resource_activity.snapshot_id,
azure_kvm_resource_activity.key_vault_name,
azure_kvm_resource_activity.storage_account_name,
azure_kvm_resource_activity.backup_vault_name,
kvm_azure_context.kvm_host_id,
kvm_azure_context.kvm_host_name,
kvm_azure_context.compute_node,
kvm_azure_context.compute_pool,
kvm_azure_context.guest_id,
kvm_azure_context.tenant_id,
kvm_azure_context.image_id,
kvm_azure_context.workload_id,
kvm_azure_context.type

EMIT alert WHEN

count_distinct(azure_kvm_resource_activity.event_name) >= ENV_MIN_DISTINCT_AZURE_KVM_POST_FAULT_EVENTS

OR azure_kvm_resource_activity.event_name IN ENV_HIGH_RISK_AZURE_KVM_POST_FAULT_EVENTS_REQUIRING_REVIEW

OR azure_kvm_resource_activity.defender_for_cloud_alert_type IN ENV_RELEVANT_KVM_POST_FAULT_DEFENDER_FOR_CLOUD_ALERTS

OR azure_kvm_resource_activity.sentinel_incident_type IN ENV_RELEVANT_KVM_POST_FAULT_SENTINEL_INCIDENT_TYPES

OR azure_kvm_resource_activity.network_flow_anomaly_type IN ENV_HIGH_RISK_KVM_POST_FAULT_AZURE_NETWORK_FLOW_ANOMALIES

OR azure_kvm_resource_activity.dns_query_risk IN ENV_HIGH_RISK_KVM_POST_FAULT_AZURE_DNS_QUERY_RISKS

GCP

Detection Viability Assessment

GCP is viable for this threat only in constrained environments where self-managed KVM compute hosts, cloud-hosted KVM systems, nested-virtualization-enabled workloads, CI KVM runners, sandbox hosts, malware-analysis hosts, or private-cloud virtualization components run in Google Cloud and their host telemetry is ingested into Chronicle, Cloud Logging, Security Command Center, a SIEM, a data lake, or an equivalent correlation platform. Google Cloud-native telemetry cannot directly detect KVM shadow MMU corruption, in-kernel exploit execution, or guest-to-host escape inside Google Cloud-managed hypervisor infrastructure. Its value is correlating self-managed KVM host-fault context, nested virtualization exposure, guest or workload context, post-fault Google Cloud activity, VPC Flow Log behavior, Cloud DNS activity, Cloud Storage access, Secret Manager access, KMS access, IAM activity, firewall policy changes, route changes, load-balancer changes, or workload expansion after suspected virtualization boundary stress.

Rule

GCP Self-Managed KVM Host Fault With Post-Fault Resource and Network Expansion

Rule Format

Behavioral correlation rule for Google Cloud environments using Admin Activity logs, Data Access logs, Security Command Center findings, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Compute Engine inventory, IAM activity, firewall policy activity, route activity, workload activity, and self-managed KVM host-context enrichment.

Detection Purpose

Detect Google Cloud environments where self-managed KVM host-fault telemetry or virtualization-boundary stress context aligns with post-fault Google Cloud activity involving identity, Cloud Storage, Secret Manager, KMS, network firewall policy, routes, DNS, load balancing, workload control, or cross-project exposure. The rule identifies suspicious Google Cloud-side behavior after KVM compute-host instability, nested virtualization exposure, guest-linked fault activity, host reboot, host quarantine, failed evacuation, unusual compute-host egress, or repeated instability tied to the same Compute Engine instance, organization, folder, project, VPC network, subnet, guest, image, workload, or compute pool.

Detection Logic

Normalize self-managed KVM host telemetry with Google Cloud organization, folder, project, Compute Engine instance, image, service account, IAM role, VPC network, subnet, firewall policy, route, load balancer, Cloud Armor policy, Cloud DNS zone, Cloud Storage bucket, Secret Manager secret, KMS key, and VPC Flow Log context. Correlate KVM host-fault or boundary-stress events with Google Cloud Admin Activity logs, Data Access logs, Security Command Center findings, VPC Flow anomalies, Cloud DNS query risk, Cloud Storage access, Secret Manager access, KMS access, IAM activity, firewall policy changes, route changes, load-balancer changes, and workload-control activity within a bounded post-fault window.

The rule should prioritize activity where a self-managed KVM host or related Google Cloud workload shows post-fault access to sensitive Cloud Storage buckets, secrets, KMS keys, service accounts, IAM roles, firewall policies, routes, VPC networks, subnets, Cloud DNS zones, load balancers, Cloud Armor policies, Compute Engine instances, GKE clusters, Cloud Run services, App Engine services, or cross-project resources. Higher confidence should apply when activity is performed by unusual principals, unexpected service accounts, rare source IPs, unexpected organizations, folders, or projects, unusual user agents, suspicious Security Command Center findings, or changes affecting sensitive Google Cloud resources.

Required Telemetry

·        Self-managed KVM host telemetry ingested into Chronicle, Cloud Logging, Security Command Center, SIEM, data lake, or equivalent correlation tooling.

·        Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, infrastructure health logs, crash records, host reboot telemetry, and host evacuation or quarantine records from self-managed KVM systems.

·        Google Cloud Admin Activity logs and Data Access logs where available.

·        Security Command Center findings where available.

·        VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, firewall logs, proxy logs, NDR logs, or data-center flow logs where available.

·        Google Cloud Compute Engine inventory, instance IDs, image IDs, service account IDs, organization IDs, folder IDs, project IDs, VPC network names, subnet names, firewall policy names, route names, load balancer names, Cloud Armor policy names, Cloud Storage bucket names, Secret Manager secret names, KMS key names, GKE cluster IDs, Cloud Run service names, App Engine service names, and workload mappings.

·        Nested virtualization exposure inventory for self-managed KVM hosts running in Google Cloud.

·        VM placement, guest ID, tenant ID, project ID, image ID, workload ID, compute-node, and compute-pool context for the self-managed KVM layer.

·        Approved Google Cloud automation identities, CI/CD identities, infrastructure-as-code identities, security tooling identities, incident-response identities, backup identities, platform or managed-service identities, source IP allowlists, expected organizations, expected folders, expected projects, expected roles, expected resources, expected user agents, and maintenance windows.

·        Destination enrichment for first-seen status, domain age, ASN, geography, reputation, service category, protocol, and internal zone.

Engineering Implementation Instructions

Deploy this rule in hunt mode before alert mode. Validate that Google Cloud telemetry can be joined with self-managed KVM host context before enabling production alerting. Map all Google Cloud audit fields, cloud-resource fields, Cloud Storage fields, Secret Manager fields, KMS fields, Security Command Center fields, VPC Flow Log fields, Cloud DNS fields, Cloud Armor fields, Compute Engine fields, GKE fields, Cloud Run fields, IAM fields, KVM host-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, network-change baselines, project baselines, organization baselines, service-account baselines, and time windows to the target Chronicle, SIEM, data-lake, or analytics environment before deployment.

This rule should not be used as a detector for Google Cloud-managed hypervisor compromise. It should not fire on vulnerable-kernel status, nested virtualization exposure, Compute Engine reboot, instance stop/start, platform maintenance, firewall policy change, IAM activity, Cloud Storage access, Secret Manager access, KMS access, route change, DNS change, or VPC Flow anomaly alone. Require self-managed KVM host-fault or boundary-stress context joined to suspicious Google Cloud-side post-fault behavior, sensitive resource access, rare compute-host egress, identity deviation, network-control change, storage access, secret access, KMS access, workload-control activity, or repeated guest-linked instability.

DRI Assessment

The rule has moderate-to-strong detection resilience because it correlates durable Google Cloud-side behaviors with self-managed KVM host-fault context rather than relying on a single CVE name, exploit string, public proof-of-concept artifact, scanner finding, vulnerable-kernel state, or standalone Google Cloud control-plane event. It remains useful across KVM guest-to-host escape variants where suspected host instability is followed by Google Cloud identity activity, Cloud Storage access, Secret Manager access, KMS access, network modification, rare egress, or workload expansion. Its main weakness is that Google Cloud-native telemetry cannot confirm KVM in-kernel exploitation and depends on self-managed host telemetry or provider-supplied host context.

DRI

8.1

TCR Assessment

Operational telemetry coverage is moderate when Google Cloud Admin Activity logs, Data Access logs, VPC Flow Logs, Compute Engine inventory, Security Command Center findings, and self-managed KVM host-fault context are available. Full-telemetry coverage is strong when Google Cloud telemetry is joined with KVM host logs, VM placement context, nested virtualization exposure, Cloud Storage logs, Secret Manager logs, KMS logs, IAM activity, Cloud DNS logs, Cloud Armor logs, NDR, incident-response records, and approved automation baselines.

Operational TCR

7.7

Full-Telemetry TCR

8.8

Limitations

·        This rule does not detect Google Cloud-managed hypervisor exploitation.

·        This rule does not directly detect KVM shadow MMU corruption or in-kernel exploit execution.

·        This rule does not prove guest-to-host escape without self-managed KVM host-fault, placement, and post-fault behavior correlation.

·        This rule requires self-managed KVM host telemetry, provider-supplied host context, or SIEM-normalized KVM host context joined with Google Cloud logs.

·        This rule requires accurate Google Cloud organization, folder, project, Compute Engine, VPC network, subnet, firewall policy, route, IAM, service account, Cloud Storage, Secret Manager, KMS, DNS, load-balancer, and workload mapping.

·        This rule can generate noise during approved infrastructure-as-code changes, CI/CD deployment, backup operations, incident response, patching, host migration, failover, autoscaling, platform maintenance, or managed-service activity.

·        This rule may miss activity where post-escape behavior remains local to the KVM host and does not produce Google Cloud audit, network, storage, identity, Secret Manager, KMS, DNS, workload, or flow telemetry.

·        This rule is weaker where Google Cloud logs are incomplete, Data Access logs are disabled, VPC Flow Logs are unavailable, self-managed host telemetry is absent, or KVM placement context is not retained.

·        This rule should not be treated as a managed-cloud hypervisor escape detector unless Google Cloud or the provider supplies relevant host-level evidence.

Detection Query Pattern

Use this pattern as implementation-ready Google Cloud correlation pseudologic and map all Google Cloud audit fields, cloud-resource fields, Cloud Storage fields, Secret Manager fields, KMS fields, Security Command Center fields, VPC Flow Log fields, Cloud DNS fields, Cloud Armor fields, Compute Engine fields, GKE fields, Cloud Run fields, IAM fields, KVM host-context fields, approved-role lookups, automation allowlists, source baselines, resource baselines, network-change baselines, project baselines, organization baselines, service-account baselines, and time windows to the target Chronicle, SIEM, data-lake, or analytics environment before deployment.

kvm_gcp_context represents a normalized correlation view derived from self-managed KVM host telemetry, Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, infrastructure health logs, crash records, host reboot records, nested virtualization exposure inventory, VM placement data, guest and tenant context, workload mappings, Google Cloud Compute Engine inventory, Google Cloud organization mapping, folder mapping, project mapping, VPC network mapping, subnet mapping, firewall policy mapping, route mapping, service account mapping, IAM role mapping, Cloud Storage bucket mapping, Secret Manager mapping, KMS key mapping, Cloud DNS mapping, Cloud Armor mapping, load-balancer mapping, VPC Flow Log context, Google Cloud Admin Activity logs, Data Access logs, Security Command Center findings, destination enrichment, and approved maintenance context.

gcp_kvm_resource_activity represents a normalized Google Cloud resource, identity, network, storage, secret, KMS, and workload-access view derived from Google Cloud Admin Activity logs, Data Access logs, Security Command Center events, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, external Application Load Balancer logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Compute Engine activity, GKE activity, Cloud Run activity, App Engine activity, firewall policy activity, route activity, logging and monitoring activity, identity context, network context, proxy context, endpoint context, and source-enrichment context.

Local teams must create, map, or enrich both views before deploying the Google Cloud KVM post-fault resource and network correlation pattern.

FROM gcp_kvm_resource_activity,
kvm_gcp_context

WHERE gcp_kvm_resource_activity.principal_email IS NOT NULL

AND kvm_gcp_context.event_time IS NOT NULL

AND gcp_kvm_resource_activity.event_time BETWEEN kvm_gcp_context.event_time AND kvm_gcp_context.event_time + ENV_KVM_TO_GCP_POST_FAULT_WINDOW

AND kvm_gcp_context.kvm_host_id IS NOT NULL

AND kvm_gcp_context.self_managed_kvm_host = true

AND kvm_gcp_context.organization_id = gcp_kvm_resource_activity.organization_id

AND kvm_gcp_context.project_id = gcp_kvm_resource_activity.project_id

AND (
kvm_gcp_context.compute_instance_id = gcp_kvm_resource_activity.compute_instance_id
OR kvm_gcp_context.instance_id = gcp_kvm_resource_activity.compute_instance_id
OR kvm_gcp_context.private_ip = gcp_kvm_resource_activity.source_ip
OR kvm_gcp_context.private_ip = gcp_kvm_resource_activity.destination_ip
OR kvm_gcp_context.vpc_network_name = gcp_kvm_resource_activity.vpc_network_name
OR kvm_gcp_context.subnet_name = gcp_kvm_resource_activity.subnet_name
OR kvm_gcp_context.firewall_policy_name = gcp_kvm_resource_activity.firewall_policy_name
OR kvm_gcp_context.route_name = gcp_kvm_resource_activity.route_name
OR kvm_gcp_context.service_account_id = gcp_kvm_resource_activity.service_account_id
OR kvm_gcp_context.principal_email = gcp_kvm_resource_activity.principal_email
OR kvm_gcp_context.storage_bucket_name = gcp_kvm_resource_activity.storage_bucket_name
OR kvm_gcp_context.secret_name = gcp_kvm_resource_activity.secret_name
OR kvm_gcp_context.kms_key_name = gcp_kvm_resource_activity.kms_key_name
OR kvm_gcp_context.gke_cluster_id = gcp_kvm_resource_activity.gke_cluster_id
OR kvm_gcp_context.cloud_run_service_name = gcp_kvm_resource_activity.cloud_run_service_name
OR kvm_gcp_context.app_engine_service_name = gcp_kvm_resource_activity.app_engine_service_name
OR kvm_gcp_context.workload_id = gcp_kvm_resource_activity.workload_id
OR kvm_gcp_context.destination_ip = gcp_kvm_resource_activity.source_ip
OR kvm_gcp_context.destination_domain = gcp_kvm_resource_activity.domain_name
)

AND kvm_gcp_context.type IN (
"kvm_host_fault_after_untrusted_guest_activity",
"kvm_host_fault_after_nested_virtualization_activity",
"kvm_shadow_paging_or_mmu_fault_context",
"kvm_compute_node_reboot_after_guest_activity",
"kvm_host_quarantine_or_eviction_after_fault",
"kvm_failed_migration_or_evacuated_host_context",
"kvm_post_fault_rare_compute_host_egress",
"kvm_post_fault_sensitive_dependency_access",
"kvm_repeated_guest_linked_host_faults",
"kvm_repeated_tenant_linked_host_faults",
"kvm_repeated_image_linked_host_faults"
)

AND (
gcp_kvm_resource_activity.method_name IN ENV_GCP_IDENTITY_ACCESS_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_IAM_OR_PRIVILEGE_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_NETWORK_EXPOSURE_CHANGE_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_FIREWALL_OR_POLICY_MODIFICATION_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_ROUTE_MODIFICATION_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_COMPUTE_INSTANCE_CONTROL_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_DISK_OR_SNAPSHOT_ACCESS_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_IMAGE_OR_ARTIFACT_ACCESS_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_BACKUP_OR_RECOVERY_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_STORAGE_RISK_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_SECRET_MANAGER_RISK_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_KMS_RISK_METHODS
OR gcp_kvm_resource_activity.method_name IN ENV_GCP_CROSS_PROJECT_ACCESS_METHODS
OR gcp_kvm_resource_activity.security_command_center_finding_type IN ENV_RELEVANT_KVM_POST_FAULT_SECURITY_COMMAND_CENTER_FINDINGS
OR gcp_kvm_resource_activity.vpc_flow_anomaly_type IN ENV_RELEVANT_KVM_POST_FAULT_GCP_VPC_FLOW_ANOMALIES
OR gcp_kvm_resource_activity.dns_query_risk IN ENV_RELEVANT_KVM_POST_FAULT_GCP_DNS_QUERY_RISKS
)

AND (
gcp_kvm_resource_activity.source_ip NOT IN ENV_APPROVED_GCP_ADMIN_SOURCE_IPS
OR gcp_kvm_resource_activity.user_agent NOT IN ENV_EXPECTED_GCP_USER_AGENTS_BY_ROLE
OR gcp_kvm_resource_activity.organization_id NOT IN ENV_EXPECTED_GCP_ORGANIZATIONS_BY_USER_OR_ROLE
OR gcp_kvm_resource_activity.folder_id NOT IN ENV_EXPECTED_GCP_FOLDERS_BY_USER_OR_ROLE
OR gcp_kvm_resource_activity.project_id NOT IN ENV_EXPECTED_GCP_PROJECTS_BY_USER_OR_ROLE
OR gcp_kvm_resource_activity.resource_name NOT IN ENV_EXPECTED_GCP_RESOURCES_BY_USER_OR_ROLE
OR gcp_kvm_resource_activity.role_name NOT IN ENV_EXPECTED_GCP_ROLES_BY_USER_OR_ROLE
OR gcp_kvm_resource_activity.principal_email NOT IN ENV_EXPECTED_GCP_IDENTITIES_BY_WORKLOAD
OR gcp_kvm_resource_activity.firewall_policy_name IN ENV_SENSITIVE_GCP_FIREWALL_POLICIES
OR gcp_kvm_resource_activity.vpc_network_name IN ENV_SENSITIVE_GCP_VPC_NETWORKS
OR gcp_kvm_resource_activity.subnet_name IN ENV_SENSITIVE_GCP_SUBNETS
OR gcp_kvm_resource_activity.route_name IN ENV_SENSITIVE_GCP_ROUTES
OR gcp_kvm_resource_activity.load_balancer_name IN ENV_SENSITIVE_GCP_LOAD_BALANCERS
OR gcp_kvm_resource_activity.cloud_armor_policy_name IN ENV_SENSITIVE_GCP_CLOUD_ARMOR_POLICIES
OR gcp_kvm_resource_activity.dns_zone_name IN ENV_SENSITIVE_GCP_DNS_ZONES
OR gcp_kvm_resource_activity.storage_bucket_name IN ENV_SENSITIVE_GCP_STORAGE_BUCKETS
OR gcp_kvm_resource_activity.secret_name IN ENV_SENSITIVE_GCP_SECRETS
OR gcp_kvm_resource_activity.kms_key_name IN ENV_SENSITIVE_GCP_KMS_KEYS
OR gcp_kvm_resource_activity.vpc_flow_anomaly_type IN ENV_HIGH_RISK_KVM_POST_FAULT_GCP_VPC_FLOW_ANOMALIES
OR gcp_kvm_resource_activity.dns_query_risk IN ENV_HIGH_RISK_KVM_POST_FAULT_GCP_DNS_QUERY_RISKS
OR gcp_kvm_resource_activity.method_name IN ENV_HIGH_RISK_GCP_KVM_POST_FAULT_METHODS_REQUIRING_REVIEW
)

AND NOT (
gcp_kvm_resource_activity.principal_email IN ENV_APPROVED_CICD_OR_IAC_IDENTITIES
AND gcp_kvm_resource_activity.source_ip IN ENV_APPROVED_CICD_OR_IAC_SOURCE_IPS
AND gcp_kvm_resource_activity.method_name IN ENV_APPROVED_CICD_OR_IAC_GCP_METHODS
AND gcp_kvm_resource_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
gcp_kvm_resource_activity.principal_email IN ENV_APPROVED_GCP_AUTOMATION_IDENTITIES
AND gcp_kvm_resource_activity.source_ip IN ENV_APPROVED_GCP_AUTOMATION_SOURCE_IPS
AND gcp_kvm_resource_activity.method_name IN ENV_APPROVED_GCP_AUTOMATION_METHODS
AND gcp_kvm_resource_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
gcp_kvm_resource_activity.principal_email IN ENV_APPROVED_SECURITY_TOOLING_IDENTITIES
AND gcp_kvm_resource_activity.source_ip IN ENV_APPROVED_SECURITY_TOOLING_SOURCE_IPS
AND gcp_kvm_resource_activity.method_name IN ENV_APPROVED_SECURITY_TOOLING_GCP_METHODS
AND gcp_kvm_resource_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
gcp_kvm_resource_activity.principal_email IN ENV_APPROVED_INCIDENT_RESPONSE_IDENTITIES
AND gcp_kvm_resource_activity.source_ip IN ENV_APPROVED_INCIDENT_RESPONSE_SOURCE_IPS
AND gcp_kvm_resource_activity.method_name IN ENV_APPROVED_INCIDENT_RESPONSE_GCP_METHODS
AND gcp_kvm_resource_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
gcp_kvm_resource_activity.principal_email IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_IDENTITIES
AND gcp_kvm_resource_activity.source_ip IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_SOURCE_IPS
AND gcp_kvm_resource_activity.method_name IN ENV_APPROVED_PLATFORM_OR_MANAGED_SERVICE_GCP_METHODS
AND gcp_kvm_resource_activity.resource_name NOT IN ENV_SENSITIVE_GCP_RESOURCES_REQUIRING_REVIEW
)

AND NOT (
gcp_kvm_resource_activity.event_time IN ENV_APPROVED_KVM_GCP_PATCH_WINDOWS
OR gcp_kvm_resource_activity.event_time IN ENV_APPROVED_KVM_GCP_MAINTENANCE_WINDOWS
OR gcp_kvm_resource_activity.event_time IN ENV_APPROVED_KVM_GCP_BACKUP_WINDOWS
OR gcp_kvm_resource_activity.event_time IN ENV_APPROVED_KVM_GCP_MIGRATION_WINDOWS
OR gcp_kvm_resource_activity.event_time IN ENV_APPROVED_KVM_GCP_INCIDENT_RESPONSE_WINDOWS
)

AND gcp_kvm_resource_activity.principal_email NOT IN ENV_ACTIVE_INVESTIGATION_SUPPRESSIONS

GROUP BY gcp_kvm_resource_activity.organization_id,
gcp_kvm_resource_activity.folder_id,
gcp_kvm_resource_activity.project_id,
gcp_kvm_resource_activity.normalized_user_id,
gcp_kvm_resource_activity.principal_email,
gcp_kvm_resource_activity.service_account_id,
gcp_kvm_resource_activity.source_ip,
gcp_kvm_resource_activity.user_agent,
gcp_kvm_resource_activity.method_name,
gcp_kvm_resource_activity.resource_name,
gcp_kvm_resource_activity.firewall_policy_name,
gcp_kvm_resource_activity.vpc_network_name,
gcp_kvm_resource_activity.subnet_name,
gcp_kvm_resource_activity.route_name,
gcp_kvm_resource_activity.load_balancer_name,
gcp_kvm_resource_activity.cloud_armor_policy_name,
gcp_kvm_resource_activity.dns_zone_name,
gcp_kvm_resource_activity.storage_bucket_name,
gcp_kvm_resource_activity.secret_name,
gcp_kvm_resource_activity.kms_key_name,
kvm_gcp_context.kvm_host_id,
kvm_gcp_context.kvm_host_name,
kvm_gcp_context.compute_node,
kvm_gcp_context.compute_pool,
kvm_gcp_context.guest_id,
kvm_gcp_context.tenant_id,
kvm_gcp_context.image_id,
kvm_gcp_context.workload_id,
kvm_gcp_context.type

EMIT alert WHEN

count_distinct(gcp_kvm_resource_activity.method_name) >= ENV_MIN_DISTINCT_GCP_KVM_POST_FAULT_METHODS

OR gcp_kvm_resource_activity.method_name IN ENV_HIGH_RISK_GCP_KVM_POST_FAULT_METHODS_REQUIRING_REVIEW

OR gcp_kvm_resource_activity.security_command_center_finding_type IN ENV_RELEVANT_KVM_POST_FAULT_SECURITY_COMMAND_CENTER_FINDINGS

OR gcp_kvm_resource_activity.vpc_flow_anomaly_type IN ENV_HIGH_RISK_KVM_POST_FAULT_GCP_VPC_FLOW_ANOMALIES

OR gcp_kvm_resource_activity.dns_query_risk IN ENV_HIGH_RISK_KVM_POST_FAULT_GCP_DNS_QUERY_RISKS

S26 Threat-to-Rule Traceability Matrix

Traceability Purpose

This section maps the primary behavioral threat conditions in this report to the S25 detection coverage developed across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, and GCP.

The traceability model is behavior-led. It does not rely on a single CVE label, Linux kernel version, KVM fault string, exploit name, public proof-of-concept reference, guest root condition, guest image name, tenant name, source IP, command string, file path, kernel message, scanner signature, actor branding, tool name, or static indicator as the basis for coverage.

Coverage Scope

The S25 rule set provides coverage for the observable enterprise sequence associated with self-managed KVM host exposure, nested virtualization risk, untrusted guest activity, host-side KVM instability, compute-node reboot or quarantine, failed migration or evacuation context, VM placement lineage, post-fault network activity, sensitive virtualization dependency access, storage access, backup access, metadata access, identity access, orchestration access, tenant-network exposure, and downstream AWS, Azure, and GCP activity where self-managed KVM telemetry or provider-supplied host context can be joined to cloud telemetry.

Coverage is strongest where Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, infrastructure health events, crash records, systemd journal telemetry, VM placement records, tenant context, image context, workload context, nested virtualization exposure inventory, endpoint telemetry, DNS logs, proxy logs, firewall logs, NDR, flow telemetry, storage logs, backup logs, identity logs, orchestration logs, cloud audit logs, SIEM correlation, and approved maintenance context can be joined into bounded behavioral sequences.

Primary Coverage Areas

·        KVM host-fault or virtualization-boundary stress involving kernel panic, kernel oops, soft lockup, watchdog event, crash dump, KVM service restart, QEMU crash, libvirt restart, KVM MMU fault, shadow-paging fault, nested virtualization fault, memory-management fault, unexpected role fault, invalid page state, compute-node reboot, host quarantine, compute-node disablement, failed migration, or host evacuation

·        Nested virtualization exposure involving x86 KVM hosts, nested-virtualization-enabled compute pools, untrusted guest context, customer-managed guest workloads, externally provisioned guests, CI-controlled guests, sandbox guests, malware-analysis guests, high-risk images, guest kernel-module activity, or guest-side nested virtualization activity

·        VM placement and virtualization lineage involving KVM host, host ID, compute node, compute pool, guest ID, tenant ID, project ID, image ID, workload ID, instance ID, and repeated fault clustering around the same guest, tenant, image, workload, host group, or compute pool

·        Post-fault sensitive dependency access involving storage backends, snapshot repositories, image repositories, backup systems, metadata services, identity services, orchestration APIs, migration networks, management networks, tenant networks, monitoring services, logging services, credentials, keys, SSH material, service files, host logs, crash dumps, VM disks, VM snapshots, and memory dumps

·        Rare compute-host egress involving new or rare destinations, suspicious destination reputation, unusual destination geography, suspicious ASN, unusual destination port, unusual protocol behavior, callback-like behavior, tool-retrieval behavior, cross-zone access, cross-tenant access, sensitive service access, management-plane access, storage access, backup access, or metadata access

·        Post-fault cloud activity in AWS, Azure, and GCP only when self-managed KVM host telemetry, provider-supplied host context, or SIEM-normalized KVM host context can be joined to cloud identity, storage, secret, key, snapshot, backup, network, route, firewall, DNS, workload, account, subscription, project, organization, service-account, managed-identity, IAM role, or resource activity

Traceability Mapping

KVM Host-Fault and Virtualization-Boundary Stress

This behavior is covered where Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, infrastructure health events, crash records, reboot records, systemd journal telemetry, and SIEM telemetry can identify KVM host instability or virtualization-boundary stress around self-managed KVM compute hosts.

Mapped Coverage

·        Splunk, Elastic, QRadar, and SIGMA coverage for KVM host-fault and virtualization-boundary stress where kernel, KVM, QEMU, libvirt, virtqemud, crash, reboot, compute-node state, and host-health fields are normalized or enriched

·        NDR / Network Behavioral Analytics supporting coverage where host-fault context can be joined to post-fault compute-host network expansion, sensitive dependency access, east-west movement, rare egress, or management-plane access

·        SentinelOne supporting coverage where endpoint telemetry from Linux KVM compute hosts identifies post-fault process activity, file access, service activity, persistence behavior, credential access, artifact access, or outbound activity

·        AWS, Azure, and GCP downstream coverage only when self-managed KVM host-fault context can be joined to later cloud identity, resource, network, storage, backup, key, secret, workload, or control-plane activity through reliable cloud-context mapping

Coverage Qualification

·        A kernel panic alone is not sufficient

·        A KVM fault string alone is not sufficient

·        A host reboot alone is not sufficient

·        A compute-node evacuation alone is not sufficient

·        A QEMU or libvirt restart alone is not sufficient

·        A vulnerable-kernel observation alone is not sufficient

·        A public proof-of-concept reference alone is not sufficient

·        Reliable KVM host identity, compute-node lineage, nested virtualization exposure, untrusted guest context, placement context, post-fault behavior, maintenance-window context, or sensitive dependency linkage must exist

·        Approved patching, kernel testing, reboot windows, host migration, live migration, evacuation, failover, CI activity, sandbox activity, malware-analysis workflows, vendor support, incident response, and platform maintenance require suppression or downgrade when expected context aligns

Nested Virtualization Exposure and High-Risk Guest Context

This behavior is covered where nested virtualization exposure inventory, guest activity telemetry, workload metadata, guest ID, tenant ID, project ID, image ID, workload ID, compute-pool mapping, and VM placement records can identify hosts or compute pools exposed to nested virtualization or high-risk guest activity.

Mapped Coverage

·        Splunk, Elastic, QRadar, and SIGMA coverage for nested virtualization exposure and high-risk guest context where KVM host inventory, compute-pool inventory, VM placement records, guest risk fields, tenant fields, image fields, workload fields, and exposure tags are normalized or enriched

·        SentinelOne supporting coverage where endpoint tags identify Linux KVM compute hosts, self-managed KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, multi-tenant virtualization hosts, or nested-virtualization-enabled hosts

·        NDR / Network Behavioral Analytics supporting coverage where nested virtualization or untrusted guest context can be joined to post-fault compute-host network expansion, sensitive dependency access, or unusual egress

·        AWS, Azure, and GCP coverage only where nested virtualization exposure in self-managed KVM environments can be joined to cloud workload, identity, storage, network, or resource activity

Coverage Qualification

·        Nested virtualization exposure alone is not sufficient

·        Guest root access alone is not sufficient

·        A high-risk guest label alone is not sufficient

·        A tenant label alone is not sufficient

·        A CI runner or sandbox label alone is not sufficient

·        A malware-analysis host label alone is not sufficient

·        Coverage requires KVM host-fault context, post-fault behavior, same-host lineage, same-compute-pool lineage, same-guest lineage, same-tenant lineage, same-image lineage, same-workload lineage, repeated guest-linked faults, sensitive dependency access, rare egress, or downstream cloud-impact context

·        Approved nested virtualization workflows should support triage and tuning but should not suppress KVM host-fault plus post-fault sensitive behavior when both are present

Post-Fault Sensitive Virtualization Dependency Access

This behavior is covered where storage, backup, metadata, identity, orchestration, migration, management, monitoring, logging, tenant-network, host-file, endpoint, and SIEM telemetry can identify sensitive dependency access after KVM host instability or virtualization-boundary stress.

Mapped Coverage

·        SentinelOne coverage for sensitive file, process, service, credential, artifact, persistence, and outbound activity on Linux KVM compute hosts after host-fault or boundary-stress context

·        Splunk, Elastic, QRadar, and SIGMA coverage where sensitive virtualization dependencies, VM disk paths, snapshot paths, memory dump paths, cloud-init paths, metadata paths, libvirt artifacts, QEMU artifacts, host logs, crash dumps, kernel module paths, SSH keys, service files, storage credentials, backup credentials, orchestration credentials, monitoring credentials, storage objects, metadata services, identity services, and orchestration APIs are normalized or enriched

·        NDR / Network Behavioral Analytics supporting coverage where sensitive dependency access produces management-plane access, storage access, backup access, metadata access, identity access, orchestration access, cross-zone access, cross-tenant access, or rare compute-host egress

·        AWS, Azure, and GCP coverage only where post-fault sensitive dependency access can be joined to cloud storage, snapshot, disk, backup, secret, key, identity, service-account, managed-identity, IAM role, workload, or resource activity

Coverage Qualification

·        Storage access alone is not sufficient

·        Backup access alone is not sufficient

·        Metadata access alone is not sufficient

·        Identity access alone is not sufficient

·        Orchestration access alone is not sufficient

·        VM disk access alone is not sufficient

·        Snapshot access alone is not sufficient

·        Host log access alone is not sufficient

·        Coverage requires prior KVM host-fault or boundary-stress context, nested virtualization exposure, untrusted guest context, same-host lineage, same-guest lineage, same-tenant lineage, same-image lineage, same-workload lineage, sensitive object lineage, rare egress, or downstream cloud-context linkage

·        Approved backup jobs, storage maintenance, migration workflows, monitoring workflows, diagnostic collection, kernel testing, patching, vendor support, incident-response collection, and approved administrative access require local baseline validation

Rare Compute-Host Egress and Network Expansion

This behavior is covered where DNS, proxy, firewall, NDR, destination reputation, destination first-seen status, domain age, ASN, geography, destination port, protocol, flow telemetry, source host identity, compute-host inventory, and SIEM telemetry can identify unusual outbound or east-west communication after KVM host instability.

Mapped Coverage

·        NDR / Network Behavioral Analytics coverage for rare compute-host egress, unusual destination ports, suspicious ASN, new or rare domains, abnormal destination geography, destination reputation anomalies, proxy anomalies, firewall anomalies, unusual protocols, management-plane access, storage access, backup access, metadata access, cross-zone access, cross-tenant access, and host-fault-to-network sequencing

·        SentinelOne supporting coverage for outbound activity from Linux KVM compute hosts where endpoint network telemetry is available

·        Splunk, Elastic, QRadar, and SIGMA coverage where DNS, proxy, firewall, NDR, endpoint, destination reputation, first-seen status, ASN, geography, destination port, protocol, compute-host inventory, KVM host-fault context, and virtualization lineage are normalized or enriched

·        AWS, Azure, and GCP coverage only where rare egress or network expansion can be joined to self-managed KVM host context and cloud identity, storage, secret, key, network, route, firewall, workload, account, subscription, project, organization, or resource activity

Coverage Qualification

·        Rare egress alone is not sufficient

·        A suspicious domain alone is not sufficient

·        Destination reputation alone is not sufficient

·        Unusual destination port alone is not sufficient

·        New domain age alone is not sufficient

·        A single outbound connection alone is not sufficient

·        Coverage requires KVM host-fault or boundary-stress context, nested virtualization exposure, untrusted guest context, same-host lineage, sensitive dependency access, storage access, backup access, metadata access, identity access, orchestration access, tenant-network access, or downstream cloud-impact context

·        Approved vendor support, update retrieval, license validation, telemetry, monitoring, backup, NTP, DNS, syslog, security tooling, vulnerability validation, migration, failover, and incident-response destinations require local allowlisting

VM Placement, Tenant, Image, and Workload Lineage

This behavior is covered where VM placement records, guest ID, tenant ID, project ID, image ID, workload ID, compute-node identity, compute-pool identity, migration records, evacuation records, and host-disablement records can be used to correlate host-fault behavior with affected guest or tenant context.

Mapped Coverage

·        Splunk, Elastic, QRadar, and SIGMA coverage for repeated guest-linked, tenant-linked, image-linked, workload-linked, compute-node-linked, or compute-pool-linked KVM host-fault behavior where placement and enrichment fields are available

·        SentinelOne supporting coverage where endpoint tags and downstream SIEM enrichment can map a Linux KVM compute host to compute-pool, guest, tenant, image, or workload context

·        NDR / Network Behavioral Analytics supporting coverage where compute-host network behavior can be mapped to affected compute nodes, compute pools, tenant networks, management networks, storage networks, migration networks, or sensitive virtualization dependencies

·        AWS, Azure, and GCP coverage only where self-managed KVM placement context can be joined to cloud workload, instance, VM, project, subscription, account, VPC, VNet, subnet, service account, managed identity, IAM role, or resource context

Coverage Qualification

·        VM placement metadata alone is not sufficient

·        Tenant identity alone is not sufficient

·        Image identity alone is not sufficient

·        Workload identity alone is not sufficient

·        Compute-pool membership alone is not sufficient

·        A single repeated-fault counter alone is not sufficient

·        Coverage requires KVM host-fault context, nested virtualization exposure, untrusted guest context, post-fault sensitive dependency access, rare egress, same-lineage clustering, or downstream cloud-impact context

·        Placement data must be accurate, timely, and retained long enough to support post-fault correlation

Downstream AWS Cloud Activity

This behavior is covered by conditional downstream AWS cloud-impact detection where self-managed KVM host-fault context, nested virtualization exposure, guest-linked fault activity, post-fault rare egress, sensitive dependency access, storage access, metadata access, identity access, orchestration access, or repeated guest-linked instability can be joined to AWS activity.

Mapped Coverage

·        AWS coverage for suspicious CloudTrail management events, CloudTrail data events, IAM activity, role assumption, access-key activity, Secrets Manager access, Systems Manager or parameter access, KMS activity, S3 enumeration or access, EBS volume or snapshot access, AMI or image access, backup access, CloudWatch log access, security group modification, route table modification, network ACL modification, EC2 instance-control activity, cross-account access, GuardDuty findings, Security Hub findings, AWS Config activity, VPC Flow anomalies, Route 53 Resolver query risk, and sensitive resource access following self-managed KVM post-fault context

·        Splunk, Elastic, and QRadar coverage where AWS logs and KVM host context are ingested into the same analytics environment

·        SIGMA coverage only where target backends can map AWS events into local event-rule templates and perform backend-native correlation

Coverage Qualification

·        AWS activity alone is not sufficient

·        AWS console access alone is not sufficient

·        IAM activity alone is not sufficient

·        Role assumption alone is not sufficient

·        Secrets Manager, KMS, S3, EBS, snapshot, or backup access alone is not sufficient

·        Security group or route table modification alone is not sufficient

·        Reliable AWS account lineage plus stronger workload, identity, source, host, resource, instance, volume, snapshot, bucket, secret, parameter, role, account, VPC, subnet, KVM host, compute node, guest, tenant, image, workload, or correlation linkage to self-managed KVM post-fault context must exist

·        CloudTrail management events, CloudTrail data events, GuardDuty, Security Hub, AWS Config, VPC Flow Logs, Route 53 Resolver logs, sensitive-resource inventories, workload mapping, KVM host context, VM placement context, and event ordering determine deployment confidence

Downstream Azure Control-Plane, Network, and Resource-Access Activity

This behavior is covered by conditional downstream Azure cloud-impact detection where self-managed KVM host-fault context, nested virtualization exposure, guest-linked fault activity, post-fault rare egress, sensitive dependency access, storage access, metadata access, identity access, orchestration access, or repeated guest-linked instability can be joined to Azure activity.

Mapped Coverage

·        Azure coverage for Azure Activity events, Azure Resource Manager activity, Defender for Cloud alerts, Sentinel incidents, managed identity activity, service-principal activity, role assignment activity, Key Vault access, Storage access, disk or snapshot access, backup access, network security group modification, route table modification, Azure Firewall or policy modification, VM control events, cross-subscription access, NSG flow anomalies, DNS query risk, and sensitive Azure resource access following self-managed KVM post-fault context

·        Splunk, Elastic, and QRadar coverage where Azure logs and KVM host context are ingested into the same analytics environment

·        SIGMA coverage only where target backends can map Azure events into local event-rule templates and perform backend-native correlation

Coverage Qualification

·        Azure activity alone is not sufficient

·        Azure portal access alone is not sufficient

·        Entra ID or Azure Activity alone is not sufficient

·        Role assignment alone is not sufficient

·        Key Vault, Storage, disk, snapshot, or backup access alone is not sufficient

·        NSG or route table modification alone is not sufficient

·        Reliable tenant and subscription lineage plus stronger workload, identity, source, host, resource, VM, VNet, subnet, NSG, route table, disk, snapshot, Storage, Key Vault, backup vault, managed identity, service principal, KVM host, compute node, guest, tenant, image, workload, or correlation linkage to self-managed KVM post-fault context must exist

·        Azure Activity logs, Azure Resource Manager events, Defender for Cloud, Sentinel, NSG flow logs, Azure Firewall logs, DNS logs, Key Vault logging, Storage logging, disk and snapshot activity, backup logs, sensitive-resource inventories, KVM host context, VM placement context, and event ordering determine deployment confidence

Downstream GCP Cloud Activity

This behavior is covered by conditional downstream Google Cloud-impact detection where self-managed KVM host-fault context, nested virtualization exposure, guest-linked fault activity, post-fault rare egress, sensitive dependency access, storage access, metadata access, identity access, orchestration access, or repeated guest-linked instability can be joined to Google Cloud activity.

Mapped Coverage

·        GCP coverage for suspicious Google Cloud Admin Activity, Data Access activity, IAM policy changes, role changes, service-account activity, service-account impersonation, Cloud Storage access, Secret Manager access, Cloud KMS activity, Security Command Center findings, network exposure changes, firewall policy modification, route modification, Compute Engine control events, disk or snapshot access, image or artifact access, backup or recovery activity, DNS risk, VPC Flow anomalies, GKE activity, Cloud Run activity, App Engine activity, cross-project access, project activity, organization activity, and sensitive resource access following self-managed KVM post-fault context

·        Splunk, Elastic, and QRadar coverage where Google Cloud audit logs and KVM host context are ingested into the same analytics environment

·        SIGMA coverage only where target backends can map Google Cloud events into local event-rule templates and perform backend-native correlation

Coverage Qualification

·        Google Cloud activity alone is not sufficient

·        Google Cloud console access alone is not sufficient

·        IAM or service-account activity alone is not sufficient

·        Cloud Storage, Secret Manager, or Cloud KMS access alone is not sufficient

·        Firewall policy, route, or load-balancer modification alone is not sufficient

·        Reliable organization and project lineage plus stronger workload, identity, source, host, resource, Compute Engine instance, VPC network, subnet, firewall policy, route, Storage bucket, secret, KMS key, service account, KVM host, compute node, guest, tenant, image, workload, or correlation linkage to self-managed KVM post-fault context must exist

·        Google Cloud Admin Activity logs, Data Access logs, Cloud Storage logging, Secret Manager logging, Cloud KMS visibility, Security Command Center context, Chronicle enrichment, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, service-account baseline quality, sensitive-resource inventories, KVM host context, VM placement context, and event ordering determine deployment confidence

NDR / Network Behavioral Analytics Coverage Disposition

NDR / Network Behavioral Analytics provides primary network-behavior and supporting sequence coverage where KVM host-fault context, nested virtualization exposure, sensitive dependency access, rare compute-host egress, tenant-network access, management-plane access, storage access, backup access, metadata access, identity access, orchestration access, or downstream cloud activity can be paired with observable network behavior.

Coverage may include rare compute-host egress, unusual destination ports, suspicious ASN, new or rare domains, abnormal destination geography, destination reputation anomalies, proxy anomalies, firewall anomalies, unusual protocols, callback-like behavior, tool-retrieval behavior, unusual internal service access, cross-zone access, cross-tenant access, sensitive service access, lateral-movement-like behavior, management-plane access, storage access, backup access, metadata access, and host-fault-to-network sequencing.

NDR cannot independently prove KVM exploitation, KVM shadow MMU corruption, in-kernel exploit execution, guest-to-host escape, guest compromise, host compromise, tenant compromise, cloud compromise, data theft, credential theft, or storage access without KVM host, endpoint, placement, guest, tenant, storage, identity, orchestration, cloud, or SIEM-forwarded context.

SIGMA Coverage Disposition

SIGMA provides portable event-rule template coverage for locally enriched KVM host-fault telemetry, nested virtualization exposure, high-risk guest context, post-fault sensitive dependency access, storage or backup access, metadata or identity access, control-plane activity, rare compute-host egress, sensitive destination access, unusual protocol behavior, network expansion behavior, and same-lineage correlation.

SIGMA is useful as event-level detection logic but should not be treated as a complete backend-independent sequence-correlation layer for this report. Local field mapping, enrichment-field creation, backend conversion, exception validation, and SIEM-native correlation are required.

SIGMA event rules support traceability for host-fault-to-post-fault-dependency-access, host-fault-to-egress, host-fault-to-storage-access, host-fault-to-identity-access, host-fault-to-control-plane-access, and repeated guest-linked or tenant-linked fault behavior, but the target backend must implement temporal correlation between KVM host telemetry, VM placement records, endpoint telemetry, DNS, proxy, firewall, NDR, storage logs, backup logs, identity logs, orchestration logs, and downstream cloud telemetry.

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the report’s detection model is behavioral, sequence-based, virtualization-boundary driven, host-fault driven, VM-placement dependent, nested-virtualization dependent, infrastructure-correlation based, post-fault activity based, compute-node context based, egress-correlation based, storage-access based, identity-access based, orchestration-access based, and tenant-impact based rather than static-file, malware-signature, or artifact-matching based.

YARA may provide limited supporting value only if a confirmed malicious guest artifact, host-side payload, exploit harness, loader, dropper, script artifact, archive artifact, memory artifact, credential-harvesting artifact, diagnostic-bundle payload, malicious kernel module, persistence artifact, post-escape tool, or reusable malware family artifact is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

Coverage Gaps and Non-Coverage Conditions

The S25 rule set does not directly prove KVM exploitation, KVM shadow MMU corruption, in-kernel exploit execution, guest-to-host escape, guest compromise, host compromise, tenant compromise, cloud compromise, data theft, credential theft, or persistence by itself.

Coverage Weakens Under the Following Conditions

·        Linux kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, infrastructure health logs, crash records, systemd journal events, host reboot telemetry, host quarantine records, migration records, evacuation records, host-disablement records, or compute-node state telemetry are unavailable, delayed, truncated, or not retained

·        KVM compute hosts are not consistently tagged by host ID, host name, compute node, compute pool, nested virtualization exposure, self-managed status, tenant, project, guest, image, workload, exposure state, or business criticality

·        VM placement records, guest ID, tenant ID, project ID, image ID, workload ID, compute-node mapping, compute-pool mapping, migration mapping, evacuation mapping, and host-disablement mapping are unavailable, stale, delayed, or not retained

·        Nested virtualization exposure inventory for x86 KVM hosts, self-managed KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, and multi-tenant virtualization hosts is unavailable or stale

·        Approved nested virtualization tenants, images, workloads, compute pools, and host groups are not maintained

·        Guest-side nested virtualization activity, guest kernel-module activity, high-risk image context, customer-managed guest context, externally provisioned guest context, CI-controlled guest context, sandbox guest context, or malware-analysis guest context is unavailable or not joined to host context

·        Host-fault-to-post-fault, host-fault-to-egress, host-fault-to-storage-access, host-fault-to-identity-access, host-fault-to-orchestration-access, host-fault-to-cloud-activity, and repeated guest-linked fault correlation windows are not tuned

·        Endpoint or EDR telemetry from KVM compute hosts, self-managed virtualization hosts, private cloud compute nodes, hosting-provider KVM nodes, CI KVM runners, sandbox hosts, malware-analysis hosts, or cloud-hosted self-managed KVM systems is unavailable, incomplete, delayed, or not mapped to KVM host context

·        File, process, command-line, parent-process, user, service, persistence, network, artifact, credential, kernel module, host log, crash dump, VM disk, VM snapshot, memory dump, cloud-init, metadata, libvirt, QEMU, storage credential, backup credential, orchestration credential, monitoring credential, or temporary staging telemetry is unavailable

·        Sensitive virtualization dependencies, storage backends, image repositories, snapshot repositories, backup systems, metadata services, identity services, orchestration APIs, migration networks, management networks, tenant networks, monitoring services, logging services, VM disk paths, snapshot paths, memory paths, credential paths, service file paths, and temporary staging paths are not maintained

·        DNS, proxy, firewall, NDR, destination reputation, destination first-seen, domain age, ASN, geography, destination port, destination protocol, internal zone, or flow telemetry is unavailable or not joined to KVM compute-host context

·        Storage logs, backup logs, metadata service logs, identity logs, orchestration logs, monitoring logs, logging-service records, migration logs, management-plane records, tenant-network records, or sensitive service records are unavailable or not normalized

·        Approved administrator users, service accounts, backup users, storage users, orchestration users, monitoring users, vendor-support users, incident-response users, maintenance windows, patch windows, reboot windows, backup windows, migration windows, kernel-testing windows, CI windows, sandbox windows, malware-analysis windows, approved process baselines, approved file paths, approved command patterns, and approved egress destinations are not tightly scoped

·        CloudTrail management events, CloudTrail data events, GuardDuty, Security Hub, AWS Config, VPC Flow Logs, Route 53 Resolver logs, EC2 inventory, EBS events, backup events, S3 data events, IAM context, sensitive-resource inventories, or AWS workload mappings are disabled or incomplete

·        Azure Activity logs, Azure Resource Manager events, Defender for Cloud, Sentinel, Network Security Group flow logs, Azure Firewall logs, DNS logs, Key Vault logs, Storage logs, VM inventory, disk and snapshot events, backup events, managed identity telemetry, service principal telemetry, role assignment activity, sensitive-resource inventories, or Azure workload mappings are disabled or incomplete

·        Google Cloud Admin Activity logs, Data Access logs, Security Command Center context, Chronicle enrichment, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, Compute Engine activity, GKE activity, Cloud Run activity, App Engine activity, service-account inventory, sensitive-resource inventories, or Google Cloud workload mappings are disabled or incomplete

·        KVM-to-AWS, KVM-to-Azure, or KVM-to-Google Cloud workload, identity, source, host, resource, instance, VM, network, storage, secret, key, service account, managed identity, role, account, subscription, project, organization, folder, or correlation mapping is unreliable

·        Adversary activity blends into approved administrative, backup, storage, migration, patch, failover, kernel testing, nested virtualization validation, CI, sandbox, malware-analysis, vendor-support, managed-service, monitoring, security-tooling, incident-response, or emergency maintenance workflows

·        Downstream cloud activity does not occur after KVM host-fault context, nested virtualization exposure, guest-linked fault activity, post-fault rare egress, sensitive dependency access, storage access, identity access, orchestration access, or repeated guest-linked instability

·        Exploitation produces no observable KVM host instability, compute-node failure, host reboot, host quarantine, host evacuation, rare egress, sensitive dependency access, storage access, backup access, metadata access, identity access, orchestration access, tenant-network exposure, persistence behavior, credential access, endpoint artifact access, or downstream cloud activity

Traceability Conclusion

The S25 detection set provides broad behavior-led coverage across the key observable stages of self-managed KVM host exposure, nested virtualization risk, untrusted guest activity, KVM host instability, compute-node failure, host quarantine, failed migration or evacuation, VM placement lineage, post-fault sensitive dependency access, rare compute-host egress, repeated guest-linked instability, tenant-impact risk, and downstream AWS, Azure, and Google Cloud activity.

Coverage is strongest for host-fault-to-post-fault sequencing, nested-virtualization-to-host-instability correlation, untrusted-guest-to-host-fault correlation, repeated guest-linked or tenant-linked host-fault clustering, sensitive storage or backup access, metadata or identity access, orchestration access, management-plane access, tenant-network access, rare compute-host egress, and downstream cloud activity when telemetry is normalized and sequence correlation is available.

The rule set intentionally avoids CVE-label-only matching, kernel-version-only matching, vendor-name-only matching, exploit-name-only matching, public proof-of-concept-only matching, static payload strings, isolated source IPs, guest root conditions, single KVM fault strings, single kernel messages, single host reboots, single cloud events, command strings, file hashes, scanner signatures, campaign names, actor branding, tool names, and other single-event conclusions as the basis for detection. Detection confidence depends on correlating KVM host-fault telemetry, nested virtualization exposure, guest context, placement context, sensitive dependency access, egress behavior, storage behavior, identity behavior, orchestration activity, tenant impact, and downstream cloud behavior rather than treating any single event category as proof of compromise.

S27 Behavior & Log Artifacts

Purpose

This section identifies the primary behavior and log artifacts that support detection, investigation, triage, and validation for KVM host-fault activity, nested virtualization exposure, untrusted guest activity, VM placement lineage, post-fault sensitive dependency access, rare compute-host egress, tenant-network exposure, storage access, backup access, metadata access, identity access, orchestration access, and downstream AWS, Azure, and Google Cloud activity where self-managed KVM telemetry or provider-supplied host context can be joined to cloud telemetry.

The artifacts below are behavior-led. They should not be treated as proof of KVM exploitation, KVM shadow MMU corruption, in-kernel exploit execution, guest-to-host escape, host compromise, tenant compromise, cloud compromise, data theft, credential theft, or persistence unless they are correlated into a coherent sequence.

Primary Artifact Categories

·        Linux kernel, KVM, QEMU, libvirt, virtqemud, systemd journal, compute-agent, infrastructure health, crash, reboot, quarantine, evacuation, migration, and compute-node state artifacts

·        Nested virtualization exposure, untrusted guest, high-risk image, guest kernel-module activity, guest virtualization activity, tenant, project, image, workload, compute-node, and compute-pool artifacts

·        VM placement, same-host lineage, same-compute-pool lineage, same-guest lineage, same-tenant lineage, same-image lineage, same-workload lineage, and repeated fault-clustering artifacts

·        Sensitive virtualization dependency artifacts involving storage backends, image repositories, snapshot repositories, backup systems, metadata services, identity services, orchestration APIs, migration networks, management networks, tenant networks, monitoring services, logging services, VM disks, VM snapshots, memory dumps, host logs, crash dumps, SSH material, credentials, keys, service files, and temporary staging locations

·        DNS, proxy, firewall, NDR, flow telemetry, rare destination, destination reputation, first-seen status, domain age, ASN, geography, protocol, destination port, and compute-host egress artifacts

·        Endpoint and EDR artifacts involving process execution, file access, service activity, persistence behavior, credential access, kernel module activity, artifact staging, archive activity, transfer activity, and outbound network behavior on self-managed KVM hosts

·        Downstream AWS, Azure, and Google Cloud activity artifacts following KVM host-fault context, nested virtualization exposure, post-fault rare egress, sensitive dependency access, storage access, identity access, orchestration access, or repeated guest-linked instability

·        KVM host, compute node, compute pool, guest, tenant, project, image, workload, source, destination, cloud-principal, cloud-resource, event-timestamp, and incident-response correlation artifacts

KVM Host-Fault and Virtualization-Boundary Artifacts

Relevant Artifacts

KVM host ID, KVM host name, host role, compute node, compute pool, self-managed KVM flag, nested virtualization exposure flag, Linux kernel message, KVM fault message, KVM MMU fault, shadow-paging fault, nested virtualization fault, memory-management fault, unexpected role fault, invalid page state, kernel panic, kernel oops, soft lockup, watchdog event, crash dump, host reboot, compute-node reboot, host quarantine, compute-node disablement, host evacuation, failed migration, KVM service restart, QEMU crash, libvirt restart, virtqemud restart, infrastructure health event, systemd journal event, crash timestamp, guest context, tenant context, image context, workload context, and event timestamp.

Useful Log Sources

·        Linux kernel logs

·        KVM logs

·        QEMU logs

·        libvirt logs

·        virtqemud logs

·        systemd journal records

·        Compute-agent logs

·        Infrastructure health logs

·        Crash records

·        Host reboot telemetry

·        Host quarantine records

·        Compute-node disablement records

·        Migration and evacuation records

·        VM placement records

·        SIEM-normalized KVM host telemetry

·        Private-cloud or hosting-platform inventory

·        Incident-response records where available

Detection Use

These artifacts support detection when KVM host-fault activity or virtualization-boundary stress is joined with nested virtualization exposure, untrusted guest context, high-risk image context, repeated guest-linked faults, post-fault sensitive dependency access, rare compute-host egress, storage access, backup access, identity access, orchestration access, tenant-network access, or downstream cloud activity.

Investigation Use

Investigators should determine whether the host-fault activity is expected for patching, kernel testing, live migration, evacuation, failover, host maintenance, CI activity, sandbox activity, malware-analysis workflows, backup workflows, vendor support, incident-response activity, hardware instability, storage instability, or known platform defects. They should also review whether host-fault activity follows nested virtualization or high-risk guest activity and whether it is followed by sensitive dependency access, rare egress, endpoint artifact access, credential access, persistence behavior, tenant impact, or cloud activity.

Non-Coverage Conditions

A kernel panic alone does not prove exploitation. A KVM fault string alone does not prove guest-to-host escape. A QEMU or libvirt restart alone is not sufficient. A host reboot alone is not sufficient. A compute-node evacuation alone is not sufficient. A vulnerable-kernel observation alone is not sufficient. These artifacts require correlation with KVM host identity, nested virtualization exposure, untrusted guest context, VM placement lineage, repeated fault clustering, post-fault behavior, sensitive dependency access, rare egress, endpoint context, storage context, identity context, orchestration context, tenant context, or downstream cloud activity before they become actionable as compromise-oriented detection evidence.

Nested Virtualization and High-Risk Guest Artifacts

Relevant Artifacts

Nested virtualization exposure flag, x86 KVM host indicator, nested-virtualization-enabled compute pool, guest ID, tenant ID, project ID, image ID, workload ID, VM placement record, guest owner, customer-managed guest label, externally provisioned guest label, partner-managed guest label, CI-controlled guest label, sandbox guest label, malware-analysis guest label, high-risk image label, guest kernel-module activity, guest virtualization-extension activity, guest nested hypervisor activity, guest nested VM lifecycle activity, guest-to-host scheduling context, compute-pool assignment, host group, migration history, and event timestamp.

Useful Log Sources

·        VM placement records

·        Compute scheduler logs

·        Private-cloud inventory

·        Hosting-platform inventory

·        OpenStack Nova or equivalent compute inventory where applicable

·        Guest metadata records

·        Tenant and project inventory

·        Image registry records

·        CI runner inventory

·        Sandbox inventory

·        Malware-analysis platform inventory

·        Nested virtualization exposure inventory

·        SIEM enrichment datasets

·        CMDB or asset inventory

·        Incident-response records where available

Detection Use

These artifacts support detection when nested virtualization exposure or high-risk guest context is joined with KVM host-fault activity, repeated guest-linked instability, post-fault sensitive dependency access, rare compute-host egress, tenant-network access, or downstream cloud activity. They are useful for prioritizing exposed compute pools and distinguishing routine host instability from host instability involving higher-risk guest context.

Investigation Use

Investigators should determine whether nested virtualization is approved for the host, compute pool, tenant, image, workload, CI process, sandbox workflow, malware-analysis process, or hosting use case. They should review whether guest activity aligns to expected workload behavior and whether the same guest, tenant, image, workload, compute pool, or host group appears in repeated fault activity or post-fault dependency access.

Non-Coverage Conditions

Nested virtualization exposure alone is not sufficient. Guest root access alone is not sufficient. A high-risk guest label alone is not sufficient. A tenant label alone is not sufficient. A CI runner or sandbox label alone is not sufficient. These artifacts require KVM host-fault context, post-fault behavior, same-host lineage, same-compute-pool lineage, same-guest lineage, same-tenant lineage, same-image lineage, same-workload lineage, repeated fault clustering, sensitive dependency access, rare egress, or downstream cloud-impact context.

Post-Fault Sensitive Dependency Artifacts

Relevant Artifacts

Storage backend access, snapshot repository access, image repository access, backup system access, metadata service access, identity service access, orchestration API access, migration network access, management network access, tenant network access, monitoring service access, logging service access, VM disk path, VM snapshot path, memory dump path, host log path, crash dump path, SSH key path, service credential path, storage credential path, backup credential path, orchestration credential path, monitoring credential path, cloud-init path, libvirt artifact path, QEMU artifact path, kernel module path, service file path, temporary staging path, archive creation, transfer activity, sensitive object name, sensitive object ID, process identity, user identity, source host, destination host, and event timestamp.

Useful Log Sources

·        Endpoint or EDR telemetry

·        SentinelOne telemetry

·        Linux audit logs

·        File access telemetry

·        Process execution telemetry

·        Service manager logs

·        Storage logs

·        Backup logs

·        Metadata service logs

·        Identity service logs

·        Orchestration logs

·        Migration logs

·        Management-plane logs

·        Monitoring logs

·        Logging-service records

·        SIEM-normalized sensitive dependency telemetry

·        Incident-response collection records

Detection Use

These artifacts support detection when sensitive virtualization dependencies are accessed after KVM host-fault activity or virtualization-boundary stress. They are useful for identifying possible post-escape collection, staging, credential access, storage access, backup access, metadata access, identity access, orchestration access, or tenant-impact behavior.

Investigation Use

Investigators should determine whether access to storage, backup, metadata, identity, orchestration, migration, management, monitoring, logging, VM disk, snapshot, memory, credential, or host artifact locations is expected for the user, process, host, workload, maintenance window, backup workflow, migration workflow, monitoring workflow, vendor support activity, or incident-response collection. They should review whether activity follows KVM host-fault context and whether it is paired with rare egress, endpoint artifact staging, persistence behavior, tenant-network access, or cloud activity.

Non-Coverage Conditions

Storage access alone is not sufficient. Backup access alone is not sufficient. Metadata access alone is not sufficient. Identity access alone is not sufficient. VM disk access alone is not sufficient. Snapshot access alone is not sufficient. Host log access alone is not sufficient. These artifacts require prior KVM host-fault or boundary-stress context, nested virtualization exposure, untrusted guest context, same-host lineage, same-guest lineage, same-tenant lineage, same-image lineage, same-workload lineage, sensitive object lineage, rare egress, endpoint context, or downstream cloud-impact context.

Rare Compute-Host Egress and Network Expansion Artifacts

Relevant Artifacts

Destination domain, destination IP, destination port, destination reputation, destination first-seen status, destination domain age, destination ASN, destination geography, network protocol, unusual protocol indicator, proxy action, firewall action, DNS query, NDR flow, source KVM host, source compute node, source compute pool, source IP, management network indicator, storage network indicator, backup network indicator, metadata network indicator, identity network indicator, orchestration network indicator, tenant network indicator, cross-zone access indicator, cross-tenant access indicator, callback-like behavior, beacon-like behavior, tool-retrieval-like behavior, lateral-movement-like behavior, egress baseline, destination baseline, and event timestamp.

Useful Log Sources

·        DNS logs

·        Proxy logs

·        Firewall logs

·        NDR / Network Behavioral Analytics telemetry

·        NetFlow or equivalent flow telemetry

·        Endpoint network telemetry

·        SentinelOne telemetry where available

·        VPC Flow Logs where applicable

·        Data-center flow logs

·        Storage network logs

·        Backup network logs

·        Management network logs

·        SIEM-normalized egress telemetry

Detection Use

These artifacts support detection when rare or suspicious outbound, east-west, cross-zone, cross-tenant, management-plane, storage, backup, metadata, identity, or orchestration communication occurs after KVM host-fault context, nested virtualization exposure, sensitive dependency access, or repeated guest-linked instability. They are useful for identifying post-fault expansion, staging, callback-like behavior, tool retrieval, lateral movement, storage access, backup access, management-plane access, or tenant-impact paths.

Investigation Use

Investigators should determine whether the destination is expected for vendor support, update retrieval, license validation, telemetry, monitoring, backup, DNS, NTP, syslog, storage access, migration, failover, security tooling, vulnerability validation, incident response, or approved business processes. They should review destination age, reputation, ASN, geography, port, protocol, proxy action, firewall action, timing, compute-host identity, KVM host lineage, tenant context, and sensitive dependency linkage.

Non-Coverage Conditions

Rare egress alone is not sufficient. A suspicious destination alone is not sufficient. Destination reputation alone is not sufficient. New domain age alone is not sufficient. Unusual destination port alone is not sufficient. A single outbound connection alone is not sufficient. These artifacts require prior KVM host-fault context, nested virtualization exposure, untrusted guest context, same-host lineage, sensitive dependency access, storage access, backup access, metadata access, identity access, orchestration access, tenant-network access, endpoint context, or downstream cloud-impact context.

VM Placement, Tenant, Image, and Workload Artifacts

Relevant Artifacts

VM placement record, guest ID, tenant ID, project ID, image ID, workload ID, compute node, compute pool, host group, instance ID, migration record, evacuation record, host-disablement record, tenant network, workload owner, image source, image age, image risk, workload criticality, service owner, exposure state, repeated guest-linked fault count, repeated tenant-linked fault count, repeated image-linked fault count, repeated workload-linked fault count, and event timestamp.

Useful Log Sources

·        VM placement records

·        Compute scheduler logs

·        Migration records

·        Evacuation records

·        Host-disablement records

·        Tenant inventory

·        Project inventory

·        Image inventory

·        Workload inventory

·        CMDB or asset inventory

·        Private-cloud inventory

·        Hosting-platform inventory

·        Cloud workload inventory where applicable

·        SIEM enrichment datasets

Detection Use

These artifacts support detection when KVM host-fault behavior, post-fault dependency access, rare egress, or cloud activity can be mapped to the same compute node, compute pool, guest, tenant, image, workload, host group, or instance. They are useful for identifying repeated fault clustering and prioritizing potential tenant-impact scenarios.

Investigation Use

Investigators should determine whether the guest, tenant, image, workload, compute pool, or host group has a known maintenance, migration, patching, kernel testing, CI, sandbox, malware-analysis, or incident-response explanation. They should review whether repeated faults cluster around the same lineage and whether post-fault behavior affects sensitive dependencies, tenant networks, management networks, storage networks, backup systems, or downstream cloud resources.

Non-Coverage Conditions

VM placement metadata alone is not sufficient. Tenant identity alone is not sufficient. Image identity alone is not sufficient. Workload identity alone is not sufficient. Compute-pool membership alone is not sufficient. A repeated-fault counter alone is not sufficient. These artifacts require KVM host-fault context, nested virtualization exposure, untrusted guest context, post-fault sensitive dependency access, rare egress, same-lineage clustering, endpoint context, or downstream cloud-impact context.

Downstream AWS Cloud Artifacts

Relevant Artifacts

CloudTrail management event, CloudTrail data event, IAM activity, role assumption, access-key activity, Secrets Manager access, Systems Manager or parameter access, KMS activity, S3 enumeration or access, EBS volume access, EBS snapshot access, AMI or image access, backup access, CloudWatch log access, security group modification, route table modification, network ACL modification, EC2 instance-control activity, cross-account access, GuardDuty finding, Security Hub finding, AWS Config change, VPC Flow anomaly, Route 53 Resolver query risk, account ID, region, principal ARN, role ARN, source IP, user agent, resource ID, EC2 instance ID, VPC ID, subnet ID, security group ID, volume ID, snapshot ID, bucket name, secret ID, parameter name, KVM host ID, compute node, guest ID, tenant ID, image ID, workload ID, and event timestamp.

Useful Log Sources

·        AWS CloudTrail management events

·        AWS CloudTrail data events

·        GuardDuty

·        Security Hub

·        AWS Config

·        VPC Flow Logs

·        Route 53 Resolver logs

·        EC2 inventory

·        EBS events

·        AWS Backup events

·        S3 data events

·        IAM logs

·        CloudWatch logs

·        SIEM-normalized AWS telemetry

·        SIEM-forwarded KVM AWS context

Detection Use

These artifacts support downstream AWS cloud-impact detection only when self-managed KVM host-fault context, nested virtualization exposure, guest-linked fault activity, post-fault rare egress, sensitive dependency access, storage access, metadata access, identity access, orchestration access, or repeated guest-linked instability is present and AWS activity is objectively suspicious.

Investigation Use

Investigators should determine whether AWS activity aligns to the same AWS account, EC2 instance, VPC, subnet, source IP, IAM role, assumed role, workload, volume, snapshot, bucket, secret, parameter, resource, KVM host, compute node, guest, tenant, image, workload, or equivalent normalized lineage tied to the KVM context. They should review whether activity involves high-risk events, access-key novelty, sensitive resources, secrets access, KMS activity, S3 activity, EBS snapshot access, backup access, logging changes, security-control modification, network-control changes, or administrative changes.

Non-Coverage Conditions

AWS activity alone is not sufficient. AWS console access alone is not sufficient. IAM activity alone is not sufficient. Role assumption alone is not sufficient. Secrets Manager, KMS, S3, EBS, snapshot, or backup access alone is not sufficient. Security group or route modification alone is not sufficient. Cloud-only anomalies must not be attributed to KVM exploitation, guest-to-host escape, host compromise, tenant compromise, or cloud compromise unless reliable self-managed KVM host context and workload, source, identity, or resource-lineage correlation exist.

Downstream Azure Cloud Artifacts

Relevant Artifacts

Azure Activity event, Azure Resource Manager activity, Defender for Cloud alert, Sentinel incident, managed identity activity, service-principal activity, role assignment, Key Vault access, Storage access, disk access, snapshot access, backup access, network security group modification, route table modification, Azure Firewall or policy activity, VM control activity, cross-subscription access, NSG flow anomaly, DNS query risk, tenant ID, subscription ID, resource group, normalized identity ID, application ID, service principal ID, managed identity ID, role definition ID, source IP, user agent, resource ID, VM ID, VNet ID, subnet ID, NSG ID, route table ID, disk ID, snapshot ID, Storage account name, Key Vault name, backup vault name, KVM host ID, compute node, guest ID, tenant ID, image ID, workload ID, and event timestamp.

Useful Log Sources

·        Azure Activity logs

·        Azure Resource Manager activity

·        Defender for Cloud

·        Microsoft Sentinel

·        Network Security Group flow logs

·        Azure Firewall logs

·        DNS logs

·        Key Vault logs

·        Storage logs

·        VM inventory

·        Disk and snapshot events

·        Backup events

·        Managed identity telemetry

·        Service principal telemetry

·        Role assignment activity

·        SIEM-normalized Azure telemetry

·        SIEM-forwarded KVM Azure context

Detection Use

These artifacts support downstream Azure cloud-impact detection only when self-managed KVM host-fault context, nested virtualization exposure, guest-linked fault activity, post-fault rare egress, sensitive dependency access, storage access, metadata access, identity access, orchestration access, or repeated guest-linked instability is present and Azure activity is objectively suspicious.

Investigation Use

Investigators should determine whether Azure activity aligns to the same tenant, subscription, resource group, VM, VNet, subnet, source IP, managed identity, service principal, role assignment, disk, snapshot, Storage account, Key Vault, backup vault, KVM host, compute node, guest, tenant, image, workload, or equivalent normalized lineage tied to the KVM context. They should review whether activity involves role changes, Key Vault access, Storage access, disk or snapshot access, backup access, network security changes, route changes, Defender for Cloud alerts, Sentinel incidents, diagnostic gaps, or sensitive resource access.

Non-Coverage Conditions

Azure activity alone is not sufficient. Azure portal access alone is not sufficient. Azure Activity alone is not sufficient. Role assignment alone is not sufficient. Key Vault, Storage, disk, snapshot, or backup access alone is not sufficient. NSG or route modification alone is not sufficient. Cloud-only anomalies must not be attributed to KVM exploitation, guest-to-host escape, host compromise, tenant compromise, or cloud compromise unless reliable self-managed KVM host context and workload, source, identity, or resource-lineage correlation exist.

Downstream GCP Cloud Artifacts

Relevant Artifacts

Google Cloud Admin Activity, Data Access activity, IAM policy change, role binding, service-account activity, service-account impersonation, Cloud Storage access, Secret Manager access, Cloud KMS activity, Security Command Center finding, firewall policy modification, route modification, Compute Engine control event, disk or snapshot access, image or artifact access, backup or recovery activity, DNS risk, VPC Flow anomaly, GKE activity, Cloud Run activity, App Engine activity, cross-project access, principal email, service account ID, organization ID, folder ID, project ID, source IP, user agent, method name, resource name, Compute instance ID, VPC network name, subnet name, firewall policy name, route name, Cloud Storage bucket name, secret name, KMS key name, KVM host ID, compute node, guest ID, tenant ID, image ID, workload ID, and event timestamp.

Useful Log Sources

·        Google Cloud Admin Activity audit logs

·        Google Cloud Data Access audit logs

·        Security Command Center

·        Chronicle or SIEM-normalized Google Cloud telemetry

·        VPC Flow Logs

·        Cloud DNS logs

·        Cloud Armor logs

·        Cloud Storage logs

·        Secret Manager logs

·        Cloud KMS logs

·        Compute Engine activity

·        GKE activity

·        Cloud Run activity

·        App Engine activity

·        IAM logs

·        Service-account inventory

·        SIEM-forwarded KVM GCP context

Detection Use

These artifacts support downstream Google Cloud-impact detection only when self-managed KVM host-fault context, nested virtualization exposure, guest-linked fault activity, post-fault rare egress, sensitive dependency access, storage access, metadata access, identity access, orchestration access, or repeated guest-linked instability is present and Google Cloud activity is objectively suspicious.

Investigation Use

Investigators should determine whether Google Cloud activity aligns to the same organization, folder, project, Compute instance, VPC network, subnet, source IP, principal, service account, Cloud Storage bucket, Secret Manager secret, KMS key, GKE cluster, Cloud Run service, App Engine service, KVM host, compute node, guest, tenant, image, workload, or equivalent normalized lineage tied to the KVM context. They should review whether activity involves IAM changes, service-account activity, Cloud Storage access, Secret Manager access, KMS activity, firewall or route changes, Security Command Center findings, cross-project access, workload-control activity, or sensitive resource access.

Non-Coverage Conditions

Google Cloud activity alone is not sufficient. Google Cloud console access alone is not sufficient. IAM or service-account activity alone is not sufficient. Cloud Storage, Secret Manager, or Cloud KMS access alone is not sufficient. Firewall policy, route, or load-balancer modification alone is not sufficient. Cloud-only anomalies must not be attributed to KVM exploitation, guest-to-host escape, host compromise, tenant compromise, or cloud compromise unless reliable self-managed KVM host context and workload, source, identity, or resource-lineage correlation exist.

YARA Artifact Disposition

YARA has no deployable primary-rule artifact set for this EXP report.

YARA is not viable as a primary artifact model because the report’s detection surface is behavioral, sequence-based, virtualization-boundary driven, host-fault driven, VM-placement dependent, nested-virtualization dependent, infrastructure-correlation based, post-fault activity based, compute-node context based, egress-correlation based, storage-access based, identity-access based, orchestration-access based, and tenant-impact based rather than static-file, malware-signature, or artifact-matching based.

YARA may become useful only if a confirmed malicious guest artifact, host-side payload, exploit harness, loader, dropper, script artifact, archive artifact, memory artifact, credential-harvesting artifact, diagnostic-bundle payload, malicious kernel module, persistence artifact, post-escape tool, or reusable malware family artifact is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

S28 Detection Strategy and SOC Implementation Guidance

Figure 5

Purpose

This section provides implementation guidance for operationalizing the S25 rule set and S26 traceability model across Linux kernel telemetry, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent telemetry, infrastructure health telemetry, VM placement records, nested virtualization exposure inventory, NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, GCP, endpoint, EDR, DNS, proxy, firewall, SIEM, SOAR, and incident-response environments.

The detection strategy is sequence-based. It prioritizes correlated behavior over single-event alerting and avoids treating a single CVE label, Linux kernel version, KVM fault string, exploit name, public proof-of-concept reference, guest root condition, guest image name, tenant name, source IP, command string, file path, kernel message, cloud event, vulnerable-version observation, scanner hit, or static indicator as proof of compromise.

Implementation Strategy

Deploy the detection model in layered stages:

·        KVM host ID, host name, self-managed status, compute node, compute pool, host role, nested virtualization exposure, guest ID, tenant ID, project ID, image ID, workload ID, exposure state, and business criticality first

·        Linux kernel, KVM, QEMU, libvirt, virtqemud, systemd journal, compute-agent, infrastructure health, crash, reboot, quarantine, migration, evacuation, and compute-node state context second

·        Nested virtualization exposure, high-risk guest, guest virtualization activity, guest kernel-module activity, customer-managed guest, externally provisioned guest, CI-controlled guest, sandbox, malware-analysis, and high-risk image context third

·        VM placement, same-host lineage, same-compute-pool lineage, same-guest lineage, same-tenant lineage, same-image lineage, same-workload lineage, and repeated fault-clustering context fourth

·        Sensitive dependency, storage, snapshot, image repository, backup, metadata, identity, orchestration, migration, management, monitoring, logging, tenant-network, host-file, credential, key, service, and temporary staging context fifth

·        DNS, proxy, firewall, NDR, destination reputation, first-seen status, domain age, ASN, geography, destination port, protocol, unusual compute-host egress, and east-west network behavior sixth

·        Endpoint and EDR context involving process, file, service, persistence, credential, kernel module, archive, transfer, staging, and outbound network behavior seventh

·        Downstream AWS, Azure, and Google Cloud cloud-impact correlation eighth

·        Alert promotion only after local telemetry validation, false-positive baselining, suppression governance, and triage playbook alignment

Telemetry Normalization Requirements

Implementation requires normalized entity and time correlation across Linux kernel, KVM, QEMU, libvirt, virtqemud, systemd journal, compute-agent, infrastructure health, VM placement, nested virtualization inventory, tenant inventory, image inventory, workload inventory, endpoint, EDR, DNS, proxy, firewall, NDR, storage, backup, metadata, identity, orchestration, AWS, Azure, Google Cloud, SOAR, incident-response, and SIEM telemetry.

Minimum Normalization Requirements

·        KVM host ID

·        KVM host name

·        Self-managed KVM indicator

·        Host role

·        Compute node

·        Compute pool

·        Host group

·        Guest ID

·        Tenant ID

·        Project ID

·        Image ID

·        Workload ID

·        Instance ID where applicable

·        Business criticality

·        Exposure state

·        Nested virtualization exposure

·        Approved nested virtualization context

·        High-risk guest context

·        Guest activity context

·        Guest kernel-module activity

·        Linux kernel event

·        KVM event

·        QEMU event

·        libvirt event

·        virtqemud event

·        Systemd journal event

·        Infrastructure health event

·        Crash event

·        Host reboot event

·        Host quarantine event

·        Compute-node disablement event

·        Host evacuation event

·        Migration event

·        KVM MMU or shadow-paging fault context

·        Memory-management fault context

·        Repeated guest-linked fault count

·        Repeated tenant-linked fault count

·        Repeated image-linked fault count

·        Repeated workload-linked fault count

·        Same-host lineage

·        Same-compute-pool lineage

·        Same-guest lineage

·        Same-tenant lineage

·        Same-image lineage

·        Same-workload lineage

·        Sensitive storage dependency

·        Snapshot repository

·        Image repository

·        Backup system

·        Metadata service

·        Identity service

·        Orchestration API

·        Migration network

·        Management network

·        Tenant network

·        Monitoring service

·        Logging service

·        VM disk path

·        VM snapshot path

·        Memory dump path

·        Host log path

·        Crash dump path

·        Credential path

·        Key path

·        Service file path

·        Temporary staging path

·        Process name

·        Process command line

·        Parent process

·        Process user

·        File action

·        Service action

·        Persistence indicator

·        Destination domain

·        Destination IP

·        Destination port

·        Destination protocol

·        Destination reputation

·        Destination first-seen status

·        Destination domain age

·        Destination ASN

·        Destination geography

·        Proxy action

·        Firewall action

·        Network behavior

·        AWS account, role, principal, region, EC2 instance, VPC, subnet, security group, EBS volume, snapshot, S3 bucket, secret, parameter, KMS, backup vault, and resource

·        Azure tenant, subscription, resource group, VM, VNet, subnet, NSG, route table, managed identity, service principal, disk, snapshot, Storage account, Key Vault, backup vault, and resource

·        GCP organization, folder, project, Compute instance, VPC network, subnet, firewall policy, route, principal, service account, Cloud Storage bucket, Secret Manager secret, KMS key, GKE, Cloud Run, App Engine, and resource

·        SOAR case ID

·        Incident-response case ID

·        Event timestamp

·        Event source

·        Approved workflow context

Correlation Requirements

Rules should use bounded correlation windows that reflect the relationship between KVM host-fault or virtualization-boundary stress and follow-on sensitive dependency access, rare compute-host egress, endpoint behavior, repeated guest-linked instability, tenant-impact behavior, or downstream cloud behavior.

Recommended Starting Windows

·        Nested virtualization or high-risk guest activity to KVM host-fault context within 30 minutes

·        KVM host-fault context to compute-node reboot, quarantine, disablement, failed migration, or evacuation within 30 minutes

·        KVM host-fault context to sensitive dependency access within 4 hours

·        KVM host-fault context to storage, snapshot, image repository, backup, metadata, identity, orchestration, migration, management, monitoring, logging, or tenant-network access within 4 hours

·        KVM host-fault context to rare compute-host egress or unusual east-west network behavior within 4 hours

·        KVM host-fault context to endpoint process, file, service, credential, persistence, archive, staging, transfer, or outbound activity within 4 hours

·        Repeated guest-linked, tenant-linked, image-linked, workload-linked, compute-node-linked, or compute-pool-linked faults within 8 hours

·        Self-managed KVM host-fault context, nested virtualization exposure, rare egress, sensitive dependency access, storage access, identity access, orchestration access, or repeated guest-linked instability to AWS, Azure, or Google Cloud activity within 24 hours

·        Continued rare egress, sensitive dependency access, storage access, identity access, orchestration activity, endpoint artifact activity, tenant-network behavior, or cloud activity after incident-response containment or administrative remediation within 24 hours

These windows should be tightened in high-volume environments and extended only when host lineage, compute-pool lineage, guest lineage, tenant lineage, image lineage, workload lineage, sensitive dependency evidence, endpoint evidence, network evidence, cloud evidence, SOAR evidence, or incident-response evidence supports continuity.

Alert Promotion Guidance

Do not promote a hunt or correlation search into alert mode until the following conditions are met:

·        Required telemetry is present and normalized

·        Required field mappings are validated

·        KVM host tagging is reliable

·        Self-managed KVM status is reliable

·        Compute-node and compute-pool mapping is reliable

·        Guest, tenant, project, image, and workload mapping is reliable

·        Nested virtualization exposure inventory is reliable

·        Linux kernel, KVM, QEMU, libvirt, virtqemud, systemd journal, and compute-agent mapping is reliable

·        Host-fault and compute-node state mapping is reliable

·        VM placement and migration mapping is reliable

·        Sensitive dependency mapping is reliable

·        Storage, backup, metadata, identity, orchestration, migration, management, monitoring, logging, and tenant-network mapping is reliable

·        Endpoint process, file, service, credential, persistence, artifact, staging, and network mappings are reliable

·        DNS, proxy, firewall, NDR, destination, and flow mappings are reliable

·        AWS, Azure, and Google Cloud context is mapped only where self-managed KVM telemetry or provider-supplied host context exists

·        Entity resolution is reliable

·        Event timing and ordering are reliable

·        Approved workflow baselines are defined

·        False-positive sources are reviewed

·        High-volume expected workflows are suppressed or downgraded

·        Query performance is tested

·        Triage guidance is documented

·        Analyst review criteria are established

·        Local severity logic is calibrated

·        Alert-routing ownership is assigned

False-Positive Control

False-positive control should use allowlists, reference sets, approved workflow baselines, known source ranges, approved KVM administrators, approved nested virtualization tenants, approved nested virtualization images, approved compute pools, approved host groups, approved CI runners, approved sandbox hosts, approved malware-analysis hosts, approved backup users, approved storage users, approved orchestration users, approved monitoring users, approved vendor support sources, approved managed-service sources, approved patch workflows, approved reboot workflows, approved kernel-testing workflows, approved live-migration workflows, approved evacuation workflows, approved failover workflows, approved backup workflows, approved storage workflows, approved incident-response windows, approved file paths, approved process baselines, approved command patterns, approved egress destinations, approved service accounts, approved cloud automation identities, approved CI/CD identities, approved infrastructure-as-code workflows, and known incident-response workflows.

Common False-Positive Sources

·        Approved KVM administration

·        Approved host patching

·        Approved kernel testing

·        Approved reboot windows

·        Approved live migration

·        Approved evacuation workflows

·        Approved failover testing

·        Approved nested virtualization validation

·        Approved CI runner activity

·        Approved sandbox activity

·        Approved malware-analysis activity

·        Approved vendor support activity

·        Approved managed-service activity

·        Approved monitoring activity

·        Approved backup jobs

·        Approved storage maintenance

·        Approved image repository maintenance

·        Approved snapshot workflows

·        Approved metadata service access

·        Approved identity service access

·        Approved orchestration activity

·        Approved migration workflows

·        Approved management-plane activity

·        Approved tenant-network operations

·        Approved diagnostic collection

·        Approved incident-response collection

·        Approved security tooling

·        Approved update retrieval

·        Approved license validation

·        Approved DNS, NTP, syslog, monitoring, vendor, or business destinations

·        Approved cloud automation

·        Infrastructure-as-code workflows

·        CI/CD workflows

·        Break-glass activity

·        Platform-support activity

·        Managed-service access

·        Security tooling access

·        Incident-response activity

Triage Guidance

Initial triage should determine whether suspicious activity forms a coherent sequence rather than a single-event anomaly.

Triage Questions

·        Was KVM host-fault, virtualization-boundary stress, compute-node reboot, host quarantine, host disablement, failed migration, or evacuation observed

·        Was the affected host a self-managed KVM compute host, OpenStack compute node, private-cloud host, hosting-provider KVM node, CI KVM runner, sandbox host, malware-analysis host, or cloud-hosted self-managed KVM system

·        Was nested virtualization exposed on the affected host or compute pool

·        Was the guest context untrusted, customer-managed, externally provisioned, partner-managed, CI-controlled, sandboxed, malware-analysis related, or tied to a high-risk image

·        Did the same guest, tenant, image, workload, compute node, compute pool, or host group appear in repeated fault activity

·        Did post-fault sensitive dependency access occur

·        Did storage, snapshot, image repository, backup, metadata, identity, orchestration, migration, management, monitoring, logging, or tenant-network access occur

·        Did rare compute-host egress, suspicious destination access, new-domain access, unusual egress port, suspicious ASN, abnormal destination geography, unusual protocol behavior, cross-zone access, cross-tenant access, or management-plane access occur

·        Did endpoint telemetry show unusual process, file, service, credential, persistence, archive, staging, transfer, kernel module, or outbound activity on the KVM host

·        Did downstream AWS, Azure, or Google Cloud administrative, network, identity, storage, secret, key, snapshot, backup, workload, or sensitive-resource activity follow

·        Can the activity be linked by KVM host, compute node, compute pool, guest, tenant, image, workload, source, destination, sensitive dependency, cloud principal, cloud resource, SOAR case, incident-response case, or equivalent normalized lineage

·        Is the activity explained by approved administration, patching, kernel testing, live migration, evacuation, failover, backup, storage maintenance, monitoring, vendor support, managed-service operation, CI activity, sandbox workflow, malware-analysis workflow, security tooling, automation, incident-response activity, emergency maintenance, or known business workflow

Escalation Guidance

Escalate when multiple behavior classes align in sequence, especially when nested virtualization or high-risk guest context is followed by KVM host-fault activity, compute-node failure, host quarantine, failed migration, sensitive dependency access, rare egress, endpoint artifact activity, repeated guest-linked instability, tenant-network exposure, or downstream cloud administrative behavior.

Higher-Priority Escalation Conditions

·        The affected KVM host supports multi-tenant workloads

·        The affected KVM host supports production workloads

·        The affected KVM host supports regulated, customer, payment, account, legal, executive, operational, CI, sandbox, or malware-analysis workloads

·        The affected KVM host exposes nested virtualization

·        The affected KVM host runs untrusted, customer-managed, externally provisioned, partner-managed, CI-controlled, sandboxed, or malware-analysis guests

·        KVM host-fault context and nested virtualization exposure align

·        KVM host-fault context and high-risk guest activity align

·        KVM host-fault context and repeated guest-linked faults align

·        KVM host-fault context and compute-node reboot, host quarantine, host disablement, failed migration, or evacuation align

·        KVM host-fault context and sensitive dependency access align

·        KVM host-fault context and storage, snapshot, image repository, backup, metadata, identity, or orchestration access align

·        KVM host-fault context and rare compute-host egress align

·        KVM host-fault context and cross-zone, cross-tenant, management-plane, tenant-network, storage, backup, or metadata access align

·        KVM host-fault context and endpoint process, file, credential, persistence, archive, staging, transfer, or outbound activity align

·        AWS, Azure, or Google Cloud activity involves privileged roles, service accounts, managed identities, secrets, keys, storage, snapshots, backups, logging changes, network-control changes, security-control suppression, or administrative configuration

·        Multiple systems independently show aligned behavior

Deployment Guardrails

Do not deploy these detections as fully automated blocking or containment logic without local validation.

Do not treat a single CVE label, Linux kernel version, KVM fault string, exploit name, public proof-of-concept reference, guest root condition, guest image name, tenant name, source IP, command string, file path, kernel message, vulnerable-version observation, scanner hit, cloud event, storage event, identity event, destination, file hash, or static indicator as proof of compromise.

Do not attribute cloud-only, endpoint-only, egress-only, host-fault-only, nested-virtualization-only, placement-only, storage-only, identity-only, orchestration-only, tenant-only, or artifact-only anomalies to KVM exploitation, in-kernel exploit execution, guest-to-host escape, host compromise, tenant compromise, or cloud compromise without prior KVM host context and reliable workload, source, host, guest, tenant, image, identity, object, or resource-lineage correlation.

Do not enable high-confidence alerting until platform-specific schemas, index names, sourcetypes, DSM fields, custom properties, ECS mappings, KVM fields, kernel fields, endpoint mappings, placement mappings, tenant mappings, image mappings, workload mappings, storage mappings, backup mappings, identity mappings, orchestration mappings, DNS mappings, proxy mappings, firewall mappings, NDR mappings, CloudTrail fields, Azure fields, Google Cloud audit fields, cloud identity mappings, enrichment sources, exception lists, false-positive baselines, query performance, triage readiness, and escalation criteria have been validated.

S29 Detection Coverage Summary

Coverage Summary

The S25 detection set provides broad behavior-led coverage for KVM host-fault activity, nested virtualization exposure, untrusted guest activity, VM placement lineage, post-fault sensitive dependency access, rare compute-host egress, tenant-network exposure, storage access, backup access, metadata access, identity access, orchestration access, endpoint artifact activity, repeated guest-linked instability, and downstream AWS, Azure, and Google Cloud activity where self-managed KVM telemetry or provider-supplied host context can be joined to cloud telemetry.

Coverage is strongest when Linux kernel, KVM, QEMU, libvirt, virtqemud, systemd journal, compute-agent, infrastructure health, VM placement, tenant, image, workload, endpoint, EDR, DNS, proxy, firewall, NDR, storage, backup, metadata, identity, orchestration, AWS, Azure, Google Cloud, and SIEM telemetry are normalized and correlated into bounded sequences.

The report’s detection model intentionally avoids CVE-label-only matching, kernel-version-only matching, vendor-name-only matching, exploit-name-only matching, public proof-of-concept-only matching, static payload strings, isolated source IPs, guest root conditions, single KVM fault strings, single kernel messages, single host reboots, single cloud events, command strings, file hashes, scanner signatures, vulnerable-version observations, campaign names, actor branding, tool names, and single-event conclusions. It focuses on durable activity patterns that remain useful across KVM guest-to-host escape risk, virtualization-boundary stress, host instability, post-fault dependency access, rare egress, tenant-impact behavior, and downstream cloud activity.

Strong Coverage Areas

·        KVM host-fault and virtualization-boundary stress where Linux kernel, KVM, QEMU, libvirt, virtqemud, crash, reboot, health, and compute-node state telemetry are normalized

·        Nested virtualization exposure and high-risk guest context where self-managed KVM host inventory, compute-pool inventory, guest records, tenant records, image records, workload records, and exposure tags are available

·        Repeated guest-linked, tenant-linked, image-linked, workload-linked, compute-node-linked, and compute-pool-linked fault clustering where VM placement and lineage records are retained

·        Post-fault sensitive dependency access involving storage, image repositories, snapshot repositories, backup systems, metadata services, identity services, orchestration APIs, migration networks, management networks, monitoring services, logging services, and tenant networks

·        SentinelOne and endpoint coverage where Linux KVM compute-host telemetry includes process, file, service, credential, persistence, artifact, staging, archive, transfer, and network activity

·        Rare compute-host egress, suspicious destination access, new or rare domain access, unusual egress port, suspicious ASN, suspicious destination geography, unusual protocol behavior, callback-like behavior, tool-retrieval-like behavior, cross-zone access, cross-tenant access, and management-plane access after KVM host-fault context

·        Splunk, Elastic, QRadar, and SIGMA correlation where KVM host telemetry, VM placement records, sensitive dependency context, endpoint telemetry, network telemetry, exception context, and cloud telemetry are normalized or enriched

·        Downstream AWS, Azure, and Google Cloud activity when correlated with self-managed KVM host-fault context, nested virtualization exposure, post-fault rare egress, sensitive dependency access, storage access, identity access, orchestration access, or repeated guest-linked instability

Moderate Coverage Areas

·        KVM host-fault activity where kernel, KVM, QEMU, libvirt, virtqemud, systemd journal, or compute-agent logs are partial or inconsistently normalized

·        Nested virtualization exposure where inventory is incomplete or approved nested virtualization baselines vary by host, tenant, image, workload, CI runner, sandbox, or malware-analysis environment

·        VM placement and tenant lineage where compute scheduler records, migration records, image records, workload records, or tenant metadata are delayed, stale, or not retained

·        Sensitive dependency access where storage, backup, metadata, identity, orchestration, migration, management, monitoring, logging, or tenant-network telemetry is incomplete

·        SentinelOne and endpoint coverage where Linux KVM compute hosts have partial process, command-line, file, service, user, credential, persistence, or network telemetry

·        NDR visibility into compute-host egress, east-west behavior, storage access, backup access, metadata access, and management-plane behavior without KVM host, endpoint, placement, tenant, or dependency enrichment

·        SIGMA portability across SIEM backends

·        Cloud detection where KVM-to-AWS, KVM-to-Azure, or KVM-to-Google Cloud workload, identity, source, host, resource, instance, VM, storage, secret, key, service account, managed identity, role, account, subscription, project, organization, folder, or correlation lineage is partial

Limited Coverage Areas

·        Exploitation that produces no observable KVM host instability, compute-node failure, host reboot, host quarantine, host evacuation, rare egress, sensitive dependency access, storage access, backup access, metadata access, identity access, orchestration access, tenant-network exposure, endpoint artifact access, or downstream cloud activity

·        In-kernel exploitation that does not produce host-fault telemetry, crash telemetry, compute-node state changes, endpoint telemetry, network telemetry, or post-fault behavior

·        Guest-to-host escape activity that remains local to the host and avoids sensitive dependency access, credential access, persistence behavior, rare egress, tenant-network access, or cloud activity

·        Host compromise that uses expected administrator accounts, expected service accounts, expected source IPs, expected maintenance windows, expected backup workflows, expected migration workflows, or approved incident-response workflows

·        Sensitive dependency access that occurs through expected backup, storage maintenance, monitoring, migration, vendor support, or administrative workflows without anomalous timing or context

·        Rare egress that uses approved vendor, update, license-validation, telemetry, monitoring, DNS, NTP, syslog, backup, hosting-provider, managed-service, or business destinations

·        Tenant-impact behavior that mirrors approved migration, evacuation, failover, autoscaling, maintenance, or workload-management workflows

·        Cloud activity without reliable KVM-to-AWS, KVM-to-Azure, or KVM-to-Google Cloud workload, identity, source, host, resource, instance, VM, storage, secret, key, service-account, managed-identity, role, or correlation linkage

·        Environments without CloudTrail data events, Azure Key Vault logs, Azure Storage logs, Google Cloud Data Access logs, Cloud Storage logs, Secret Manager logs, Cloud KMS logs, VPC Flow Logs, NSG flow logs, or equivalent sensitive-service visibility

Non-Covered Areas

The S25 rule set does not directly prove:

·        KVM exploitation

·        KVM shadow MMU corruption

·        In-kernel exploit execution

·        Guest-to-host escape

·        Guest compromise

·        Host compromise

·        Tenant compromise

·        Credential theft

·        Data theft

·        Persistence

·        AWS compromise

·        Azure compromise

·        Google Cloud compromise

·        Downstream cloud compromise

·        Adversary attribution

·        Campaign attribution

These outcomes require investigation, corroborating telemetry, and incident-specific validation.

System Coverage Summary

NDR / Network Behavioral Analytics

NDR provides primary network-behavior and supporting sequence coverage for rare compute-host egress, unusual destination ports, suspicious ASN, new or rare domains, abnormal destination geography, destination reputation anomalies, proxy anomalies, firewall anomalies, unusual protocols, callback-like behavior, tool-retrieval behavior, unusual internal service access, cross-zone access, cross-tenant access, sensitive service access, lateral-movement-like behavior, management-plane access, storage access, backup access, metadata access, and host-fault-to-network sequencing.

NDR does not independently prove KVM exploitation, KVM shadow MMU corruption, in-kernel exploit execution, guest-to-host escape, guest compromise, host compromise, tenant compromise, cloud compromise, credential theft, or data theft without KVM host, endpoint, placement, guest, tenant, storage, identity, orchestration, cloud, or SIEM-forwarded context.

SentinelOne

SentinelOne provides strong supporting endpoint coverage where Linux KVM compute-host, self-managed virtualization host, private cloud compute-node, hosting-provider KVM node, CI KVM runner, sandbox host, malware-analysis host, process, command-line, file, service, credential, persistence, artifact, archive, transfer, kernel module, network, and rare-egress context can be joined to KVM host-fault activity, nested virtualization exposure, sensitive dependency access, or repeated guest-linked instability.

SentinelOne is strongest as host-side behavior context rather than as the primary source of KVM exploitation proof.

Splunk

Splunk provides strong correlation coverage when Linux kernel, KVM, QEMU, libvirt, virtqemud, compute-agent, infrastructure health, VM placement, tenant, image, workload, endpoint, file, process, DNS, proxy, firewall, NDR, storage, backup, metadata, identity, orchestration, AWS, Azure, and Google Cloud telemetry are normalized into searchable indexes with reliable field mappings, sourcetypes, lookups, summary datasets, and sequence logic.

Elastic

Elastic provides strong SIEM sequence and correlation coverage when Linux kernel, KVM, QEMU, libvirt, virtqemud, compute-agent, infrastructure health, VM placement, tenant, image, workload, endpoint, file, process, DNS, proxy, firewall, NDR, storage, backup, metadata, identity, orchestration, AWS, Azure, and Google Cloud data are normalized into ECS-compatible or locally enriched fields with reliable EQL sequencing, transforms, enrichments, value lists, and exception handling.

QRadar

QRadar provides strong correlation coverage when DSM parsing, custom properties, reference sets, reference maps, building blocks, event ordering, and offense grouping are validated across Linux kernel, KVM, QEMU, libvirt, virtqemud, compute-agent, infrastructure health, VM placement, tenant, image, workload, endpoint, file, process, DNS, proxy, firewall, NDR, storage, backup, metadata, identity, orchestration, AWS, Azure, and Google Cloud telemetry.

SIGMA

SIGMA provides portable event-rule template logic for locally enriched KVM host-fault telemetry, nested virtualization exposure, high-risk guest context, post-fault sensitive dependency access, storage or backup access, metadata or identity access, control-plane activity, rare compute-host egress, sensitive destination access, unusual protocol behavior, network expansion behavior, and same-lineage correlation.

SIGMA production value depends on SIEM translation quality, field mappings, enrichment-field creation, sequence support, wildcard behavior, case handling, backend-native correlation, and local event-source coverage.

YARA

YARA has zero deployable rules for this EXP report because no stable malicious guest artifact, host-side payload, exploit harness, loader, dropper, script artifact, archive artifact, memory artifact, malicious kernel module, persistence artifact, credential-harvesting artifact, diagnostic-bundle payload, post-escape tool, or reusable malware family is available.

AWS

AWS provides conditional downstream cloud-impact coverage when suspicious AWS activity is correlated with self-managed KVM host-fault context, nested virtualization exposure, guest-linked fault activity, post-fault rare egress, sensitive dependency access, storage access, metadata access, identity access, orchestration access, or repeated guest-linked instability through reliable AWS account lineage plus stronger workload, identity, source, host, EC2 instance, VPC, subnet, security group, EBS volume, snapshot, S3 bucket, secret, parameter, IAM role, account, KVM host, compute node, guest, tenant, image, workload, or correlation linkage.

Azure

Azure provides conditional downstream cloud-impact coverage when suspicious Azure control-plane, identity, resource, Key Vault, Storage, disk, snapshot, backup, service-principal, managed-identity, network security, route table, Defender for Cloud, Sentinel, or administrative activity is correlated with self-managed KVM context through reliable tenant and subscription lineage plus stronger workload, identity, source, host, VM, VNet, subnet, NSG, route table, disk, snapshot, Storage, Key Vault, backup vault, managed identity, service principal, KVM host, compute node, guest, tenant, image, workload, or correlation linkage.

GCP

GCP provides conditional downstream Google Cloud coverage when Google Cloud Admin Activity logs, Data Access logs, IAM logs, service-account logs, Cloud Storage logs, Secret Manager logs, KMS logs, Security Command Center context, Chronicle context, VPC Flow Logs, Cloud DNS logs, Cloud Armor logs, Compute Engine activity, GKE activity, Cloud Run activity, App Engine activity, and KVM context are normalized and correlated through organization and project lineage plus stronger workload, identity, source, host, Compute instance, VPC network, subnet, firewall policy, route, Cloud Storage bucket, Secret Manager secret, KMS key, service account, KVM host, compute node, guest, tenant, image, workload, or correlation linkage.

Coverage Conclusion

The detection set provides strong practical coverage for observable enterprise behavior associated with KVM host-fault activity, nested virtualization exposure, high-risk guest context, VM placement lineage, post-fault sensitive dependency access, rare compute-host egress, endpoint artifact activity, repeated guest-linked instability, tenant-impact risk, and downstream cloud activity.

It is strongest when multiple telemetry classes align in sequence and weakest where exploitation produces no observable KVM host instability, compute-node failure, host reboot, host quarantine, host evacuation, rare egress, sensitive dependency access, storage access, backup access, metadata access, identity access, orchestration access, endpoint artifact access, tenant-network exposure, repeated fault clustering, or downstream cloud behavior.

S30 Intelligence Maturity Assessment

Maturity Assessment Summary

The intelligence maturity level for this report is high for behavior-led detection strategy and moderate for direct compromise confirmation.

The detection model is mature because it focuses on durable behavioral relationships: nested virtualization exposure, high-risk guest context, KVM host-fault activity, compute-node failure, host quarantine, failed migration, VM placement lineage, repeated guest-linked instability, post-fault sensitive dependency access, rare compute-host egress, endpoint artifact activity, tenant-network exposure, and downstream AWS, Azure, and Google Cloud activity where self-managed KVM telemetry or provider-supplied host context can be joined to cloud telemetry.

Direct compromise confirmation remains limited because enterprise telemetry generally does not expose attacker intent, KVM shadow MMU corruption, in-kernel exploit execution, guest-to-host escape, host compromise, tenant compromise, credential theft, data theft, or persistence directly. Most environments infer misuse through correlated host-fault behavior, nested virtualization exposure, placement context, post-fault dependency access, endpoint artifacts, egress behavior, tenant impact, and downstream cloud activity.

Behavioral Intelligence Maturity

Behavioral maturity is high.

The report identifies repeatable post-exposure behavior that can be detected across Linux kernel telemetry, KVM logs, QEMU logs, libvirt logs, virtqemud logs, systemd journal records, compute-agent logs, infrastructure health telemetry, VM placement records, tenant inventory, image inventory, workload inventory, endpoint telemetry, EDR, DNS, proxy, firewall, NDR, storage logs, backup logs, metadata logs, identity logs, orchestration logs, SIEM, AWS, Azure, and Google Cloud platforms.

The behaviors are durable across CVE labels, kernel versions, exploit names, public proof-of-concept references, guest root conditions, guest image names, tenant names, source infrastructure, command strings, file paths, kernel messages, scanner signatures, actor branding, campaign names, tool names, and cloud-provider variation.

Strong Behavioral Anchors

·        KVM host-fault and virtualization-boundary stress involving kernel panic, kernel oops, soft lockup, watchdog event, crash dump, KVM service restart, QEMU crash, libvirt restart, KVM MMU fault, shadow-paging fault, nested virtualization fault, memory-management fault, unexpected role fault, invalid page state, compute-node reboot, host quarantine, host disablement, failed migration, or host evacuation

·        Nested virtualization exposure involving x86 KVM hosts, nested-virtualization-enabled compute pools, untrusted guest context, customer-managed guest workloads, externally provisioned guests, CI-controlled guests, sandbox guests, malware-analysis guests, high-risk images, guest kernel-module activity, or guest-side nested virtualization activity

·        VM placement lineage involving KVM host, compute node, compute pool, guest ID, tenant ID, project ID, image ID, workload ID, and repeated fault clustering around the same guest, tenant, image, workload, host group, or compute pool

·        Post-fault sensitive dependency access involving storage backends, image repositories, snapshot repositories, backup systems, metadata services, identity services, orchestration APIs, migration networks, management networks, tenant networks, monitoring services, logging services, VM disks, VM snapshots, memory dumps, host logs, crash dumps, SSH material, credentials, keys, and service files

·        Rare compute-host egress involving new or rare destinations, suspicious destination reputation, unusual destination geography, suspicious ASN, unusual destination port, unusual protocol behavior, callback-like behavior, tool-retrieval behavior, cross-zone access, cross-tenant access, sensitive service access, management-plane access, storage access, backup access, or metadata access

·        Endpoint artifact behavior involving unusual process execution, file access, service activity, credential access, kernel module activity, persistence behavior, staging, archive activity, transfer activity, or outbound network behavior on self-managed KVM hosts

·        Downstream AWS, Azure, or Google Cloud activity following self-managed KVM host-fault context, nested virtualization exposure, rare egress, sensitive dependency access, storage access, identity access, orchestration access, or repeated guest-linked instability

Telemetry Maturity

Telemetry maturity is moderate to high.

Linux kernel, KVM, QEMU, libvirt, virtqemud, systemd journal, compute-agent, infrastructure health, VM placement, tenant, image, workload, endpoint, EDR, DNS, proxy, firewall, NDR, storage, backup, metadata, identity, orchestration, SIEM, AWS, Azure, and Google Cloud telemetry provide strong coverage where KVM host, compute node, compute pool, guest, tenant, project, image, workload, source, destination, process, file, dependency, cloud principal, resource, and timestamp fields are available and normalized.

Telemetry maturity decreases when KVM host logs are incomplete, kernel messages are truncated, VM placement records are stale, nested virtualization exposure inventory is incomplete, guest or tenant context is unavailable, host-fault telemetry is noisy, endpoint telemetry is absent, storage or backup logs are incomplete, identity or orchestration logs are not retained, source attribution is noisy, cloud logs are not correlated, or approved workflow baselines are weak.

Cloud and Virtualization Maturity

Cloud and virtualization maturity is moderate to strong.

AWS, Azure, and Google Cloud provide useful downstream cloud-impact visibility when cloud telemetry can be joined to self-managed KVM context through workload, identity, source, host, EC2 instance, VM, Compute instance, VPC, VNet, subnet, storage, secret, key, service account, managed identity, role, resource, account, tenant, subscription, organization, project, folder, or correlation lineage.

Cloud platforms do not independently prove KVM exploitation, KVM shadow MMU corruption, in-kernel exploit execution, guest-to-host escape, host compromise, tenant compromise, credential theft, or data theft. Their strongest value comes from correlation with prior self-managed KVM host-fault context, nested virtualization exposure, sensitive dependency access, rare egress, endpoint artifact activity, tenant-network behavior, SOAR, incident-response, or SIEM-forwarded context.

Maturity increases when CloudTrail, GuardDuty, Security Hub, AWS Config, VPC Flow Logs, Route 53 Resolver logs, Azure Activity, Azure Resource Manager, Defender for Cloud, Sentinel, Key Vault, Storage, NSG flow logs, Google Cloud Admin Activity, Data Access logs, Cloud Storage logs, Secret Manager logs, KMS logs, Security Command Center, Chronicle, sensitive-resource inventories, and cloud identity mappings are normalized and validated.

Adversary-Resilience Maturity

Adversary-resilience maturity is high for behavior-led detection and moderate for high-confidence exploitation attribution.

The detection model is resilient because it avoids brittle indicators and focuses on behavior an adversary may produce when converting guest-side control or guest-to-host escape opportunity into host instability, compute-node disruption, sensitive dependency access, credential access, rare egress, endpoint artifact activity, tenant-network exposure, repeated guest-linked instability, or downstream cloud activity.

The model is less resilient when adversaries use expected administrator sources, expected service accounts, approved maintenance windows, approved backup workflows, approved migration workflows, approved vendor support paths, approved managed-service sources, approved CI or sandbox workflows, approved cloud automation, or known business destinations. It is also less resilient when adversaries avoid host instability, avoid rare egress, avoid sensitive dependency access, avoid storage access, avoid identity access, avoid orchestration activity, avoid endpoint artifact activity, avoid tenant-network behavior, avoid cloud activity, and stop activity before downstream impact.

Operationalization Maturity

Operationalization maturity is moderate.

The S25 rules are implementation-ready detection patterns, but production deployment requires local validation of schemas, index names, sourcetypes, DSM fields, custom properties, ECS mappings, KVM fields, kernel fields, QEMU fields, libvirt fields, virtqemud fields, compute-agent fields, endpoint fields, file fields, process fields, DNS fields, proxy fields, firewall fields, NDR fields, storage fields, backup fields, metadata fields, identity fields, orchestration fields, CloudTrail fields, Azure fields, Google Cloud audit fields, source mappings, asset mappings, workload mappings, guest mappings, tenant mappings, image mappings, cloud identity mappings, enrichment, exception lists, false-positive baselines, query performance, triage logic, and alert-routing decisions.

Operational maturity increases when detection owners validate each platform’s field mappings, confirm telemetry quality, baseline approved KVM administration, patching, kernel testing, live migration, evacuation, failover, nested virtualization validation, CI activity, sandbox activity, malware-analysis workflows, backup workflows, storage maintenance, vendor support, managed-service activity, cloud administration, service accounts, automation, CI/CD, infrastructure-as-code, break-glass, and incident-response workflows, and test sequence logic using realistic benign and suspicious event data.

Attribution Maturity

Attribution maturity is low to moderate.

The rule set supports detection of behavior consistent with KVM virtualization-boundary stress, guest-to-host escape risk, host-fault activity, post-fault dependency access, rare egress, endpoint artifact activity, tenant-impact behavior, and downstream cloud activity. It should not be used by itself to attribute activity to a specific adversary, campaign, exploit developer, infrastructure provider, malware family, or named threat group without external evidence and incident-specific validation.

Attribution requires corroborating evidence such as exploitation timeline, KVM host logs, crash traces, guest context, placement records, endpoint artifacts, command history, file access, credential access, sensitive dependency access, network behavior, destination infrastructure, cloud activity, victimology, actor tradecraft, and threat-intelligence reporting.

Maturity Limitations

Primary Maturity Limitations

·        Limited direct visibility into exploitation success

·        Limited direct visibility into KVM shadow MMU corruption

·        Limited direct visibility into in-kernel exploit execution

·        Limited direct visibility into guest-to-host escape

·        Limited direct visibility into host compromise

·        Limited direct visibility into tenant compromise

·        Limited direct visibility into credential theft

·        Limited direct visibility into data theft

·        Limited direct visibility into persistence

·        Variable Linux kernel, KVM, QEMU, libvirt, and virtqemud logging

·        Variable compute-agent and infrastructure health telemetry

·        Variable VM placement retention

·        Variable nested virtualization exposure inventory

·        Variable guest, tenant, image, and workload context

·        Variable host-fault telemetry quality

·        Variable endpoint and EDR visibility on KVM compute hosts

·        Variable storage, backup, metadata, identity, and orchestration telemetry

·        Variable source attribution and destination reputation coverage

·        Variable KVM-to-AWS, KVM-to-Azure, and KVM-to-Google Cloud workload and identity correlation

·        Variable cloud data-event logging

·        Variable approved workflow baselines

·        High false-positive potential when detections are deployed without local tuning

Maturity Improvement Priorities

Priority Improvements

·        Improve Linux kernel, KVM, QEMU, libvirt, virtqemud, systemd journal, compute-agent, and infrastructure health log retention

·        Improve KVM host ID, self-managed status, compute node, compute pool, host group, nested virtualization exposure, guest, tenant, project, image, workload, exposure, and business criticality tagging

·        Improve nested virtualization inventory for x86 KVM hosts, private-cloud compute nodes, hosting-provider KVM nodes, CI KVM runners, sandbox hosts, malware-analysis hosts, and multi-tenant virtualization hosts

·        Improve VM placement, migration, evacuation, host-disablement, guest lineage, tenant lineage, image lineage, and workload lineage retention

·        Improve KVM host-fault, KVM MMU fault, shadow-paging fault, nested virtualization fault, memory-management fault, compute-node state, crash, reboot, quarantine, and evacuation normalization

·        Improve sensitive dependency mapping for storage backends, image repositories, snapshot repositories, backup systems, metadata services, identity services, orchestration APIs, migration networks, management networks, monitoring services, logging services, and tenant networks

·        Improve VM disk, snapshot, memory dump, host log, crash dump, credential path, key path, service file, kernel module, and temporary staging telemetry

·        Improve endpoint, EDR, process, command-line, parent-process, process-user, file-action, service-action, persistence, archive, transfer, credential, and outbound network telemetry for KVM compute hosts

·        Improve DNS, proxy, firewall, NDR, destination reputation, destination first-seen, domain age, ASN, geography, protocol, and egress-port normalization

·        Improve storage, backup, metadata, identity, orchestration, migration, management, monitoring, logging, and tenant-network logging

·        Improve SOAR and incident-response integration for containment and post-remediation context

·        Improve sensitive-resource inventories and virtualization dependency baselines

·        Improve KVM-to-AWS, KVM-to-Azure, and KVM-to-Google Cloud workload, identity, source, host, instance, VM, network, storage, secret, key, service account, managed identity, role, account, subscription, project, organization, folder, and resource lineage

·        Enable relevant cloud data-event logging for sensitive AWS, Azure, and Google Cloud services

·        Build approved workflow baselines for KVM administrators, nested virtualization tenants, CI runners, sandbox environments, malware-analysis workflows, monitoring, patching, kernel testing, live migration, evacuation, failover, backup, storage maintenance, vendor support, managed-service access, cloud administration, service accounts, automation, CI/CD, infrastructure-as-code, break-glass use, security tooling, and incident-response activity

·        Test detection logic against realistic benign and suspicious sequences before alert promotion

Final Intelligence Maturity Assessment

The report’s intelligence maturity is strong for behavior-led detection engineering, strong for executive risk framing, moderate to strong for telemetry-driven operational detection, moderate to strong for KVM host-fault, nested virtualization, VM placement, SIEM, endpoint, egress, storage, backup, identity, orchestration, tenant-impact, and cloud correlation, moderate for AWS, Azure, and Google Cloud downstream cloud correlation, and low to moderate for direct exploitation or attribution confirmation.

The S25 through S30 detection model is best used as an implementation-ready threat-to-detection framework that identifies KVM host-fault activity, nested virtualization exposure, high-risk guest context, VM placement lineage, post-fault sensitive dependency access, rare compute-host egress, endpoint artifact activity, repeated guest-linked instability, tenant-impact risk, and downstream cloud-impact patterns. It should not be used as a standalone proof model for KVM exploitation, KVM shadow MMU corruption, in-kernel exploit execution, guest-to-host escape, host compromise, tenant compromise, data theft, credential theft, persistence, or cloud compromise without corroborating telemetry and incident-specific validation.

S31 — Telemetry Dependencies

KVM guest-to-host escape and multi-tenant virtualization boundary compromise requires telemetry that can prove whether suspicious guest-side virtualization behavior, nested virtualization activity, host-side KVM instability, compute-node failure, host artifact access, storage access, backup access, credential exposure, control-plane interaction, outbound communication, tenant-boundary exposure, or post-remediation activity stayed within normal virtualization operations or created material compute-host trust risk. The central dependency is the ability to correlate KVM host inventory, nested virtualization exposure, guest trust classification, kernel patch and reboot state, VM placement records, tenant ownership, host kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, crash telemetry, storage logs, backup logs, identity logs, metadata logs, orchestration logs, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, change-management records, incident-response records, and remediation evidence into one guest-to-host-to-impact investigation model.

KVM Asset, Exposure, and Compute-Plane Telemetry

·        KVM asset telemetry must identify x86 KVM compute hosts, Linux KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, self-managed KVM cloud hosts, Kubernetes virtualization hosts, CI KVM runners, sandbox KVM hosts, malware-analysis virtualization hosts, developer lab hosts, production virtualization hosts, staging virtualization hosts, high-availability compute pools, and multi-tenant virtualization hosts.

·        Exposure telemetry must identify nested virtualization state, CPU virtualization exposure, kernel version, patch state, reboot state, livepatch state, host role, compute pool, tenant placement, guest trust classification, approved nested virtualization use, management-network access, storage-network access, backup access, migration-network access, metadata-service access, and orchestration dependency.

·        Required fields include host name, host ID, compute node, compute pool, virtualization platform, CPU architecture, nested virtualization state, kernel version, patch state, reboot state, livepatch state, guest ID, VM ID, tenant ID, project ID, image ID, workload ID, environment, region, business owner, platform owner, tenant owner, and remediation status where available.

·        This telemetry is required to determine whether suspicious guest-side behavior affected the correct exposure class: KVM compute hosts where untrusted or high-risk guests can exercise virtualization behavior that may affect host integrity.

·        Asset and exposure telemetry must be interpreted conservatively because unrelated Linux hosts, container hosts, Kubernetes worker nodes, cloud control-plane systems, storage appliances, VPN systems, and identity systems may not share the same guest-to-host escape behavior model.

Guest Activity, Nested Virtualization, and Workload Telemetry

·        Guest activity telemetry must capture nested hypervisor activity, nested VM creation, nested VM lifecycle changes, privileged virtualization tooling, virtualization-extension use, kernel module loading, low-level memory-management behavior, repeated VM state transitions, fuzzing activity, kernel testing, virtualization test-harness behavior, and high-risk workload execution where available.

·        Required fields include guest ID, VM ID, tenant ID, project ID, image ID, workload ID, guest owner, source user, source automation, process name where available, command line where available, kernel module event where available, nested virtualization indicator, event timestamp, compute host, compute pool, and approved workload context.

·        This telemetry is required to determine whether suspicious host-side instability was preceded by guest-side virtualization behavior or whether host instability was more likely related to maintenance, hardware failure, capacity pressure, unrelated kernel defects, storage failure, or routine platform operations.

·        Guest telemetry may be unavailable, incomplete, customer-controlled, privacy-restricted, or untrusted in multi-tenant and customer-managed environments and should be treated as high-value evidence when present, not as a guaranteed data source.

·        Guest activity telemetry must be interpreted against approved CI execution, sandbox testing, malware-analysis activity, developer lab work, kernel testing, nested virtualization validation, vulnerability validation, vendor support, and documented incident-response activity.

Host Kernel, KVM, Crash, and Fault Telemetry

·        Host kernel and KVM telemetry must capture KVM warnings, MMU fault behavior, shadow paging fault behavior, reverse-map handling issues, nested virtualization faults, unexpected role handling, invalid page state, memory corruption indicators, kernel oops events, panics, soft lockups, watchdog events, kernel crashes, unexplained host reboots, compute-node failures, service restarts, host quarantine, and host evacuation.

·        Required fields include host name, host ID, compute node, compute pool, kernel version, event timestamp, fault type, KVM fault family, crash dump reference, panic string where available, oops string where available, reboot event, service restart, affected guest ID where available, affected tenant ID where available, and maintenance context.

·        This telemetry is required to determine whether guest-side virtualization activity remained benign workload behavior or aligned with host-side boundary stress, compute-node failure, or suspected guest-to-host impact.

·        Crash and fault telemetry may be unavailable where crash dumps are disabled, logs rotate quickly, cloud providers retain host-side evidence, or automated recovery resets the host before responders preserve volatile data.

·        Host fault telemetry must be interpreted against approved patching, live migration, failover testing, host evacuation, kernel testing, driver defects, hardware failure, capacity exhaustion, storage failure, platform maintenance, and incident-response cleanup.

QEMU, Libvirt, Virtqemud, and Compute-Agent Telemetry

·        Virtualization service telemetry must capture QEMU process behavior, libvirt activity, virtqemud activity, compute-agent behavior, migration-service activity, host service restarts, VM lifecycle actions, service faults, process crashes, domain lifecycle changes, storage attachment events, image access, snapshot access, metadata interaction, and orchestration agent actions.

·        Required fields include host name, compute node, service name, process name, parent process where available, user context where available, VM ID, guest ID, tenant ID, project ID, image ID, action, status, error message, timestamp, migration state, evacuation state, and approved maintenance or automation context.

·        This telemetry is required to determine whether host-side instability or post-fault behavior affected VM lifecycle state, migration behavior, storage attachment, image access, compute-agent behavior, or orchestration service interaction.

·        Virtualization service telemetry must be interpreted against approved live migration, evacuation, host maintenance, patch validation, backup jobs, storage maintenance, monitoring, platform engineering, vendor support, and incident-response collection.

·        Service telemetry should not be used as standalone compromise proof because QEMU, libvirt, virtqemud, and compute-agent events may occur during normal workload scheduling, failover, evacuation, migration, patching, or recovery.

VM Artifact, Storage, Backup, and Sensitive Object Telemetry

·        Artifact and storage telemetry must capture access to VM disks, snapshots, memory dumps, guest configuration files, metadata files, cloud-init data, image repositories, backup repositories, libvirt artifacts, QEMU artifacts, host logs, crash dumps, diagnostic files, temporary staging paths, storage credentials, backup credentials, orchestration credentials, monitoring credentials, tenant secrets, service tokens, deployment credentials, and reusable administrative credentials.

·        Required fields include host name, host ID, compute node, file path where available, object name, object type, storage backend, backup repository, image repository, snapshot repository, action, user context where available, process context where available, source host, timestamp, tenant ID, project ID, VM ID, image ID, and approved workflow context.

·        This telemetry is required to determine whether suspected guest-to-host compromise resulted in VM artifact exposure, tenant data exposure, credential exposure, storage access, backup access, or cross-workload confidentiality risk.

·        Where object-level telemetry is absent, responders may need to rely on storage logs, backup logs, image repository logs, access-control records, file integrity monitoring, known-good host baselines, backup comparison, and incident-response artifact collection.

·        Artifact and storage telemetry must be interpreted against approved backup activity, storage maintenance, image management, migration, host evacuation, monitoring, kernel testing, CI, sandboxing, malware-analysis workflows, vendor support, and incident-response collection.

Network, DNS, Proxy, Firewall, NDR, and Egress Telemetry

·        Network telemetry must capture inbound, outbound, and east-west communication involving KVM compute hosts, virtualization hosts, management networks, storage networks, backup networks, migration networks, metadata services, identity services, orchestration services, tenant networks, monitoring systems, logging systems, and external destinations.

·        Source-enrichment telemetry should identify compute-host identity, host role, compute pool, tenant context where available, guest context where available, source interface, management-zone membership, storage-zone membership, backup-zone membership, migration-zone membership, and expected host egress behavior.

·        Outbound telemetry should identify rare destinations, newly observed domains, raw-IP communication, DNS anomalies, HTTPS callbacks, SSH, SMB, NFS, object storage, file-transfer behavior, tunneling, command-and-control-like communication, tool retrieval, repeated callbacks, and traffic inconsistent with approved update, monitoring, storage, backup, metadata, migration, orchestration, DNS, NTP, syslog, or management behavior.

·        Required fields include source host, source IP, source interface, destination domain, destination IP, destination port, protocol, timestamp, action, destination reputation, ASN, geography, first-seen status, domain age, proxy action, firewall action, and NDR behavior where available.

·        Network telemetry is required to connect suspicious KVM host instability, host artifact access, storage access, backup access, credential exposure, control-plane interaction, and infrastructure expansion into one investigation timeline.

·        Network telemetry must not be used as standalone exploit confirmation because it may lack guest activity context, host-fault context, process attribution, VM placement context, tenant ownership, artifact access, or approved maintenance context.

Control-Plane, Metadata, Identity, and Orchestration Telemetry

·        Control-plane telemetry must capture VM placement, host assignment, scheduling decisions, migration events, evacuation events, host disablement, host quarantine, compute service restarts, tenant ownership, image lineage, project ownership, metadata-service access, identity-service access, orchestration API activity, platform-administration actions, and management-network interaction.

·        Required fields include timestamp, host ID, compute node, compute pool, VM ID, guest ID, tenant ID, project ID, image ID, workload ID, actor, action, API method, migration state, host state, evacuation state, source IP, destination service, administrative identity, and approved change or maintenance record where available.

·        This telemetry is required to determine which guests and tenants were placed on affected hosts, whether host faults required evacuation or rescheduling, whether post-fault actions touched sensitive services, and whether tenant blast radius can be established.

·        Control-plane telemetry must be interpreted against approved platform operations, live migration, autoscaling, host evacuation, failover testing, maintenance, patching, storage operations, backup operations, monitoring, and incident-response cleanup.

·        Cloud control-plane logs alone are not sufficient to prove guest-to-host compromise without host-side KVM, crash, network, storage, artifact, or post-fault behavior.

Change-Control, Remediation, Incident Response, and Business-Workflow Context

·        Change-control telemetry must capture approved KVM administration, kernel patching, reboot validation, livepatch validation, nested virtualization enablement or disablement, host evacuation, live migration, compute-node quarantine, failover testing, CI execution, sandbox testing, malware-analysis activity, backup activity, storage maintenance, vendor support, emergency maintenance, and incident-response cleanup.

·        Incident-response records must capture affected host, affected kernel version, nested virtualization state, affected guest, affected tenant, affected image, affected compute pool, affected storage object, affected backup repository, affected credential material, affected control-plane service, containment action, action owner, timestamp, validation status, evidence source, decision owner, and closure rationale.

·        Business workflow context must capture approved platform administrators, approved automation accounts, approved tenant workloads, approved nested virtualization use cases, approved CI pipelines, approved sandbox use cases, approved malware-analysis workflows, approved backup jobs, approved storage maintenance windows, approved migration windows, approved patch windows, approved vendor-support workflows, and approved incident-response activities.

·        This telemetry is required to determine whether containment was complete, whether suspicious activity continued after remediation, whether tenant exposure was scoped, and whether observed behavior aligned with approved virtualization operations.

·        Remediation should not be assumed complete unless patch state, reboot completion, nested virtualization exposure, host state, VM placement, tenant ownership, host-fault evidence, artifact access, storage access, backup access, credential exposure, control-plane activity, outbound communication, and post-remediation monitoring are explicitly validated.

S32 — Detection Limitations

Detection of KVM guest-to-host escape and multi-tenant virtualization boundary compromise is limited by whether the organization can reconstruct the relationship between untrusted guest placement, nested virtualization exposure, suspicious guest-side virtualization activity, host-side KVM instability, compute-node failure, VM placement, tenant ownership, host artifact access, credential exposure, storage access, backup access, control-plane interaction, outbound communication, remediation evidence, and approved virtualization operations. Environments that rely only on vulnerable-kernel status, public proof-of-concept references, scanner findings, package versions, isolated crash strings, nested virtualization presence, guest root access, or single host reboots will not have enough evidence for high-confidence compromise or impact determination.

Primary Limitations

·        Missing KVM asset inventory may prevent identification of x86 KVM hosts, Linux KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, self-managed KVM cloud hosts, Kubernetes virtualization hosts, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, developer lab hosts, production compute hosts, staging compute hosts, business owners, platform owners, tenant owners, and exposure state.

·        Missing nested virtualization exposure inventory may prevent review of Intel or AMD nested virtualization state, compute-pool policy, approved nested virtualization use, guest trust level, customer-managed workload placement, CI workload placement, sandbox workload placement, and high-risk image placement.

·        Missing VM placement and tenant mapping may prevent reliable assessment of which guests, tenants, projects, images, workloads, compute pools, storage paths, and host groups were affected during the suspicious window.

·        Missing guest telemetry may prevent review of nested hypervisor activity, nested VM lifecycle manipulation, privileged virtualization tooling, virtualization-extension use, kernel module loading, low-level memory-management behavior, repeated VM state transitions, fuzzing activity, kernel testing, or virtualization test-harness behavior.

·        Missing host kernel, KVM, QEMU, libvirt, virtqemud, compute-agent, systemd journal, or infrastructure health logs may prevent reliable assessment of host-side KVM instability, MMU fault behavior, shadow paging fault behavior, reverse-map handling issues, kernel oops events, panics, soft lockups, watchdog events, host reboots, service restarts, host evacuation, or compute-node failure.

·        Missing crash dumps, kernel traces, or volatile evidence may prevent review of the fault sequence between suspicious guest behavior and host-side boundary stress.

·        Missing endpoint or host process telemetry may prevent review of post-fault shell activity, service manipulation, VM artifact access, credential access, file staging, archive activity, transfer-tool use, persistence-like behavior, or rare egress from compute-host context.

·        Missing storage, backup, image repository, snapshot repository, metadata, identity, and orchestration logs may prevent assessment of VM artifact access, storage access, backup access, credential exposure, metadata access, control-plane interaction, or cross-tenant exposure.

·        Missing DNS, proxy, firewall, NDR, EDR network, NetFlow, VPC flow, data-center flow, or host network telemetry may prevent assessment of rare outbound communication, suspicious destinations, raw-IP communication, file-transfer behavior, tunneling, repeated callbacks, tool retrieval, or unusual east-west access.

·        Missing change-control, maintenance, patch-validation, reboot-validation, livepatch-validation, live-migration, host-evacuation, CI, sandbox, malware-analysis, backup, storage-maintenance, vendor-support, and incident-response records may prevent reliable false-positive control.

·        Short log retention may prevent reconstruction of the period between guest-side virtualization behavior, host-side KVM instability, compute-node recovery, VM artifact access, storage access, backup access, outbound communication, patching, reboot validation, containment, and post-remediation monitoring.

·        Poor timestamp normalization can break sequence logic between guest activity, host logs, KVM faults, crash telemetry, VM placement records, control-plane actions, storage access, backup access, network events, change-management records, and remediation evidence.

·        Incomplete host, guest, tenant, VM, image, workload, compute pool, storage object, backup repository, credential object, destination, administrative identity, and business-owner normalization can prevent reliable correlation across virtualization, network, storage, control-plane, and incident-response telemetry.

Detection Boundary

·        A vulnerable kernel, public proof-of-concept reference, scanner finding, nested virtualization setting, guest root condition, KVM warning, host reboot, kernel panic, oops event, soft lockup, watchdog event, or compute-node failure is not proof of compromise by itself.

·        Suspicious guest-side virtualization behavior should not be treated as successful guest-to-host escape without host-side KVM instability, host fault evidence, compute-node impact, host artifact access, storage access, backup access, credential exposure, control-plane interaction, outbound communication, tenant-boundary exposure, or active exploitation intelligence.

·        Host instability should not be attributed to guest-to-host exploitation unless tied to guest, tenant, image, workload, nested virtualization state, KVM fault pattern, VM placement, host context, maintenance context, or bounded time-window evidence.

·        Host artifact access, VM disk access, snapshot access, memory artifact access, metadata access, credential access, storage access, backup access, outbound communication, or control-plane activity should not be attributed to KVM compromise without host, guest, tenant, process, object, destination, or time-window linkage.

·        Cloud-only anomalies, identity-only anomalies, storage-only anomalies, backup-only anomalies, network-only anomalies, control-plane-only anomalies, or tenant-only anomalies should not be treated as KVM guest-to-host compromise without guest-layer, host-layer, placement-layer, fault-layer, artifact-layer, or post-fault correlation.

·        Legitimate KVM administration, kernel patching, reboot validation, live migration, host evacuation, failover testing, CI execution, sandbox testing, malware-analysis workflows, backup activity, storage maintenance, vendor support, monitoring, emergency remediation, and incident-response cleanup can create overlapping signals.

·        Detection logic must not rely on prior alert state, another rule’s output, analyst judgment after alert generation, DRI, or TCR as an input.

·        High-confidence alerting should require validated multi-signal correlation across guest activity, host-side KVM instability, VM placement, tenant ownership, crash evidence, compute-node recovery, host artifact access, storage access, backup access, credential exposure, control-plane interaction, outbound communication, remediation evidence, and approved workflow context where applicable.

Operational Impact of Limitations

Detection coverage should be reduced, scoped down, converted to hunt-only logic, or withheld when required telemetry is unavailable, incomplete, delayed, sampled, inconsistently normalized, or unable to support bounded sequence correlation. Suspicious KVM instability may be analytically important but unsuitable for high-confidence alerting if the organization cannot validate guest origin, nested virtualization state, host-fault sequence, VM placement, tenant ownership, post-fault host behavior, storage access, backup access, credential exposure, control-plane activity, outbound communication, remediation status, and approved virtualization workflow evidence within locally validated correlation windows.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making KVM asset exposure, nested virtualization governance, guest trust classification, patch and reboot state, host-fault evidence, VM placement, tenant ownership, artifact access, storage access, backup access, credential exposure, control-plane activity, outbound communication, post-remediation monitoring, and tenant blast-radius assessment measurable, governed, and resilient under active virtualization boundary pressure. The objective is not only to patch one kernel version, disable one nested virtualization setting, or suppress one crash pattern, but to prove that KVM activity can be scoped, correlated, contained, and separated from legitimate virtualization operations when compute-host trust exposure is suspected.

KVM Asset, Exposure, and Nested Virtualization Governance

·        Maintain a complete inventory of x86 KVM compute hosts, Linux KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, self-managed KVM cloud hosts, Kubernetes virtualization hosts, CI KVM runners, sandbox KVM hosts, malware-analysis virtualization hosts, developer lab hosts, production virtualization hosts, staging virtualization hosts, high-availability compute pools, multi-tenant compute pools, business owners, platform owners, tenant owners, and remediation status.

·        Maintain a complete inventory of nested virtualization exposure, CPU virtualization settings, compute-pool policy, approved nested virtualization hosts, approved tenants, approved images, approved CI pipelines, approved labs, approved sandbox environments, approved malware-analysis environments, and documented business requirements.

·        Prioritize remediation for KVM hosts supporting multi-tenant workloads, regulated workloads, customer-managed tenants, partner workloads, CI execution, sandboxed analysis, malware detonation, shared storage, backup repositories, identity services, orchestration systems, management networks, and high-availability business services.

·        Require auditable change-control for KVM patching, reboot validation, livepatch validation, nested virtualization enablement or disablement, workload placement changes, host evacuation, live migration, compute-node quarantine, storage mapping changes, backup mapping changes, credential rotation, and incident-response cleanup.

·        Treat unknown KVM ownership, unknown nested virtualization state, unknown guest trust classification, unknown patch or reboot state, unknown VM placement, unknown tenant ownership, or unknown storage and backup dependency as compute trust risk until exposure is resolved.

Nested Virtualization Restriction and Workload Placement Hardening

·        Restrict nested virtualization to approved hosts, approved tenants, approved images, approved CI pipelines, approved labs, approved sandbox systems, approved malware-analysis workflows, and documented business requirements where operationally feasible.

·        Disable nested virtualization for untrusted, customer-managed, externally provisioned, partner-managed, sandboxed, malware-analysis, or high-risk guests where there is no approved business requirement.

·        Separate high-risk guest workloads from sensitive tenants, regulated workloads, shared storage dependencies, backup repositories, identity integrations, orchestration services, management networks, and high-availability business workloads where operationally feasible.

·        Baseline approved nested virtualization users, workloads, guest images, CI pipelines, sandbox environments, malware-analysis systems, kernel-testing workflows, platform engineering workflows, and maintenance windows.

·        Treat unexpected nested virtualization activity, guest-side privileged virtualization behavior, or repeated low-level virtualization behavior as high-priority investigation context when followed by KVM host instability, compute-node failure, VM artifact access, storage access, credential exposure, control-plane interaction, rare egress, or tenant-boundary concern.

Patch, Reboot, Livepatch, and Host-State Hardening

·        Validate kernel patch state, reboot completion, livepatch effectiveness, mitigation state, vulnerable-host inventory, compute-pool exposure, and host return-to-service status across affected KVM environments.

·        Do not treat package installation as remediation unless the host has rebooted into the fixed kernel or livepatch effectiveness has been validated with kernel-specific evidence.

·        Require host-fault preservation before routine cleanup, rebuild, log rotation, evacuation, or return-to-service activity when guest-to-host exposure cannot be ruled out.

·        Maintain known-good host baselines for kernel version, KVM modules, QEMU packages, libvirt services, virtqemud services, compute agents, storage agents, backup agents, monitoring agents, orchestration agents, host users, SSH keys, systemd units, cron entries, firewall rules, bridge interfaces, tap devices, storage mounts, migration settings, and management access.

·        Treat unexplained host configuration drift, repeated service restarts, crash artifact deletion, log deletion, unusual host reboots, unexpected package changes, or repeated compute-node instability after suspicious guest activity as high-priority investigation context.

Host Artifact, Credential, Storage, and Backup Hardening

·        Protect and monitor VM disks, snapshots, memory dumps, guest configuration files, metadata files, cloud-init data, image repositories, backup repositories, libvirt artifacts, QEMU artifacts, host logs, crash dumps, temporary staging paths, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, deployment credentials, and reusable administrative credentials.

·        Restrict access to VM artifacts, image repositories, snapshot repositories, backup repositories, storage credentials, orchestration credentials, monitoring credentials, metadata credentials, cloud-init data, and host crash artifacts to approved users, approved services, approved workflows, and approved maintenance windows.

·        Require credential and token review or rotation when suspicious KVM instability aligns with host artifact access, storage access, backup access, metadata access, orchestration activity, rare egress, tenant-boundary uncertainty, or incomplete containment.

·        Monitor access to VM disks, snapshots, memory artifacts, metadata paths, cloud-init data, image repositories, backup repositories, host logs, crash dumps, credential-bearing files, storage paths, and orchestration files after suspicious host instability.

·        Treat VM artifact access, storage access, backup access, metadata access, credential exposure, or cross-tenant object access as scope-expansion conditions affecting tenant trust and business continuity.

Network, Control-Plane, and Tenant-Boundary Hardening

·        Enrich DNS, proxy, firewall, NDR, EDR network, flow, control-plane, storage, backup, identity, metadata, orchestration, and incident-response telemetry with KVM host identity, compute pool, nested virtualization state, guest ID, tenant ID, project ID, image ID, workload ID, host-fault context, storage object, backup repository, destination context, business owner, platform owner, tenant owner, and approved-workflow status.

·        Monitor rare outbound destinations, raw-IP communication, object storage access, SSH, SMB, NFS, newly observed domains, low-reputation infrastructure, unusual ports, unexpected protocols, repeated callbacks, tenant-network access, management-network access, metadata access, identity access, storage access, backup access, and orchestration activity after suspicious KVM instability.

·        Review control-plane activity for host disablement, evacuation, live migration, failed migration, emergency maintenance, VM rescheduling, storage attachment, image access, snapshot access, metadata access, and administrative actions after suspicious guest-side virtualization behavior.

·        Review tenant and workload impact where affected hosts supported multi-tenant workloads, regulated workloads, customer-managed guests, partner workloads, CI execution, sandboxed analysis, malware detonation, shared storage, backup repositories, or high-availability business services.

·        Treat network, control-plane, and tenant telemetry as supporting context rather than standalone proof of guest-to-host escape, host compromise, credential exposure, tenant exposure, or containment failure.

Incident Response and Containment Hardening

·        Create response procedures for suspicious guest-side virtualization behavior, nested virtualization exposure, KVM host instability, compute-node failure, host evacuation, VM placement anomalies, host artifact access, credential exposure, storage access, backup access, control-plane interaction, rare outbound communication, tenant-boundary uncertainty, and post-remediation activity.

·        Require responders to validate affected host, affected kernel version, nested virtualization state, affected guest, affected tenant, affected image, affected compute pool, host-fault evidence, crash evidence, VM placement, storage access, backup access, credential exposure, control-plane activity, outbound communication, business owner, tenant sensitivity, data sensitivity, and remediation status.

·        Prepare decision paths for emergency patching, reboot validation, livepatch validation, nested virtualization disablement, compute-host quarantine, workload evacuation, host rebuild, storage review, backup validation, credential rotation, control-plane review, tenant impact assessment, vendor escalation, legal and compliance escalation, cyber-insurance coordination, communications planning, executive reporting, and customer or partner trust management.

·        Treat suspected KVM host compromise or cross-tenant exposure as a compute trust, tenant-separation, storage exposure, credential exposure, control-plane resilience, and containment-validation incident, not a routine host crash, isolated kernel warning, single vulnerable-kernel finding, or patch-management task.

·        Require post-event validation to distinguish approved KVM administration, kernel patching, live migration, host evacuation, failover testing, CI execution, sandbox testing, malware-analysis workflows, backup activity, storage maintenance, vendor support, monitoring, emergency remediation, and incident-response cleanup from attacker-driven behavior.

S34 — Defensive Control & Hardening Architecture

Figure 6

KVM guest-to-host escape and multi-tenant virtualization boundary compromise defensive architecture showing KVM asset governance, nested virtualization restriction, host-fault visibility, VM placement reconstruction, artifact and credential protection, storage and backup access review, control-plane correlation, tenant-boundary validation, SOC triage, and executive compute-trust restoration.

The defensive architecture should treat KVM hosts, compute pools, nested virtualization exposure, VM placement, storage dependencies, backup paths, identity integrations, orchestration services, management networks, and tenant boundaries as governed compute trust infrastructure rather than isolated Linux hosts or routine patch-management assets. The architecture must connect KVM asset inventory, nested virtualization governance, guest trust classification, host-fault telemetry, virtualization service telemetry, VM placement reconstruction, artifact protection, storage and backup visibility, control-plane correlation, tenant impact review, incident-response containment, and executive trust decisioning into one guest-to-host-to-impact assurance model.

Architecture Layer One — KVM Asset and Exposure Governance

KVM asset and exposure governance establishes which KVM compute hosts exist, which hosts support nested virtualization, which hosts run untrusted or high-risk guests, which compute pools support sensitive tenants, which storage and backup dependencies are attached, which control-plane services depend on each host, and which business workflows require protection. This layer captures host identity, compute pool, platform family, kernel version, patch state, reboot state, livepatch state, nested virtualization state, guest trust class, VM placement, tenant ownership, environment, region, business owner, platform owner, tenant owner, and remediation status.

Architecture Layer Two — Nested Virtualization and Workload Placement Control

Nested virtualization and workload placement control determines whether high-risk guest workloads can exercise virtualization behavior on sensitive hosts. This layer captures approved nested virtualization use cases, approved tenants, approved images, approved CI pipelines, approved sandbox environments, approved malware-analysis workflows, compute-pool restrictions, workload placement policy, tenant separation requirements, and exceptions that allow nested virtualization on production or multi-tenant compute infrastructure.

Architecture Layer Three — Guest Activity and Host-Fault Visibility

Guest activity and host-fault visibility determines whether suspicious guest-side virtualization behavior remained routine workload activity or aligned with host-side KVM instability. This layer captures guest-side nested hypervisor activity where available, nested VM lifecycle behavior, privileged virtualization tooling, low-level memory-management behavior, KVM warnings, MMU fault behavior, shadow paging fault behavior, reverse-map handling issues, kernel oops events, panics, soft lockups, watchdog events, crash dumps, unexplained reboots, compute-node failures, host quarantine, and host evacuation.

Architecture Layer Four — Virtualization Service and Compute-Agent Monitoring

Virtualization service and compute-agent monitoring determines whether KVM instability affected VM lifecycle state, host services, compute agents, migration behavior, storage attachment, or orchestration activity. This layer captures QEMU activity, libvirt activity, virtqemud activity, compute-agent logs, migration-service activity, host service restarts, VM lifecycle events, domain state changes, failed migrations, live migrations, evacuation actions, storage attachment events, image access, snapshot access, and compute-node recovery.

Architecture Layer Five — VM Artifact, Credential, Storage, and Backup Protection

VM artifact, credential, storage, and backup protection determines whether suspected host compromise affected tenant artifacts or privileged infrastructure material. This layer captures VM disks, snapshots, memory artifacts, guest configuration files, metadata files, cloud-init data, image repositories, backup repositories, libvirt artifacts, QEMU artifacts, host logs, crash dumps, temporary staging paths, SSH keys, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, deployment credentials, and access-control context.

Architecture Layer Six — Network Egress and Internal Service Monitoring

Network egress and internal service monitoring determines whether the KVM compute host became a callback source, staging point, lateral movement path, tenant-boundary bridge, or path into sensitive infrastructure services. This layer captures DNS queries, proxy events, firewall events, NDR metadata, outbound HTTPS, SSH, SMB, NFS, object storage, raw-IP communication, file-transfer behavior, tunneling, repeated callbacks, tool retrieval, identity service access, metadata service access, storage access, backup access, orchestration access, management-network access, tenant-network access, destination reputation, first-seen destination context, and approved compute-host egress baselines.

Architecture Layer Seven — Control-Plane, Placement, and Tenant Blast-Radius Review

Control-plane, placement, and tenant blast-radius review determines which guests, tenants, workloads, images, projects, compute pools, storage objects, backup repositories, and management services were exposed during the suspicious window. This layer captures VM placement history, tenant ownership, project ownership, image lineage, scheduling decisions, live migration events, host assignment history, compute-pool membership, host disablement, host quarantine, evacuation records, metadata access, identity access, orchestration API activity, and platform-owner validation.

Architecture Layer Eight — SOC Correlation and False-Positive Control

SOC correlation joins KVM asset context, nested virtualization exposure, guest trust classification, guest activity, host-fault telemetry, virtualization service telemetry, VM placement, tenant ownership, artifact access, storage access, backup access, credential context, network behavior, control-plane activity, change-control records, patch-validation records, live-migration records, CI records, sandbox records, malware-analysis records, vendor-support records, incident-response records, and business workflow baselines. This layer validates whether activity is attacker-driven, tenant-driven, scanner-driven, administrator-driven, platform-engineering-driven, CI-driven, sandbox-driven, malware-analysis-driven, vendor-support-driven, maintenance-related, recovery-related, or incident-response-related.

Architecture Layer Nine — Incident Response and Executive Compute-Trust Workflow

Incident response and executive compute-trust workflow connects technical validation to business decisions. This layer captures incident severity, affected hosts, affected kernel versions, affected guests, affected tenants, affected images, affected compute pools, affected storage objects, affected backup repositories, affected credentials, affected control-plane services, containment actions, patch validation, reboot validation, nested virtualization restriction, host quarantine, workload evacuation, host rebuild, credential rotation, storage and backup validation, tenant impact assessment, legal review, compliance review, cyber-insurance coordination, communications planning, executive reporting, board-level assurance, and validation that affected compute infrastructure can safely return to service.

Architecture Outcome

The architecture should enable the organization to answer seven questions during a KVM guest-to-host escape and virtualization boundary incident:

·        Which KVM host, guest, tenant, image, workload, compute pool, storage object, backup repository, credential source, control-plane service, management network, destination, business owner, platform owner, tenant owner, or remediation action was affected?

·        Did the activity align with approved KVM administrators, platform automation, CI pipelines, sandbox activity, malware-analysis workflows, kernel testing, live migration, host evacuation, patch validation, backup jobs, storage maintenance, vendor support, maintenance windows, emergency changes, or incident-response activity?

·        Did suspicious guest-side virtualization behavior transition into host-side KVM instability, compute-node failure, host artifact access, storage access, backup access, credential exposure, control-plane interaction, rare egress, tenant-boundary exposure, or post-remediation activity?

·        Did the activity affect multi-tenant workloads, regulated workloads, customer-managed guests, partner workloads, shared storage, backup repositories, identity services, orchestration services, management networks, high-availability compute pools, or business-critical services?

·        Can the organization patch and reboot affected hosts, disable or restrict nested virtualization, quarantine compute nodes, preserve host-fault evidence, reconstruct VM placement, validate tenant ownership, review storage and backup access, rotate credentials, and restore compute availability without over-attributing unrelated virtualization administration or recovery activity to exploitation?

·        Can the organization prove that guest activity, host-fault behavior, VM placement, artifact access, storage access, backup access, network behavior, control-plane activity, and post-remediation behavior were approved operational activity rather than suspicious follow-on behavior?

·        Can leadership make defensible decisions about host integrity, tenant exposure, credential exposure, storage and backup trust, control-plane resilience, customer or partner impact, regulatory review, cyber-insurance coordination, notification analysis, and compute-trust restoration?

S35 — Defensive Control Mapping Matrix

Preventive Controls

·        Maintain complete inventory of x86 KVM compute hosts, Linux KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, self-managed KVM cloud hosts, Kubernetes virtualization hosts, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, developer lab hosts, production hosts, staging hosts, compute pools, tenant owners, platform owners, business owners, kernel versions, patch state, reboot state, nested virtualization state, storage dependencies, backup dependencies, identity dependencies, orchestration dependencies, and management-network access.

·        Enforce timely kernel patching, reboot validation, livepatch validation, nested virtualization restriction, untrusted guest placement controls, compute-pool segmentation, high-risk workload isolation, tenant placement governance, storage access restriction, backup access restriction, privileged access workflows, role-based administration, MFA where supported, vendor-support restrictions, and change-control validation.

·        Restrict nested virtualization, privileged virtualization tooling, host administrative access, storage access, backup access, image repository access, snapshot repository access, metadata access, orchestration access, migration access, monitoring access, and management-network access to approved users, approved services, approved workflows, approved hosts, approved tenants, approved images, and monitored maintenance windows.

·        Harden QEMU, libvirt, virtqemud, compute-agent, storage-agent, backup-agent, monitoring-agent, orchestration-agent, migration-service, metadata-service, host networking, bridge interfaces, tap devices, firewall rules, storage mounts, kernel modules, service files, SSH keys, systemd units, cron entries, and management access restrictions.

·        Maintain allowlists for approved KVM administrators, platform automation, CI pipelines, sandbox environments, malware-analysis workflows, kernel-testing systems, backup jobs, storage maintenance systems, migration workflows, monitoring systems, vendor support sources, incident-response systems, approved egress destinations, and business-required compute-host communication.

·        Prioritize preventive controls for KVM environments supporting multi-tenant workloads, regulated workloads, customer-managed tenants, partner workloads, CI execution, sandboxed analysis, malware detonation, shared storage, backup repositories, identity services, orchestration systems, management networks, and high-availability business services.

Detective Controls

·        Monitor nested virtualization enabled on x86 KVM hosts that run untrusted, tenant-controlled, customer-managed, externally provisioned, partner-managed, CI-controlled, sandboxed, malware-analysis, or high-risk guest workloads.

·        Monitor guest-side nested virtualization activity, nested VM creation, nested VM lifecycle changes, privileged virtualization tooling, virtualization-extension use, kernel module loading, low-level memory-management behavior, repeated VM state transitions, fuzzing activity, kernel testing, and virtualization test-harness behavior where available.

·        Monitor KVM host kernel warnings, MMU fault patterns, shadow paging fault behavior, reverse-map handling issues, nested virtualization faults, unexpected role handling, invalid page state, memory corruption indicators, kernel oops events, panics, soft lockups, watchdog events, kernel crashes, unexplained reboots, compute-node failures, service restarts, host quarantine, and host evacuation.

·        Monitor repeated host faults associated with the same guest, tenant, image, workload family, compute pool, automation pattern, nested virtualization workload, or scheduling placement.

·        Monitor QEMU, libvirt, virtqemud, compute-agent, storage-agent, backup-agent, monitoring-agent, orchestration-agent, migration-service, and metadata-service behavior after suspicious host instability.

·        Monitor access to VM disks, snapshots, memory artifacts, guest configuration files, metadata files, cloud-init data, image repositories, backup archives, libvirt artifacts, QEMU artifacts, host logs, crash dumps, SSH keys, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, deployment credentials, and temporary staging paths.

·        Monitor DNS, proxy, firewall, EDR network, NDR, and flow telemetry for rare destinations, raw-IP communication, object storage access, file-transfer behavior, tunneling, SSH, SMB, NFS, newly observed domains, low-reputation infrastructure, repeated callbacks, management-network access, tenant-network access, storage access, backup access, metadata access, and orchestration access after suspicious KVM instability.

·        Monitor control-plane logs for host evacuation, live migration, failed migration, host disablement, compute service restart, emergency maintenance, workload rescheduling, VM placement changes, storage attachment, image access, snapshot access, metadata access, and administrative actions after suspicious KVM faults.

·        Monitor post-remediation activity involving recurring host instability, rare egress, unexplained configuration drift, storage access, backup access, credential use, control-plane activity, deleted logs, missing crash artifacts, VM placement anomalies, or tenant-boundary uncertainty.

·        Require multi-signal guest-to-host, host-to-artifact, host-to-storage, host-to-control-plane, host-to-network, or host-to-tenant correlation before high-confidence alerting or compromise determination.

Responsive Controls

·        Patch affected KVM hosts, validate reboot completion, validate livepatch effectiveness where applicable, restrict nested virtualization, isolate high-risk workloads, quarantine affected compute nodes, evacuate workloads carefully, and validate affected host state.

·        Preserve host kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, systemd journals, crash dumps, host health records, VM placement records, tenant ownership records, storage logs, backup logs, identity logs, metadata logs, orchestration logs, firewall logs, DNS logs, proxy logs, NDR telemetry, endpoint telemetry where available, change-management records, incident-response records, and remediation evidence before log rotation or cleanup.

·        Reconstruct VM placement, guest ownership, tenant ownership, image lineage, compute-pool membership, migration history, host assignment history, host evacuation actions, and suspicious host-fault windows.

·        Inspect VM disks, snapshots, memory artifacts, guest configuration files, metadata files, cloud-init data, libvirt artifacts, QEMU artifacts, host logs, crash dumps, image repositories, backup repositories, temporary staging paths, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, and deployment credentials.

·        Rotate compute-host credentials, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant-exposed credentials, SSH keys, API tokens, service accounts, vendor support credentials, deployment secrets, and reused credentials when compromise cannot be ruled out.

·        Review outbound communication, rare destinations, callbacks, tool retrieval, internal service access, DNS queries, proxy actions, firewall actions, NDR behaviors, and egress that deviates from approved KVM compute-host behavior.

·        Review control-plane, metadata, identity, storage, backup, orchestration, migration, monitoring, management-network, tenant-network, and sibling compute activity after suspicious KVM instability.

·        Perform legal and compliance review, cyber-insurance coordination, communications planning, customer or partner notification analysis, executive reporting, and board-level compute-trust assurance where cross-tenant exposure, regulated workload impact, credential exposure, storage or backup access, management-plane compromise, service disruption, or incomplete containment is suspected.

·        Confirm that guest activity, host state, KVM fault evidence, VM placement, tenant ownership, artifact access, storage access, backup access, credential exposure, outbound communication, control-plane behavior, and post-remediation monitoring support closure before the incident is considered contained.

Governance Controls

·        Maintain approved inventories for KVM compute hosts, nested virtualization exposure, guest trust classification, tenant ownership, VM placement, image lineage, compute pools, storage dependencies, backup repositories, identity dependencies, orchestration dependencies, management networks, administrators, automation accounts, CI pipelines, sandbox environments, malware-analysis workflows, vendor support sources, business owners, platform owners, and tenant owners.

·        Maintain approved workflows for KVM administration, kernel patching, reboot validation, livepatch validation, nested virtualization enablement or disablement, workload placement, live migration, host evacuation, failover testing, backup operations, storage maintenance, monitoring, kernel testing, CI execution, sandbox testing, malware-analysis activity, vendor support, emergency maintenance, incident-response cleanup, credential rotation, storage validation, and tenant impact review.

·        Require change-control records for KVM patching, nested virtualization changes, compute-pool changes, workload placement changes, host evacuation, live migration, storage access changes, backup access changes, image repository access, snapshot repository access, metadata service changes, orchestration changes, management-network changes, credential rotation, vendor support activity, and emergency remediation.

·        Maintain escalation criteria for suspicious nested virtualization activity, guest-side privileged virtualization behavior, KVM host instability, compute-node failure, repeated tenant-linked faults, host artifact access, storage access, backup access, credential exposure, control-plane activity, outbound communication, tenant-boundary uncertainty, post-remediation activity, and unresolved exposure.

·        Track KVM guest-to-host escape and compute trust risk in the risk register when telemetry, patching, reboot validation, nested virtualization governance, VM placement visibility, tenant mapping, storage visibility, backup visibility, outbound monitoring, control-plane correlation, or response gaps create unresolved enterprise risk.

Control Mapping Summary

The strongest control posture combines prevention of unnecessary nested virtualization exposure, detection of suspicious guest-to-host and post-fault host behavior, and response workflows that restore compute-host trust, tenant separation, storage confidence, backup integrity, credential protection, control-plane assurance, and business continuity. Controls should be prioritized for KVM environments supporting multi-tenant workloads, regulated workloads, customer-managed tenants, partner workloads, CI execution, sandboxed analysis, malware detonation, shared storage, backup repositories, identity services, orchestration systems, management networks, high-availability compute pools, and business-critical services.

S36 — CyberDax Intelligence Maturity Assessment

Current Intelligence Maturity

Moderate

Maturity Rationale

KVM guest-to-host escape and multi-tenant virtualization boundary compromise is a well-defined behavior class, but organization-specific maturity depends on whether suspicious guest-side virtualization behavior, nested virtualization exposure, host-side KVM instability, compute-node failure, VM placement, tenant ownership, host artifact access, storage access, backup access, credential exposure, control-plane interaction, outbound communication, post-remediation activity, and approved virtualization operations can be correlated. Many environments can identify vulnerable kernels, nested virtualization settings, host crashes, or compute-node failures, but fewer can prove whether suspicious guest activity resulted in host compromise, VM artifact exposure, tenant-boundary exposure, storage or backup access, credential exposure, control-plane interaction, or containment failure.

Strengths

·        The behavior pattern is durable because it focuses on guest-to-host and compute trust tradecraft rather than one CVE name, scanner fingerprint, actor name, exploit string, crash string, package version, vulnerable-kernel finding, proof-of-concept reference, or static IOC.

·        The core sequence is analytically clear: exposure identification, guest-to-host escape attempt, host instability and boundary stress, host access and artifact exposure, infrastructure expansion, and post-remediation trust validation.

·        Detection opportunities are strong where KVM asset inventory, nested virtualization exposure mapping, guest trust classification, host kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, VM placement records, tenant ownership, crash telemetry, storage logs, backup logs, identity logs, metadata logs, orchestration logs, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, change-control records, and business context can be correlated.

·        Defensive controls can be mapped directly to KVM asset governance, nested virtualization restriction, patch and reboot validation, host-fault visibility, VM placement reconstruction, artifact protection, storage and backup visibility, control-plane correlation, tenant-boundary review, SOC triage, and incident-response containment.

·        Blocks 2, 3, 4, and 5 remain aligned while preserving a behavior-led model and avoiding actor-only, scanner-only, IOC-only, crash-only, vulnerable-version-only, proof-of-concept-only, product-only, or single-CVE-only overreach.

Maturity Gaps

·        KVM asset inventory may not reliably identify x86 KVM hosts, Linux KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, self-managed KVM cloud hosts, Kubernetes virtualization hosts, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, developer lab hosts, production hosts, staging hosts, business owners, platform owners, tenant owners, or exposure state.

·        Nested virtualization exposure mapping may not reliably identify Intel or AMD nested virtualization state, compute-pool policy, approved nested virtualization use, guest trust level, customer-managed workload placement, CI workload placement, sandbox workload placement, malware-analysis workload placement, or high-risk image placement.

·        Guest telemetry may not preserve sufficient nested hypervisor activity, nested VM lifecycle behavior, privileged virtualization tooling, virtualization-extension use, kernel module activity, low-level memory-management behavior, repeated VM state transitions, fuzzing activity, kernel testing, or virtualization test-harness context.

·        Host kernel, KVM, QEMU, libvirt, virtqemud, compute-agent, systemd journal, infrastructure health, and crash telemetry may not preserve enough fault, sequence, process, service, reboot, evacuation, or host-quarantine detail for complete reconstruction.

·        VM placement and tenant mapping may not preserve sufficient guest ID, tenant ID, project ID, image ID, workload ID, compute node, compute pool, migration state, host assignment history, evacuation history, or owner context.

·        Endpoint or host process telemetry may not preserve sufficient shell activity, service-control activity, file access, archive behavior, transfer behavior, credential access, artifact access, persistence-like behavior, or rare egress from compute-host context.

·        Storage, backup, image repository, snapshot repository, metadata, identity, orchestration, monitoring, and logging telemetry may not preserve enough context to prove post-escape activity or tenant-boundary exposure.

·        DNS, proxy, firewall, NDR, EDR network, and flow telemetry may not reliably connect outbound behavior to the affected KVM host, compute pool, guest, tenant, source interface, process context, or host-fault window.

·        Help desk, incident-response, SOAR, vulnerability-management, vendor-support, change-control, and remediation records may not consistently document patch validation, reboot completion, livepatch validation, nested virtualization restriction, host quarantine, workload evacuation, credential rotation, storage review, backup review, tenant impact assessment, or post-remediation validation.

·        Business workflow baselines for KVM administrators, platform automation, CI pipelines, sandbox activity, malware-analysis workflows, kernel testing, live migration, host evacuation, backup activity, storage maintenance, vendor support, emergency remediation, and incident-response cleanup may be insufficient for false-positive control.

·        Organizations may over-rely on patch status, package version, vulnerable-kernel names, public exploit reporting, nested virtualization presence, host crashes, or scanner findings rather than validating the full guest-to-host-to-impact sequence.

Maturity Improvement Priorities

·        Normalize KVM asset inventory, nested virtualization exposure, guest trust classification, kernel version, patch state, reboot state, livepatch state, VM placement, tenant ownership, image lineage, compute-pool membership, storage dependency, backup dependency, identity dependency, orchestration dependency, management-network dependency, business ownership, platform ownership, and tenant sensitivity.

·        Improve guest activity logging where available, including nested virtualization activity, nested VM lifecycle events, privileged virtualization tooling, virtualization-extension use, kernel module activity, low-level memory-management behavior, repeated VM state transitions, CI execution context, sandbox context, malware-analysis context, and kernel-testing context.

·        Improve host kernel telemetry, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, crash dump retention, kernel trace retention, systemd journal retention, service restart visibility, host evacuation records, compute-node failure records, host quarantine records, and timestamp normalization.

·        Improve VM placement records, tenant ownership records, image lineage, workload mapping, migration history, host assignment history, compute-pool mapping, scheduling records, evacuation records, and blast-radius reconstruction workflows.

·        Improve artifact visibility, storage logs, backup logs, image repository logs, snapshot repository logs, metadata-service logs, identity logs, orchestration logs, monitoring logs, logging-system records, credential-bearing file monitoring, and sensitive path mapping.

·        Improve DNS, proxy, firewall, NDR, EDR network, flow, data-center network, VPC flow, management-network, storage-network, backup-network, migration-network, tenant-network, and orchestration-service correlation.

·        Improve remediation evidence capture for KVM patch validation, reboot completion, livepatch validation, nested virtualization restriction, host quarantine, workload evacuation, host rebuild, VM placement reconstruction, storage review, backup review, credential rotation, control-plane review, tenant impact assessment, vendor escalation, and post-remediation monitoring.

·        Improve baselines for KVM administration, patching, reboot validation, live migration, host evacuation, kernel testing, CI execution, sandboxing, malware-analysis workflows, backup operations, storage maintenance, monitoring, vendor support, emergency remediation, incident-response cleanup, and approved outbound destinations.

·        Add KVM guest-to-host escape validation steps to SOC, platform engineering, infrastructure, vulnerability management, incident response, legal, compliance, privacy, cyber-insurance, communications, business-continuity, customer-impact, partner-impact, tenant-impact, and executive reporting workflows.

Maturity Outlook

Maturity can improve quickly if the organization prioritizes KVM asset inventory completeness, nested virtualization exposure mapping, guest trust classification, patch and reboot validation, host-fault telemetry, crash dump retention, VM placement history, tenant ownership mapping, storage and backup visibility, credential exposure review, control-plane correlation, outbound monitoring, platform workflow baselining, change-control completeness, and SOC workflows that connect guest behavior to host-fault, artifact, storage, backup, control-plane, network, tenant, and post-remediation evidence. The highest-value improvements are nested virtualization governance, KVM host ownership, patch and reboot validation, VM placement reconstruction, tenant mapping, storage and backup dependency mapping, credential rotation readiness, management-network visibility, post-fault containment correlation, and executive compute-trust assurance.

S37 — Strategic Defensive Improvements

Strategic improvement should reduce the likelihood that attackers can use untrusted guest placement, nested virtualization exposure, weak compute-pool governance, host-side KVM fault behavior, incomplete patch and reboot validation, VM artifact access, storage access, backup access, credential exposure, control-plane trust, outbound communication, or tenant-boundary uncertainty to create compute-trust, tenant-separation, containment, or business-continuity uncertainty without detection. The objective is measurable KVM guest-to-host resilience and virtualization trust governance, not patch response alone.

Priority One — Establish Compute Trust and Tenant Separation as Security Metrics

·        Define measurable assurance metrics for KVM asset inventory completeness, nested virtualization exposure mapping, guest trust classification, kernel patch state, reboot validation, livepatch validation, VM placement history, tenant ownership mapping, host-fault telemetry coverage, crash dump retention, storage dependency mapping, backup dependency mapping, credential exposure visibility, outbound monitoring, control-plane correlation, tenant impact review, and post-remediation monitoring.

·        Track resilience completeness for KVM environments supporting multi-tenant workloads, regulated workloads, customer-managed tenants, partner workloads, CI execution, sandboxed analysis, malware detonation, shared storage, backup repositories, identity services, orchestration systems, management networks, and high-availability business services.

·        Report unresolved nested virtualization exposure, unknown guest trust classification, unknown patch or reboot state, weak VM placement visibility, incomplete tenant mapping, weak host-fault telemetry, weak crash retention, weak storage attribution, weak backup attribution, incomplete control-plane records, weak outbound monitoring, and post-remediation uncertainty as enterprise risk.

·        Treat unexplained guest-side virtualization behavior, KVM host instability, compute-node failure, VM artifact access, storage access, backup access, credential exposure, control-plane interaction, rare egress, tenant-boundary uncertainty, or post-remediation activity affecting high-value compute infrastructure as executive-relevant trust issues.

Priority Two — Harden KVM Exposure, Nested Virtualization, and Workload Placement Governance

·        Maintain live inventory of x86 KVM hosts, Linux KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, self-managed KVM cloud hosts, Kubernetes virtualization hosts, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, developer lab hosts, public exposure state, nested virtualization state, compute pools, guest trust classifications, tenant owners, platform owners, business owners, storage dependencies, backup dependencies, identity dependencies, orchestration dependencies, and management-network dependencies.

·        Enforce emergency kernel remediation, reboot validation, livepatch validation, nested virtualization restriction, high-risk workload isolation, compute-pool segmentation, placement governance, privileged access workflows, role-based administration, MFA where supported, vendor-support restrictions, platform-automation restrictions, monitoring validation, and change-control validation by business criticality and tenant sensitivity.

·        Harden nested virtualization settings, KVM modules, QEMU services, libvirt services, virtqemud services, compute agents, storage agents, backup agents, monitoring agents, orchestration agents, migration services, metadata services, host networking, firewall rules, bridge interfaces, tap devices, storage mounts, SSH keys, systemd units, cron entries, and management access.

·        Validate that KVM administration can distinguish approved kernel patching, reboot validation, live migration, host evacuation, CI execution, sandbox testing, malware-analysis activity, kernel testing, storage maintenance, backup activity, vendor support, emergency remediation, and incident response from attacker-relevant activity.

·        Reduce broad or informal exceptions that allow sensitive KVM hosts, multi-tenant compute pools, regulated workloads, customer-managed workloads, or shared storage environments to remain exposed to unnecessary nested virtualization, weak placement governance, incomplete logging, unclear tenant ownership, or unresolved compute trust risk.

Priority Three — Improve Guest, Host-Fault, Placement, and Artifact Visibility

·        Centralize KVM host inventory, nested virtualization inventory, guest trust classification, guest activity logs where available, host kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, systemd journals, crash records, VM placement records, tenant mapping, image lineage, workload mapping, migration records, host evacuation records, storage logs, backup logs, metadata logs, identity logs, orchestration logs, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, change-control records, vulnerability-management data, incident-response records, and remediation evidence.

·        Improve telemetry that links suspicious guest-side virtualization activity to host-side KVM instability, compute-node failure, host evacuation, VM placement anomalies, host artifact access, storage access, backup access, credential exposure, control-plane interaction, outbound communication, tenant-boundary exposure, and post-remediation activity.

·        Prioritize detection for suspicious guest-side virtualization behavior followed by KVM host instability, compute-node failure, repeated tenant-linked faults, host artifact access, VM disk access, snapshot access, memory artifact access, storage access, backup access, credential access, control-plane interaction, rare egress, or continued activity after remediation.

·        Validate timestamp normalization, field mapping, schema mapping, lookup accuracy, enrichment quality, exception logic, asset tagging, nested virtualization mapping, VM placement mapping, tenant mapping, storage object mapping, backup repository mapping, destination mapping, and SIEM correlation before promoting hunt logic into high-severity alerting.

·        Require staged containment review for KVM hosts with unresolved host compromise evidence, VM artifact exposure, credential exposure, storage access, backup access, control-plane activity, rare egress, cross-tenant uncertainty, or post-remediation activity.

Priority Four — Strengthen Artifact, Credential, Storage, Backup, and Control-Plane Trust Controls

·        Improve visibility into VM disks, snapshots, memory artifacts, guest configuration files, metadata files, cloud-init data, image repositories, backup repositories, libvirt artifacts, QEMU artifacts, host logs, crash dumps, temporary staging paths, SSH keys, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, deployment credentials, and reusable administrative credentials.

·        Improve protection for storage backends, backup repositories, image repositories, snapshot repositories, metadata services, identity services, orchestration APIs, migration services, monitoring systems, logging systems, management networks, tenant networks, and sibling compute infrastructure reachable from compute-host context.

·        Improve tenant impact visibility into affected guests, adjacent tenants, sibling VM disks, cross-tenant snapshots, shared storage, management databases, image repositories, backup platforms, migration services, host inventory systems, and management-plane access paths.

·        Define rapid response paths for host quarantine, workload evacuation, host rebuild, storage review, backup validation, credential rotation, token rotation, SSH key review, metadata access review, orchestration review, management-network review, tenant impact assessment, legal review, compliance review, cyber-insurance engagement, communications planning, customer or partner notification analysis, and executive reporting.

·        Prioritize assets and workflows involving multi-tenant workloads, regulated workloads, customer-managed guests, partner workloads, CI execution, sandboxed analysis, malware detonation, shared storage, backup repositories, identity integrations, orchestration systems, management networks, high-availability compute pools, and business-critical services.

Priority Five — Improve Source-Enrichment, Egress, Fault, and Post-Remediation Correlation

·        Enrich DNS, firewall, proxy, NDR, EDR network, flow, control-plane, storage, backup, metadata, identity, orchestration, endpoint-adjacent, incident-response, and change-management telemetry with KVM host identity, nested virtualization state, compute pool, guest ID, tenant ID, project ID, image ID, workload ID, host-fault context, storage object, backup repository, destination context, business owner, platform owner, tenant owner, and approved workflow status.

·        Monitor suspicious egress and east-west access after abnormal guest-side virtualization behavior, KVM host instability, compute-node failure, host artifact access, storage access, backup access, credential access, control-plane activity, tenant-boundary concern, or post-remediation activity.

·        Restrict outbound access from KVM compute hosts to approved update destinations, package repositories, DNS, NTP, syslog, monitoring destinations, storage destinations, backup destinations, migration destinations, metadata services, orchestration services, management networks, and documented business paths where feasible.

·        Prevent network-only detections from asserting KVM exploitation, host compromise, credential exposure, data theft, cross-tenant exposure, control-plane compromise, command-and-control, lateral movement, or containment failure without guest, host-fault, placement, artifact, storage, backup, control-plane, remediation, or workflow correlation.

·        Treat continued host instability, rare egress, artifact access, storage access, backup access, credential use, control-plane activity, deleted logs, missing crash artifacts, VM placement anomalies, tenant-boundary uncertainty, or suspicious host behavior after remediation as containment-validation failure until proven otherwise.

Priority Six — Strengthen SOC, Platform, Legal, Tenant, and Executive Response

·        Create or update playbooks for suspicious guest-side virtualization behavior, nested virtualization exposure, KVM host instability, compute-node failure, repeated tenant-linked faults, host artifact access, VM disk access, snapshot access, memory artifact access, credential exposure, storage access, backup access, control-plane interaction, rare outbound communication, tenant-boundary uncertainty, and post-remediation activity.

·        Require responders to validate affected host, affected kernel version, nested virtualization state, affected guest, affected tenant, affected image, affected compute pool, host-fault evidence, crash evidence, VM placement, tenant ownership, storage access, backup access, credential exposure, control-plane activity, destination context, business owner, platform owner, tenant sensitivity, data sensitivity, and remediation status.

·        Require rapid decision paths for emergency patching, reboot validation, livepatch validation, nested virtualization disablement, compute-host quarantine, workload evacuation, host rebuild, VM placement reconstruction, storage validation, backup validation, credential rotation, control-plane review, tenant impact assessment, vendor escalation, legal and compliance escalation, cyber-insurance coordination, communications planning, customer or partner notification analysis, and executive reporting.

·        Require compute-trust validation before affected hosts or compute pools resume unrestricted multi-tenant, customer-managed, regulated, partner-facing, CI, sandbox, malware-analysis, shared-storage, backup-connected, identity-connected, orchestration-connected, or high-availability functions.

·        Require post-event review to determine whether the organization can prove that KVM activity was approved operational activity rather than suspicious follow-on behavior.

Strategic Outcome

The organization should be able to prove whether suspicious KVM activity affected host integrity, VM artifact exposure, credential access, storage access, backup access, control-plane interaction, tenant separation, outbound communication, customer-facing availability, partner workflows, regulated workloads, or post-remediation access. It should also be able to scope exposure across KVM host, nested virtualization setting, guest, tenant, image, workload, compute pool, storage object, backup repository, credential source, control-plane service, management network, outbound destination, business owner, platform owner, tenant owner, remediation action, change-control record, and business workflow context, then restore compute-host trust, tenant separation, storage confidence, backup integrity, credential protection, control-plane assurance, tenant confidence, and business continuity before virtualization boundary compromise becomes broad operational disruption.

S38 — Attack Economics & Organizational Impact Model

Figure 7

KVM guest-to-host escape and multi-tenant virtualization boundary compromise attack economics model showing how untrusted guest-side virtualization behavior can create host integrity uncertainty, tenant-boundary exposure risk, VM artifact exposure, storage and backup trust loss, credential exposure, control-plane impact, containment burden, and executive compute-trust restoration.

KVM guest-to-host escape and multi-tenant virtualization boundary compromise changes intrusion economics by allowing adversaries to pressure infrastructure that may support public cloud services, private cloud platforms, hosting-provider environments, OpenStack compute nodes, Kubernetes virtualization, CI execution, sandboxed analysis, malware-analysis systems, developer labs, customer-managed workloads, regulated workloads, shared storage, backup repositories, identity integrations, orchestration services, management networks, high-availability applications, and multi-tenant compute operations. When suspicious guest-side virtualization behavior, nested virtualization activity, host-side KVM instability, compute-node failure, host artifact access, credential exposure, storage access, backup access, control-plane interaction, outbound communication, tenant-boundary uncertainty, or post-remediation activity aligns inside one investigation window, the attacker can create disproportionate business uncertainty without compromising every endpoint, user account, application, tenant, or internal system individually.

The organization’s cost expands when responders must prove whether guest-side virtualization activity remained routine workload behavior, whether nested virtualization exposure created host-boundary risk, whether KVM instability reflected exploit-aligned boundary stress, whether VM artifacts were accessed, whether storage or backup systems were reached, whether credentials or tokens were exposed, whether control-plane services were affected, whether outbound communication reflected callback or staging behavior, whether tenant boundaries were impacted, and whether affected compute infrastructure can safely return to service after remediation.

Adversary Economic Advantage

·        KVM guest-to-host escape can reduce attacker friction because the adversary can begin from a guest workload, tenant-controlled environment, customer-managed image, CI job, sandbox workload, malware-analysis environment, or high-risk virtualization workload rather than first compromising a traditional employee endpoint or enterprise identity path.

·        Nested virtualization exposure can give adversaries access to low-level virtualization behavior, nested VM lifecycle manipulation, virtualization-extension use, memory-management behavior, and host-boundary stress paths from inside a guest-controlled environment.

·        A successful or suspected guest-to-host transition can create access uncertainty across VM disks, snapshots, memory artifacts, cloud-init data, metadata files, libvirt artifacts, QEMU artifacts, host logs, crash dumps, storage paths, backup repositories, and credential-bearing files.

·        KVM compute hosts give adversaries scalable leverage when one affected host supports multiple guests, multiple tenants, shared storage, backup repositories, identity integrations, orchestration services, migration networks, management networks, or downstream business workloads.

·        Normal KVM administration, kernel patching, reboot validation, live migration, host evacuation, failover testing, CI execution, sandbox testing, malware-analysis workflows, backup activity, storage maintenance, monitoring, vendor support, emergency remediation, and incident-response cleanup can make attacker-driven behavior harder to classify quickly.

·        A single affected KVM compute host supporting multi-tenant workloads, regulated workloads, customer-managed tenants, partner workloads, shared storage, backup repositories, identity services, orchestration systems, management networks, or high-availability services can create disproportionate business impact if host integrity, credential exposure, storage access, backup access, or tenant-boundary exposure cannot be ruled out.

·        The attacker benefits when defenders cannot quickly determine whether guest activity, host-fault behavior, VM placement, artifact access, storage access, backup access, credential use, control-plane activity, outbound communication, or post-remediation behavior were legitimate operational activity or adversary-driven exploitation.

·        Downstream impact can extend into emergency patching, reboot validation, nested virtualization restriction, compute-host quarantine, workload evacuation, host rebuilds, VM placement reconstruction, tenant impact assessment, storage and backup review, credential rotation, control-plane review, vendor escalation, legal assessment, compliance review, cyber-insurance coordination, communications planning, executive reporting, and compute-trust restoration.

Defender Cost Expansion

·        The organization must investigate both suspicious KVM activity and the reliability of the asset, nested virtualization, guest activity, host KVM, crash, VM placement, tenant mapping, storage, backup, identity, metadata, orchestration, network, endpoint, change-control, remediation, and business-workflow evidence needed to confirm or disprove impact.

·        Response teams may need to reconstruct KVM asset exposure, nested virtualization state, guest trust classification, guest-side virtualization behavior, host-side KVM instability, compute-node failure, crash evidence, VM placement, tenant ownership, host artifact access, storage access, backup access, credential exposure, control-plane interaction, outbound communication, and post-remediation activity.

·        Mitigation may require emergency kernel remediation, reboot validation, livepatch validation, nested virtualization disablement, compute-host quarantine, workload evacuation, host rebuild, storage review, backup validation, credential rotation, token rotation, SSH key review, metadata access review, orchestration review, management-network review, tenant impact assessment, legal and compliance review, cyber-insurance support, communications planning, and executive assurance.

·        Internal exposure scoping may be required across affected KVM hosts, compute pools, guests, tenants, projects, images, workload families, storage objects, backup repositories, image repositories, snapshot repositories, metadata paths, identity services, orchestration services, management networks, migration networks, credentials, and business owners.

·        Response cost increases when KVM asset inventory, nested virtualization exposure mapping, guest trust classification, VM placement history, tenant mapping, host kernel logs, KVM logs, QEMU logs, libvirt logs, crash dumps, storage logs, backup logs, control-plane records, network telemetry, change-control records, or remediation evidence are incomplete.

·        Business impact increases when defenders must prove whether host compromise occurred, whether VM artifacts were accessed, whether credentials were exposed, whether storage or backup systems were reached, whether control-plane trust was affected, whether tenant boundaries were crossed, and whether compute services can safely continue.

Organizational Impact Model

Compute Trust Impact

The organization must determine whether x86 KVM compute hosts, Linux KVM hosts, OpenStack compute nodes, private cloud compute nodes, hosting-provider KVM nodes, self-managed KVM cloud hosts, Kubernetes virtualization hosts, CI KVM runners, sandbox KVM hosts, malware-analysis hosts, developer lab hosts, production hosts, staging hosts, or multi-tenant compute pools were exposed, affected, vulnerable, insufficiently patched, missing reboot validation, running nested virtualization for untrusted workloads, or positioned in high-value compute roles during the event window.

Nested Virtualization and Guest Trust Impact

The organization must determine whether nested virtualization exposure, CPU virtualization settings, guest trust classification, customer-managed workloads, externally provisioned workloads, partner-managed workloads, CI-controlled workloads, sandboxed workloads, malware-analysis workloads, high-risk guest images, or approved nested virtualization exceptions created a path for guest-side activity to influence host integrity.

Host Instability and KVM Boundary Impact

The organization must determine whether suspicious guest-side behavior remained routine workload activity, whether host-side KVM warnings occurred, whether MMU fault behavior appeared, whether shadow paging or reverse-map handling issues occurred, whether kernel oops events, panics, soft lockups, watchdog events, unexplained reboots, compute-node failures, service restarts, host quarantine, or host evacuation aligned with guest-side virtualization activity, and whether the activity represented actual boundary stress rather than benign maintenance, hardware failure, capacity exhaustion, storage failure, driver instability, or unrelated kernel defects.

VM Placement and Tenant Blast-Radius Impact

The organization must determine which guests, tenants, projects, images, workload families, compute pools, host groups, migration events, evacuation actions, and scheduling decisions were involved during the suspicious window. This includes determining whether the same guest, tenant, image, workload family, automation pattern, nested virtualization workload, or compute pool was repeatedly associated with host instability or post-fault activity.

Host Artifact and Credential Impact

The organization must determine whether VM disks, snapshots, memory dumps, guest configuration files, metadata files, cloud-init data, libvirt artifacts, QEMU artifacts, host logs, crash dumps, image repositories, backup archives, temporary staging paths, SSH keys, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, deployment credentials, or reusable administrative credentials were accessed, copied, exposed, rotated, or reused after suspicious KVM activity.

Storage, Backup, and Infrastructure Dependency Impact

The organization must determine whether affected compute hosts accessed storage backends, backup repositories, image repositories, snapshot repositories, migration paths, metadata services, identity services, orchestration APIs, monitoring systems, logging systems, management networks, tenant networks, or sibling compute hosts after suspicious host instability. This review determines whether suspected host compromise extended beyond a single compute node into shared infrastructure dependencies.

Outbound Communication and Internal Service Impact

The organization must determine whether the KVM compute host initiated rare outbound communication, DNS anomalies, HTTPS callbacks, SSH, SMB, NFS, object storage access, file-transfer behavior, raw-IP communication, tunneling, tool retrieval, repeated callbacks, tenant-network access, management-network access, or sensitive internal-service access inconsistent with approved updates, package repositories, DNS, NTP, syslog, monitoring, storage, backup, metadata, migration, orchestration, or platform operations.

Containment and Compute-Trust Restoration Impact

The organization must restore compute-host trust, tenant separation, storage confidence, backup integrity, credential protection, control-plane assurance, and business continuity through KVM patch validation, reboot validation, livepatch validation, nested virtualization restriction, host quarantine, workload evacuation, host rebuild, VM placement reconstruction, tenant ownership review, storage and backup validation, credential rotation, control-plane review, outbound review, vendor escalation, legal review, compliance assessment, cyber-insurance coordination, executive reporting, and post-remediation monitoring.

Governance Impact

Leadership may need to treat confirmed or strongly suspected KVM guest-to-host escape as an executive-level compute trust and tenant-separation incident because affected hosts can support multi-tenant workloads, regulated workloads, customer-managed guests, partner workloads, CI execution, sandboxed analysis, malware detonation, shared storage, backup repositories, identity services, orchestration systems, management networks, high-availability services, and business-critical service continuity.

Economic Impact Summary

KVM guest-to-host escape and multi-tenant virtualization boundary compromise is economically powerful for adversaries because it can convert guest-side control into host integrity uncertainty, VM artifact exposure risk, credential exposure, storage and backup trust concerns, control-plane reach, tenant-boundary uncertainty, and containment burden. The organization’s financial exposure grows when it cannot quickly prove whether guest activity remained contained, whether host compromise occurred, whether VM artifacts were accessed, whether credentials were exposed, whether storage or backup systems were reached, whether control-plane services were affected, whether outbound communication occurred, whether tenant boundaries were impacted, and whether compute infrastructure can safely continue.

S39 Economic Impact & Organizational Exposure

KVM guest-to-host escape and multi-tenant virtualization boundary compromise expands the organizational exposure model by increasing uncertainty around whether guest-controlled virtualization behavior, nested virtualization exposure, KVM MMU behavior, shadow paging behavior, reverse-map handling, SEV, SEV-ES, SEV-SNP, SVM nested virtualization behavior, host-side KVM instability, compute-node failure, VM placement, tenant ownership, host artifact access, storage access, backup access, credential exposure, metadata access, identity access, orchestration access, management-plane activity, rare egress, tenant-boundary exposure, or post-remediation activity affected the integrity of the virtualization layer. The exposure aligns with the report’s established detection model because the core business risk is not limited to one CVE identifier, one exploit nickname, one kernel version, one nested virtualization setting, one host crash, one proof-of-concept, or one scanner pattern; it is whether trusted KVM compute infrastructure can be converted into a host-integrity risk, tenant-separation risk, VM artifact exposure point, storage or backup trust issue, credential exposure path, control-plane dependency risk, or executive compute-trust restoration problem.

Economic exposure rises when suspicious KVM activity involves nested-virtualization-enabled x86 KVM hosts, arm64 KVM hosts, AMD SVM nested virtualization, SEV-ES or SEV-SNP guest behavior, KVM/QEMU virtualization boundaries, untrusted guest workloads, customer-managed guests, externally provisioned workloads, CI-controlled workloads, sandboxed workloads, malware-analysis workloads, high-risk guest images, host-side KVM warnings, MMU fault behavior, shadow paging fault behavior, reverse-map handling issues, kernel oops events, panics, soft lockups, watchdog events, compute-node resets, host evacuation, host quarantine, VM placement uncertainty, storage access, backup access, metadata access, identity access, orchestration activity, management-network access, rare outbound communication, or repeated guest-linked host instability. Exposure is highest when suspicious guest-side activity cannot be separated from host-side KVM instability, host artifact access, credential exposure, storage or backup access, control-plane interaction, tenant-boundary exposure, rare egress, or activity that continues after remediation.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible enterprise estimate is tied to whether activity remains limited to exposure validation, scanner traffic, vulnerable-kernel findings, nested virtualization discovery, guest-side testing, isolated host instability, failed boundary-stress attempts, virtualization-boundary confidentiality review, or patch validation; becomes suspected or confirmed KVM guest-to-host boundary stress; or expands into host-level access, VM artifact exposure, credential exposure, storage access, backup access, control-plane interaction, rare outbound communication, cross-tenant exposure, multi-host instability, or loss of confidence in virtualization-layer trust.

Economic exposure increases when the organization cannot quickly prove whether guest-side virtualization activity remained limited to approved workload behavior, whether nested virtualization behavior reached host-side KVM fault conditions, whether compute-node instability was exploit-aligned, whether VM disks or snapshots were accessed, whether memory artifacts or metadata were exposed, whether credentials or tokens were accessed, whether storage or backup systems were reached, whether control-plane services were affected, whether outbound communication occurred, whether tenant boundaries were impacted, and whether host kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, VM placement records, tenant records, crash evidence, storage logs, backup logs, identity logs, metadata logs, orchestration logs, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, change-control records, and remediation evidence can be joined into a reliable sequence.

Low Impact Scenario

Estimated $500K - $4M

This scenario applies when suspicious guest-side virtualization behavior, nested virtualization misuse, exposed-kernel findings, scanner activity, public proof-of-concept-like activity, failed boundary-stress attempts, isolated KVM warnings, isolated host instability, compute-node recovery, virtualization-boundary review, or guest-side testing is detected quickly, but available telemetry confirms no successful host compromise, no VM artifact access, no storage access, no backup access, no credential exposure, no control-plane interaction, no tenant-boundary exposure, no rare outbound communication, no persistence-like host changes, and no post-remediation activity. Response remains limited to targeted patch validation, reboot confirmation, nested virtualization restriction, host-fault preservation, focused VM placement review, tenant impact check, storage and backup spot-checking, outbound communication review, short-term monitoring, and executive tracking.

Moderate Impact Scenario

Estimated $5M - $30M

This scenario applies when confirmed or strongly suspected guest-to-host boundary stress affects one or more KVM compute hosts where suspicious guest-side virtualization behavior aligns with host-side KVM instability, compute-node failure, repeated tenant-linked faults, host evacuation, host quarantine, VM artifact access, storage access, backup access, metadata access, rare outbound communication, administrative changes, or control-plane interaction. The organization cannot immediately determine whether adversaries obtained host-level access, exposed guest artifacts, accessed VM disks or snapshots, reached credentials, manipulated host configuration, accessed storage or backup systems, interacted with identity or orchestration services, or crossed tenant boundaries. Response may require enterprise-focused KVM host review, nested virtualization inventory validation, VM placement reconstruction, tenant ownership review, crash and kernel log preservation, compute-node quarantine, host configuration comparison, storage and backup access review, credential and token review, control-plane analysis, outbound traffic analysis, legal and compliance review, cyber-insurance coordination, executive reporting, and strengthened monitoring for post-remediation activity.

High Impact Scenario

Estimated $40M - $180M+

This scenario applies when KVM guest-to-host escape or virtualization-boundary compromise becomes an enterprise-impact event involving confirmed or strongly suspected host compromise, cross-tenant exposure, VM disk or snapshot access, memory artifact exposure, credential access, storage or backup repository access, identity service interaction, orchestration abuse, management-network access, lateral movement from a compute host, multi-host instability, tenant data exposure, service disruption, host physical page access, host kernel read/write behavior, or incomplete containment. The upper end of this range applies when the organization must assume that affected compute hosts, tenant workloads, storage backends, backup systems, metadata paths, orchestration agents, identity integrations, management services, and dependent workloads were exposed until audit evidence proves otherwise. Response may require extended host forensics, emergency workload evacuation, compute-host rebuilds, nested virtualization disablement, broad credential and token rotation, storage and backup validation, tenant impact assessment, customer or partner notification analysis, legal and privacy escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal validation that affected compute infrastructure can safely return to service.

Annualized Risk Exposure

Estimated $5M - $40M+ for materially exposed enterprise environments with nested-virtualization-enabled KVM hosts, untrusted or customer-managed guest workloads, multi-tenant compute pools, incomplete host-fault logging, incomplete crash evidence, weak VM placement history, limited tenant mapping, incomplete reboot validation, limited storage and backup attribution, weak outbound monitoring, incomplete management-plane records, or poor host-to-workload mapping.

Exposure may exceed $40M - $180M+ where KVM guest-to-host compromise results in confirmed or suspected host-level access, cross-tenant exposure, VM disk or snapshot access, credential exposure, storage or backup repository access, identity or orchestration interaction, management-network access, multi-host instability, regulated workload exposure, customer-facing service disruption, host physical page access, host kernel read/write behavior, incomplete containment, cyber-insurance review, legal escalation, communications response, or board-level reporting.

Management-Platform Dependency

Management-platform dependency is high where KVM administration, nested virtualization configuration, host patching, reboot validation, livepatch validation, VM placement, live migration, host evacuation, compute-node quarantine, storage attachment, backup workflows, image repository management, metadata services, identity integrations, orchestration services, monitoring systems, migration networks, management networks, and privileged access workflows are used to manage virtualization infrastructure. Dependency increases when affected hosts support multi-tenant workloads, regulated workloads, customer-managed guests, partner workloads, CI execution, sandboxed analysis, malware-analysis workflows, shared storage, backup repositories, high-availability compute pools, or downstream services that cannot be easily isolated without business disruption.

Compute-Host Trust

Compute-host trust is reduced when the organization cannot prove that KVM host state, nested virtualization configuration, CPU architecture exposure, kernel version, reboot completion, livepatch effectiveness, QEMU state, libvirt state, virtqemud state, compute-agent behavior, VM placement history, tenant mapping, storage mappings, backup mappings, host credentials, service credentials, metadata access, identity access, orchestration access, management-network access, and host configuration baselines remained reliable during the activity window.

Compute-host trust is further reduced when suspicious guest-side virtualization behavior, host-side KVM instability, compute-node failure, repeated tenant-linked faults, host artifact access, storage access, backup access, credential access, control-plane activity, outbound communication, host configuration drift, log deletion, missing crash artifacts, host physical page access, host kernel read/write behavior, or telemetry gaps cannot be tied to approved patching, approved reboot validation, approved live migration, approved host evacuation, approved CI execution, approved sandbox activity, approved malware-analysis workflows, approved backup operations, approved storage maintenance, approved vendor support, approved monitoring, or validated incident-response activity.

Visibility Confidence

Visibility confidence is highest when KVM asset inventory, nested virtualization inventory, guest trust classification, CPU architecture context, SEV, SEV-ES, SEV-SNP, or SVM context where applicable, host kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, systemd journals, crash dumps, VM placement records, tenant records, image records, workload records, migration records, storage logs, backup logs, metadata logs, identity logs, orchestration logs, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, patch records, reboot records, change-control records, and remediation evidence can be joined reliably.

Visibility confidence is reduced when host logs rotate quickly, crash dumps are disabled, guest telemetry is unavailable, VM placement records are incomplete, tenant mapping is weak, storage and backup logs lack host attribution, metadata access is poorly logged, identity and orchestration events cannot be mapped to compute-host context, outbound telemetry cannot distinguish approved KVM behavior from suspicious communication, or timestamps and change records are insufficient to reconstruct the guest-to-host-to-impact sequence.

Privileged Object Confidence

Privileged object confidence is high when VM disks, snapshots, memory artifacts, guest configuration files, metadata files, cloud-init data, image repositories, backup repositories, libvirt artifacts, QEMU artifacts, host logs, crash dumps, SSH keys, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, deployment credentials, reusable administrative credentials, service accounts, kernel modules, systemd units, cron entries, firewall rules, bridge interfaces, tap devices, storage mounts, and management-access restrictions can be validated against approved baselines.

Confidence is reduced when suspicious activity occurs outside approved windows, lacks an owning ticket, accesses VM artifacts, touches storage or backup repositories, exposes credentials, modifies host configuration, changes service state, initiates rare outbound communication, uses metadata or identity services unexpectedly, accesses orchestration APIs, touches tenant networks, deletes logs, removes crash artifacts, or creates uncertainty around whether the action was performed by an expected administrator, platform automation, backup workflow, storage workflow, monitoring process, vendor support workflow, emergency change, or incident-response workflow.

Connector and Credential Dependency

Connector and credential dependency is high when KVM compute hosts, storage agents, backup agents, orchestration agents, monitoring agents, metadata services, identity integrations, migration services, image repositories, snapshot repositories, deployment systems, CI pipelines, sandbox systems, malware-analysis systems, and management platforms rely on SSH keys, API tokens, service accounts, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, deployment secrets, tenant secrets, vendor support credentials, reusable administrative credentials, or automation accounts. These dependencies increase the impact of even limited host compromise because responders may need to prove that configuration files, credential material, service tokens, metadata paths, storage connectors, backup connectors, orchestration integrations, and downstream trust relationships remained intact.

Credential dependency becomes materially higher when VM artifacts, metadata files, cloud-init data, host logs, crash dumps, storage credentials, backup credentials, orchestration credentials, monitoring credentials, metadata credentials, tenant secrets, service tokens, deployment credentials, or reusable administrative credentials may have been accessed after suspicious KVM instability, host artifact access, outbound communication, control-plane activity, administrative-control changes, host physical page access, or host kernel read/write behavior.

Downstream Infrastructure Dependency

Downstream infrastructure dependency is high when KVM compute hosts, sibling compute hosts, tenant networks, storage backends, backup repositories, image repositories, snapshot repositories, metadata services, identity providers, orchestration APIs, migration networks, monitoring systems, logging systems, management networks, CI systems, sandbox environments, malware-analysis environments, and application infrastructure depend on the affected virtualization layer. These dependencies increase scope because attackers may use host-level context, exposed credentials, VM artifacts, storage access, backup access, metadata access, control-plane access, or trusted compute-host relationships to affect adjacent services or downstream workloads.

Downstream dependency should be interpreted conservatively because KVM guest-to-host escape does not automatically prove cloud compromise, identity compromise, storage compromise, data theft, ransomware deployment, destructive activity, or broad lateral movement. It becomes materially relevant when telemetry shows credential access, VM artifact exposure, storage access, backup access, metadata access, identity access, orchestration activity, management-network access, tenant-network access, rare outbound communication, host physical page access, host kernel read/write behavior, or suspicious use of credentials connected to the affected compute host.

Customer, Workforce, and Regulatory Exposure

Customer, workforce, and regulatory exposure increases when suspicious KVM guest-to-host activity, host compromise, VM artifact exposure, credential exposure, storage access, backup access, control-plane interaction, tenant-boundary exposure, management-network access, outbound communication, customer-facing service disruption, regulated workload concern, partner workflow exposure, or incomplete containment affects multi-tenant workloads, regulated workloads, customer-managed guests, partner workloads, workforce-facing systems, externally hosted services, shared storage, backup repositories, identity integrations, orchestration systems, or high-availability business services.

Exposure also increases when telemetry gaps prevent timely confirmation of whether customer data, tenant workloads, regulated data, partner workflows, storage objects, backup repositories, credentials, control-plane actions, metadata access, outbound communication, post-remediation activity, customer reports, partner reports, service disruption, host physical page access, or host kernel read/write behavior occurred.

Residual Economic Risk

Residual economic risk remains after kernel patching, reboot validation, livepatch validation, nested virtualization restriction, host quarantine, workload evacuation, host rebuild, storage review, backup validation, credential rotation, control-plane review, egress blocking, tenant impact review, vendor escalation, or incident-response cleanup when the pre-remediation activity window cannot be reconstructed. Updating affected hosts reduces future exposure, but it does not prove that pre-remediation host compromise, VM artifact access, credential exposure, storage access, backup access, control-plane interaction, outbound communication, tenant-boundary exposure, host physical page access, host kernel read/write behavior, or persistence-like host changes did not occur.

Residual risk should remain elevated until historical host kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, systemd journals, crash dumps, VM placement records, tenant records, storage logs, backup logs, metadata logs, identity logs, orchestration logs, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, backup comparison data, change-control records, incident-response notes, remediation records, and business-owner evidence have been reviewed.

Proof-of-Concept / KEV Behavioral Coverage Assessment

This report’s behavioral detection model directly covers Januscape / CVE-2026-53359 where observable activity aligns with the primary KVM/x86 guest-to-host compromise chain: nested virtualization exposure, guest-side privileged virtualization activity, KVM shadow MMU or related host-fault behavior, host-side instability, compute-node failure, VM placement risk, host artifact access, storage access, backup access, credential exposure, control-plane interaction, rare outbound communication, tenant-boundary concern, and containment validation.

The model directly covers ITScape / CVE-2026-46316 where observable activity aligns with a KVM/arm64 guest-to-host escape model: architecture-specific KVM guest activity, host compromise signals, compute-node context, VM placement, host artifact access, sensitive dependency access, outbound communication, and containment validation. ITScape should not be treated as the same x86 shadow-MMU path as Januscape, but it is direct coverage for the broader KVM guest-to-host escape behavior class.

The model directly covers CVE-2026-46113 because it maps to KVM x86 shadow paging use-after-free behavior and aligns with the report’s KVM MMU, shadow paging, reverse-map, memory-management, nested virtualization, KVM instability, and guest-to-host boundary-stress model. This item should be counted as direct behavioral coverage because S25 is designed around KVM host-fault and shadow paging behavior rather than a single exploit nickname.

The model directly covers CVE-2026-23401 because it maps to KVM x86/MMU shadow-present SPTE handling behavior and aligns with the report’s KVM MMU, shadow paging, memory-management, and host-fault coverage model. This item should not be described as Januscape-equivalent, but it is direct behavioral coverage for the report’s KVM MMU and shadow paging detection model.

The model directly covers CVE-2023-4155 because a KVM guest using SEV-ES or SEV-SNP can trigger recursive VMGEXIT handling, stack overflow behavior, denial-of-service impact, and potential guest-to-host escape in specific kernel configurations. This aligns directly with the report’s nested virtualization, SEV, SEV-SNP, guest-triggered host-fault, compute-node instability, and guest-to-host boundary-risk model.

The model directly covers CVE-2021-3653 because AMD SVM nested virtualization behavior involving VMCB validation, L1-to-L2 nested guest handling, host physical page access, crash, sensitive data exposure, or potential guest-to-host escape aligns directly with the report’s nested virtualization, tenant-boundary, host-fault, and virtualization trust model.

The model directly covers CVE-2021-3656 because AMD SVM nested virtualization behavior involving improper VMCB validation and the possibility of host physical page read/write, system crash, sensitive data exposure, or potential guest-to-host escape aligns directly with the report’s guest-controlled virtualization, host physical page access, KVM host-fault, and guest-to-host boundary-risk model.

The model directly covers CVE-2021-4093 because a KVM guest using SEV-ES can trigger host-kernel out-of-bounds reads and writes through malicious VMGEXIT behavior, resulting in system crash or potential guest-to-host escape. This aligns directly with the report’s SEV-ES, guest-triggered host-kernel access, host instability, and compute-host trust model.

The model provides coverage with adaptation for VMSCAPE / CVE-2025-40300 where local evidence involves KVM/QEMU virtualization-boundary confidentiality exposure, branch predictor isolation weakness, guest-to-host or cross-boundary secret exposure concern, and compute-trust impact. This item should not be counted as direct host compromise coverage because speculative-execution data exposure is a different technical path than KVM host takeover, but it maps to the report’s broader virtualization trust, tenant-boundary assurance, and KVM/QEMU exposure model when local telemetry can support impact assessment.

The model provides coverage with adaptation for CVE-2026-31591 because KVM SEV-SNP vCPU synchronization behavior can corrupt vCPU state or crash the host kernel. This aligns with the report’s host-fault and compute-node instability branches, but it should not be counted as direct guest-to-host escape coverage unless local telemetry also shows host compromise, artifact access, storage access, backup access, credential exposure, rare egress, tenant impact, or post-remediation containment failure.

The model provides coverage with adaptation for CVE-2026-31593 because KVM SEV behavior involving VMSA synchronization and guest-private memory access can generate an RMP page fault and panic the host on SNP-enabled systems. This aligns with the report’s SEV/SNP host-fault, host panic, and compute-node instability model, but it should not be counted as direct guest-to-host compromise coverage without post-fault dependency, artifact, credential, tenant, or containment evidence.

Known exploitation reporting, public proof-of-concept availability, vendor patch availability, scanner coverage, NVD metadata, security research publication, and KEV-style urgency should be treated as prioritization inputs, not compromise proof. Local compromise assessment must still be based on observable guest activity, host-side KVM behavior, crash or fault telemetry, VM placement history, artifact access, storage access, backup access, credential exposure, control-plane activity, outbound communication, tenant impact, and incident-response findings.

Detection Engineering Coverage Interpretation

The S25 detection content provides direct behavioral coverage when suspicious guest-side virtualization activity, nested virtualization exposure, KVM host instability, compute-node failure, VM placement anomalies, host artifact access, storage access, backup access, credential exposure, control-plane interaction, rare compute-host egress, tenant-boundary exposure, repeated guest-linked faults, host physical page access, host kernel read/write behavior, or post-remediation activity falls inside the report’s KVM guest-to-host escape model. Direct coverage applies where observable activity can be joined across guest, host, KVM, placement, tenant, artifact, storage, backup, identity, orchestration, network, administrative, and remediation evidence.

Detection coverage should be interpreted as behavior-led coverage, not CVE-string coverage. CVE identifiers, kernel versions, exploit names, proof-of-concept names, crash strings, guest image names, tenant names, source IPs, command strings, file paths, kernel messages, scanner labels, malware names, actor names, campaign labels, or exploit labels should not be used as primary detection inputs unless they are locally approved enrichment supporting triage. Detection confidence remains based on observable guest behavior, host-fault behavior, VM placement context, tenant context, artifact access, storage behavior, backup behavior, control-plane context, outbound communication, administrative context, remediation context, and change-control context.

Exploit scripts, proof-of-concept tooling, scanner logic, kernel module examples, crash strings, public exploit writeups, guest-side harnesses, CPU architecture references, and source infrastructure should be interpreted as behavior-led enrichment only. The report does not detect a named malware family directly. It detects the behavior that exploitation tooling, researchers, scanners, tenant-controlled workloads, or adversaries may produce when they interact with nested virtualization, trigger host-side KVM instability, access VM artifacts, touch storage or backup systems, access credentials, communicate externally, interact with control-plane services, affect tenant boundaries, read or write host physical pages, or create host-kernel access conditions.

Actor, campaign, cybercrime, ransomware, initial-access, espionage, broker, cloud-abuse, or virtualization-research coverage should be treated as enrichment and context only. The report does not detect actor names directly. It detects the behavior those actors, operators, affiliates, researchers, tenants, or toolchains may produce when abusing guest-controlled virtualization behavior, nested virtualization exposure, KVM fault behavior, compute-host trust relationships, storage access, backup access, credentials, control-plane paths, outbound communication, and tenant-boundary uncertainty.

Active exploitation attempts, public reporting, proof-of-concept availability, vendor priority, scanner coverage, and KEV status should be treated as urgency and remediation-prioritization signals, not as detection coverage by themselves. Local compromise assessment must still be based on observable guest activity, host KVM telemetry, crash evidence, VM placement records, tenant ownership, artifact access, storage access, backup access, credential exposure, outbound communication, control-plane behavior, and incident-response findings.

Direct Coverage

Direct coverage applies where observable activity aligns with the report’s KVM guest-to-host compromise chain: nested virtualization exposure, guest-side privileged virtualization activity, host-side KVM instability, architecture-specific KVM escape behavior, KVM MMU behavior, shadow paging behavior, reverse-map handling, SEV, SEV-ES, SEV-SNP, SVM nested virtualization behavior, host physical page access, host-kernel read/write behavior, compute-node failure, host artifact access, storage access, backup access, credential exposure, control-plane interaction, rare outbound communication, tenant-boundary uncertainty, or containment failure.

·        CVE-2026-53359

·        CVE-2026-46316

·        CVE-2026-46113

·        CVE-2026-23401

·        CVE-2023-4155

·        CVE-2021-3653

·        CVE-2021-3656

·        CVE-2021-4093

The CVEs listed above should be counted as direct coverage because they fall inside the report’s explicit KVM guest-to-host escape, KVM MMU, shadow paging, nested virtualization, SEV, SEV-ES, SEV-SNP, SVM, host physical page access, host-kernel read/write, compute-host trust, tenant-boundary, post-fault dependency access, rare egress, and containment-validation model. They should not all be described as Januscape-equivalent. The correct framing is that they are directly covered by the behavior model in S25, with Januscape and ITScape acting as the strongest current public anchors.

Coverage With Adaptation

Coverage with adaptation applies to related KVM, hypervisor, SEV, SEV-SNP, QEMU, virtualization-boundary, confidentiality, host-fault, VM-isolation, or multi-tenant compute trust issues that are not direct guest-to-host escape matches but still produce behavior that can be mapped to the report’s detection model.

·        CVE-2025-40300

·        CVE-2026-31591

·        CVE-2026-31593

Coverage with adaptation requires local architecture mapping, CPU architecture mapping, virtualization platform mapping, guest-to-host boundary mapping, nested virtualization mapping, SEV or SEV-SNP context where applicable, QEMU/KVM context where applicable, host telemetry, guest activity context where available, VM placement mapping, tenant mapping, host-fault telemetry, sensitive dependency mapping, storage and backup mapping, credential exposure review, outbound telemetry, control-plane telemetry, approved administrator baselines, approved workload baselines, and telemetry joins. These items should not be counted as direct guest-to-host compromise coverage unless local telemetry shows suspicious guest-side virtualization behavior, host-side KVM instability, host compromise, artifact access, storage access, backup access, credential exposure, rare egress, control-plane interaction, tenant impact, or containment failure.

Non-Coverage Conditions

Non-coverage applies where related activity does not produce observable guest-side virtualization behavior, nested virtualization exposure, KVM host instability, host-fault telemetry, compute-node failure, VM placement linkage, host artifact access, storage access, backup access, credential exposure, control-plane interaction, outbound communication, tenant-boundary exposure, repeated guest-linked instability, virtualization-boundary confidentiality exposure, host physical page access, host-kernel read/write behavior, or post-remediation activity.

Non-coverage applies when activity remains limited to vulnerable-kernel exposure, nested virtualization presence, package-version findings, scanner output, public proof-of-concept references, isolated KVM warnings, isolated API errors, isolated host reboots, generic Linux privilege escalation that remains inside the guest, unrelated container escape behavior, unrelated Kubernetes control-plane compromise, cloud identity compromise, storage-only anomalies, backup-only anomalies, network-only anomalies, host-instability-only events, denial-of-service-only events, WARN-only events, side-channel-only items without KVM/QEMU virtualization-boundary relevance, or maintenance activity without supporting guest, host, placement, fault, process, object, destination, or time-window linkage.

Non-coverage also applies when required guest activity logs, host kernel logs, KVM logs, QEMU logs, libvirt logs, virtqemud logs, compute-agent logs, crash dumps, VM placement records, tenant records, storage logs, backup logs, metadata logs, identity logs, orchestration logs, DNS logs, proxy logs, firewall logs, NDR telemetry, endpoint telemetry where available, change-control records, incident-response evidence, or SIEM telemetry are unavailable or cannot be joined reliably enough to support a coverage determination.

Activity should not be counted when it is better explained by approved KVM administration, kernel patching, reboot validation, livepatch validation, live migration, host evacuation, failover testing, kernel testing, CI execution, sandbox testing, malware-analysis activity, backup operations, storage maintenance, monitoring, vulnerability validation, vendor support, emergency remediation, security testing, vulnerability management, or incident response.

Current Coverage Count

Directly covered CVEs: 8

·        CVE-2026-53359

·        CVE-2026-46316

·        CVE-2026-46113

·        CVE-2026-23401

·        CVE-2023-4155

·        CVE-2021-3653

·        CVE-2021-3656

·        CVE-2021-4093

CVEs covered with adaptation: 3

·        CVE-2025-40300

·        CVE-2026-31591

·        CVE-2026-31593

Known exploited / exploitation-attempt-represented vulnerabilities in this S39 review: no confirmed KEV or named-actor exploitation claim should be made unless final publication QA confirms it.

Public exploit / proof-of-concept items requiring final publication QA: at least 3

·        CVE-2026-53359

·        CVE-2026-46316

·        CVE-2025-40300

Named malware / tooling / exploit-framework coverage: behavior-led public exploit-tooling and KVM guest-to-host abuse coverage, not a named malware-family count.

Named actor / campaign coverage: no confirmed named actor or APT attribution should be claimed.

Total CVEs directly covered by this report’s behavioral detection model: 8

Total CVEs covered with adaptation by this report’s behavioral detection model: 3

Total CVEs represented in the corrected S39 coverage register: 11

Coverage Qualification

Coverage is strong for behaviorally visible KVM guest-to-host exploitation where suspicious guest-side virtualization activity can be joined with nested virtualization exposure, KVM host instability, shadow paging or memory-management fault behavior, SEV or SEV-SNP context, SVM nested virtualization context, compute-node failure, VM placement context, tenant context, host artifact access, storage access, backup access, credential exposure, control-plane activity, rare egress, host physical page access, host-kernel read/write behavior, or post-remediation activity.

Coverage with adaptation is appropriate for KVM/QEMU virtualization-boundary confidentiality exposure, SEV-SNP vCPU synchronization behavior, and SEV/SNP host-panic behavior where the local environment can map architecture, CPU, guest, host, tenant, storage, control-plane, host-fault, and remediation context.

The report should not claim universal KVM detection, universal Linux kernel detection, universal hypervisor escape detection, universal cloud-provider detection, universal managed-cloud hypervisor detection, universal guest compromise detection, universal container escape detection, universal storage compromise detection, universal cloud identity compromise detection, universal data-exfiltration detection, universal ransomware detection, universal KEV coverage, universal APT coverage, or standalone actor attribution. Detection confidence depends on telemetry completeness, field mapping, local baselines, KVM asset inventory, nested virtualization exposure inventory, VM placement records, tenant mapping, host-fault telemetry, crash evidence, storage and backup telemetry, control-plane telemetry, outbound telemetry, change-control evidence, false-positive testing, query performance testing, and SOC triage readiness.

Executive Exposure Statement

The organization’s economic exposure is highest when KVM guest-to-host escape or virtualization-boundary compromise creates uncertainty around whether the virtualization layer remained trustworthy. The strategic risk is not only that a vulnerable kernel exists, that nested virtualization is enabled, that a public proof-of-concept exists, that a scanner touched the environment, that a host crashed, or that a side-channel class exists; it is the possibility that attackers used guest-controlled virtualization behavior to influence host-side KVM execution, expose VM artifacts, reach storage or backup systems, access credentials, interact with orchestration or identity services, cross tenant boundaries, initiate outbound communication, disrupt compute availability, expose virtualization-boundary secrets, read or write host physical pages, or retain host-level access on infrastructure that downstream workloads and business services depend on.

S40 — References

Vendor / Platform Documentation

·        Linux Kernel Organization - Linux Kernel Stable Tree / KVM patch references - hxxps://git[.]kernel[.]org/stable/

·        Linux Kernel Documentation - KVM - hxxps://docs[.]kernel[.]org/virt/kvm/

·        QEMU Project - QEMU Documentation - hxxps://www[.]qemu[.]org/docs/master/

·        Libvirt Project - Libvirt Documentation - hxxps://libvirt[.]org/docs.html

Vulnerability and Public Advisory Sources

·        NVD - CVE-2026-53359 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-53359

·        NVD - CVE-2026-46316 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-46316

·        NVD - CVE-2026-46113 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-46113

·        NVD - CVE-2026-23401 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-23401

·        NVD - CVE-2023-4155 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2023-4155

·        NVD - CVE-2021-3653 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2021-3653

·        NVD - CVE-2021-3656 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2021-3656

·        NVD - CVE-2021-4093 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2021-4093

·        NVD - CVE-2025-40300 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2025-40300

·        NVD - CVE-2026-31591 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-31591

·        NVD - CVE-2026-31593 - hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-31593

·        Openwall oss-security - Januscape / CVE-2026-53359 KVM x86 guest-to-host escape disclosure thread - hxxps://www[.]openwall[.]com/lists/oss-security/2026/07/06/7

·        GitHub - V4bel / Januscape - hxxps://github[.]com/V4bel/Januscape

·        GitHub - V4bel / ITScape - hxxps://github[.]com/V4bel/ITScape

·        GitHub - comsec-group / VMScape - hxxps://github[.]com/comsec-group/vmscape

Threat Technique Framework

·        MITRE ATT&CK - hxxps://attack[.]mitre[.]org/

·        CISA Known Exploited Vulnerabilities Catalog - hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog