Вакансии по пентесту всё чаще требуют не только понимания принципов работы ключевых СЗИ (WAF, EDR, NAC), но и практических навыков их обхода. То же самое касается EDR/AV. В реальных отчётах о кибератаках также регулярно упоминается, как злоумышленники обходят средства защиты и остаются незамеченными.

Предлагаем рассмотреть пару приемов таких обходов и проверить, готовы ли ваши системы защиты к подобным вызовам.

Маскировка путей

Как оставаться незамеченным для систем EDR (Endpoint Detection and Response), имея права доступа обычного пользователя?

Большинство методов обхода EDR требуют наличия повышенных привилегий (права Администратора, SYSTEM и т.д.). Следовательно, при работе под обычной учетной записью главной задачей становится выполнение операций максимально незаметным способом.

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

Событие создания процесса

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

Ниже — пример такого события из логов Sysmon:

Среди ключевых атрибутов события, отслеживаемых системами мониторинга, можно выделить Image (путь к образу), CommandLine (командная строка), CurrentDirectory (текущий каталог) и ParentProcessID (ID родительского процесса).

Представим, что аналитик видит в логах два события создания процесса с разными путями в поле Image:

• C:\Program Files\Windows Defender\MsMpEng.exe

• %TEMP%\SuperJuicy.exe

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

Опытный аналитик знает, что рабочие каталоги антивирусов и EDR защищены на уровне ядра. Без повышения привилегий (например, через BYOVD или эксплуатацию уязвимости) злоумышленник не сможет поместить свой файл в эти папки.

Следовательно, в первую очередь внимание привлечет SuperJuicy.exe. Причина — не название, а его расположение, ведь легитимный MsMpEng.exe находится в защищенной директории Windows Defender. Но, конечно, в рамках тщательного расследования необходимо проанализировать оба случая.

Атака с маскировкой файлов, используемая в фишинге

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

Распространенные методы:

• Двойное расширение файла: например, файл с именем document.pdf.exe маскируется под PDF.

• Маскировка типов файлов: изменение метаданных для ложной идентификации типа файла.

• Переопределение справа налево (RLO): использование специальных символов, чтобы изменить порядок отображения имени файла (например, txt.exe будет выглядеть как exe.txt).

• Использование легитимных имен или путей: вредоносному файлу дают имя известного приложения (svchost.exe) или размещают в системных каталогах (C:\Windows\System32)

• Подделка подписи: копирование действительных подписей и метаданных для обхода некоторых механизмов защиты.

Далее мы воспользуемся техникой легитимного использования и применим ее к пути файла. Цель — замаскировать атрибут Image, чтобы он не привлекал внимания в логах SIEM.

Маскировка путей с помощью Unicode-омоглифов

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

Для этого мы замаскируем путь к нашему файлу так, чтобы в поле Image он выглядел как C:\Program Files\Windows Defender\MsMpEng.exe. В журналах Sysmon, Process Monitor и других утилит путь к процессу должен быть неотличим от пути к исполняемому файлу антивируса.

В основе этого метода лежит использование Unicode-символов, которые являются омоглифами (визуально неотличимыми аналогами ASCII-пробела). К ним относятся, например:

• U+2000: En Quad

• U+2001: Em Quad

• U+2002: En Space
  ...

• U+200A: Hair Space

Так как у нас только права обычного пользователя, сначала нужно найти место в пути C:\Program Files\Windows Defender\MsMpEng.exe, где разрешено создавать папки или файлы.

Наиболее подходящим местом для этого является корень диска C:. По умолчанию стандартный пользователь имеет права на создание папок в этой директории, хотя и это может быть ограничено политикой безопасности организации. В нашей тестовой среде на Windows 11 создание папки прошло успешно.

Итак, создадим папку с именем Program Files 00 в корне диска C:. В результате получим путь C:\Program Files 00, где у нашего пользователя будут полные права (чтение, запись, выполнение).

Затем переименуем ее, заменив пробел на Unicode-омоглиф: Program[U+2000]Files. Мы разделяем процесс на два этапа, чтобы сначала гарантированно проверить наличие прав на создание папки. Впрочем, в некоторых системах может получиться создать папку с Unicode-символом сразу.

После переименования посмотрим на вывод команды dir, указанный выше. Сможете ли вы на глаз отличить стандартную папку Program Files от созданной нами?

Следующий этап — воссоздание правдоподобной структуры каталогов. Копируем содержимое папки C:\Program Files\Windows Defender в наш новый каталог C:\Program[U+2000]Files\Windows Defender и размещаем в нем наш файл TheJuicyOne.exe.

Для усиления маскировки в созданной папке можно дополнительно применить техники DLL Hijacking или DLL Side-Loading, с использованием исполняемых файлов Windows Defender.

Теперь, в рамках нашего PoC, мы запустим TheJuicyOne.exe и посмотрим на событие его создания в Sysmon.

Сравним записи в журнале для нашего файла и для легитимного MpCmdRun.exe. На основе одной лишь информации из лога невозможно заметить разницу: оба события указывают на выполнение файла из каталога C:\Program Files\Windows Defender.

Таким образом, аналитик не сможет по одному лишь логу определить, что TheJuicyOne.exe в действительности запущен из совершенно другого места.

Маскировка пути под Windows Defender или другие AV/EDR-решения влечет за собой несколько последствий:

• Это запутывает аналитиков и замедляет реагирование.

• Это может направить расследование по ложному пути. Например, аналитик может подумать, что скомпрометирован сам Windows Defender, и сосредоточится на этой версии.

• И главное — наш файл выглядит как легитимный.

Защита от техники маскировки путей

Рекомендации по противодействию этому методу:

• Настроить мониторинг путей, содержащих "поддельные" пробелы — символы Unicode, которые выглядят как обычный пробел.

• Доработать средства просмотра логов для явного отображения таких символов. Например, чтобы папка Program Files с омоглифом отображалась как Program[En Quad]Files.

• Ограничить права пользователей на создание папок в корне диска C:.

BYOVD: обход EDR с помощью символьных ссылок Windows

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

Для демонстрации этой техники мы покажем, как на практике применить ее для отключения Windows Defender в Windows 11.

Что такое "Bring Your Own Vulnerable Driver" (BYOVD)

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

Техника BYOVD популярна среди киберпреступников. Некоторые реальные примеры групп, использующих технику BYOVD:

• Группа вымогателей Kasseika использует драйвер Martini для завершения процессов антивирусных продуктов и инструментов безопасности.

• Water Bakunawa использует EDRKillShifter для уклонения от обнаружения и нарушения процессов мониторинга безопасности.

• Группа ransomware BlackByte использовала технику BYOVD для эксплуатации уязвимости в драйвере MSI Afterburner RTCore64.sys. Это позволило отключать драйверы, используемые для обеспечения безопасности.

Ограничение техники Bring Your Own Vulnerable Driver заключается в необходимости находить драйверы с эксплуатируемыми уязвимостями. Эти драйверы часто попадают в список блокировки уязвимых драйверов от Microsoft. При регулярном обновлении этого списка количество доступных для эксплуатации драйверов со временем будет уменьшаться.

Использование функции записи файлов любого драйвера с помощью символьной ссылки Windows

Как мы знаем, Endpoint Detection and Response (EDR) устанавливает на компьютер минифильтр для сбора событий, связанных с процессами, файлами и другой активностью. Работает он, как правило, в режиме ядра.

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

Обычно минифильтры EDR не отправляют собранные логи напрямую на сервер. Вместо этого они передают данные службе, работающей в пользовательском режиме (user-mode service). Уже эта служба отвечает за дальнейшую обработку, анализ и передачу данных на сервер.

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

Для "ослепления" EDR обычно применяют два метода:

• Атака на минифильтр EDR: поиск способа выгрузить его из операционной системы или предотвратить загрузку.

• Атака на службу в пользовательском режиме: поиск способа завершить процесс службы. В случае успеха EDR больше не сможет отправлять логи на сервер.

Использование функции записи в файл для вывода из строя службы EDR

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

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

Поэтому в этой статье мы сосредоточимся на подходе с повреждением исполняемого файла службы EDR. Основные шаги:

• Шаг 1. Находим драйвер-минифильтр, который выполняет операцию записи в файл при загрузке системы, не требуя для этого явного вызова через IOCTL. Идеальные кандидаты — драйверы, использующие API ZwWriteFile.

• Шаг 2. С помощью реверс-инжиниринга или отладки определяем точный путь к файлу, в который драйвер производит запись.

• Шаг 3. Регистрируем найденный драйвер как службу ядра, которая будет автоматически загружаться при старте системы.

• Шаг 4. Создаем символическую ссылку от выходного файла минифильтра к исполняемому файлу службы EDR.

• Шаг 5. Перезагружаем систему и проверяем, был ли исполняемый файл службы EDR поврежден или перезаписан.

На Шаге 1 можно использовать функцию ZwCreateFile, но ZwWriteFile в определенный момент обязательно вызовет ZwCreateFile и гарантированно перезапишет содержимое целевого файла.

На Шаге 3 необходимо обеспечить, чтобы наша новая служба загружалась и выполнялась раньше службы EDR. Как это сделать?

Секрет победы этой "гонки загрузки" кроется в ключе реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder

Этот ключ реестра определяет последовательность загрузки групп служб при старте системы. Группы служб — это коллекции служб, которые ОС загружает в определенном порядке для стабильной работы. Ключ содержит значение с именем "List", которое представляет собой многострочное строковое значение (REG_MULTI_SZ). Каждая строка в этом списке представляет имя группы служб.

Чтобы наша служба всегда выполнялась первой, достаточно при регистрации указать для нее группу из семейства FSFilter *. Это обеспечит ее загрузку до службы пользовательского режима EDR.

Если же зарегистрировать нашу службу в группе, которая в списке находится выше "FSFilter Anti-Virus", можно потенциально вывести из строя и сам минифильтр EDR. Однако такой метод с высокой вероятностью вызовет "синий экран смерти" (BSOD) в Windows.

На Шаге 4 нужно правильно создать символическую ссылку. Символическая ссылка (symlink) в Windows — это объект файловой системы, который служит указателем на другой файл или каталог. Он позволяет перенаправлять все операции с одного пути на другой, не изменяя фактического расположения данных.

Рассмотрим практический пример. Чтобы создать символическую ссылку на файл D:\Documents\example.txt по пути C:\Users\Пользователь\Links\example.txt, нужно выполнить команду:

mklink "C:\Users\Пользователь\Links\example.txt" "D:\Documents\example.txt"

Эта команда создает символическую ссылку с именем example.txt в папке Links, которая указывает на оригинальный файл example.txt в папке Documents.

Теперь доступ к C:\Users\ВашПользователь\Links\example.txt будет перенаправлять вас к файлу, расположенному по пути D:\Documents\example.txt.

Отключение Windows Defender с помощью драйвера Process Monitor и символических ссылок

Проведем демонстрацию отключения Windows Defender на системе Windows 11 версии 24H2 (Сборка ОС 26100.2894) с обновлением, установленным в январе 2025 года.

Утилита Process Monitor предоставляет функцию логирования процесса загрузки Windows. При использовании этой функции Process Monitor регистрирует службу PROCMON24 следующим образом:

Группа службы PROCMON24 называется "FSFilter Activity Monitor", а её тип равен 1. Это означает, что она будет функционировать как минифильтр, работающий на уровне ядра.

Что касается Windows Defender, служба WinDefend будет запускать исполняемый файл антивирусной службы (MsMpEng.exe).

В реестре службы WinDefend отсутствует значение "Group", что означает, что она будет загружаться последней в списке "ServiceGroupOrder".

Значения "Типа" службы (Service "Type" Values):

• 0x01: Драйвер устройства ядра (Kernel device driver).

• 0x02: Драйвер файловой системы (File system driver).

• 0x04: Драйвер адаптера (Adapter driver).

• 0x08: Драйвер распознавателя (Recognizer driver).

• 0x10: Собственный процесс Win32 (Win32 own process).

• 0x20: Совместный процесс Win32 (Win32 shared process). Служба разделяет процесс с другими службами.

Из приведенной выше информации можно сделать вывод, что PROCMON24 всегда будет загружаться раньше WinDefend. Это означает, что в момент работы PROCMON24 процесс антивирусной службы MsMpEng.exe еще не активен, что позволяет нам его перезаписать.

Process Monitor записывает лог загрузки в файл C:\Windows\Procmon.pmb. Чтобы отключить Windows Defender, мы сначала активируем "Boot Logging", а затем создадим символическую ссылку:

mklink C:\Windows\Procmon.pmb "C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24090.11-0\MsMpEng.exe"

После создания этой ссылки мы перезагружаем Windows. Это приведет к тому, что файл антивирусной службы будет перезаписан и поврежден, что фактически выведет Windows Defender из строя.

После перезагрузки Windows мы проверяем, удалось ли отключить Windows Defender, изучив файл его службы. Поскольку файл был изменен, он либо потерял свою цифровую подпись, либо его структура более не соответствует формату PE-файла. В обоих случаях Диспетчер управления службами Windows не сможет его запустить.

Нам удалось успешно отключить Windows Defender. Исполняемый файл антивирусной службы был поврежден, так как драйвер PROCMON24 перезаписал его содержимое. Проверка в Диспетчере служб показывает, что WinDefend не запущен.

А диспетчер управления службами сообщает о невозможности запуска службы WinDefend в журнале событий:

Однако этот метод не всегда срабатывает с первой попытки. В нескольких случаях после создания символической ссылки и включения логирования загрузки перезапись файла не удавалась. Вероятно, это связано с дополнительными условиями гонки (race conditions), которые требуют более глубокого изучения с помощью отладки ядра.

Подведем итоги

Злоумышленники постоянно ищут новые методы, чтобы "ослепить" EDR и оставаться незамеченными для системных администраторов.

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

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

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

С появлением этой техники данное ограничение снимается. Атакующие больше не зависят от поиска уязвимых драйверов. Вместо этого им достаточно найти любой драйвер с функцией записи в файл (например, для ведения журналов, трассировки и т.д.). В сочетании с символическими ссылками это выводит BYOVD на новый уровень.

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