ANTICHAT - Обход EDR российские решения: PT Sandbox, Kaspersky EDR и SEKOIA

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

Каждый второй «обзор российских EDR» - пересказ маркетинговых PDF вендора со скриншотами дашбордов. Красивые графики, зелёные галочки, «99.7% детектирования». Ни одна русскоязычная статья не отвечает на вопрос, который реально волнует Red Team оператора: где у этих решений слепые пятна? Какие техники обхода работают прямо сейчас, а какие уже закрыли? В итоге пентестеры выходят на engagement вслепую и тратят часы на разведку того, что давно пора задокументировать.

Попробуем это исправить. Разберём архитектуру детектирования PT Sandbox, Kaspersky EDR Expert и SEKOIA XDR, пройдёмся по техникам обхода с привязкой к MITRE ATT&CK и дадим методологию тестирования, которую можно адаптировать под конкретный проект.

Оговорка: все техники - только для авторизованного тестирования. Цель - повышение качества защиты через adversary simulation, а не руководство к действию для вражески настроенной публики.
Что российские EDR реально мониторят: архитектура детектирования
Прежде чем обходить EDR, нужно понять, как он «видит» мир. Разница между решениями существенна - у каждого свои приоритеты в сборе телеметрии.
Kaspersky EDR Expert: ядро, ETW и userland
Kaspersky EDR Expert - наиболее зрелый зверь из тройки с точки зрения endpoint-агента. Архитектура опирается на несколько источников телеметрии: kernel-mode callbacks для мониторинга создания процессов, загрузки модулей и операций с реестром; подписка на ETW-провайдеры (

Код:

Microsoft-Windows-Kernel-Process

Код:

Microsoft-Windows-Kernel-File

Код:

DotNET

и другие); плюс, предположительно, userland-хуки на ntdll.dll (объём варьируется в зависимости от версии агента - публичных исследований, подтверждающих конкретный список хуков, я не нашёл).

По результатам независимого тестирования AV-TEST (декабрь 2023 - март 2024) Kaspersky EDR Expert показал высокий уровень детектирования в двух сценариях: атака в стиле APT18 (фишинг + обнаружение систем + обфускация данных) и атака с тактиками TA577/Turla/FIN6 (фишинг, манипуляция данными, lateral movement). Продукт получил сертификацию AV-TEST Approved Advanced EDR. Переводя на практический язык: «коробочные» техники из публичных фреймворков здесь не пройдут - нужна серьёзная кастомизация.
PT Sandbox и MaxPatrol EDR: акцент на динамический анализ
PT Sandbox - это в первую очередь песочница для динамического анализа, а не классический EDR-агент. Решение Positive Technologies для защиты конечных точек - MaxPatrol EDR, работающий в связке с MaxPatrol SIEM и PT Sandbox. Архитектура PT Sandbox делает ставку на поведенческий анализ в контролируемой среде: файл запускается в изолированной VM, система фиксирует API-вызовы, сетевые соединения, изменения файловой системы и реестра.

Ключевое отличие от Kaspersky: PT Sandbox - дополнительный эшелон, а не единственная линия обороны на хосте. По собственным данным Positive Technologies, 74% российских компаний считают себя недостаточно защищёнными от целевых атак, а 73% называют обнаружение таких атак главной задачей. Отсюда и фокус PT на комбинацию EPP + EDR + Sandbox - «матрёшка» из защитных слоёв.
SEKOIA XDR: европейская платформа в российских реалиях
SEKOIA.IO - европейская SOC-платформа (SIEM/SOAR/TI) с сильным модулем Threat Intelligence и SOAR-функциями. В отличие от «тяжёлых» агентских решений, у SEKOIA нет собственного endpoint-агента - endpoint-телеметрию платформа получает через сторонних агентов (Sysmon, Microsoft Defender, Wazuh и др.), а сама занимается кросс-доменной корреляцией событий. Это снижает нагрузку на хосты, но создаёт слепые пятна: глубина мониторинга определяется возможностями стороннего агента, а не самой SEKOIA.

Для Red Team оператора это означает три разных подхода к тестированию: против Kaspersky EDR придётся работать с обходом хуков и kernel callbacks; против PT Sandbox - с anti-sandbox техниками (Virtualization/Sandbox Evasion, T1497); а тестирование SEKOIA потребует оценки глубины телеметрии конкретного агента, который поставляет ей данные, плюс обхода корреляционных правил платформы.

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

Требования к лабораторной среде
Перед тем как переходить к конкретным EDR bypass техникам, зафиксируем лабораторные условия. Без контролируемой среды любые выводы - гадание на кофейной гуще.

ОС: Windows 10/11 Enterprise (21H2+), Windows Server 2019/2022. Для Linux-хостов - CentOS 8/Ubuntu 22.04
Инструменты анализа: Process Hacker 2 (или System Informer), PE-sieve, hollows_hunter, API Monitor, IDA Pro / Binary Ninja
Фреймворки: Cobalt Strike 4.9+ с кастомным Malleable C2-профилем, Havoc Framework, самописный loader на C/Rust
Сеть: изолированный VLAN с контролируемым выходом в интернет. EDR-агенты должны видеть свою консоль управления - иначе тестирование нерелевантно
Права: начальный доступ с правами обычного пользователя для тестирования userland-техник, отдельный сценарий с local admin для BYOVD/BYOI
Версии EDR: фиксировать точную версию агента и дату обновления баз. Результат, полученный на агенте трёхмесячной давности, к текущей версии неприменим - проверено на собственной шкуре

Direct и Indirect Syscalls: обход userland-хуков EDR
Техника обхода userland-хуков через прямые/непрямые системные вызовы соответствует T1106 (Native API, Execution) - MITRE прямо указывает использование syscalls в описании. T1562.001 (Disable or Modify Tools) применима к патчингу хуков EDR, но не к самому механизму syscall-вызовов. Современные решения, включая Kaspersky EDR, устанавливают inline-хуки на функции ntdll.dll:

Код:

NtAllocateVirtualMemory

Код:

NtWriteVirtualMemory

Код:

NtCreateThreadEx

Код:

NtMapViewOfSection

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

Direct Syscalls - вызов системных функций напрямую через инструкцию

Код:

syscall

, минуя ntdll.dll и установленные на ней хуки. SysWhispers3 генерирует ассемблерные стабы с актуальными номерами syscall для целевой версии Windows. Hell's Gate и Halo's Gate динамически извлекают номера syscall из самой ntdll.dll в рантайме.

Ограничения: прямые syscall работают против userland-хуков, но бессильны против kernel-level мониторинга. Kaspersky EDR Expert использует kernel callbacks (

Код:

PsSetCreateProcessNotifyRoutine

Код:

PsSetCreateThreadNotifyRoutine

Код:

PsSetLoadImageNotifyRoutine

), которые срабатывают независимо от способа вызова. Кроме того, современные EDR детектируют сам паттерн - инструкция

Код:

syscall

из памяти, не принадлежащей ntdll.dll, это аномалия. Именно поэтому Indirect Syscalls (вызов через

Код:

jmp

на легитимный адрес внутри ntdll.dll) вытесняют прямые - стек вызовов выглядит чище.

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

Код:

Код:

; Indirect syscall - упрощённая концепция (см. SysWhispers3 / HellsHall для рабочей реализации)

; syscall_addr указывает на инструкцию `syscall; ret` внутри ntdll!Nt*

; Используем call (не jmp!), чтобы return address на стеке указывал в ntdll -

; это базовый indirect syscall: маскировка действует только на момент syscall transition.

; Для полноценного call stack spoofing нужны техники вроде SilentMoonwalk или RecycledGate

mov r10, rcx

mov eax,            ; System Service Number для целевой Nt*-функции

call qword ptr [syscall_addr] ; call на syscall; ret gadget внутри ntdll.dll

ret

Что это значит на практике: против Kaspersky EDR голый SysWhispers3 без доработки call stack уже ловится - агент проверяет return address. Я на нескольких проектах убедился, что indirect syscalls с корректным стеком работают стабильнее, но требуют актуализации при каждом обновлении ОС. Для PT Sandbox syscall-техники менее релевантны - там анализ идёт на уровне поведения процесса целиком, а не отдельных API-вызовов.
ETW Patching: ослепляем телеметрию
Event Tracing for Windows - один из важнейших источников телеметрии для EDR. Через ETW-провайдеры поступают данные о .NET-событиях, DNS-запросах, RPC-вызовах, LDAP-операциях, загрузке модулей. Техника Disable or Modify Tools (T1562.001, Defense Evasion) через патчинг ETW направлена на то, чтобы «ослепить» агента.

Классический подход: патчинг

Код:

EtwEventWrite

в ntdll.dll внутри своего процесса. Получаем адрес функции, меняем protection на RWX через

Код:

VirtualProtect

, записываем

Код:

ret

(0xC3) в первый байт, возвращаем исходные атрибуты. После этого ETW-события из контекста процесса не генерируются. Грубо, но работает - до первой проверки целостности.

Что детектируется и что нет:

ДействиеKaspersky EDRPT SandboxSEKOIA XDRПатчинг EtwEventWrite в своём процессеОбнаруживается по периодической проверке целостности хуковФиксируется как подозрительная модификация памятиЗависит от глубины агентской телеметрииПатчинг NtTraceEventАналогичноАналогичн оАналогичноОтключение ETW-сессий через APIОбнаруживается через мониторинг ETW-сессийНе применимо (песочница)Обнаруживается при наличии ETW-мониторинга

Патчинг ETW работает только для процесса, из которого выполнен. Kernel-level ETW-провайдеры (которые Kaspersky использует для мониторинга процессов, потоков, файловых операций) этим способом не затрагиваются. Чтобы «убить» kernel ETW, нужен доступ к ядру - а это уже территория BYOVD.
Process Injection: живые и мёртвые техники
Process Injection (T1055, Defense Evasion / Privilege Escalation) - большой класс техник, и их эффективность против российских EDR сильно варьируется. Тут важно разделить зёрна от плевел.

Мёртвые техники (детектируются всеми тремя решениями из коробки):

Классическая DLL Injection через

Код:

CreateRemoteThread

+

Код:

LoadLibrary

- последовательность

Код:

OpenProcess

→

Код:

VirtualAllocEx

→

Код:

WriteProcessMemory

→

Код:

CreateRemoteThread

знакома любому EDR. Kaspersky блокирует на этапе создания удалённого потока
Process Hollowing в базовом варианте (

Код:

CREATE_SUSPENDED

→

Код:

NtUnmapViewOfSection

→

Код:

WriteProcessMemory

→

Код:

ResumeThread

) - характерная цепочка вызовов давно в сигнатурах. Если вы всё ещё пробуете это на реальном engagement - пересмотрите подход

Условно живые техники (требуют кастомизации):

APC Injection через

Код:

QueueUserAPC

/

Код:

NtQueueApcThread

- менее тривиальна для детектирования, потому что APC-механизм используется легитимным кодом. Но Kaspersky EDR отслеживает запись в чужое адресное пространство + постановку APC в комбинации
Thread Hijacking - подмена контекста существующего потока через

Код:

SuspendThread

→

Код:

SetThreadContext

→

Код:

ResumeThread

. Сложнее для обнаружения: новый поток не создаётся. Однако

Код:

SetThreadContext

на чужой поток - индикатор, который фиксируют зрелые EDR
Module Stomping (перезапись кода легитимной DLL в памяти) - работает против решений, которые не проверяют целостность загруженных модулей в рантайме. PT Sandbox обнаруживает это при динамическом анализе, но на живом хосте детектирование зависит от настроек EDR-агента

Практический вывод для тест EDR red team: любая инъекция через стандартные API без обфускации - детектируется. Комбинация indirect syscalls + APC injection + шифрование payload в памяти до момента исполнения создаёт окно возможностей, но ненадолго. Каждое обновление баз сужает его.
BYOVD: уничтожение EDR-агента через уязвимый драйвер
BYOVD (Bring Your Own Vulnerable Driver) - атакующий загружает в систему легитимный, подписанный, но уязвимый драйвер и через его уязвимости получает выполнение кода на уровне ядра. Это позволяет убить процессы EDR-агента, снять kernel callbacks и полностью ослепить защиту. Грубо, шумно, но работает.

По данным Sophos X-Ops (отчёт об EDRKillShifter, август 2024), BYOVD стала рабочей лошадкой рансомварных группировок: LockBit, BlackByte, Play, Medusa, BianLian инвестируют в кастомные «EDR killer» утилиты. EDRKillShifter от RansomHub и модульное ПО NtKiller (продаётся как коммерческий EDR killer на underground-форумах) - примеры того, как этот подход коммерциализировался.

Как это работает против российских EDR:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше

Получить доступ просто — достаточно проявить активность на форуме

BYOI: штатный инсталлятор как оружие обхода EDR

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше

Получить доступ просто — достаточно проявить активность на форуме

Sandbox Evasion: PT Sandbox под прицелом
PT Sandbox как решение для динамического анализа - отдельная мишень. Техника Virtualization/Sandbox Evasion (T1497, Defense Evasion / Discovery) здесь выходит на первый план.

Классические методы обнаружения песочницы:

Проверка артефактов виртуализации (ключи реестра VMware, VirtualBox, гипервизорные CPUID-листья)
Тайминг-атаки: замер

Код:

RDTSC

и сравнение с ожидаемым - в песочнице результаты часто аномальны
Проверка пользовательского окружения: количество процессов, наличие документов в «Моих документах», история браузера. Пустая система - верный признак песочницы
Debugger Evasion (T1622):

Код:

IsDebuggerPresent

,

Код:

NtQueryInformationProcess(ProcessDebugPort)

, наличие аппаратных breakpoint через

Код:

GetThreadContext

Что PT Sandbox делает в ответ: решения этого уровня эмулируют пользовательскую активность, настраивают реалистичное окружение, включают «человеческие» артефакты. Но ни одна песочница не способна идеально имитировать продакшен-среду (кстати, на этом и строится вся логика обхода).

Практический подход обход антивируса пентест: вместо одной проверки используйте каскад из 5-7 несвязанных проверок окружения с задержками между ними. Если хотя бы 3 из 7 показывают признаки песочницы - payload не исполняется. Такой подход сложнее для адаптации со стороны вендора, потому что каждая проверка по отдельности выглядит легитимно. Потренировавшись собственной песочнице, можно калибровать пороги под конкретный PT Sandbox.
Сводная таблица: российские EDR сравнение техник обхода

ТехникаMITRE ATT&CKKaspersky EDR ExpertPT Sandbox / MaxPatrol EDRSEKOIA XDRDirect SyscallsT1106Детектирует по аномальному call stackНе применимо (sandbox) / Частично (EDR)Зависит от конфигурацииIndirect SyscallsT1106Сложнее детектировать, но развиваетсяНе применимо / ЧастичноЗависит от конфигурацииETW PatchingT1562.001Периодическая проверка целостностиФиксирует модификацию памятиЧастичноClassic DLL InjectionT1055БлокируетОбнаружив аетОбнаруживаетAPC InjectionT1055Обнаруживает комбинациюОбнаруживает поведениеЧастичноThread HijackingT1055Обнаруживает SetThreadContextОбнаруживает поведениеЧастичноBYOVDT1562.001Se lf-protection усложняет, но не исключаетФиксирует загрузку драйвера (SIEM)Фиксирует через интеграцииBYOIT1562.001Требует проверкиТребует проверкиТребует проверкиSandbox EvasionT1497Не применимоПрямая мишеньНе применимоPowerShell obfuscationT1059.001AMSI + Script Block LoggingДинамический анализЧерез лог-источники

Данные в столбцах Kaspersky основаны на AV-TEST 2024 и архитектурном анализе. Для PT и SEKOIA - на архитектурных особенностях решений. Конкретные результаты зависят от версии агента, конфигурации политик и актуальности баз. Воспринимайте таблицу как отправную точку для собственного тестирования, а не финальный вердикт.
Методология тестирования EDR на Red Team engagement
Вместо хаотичного «кидания шеллов в надежде, что пролетит» - структурированный подход к обнаружению угроз EDR и оценке реальной эффективности.
Шаг 1: разведка агента
Перед атакой определите, что работает на хосте. Security Software Discovery (T1518.001, Discovery) - стартовая точка. Проверяйте запущенные сервисы и процессы:

Код:

kavfs.exe

Код:

avp.exe

для Kaspersky,

Код:

ptsandbox

для компонентов PT, характерные имена для SEKOIA-интеграций.

Код:

wmic service list brief

или

Код:

Get-Service

без обращения к подозрительным API - сам запрос легитимен.
Шаг 2: оценка глубины хуков
Загрузите в целевой процесс PE-sieve или hollows_hunter - они покажут, какие функции ntdll.dll модифицированы. Это даст карту хуков конкретной версии агента.

Код:

pe-sieve.exe /pid /hooks

покажет все inline-патчи. У меня, например, на одном проекте PE-sieve показал 14 хуков на ntdll - и это была далеко не полная картина, потому что kernel callbacks PE-sieve не видит.
Шаг 3: инкрементальное тестирование
Не запускайте Cobalt Strike beacon первым действием. Начните с минимального действия и наращивайте сложность:

Выделение RWX-памяти через

Код:

VirtualAlloc

- срабатывает ли алерт?
Запись тестового кода (NOP sled + ret) в выделенную память - фиксируется ли?
Создание потока на записанный код - блокируется ли?
Повторение через indirect syscalls - есть ли разница?

Код:

// Тест A (canary): RWX с самого начала - грубый паттерн, ожидаемо триггерит EDR

LPVOID mem

=

VirtualAlloc

(

NULL

,

4096

,

MEM_COMMIT

|

MEM_RESERVE

,

PAGE_EXECUTE_READWRITE

)

;

if

(

mem

)

{

memset

(

mem

,

0x90

,

4095

)

;

(

(

unsigned

char

*

)

mem

)

[

4095

]

=

0xC3

;

(

(

void

(

*

)

(

)

)

mem

)

(

)

;

// EDR должен среагировать - замеряем точку детектирования

VirtualFree

(

mem

,

0

,

MEM_RELEASE

)

;

}

// Тест B (стелс): RW → RX через VirtualProtect - паттерн реального malware

LPVOID mem2

=

VirtualAlloc

(

NULL

,

4096

,

MEM_COMMIT

|

MEM_RESERVE

,

PAGE_READWRITE

)

;

if

(

mem2

)

{

memset

(

mem2

,

0x90

,

4095

)

;

(

(

unsigned

char

*

)

mem2

)

[

4095

]

=

0xC3

;

DWORD oldProt

;

VirtualProtect

(

mem2

,

4096

,

PAGE_EXECUTE_READ

,

&

oldProt

)

;

// RW→RX - менее заметно

(

(

void

(

*

)

(

)

)

mem2

)

(

)

;

VirtualFree

(

mem2

,

0

,

MEM_RELEASE

)

;

}

// Сравните: на каком тесте EDR срабатывает раньше? Это определяет выбор техники обхода

Этот подход позволяет определить, на каком этапе kill chain срабатывает детектирование: на аллокации, на записи, или на execution primitive. Знание точки срабатывания определяет выбор техники обхода.
Шаг 4: документирование
Каждый тест фиксируйте: версия агента, дата баз, техника, результат (обнаружено / заблокировано / пропущено / алерт без блокировки). Без этих данных ваш отчёт для заказчика - просто список теоретических уязвимостей. А заказчик хочет конкретику.
Что это значит для red team против EDR
Российские EDR решения в 2024–2025 году - не бумажные тигры. Kaspersky EDR Expert показывает зрелую архитектуру детектирования с покрытием от userland до ядра. PT Sandbox эффективен как дополнительный эшелон динамического анализа. SEKOIA XDR берёт широтой корреляции, хотя глубина агентской телеметрии зависит от того, что подключено снизу.

Три практических вывода:

Публичные инструменты без модификации не работают. Стандартный Cobalt Strike beacon, Mimikatz, SharpHound - всё в сигнатурах. Нужны кастомные loaders, обфускация (Obfuscated Files or Information, T1027, Defense Evasion) и свежие C2-профили. Заявлено «undetectable», но детектится почти мгновенно.
Комбинируйте техники. Indirect syscalls + ETW patch + encrypted payload + staged injection - каждый элемент по отдельности может быть детектирован, но комбинация создаёт окно. По данным Fox-IT, наиболее перспективное направление - «виртуализация» malware, когда вредоносный код исполняется внутри кастомного интерпретатора и никогда не появляется в «сыром» виде в памяти.
Kernel-level - последний рубеж. Если engagement требует гарантированного обхода, BYOVD остаётся единственной техникой с kernel-level доступом. Но она шумная, требует admin-привилегий и оставляет следы, которые потом придётся объяснять в отчёте.

Практикуете обход EDR на реальных проектах? На курсах античат по пентесту Red Team операторы отрабатывают эти техники в лабораторных средах с развёрнутыми EDR-решениями - от разведки агента до полного обхода.
Вопрос к читателям
На каждом engagement сталкиваюсь с одной дилеммой: indirect syscalls пережили уже несколько поколений обновлений EDR-агентов и до сих пор работают с правильным call stack, но вендоры всё ближе к детектированию через анализ стека вызовов в ядре. Кто-нибудь из коллег уже ловил ситуацию, когда Kaspersky EDR начал блокировать indirect syscalls на конкретной версии агента - или пока стабильно проходит?