На прошлом проекте я убил три дня на кастомный лоадер под Cobalt Strike. Шифрованный шеллкод, indirect syscalls через SysWhispers3, запуск через Early Bird APC injection в
. На локальном стенде - тишина, ни одного алерта в Elastic. На продакшене CrowdStrike Falcon перехватил цепочку через четыре секунды. Не бинарник, не шеллкод, не хэш - поведенческий паттерн:
дёрнул DNS к домену, зарегистрированному менее суток назад. Kernel callback зафиксировал создание потока, ETW-провайдер отдал DNS-телеметрию в облако, и корреляция сработала раньше, чем payload успел отстучаться на C2.
Статья записана со слов моего коллеги по работе. Текст составлен от первого лица.
Вот почему обход EDR в Red Team - это не про «скачал утилиту, запустил, работает». Это про системное понимание трёх вещей одновременно: что видит агент на эндпоинте, что попадает в SIEM, и какие корреляционные правила связывают одно с другим. Дальше разберу конкретные техники уклонения от обнаружения EDR и SIEM-систем, которые реально работают в проектах (архитектуру C2-фреймворков и разработку кастомных имплантов под это я разобрал в
полном руководстве по разработке Red Team инструментов), покажу, как ваши действия выглядят со стороны SOC, и объясню, где именно ломаются стандартные подходы.
Три вектора атаки на архитектуру EDR
Прежде чем обходить конкретный продукт - разберитесь, где у EDR вообще attack surface. Большинство материалов на русском описывают техники вроде «патчим AMSI - и всё работает», начисто игнорируя архитектуру обнаружения как систему. По данным Vectra AI, техники обхода EDR разделяются на три фундаментальных семейства - и обход одного не отключает остальные.
Blinding: ослепление без остановки агента
Blinding-техники не убивают процесс EDR - они мешают ему собирать или передавать телеметрию. Агент выглядит работающим, статус в консоли зелёный, но данные не доходят до аналитиков. По MITRE ATT&CK это Indicator Blocking (T1562.006, 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 агент всё равно слал телеметрию - потому что не все исполняемые файлы, отправляющие отчёты, входят в захардкоженный список инструмента. Только после ручного добавления неучтённых процессов через
логи перестали отображаться на портале, и устройство выглядело как отключённое. Мелочь, а решает всё.
Другой вариант blinding -
патчинг ETW в памяти процесса. Обнуляете
или
внутри контекста вашего лоадера - 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-группировки модифицируют конфигурацию загрузки через
, перезагружают хост в Safe Mode with Networking и только потом разворачивают payload. Грубо, но работает.
Hiding: выполнение в доверенном контексте
Hiding-техники не трогают EDR - они запускают вредоносные действия через процессы и бинарники, которым агент доверяет. Это System Binary Proxy Execution (T1218, 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, когда инструкция
выполняется прямо из вашего PE-модуля, оставляют характерный артефакт: return address в стеке указывает не на
, а на неизвестный регион памяти. CrowdStrike Falcon проверяет именно это - и ловит.
Indirect syscalls решают проблему. Вы находите адрес инструкции
внутри оригинальной
и передаёте управление туда. При наличии inline hook в целевой Nt-функции поиск gadget в её теле может не найти
- тогда используются техники Halo's Gate или Tartarus' Gate для определения SSN и gadget из соседних, не перехваченных Nt-функций. Для EDR всё выглядит так, будто вызов пришёл из штатной библиотеки:
C:
Код:
// Концепция 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
'
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) для
, который порождает ваш payload
- Sysmon Event ID 1 (Process Create) с
Код:
ParentImage: WmiPrvSE.exe
SOC-аналитик, который видит
как parent process для
или
с нехарактерными аргументами, немедленно эскалирует. То же с DCOM -
(T1218.014, Defense Evasion) или
через DCOM (T1021.003, Lateral Movement; по LOLBAS для excel.exe также релевантна T1105), порождающие дочерние процессы (
,
), вызывают срабатывание поведенческих правил.
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:
(T1202) ->
(T1218.005) -> PowerShell (T1059.001) ->
(T1105) ->
(T1105) -> persistence через
(T1112). Примечание: ATT&CK-идентификаторы указаны для каждого бинарника по его основной роли в цепочке; для
по LOLBAS также релевантна T1564.004, для
- T1003.002 и T1564.004.
Для SIEM-аналитика каждая утилита по отдельности легитимна. Но цепочка -
, запущенный из
, который запускает PowerShell - аномалия. Проблема в том, что для более новых LOLBins (
(T1105),
(T1105),
(T1218.013)) покрытие детекшн-правил значительно слабее, чем для классических.
Мой практический подход к уклонению от обнаружения через SIEM при использовании LOLBins:
- Никогда не создавайте цепочку из нескольких LOLBins в одной сессии - разносите по времени
- Используйте LOLBins, нативные для целевой среды - если в организации гоняют
для мониторинга, ваш
будет неотличим
- Аргументы командной строки должны быть неотличимы от легитимных - 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 - отдельная песня. Эндпоинт
- домен, который большинство организаций либо напрямую разрешают, либо не могут заблокировать без нарушения бизнес-процессов. Для SIEM это обычный HTTPS к высокорепутационному домену.
На проектах я делаю так: C2-коммуникации идут через сервис, который целевая организация и так использует. У клиента Slack - C2 через Slack API. Корреляционное правило, которое поймает это, должно анализировать не destination domain, а паттерн запросов - периодичность, размер ответов, аномальные эндпоинты. Большинство SIEM-инсталляций таких правил не имеют.
BOF-цепочки и time-differential evasion техники
BOF: выполнение в памяти без создания процессов
Beacon Object Files (BOF) - один из самых эффективных подходов для уклонения от обнаружения EDR при постэксплуатации. BOF - скомпилированный объектный файл на C, который загружается и исполняется непосредственно в памяти процесса Beacon. Без создания нового процесса, без записи на диск, без порождения дочерних процессов.
Почему это критично: большинство поведенческих правил EDR триггерятся на Process Injection (T1055, Defense Evasion) - создание удалённого потока, запись в чужую память, появление нового процесса. BOF обходит всё это, потому что выполняется в уже существующем контексте. Нет нового процесса - нет Sysmon Event ID 1. Нет удалённого потока - нет callback от
Код:
PsSetCreateThreadNotifyRoutine
.
C:
Код:
// Пример концепции BOF - сбор информации о домене
// Компилируется в .o файл и загружается в Beacon
// Не создаёт новых процессов
#include
#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 эффективнее разносить шаги по разным процессам. Пример с задержками в одном процессе:
- Выделение RW-памяти (без Execute) - ждём 30 секунд
- Запись зашифрованного шеллкода - ждём 60 секунд
- Изменение защиты на RX через
- ждём 30 секунд
- Выполнение через легитимный callback (
)
Каждый шаг в отдельности - нормальная операция.
с
- штатный вызов.
на
- используется легитимными JIT-компиляторами.
с 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-модель определила аномальную последовательность:
->
-> 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 драйвер
регистрирует 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. Сверяйте хэши с базой loldrivers.io. HVCI (Hypervisor-protected Code Integrity) и WDAC (Windows Defender Application Control) - основные контрмеры, блокирующие загрузку уязвимых драйверов.
Baseline LOLBin usage. Создайте профиль нормального использования
,
,
в вашей среде. Любое отклонение - parent process, аргументы, время суток - повод для расследования.
Network anomaly detection. Когда EDR ослеплён, сетевая телеметрия - единственный источник правды. NDR-решения видят lateral movement, C2-коммуникации и exfiltration даже при полностью скомпрометированном эндпоинте. По данным ExtraHop, атакующие могут отключить агентов, но не могут изменить то, как их поведение выглядит в сетевом трафике.
Корреляция по времени. Time-differential атаки работают против фиксированных временных окон. Расширяйте окна для связки
->
-> execution callback до минут, а не секунд.
Обход EDR и SIEM в Red Team - не список «трюков», а системная дисциплина. Нужно понимать архитектуру обнаружения на уровне ядра, телеметрии и корреляционных правил. Каждый проект уникален: техника, которая обходит CrowdStrike, может провалиться против SentinelOne - и наоборот. Единственная универсальная стратегия - знать, что видит защитник, и действовать в его слепых зонах. Проверьте свой стек: запустите EDRSilencer на стенде и посмотрите, через сколько секунд SOC заметит, что агент перестал слать телеметрию. Если ответ «никогда» - задумайтесь.
Линейный вид
