|
https://forum.antichat.xyz/attachmen...ec10c4b235.png
Вы подготовили идеальный имплант - обфусцированный, с indirect syscalls, с обходом AMSI и ETW. Запускаете на целевой машине, и через три секунды агент CrowdStrike Falcon отправляет алерт в SOC. Проблема не в вашем payload. Проблема в том, что EDR-драйвер в Ring 0 зарегистрировал kernel callbacks на создание процессов и загрузку образов задолго до того, как ваш код коснулся ntdll.dll. Единственный способ ослепить эту защиту - оказаться на том же уровне привилегий. Именно поэтому BYOVD атака обход EDR остаётся главной техникой нейтрализации endpoint-защиты и в red team-операциях, и в реальных кибератаках - хотя в связке с ней часто применяются living off the land техники, которые я разобрал в полном руководстве по LOLBAS и обходу EDR. Здесь разберу практическую механику: какие драйверы дают нужные примитивы, как устроена цепочка от Код:
sc createДисклеймер. Материал для специалистов по offensive security и пентестеров, действующих в рамках авторизованных проектов. Применение описанных техник без письменного разрешения владельца инфраструктуры - это ст. 272–274 УК РФ и аналоги в других юрисдикциях. Не надо так. Почему Bring Your Own Vulnerable Driver - ведущая техника обхода антивируса через драйвер Ещё три года назад BYOVD-атаки выглядели как экзотика: группировка берёт один уязвимый драйвер, юзает его до попадания в блоклист, переключается на следующий. В 2026-м ситуация другая. По данным Cisco Talos и Trend Micro (апрель 2026), две ransomware-группировки - Qilin и Warlock - превратили BYOVD в штатную фазу pre-encryption. Обе поддерживают ротируемый пул уязвимых драйверов, мониторят обновления Microsoft Vulnerable Driver Blocklist и переключаются на незаблокированные альтернативы. Их инструментарий заточен на завершение работы (терминацию) более 300 endpoint security продуктов до запуска шифрования. Не разовый трюк - конвейер. Параллельно, по публикации The Hacker News (март 2026), исследователи зафиксировали 54 различных EDR-килера, эксплуатирующих 35 подписанных уязвимых драйверов через BYOVD. Это уже не инциденты - это индустрия. В терминах MITRE ATT&CK техника маппится на:
Kill chain BYOVD-атаки: от административных привилегий до Ring 0 Прежде чем разбирать конкретные драйверы, зафиксируем цепочку. BYOVD - не техника первоначального доступа. Она требует локальных административных привилегий. Kill chain выглядит так:
Классификация уязвимых драйверов Windows: какой примитив нужен для EDR killer Не каждый драйвер из базы LOLDrivers годится для конкретной задачи. По классификации CrowdStrike, абьюзируемые драйверы делятся на три категории: vulnerable (с программными ошибками), weaponizable (с опасным by-design функционалом) и malicious (специально созданные). Первые две - основа BYOVD. Драйверы с ошибками реализации Классика - Dell dbutil_2_3.sys с CVE-2021-21551, активно эксплуатируемой в реальных атаках (включена в каталог CISA KEV). По NVD, это insufficient access control (CWE-782) с оценкой CVSS 8.8 (HIGH) и вектором CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Обратите внимание на Scope=Changed - эксплуатация затрагивает ресурсы за пределами скоупа уязвимого компонента, то есть весь kernel. Привилегии для эксплуатации - Low (PR:L), действие пользователя не требуется (UI:N). Драйвер предназначен для обновления BIOS и firmware ноутбуков Dell. Ключевая проблема - отсутствие ACL на device object: устройство доступно любому пользователю, а IOCTL-обработчики дают примитивы чтения/записи памяти ядра без проверки источника запроса. Именно его эксплуатировала Lazarus в рутките FudModule в 2021–2022 годах (по данным ESET, октябрь 2022) для kernel read/write, позже мигрировав на другие BYOVD-драйверы и в итоге на zero-day CVE-2024-21338 в appid.sys. Эволюция показательная: от BYOVD к 0-day, когда блоклисты поджали. Другой пример - capcom.sys - подписанный драйвер от Capcom (да, той самой игровой компании), раскрытый в 2016 году. Содержит by-design механизм выполнения произвольного shellcode в kernel context: временно отключает бит SMEP (bit 20) в регистре CR4, после чего восстанавливает значение. По данным Bitdefender, это фактически подписанная открытая дверь в Ring 0 для любого процесса с admin-привилегиями. Красивее приглашения не придумаешь. Драйверы с опасным функционалом by design Вторая категория - драйверы, которые работают ровно так, как задумано разработчиком, но дают опасные возможности user-mode приложениям. По данным Bitdefender, неоднократно использовались ransomware-группировкой BlackCat. Тут нет бага - by design предоставляется Код:
MmMapIoSpaceWinRing0.sys - драйвер для мониторинга аппаратных сенсоров (температура, напряжение). Даёт прямой доступ к MSR (Model-Specific Registers), интерфейсам ввода-вывода и физической памяти. Входит в состав десятков утилит: CPUID HWMonitor, Open Hardware Monitor и прочих. Если у вас на машине стоит мониторилка температуры - вполне возможно, WinRing0.sys уже там. EnCase driver (Guidance Software) - ключевой кейс 2026 года. По данным Huntress, в феврале атакующие притащили легитимный драйвер форензик-инструмента EnCase с сертификатом, истекшим в январе 2010 года и впоследствии отозванным. Windows всё равно его загружает. Почему? DSE при загрузке драйверов не проверяет CRL/OCSP - архитектурное решение для предотвращения DoS при недоступности revocation-серверов на boot-time, распространяющееся и на runtime-загрузку. Ирония: форензик-инструмент стал оружием против форензики. EDR-килер на базе этого драйвера терминировал 59 процессов endpoint security. Для анализа нового драйвера в IDA Pro или Ghidra ключевая задача - найти обработчик Код:
IRP_MJ_DEVICE_CONTROLКод:
MmMapIoSpaceКод:
ZwMapViewOfSectionКод:
MmCopyMemoryКод:
__writecr0https://forum.antichat.xyz/attachmen...649fb14e40.png Практический workflow: отключение EDR решений через уязвимый драйвер Требования к окружению
Шаг 1: Доставка и маскировка драйвера. 📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше Получить доступ просто — достаточно проявить активность на форуме Как EDR-килеры маскируют загрузку уязвимого драйвера в 2026 году Современные EDR-килеры - далеко не примитивные скрипты. Разберём техники из реальных инцидентов. Кодирование payload и антифорензика В кейсе Huntress (февраль 2026) бинарник EDR-килера использовал словарную подстановку для маскировки встроенного драйвера. Идея элегантная: каждый байт .sys-файла заменялся английским словом из словаря на 256 позиций. Индекс слова равен значению байта. Слово "about" на индексе 0 декодируется в 0x00, "block" на индексе 77 - в 0x4D (ASCII "M"). Закодированный payload занимал 384 528 байт текста, разделённого пробелами. Первые слова - "block both choice about" - декодируются в Код:
4D 5A 90 00Подход обходит сразу два уровня детекции. Строковый анализ не находит подозрительных API-имён или путей. Энтропийный анализ показывает около 4 бит/байт - сильно ниже порога 7–8 бит/байт, характерного для зашифрованного или упакованного содержимого. Антивирус смотрит на это и видит текстовый файл. Хитро. Для идентификации целевых процессов тот же бинарник хэшировал имена 59 EDR-процессов алгоритмом FNV-1a (seed 0x811C9DC5) на этапе инициализации. В рантайме Код:
CreateToolhelp32SnapshotРотация пула драйверов как EDR evasion 2026 Ключевое отличие BYOVD-кампаний 2026 года от атак 2022–2023 - операционное управление пулом драйверов. По данным Druva, группировки Qilin и Warlock ведут курируемый список уязвимых драйверов, мониторят обновления блоклиста Microsoft и переключаются на незаблокированные альтернативы. Один драйвер попал в блоклист - берём следующий из пула. Как карусель. Предпочтение отдаётся legacy-драйверам эпохи 2013–2016 годов: по данным Bitdefender, они не содержат современных защит типа Control Flow Guard (CFG), что упрощает эксплуатацию. Одновременно ведётся поиск среди свежих релизов - новый уязвимый драйвер особенно ценен, потому что ещё не попал ни в один блоклист. В сентябре 2024 года CrowdStrike зафиксировал инцидент, где атакующий притащил шесть различных уязвимых драйверов для обхода Falcon sensor. Все были обнаружены или заблокированы, но сам факт показателен - расчёт на то, что хотя бы один из набора пройдёт мимо защиты. Shotgun approach в чистом виде. Защита от BYOVD: почему блоклист Microsoft не работает и что делать HVCI как основной барьер против kernel driver exploit Hypervisor-Protected Code Integrity (HVCI) - единственная технология, которая архитектурно блокирует BYOVD. HVCI использует гипервизор Windows для изоляции проверки целостности кода в защищённое окружение, недоступное основному ядру ОС. Даже с kernel read/write атакующий не может модифицировать политики code integrity - они живут в отдельном домене безопасности Virtual Trust Level 1 (VTL1). Проблема: HVCI требует поддержки виртуализации на уровне CPU и совместимости всех загруженных драйверов. На практике многие корпоративные среды отключают HVCI из-за конфликтов с legacy-софтом или проседания производительности. Именно эти среды - идеальные цели для BYOVD. Если у вас в инфраструктуре есть машины без HVCI - считайте, что двери в Ring 0 приоткрыты. Проверка статуса через PowerShell: Код:
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object VirtualizationBasedSecurityStatusПочему Microsoft Vulnerable Driver Blocklist недостаточен По данным Picus Security, блоклист обновляется через отдельный механизм servicing (DriverSiPolicy.p7b), но фактическая частота обновлений - несколько раз в год. Между обновлениями новые уязвимые драйверы остаются доступными. Проект LOLDrivers.io каталогизирует сотни уязвимых драйверов - блоклист Microsoft покрывает малую часть из них. Плюс Windows не проверяет CRL при загрузке драйверов. Драйвер EnCase с сертификатом, отозванным более 15 лет назад, успешно загружается на полностью обновлённой Windows 11 (данные Huntress). Это структурная проблема DSE, а не ошибка конфигурации. Чинить её Microsoft не торопится - слишком много сломается. Детектирование BYOVD на уровне телеметрии Для blue team: если HVCI не включён, остаётся мониторинг. Ключевые индикаторы обхода защиты конечных точек через BYOVD: ИндикаторИсточник телеметрииЧто мониторитьЗагрузка драйвера из нестандартного путиSysmon Event ID 6 (Driver Loaded)ImageLoaded не из System32\driversСоздание kernel-mode сервисаWindows Event ID 7045ServiceType = kernel, нестандартное имяДрайвер с отозванным сертификатомSysmon + SIEM корреляцияХэш драйвера в базе LOLDriversМассовая терминация защитных процессовSysmon Event ID 5 (Process Terminated)Несколько EDR-процессов за короткий интервалИсчезновение kernel callbacksETW + EDR телеметрияПрекращение потока событий от EDR Наиболее надёжный сигнал - корреляция: появление нового kernel-mode сервиса + загрузка драйвера с хэшем из LOLDrivers + последующее молчание EDR-телеметрии. По отдельности каждый индикатор может быть легитимным. Цепочка - это BYOVD. Базовое правило детектирования для SIEM: Код: Код:
# Псевдо-правило: создание kernel-mode сервиса из нестандартного путиRing 0 привилегии ядро Windows: что изменится дальше BYOVD в 2026 году - это чёткий тренд: техника из арсенала APT перекочевала в стандартный набор ransomware-операторов. Группировки типа Qilin и Warlock поставили процесс на поток - от поиска уязвимых драйверов до автоматической ротации при обновлении блоклиста. Для red team оператора это значит, что простое использование публичных тулкитов типа Blackout или KDU всё чаще ловится EDR-вендорами. Реальная ценность - в умении самостоятельно реверсить IOCTL-хендлеры, находить драйверы, которых ещё нет в LOLDrivers, и адаптировать загрузчик под конкретную конфигурацию цели. Тут нет шорткатов - только IDA, Ghidra и терпение. Для blue team - единственная архитектурная защита остаётся HVCI. Всё остальное - детектирование постфактум. Если ваша инфраструктура не поддерживает VBS/HVCI, BYOVD-атака с новым драйвером из пула пройдёт мимо любого блоклиста. Проверьте статус HVCI на ваших endpoint'ах прямо сейчас - команда PowerShell выше. Если значение не 2, у вас та же проблема, что и у жертв Qilin. Вопрос к читателям В описанном кейсе Huntress EDR-килер терминировал 59 процессов endpoint security, но Huntress agent не был в списке целей. При подготовке к red team-проекту вы анализируете конкретный EDR-килер и обнаруживаете, что он определяет целевые процессы через FNV-1a хэширование с seed 0x811C9DC5. Вопрос: какой набор IOCTL-кодов RTCore64.sys вы используете для read/write виртуальной памяти ядра - стандартные из публичных PoC или модифицированные через собственный wrapper? Поделитесь, с каким конкретным драйвером из LOLDrivers вы получали наиболее стабильный kernel r/w примитив на Windows 11 24H2 с отключённым HVCI. |
| Время: 12:54 |