VBS-анклавы: как технологии защиты помогают создавать скрытное вредоносное ПО

Безопасность на основе виртуализации (Virtualization-based security, VBS) — одно из самых интересных достижений в области кибербезопасности последних лет. Возможность изолировать критически важные компоненты операционной системы позволила Microsoft добиться значительного повышения уровня защиты благодаря таким функциям, как Credential Guard и Hypervisor-Protected Code Integrity (HVCI).

Одной из часто упускаемых из виду возможностей VBS является технология VBS-анклавов — механизм, позволяющий изолировать определенную область процесса, делая её недоступной для других процессов, самого процесса и даже ядра операционной системы.

VBS-анклавы могут применяться в различных сценариях обеспечения безопасности. Microsoft использует их для реализации нескольких важных сервисов, включая вызывающую споры функцию Recall. Кроме того, компания поддерживает разработку VBS-анклавов сторонними разработчиками и активно продвигает их использование.

Несмотря на защитный потенциал анклавов, они могут представлять интерес и для злоумышленников — вредоносное ПО, запущенное внутри анклава, может быть практически невидимым для методов обнаружения и анализа оперативной памяти.

В данной статье рассматриваются VBS-анклавы и то, как их можно использовать в злонамеренных целях. Кроме того, описывается Mirage — техника обхода обнаружения в памяти, основанная на подходе «Bring your own vulnerable enclave (BYOVE)». Также разбирается, как злоумышленники могут использовать старые, уязвимые версии легитимных анклавов для реализации скрытой техники уклонения.

Уровни виртуального доверия

Традиционно Windows использовала кольцевую архитектуру процессора для защиты ОС от вмешательства пользовательских приложений. Этот аппаратный механизм обеспечивает разделение операционной системы и пользовательских программ — ядро работает в ring0, будучи изолированным от приложений в ring3 (пользовательский режим). Однако эта модель имеет значительный недостаток: злоумышленники могут относительно легко скомпрометировать систему с помощью атак на ядро.

Ядро Windows обладает широкой атакуемой поверхностью. Огромное количество сторонних драйверов, а также разнообразные сервисы, предоставляемые самим ядром, способствуют постоянному появлению уязвимостей, эксплуатируемых для атак на уровень ядра. Используя эксплойт для ядра, злоумышленник получает возможность полностью контролировать операционную систему. Очевидно, что граница между пользовательским и привилегированным режимами оказалась недостаточной.

Чтобы устранить эту проблему, Microsoft ввела дополнительный уровень защиты в виде уровней виртуального доверия (Virtual Trust Levels, VTL). Привилегии в VTL основаны на доступе к памяти — каждый уровень доверия предоставляет исполняемым на нём сущностям разные права на доступ к физической памяти. В частности, более низкие VTL не могут обращаться к памяти более высоких.

Как и традиционные кольца процессора, VTL разделяют ОС на различные «режимы» исполнения, начиная с VTL0 и заканчивая (потенциально) VTL16. Однако в отличие от колец процессора, где ring0 обладает максимальными привилегиями, в VTL более высокие уровни обладают большей привилегированностью, чем нижние.

В настоящее время Windows использует два основных уровня доверия: VTL0 и VTL1 (существует также VTL2, но он выходит за рамки этого материала).

• VTL0 отвечает за выполнение традиционных компонентов ОС, включая ядро и пользовательские приложения.
• VTL1, обладающий более высокими привилегиями, вводит два новых режима выполнения: защищённый режим ядра (Secure Kernel Mode) и изолированный пользовательский режим (Isolated User Mode).

Защищённый режим ядра

Защищённый режим ядра (Secure Kernel Mode) — это режим выполнения ring0 VTL1. В этом режиме работает защищённое ядро — отдельный вариант ядра, выполняемый в VTL1 и обладающий более высокими привилегиями, чем обычное ядро. Благодаря этим привилегиям защищённое ядро может применять политики безопасности к обычному ядру и ограничивать его доступ к критически важным областям памяти.

Как уже отмечалось, ядро Windows имеет широкую атакуемую поверхность и может быть скомпрометировано. Однако, если лишить обычное ядро части привилегий и передать их защищённому ядру, можно значительно снизить риск его компрометации.

Теоретически компрометация защищённого ядра всё же может привести к полному захвату системы. Однако этот сценарий гораздо менее вероятен, поскольку защищённое ядро имеет очень узкую функциональность и не поддерживает сторонние драйверы, что значительно сокращает возможные векторы атак.

Изолированный пользовательский режим

Изолированный пользовательский режим (Isolated User Mode, IUM) — это режим выполнения ring3 VTL1. Он предназначен для выполнения защищённых процессов (Secure Processes) — особого типа пользовательских процессов, использующих механизм изоляции памяти VTL1.

Главная особенность IUM заключается в том, что память внутри этого режима недоступна любому коду в VTL0, включая обычное ядро. Это делает изолированный пользовательский режим основой механизмов изоляции, таких как Credential Guard.

Итоговая архитектура уровней выполнения

Введение VTL0/VTL1 привело к появлению четырёх режимов выполнения:

1. Ring0 VTL0 — Обычный режим ядра (Normal Kernel Mode)
2. Ring0 VTL1 — Защищённый режим ядра (Secure Kernel Mode)
3. Ring3 VTL0 — Обычный пользовательский режим (Normal User Mode)
4. Ring3 VTL1 — Изолированный пользовательский режим (Isolated User Mode)

Режимы выполнения, созданные путем добавления VTL (Akamai)

Что такое VBS-анклавы?

Ещё одной возможностью, реализуемой через изолированный пользовательский режим (IUM), являются VBS-анклавы. VBS-анклав представляет собой изолированную область пользовательского процесса, находящуюся в IUM, в которую можно загружать специальные библиотеки (DLL), называемые «модулями анклавов».

Когда модуль загружается в анклав, он становится частью доверенной среды выполнения (Trusted Execution Environment, TEE). Это означает, что данные и код внутри анклава недоступны для любых процессов, работающих в VTL0, и, следовательно, не могут быть скомпрометированы или украдены злоумышленниками.

Схема памяти анклава VBS (Microsoft)

Создание и использование VBS-анклавов

Пользовательский процесс может создать анклав с помощью специальных Windows API, загрузить в него модуль и инициализировать его. Модули анклавов представляют собой DLL, специально скомпилированные для работы внутри анклава. После инициализации хост-процесс не может обращаться к памяти анклава и может взаимодействовать с ним только через экспортированные функции с использованием API CallEnclave.

Пример кода создания VBS-анклава (Microsoft)

Ограничения и контроль загрузки модулей

Поскольку Microsoft стремится максимально ограничить доступ к VTL1, загрузка DLL в анклав возможна только при наличии специальной подписи, выданной Microsoft. Любая попытка загрузить неподписанный модуль будет заблокирована. Подписание модулей анклавов доступно только доверенным третьим сторонам. Однако интересно, что ограничений на загрузку подписанных модулей не существует — любой процесс может загрузить любой подписанный модуль в анклав.

Ограниченные возможности модулей анклавов

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

API, доступные внутри анклавов, импортируются из специальных библиотек, загружаемых в VTL1. Например, в то время как обычные процессы используют ntdll.dll для обращения к сервисам ОС, модули анклавов взаимодействуют с системой через vertdll.dll — специальный аналог ntdll, предназначенный для обмена с защищённым ядром через системные вызовы (syscalls).

Вредоносное ПО в анклавах

Концепция «enclave malware» представляет значительный интерес для злоумышленников, поскольку предоставляет две ключевые возможности:

1. Запуск в изолированной области памяти
• Адресное пространство анклава недоступно для любых процессов, работающих в VTL0, включая системы EDR (Endpoint Detection and Response) и инструменты анализа.
• Это делает обнаружение вредоносного кода значительно сложнее.
2. Невидимые вызовы API
• Вызовы API, выполненные внутри анклава, невидимы для EDR-систем.
• EDR-решения контролируют API-вызовы в пользовательском режиме, размещая хуки в системных библиотеках (например, в NTDLL.dll) и применяя драйверы для мониторинга ядра.
• Однако анклавные вызовы API не фиксируются этими методами, поскольку выполняются из VTL1 и не проходят через перехваченные компоненты VTL0.

Механизм скрытия API-вызовов

На Рис. 4 показано преимущество анклавного вредоносного ПО:

• Обычный процесс, вызывая Windows API, может быть зафиксирован EDR, так как хуки внедряются в NTDLL.dll или в код ядра.
• Модуль анклава использует библиотеку vertdll.dll, загруженную в VTL1, и выполняет вызовы напрямую к защищённому ядру.
• Эти операции недоступны для EDR и остаются невидимыми для традиционных средств защиты.

Различия между обычным пользовательским режимом и процессами вызова API IUM (Akamai)

Как злоумышленники могут выполнять вредоносный код внутри анклава?

Как уже упоминалось, модули анклавов должны быть подписаны сертификатом, выданным Microsoft, что означает, что только одобренные компанией субъекты могут загружать свой код в анклав. Однако у злоумышленников всё же есть несколько способов обойти это ограничение.

Использование уязвимостей ОС

Первый метод заключается в эксплуатации уязвимостей операционной системы.

Примером такой атаки является уязвимость CVE-2024-49706, обнаруженная Алексом Ионеску (Winsider Seminars & Solutions). Она позволяла загружать неподписанные модули в анклав. Хотя Microsoft закрыла эту уязвимость, мотивированные злоумышленники могут обнаружить аналогичные ошибки в будущем.

Получение легитимной подписи

Другой вариант — получить подлинную подпись для вредоносного модуля.

Microsoft предоставляет возможность сторонним организациям подписывать модули анклавов через Trusted Signing Platform.

• Хотя получить такую подпись непросто, опытные злоумышленники могут скомпрометировать доверенное подписывающее лицо и таким образом подписать вредоносный код.

Использование отладочных анклавов

Ещё один способ обхода ограничений — злоупотребление функцией «отладочного анклава» (debuggable enclave).

При создании VBS-анклава разработчик может разрешить его отладку.

• Если модуль скомпилирован с этим параметром, он поддерживает возможность отладки.
• Обычно анклавы не поддаются отладке, так как работают в VTL1, а отладчики не могут получить доступ к памяти анклава, чтобы извлечь данные или установить точки останова.
• На примере ниже отладчик не может прочитать содержимое памяти анклава.

Однако если злоумышленник получает доступ к отладочному анклаву, он может использовать его для исполнения произвольного кода внутри защищённой среды.

Попытка чтения памяти отладочного модуля анклава (Akamai)

Эксплуатация уязвимых анклавов

Последняя техника основана на поиске уязвимостей в существующих анклавных модулях.

• Некоторые доверенные модули анклавов могут содержать ошибки или устаревшие компоненты, которые позволяют загрузить в них вредоносный код.
• Если злоумышленники обнаружат уязвимый анклав, они могут использовать его в атаках, переписывая код или загружая вредоносные библиотеки.

Отладочные анклавы: особые исключения для отладки

Интересной особенностью является то, что даже если модуль анклава разрешает отладку, он всё равно загружается в VTL1. Для обеспечения возможности отладки защищённое ядро (Secure Kernel) реализует специальные исключения, применяемые к отладочным модулям анклавов.

Как это работает?

• Когда обычное ядро пытается прочитать память анклава, оно делает вызов в защищённое ядро.
• В этом случае вызывается функция SkmmDebugReadWriteMemory, которая проверяет, является ли целевой модуль отладочным.
• Если модуль разрешает отладку, ядро выполняет запрошенную операцию и передаёт данные отладчику.

Пример успешного чтения памяти анклава

После загрузки отладочного анклавного модуля, отладчик получает доступ к памяти анклава и может её читать без ограничений (Akamai)

Подобным образом процесс, работающий в VTL0, может изменять права доступа к памяти внутри отладочного анклавного модуля. Это исключение реализовано в защищённом вызове ядра SkmmDebugProtectVirtualMemory.

Microsoft настоятельно рекомендует разработчикам не использовать отладочные анклавные модули в производственной среде, так как это подрывает саму концепцию анклавов, заключающуюся в изоляции памяти от VTL0. Если модуль поддерживает отладку, все данные, которые он обрабатывает, могут быть легко скомпрометированы.

Риски использования отладочного анклавного модуля в производстве очевидны, но злоумышленники могут воспользоваться механизмом для другой цели — выполнения неподписанного кода в VTL1.

Если атакующему удастся получить доступ к любому подписанному анклавному модулю с поддержкой отладки, он сможет добиться выполнения произвольного кода в VTL1, выполнив следующие четыре шага:

1. Получить адрес любой функции внутри анклавного модуля с помощью GetProcAddress.
2. Изменить права доступа к памяти этой функции на RWX (чтение, запись, выполнение).
3. Перезаписать код функции произвольным шеллкодом.
4. Вызвать изменённую функцию с помощью CallEnclave, тем самым запустив вредоносный код внутри VTL1.

Ниже показа пример кода, реализующего такой процесс.

Пример кода, который выполняет неподписанный shellcode внутри анклава (Akamai)

Техника Bring Your Own Vulnerable Enclave (BYOVE)

Как уже упоминалось, Windows использует механизм подписей, чтобы предотвратить загрузку неавторизованных анклавов в VTL1. Подход, основанный на строгой проверке подписи, не является уникальным для анклавов — он впервые появился в системе принудительного подписывания драйверов (DSE), которая запрещает запуск неподписанных драйверов в ядре Windows.

Чтобы обойти этот механизм, злоумышленники начали применять технику Bring Your Own Vulnerable Driver (BYOVD). А можно ли использовать аналогичный метод в отношении анклавов? Можно ли скомпрометировать уязвимый подписанный анклавный модуль, чтобы выполнять код в IUM?

Возьмем CVE-2023-36880 — уязвимость в модуле VBS-анклава, используемом браузером Microsoft Edge. Уязвимость позволяет злоумышленнику читать и записывать произвольные данные внутри анклава. Хотя Microsoft классифицировала её как уязвимость раскрытия информации, в описании указано, что она также может привести к ограниченному выполнению кода.

Идея заключается в том, чтобы использовать возможность чтения и записи для перезаписи стека анклава с помощью цепочки ROP, что в конечном итоге позволило бы выполнить шеллкод внутри анклава. Однако стоит учесть, что анклавы защищены от выполнения неподписанного кода с помощью механизма arbitrary code guard (ACG).

ACG — это защитный механизм, предназначенный для блокировки выполнения динамически генерируемого кода, то есть кода, который создаётся во время работы процесса, а не загружается из исполняемого файла или его библиотек. Механизм реализуется через два правила:

1. После загрузки процесса нельзя создавать новые исполняемые страницы.
2. Уже исполняемая страница не может стать доступной для записи.

На уровне ядра Windows ACG применяется по умолчанию, но в пользовательском режиме он активируется только для процессов, которые были специально сконфигурированы для его использования. Для процессов IUM, включая анклавы, ACG применяется автоматически, как и в обычном ядре.

Это можно проверить, попытавшись выделить новую RWX-страницу внутри анклава с помощью VirtualAlloc — операция завершится с ошибкой 0x677, STATUS_DYNAMIC_CODE_BLOCKED. Аналогично, попытка изменить права доступа к уже исполняемой странице с помощью VirtualProtect или сделать страницу исполняемой приведёт к такому же результату.

Попытка выделить страницу RWX внутри анклава (Akamai)

Чтобы разобраться в таком поведении, можно изучить функцию SecureKernel!NtAllocateVirtualMemoryEx, которая отвечает за динамическое выделение памяти в IUM. Функция анализирует запрашиваемую маску защиты, и если процесс пытается выделить исполняемую страницу, она возвращает ошибку ACG STATUS_DYNAMIC_CODE_BLOCKED. Аналогичные проверки реализованы в SkmmProtectVirtualMemory, что предотвращает изменение прав доступа к уже существующим страницам памяти в IUM.

Код NtAllocateVirtualMemoryEx отклоняет исполняемое выделение памяти (Akamai)

Как мы видим, не удается обойти ACG внутри анклава и загрузить неподписанный код. Теоретически возможно создание полного ROP-эксплойта, который потенциально позволил бы злоумышленникам вызывать произвольные API в VTL1. Тем не менее, можно изучить другую интересную возможность использования уязвимых анклавов.

Какие техники можно использовать, выполняя код внутри анклава?

Понимая, что анклавы обладают значительным потенциалом для злоумышленников и что их запуск при достаточной мотивации возможен, следующий вопрос, который мы исследовали, — какие методы доступны вредоносному ПО в таком окружении.

Самый очевидный вариант — использовать анклавы так, как они изначально предназначены. Если анклав может защищать конфиденциальные данные от атакующих, он также может использоваться злоумышленниками для сокрытия их собственных «секретов» от компонентов VTL0.

Этот подход может быть полезен в разных сценариях: скрытие полезной нагрузки от EDR, защита ключей шифрования от аналитиков или хранение конфигурации вредоносного ПО таким образом, чтобы она не попадала в дампы памяти.

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

Доступ к памяти пользовательского режима VTL0

Несмотря на ограниченный доступ анклавов к системе, у них остаётся доступ к одному важному ресурсу — памяти процесса. Анклав может выполнять операции чтения и записи в пределах всего адресного пространства процесса, включая VTL0.

Существуют некоторые ограничения: код, выполняющийся внутри анклава, подчиняется стандартным правилам доступа к памяти и не может их изменять. Это означает, что анклав не сможет записывать данные в память, помеченную как «только для чтения», или изменять атрибуты страниц, превращая неисполняемую память в исполняемую.

Код, выполняющийся внутри анклава и демонстрирующий доступ к памяти процесса, а также возможные ограничения (Akamai)

Доступ к памяти пользовательского режима VTL0 открывает возможность реализации различных полезных техник. Загружая вредоносный анклав в целевой процесс, можно незаметно отслеживать и красть конфиденциальные данные, а также модифицировать значения в памяти процесса для изменения его поведения.

Применение этих техник через анклав даёт значительное преимущество. Как уже упоминалось, выполнение API-вызовов из анклава обходит мониторинг EDR, что делает подобные операции невидимыми для систем обнаружения. Так как доступ к памяти в этих атаках осуществляется анклавом, они остаются скрытыми от традиционных защитных механизмов.

Выполнение кода пользовательского режима VTL0

Хотя анклав может читать и записывать данные в память VTL0, если у него есть соответствующие разрешения, код, находящийся в VTL0, не может быть выполнен внутри анклава, даже если он обладает исполняемыми правами.

Тем не менее, анклав всё же может запускать код в VTL0 удалённо. Используя API CallEnclave с указанием адреса в VTL0, анклав может инициировать выполнение кода в обычном пользовательском потоке.

Анклав не может выполнить код VTL0 (Akamai)

Заставляя процесс пользовательского режима действовать от их имени, анклавы могут косвенно взаимодействовать с системой способами, которые обычно для них недоступны. Например, анклав может вызвать функцию VTL0, которая читает файл, создаёт сетевое соединение и выполняет другие операции.

Однако важно отметить, что выполнение кода в пользовательском режиме таким способом не даёт преимуществ с точки зрения уклонения от обнаружения. Так как этот код выполняется как обычный код пользовательского режима, EDR может его зафиксировать.

Антиотладка

Ещё одной интересной возможностью вредоносного кода в анклаве является антиотладка. Код, выполняющийся внутри анклава, остаётся недоступным для VTL0-приложений, включая отладчики, что даёт вредоносному ПО значительное преимущество.

Ограниченный набор API, доступных анклавам, означает, что не все традиционные методы антиотладки могут быть реализованы. Например, анклавы не могут вызывать API NtQueryInformationProcess, IsDebuggerPresent, а также API для работы с датой и временем. Тем не менее, остаются другие варианты.

Первый метод — использование доступа анклава к адресному пространству VTL0. Анклав может напрямую прочитать PEB процесса и проверить значение флага BeingDebugged. Если отладчик обнаружен, анклав может инициировать завершение процесса.

Другой подход — реализация антиотладки на основе задержек. Хотя API для получения времени недоступны анклавам, они могут использовать инструкцию rdtsc. Эта инструкция возвращает количество тактов процессора с момента загрузки системы. Измеряя время между вызовами анклава, можно определить аномальные задержки (например, вызванные пошаговой отладкой) и завершить процесс, если задержка превышает пороговое значение.

Антиотладка на основе времени в анклаве с использованием инструкции сборки rdtsc (Akamai)

Переместив критически важные части кода в анклав и добавив антиотладочные проверки, можно создать вредоносное ПО, практически неуязвимое для динамического анализа.

Такое ПО будет зависеть от анклава для нормальной работы, а процесс в пользовательском режиме не сможет модифицировать проверки, выполняющиеся внутри анклава. При корректной реализации этот метод можно обойти только через отладку Hyper-V или защищённого ядра.

Техника Bring Your Own Vulnerable Enclave (BYOVE). Раунд 2

Использование уязвимого анклавного модуля для выполнения кода в IUM приводил к ошибке. Теперь стоит проверить, можно ли использовать концепцию BYOVE в других сценариях. Уязвимость CVE-2023-36880 связана с функциями SealSettings и UnsealSettings, экспортируемыми анклавным модулем.

• SealSettings получает указатель на буфер данных, шифрует его и записывает зашифрованные данные в адрес назначения, предоставленный вызывающим процессом.
• UnsealSettings выполняет обратную операцию — расшифровывает буфер и записывает результат в заданный адрес.

Проблема обеих функций в том, что они не проверяют корректность переданных адресов. Это означает, что злоумышленник может указать любой адрес внутри процесса, включая адреса внутри самого анклава.

Уязвимый код внутри функции UnsealSettings (Akamai)

Уязвимость предоставляет злоумышленнику две возможности

Эксплуатация ошибки для чтения/записи произвольных данных внутри анклава (Akamai)

1. Произвольная запись внутри анклава: хакер может вызвать SealSettings для шифрования произвольных данных, а затем вызвать UnsealSettings, чтобы указать на адрес назначения внутри анклава. Это приводит к записи исходных данных в память анклава.
2. Произвольное чтение внутри анклава: злоумышленник может вызвать SealSettings, указав адрес внутри анклава в качестве указателя исходного буфера. Это заставит анклав зашифровать данные из памяти анклава и записать их в контролируемое злоумышленником место. Затем киберпреступник может расшифровать эти данные, вызвав UnsealSettings, что позволит ему читать произвольные данные из анклава.

Mirage — обход обнаружения в памяти на основе VTL1

Хотя нам не удалось выполнить код в VTL1, примитив произвольной записи открыл две уникальные возможности:

1. Хранение произвольных данных в VTL1, делая их недоступными для процессов VTL0.
2. Запись произвольных данных в адресное пространство VTL0 из VTL1, что скрывает эту операцию от мониторинга VTL0-системами.

Кроме того, поскольку эти возможности предоставляются через загрузку подписанного анклавного модуля, ими может воспользоваться любой атакующий без необходимости подписывать что-либо самостоятельно.

Техника обхода Mirage

Чтобы продемонстрировать потенциал этих возможностей, используем технику обхода обнаружения в памяти под названием Mirage, которая создает полезную нагрузку за счёт переключения между памятью VTL1 и VTL0.

• Шеллкод хранится в памяти анклава (VTL1).
• Периодически он переносится обратно в VTL0, используя уязвимость.
• После выполнения он мгновенно стирается из памяти VTL0.

Жизненный цикл процесса уклонения Mirage (Akamai)

Преимущества Mirage

• Скрытость от сканирования памяти и дампов. Поскольку полезная нагрузка большую часть времени хранится в VTL1, она не обнаруживается при анализе памяти. Кроме того, во время неактивного состояния полезная нагрузка полностью недоступна.

• Шеллкод записывается в VTL0 анклавом, а не процессом. EDR-решения не могут отслеживать код, выполняемый в VTL1. Это означает, что EDR не сможет перехватить момент записи шелл-кода в память VTL0.

Обнаружение

На сегодняшний день анклавы используются очень ограниченным числом приложений. Даже если их распространённость увеличится, они всё равно будут загружаться только определёнными процессами, а не произвольными программами. Например, calc.exe не должен загружать VBS-анклав, и подобное поведение будет выглядеть подозрительно.

По этой причине аномальное использование анклавов может служить хорошим индикатором компрометации. Защитные механизмы могут воспользоваться этим, создав эталон известных легитимных случаев использования VBS-анклавов и выявляя любые отклонения от него.

Обнаружение анклавов может осуществляться двумя основными способами:

1. Мониторинг вызовов API, связанных с анклавами
2. Выявление загруженных DLL-файлов анклавов

Вызовы API, связанные с анклавами

Следующие API-функции используются процессами для управления VBS-анклавами и могут указывать на их загрузку:

• CreateEnclave
• LoadEnclaveImageW
• InitializeEnclave
• CallEnclave
• DeleteEnclave
• TerminateEnclave

Выявление загруженных DLL-файлов анклавов

Другой способ обнаружения аномального использования анклавов — отслеживание загрузки специфичных DLL, которые обычно применяются анклавами. В частности, это:

• Vertdll.dll
• Ucrtbase_enclave.dll

Данные библиотеки не должны использоваться никакими другими процессами, кроме анклавов. Если они загружены в процесс, это означает, что он вероятно использует анклав, что может быть индикатором подозрительной активности.

Заключение

VBS-анклавы представляют собой мощный инструмент для разработчиков, позволяющий защищать критически важные компоненты приложений. Однако, они также могут быть использованы злоумышленниками для скрытия вредоносного кода. Хотя подобные атаки пока носят теоретический характер, нельзя исключать, что в будущем группировки начнут активно применять VBS-анклавы для защиты своих вредоносных программ от обнаружения.