Windows Theme Spoofing В Windows существуют специальные файлы тем с одноименным расширением .themes. Они позволяют кастомизировать систему, применяя новые раскраски, цветовые палитры, шрифты и обои. В 2023 году вышел POC на уязвимость themebleed (https://github.com/exploits-forsale/themebleed ) (POC2 (https://github.com/Jnnshschl/CVE-2023-38146/tree/main?tab=readme-ov-file )), которая как-то не была оценена по достоинству. Фактически, это был Built-In Loader. Все основывалось на том, что Explorer.exe, обнаруживая в файле темы специальную ссылку на файл стилей (msstyles) , осуществит удаленную загрузку DLL с именем, оканчивающемся на _vrf.dll. Была, конечно, осуществлена проверка подписи, но эту проверку обошли с помощью атаки TOCTOU (Time of Check - Time of Use). При первом обращении на подконтрольный атакующему SMB-сервер происходила передача легитимной библиотеки DLL для осуществления проверок подписи, однако за первым запросом следовал второй (после успешной проверки), на который уже отдавалась вредоносная библиотека. На этом исследования Windows Themes не закончились и обнаружилась новая уязвимость — утечка NetNTLM-хеша без необходимости открытия файла тем. Достаточно было зайти в папку с правильно сгенерированным файлом и хеш был в наших руках. Язве был назначен идентификатор CVE-2024-21320 (https://www.akamai.com/blog/security-research/leaking-ntlm-credentials-through-windows-themes ), а POC можно найти тут (https://github.com/akamai/akamai-security-research/tree/main/PoCs/CVE-2024-21320 ). Эти две уязвимости могут отлично работать в чейне с Smuggling-техниками. Патч на CVE-2024-21320 заключался во внедрении проверки на UNC путь функцией PathIsUnc() — если путь был на сетевую шару, то Explorer.exe не пытался подгрузить файлы для файла темы. Однако исследователи нашли способ обхода (благодаря статье Google Project Zero (https://googleprojectzero.blogspot.com/2016/02/the-definitive-guide-on-win32-to-nt.html )), указав UNC Path в ином формате: \??\UNC\ip\share. Так родилась CVE-2024-38030, подробного ее разбора не было, но появился POC (https://github.com/CICADA8-Research/Penetration/blob/main/POCs/CVE-2024-38030/theme.theme ). MS чуть исправила функцию и, казалось бы, на этом все, однако, приключения не закончились, и появилась CVE-2025-21308 (https://github.com/advisories/GHSA-fw67-4j8q-76gw ). На нее пока нет ни разбора, ни POCа, но что-то мне подсказывает, что вновь появился способ обхода проверки на UNC путь :) На изображении представлена таблица с тремя колонками, показывающими различные форматы представления путей к сетевым ресурсам Windows: Dos Path: Путь в формате DOS. Это привычный для пользователей формат пути, используемый в файловых системах Windows, начинающийся с двойного обратного слэша (\\). Full Path: Полный путь, который интерпретируется системой. Это более "прямолинейная" версия пути, где убраны избыточные компоненты, такие как . и ... NT Path: Путь в формате NT. Этот формат пути используется внутри Windows, для работы с внутренними компонентами ядра и драйверами. Он начинается с префикса \\?\UNC\, указывающего, что путь относится к сетевым ресурсам. Примеры из таблицы: \\server\share\ABC\DEF: Полный путь совпадает с DOS-путем. NT-путь представлен как \\?\UNC\server\share\ABC\DEF. \\server: Полный путь остается тем же. NT-путь: \\?\UNC\server. \\server\share\ABC\.\..\XYZ: В полном пути интерпретируется так, что .\..\ заменяются на переход на уровень выше: \\server\share\XYZ. NT-путь отражает это изменение: \\?\UNC\server\share\XYZ. \\server\share\ABC\.\.\..\..\: В полном пути происходит последовательное поднятие на уровни выше до корня: \\server\share. NT-путь аналогичен: \\?\UNC\server\share. Комментарий: Таблица демонстрирует, как система преобразует пути в процессе интерпретации и работы с ними. NT-путь используется для расширенной работы с файловой системой, например, чтобы обойти ограничения длины пути или для низкоуровневых операций. Избыточные символы, такие как . (текущая директория) и .. (переход на уровень выше), удаляются из полного пути для его упрощения.