safemode.space
← All techniques
LM-0005
ST0007Lateral Movement

Virtualization Escape

Description

The adversary pivots across partitions by abusing the mechanisms a separation kernel or hypervisor exposes for inter-partition communication and device sharing. Paths include message ports/queues, shared-memory windows, virtual NICs and bridges, hypercalls, and common driver backends (e.g., storage or DMA engines without strict IOMMU bounds). A foothold in a less-trusted partition, often a payload or guest OS, can be turned into access to a higher-privilege domain by crafting traffic that exploits parser flaws in port services, racing management channels, or coercing backend drivers to perform out-of-bounds operations. Once the boundary is crossed, the actor can reach bus gateways, file systems, or control applications hosted in adjacent partitions and continue movement under the guise of permitted inter-partition exchanges.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(j)
    addresses
    high
    direct

    Inter-partition communication channels (message ports, shared memory, virtual NICs, hypercalls) ARE the attack surface (2)(j)'s obligation requires the product to limit and harden.

  • craAnnex I, Part I, (2)(k)
    addresses
    high
    direct

    Hypervisor-escape via parser flaws or driver out-of-bounds is the canonical exploitation scenario (2)(k)'s exploitation-mitigation obligation (IOMMU, capability checks, hardened parsers) is meant to reduce the impact of.

  • craAnnex I, Part II, (3)
    addresses
    moderate
    direct

    Effective and regular tests of separation-kernel/hypervisor boundaries (fuzzing of message ports, IOMMU validation) is the (Part II, 3) obligation manufacturers must apply for products relying on virtualization separation.

  • eu-space-actArt. 76(6)
    addresses
    moderate
    direct

    Hypervisor-escape testing (primary: Art. 88(1)) — separation-kernel boundary fuzzing — is reviewed under 76(6)'s effectiveness-assessment-policy.

  • eu-space-actArt. 84(2)
    addresses
    moderate
    direct

    Hypervisor escape attacks the integrity boundary 84(2)'s Annex VII point 5.1 requires for separation kernels and partitioned environments.

  • eu-space-actArt. 88(1)
    addresses
    moderate
    direct

    Hypervisor/separation-kernel boundary testing — fuzzing of message ports, IOMMU validation — is within 88(1)'s testing programme scope.

  • eu-space-actArt. 88(3)
    addresses
    moderate
    direct

    Hypervisor-escape testing (primary: Art. 88(1)) cascades to 88(3) — TLPT 3-yearly cadence covers separation-kernel boundary fuzzing on operator products.

  • nis2Art. 21(2)(e)
    addresses
    high
    direct

    Separation kernels, hypervisors, virtual NICs, IPC port services, and shared driver backends with IOMMU bounds are squarely within Art. 21(2)(e)'s network-and-information-systems acquisition/development/maintenance and vulnerability-handling obligation — including disclosed parser flaws and racing-management-channel weaknesses.

  • nis2Art. 21(2)(i)
    addresses
    moderate
    direct

    Inter-partition communication ports, shared-memory windows, hypercalls, and DMA-engine permissions are access-controlled isolation boundaries; Art. 21(2)(i)'s access-control + asset-management obligation governs which partitions can invoke which inter-partition mechanisms.

  • nis2-implAnnex 6.10.1
    addresses
    high
    derived

    Vulnerability-handling-and-disclosure procedures must apply to hypervisor and separation-kernel defects; coordinated remediation is the procedural mechanism that closes virtualization-escape paths once disclosed.

  • nis2-implAnnex 6.2.1
    addresses
    moderate
    derived

    Separation kernels and hypervisors are produced through the secure-development life cycle; the rules for that lifecycle govern the implementation quality of inter-partition communication, shared-memory windows and device-emulation paths that virtualization escape exploits.

  • nis2-implAnnex 6.6.1
    addresses
    moderate
    derived

    Security-patch management procedures determine how quickly hypervisor defects are deployed in flight or ground systems; deployment cadence bounds the exploit window for disclosed escape paths.

ENISA controls

  • ENISA-STL-2025-03-sD.21-i02
    mitigates
    moderate

    Coding standards including safe memory access reduce parser-flaw and out-of-bounds-write defects in port services and management channels.

  • ENISA-STL-2025-03-sD.21-i03
    addresses
    moderate

    A documented secure development lifecycle covers separation-kernel and hypervisor design including IOMMU-bounded driver backends and hardened message-port services.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, LM-0005 (SPARTA v3.2).

Built 2026-07-25 from 216 techniques, 334 regulation articles, 125 ENISA controls, 2,610 framework controls, and 90 countermeasures.