Эволюция методов уклонения: как злоумышленники маскируются и атакуют системы защиты

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

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

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

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

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

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

Ниже приведен пример подобного события, извлеченного из журналов Sysmon:

Среди ключевых атрибутов события, за которыми следят системы мониторинга, можно выделить:

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

Какой из этих процессов покажется более подозрительным?

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

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

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

Распространенные методы включают:

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

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

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

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

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

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

Итак, создадим папку с именем 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 влечет за собой несколько серьезных последствий:

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

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

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

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

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

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

Упрощенный I/O Stack с Filter Manager

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

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

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

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

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

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

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

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

Шаг 1. Находим драйвер-минифильтр, который выполняет операцию записи в файл при загрузке системы, не требуя для этого явного вызова через IOCTL. Идеальные кандидаты – драйверы, использующие API ZwWriteFile.Шаг 2. С помощью реверс-инжиниринга или отладки определяем точный путь к файлу, в который драйвер производит запись.Шаг 3. Регистрируем найденный драйвер как службу ядра, которая будет автоматически загружаться при старте системы.Шаг 4. Создаем символическую ссылку, чтобы путь, по которому драйвер производит запись, указывал на исполняемый файл службы EDR.Шаг 5. Перезагружаем систему и проверяем, был ли исполняемый файл службы EDR поврежден или перезаписан.

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

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

Чтобы наша служба всегда выполнялась раньше службы EDR, достаточно при ее регистрации указать принадлежность к группе из семейства 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 на системе Windows 11 версии 24H2 (Сборка ОС 26100.2894) с обновлением, установленным в январе 2025 года.

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

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

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

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

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

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

Process Monitor по умолчанию записывает лог загрузки в файл C:\Windows\Procmon.pmb. Чтобы отключить Windows Defender, мы сначала активируем функцию "Boot Logging" в Process Monitor, а затем создадим символическую ссылку:mklink C:\Windows\Procmon.pmb "C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24090.11-0\MsMpEng.exe"

После создания этой ссылки мы перезагружаем Windows. В процессе загрузки драйвер PROCMON24 попытается записать данные своего журнала в файл C:\Windows\Procmon.pmb, но из-за символической ссылки фактически перезапишет и повредит исполняемый файл антивирусной службы MsMpEng.exe, что выведет Windows Defender из строя.

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

Файл Антивирусной службы (MsMpEng.exe) был перезаписан.

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

А Диспетчер управления службами фиксирует в системном журнале событий ошибку о невозможности запуска службы WinDefend.

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

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

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

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

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

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

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