Когда пентестер исследует скомпрометированный хост, он привычно смотрит в Ring 0 - проверяет драйверы ядра, ищет хуки в SSDT, анализирует загрузочные записи. Всё по методичке. Но есть класс угроз, при котором всё перечисленное бесполезно. Гипервизорный руткит работает на уровне Ring -1 - буквально ниже ядра операционной системы. Он не модифицирует код ядра, не перехватывает системные вызовы привычным способом. Он перемещает всю ОС в виртуальную машину и контролирует каждый её аппаратный вызов. Ядро при этом продолжает считать себя хозяином системы. Как тот охранник, который не знает, что камеры показывают ему запись вчерашнего дня.
По данным Positive Technologies, руткиты составляют менее 1% от общего числа обнаруживаемых вредоносных программ, но каждый выявленный случай связан с громкими таргетированными атаками. Виртуализационные руткиты - ещё более редкий и сложный подвид, для которого русскоязычные источники не дают практически никакой технической детализации. Здесь я разберу архитектуру гипервизорных руткитов от EPT-уровня до конкретных команд детекции, которые можно применить в реальном engagement.
Архитектура Ring -1 и виртуализационный руткит
Чтобы понять, почему гипервизорный руткит настолько опасен, стоит разобраться в иерархии привилегий x86. Классическая модель защиты Intel - четыре кольца: Ring 3 для пользовательских приложений, Ring 0 для ядра ОС. Когда Intel и AMD внедрили аппаратную виртуализацию (Intel VT-x и AMD-V соответственно), появился новый режим работы процессора, неформально названный Ring -1. Джоанна Рутковска, создатель Blue Pill, ввела этот термин специально - чтобы подчеркнуть: гипервизор обладает бо́льшими привилегиями, чем ядро ОС в Ring 0.Технически Ring -1 реализован через два режима:
- VMX Root Mode (Intel) / Host Mode (AMD) - режим гипервизора (VMM). Полный контроль над аппаратурой.
- VMX Non-Root Mode / Guest Mode - режим гостевой ОС. Определённые инструкции вызывают VM-exit, передавая управление гипервизору.
Как Intel VT-x и AMD-V создают поверхность атаки
Аппаратная виртуализация проектировалась для легитимных целей - запуска нескольких ОС, изоляции нагрузок. Но те же механизмы дают атакующему контроль, о котором kernel-mode руткиты могли только мечтать:VMCS (Virtual Machine Control Structure) - структура данных, определяющая поведение VM-exit/VM-entry. Кто контролирует VMCS - контролирует всё.
EPT (Extended Page Tables) / NPT (Nested Page Tables) - второй уровень трансляции адресов. Гипервизор определяет, какие физические страницы памяти доступны гостю и с какими правами. Через это можно создавать невидимые «теневые» страницы.
MSR Bitmap - определяет, какие обращения к Model-Specific Registers вызывают VM-exit. Гипервизорный руткит может перехватывать запись в IA32_LSTAR (адрес syscall-обработчика) без ведома ОС.
Фундаментальная проблема аппаратной виртуализации с точки зрения безопасности - процессор не предоставляет гостевой ОС инструкции для проверки собственного статуса. Нет такого
AMIVIRTUALIZED в ISA. Эта асимметрия - фундамент всех VM-based rootkit техник.Blue Pill атака виртуализация: от концепта к архитектуре VMBR
Blue Pill - proof-of-concept, представленный Джоанной Рутковской в 2006 году на Black Hat USA. Идея простая и элегантная: вредоносный код на лету перемещает работающую ОС в виртуальную машину, создавая «тонкий» гипервизор между аппаратурой и ядром. Название отсылает к «Матрице» - приняв синюю таблетку, вы остаётесь в иллюзии, не зная, что реальность подменена.Архитектура Blue Pill и подобных VMBR (Virtual Machine Based Rootkit) работает так:
- Инициализация VMX - руткит выполняет
VMXON, активируя режим VMX Root. - Конфигурация VMCS - настраиваются Guest State Area (текущее состояние ОС) и Host State Area (точка входа в гипервизор при VM-exit).
- Настройка VM-Execution Controls - определяется, какие события вызывают VM-exit: CPUID, RDMSR/WRMSR, обращения к CR-регистрам, I/O-порты.
- VMLAUNCH - ОС «просыпается» в Non-Root Mode, не замечая перехода. Все регистры, память, таблицы страниц - идентичны состоянию до виртуализации.
EPT и shadow pages: VM-based rootkit техники невидимого перехвата
Современные реализации гипервизорных руткитов активно используют Extended Page Tables для создания «теневых» (shadow) страниц памяти. По исследованию secret.club (июнь 2025), посвящённому Rust-based гипервизорам illusion-rs и matrix-rs, механизм EPT-hooking позволяет перенаправлять поток исполнения без модификации гостевой памяти. Вдумайтесь - перехват без патчинга.Как это работает:
- Гипервизор находит целевую страницу памяти (например, содержащую
NtCreateFile). - Создаётся дубликат - shadow page. В дубликат внедряется trampoline.
- В EPT настраиваются раздельные права: оригинальная страница получает Read/Write, а shadow page - Execute-Only.
- Когда гость читает память (например, PatchGuard проверяет целостность), он видит оригинальный, чистый код. Но при исполнении процессор через EPT-трансляцию использует shadow page с перехватчиком.
Проект illusion-rs использует модель с одним EPT на логический процессор и VMCALL + Monitor Trap Flag (MTF) для single-stepping. Проект matrix-rs идёт дальше - dual-EPT: primary EPT для чтения/записи и secondary EPT для исполнения, с динамическим переключением EPTP при нарушениях доступа. Оба проекта - открытый исходный код. EPT-hooking перестал быть академической экзотикой.
Nested virtualization exploit и атаки на легитимный гипервизор
Отдельный вектор - злоупотребление вложенной виртуализацией. Если на хосте уже крутится легитимный гипервизор (VMware ESXi, Hyper-V, KVM), атакующий может «bluepill'нуть» сам гипервизор, создав дополнительный уровень перехвата.Рутковска подчеркнула: «Поддержка вложенной виртуализации - можно загрузить Blue Pill, а затем внутри созданной виртуальной машины запустить обычный гипервизор вроде Xen или Virtual PC. Можно даже загрузить несколько экземпляров Blue Pill друг в друга». Матрёшка из гипервизоров. И вот тут возникает принципиальная проблема: детектирование виртуализации и детектирование скомпрометированного гипервизора - две совершенно разных задачи.
В лабораторных условиях при работе с nested virtualization я анализировал следующие артефакты:
Shadow VMCS - при вложенной виртуализации легитимный гипервизор L1 управляет VMCS для гостей L2. Вредоносный гипервизор L0 (Blue Pill) должен поддерживать shadow-копии этих VMCS. Аномалии в обработке VMREAD/VMWRITE могут быть индикатором.
EPT-over-EPT - при nested virtualization адреса транслируются через несколько уровней EPT. Каждый дополнительный уровень вносит измеримую задержку в обращения к памяти.
VM-exit latency - при наличии промежуточного гипервизора каждый VM-exit проходит через дополнительный уровень обработки. Этот overhead можно измерить, хотя задача нетривиальная.
Таблица уровней вложенности и их влияния:
| Уровень | Исполнитель | VM-exit latency | Контроль EPT |
|---|---|---|---|
| L0 (вредоносный Blue Pill) | Аппаратура напрямую | Базовая | Полный |
| L1 (легитимный гипервизор) | Под контролем L0 | Увеличенная | Виртуализированный |
| L2 (гостевая ОС) | Под контролем L1 + L0 | Значительно увеличенная | Отсутствует |
Почему EDR и антивирусы слепы к гипервизор безопасность атаки
Вопрос, который я слышу на каждом engagement: «Но у нас стоит EDR класса X, он ведь увидит?». Короткий ответ - нет. Длинный - тоже нет, но с объяснением.Любое программное средство защиты работает внутри ОС - в Ring 3 или Ring 0. Гипервизорный руткит сидит в Ring -1. Это означает:
Сканирование памяти бесполезно. EDR читает физическую память через API ядра. Но трансляция физических адресов проходит через EPT, контролируемый руткитом. Руткит подставляет «чистые» страницы при чтении, показывая shadow page с hook только при исполнении. Классический split-view.
Мониторинг системных вызовов перехвачен. Если руткит ставит перехватчик на IA32_LSTAR MSR (как описано в исследовании secret.club для illusion-rs), все syscall проходят через его обработчик до попадания в ядро. EDR видит уже отфильтрованный поток.
Проверка целостности ядра обманута. PatchGuard проверяет код ядра через обычные операции чтения памяти. EPT-based hooking возвращает оригинальный код при чтении и подставляет модифицированный при исполнении. PatchGuard видит неизменённый код и молчит.
Hardware Performance Counters - частично. Теоретически PMC могут обнаружить аномальное количество VM-exit. Руткит может перехватывать доступ к PMC MSR (IA32_PERFEVTSELx, IA32_PMCx) и корректировать возвращаемые значения. Но PMC инкрементируются аппаратно, и полная фальсификация всех счётчиков одновременно - нерешённая задача. Исследование NumChecker (2013) показало, что определённые PMC-паттерны сложно подделать без детектируемых побочных эффектов. Это одна из немногих зацепок.
По классификации MITRE ATT&CK гипервизорные руткиты попадают под несколько техник:
Ссылка скрыта от гостей
как базовая категория, Run Virtual Instance (T1564.006, Defense Evasion) - собственно механизм перемещения ОС в VM, и Disable or Modify Tools (T1562.001, Defense Evasion), поскольку руткит фактически нейтрализует все инструменты мониторинга уровня ОС.Обнаружение руткита гипервизора: практические техники для пентестеров
Теперь главное - как обнаружить subverted hypervisor. Сразу скажу: идеального метода не существует. Рутковска называла timing-based detection «слепым переулком» (blind avenue) для полноценного решения. Но в реальном engagement комбинация нескольких подходов даёт рабочие результаты. Лично я использую четыре, и ниже - каждый из них.Timing-based detection: RDTSC и CPUID fingerprinting
Каждый VM-exit добавляет задержку. Инструкции CPUID и RDMSR гарантированно вызывают VM-exit в среде с гипервизором. Измеряя время их выполнения через RDTSC, можно поймать аномалию.Базовый замер через inline assembly:
Код:
; Замер латентности CPUID через RDTSC
; На bare-metal CPUID занимает ~100-200 циклов
; При наличии гипервизора: 1000-5000+ циклов из-за VM-exit
lfence ; Сериализация - гарантирует завершение предыдущих инструкций
rdtsc ; Читаем TSC (младшие 32 бита в EAX)
mov esi, eax ; Сохраняем начальное значение
xor eax, eax ; EAX = 0 (CPUID leaf 0)
cpuid ; Вызывает VM-exit при активном гипервизоре
rdtscp ; Читаем TSC с сериализацией (предпочтительнее RDTSC)
sub eax, esi ; EAX = разница циклов
; Если EAX > порогового значения - подозрение на гипервизор
; Примечание: LFENCE перед первым RDTSC и RDTSCP в конце необходимы
; для предотвращения переупорядочивания инструкций (out-of-order execution)- Руткит может перехватывать RDTSC. В VMCS есть бит RDTSC exiting (бит 12 Primary Processor-Based Controls), вызывающий VM-exit при каждом RDTSC/RDTSCP, и механизм TSC offsetting (бит 3), позволяющий прозрачно корректировать значение TSC без VM-exit. Но TSC offsetting добавляет лишь фиксированное смещение и не может динамически компенсировать переменную латентность каждого VM-exit. Для точной компенсации руткит должен использовать RDTSC exiting с динамическим расчётом - что само по себе добавляет overhead и потенциально детектируемо через статистический анализ дисперсии.
- Шум от легитимных процессов. Прерывания, переключение контекста, кэш-промахи - всё вносит погрешность.
- Нужна baseline. Вы должны знать «нормальную» латентность CPUID на конкретном CPU без гипервизора.
Анализ аппаратная виртуализация уязвимости через артефакты VMCS
Второй подход - поиск артефактов, которые гипервизор не может полностью скрыть.CPUID Hypervisor Bit. Leaf 0x1 регистра ECX, бит 31 (Hypervisor Present) - устанавливается спецификацией для сигнализации работы в виртуальной среде. Легитимные гипервизоры его ставят. Руткит может сбросить через перехват CPUID, но тогда при nested virtualization возникнут конфликты - легитимный вложенный гипервизор не сможет корректно работать.
C:
// Проверка Hypervisor Present Bit (пример для демонстрации концепции)
#include <cpuid.h>
int check_hypervisor_bit(void) {
unsigned int eax, ebx, ecx, edx;
__cpuid(1, eax, ebx, ecx, edx);
return (ecx >> 31) & 1; // Бит 31 ECX
}
// Если 1 - гипервизор присутствует
// Если 0, но timing-анализ показывает VM-exit latency - подозрение на cloakingIntel VT-x AMD-V rootkit: детектирование через аппаратные механизмы
Intel TXT (Trusted Execution Technology) - аппаратный механизм, который теоретически гарантирует целостность загрузочной цепочки, включая гипервизор. Рутковска, однако, продемонстрировала обход Intel TXT на Black Hat DC - так что как единственный метод защиты он ненадёжен.SMM (System Management Mode) - Ring -2, ещё более привилегированный режим. SMM-обработчик теоретически может инспектировать состояние VMX и обнаружить несанкционированный гипервизор. На практике это требует модификации прошивки (UEFI/BIOS) и редко доступно пентестеру. Но знать о нём стоит.
Firmware-based attestation - использование TPM для хэширования цепочки загрузки. Если гипервизорный руткит внедрился после начального замера, TPM PCR будут содержать корректные значения. Если до - хэши не совпадут при удалённой аттестации.
Пошаговая детекция subverted hypervisor detection для пентестеров
Ниже - алгоритм, который я применяю при подозрении на компрометацию гипервизора в ходе red team engagement.Шаг 1. Статистический timing-анализ
Выполните серию из 10000+ замеров латентности CPUID с разными leaf и постройте гистограмму. На bare-metal - узкое нормальное распределение. При наличии гипервизора - бимодальное (быстрые вызовы кэшированных leaf и медленные с полным VM-exit).
Python:
# Пример скрипта для анализа результатов timing-замеров
# Данные собираются отдельным драйвером/утилитой, которая выполняет RDTSC+CPUID+RDTSC
# Инструменты сбора: HyperCheck (NIST, github.com/nist/hypercheck), кастомный драйвер
# Формат входных данных: текстовый файл, одно значение (циклы TSC) на строку
# Минимальный C-код сбора замеров (компилировать: gcc -O0 -o tsc_cpuid tsc_cpuid.c):
# #include <stdio.h>
# #include <stdint.h>
# int main() {
# for (int i = 0; i < 10000; i++) {
# uint32_t lo1, lo2;
# asm volatile("lfence; rdtsc" : "=a"(lo1) :: "edx");
# asm volatile("cpuid" ::: "eax","ebx","ecx","edx");
# asm volatile("rdtscp" : "=a"(lo2) :: "ecx","edx");
# printf("%u\n", lo2 - lo1);
# }
# }
# Пример для демонстрации концепции анализа
import numpy as np
def analyze_timing(measurements):
"""Анализ распределения латентности CPUID."""
mean = np.mean(measurements)
std = np.std(measurements)
# На bare-metal типичная латентность CPUID: 100-300 циклов
# При гипервизоре: 1000-5000 циклов
BARE_METAL_THRESHOLD = 500
above_threshold = sum(1 for m in measurements if m > BARE_METAL_THRESHOLD)
ratio = above_threshold / len(measurements)
print(f"Mean: {mean:.0f} cycles, StdDev: {std:.0f}")
print(f"Samples above threshold: {ratio*100:.1f}%")
if ratio > 0.5:
print("[ALERT] Hypervisor presence likely")
elif ratio > 0.1:
print("[WARN] Anomalous timing distribution")
else:
print("[OK] Consistent with bare-metal")Проверьте согласованность CPUID leaf между собой. Запросите leaf 0x0 (Vendor ID), 0x1 (Feature Information с Hypervisor bit), 0x40000000 (Hypervisor Vendor), 0x40000001-0x40000010 (Hypervisor-specific). Несогласованность - например, Hypervisor bit сброшен, но leaf 0x40000000 возвращает валидный vendor string - указывает на неполный cloaking.
Bash:
# На Linux - cpuid utility
cpuid -l 0x1 | grep hypervisor
cpuid -l 0x40000000
cpuid -l 0x40000001
# Сравните с известными сигнатурами:
# "KVMKVMKVM\0\0\0" - KVM
# "Microsoft Hv" - Hyper-V
# "VMwareVMware" - VMware
# Неизвестная или пустая строка при наличии hypervisor bit - подозрительноЕсли есть возможность снять дамп физической памяти (через PCILeech с Thunderbolt/USB3380/FPGA, inception через FireWire/Thunderbolt, или LiME для Linux - с оговоркой, что LiME работает из гостя и может быть обманут EPT), ищите артефакты гипервизора:
Bash:
# Поиск VMCS-структур в памяти
# VMCS revision identifier специфичен для модели CPU и читается из IA32_VMX_BASIC MSR (0x480)
# Сначала определите revision ID целевого процессора, затем сканируйте 4KB-aligned страницы
# Пример: для Haswell revision ID = 0x11, для Skylake/Kaby Lake = 0x1F
# YARA-правило для сканирования VMCS revision ID на 4KB-aligned страницах
# ВАЖНО: revision ID зависит от модели CPU (например, 0x11 для Haswell, 0x1F для Skylake)
# Предварительно прочитайте IA32_VMX_BASIC MSR (0x480) на идентичном CPU без гипервизора
# Volatility 2 (legacy):
volatility -f memory.dump --profile=Win10x64 yarascan \
--yara-rules="rule vmcs_scan { strings: \$rev = { 1F 00 00 00 } condition: \$rev }"
# Результаты фильтруйте вручную по 4KB-alignment (адрес % 4096 == 0)
# Для точной фильтрации используйте внешний YARA-скан по raw-дампу:
# yara -s vmcs.yar memory.dump
# где vmcs.yar содержит:
# rule vmcs_scan { strings: $rev = { 1F 00 00 00 } condition: for any i in (1..#rev) : (@rev[i] % 4096 == 0) }
#
# Volatility 3 (рекомендуется в 2025):
# vol -f memory.dump windows.yarascan.YaraScan --yara-rules "rule vmcs_scan { strings: \$rev = { 1F 00 00 00 } condition: \$rev }"
# ВАЖНО: revision ID (здесь 0x1F) зависит от модели и stepping CPU - всегда сверяйте с IA32_VMX_BASIC на reference-системе
# Поиск VMXON-регионов
# Каждый логический процессор с активным VMX имеет VMXON region
# Volatility 3 (рекомендуется):
vol -f memory.dump windows.volshell.Volshell
# В volshell: сканирование физической памяти на характерные паттерны
# Volatility 2 (legacy, не рекомендуется для новых проектов):
# volatility -f memory.dump --profile=Win10x64 volshellПри физическом доступе подключите kernel debugger через serial/USB/network. Если хост bluepill'нут, debugger подключается к гостевой ОС внутри VM. Но определённые команды могут выявить несоответствия:
Код:
kd> rdmsr 0x3A ; IA32_FEATURE_CONTROL - проверка MSR Lock Bit
kd> rdmsr 0x480 ; IA32_VMX_BASIC - revision и размер VMCS
kd> rdmsr 0x48B ; IA32_VMX_PROCBASED_CTLS2 - доступные secondary controls
; Сравните значения MSR с документацией Intel для данного CPU
; Аномалии в доступных битах могут указывать на виртуализацию MSRМаппинг гипервизорных руткитов на MITRE ATT&CK
Для документирования находок при пентесте - маппинг на MITRE ATT&CK:| Техника ATT&CK | ID | Тактика | Применение к гипервизорным руткитам |
|---|---|---|---|
| Rootkit | T1014 | Defense Evasion | Базовая категория - сокрытие присутствия на уровне VMM |
|
Ссылка скрыта от гостей
| T1564.006 | Defense Evasion | Непосредственно Blue Pill - перемещение ОС в VM |
| System Checks | T1497.001 | Defense Evasion, Discovery | Pre-installation check: руткит проверяет наличие существующего гипервизора перед VMXON. Вспомогательная техника, не основной механизм атаки |
| Exploitation for Privilege Escalation | T1068 | Privilege Escalation | Эксплуатация уязвимостей для получения привилегий Ring -1 |
| Disable or Modify Tools | T1562.001 | Defense Evasion | Нейтрализация EDR/AV через EPT-манипуляции |
| Native API | T1106 | Execution | Использование нативных API ОС (например, NtSetSystemInformation) для загрузки драйвера-установщика гипервизора. Сами VMX-инструкции (VMXON, VMLAUNCH) - не OS API и не покрываются T1106 напрямую |
T1564.006 (Run Virtual Instance) - наиболее точное описание Blue Pill-атаки в терминологии ATT&CK. Примечательно, что эта техника относительно свежая во фреймворке, и далеко не все SOC-команды включают её в мониторинг. Если вы в blue team - проверьте.
Bare-metal hypervisor security: перспективы защиты
Рутковска в 2009 году сказала: «Я не верю, что мы увидим Blue Pill-подобное вредоносное ПО в дикой природе в ближайшее время, потому что обычное вредоносное ПО уровня ядра работает достаточно хорошо. Индустрия антивирусов не справляется даже с обнаружением этого класса угроз». Прошло 15+ лет - прогноз в целом подтвердился. Массового применения гипервизорных руткитов нет. Но в таргетированных атаках APT-группировок, которые, по данным Positive Technologies, обладают «достаточной технической квалификацией и финансовыми возможностями», этот вектор нельзя сбрасывать со счетов.Hyper-V's Virtual Secure Mode (VSM),
Ссылка скрыта от гостей
,
Ссылка скрыта от гостей
- всё это поднимает планку для атакующего. Но не устраняет фундаментальную проблему. Если атакующий получает контроль на уровне прошивки (UEFI rootkit), он может внедрить гипервизор до инициализации любых защитных механизмов. Именно поэтому Secure Boot с корректно настроенной цепочкой доверия и аппаратная аттестация через TPM остаются ключевыми элементами обороны от transparent malware virtualization.Заключение
Гипервизорный руткит - не теоретическая страшилка из академических статей. Это рабочий класс атак с публично доступными PoC - от оригинального Blue Pill до современных Rust-based гипервизоров illusion-rs и matrix-rs, демонстрирующих EPT-hooking без модификации гостевой памяти.Для пентестера главный вывод прост: если вы ограничиваете анализ уровнем ядра, вы по определению не видите Ring -1. Обнаружение руткита гипервизора требует комбинации timing-анализа, CPUID fingerprinting, анализа физической памяти и (в идеале) аппаратных средств аттестации. Ни один метод не достаточен сам по себе, но вместе они дают рабочую методологию для выявления VMM компрометации.
Начните с малого: включите проверку CPUID Hypervisor Bit и timing-анализ CPUID латентности в стандартный чеклист при исследовании скомпрометированных хостов. Если числа не сходятся - копайте в Ring -1.
