Попытки обхода Windows Defender глазами защитника: сигналы, телеметрия и укрепление детекта

Windows Defender (Microsoft Defender Antivirus) остаётся базовым слоем защиты на большинстве корпоративных рабочих станций. Атакующие активно развивают техники обхода его детекта, но каждая такая техника оставляет наблюдаемые артефакты. Эта статья разбирает основные категории обхода с позиции защитника: какие сигналы генерируются, где их искать и как усилить детект.

Прямые системные вызовы: почему они обходят userland-хуки​

Стандартный путь вызова ядра на Windows проходит через ntdll.dll, где каждая функция-заглушка выполняет последовательность mov r10, rcx → mov eax, <syscall_number> → syscall. EDR-продукты часто ставят inline-хуки на эти заглушки, перехватывая вызовы до их ухода в ядро.

Техника прямых системных вызовов (direct syscalls) обходит этот слой: вредоносный код самостоятельно формирует инструкцию syscall с нужным номером, минуя ntdll.dll полностью. Вариант Hell's Gate динамически извлекает номера системных вызовов из экспортируемых функций ntdll.dll на этапе выполнения, парся байтовый паттерн заглушки:

; Типичная заглушка в ntdll.dll (x64):
; 4C 8B D1       mov r10, rcx
; B8 XX XX 00 00 mov eax, <syscall_number>
; ...
; 0F 05          syscall

Код извлекает XX XX — номер системного вызова — и сохраняет его в таблицу (VX_TABLE), после чего выполняет syscall напрямую из собственного ассемблерного модуля.

Что видит защитник​

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

• Процесс выполняет syscall из региона памяти, не принадлежащего ntdll.dll. ETW-провайдер Microsoft-Windows-Kernel-Audit-API-Calls и ядро фиксируют адрес возврата вызова.
  
• Последовательность вызовов нетипична для процесса. Например, notepad.exe вызывает NtCreateSection + NtMapViewOfSection + NtCreateThreadEx — это аномальная цепочка.
  
• Отсутствие стека вызовов через ntdll.dll. При анализе стека потока в момент системного вызова фрейм возврата указывает не на заглушку ntdll, а на произвольный адрес.
  

Инъекция через section mapping без VirtualAllocEx​

Классическая инъекция через VirtualAllocEx + WriteProcessMemory + CreateRemoteThread хорошо детектируется. Альтернатива — использование объектов раздела (section):

1. NtCreateSection создаёт раздел с правами PAGE_EXECUTE_READWRITE.
   
2. NtMapViewOfSection проецирует его в локальный процесс (для записи payload).
   
3. Тот же раздел проецируется в целевой процесс с правами на исполнение.
   
4. NtCreateThreadEx запускает поток по адресу спроецированного кода.
   

Преимущество для атакующего: нет вызовов VirtualAllocEx и WriteProcessMemory, которые традиционно мониторятся. Память появляется в целевом процессе как результат проекции раздела — механизма, который активно используется легитимным ПО (DLL-загрузчик, shared memory).

Сигналы для детекта​

Наблюдение	Источник телеметрии	Почему аномально
Раздел создан с PAGE_EXECUTE_READWRITE	ETW Microsoft-Windows-Kernel-Memory	Легитимные разделы редко требуют одновременной записи и исполнения
Раздел спроецирован в чужой процесс	Sysmon Event ID 10 (ProcessAccess) с SECTION_MAP_WRITE + SECTION_MAP_EXECUTE	Нетипичная комбинация прав для межпроцессного взаимодействия
Поток создан в удалённом процессе с адресом из спроецированного раздела	Sysmon Event ID 8 (CreateRemoteThread)	Прямой индикатор инъекции
Раздел не имеет backing file	Ядро, NtQuerySection	Legitimate shared memory обычно привязан к файлу или именован

Хеширование имён API: зачем и как детектировать​

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

Типичная реализация использует Jenkins One-at-a-Time hash с начальным значением (seed). В рассмотренном примере seed равен 8, а макрос HASHA(API) вычисляет хеш на этапе компиляции.

Что это даёт защитнику​

• Статический анализ: обход таблицы экспорта (чтение AddressOfNames, AddressOfFunctions, AddressOfNameOrdinals) с последующим сравнением хешей — характерный паттерн. Дизассемблирование выявляет циклы с арифметическими операциями add, xor, shr, shl, типичными для хеш-функций.
  
• Поведенческий анализ: процесс читает PE-заголовок и экспортную таблицу ntdll.dll вручную, без использования GetProcAddress или LdrGetProcedureAddress. Это фиксируется через мониторинг доступа к памяти другого модуля.
  
• YARA-правила: можно написать правила на характерные константы (seed, начальные значения хешей) и последовательности инструкций, если известен конкретный инструмент.
  

Отключение и ослепление Defender​

Прямое отключение — грубая, но всё ещё встречающаяся техника:

• Через WMI: Set-MpPreference -DisableRealtimeMonitoring $true (требует прав администратора).
  
• Через реестр: запись в HKLM\SOFTWARE\Policies\Microsoft\Windows Defender.
  
• Через службу: остановка WinDefend через sc stop или манипуляцию с Service Control Manager.
  
• Через WMI-класс MSFT_MpPreference: вызов методов WMI-провайдера Defender.
  

Телеметрия отключения​

Windows Defender генерирует события при изменении собственной конфигурации:

• Event ID 5007 (Microsoft-Windows-Windows Defender/Operational): изменение конфигурации.
  
• Event ID 5001: отключение сканирования в реальном времени.
  
• Event ID 1011: удаление исключения (если атакующий сначала добавляет исключение, потом удаляет следы).
  
• Sysmon Event ID 13 (RegistryEvent): запись в ключи политик Defender.
  

Критически важно: если Defender отключён и не сгенерировал событие — это само по себе индикатор компрометации. Настройка аудита должна включать мониторинг состояния службы WinDefend через внешний watchdog.

Многослойная модель детекта​

Ни один отдельный сигнал не даёт полной картины. Эффективная защита строится на корреляции:

Уровень 1: ETW и ядро​

ETW-провайдеры ядра (Microsoft-Windows-Kernel-Process, Microsoft-Windows-Kernel-Memory, Microsoft-Windows-Kernel-Audit-API-Calls) дают низкоуровневую телеметрию, которую сложно подавить из user mode. Однако атакующий может попытаться отключить ETW-сессию через NtTraceControl — это тоже наблюдаемое событие.

Уровень 2: Sysmon и EDR​

Sysmon с правильно настроенной конфигурацией фиксирует:

• Создание потоков в удалённых процессах (Event ID 8).
  
• Доступ к процессам с подозрительными правами (Event ID 10).
  
• Загрузку образов из нестандартных путей (Event ID 7).
  
• Изменение реестра в ключах безопасности (Event ID 13).
  

Уровень 3: Поведенческая корреляция​

Отдельные события могут быть легитимными. Детект строится на цепочках:

NtCreateSection(EXECUTE_READWRITE) 
  → NtMapViewOfSection(в чужой процесс) 
    → NtCreateThreadEx(адрес из раздела)

Такая последовательность в рамках одного процесса-источника с высокой вероятностью означает инъекцию.

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

1. Включить Attack Surface Reduction (ASR) правила. Правило «Block process creations originating from PSExec and WMI commands» и «Block executable files from running unless they meet a prevalence, age, or trusted criterion» закрывают часть векторов.
   
2. Настроить Sysmon на минимально необходимый набор Event ID. Event ID 8, 10, 7, 13 — базовый минимум для детекта инъекций и манипуляций с Defender.
   
3. Мониторить состояние службы WinDefend. Внешний watchdog (через Task Scheduler, SCCM или отдельный агент) должен алертить при остановке или изменении конфигурации службы.
   
4. Использовать Credential Guard и HVCI. Виртуализация безопасности усложняет инъекцию в защищённые процессы и ограничивает доступ к LSASS.
   
5. Коррелировать события из разных источников. Один Sysmon не даст полной картины. Комбинация ETW + Sysmon + Windows Event Log позволяет выявлять цепочки, которые по отдельности выглядят безобидно.
   
6. Проверять целостность конфигурации Defender. Регулярный аудит Get-MpPreference на соответствие baseline: отсутствие несанкционированных исключений, включённый realtime monitoring, актуальные сигнатуры.
   

Ограничения защитника​

• Прямые системные вызовы невозможно заблокировать на уровне ядра без нарушения совместимости — ядро не различает, кто выполняет syscall.
  
• ETW-телеметрию можно подавить из kernel mode (драйвер с правами администратора может остановить сессию).
  
• Если атакующий получил SYSTEM и может загружать драйверы, большинство userland-детектов обходятся.
  
• Defender не является EDR: его поведенческий анализ ограничен по сравнению с полноценными EDR-решениями, которые коррелируют события в облаке.
  

Защита от обхода Defender — это не одна настройка, а процесс построения многослойной телеметрии, где каждый слой компенсирует слепые зоны предыдущего.

Источники​

• Цикл статей "Изучение вредоносных программ" | Обход Windows defender | Osint42.Org - Безопасность и код
  
• OWASP Top Ten Web Application Security Risks | OWASP Foundation
  
• MITRE ATT&CK®