ANTICHAT - Гипервизорный руткит обнаружение: Blue Pill, EPT-abuse и практические техники детекции subverted hypervisor

https://forum.antichat.xyz/attachmen...ed4c29321b.png

Когда пентестер исследует скомпрометированный хост, он привычно смотрит в 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, передавая управление гипервизору.

Виртуализационный руткит эксплуатирует именно этот механизм: он садится в VMX Root Mode, а вся операционная система - со всеми драйверами, антивирусами и EDR - оказывается в Non-Root Mode, не подозревая об этом. Любая привилегированная операция гостя - чтение MSR, доступ к CR-регистрам, выполнение CPUID - прозрачно перехватывается гипервизором через 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, не замечая перехода. Все регистры, память, таблицы страниц - идентичны состоянию до виртуализации.

Рутковска подчеркнула принципиальное отличие: «В отличие от всех предыдущих руткитов режима ядра, Blue Pill ничего не перехватывает (hook) в коде или данных ядра. Он просто сидит выше ядра и не нуждается в его модификации». Kernel-mode руткиты патчат SSDT, IDT, объекты ядра - и именно поэтому PatchGuard их ловит. Blue Pill не трогает ничего из этого.
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 с перехватчиком.

Исследование secret.club прямо говорит: подход «навигирует вокруг защит ядра вроде PatchGuard» и «сохраняет целостность системы» - гостевая ОС не обнаружит модификации при любых проверках целостности памяти.

Проект 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Контроль EPTL0 (вредоносный 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 гипервизорные руткиты попадают под несколько техник: Rootkit (T1014, Defense Evasion) как базовая категория, 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 без гипервизора.

Фишка в том, что даже при TSC offsetting руткит не может идеально компенсировать задержку для всех инструкций одновременно. Серия замеров разных инструкций (CPUID с разными leaf, RDMSR для разных MSR, INVD) с последующим статистическим анализом выявляет аномалии - отдельные инструкции показывают нехарактерное соотношение латентностей.
Анализ аппаратная виртуализация уязвимости через артефакты VMCS
Второй подход - поиск артефактов, которые гипервизор не может полностью скрыть.

CPUID Hypervisor Bit. Leaf 0x1 регистра ECX, бит 31 (Hypervisor Present) - устанавливается спецификацией для сигнализации работы в виртуальной среде. Легитимные гипервизоры его ставят. Руткит может сбросить через перехват CPUID, но тогда при nested virtualization возникнут конфликты - легитимный вложенный гипервизор не сможет корректно работать.

C:

Код:

// Проверка Hypervisor Present Bit (пример для демонстрации концепции)

#include 

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 - подозрение на cloaking

CPUID Leaf 0x40000000. Стандарт гипервизоров (Hyper-V Interface, VMware backdoor) определяет информационные листы начиная с 0x40000000. Руткит, маскирующийся под отсутствие гипервизора, должен перехватывать все эти листы. Несогласованность ответов между разными leaf - индикатор. На практике именно на этом и палятся: один leaf перехвачен, соседний - забыли.
Intel 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 

#   #include 

#   int main() {

#       for (int i = 0; i 

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"

)

Шаг 2. CPUID enumeration с перекрёстной проверкой

Проверьте согласованность 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 - подозрительно

Шаг 3. Анализ памяти через Volatility

Если есть возможность снять дамп физической памяти (через 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

Шаг 4. WinDbg kernel debugging через вторичный канал

При физическом доступе подключите 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&CKIDТактикаПрименение к гипервизорным руткитамRootkitT1014Defense EvasionБазовая категория - сокрытие присутствия на уровне VMMRun Virtual InstanceT1564.006Defense EvasionНепосредственно Blue Pill - перемещение ОС в VMSystem ChecksT1497.001Defense Evasion, DiscoveryPre-installation check: руткит проверяет наличие существующего гипервизора перед VMXON. Вспомогательная техника, не основной механизм атакиExploitation for Privilege EscalationT1068Privilege EscalationЭксплуатация уязвимостей для получения привилегий Ring -1Disable or Modify ToolsT1562.001Defense EvasionНейтрализация EDR/AV через EPT-манипуляцииNative APIT1106ExecutionИспользование нативных 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), Intel TDX (Trust Domain Extensions), AMD SEV (Secure Encrypted Virtualization) - всё это поднимает планку для атакующего. Но не устраняет фундаментальную проблему. Если атакующий получает контроль на уровне прошивки (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.