SLAT-based hooks are nasty because the guest OS can be clean and wrong at the same time. The attacker runs a small hypervisor under the OS and controls memory translation through Second Level Address Translation (SLAT): Extended Page Tables (EPT) on Intel, Nested Page Tables (NPT) on AMD. Guest page tables still look normal. A scanner reads clean bytes. Execution can still land on a different physical page.
I wanted this written down in the same way I would debug it: what the hook changes, what it cannot hide cheaply, and which signals are worth collecting before you trust a detection result.
The Split-View Hook
In a normal system, the OS sets up page tables that translate virtual addresses to physical addresses. With hardware-assisted virtualization, a second layer is added: the hypervisor maintains EPT/NPT tables that translate Guest Physical Addresses to the final System Physical Addresses. Those tables enforce read, write, and execute permissions independently of what the guest thinks.
Intel EPT supports execute-only pages. A page can execute but cannot be read. That is enough to build a split-view hook. The attacker clones a target code page, puts a hook in the clone, and configures EPT so that:
- Execution accesses resolve to the shadow page containing the hook (marked X=1, R=0, W=0).
- Read and write accesses by the guest, or by security software, hit an EPT violation. The hypervisor catches the trap, temporarily points the GPA entry back to the original page, services the read/write, and then restores the execute-only mapping to the shadow page.
The result is simple and annoying: memory reads return the original bytes, while instruction fetches go somewhere else. The attacker never has to edit guest-visible page tables.
Gaining Control Without Constant Exits: View Switching
If every execution of a hooked page required a VM-exit, the timing would stand out. Modern implants avoid that by using multiple EPT pointers. Intel VMCS can hold multiple EPT base addresses (EPTPs), and Xen altp2m allows up to 512 memory views per guest. Switching views can be as cheap as changing the EPTP index, with no page table rebuild and often no VM-exit when VMFUNC is available.
A rootkit can maintain:
- A vanilla view for normal operation.
- A hooked view where certain pages point to shadow code.
- A hidden view where the attacker module is removed from enumeration.
When a privileged event occurs, such as a system call, the hypervisor flips the view, runs the hook, and flips back before normal scanners read the page. The visible window is short and the cost is lower than repeated EPT-violation traps.
What The Hook Tries To Hide
The implant also has to hide the hypervisor itself. Most of the work is boring consistency work: clocks need to look right, MSRs need to agree with CPUID, and TLB behavior cannot be too noisy.
TSC Spoofing
The classic tell is CPUID taking hundreds more cycles than it should because it causes a VM-exit. A stealthy hypervisor intercepts the Time Stamp Counter (TSC) and subtracts its own overhead before returning to the guest. Implants like Ophion go further: they trap the next RDTSC after a monitored exit and return a value close to native latency. Simple before/after timing checks stop being useful.
MSR Masking
Many Model-Specific Registers betray virtualization. IA32_FEATURE_CONTROL, which locks VMX, can be spoofed to report VMX disabled. Access to Hyper-V or KVM synthetic MSR ranges (0x40000000+) can be answered with a #GP fault to avoid fingerprinting. If CPUID says VMX is unsupported, the MSRs have to tell the same story.
TLB Management
Using VPIDs on Intel or ASIDs on AMD, the hypervisor tags TLB entries so guest and host mappings can coexist without flushes on every transition. A careful implant avoids global INVEPT/INVVPID flushes that would produce measurable latency spikes. It uses selective invalidations only when it has to.
What Actually Works for Detection
Once the guest view is curated, detection has to look for side effects. No single signal is enough. I would rather have three mediocre signals that agree than one clean signal that is easy to spoof.
Statistical Timing Analysis
Even with TSC compensation, the hypervisor dispatch path adds jitter. Instruction Execution Time (IET) is more useful as a distribution than as one number. The mean can be cleaned up; variance, kurtosis, and spectral width are harder to fake. Periodic outliers are more interesting than isolated spikes.
TLB and Translation Profiling
Forced permission flips or view switches leave footprints in TLB behavior. A probe can alternate read and execute on the same page. A split-view hook often toggles the backing page, producing abnormal ITLB misses or delayed translations. TLB-related performance counters, such as ITLB misses and page-walk cycles, are useful here.
Cross-View Comparison (VMI)
When the detector runs at the hypervisor level or below it, it can reconstruct the guest state and compare it with what the guest reports. Hidden processes, altered syscall tables, and mismatched module lists show up because the observer is outside the guest abstraction the attacker is shaping.
Hardware Performance Counters (PMU)
Counters for L3 cache misses, ITLB flushes, and branch mispredictions can expose stolen cycles and extra translation pressure. A spike in PMI interrupts around sensitive kernel paths is suspicious. Hypervisors can virtualize some counters, so I treat PMU data as corroboration, not proof by itself.
Cache and Speculative-Execution Side Channels
The Return Stack Buffer technique Hyper-channel populates the RSB, forces a VM-exit, then times a sequence of RETs. RSB pollution by the hypervisor exit handler creates a measurable miss penalty. Cache contention probes can also reveal the hypervisor memory footprint. Speculative execution bugs cut both ways: mitigations like L1 cache flushes on VM-entry add latency, while weak boundaries can leak data from the hypervisor itself.
Below-Hypervisor Introspection (SMM, DMA)
The strongest checks sit below the hypervisor. System Management Mode (SMM) can assert an SMI and verify EPT structures or hypervisor code. PCIe forensic cards with DMA access can read physical memory out of band. These are not endpoint-friendly techniques, but they make the trust boundary much cleaner.
| Detection Layer | Signal | Counter-Stealth |
|---|---|---|
| Guest timing probes | Increased variance, spectral broadening | TSC compensation, selective hook placement |
| TLB/PMU profiling | Abnormal ITLB flushes, L3 miss spikes | Tagged TLB, minimal invalidation |
| Cross-view (VMI) | Hidden processes, module mismatch | Keep state outside guest abstractions |
| SMM / DMA | Direct memory comparison | Must compromise firmware |
Lessons from the Wild: SubVirt, Blue Pill, HyperLeech, Ophion
SubVirt (2006) showed why a VM-based rootkit changes the evidence model: the rootkit state can live outside the guest. Blue Pill pushed the idea of live migration into a malicious hypervisor. HyperLeech (2020) added DMA-based injection and cleanup, which brings PCIe and IOMMU telemetry into scope. Ophion is a useful modern reference because it combines firmware-locked MSR masks, identity-mapped large-page EPT, and TSC handling to reduce obvious timing artifacts.
Practical Detection Strategy
SLAT hooks are a telemetry problem, not a signature problem. My order of preference:
- Immutable boot chain and firmware attestation: make sure the platform has not been subverted below the OS.
- Host-side hypervisor provenance: if you control the host, watch for unauthorized VMX root transitions.
- Guest-side statistical timing probes: use independent clocks, such as HPET and thread racing, and compare distributions against a local baseline.
- Selective page-local probes: alternate small read and execute loops on protected modules, then watch TLB and cache side effects.
- PMU/HPC as supporting evidence: flag unusual counts but do not treat them as standalone proof.
- Confidential computing features: SEV-SNP and Intel TDX restrict malicious remapping and improve attestation, which closes off many of these hooks by design.
False positives matter. Hyper-V, VBS, and legitimate memory introspection frameworks use the same primitives. The signals I care about are behavioral: unexplained read/execute asymmetry on production code pages, TLB churn around security-sensitive paths, PMU interrupt patterns that do not match the local baseline, or below-host measurements that contradict guest-reported memory.
Where I Land
SLAT-based hooks move the interesting state below the OS. That does not make them magic. They still burn cycles, touch caches, pressure TLBs, and sometimes leak inconsistencies between read and execute paths.
If I were building a detector, I would start small: one page-local read/execute probe, one timing distribution, one PMU signal, and one host or firmware sanity check where available. Then I would tune against real Hyper-V/VBS systems before calling anything malicious.