Привет! Меня зовут Сергей Буреев (@TCross \ THunter HackTeam), я специалист по пентесту и исследователь в области информационной безопасности.
Пост будет посвящен ещё одной Coerce атаке, про которую я рассказывал в докладе «Атаки на защиту» на конференции CyberWave2025 — если вы были в зале, надеюсь, вам понравилось. Если нет — вот, делюсь докладом тут :)
TL;DR:
Берём MS-EVEN протокол (журналы событий через RPC)
Используем его ElfrOpenBELW для провоцирования обращения к SMB-шаре атакующего
Антивирус (Defender, и не только) лезет туда со своими NTLM-хешами
Релей — и привет, привилегии!
Но это ещё не всё. Есть приятный (или не очень) бонус.
Немного о Coerce
Coerce атаки - это тип атак, направленных на принудительную аутентификацию жертвы в системе злоумышленника. В результате чего атакующий получает учетные данные (NetNTLMv1\2, Kerberos AP-REQ), которые в дальнейшем может:
- получить пароль в открытом виде (брутфорс);
- перенаправить в другой сервис для прохождения аутентификации (relay атаки).
Подробнее про coerce и relay атаки можно почитать:
https://habr.com/ru/companies/ussc/articles/688682/
https://habr.com/ru/companies/otus/articles/745942/
https://habr.com/ru/articles/848542/
Идея
Сидел я как-то вечером, ковырялся в своем стенде Active Directory, исследовал RPC-интерфейсы в поисках чего-то нового… И тут мне в голову пришло: а что если совместить давно известную коэрс-атаку через MS-EVEN с тем, как антивирусы ведут себя при обращении к сомнительным файлам? Например, как Windows Defender или другие антивирусы любят запрашивать подозрительные .exe по SMB? Они ж ради проверки хэша или удаления файла вполне себе могут отправить NTLM-аутентификацию.
И оказалось — всё работает.
Evilent: злое событие
Я решил назвать атаку Evilent — от слов "evil" и "event", потому что это буквально событие, от которого потом начинаются проблемы.
Сценарий атаки довольно прост:
Атакующий (с минимальными правами в AD) подключается к RPC-интерфейсу \pipe\eventlog.
Через ElfrOpenBELW он указывает путь до файла с полезной нагрузкой, которая спровоцирует антивирус - \\attacker\Share\metra.exe.
Хост честно пытается запросить файл. Но запрос идёт не один — а с мутациями имени файла: например, test.exeem䵌䵅P. Байт 䵌䵅P (\xe4\xb5\x8c\xe4\xb5\x85\x50) всегда одинаковый. Остальные — предсказуемо случайные.
Тут нужно уточнить, что для повышения успеха атаки лучше отправить несколько запросов в rpc функцию что бы сгенерировалось большее количество имен файла и тем самым повышается вероятность того, что сервер обратится к нам с нужным именем файла.
Слайды из презентации для доклада Если на SMB-сервере атакующего лежит файл с подходящим именем, он детектится антивирусом.
Антивирус, в свою очередь, лезет за ним — но уже с отправкой NTLM-аутентификации (NetNTLM) от имени машинного аккаунта.
А дальше — дело техники: релей в ADCS, SMB, LDAP и привет привилегии.
Слайды из презентации для доклада
Проверка гипотезы
Проверял на Windows Server 2016, 2019 и 2022 с последними обновлениями. Всё чинно, благородно, никаких патчей на горизонте. Файл-триггер генерировал через MSFVenom и добавлял к имени "мусорные" байты. Для честности прогнал на стенде с разными антивирусами — работает. И Defender, и парочка коммерческих решений радостно дёргают SMB с NTLM-хешем.
Кто виноват и что делать?
Атака работает только в AD-среде, требует учётной записи с минимальными правами (достаточно доступа к eventlog RPC), и в итоге может привести к эскалации привилегий, если рядом есть уязвимые сервисы для NTLM-релея.
Патча, как вы уже догадались, нет. NT AUTHORITY\LOCAL SERVICE сам по себе хешей не даёт, но как только в игру вступает антивирус — всё меняется.
Сразу отвечаю на главный вопрос: а ты в Microsoft писал?
Да, писал.
Они подтвердили, что в курсе и проблема имеет место быть, и даже выкатили рекомендации по защите (в духе: отключать NTLM, мониторить обращения к RPC-интерфейсам, ограничивать доступ к eventlog), так же отдельно упомянули что в Windows Server 2025 добавили групповую политику которая ограничивает обычным пользователем доступ к журналам событий (но включить её необходимо самим, по дефолту она не применяется).
Формально это не баг, а "expected-but-dangerous behavior" — ну, вы понимаете.
Выводы
Старые интерфейсы Windows могут быть удивительно полезны… для атакующего;
Даже без эксплуатации багов можно выжать максимум из штатных механизмов, если знать, куда нажать;
Не пускайте пользователей к \pipe\eventlog, если они туда не должны;
Включайте подписи SMB, LDAP и Channel Binding;
Настройте фильтрацию трафика;
И конечно следите за актуальными обновлениями безопасности.
Bonus
Оказывается coerce-атаки можно использовать не только для захвата учетных данных, но и для раскрытия переменных окружения пользователя (а там уже могут быть всякие интересности: токены, команды запуска и тд).
Тут всё просто, когда указываем путь до нашей SMB-шары, надо вместо имени папки подставить нужную нам переменную (прим. \\attacker\%username%).
Как то так :) А дальше уже дело техники и фантазии как это может быть полезно пентестерам и что ещё можно из этого получить.
ЗЫ
Для тех кто дочитал до конца прикладываю ссылку на инструменты для Evilent атаки, приветствуются предложения по развитию и улучшению =), с презентацией доклада можно ознакомиться тут (спасибо@Michaelzhm).
Надеюсь данный материал был вам полезен и даст пищу для размышлений и дальнейших исследований.
