Статья Red Team vs SOC: как пентестер обходит EDR и SIEM в реальных проектах

На прошлом проекте я убил три дня на кастомный лоадер под Cobalt Strike. Шифрованный шеллкод, indirect syscalls через SysWhispers3, запуск через Early Bird APC injection в RuntimeBroker.exe. На локальном стенде - тишина, ни одного алерта в Elastic. На продакшене CrowdStrike Falcon перехватил цепочку через четыре секунды. Не бинарник, не шеллкод, не хэш - поведенческий паттерн: RuntimeBroker.exe дёрнул DNS к домену, зарегистрированному менее суток назад. Kernel callback зафиксировал создание потока, ETW-провайдер отдал DNS-телеметрию в облако, и корреляция сработала раньше, чем payload успел отстучаться на C2.

Статья записана со слов моего коллеги по работе. Текст составлен от первого лица.

Вот почему обход EDR в Red Team - это не про «скачал утилиту, запустил, работает». Это про системное понимание трёх вещей одновременно: что видит агент на эндпоинте, что попадает в SIEM, и какие корреляционные правила связывают одно с другим. Дальше разберу конкретные техники уклонения от обнаружения EDR и SIEM-систем, которые реально работают в проектах, покажу, как ваши действия выглядят со стороны SOC, и объясню, где именно ломаются стандартные подходы.

Три вектора атаки на архитектуру EDR​

Прежде чем обходить конкретный продукт - разберитесь, где у EDR вообще attack surface. Большинство материалов на русском описывают техники вроде «патчим AMSI - и всё работает», начисто игнорируя архитектуру обнаружения как систему. По данным Vectra AI, техники обхода EDR разделяются на три фундаментальных семейства - и обход одного не отключает остальные.

Blinding: ослепление без остановки агента​

Blinding-техники не убивают процесс EDR - они мешают ему собирать или передавать телеметрию. Агент выглядит работающим, статус в консоли зелёный, но данные не доходят до аналитиков. По MITRE ATT&CK это

Ссылка скрыта от гостей

, Defense Evasion).

Самый наглядный пример - EDRSilencer. Инструмент, изначально сделанный для Red Team, использует Windows Filtering Platform (WFP) для блокировки исходящего трафика EDR-агентов. По данным Trend Micro Threat Hunting Team, реальные злоумышленники уже затащили EDRSilencer в свои атаки. Он динамически определяет запущенные EDR-процессы и создаёт WFP-фильтры, блокирующие их сетевые коммуникации по IPv4 и IPv6. Фильтры помечены как persistent - переживают перезагрузку.

На практике в Trend Micro Vision One при первой попытке использования EDRSilencer агент всё равно слал телеметрию - потому что не все исполняемые файлы, отправляющие отчёты, входят в захардкоженный список инструмента. Только после ручного добавления неучтённых процессов через block <path> логи перестали отображаться на портале, и устройство выглядело как отключённое. Мелочь, а решает всё.

Другой вариант blinding - патчинг ETW в памяти процесса. Обнуляете EtwEventWrite или NtTraceEvent внутри контекста вашего лоадера - EDR-агент теряет часть телеметрии по .NET-событиям, сетевой активности и LDAP-запросам. Но kernel callbacks при этом продолжают работать - создание потоков, загрузка образов по-прежнему видны. Полуслепой агент - это не слепой агент.

Blocking: прямое убийство агента​

Blocking - самые грубые техники, которые напрямую завершают процессы EDR или блокируют их загрузку. Обычно требуют привилегий уровня ядра. По MITRE ATT&CK сюда входят Safe Mode Boot (T1562.009, Defense Evasion) и Exploitation for Privilege Escalation (T1068).

Основной инструмент - BYOVD (подробнее ниже). Альтернатива - загрузка системы в Safe Mode, где большинство EDR-агентов просто не стартуют. Техника живёт в реальных атаках: некоторые ransomware-группировки модифицируют конфигурацию загрузки через bcdedit, перезагружают хост в Safe Mode with Networking и только потом разворачивают payload. Грубо, но работает.

Hiding: выполнение в доверенном контексте​

Hiding-техники не трогают EDR - они запускают вредоносные действия через процессы и бинарники, которым агент доверяет. Это

Ссылка скрыта от гостей

, Defense Evasion) и DLL Side-Loading (T1574.002, тактики: Persistence, Privilege Escalation, Defense Evasion). EDR видит активность, но считает её легитимной.

Сюда входят LOLBins, DLL Side-Loading через доверенные приложения (PDF-ридеры, утилиты производителей оборудования), выполнение через scheduled tasks и WMI. Согласно CrowdStrike Global Threat Report за 2026 год, 82% обнаружений были malware-free - атакующие использовали легитимные инструменты, кражу учётных данных и living off the land техники, которые EDR архитектурно не способен заблокировать без ложных срабатываний на легитимную администраторскую активность. Восемьдесят два процента. Без единого бинарника.

Обход user-mode телеметрии: indirect syscalls на практике​

Исследование HookChain, представленное Helvio Carvalho Junior на DEF CON 32 (август 2024), показало кое-что занятное: 94% проанализированных EDR-решений в части user-mode hooking полагаются исключительно на перехват ntdll.dll, не устанавливая хуки на kernel32/win32u. Это позволяет обойти user-mode хуки через перенаправление вызовов. Не означает отсутствие kernel-level мониторинга - большинство enterprise EDR дополнительно используют kernel callbacks и ETW. Но HookChain достиг 88% успешного обхода на 26 протестированных EDR. Это не теория - верифицированный результат.

На практике я использую indirect syscalls, и вот почему. Direct syscalls, когда инструкция syscall выполняется прямо из вашего PE-модуля, оставляют характерный артефакт: return address в стеке указывает не на ntdll.dll, а на неизвестный регион памяти. CrowdStrike Falcon проверяет именно это - и ловит.

Indirect syscalls решают проблему. Вы находите адрес инструкции syscall; ret внутри оригинальной ntdll.dll и передаёте управление туда. При наличии inline hook в целевой Nt-функции поиск gadget в её теле может не найти syscall; ret - тогда используются техники Halo's Gate или Tartarus' Gate для определения SSN и gadget из соседних, не перехваченных Nt-функций. Для EDR всё выглядит так, будто вызов пришёл из штатной библиотеки:

// Концепция indirect syscall - поиск syscall;ret gadget в ntdll
// Это позволяет выполнить системный вызов так, что return address
// в стеке указывает на ntdll.dll, а не на наш код

BYTE* pFunction = (BYTE*)GetProcAddress(
    GetModuleHandleA("ntdll.dll"), "NtAllocateVirtualMemory");

// ВНИМАНИЕ: упрощённая демонстрация. В production-лоадере необходимо:
// 1. Реализовать Halo's Gate / Tartarus' Gate для определения SSN при наличии хуков
// 2. Искать gadget в соседних Nt-функциях, если текущая захукана
// 3. Валидировать найденный gadget перед использованием
// Ищем опкоды: 0F 05 (syscall) + C3 (ret)
// При наличии inline hook пролог перезаписан и поиск ниже может не найти gadget
BYTE* gadgetAddr = NULL;
for (int offset = 0; offset < 64; offset++) {
    if (pFunction[offset] == 0x0F && pFunction[offset + 1] == 0x05) {
        gadgetAddr = &pFunction[offset];
        break;
    }
}
// Далее: помещаем номер syscall в EAX, аргументы в регистры,
// и делаем JMP на gadgetAddr вместо прямого syscall

Но даже indirect syscalls - не серебряная пуля. Аллоцируете RWX-память через NtAllocateVirtualMemory, потом создаёте удалённый поток через NtCreateThreadEx в чужом процессе - kernel callback на PsSetCreateThreadNotifyRoutine всё равно сработает. User-mode evasion бесполезна против kernel-level мониторинга. Точка.

Поэтому эффективный обход EDR в Red Team - всегда комбинация: indirect syscalls + шифрованный шеллкод + правильный выбор целевого процесса + контроль временных интервалов между подозрительными действиями.

Атакующий загружает легитимный, подписанный Microsoft драйвер с известной уязвимостью и через неё получает выполнение кода на уровне ядра Windows. Оттуда - завершение процессов EDR, отключение телеметрии, установка руткитов. По MITRE ATT&CK это Exploitation for Privilege Escalation (T1068) и Rootkit (T1014, Defense Evasion - техника описана MITRE для множества платформ, однако публичные тесты Atomic Red Team на данный момент существуют только для Linux).

Техника давно вышла из арсенала государственных группировок в широкий оборот - RansomHub, BlackByte, Akira и Scattered Spider активно используют BYOVD. EDRKillShifter работает как BYOVD-as-a-service для криминальной среды.

Конкретный пример: ransomware Reynolds встроил уязвимый драйвер NSecsoft NSecKrnl (CVE-2025-68947, CVSS 5.7 MEDIUM по вектору CVSS:4.0/AV:L/AC:H/AT/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N) непосредственно в payload. Уязвимость позволяет локальному аутентифицированному атакующему завершать процессы других пользователей, включая SYSTEM и Protected Processes, через специально сформированные IOCTL-запросы к драйверу (CWE-862 - отсутствие авторизации). Казалось бы, CVSS 5.7 - ерунда. Но в BYOVD-сценарии атакующий уже имеет локальный доступ, а единственная цель - убить процесс EDR (availability impact), и этого достаточно для дальнейшего развития атаки. Убийство агента стало частью самого ransomware - никакого отдельного EDR-killer.

Ещё один задокументированный кейс: кампания с драйвером TrueSight, в которой было развёрнуто более 2500 вариантов драйвера между серединой 2024 и началом 2025 года, по данным Vectra AI.

Обнаружение BYOVD: окно закрывается быстро​

Критический момент для SOC - BYOVD нужно обнаружить до того, как эксплойт отработает. После того как EDR убит, телеметрия перестаёт генерироваться. Окно узкое.

Основной источник детекта - Sysmon Event ID 6 (Driver Loaded), кросс-ссылка с хэшами известных уязвимых драйверов. Для Red Team это значит: используете известный драйвер без модификации - у SOC есть шанс вас поймать. Нашли zero-day в менее известном драйвере - шанс стремится к нулю.

# Sigma-правило (концепция) для детекта загрузки уязвимого драйвера
# Проверьте хэши против loldrivers.io
title: Suspicious Vulnerable Driver Loaded
logsource:
    product: windows
    service: sysmon
    category: driver_loaded
detection:
    selection:
        # EventID: 6 уже подразумевается category: driver_loaded
        # Хэш-детект легко обходится модификацией padding/ресурсов драйвера -
        # дополните правилом на основе имени, подписи, imphash или authentihash (см. loldrivers.io)
        Hashes|contains:
            - 'SHA256=<hash_of_known_vulnerable_driver>'
    condition: selection

Обход SIEM алертов: как Red Team работает в слепой зоне SOC​

Тут начинается территория, которую русскоязычные материалы практически не покрывают. Обойти EDR - полдела. Вторая половина - не попасть в корреляционные правила SIEM. В реальном проекте SOC работает с Elastic, Splunk или аналогом, где настроены десятки правил корреляции. Каждое ваше действие генерирует события, и задача - понимать, какие именно.

Какие Event ID генерирует lateral movement​

Когда вы делаете lateral movement через WMI, генерируются:

• Event ID 4624 (Logon Type 3 - Network) на целевом хосте
• Event ID 4688 (Process Creation) для WmiPrvSE.exe, который порождает ваш payload
• Sysmon Event ID 1 (Process Create) с ParentImage: WmiPrvSE.exe

SOC-аналитик, который видит WmiPrvSE.exe как parent process для cmd.exe или powershell.exe с нехарактерными аргументами, немедленно эскалирует. То же с DCOM - mmc.exe (T1218.014, Defense Evasion) или excel.exe через DCOM (T1021.003, Lateral Movement; по LOLBAS для excel.exe также релевантна T1105), порождающие дочерние процессы (cmd.exe, powershell.exe), вызывают срабатывание поведенческих правил.

Living off the Land через призму SIEM​

Living off the Land (LOLBins) - техника System Binary Proxy Execution (T1218, Defense Evasion), при которой атакующий использует штатные Windows-утилиты вместо собственного вредоносного ПО. По данным CrowdStrike, 79% обнаружений атак не включали malware вообще.

Январская 2026 года кампания с Remcos/NetSupport RAT, описанная Hive Security, прошла путь от фишингового письма до persistent remote access, используя ноль кастомного ПО - каждый шаг через подписанный Microsoft бинарник. Kill chain: forfiles (T1202) -> mshta (T1218.005) -> PowerShell (T1059.001) -> curl.exe (T1105) -> tar.exe (T1105) -> persistence через reg.exe (T1112). Примечание: ATT&CK-идентификаторы указаны для каждого бинарника по его основной роли в цепочке; для tar.exe по LOLBAS также релевантна T1564.004, для reg.exe - T1003.002 и T1564.004.

Для SIEM-аналитика каждая утилита по отдельности легитимна. Но цепочка - mshta.exe, запущенный из forfiles.exe, который запускает PowerShell - аномалия. Проблема в том, что для более новых LOLBins (curl.exe (T1105), tar.exe (T1105), MAVInject.exe (T1218.013)) покрытие детекшн-правил значительно слабее, чем для классических.

Мой практический подход к уклонению от обнаружения через SIEM при использовании LOLBins:

1. Никогда не создавайте цепочку из нескольких LOLBins в одной сессии - разносите по времени
2. Используйте LOLBins, нативные для целевой среды - если в организации гоняют curl.exe для мониторинга, ваш curl.exe будет неотличим
3. Аргументы командной строки должны быть неотличимы от легитимных - Sysmon Event ID 1 логирует полную командную строку

C2 через доверенные сервисы: SIEM не детектирует​

Современный C2 не требует собственной инфраструктуры. По данным Hive Security, атакующие используют сервисы, которым организация уже доверяет - GitHub, Google Docs, Discord, Slack, Notion - как dead-drop для команд и эксфильтрации. C2-трафик сливается с легитимным HTTPS к известным доменам. Firewall-правила и proxy allowlists, разрешающие трафик к GitHub, автоматически разрешают и C2.

Telegram Bot API - отдельная песня. Эндпоинт api.telegram.org - домен, который большинство организаций либо напрямую разрешают, либо не могут заблокировать без нарушения бизнес-процессов. Для SIEM это обычный HTTPS к высокорепутационному домену.

На проектах я делаю так: C2-коммуникации идут через сервис, который целевая организация и так использует. У клиента Slack - C2 через Slack API. Корреляционное правило, которое поймает это, должно анализировать не destination domain, а паттерн запросов - периодичность, размер ответов, аномальные эндпоинты. Большинство SIEM-инсталляций таких правил не имеют.

BOF-цепочки и time-differential evasion техники​

BOF: выполнение в памяти без создания процессов​

Ссылка скрыта от гостей

(BOF) - один из самых эффективных подходов для уклонения от обнаружения EDR при постэксплуатации. BOF - скомпилированный объектный файл на C, который загружается и исполняется непосредственно в памяти процесса Beacon. Без создания нового процесса, без записи на диск, без порождения дочерних процессов.

Почему это критично: большинство поведенческих правил EDR триггерятся на Process Injection (T1055, Defense Evasion) - создание удалённого потока, запись в чужую память, появление нового процесса. BOF обходит всё это, потому что выполняется в уже существующем контексте. Нет нового процесса - нет Sysmon Event ID 1. Нет удалённого потока - нет callback от PsSetCreateThreadNotifyRoutine.

// Пример концепции BOF - сбор информации о домене
// Компилируется в .o файл и загружается в Beacon
// Не создаёт новых процессов

#include <windows.h>
#include "beacon.h"  // Cobalt Strike BOF API

// Динамическое определение функций через BOF API
// BOF Dynamic Function Resolution: LIBRARY$Function convention
// Компиляция: x86_64-w64-mingw32-gcc -c bof.c -o bof.o
// Требует beacon.h из Cobalt Strike toolkit
DECLSPEC_IMPORT NET_API_STATUS WINAPI NETAPI32$DsGetDcNameA(
    LPCSTR, LPCSTR, GUID*, LPCSTR, ULONG, PDOMAIN_CONTROLLER_INFOA*);

void go(char* args, int len) {
    PDOMAIN_CONTROLLER_INFOA dcInfo;
    DWORD result = NETAPI32$DsGetDcNameA(
        NULL, NULL, NULL, NULL, 0, &dcInfo);
    if (result == ERROR_SUCCESS) {
        BeaconPrintf(CALLBACK_OUTPUT,
            "DC: %s", dcInfo->DomainControllerName);
    }
    // Пример для демонстрации концепции
}

Ограничение BOF: они работают в контексте Beacon-процесса. Если BOF дёрнет сетевое API или сделает LDAP-запрос, ETW-провайдер это зафиксирует. BOF не делает вас невидимым - он убирает один уровень видимости (process creation). Остальные уровни телеметрии никуда не деваются.

Time-differential атаки: эксплуатация задержки обработки EDR​

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

Time-differential атака разносит подозрительные действия по времени так, чтобы каждое действие в отдельности не превышало порог срабатывания, а корреляционное окно EDR не успевало связать их в цепочку. Оговорка: зрелые EDR (CrowdStrike Falcon, SentinelOne) отслеживают контекст процесса на протяжении всего его жизненного цикла, и задержки внутри одного процесса против них неэффективны. Техника работает преимущественно против EDR с фиксированными временными окнами корреляции и без облачной аналитики. Для обхода зрелых EDR эффективнее разносить шаги по разным процессам. Пример с задержками в одном процессе:

1. Выделение RW-памяти (без Execute) - ждём 30 секунд
2. Запись зашифрованного шеллкода - ждём 60 секунд
3. Изменение защиты на RX через VirtualProtect - ждём 30 секунд
4. Выполнение через легитимный callback (EnumWindows)

Каждый шаг в отдельности - нормальная операция. VirtualAlloc с PAGE_READWRITE - штатный вызов. VirtualProtect на PAGE_EXECUTE_READ - используется легитимными JIT-компиляторами. EnumWindows с callback - обычная работа с GUI. Но вместе они образуют injection chain. Задержки между шагами могут вынудить EDR с фиксированными окнами корреляции анализировать каждый шаг изолированно. Против зрелых EDR с process lifecycle tracking эта техника в рамках одного процесса не работает - нужно разносить шаги по разным процессам.

Практический workflow обхода EDR и SIEM в проекте​

Как выглядит реальная последовательность действий в Red Team проекте с полным стеком защиты (EDR + SIEM + SOC):

📚 Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Когда EDR всё-таки побеждает: уроки провалов​

Было бы нечестно описывать только успешные обходы. Три сценария из моей практики, когда EDR и SOC выиграли:

Провал 1: Облачная корреляция. Indirect syscalls обошли user-mode хуки, но CrowdStrike Falcon отправил kernel callback телеметрию в облако, где ML-модель определила аномальную последовательность: explorer.exe -> forfiles.exe -> unnamed process делает DNS-запрос к young domain. Время до алерта - менее минуты. Обидно.

Провал 2: Memory scan. SentinelOne периодически сканирует RX-страницы памяти процессов. Шеллкод был зашифрован при загрузке, но после дешифровки в памяти сигнатура C2-фреймворка (Cobalt Strike sleep mask configuration) была обнаружена при плановом сканировании. Урок: используйте sleep mask с шифрованием beacon-конфигурации в памяти или переходите на менее «засвеченные» фреймворки (Havoc, Sliver).

Провал 3: SOC-аналитик нашёл вручную. SIEM не сгенерировал алерт, EDR не заблокировал. Но SOC-аналитик на threat hunting заметил нетипичный паттерн: scheduled task с именем, похожим на легитимное, но с отличием в одну букву. Ручной анализ выявил весь kill chain. Напоминание: автоматизация - не единственный ваш противник. Человек с кофе в 3 ночи тоже опасен.

Bypass CrowdStrike Falcon: специфика вендора​

CrowdStrike заслуживает отдельного разговора - это EDR, с которым Red Team сталкивается чаще всего в enterprise-среде. В версиях 2023+ Falcon преимущественно опирается на kernel-level телеметрию и ETW, а user-mode hooking отошёл на второй план. Классический unhooking NTDLL - необходимый, но недостаточный шаг.

Kernel-mode драйвер csagent.sys регистрирует callbacks через PsSetCreateProcessNotifyRoutine, PsSetCreateThreadNotifyRoutine и PsSetLoadImageNotifyRoutine. Minifilter-драйвер перехватывает файловые операции. Отключить это из user-mode невозможно - от слова совсем.

В одном из публичных отчётов CISA о red team assessment критической инфраструктуры США отмечалось, что EDR-решения обнаружили «лишь несколько» из развёрнутых payload'ов (контекст мог включать неоптимальную настройку EDR). При определённых условиях обход возможен - но требует комбинации техник и глубокого понимания конкретного продукта.

Рекомендации для Purple Team​

Если вы читаете это как SOC-аналитик - вот что поможет ловить описанные техники:

Мониторинг WFP-фильтров. EDRSilencer и аналоги создают persistent WFP-фильтры. Мониторьте создание новых WFP-фильтров через аудит - для большинства бизнес-приложений это нетипичная операция.

Sysmon Event ID 6. Загрузка любого неизвестного драйвера - потенциальный BYOVD. Сверяйте хэши с базой

Ссылка скрыта от гостей

. HVCI (Hypervisor-protected Code Integrity) и WDAC (Windows Defender Application Control) - основные контрмеры, блокирующие загрузку уязвимых драйверов.

Baseline LOLBin usage. Создайте профиль нормального использования mshta.exe, certutil.exe, regsvr32.exe в вашей среде. Любое отклонение - parent process, аргументы, время суток - повод для расследования.

Network anomaly detection. Когда EDR ослеплён, сетевая телеметрия - единственный источник правды. NDR-решения видят lateral movement, C2-коммуникации и exfiltration даже при полностью скомпрометированном эндпоинте. По данным ExtraHop, атакующие могут отключить агентов, но не могут изменить то, как их поведение выглядит в сетевом трафике.

Корреляция по времени. Time-differential атаки работают против фиксированных временных окон. Расширяйте окна для связки VirtualAlloc -> VirtualProtect -> execution callback до минут, а не секунд.

Обход EDR и SIEM в Red Team - не список «трюков», а системная дисциплина. Нужно понимать архитектуру обнаружения на уровне ядра, телеметрии и корреляционных правил. Каждый проект уникален: техника, которая обходит CrowdStrike, может провалиться против SentinelOne - и наоборот. Единственная универсальная стратегия - знать, что видит защитник, и действовать в его слепых зонах. Проверьте свой стек: запустите EDRSilencer на стенде и посмотрите, через сколько секунд SOC заметит, что агент перестал слать телеметрию. Если ответ «никогда» - задумайтесь.