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

https://forum.antichat.xyz/attachmen...a29ee57c83.png

На прошлом проекте я убил три дня на кастомный лоадер под 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-систем, которые реально работают в проектах (архитектуру 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 агент всё равно слал телеметрию - потому что не все исполняемые файлы, отправляющие отчёты, входят в захардкоженный список инструмента. Только после ручного добавления неучтённых процессов через

Код:

block

логи перестали отображаться на портале, и устройство выглядело как отключённое. Мелочь, а решает всё.

Другой вариант 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 - они запускают вредоносные действия через процессы и бинарники, которым агент доверяет. Это 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, когда инструкция

Код:

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 всё выглядит так, будто вызов пришёл из штатной библиотеки:

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) для

Код:

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:

Никогда не создавайте цепочку из нескольких LOLBins в одной сессии - разносите по времени
Используйте LOLBins, нативные для целевой среды - если в организации гоняют

Код:

curl.exe

для мониторинга, ваш

Код:

curl.exe

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

Код:

VirtualProtect

- ждём 30 секунд
Выполнение через легитимный 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. Сверяйте хэши с базой loldrivers.io. 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 заметит, что агент перестал слать телеметрию. Если ответ «никогда» - задумайтесь.