Обнаружение песочницы и VM по артефактам

По данным Red Report 2026 от Picus Security, техника T1497 Virtualization/Sandbox Evasion вернулась на четвёртую строку по частоте использования - после двух лет вне топ-10. AppSecure Security оценивает: 30–40% массового вредоносного ПО реализует хотя бы одну проверку на виртуальную среду, а у APT-группировок и операторов ransomware показатель приближается к 100%. При разборе семплов в IDA и x64dbg я вижу одну и ту же картину каждую неделю: код первым делом проверяет реестр, MAC-адрес сетевой карты и количество ядер CPU - и только потом решает, распаковывать ли основную нагрузку. Ниже - разбор конкретных артефактов, по которым малварь определяет, что работает не на станции жертвы, а внутри песочницы или виртуальной машины.

Зачем малвари обнаружение песочницы и виртуальной машины​

Когда вредонос попадает на хост, у него одна задача - решить, стоит ли разворачивать полезную нагрузку. Если среда окажется песочницей EDR-вендора или виртуалкой аналитика, раскрытие payload приведёт к сигнатуре и блокировке всей кампании. Экономика тут простая: один anti-VM модуль в 50–100 строк C-кода продлевает жизнь семпла на недели.

Малварь проводит серию системных проверок - в терминологии MITRE ATT&CK это техника T1497 Virtualization/Sandbox Evasion, тактики Defense Evasion и Discovery. При обнаружении артефактов виртуализации вредонос завершает работу, показывает фальшивую ошибку или имитирует легитимное поведение.

T1497 делится на три подтехники:


В kill chain обнаружение виртуальной машины происходит сразу после initial access - между доставкой дроппера и распаковкой основного payload. Это точка принятия решения: среда «грязная» (есть признаки виртуальной среды) - малварь сворачивается. «Чистая» - продолжает цепочку post-exploitation.

Проверка реестра на VM: ключи VMware, VirtualBox, Hyper-V​

Реестр Windows - первое место, куда смотрит практически любой anti-VM код. Гипервизоры при установке гостевых дополнений оставляют предсказуемые ключи, которые невозможно спрятать без пост-обработки образа. Это как визитная карточка, забытая на месте преступления.

По данным Unit 42 (Palo Alto Networks) и AppSecure Security, наиболее проверяемые пути:


Проверка срабатывает только при наличии гостевых дополнений. Голый образ без VMware Tools или Guest Additions этих ключей не содержит. Но большинство песочниц вендоров ставят дополнения ради shared folders и clipboard - так что ключи на месте почти всегда. Применимость: Windows XP и новее, все версии гипервизоров.

WMI-запросы как альтернатива прямому чтению реестра​

Малварь не всегда лезет в реестр напрямую - часть семплов использует WMI. Это затрудняет статический анализ: нет явных вызовов RegOpenKeyEx, вместо них - COM-взаимодействие через IWbemServices::ExecQuery. По данным ISACA, WMI-based evasion - один из самых распространённых подходов, потому что WMI использует ALPC для межпроцессного взаимодействия. Многие песочницы этот канал не перехватывают и не могут подменить возвращаемые данные. Слепое пятно, которым малварь пользуется годами.

Ключевые WMI-классы для обхода песочницы malware:

• Win32_ComputerSystem - поля Manufacturer и Model содержат строки VMware, VirtualBox, Xen, QEMU для виртуальных машин
• Win32_BIOS - поле SerialNumber или Version может содержать VBOX, VMware
• Win32_DiskDrive - Model содержит VBOX HARDDISK, VMware Virtual disk, QEMU HARDDISK
• Win32_BaseBoard - Manufacturer для VirtualBox показывает Oracle Corporation

Тест из репозитория Atomic Red Team (T1497.001, «Detect Virtualization Environment via WMI Manufacturer/Model Listing»):
Этот же скрипт полезен для проверки собственного стенда перед анализом семпла: если команда срабатывает - песочница «грязная» и вредонос её распознает.

Обнаружение MAC-адресов виртуальных машин​

Каждый сетевой адаптер имеет MAC-адрес, первые три октета которого - OUI (Organizationally Unique Identifier), привязанный к производителю. Гипервизоры используют фиксированные OUI-префиксы для виртуальных адаптеров, и малварь этим пользуется. Получает MAC через GetAdaptersInfo() или GetAdaptersAddresses() из Iphlpapi.dll и побайтово сравнивает первые три октета.


В дизассемблере эта проверка выглядит как последовательность cmp byte ptr [reg+offset] с константами OUI. В IDA или Ghidra - характерный блок из трёх-четырёх побайтовых сравнений после вызова GetAdaptersInfo. Узнаётся мгновенно, если знаешь что искать.

MAC-адрес можно сменить средствами гипервизора. В VMware Workstation - через параметр ethernet0.address в .vmx-файле, в VirtualBox - через GUI настроек адаптера. Но если песочница работает с дефолтным MAC - малварь определит её за микросекунды.

Детект VMware VirtualBox драйверов и процессов​

Помимо реестра и MAC-адресов, гипервизоры оставляют артефакты в виде запущенных процессов, загруженных драйверов и доступных устройств. Обнаружение драйверов гипервизора - один из самых надёжных индикаторов, потому что драйверы загружаются в ядро и видны через штатные API. Их не спрячешь, не сломав функциональность гостевой ОС.

Процессы-индикаторы (по данным AppSecure Security и Unit 42):


Малварь перечисляет процессы через CreateToolhelp32Snapshot() с флагом TH32CS_SNAPPROCESS, затем цикл Process32First()/Process32Next() со сравнением имени через lstrcmpiA. Банально, но работает.

Устройства: вызов CreateFileA("\\.\VBoxMiniRdrDN", ...) - если возвращается валидный хендл, устройство VirtualBox Shared Folders существует. Аналогично \\.\vmci для VMware VMCI (Virtual Machine Communication Interface) и \\.\VBoxGuest для VirtualBox.

Файловые пути: C:\Program Files\VMware\VMware Tools\, C:\Program Files\Oracle\VirtualBox Guest Additions\, C:\Windows\System32\drivers\VBoxMouse.sys, C:\Windows\System32\drivers\vmhgfs.sys. Простой вызов GetFileAttributesA на эти пути даёт ответ.

Драйверы ядра: вызов EnumDeviceDrivers() из Psapi.dll возвращает массив адресов загруженных драйверов. Далее GetDeviceDriverBaseNameA() для каждого адреса - и сравнение имён модулей с паттернами VBox[I], vm[/I], vmware*. На тестовом стенде в VMware Workstation эта проверка находит vmhgfs.sys, vmci.sys, vmxnet3.sys за доли секунды.

Hardware fingerprinting вредоносного ПО​

Hardware fingerprinting - комплекс проверок, не зависящих от гостевых дополнений. Удалили VMware Tools, сменили MAC - а аппаратные характеристики виртуальной машины всё равно выдают среду. Потому что типичная песочница - это убогий набор ресурсов, который ни один живой пользователь не потерпит.


По данным ISACA, малварь проверяет ресурсы через WMI: Win32_Processor (NumberOfCores), Win32_PhysicalMemory (Capacity), Win32_DiskDrive (Size). Пороги обычно зашиты жёстко: ядер < 2, RAM < 2 ГБ, диск < 80 ГБ - среда считается виртуальной. Два ядра и 4 гига в 2025 году - это приговор.

CPUID и аппаратные признаки виртуальной среды​

Инструкция CPUID с EAX=1 возвращает в ECX бит 31 (hypervisor present bit). Бит установлен - код работает под гипервизором. Это стандартизированное поведение Intel/AMD: на реальном железе бит сброшен. Проверка в три инструкции.

Далее CPUID с EAX=0x40000000 возвращает строку-идентификатор гипервизора в регистрах EBX:ECX:EDX:


Это одна из самых надёжных anti-VM техник - гипервизор не может скрыть hypervisor present bit без модификации обработки CPUID, а это требует кастомного гипервизора. Именно поэтому команда WildFire (Unit 42) построила собственный гипервизор с нуля: стандартные KVM/Xen/QEMU принципиально неспособны скрыть свои CPUID-артефакты. Это не маркетинг - это инженерная необходимость.

Отдельная категория - backdoor-интерфейс VMware. Малварь выполняет инструкцию in с магическим значением 0x564D5868 ('VMXh') в EAX и номером порта 0x5658 ('VX') в DX. Если код работает в VMware, гипервизор перехватывает обращение к порту и возвращает валидный ответ. На реальном железе инструкция in на этот порт генерирует исключение. По данным Unit 42, это «один из самых ранних и широко используемых механизмов» детекта VMware - ему больше 15 лет, а он по-прежнему работает.

Тайминг-атаки и anti-sandbox техники​

Тайминг-проверки (T1497.003, Time Based Checks) эксплуатируют разницу в скорости выполнения инструкций на реальном железе и в виртуальной среде. Инструкция RDTSC считывает счётчик тактов процессора - малварь выполняет её до и после критической секции кода и сравнивает дельту. На реальном железе - единицы-десятки тактов, в VM - существенно больше из-за VM-exit/VM-entry.

Второй подход - анализ точности Sleep. Песочницы перехватывают Sleep() и ускоряют таймер для сокращения времени анализа. Малварь вызывает Sleep(1000) и затем сверяет реальное время через GetTickCount() или чтение KUSER_SHARED_DATA.TickCountQuad по адресу 0x7ffe0320. Если прошло ровно 1000 мс - среда подозрительна: на реальном железе отклонение +/- 1% из-за гранулярности аппаратного таймера PIT (32.768 КГц). Ирония: песочница слишком точна - и этим себя выдаёт.

Более продвинутые семплы вообще не вызывают API таймеров, а читают тики напрямую из KUSER_SHARED_DATA - структура проецируется по адресу 0x7ffe0000 на обеих разрядностях и обходит перехваты user-mode API. Красивый трюк.

Третий вариант - стаггерированные задержки: тысячи коротких Sleep-вызовов по 1–10 мс, суммарно дающие нужную паузу. Песочница может ускорить один длинный Sleep, но тысячи микро-задержек отследить и ускорить значительно сложнее. Тест Atomic Red Team для T1497.003 («Delay execution with ping») демонстрирует аналогичный принцип, но на Linux/macOS - задержка через сетевой ping вместо системного sleep.

Обнаружение попыток детекта VM: Sigma-правила и защитные контрмеры​

Для blue team критически важно уметь ловить сами попытки проверки виртуального окружения. Если семпл на рабочей станции проверяет ключи реестра VMware или делает WMI-запрос к Win32_ComputerSystem.Manufacturer - это индикатор антиотладки и антианализа. Нормальный софт так не делает.

Sigma-правило posh_ps_detect_vm_env.yml из репозитория SigmaHQ (привязано к T1497 и T1497.001) детектирует PowerShell-скрипты, выполняющие проверку виртуального окружения. Правило срабатывает на паттерны WMI-запросов к классам виртуализации в PowerShell Script Block Logging (Event ID 4104). Для срабатывания нужно включить расширенное логирование PowerShell в GPO - без этого правило бесполезно.

D3FEND-контрмеры (по данным MITRE D3FEND для T1497):


Практические рекомендации по закалке песочницы:

Чек-лист артефактов виртуализации​

Сводная таблица для реверс-инженера, препарирующего семпл, или для blue team, настраивающей правила детектирования:


При реверсе семпла в IDA или Ghidra: если в коде обнаружились обращения к трём и более категориям из таблицы - с высокой вероятностью реализован anti-VM модуль. Для подтверждения - загрузить семпл на «чистой» VM (со сменённым MAC, без дополнений, с pocket litter) и на «грязной» дефолтной. Разница в поведении подтвердит evasion-логику. Я так делаю на каждом втором семпле - и разница видна невооружённым глазом.

Обнаружение песочницы и виртуальной машины - гонка вооружений, в которой индустрия защиты проигрывает методологически. Проблема не в конкретных артефактах: MAC сменить, реестр почистить, ядер добавить - всё решаемо за полчаса. Проблема в том, что подавляющее большинство коммерческих песочниц построены на KVM, Xen или QEMU - гипервизорах с открытым кодом, которые малварь-разработчики изучают так же тщательно, как и сами вендоры. Для каждого из этих гипервизоров в открытом доступе существуют десятки evasion-техник (Al-Khaser на GitHub - классический пример). Unit 42 прямо написали, что единственным реальным решением стала разработка собственного гипервизора с нуля - и это инженерная необходимость, когда весь код mainstream-гипервизоров давно разобран атакующими.

Я разбираю семплы каждую неделю и вижу устойчивый тренд: anti-VM модуль - уже не признак APT-уровня, а стандартная практика даже для commodity-вредоносов. Три WMI-запроса, проверка MAC и CPUID - 50 строк кода, блокирующие анализ в дефолтной песочнице. Порог входа для атакующих упал до минимума.

Мой прогноз: в ближайшие год-два evasion сместится с системных проверок на анализ pocket litter и поведенческих паттернов. Малварь будет проверять не «есть ли VMware Tools в реестре», а «есть ли в браузере 200 закладок, cookie от Gmail и история покупок на маркетплейсе». Песочницы следующего поколения должны будут не просто эмулировать ОС, а эмулировать цифровую жизнь конкретного пользователя - со всем его бытовым мусором. Это совершенно другой уровень инженерии, к которому большинство вендоров пока не готовы. Попробуйте прогнать Al-Khaser на своём стенде - и посмотрите, сколько проверок он пройдёт. Результат может неприятно удивить.