Обход EDR через kernel callback unhooking — что работает в 2026 и где ловят

[valru]

Занимаюсь red team в небольшой команде, клиенты в основном СНГ-банки и страховые. За последние полгода заметил серьёзный сдвиг: почти все поставили CrowdStrike Falcon или Carbon Black, и классические shellcode-инжекции через VirtualAllocEx+CreateRemoteThread уже не проходят даже через первый слой защиты. Начал копать тему kernel callback unhooking — конкретно снятие хуков с SSDT и удаление kernel callbacks через NtQuerySystemInformation(SystemKernelDebuggerInformation) и ручную патч LSASS.

Сейчас использую связку: сначала через драйвер с уязвимостью (тащу старый Gigabyte драйвер gdrv.sys CVE-2018-19320, он до сих пор работает на Win11 23H2 если SecureBoot выключен) загружаю свой неподписанный код в kernel. Затем снимаю ObRegisterCallbacks у AV-продукта, после чего LSASS дампится спокойно через MiniDumpWriteDump.

Вопрос к сообществу: у кого есть опыт с Falcon на актуальных системах? Они перешли на ETW-based детект, и мне не до конца понятно — снятие kernel callbacks им не поможет, потому что часть телеметрии идёт через ETW providers, которые в user mode. Как вы это обходите?

[matguyvr]

Вопрос немного в сторону: а SecureBoot в банках реально выключен? Мне казалось, что крупные финансовые организации в РФ уже лет пять как требуют SecureBoot + TPM 2.0 как минимум для АРМ с доступом к АБС. Если SecureBoot включён, загрузка неподписанного ядерного кода через BYOVD уже не тривиальна.

[makler]

@valru, По SecureBoot: у нас была пара клиентов (не буду уточнять сегмент), где SecureBoot формально включён, но ключи в базе данных Allowed (db) не обновлялись с 2019 года. То есть старые отозванные сертификаты Microsoft всё ещё доверенные. CVE-2023-24932 (BlackLotus) патч стоит, но вот более свежие техники через уязвимые boot files всё ещё проходят на части машин. Это скорее про неправильно настроенный SecureBoot, но в реальности это очень частая история.

Так что отвечая на оригинальный вопрос: да, в некоторых организациях SecureBoot — это скорее галочка в чеклисте, чем реальная защита.

[sergeyserov]

Хочу добавить про Carbon Black: у них есть режим, где они мониторят не через kernel callbacks, а через сетевой трафик (CBC Network Sensor) и поведенческие паттерны в user space. То есть даже если ты чисто отработал на уровне ядра и не оставил следов в callback-таблицах, их UEBA-модуль может поднять алерт на аномальное поведение процесса (например, LSASS читается процессом, у которого нет в истории такого паттерна).

На практике это означает, что kernel-уровень — необходимое, но не достаточное условие. Нужно ещё мимикрировать под легитимный процесс в поведении. Мы для этого делаем инжекцию в уже запущенный svchost.exe с нужным профилем активности.

[bruce01]

@valru, По ETW: провайдеры Microsoft-Windows-Threat-Intelligence (TI) работают в PPL-процессе, напрямую патчить их через NtWriteVirtualMemory не дашь. Но есть способ через EtwpDebuggerData — структура в ntoskrnl, если ты уже в kernel, можно занулить поле SystemLogger и большинство TI-событий перестают логироваться. Это работает на Win11 22H2/23H2, на 24H2 Microsoft что-то поменял в верификации, ещё не разобрался.

Но честно — я бы не тащил gdrv.sys в 2026. Его сигнатура забита в LOLDrivers, половина EDR его блочит ещё на стадии загрузки по хэшу. Ищи что-то свежее из последних 18 месяцев.

[b1llyn0m]

Подтверждаю про gdrv.sys — на Falcon 7.x он блочится мгновенно. У нас в лабе стоит Falcon 7.18 (актуальный на Q1 2026), и любой known-bad драйвер из публичных баз летит в карантин раньше, чем NtLoadDriver вернёт статус.

Для обхода через BYOVD (Bring Your Own Vulnerable Driver) сейчас нужно искать драйверы, которых нет в базах. Либо смотреть в сторону firmware-уровня — если есть физический доступ или supply chain, UEFI-имплант обходит всё это хозяйство на корню, но это уже другая история и другие риски для пентестера.