"SYSTEM" за $5000. Найден способ взломать Windows Admin Center через обычную папку

Cymulate Research Labs обнаружила уязвимость локального повышения привилегий в Microsoft Windows Admin Center (WAC) версии 2.4.2.1, которая затрагивает все установки WAC вплоть до версии 2411. Проблема оказалась не в «хитром баге», а в банальной, но опасной ошибке конфигурации: каталог C:\ProgramData\WindowsAdminCenter доступен на запись любому обычному пользователю. На первый взгляд это выглядит как рядовая недоработка прав, но внутри этой папки работают компоненты, которые запускаются как служба с привилегиями SYSTEM — и это превращает запись в каталог в прямую точку входа для эскалации.

По сути, любая организация, использующая WAC для управления серверами или инфраструктурой, автоматически наследует риск: достаточно, чтобы у злоумышленника был доступ к файловой системе на хосте, где установлен WAC. Cymulate отмечает, что уязвимость бьёт по технологическому слою, а не по конкретным отраслям: под ударом любые развёртывания, где задействованы WAC Gateway, интегрированные расширения, привилегированные административные сценарии или Windows Server-хосты с установленным WAC. Исследователи показали, что из-за неверных прав доступа можно собрать рабочие цепочки эксплуатации и подняться от низких привилегий до SYSTEM, фактически ломая границу безопасности Windows.

Первый путь эксплуатации связан с механизмом удаления расширений. Исследователи рассуждали просто: какие действия почти гарантированно выполняются с повышенными привилегиями, но при этом касаются пользовательского содержимого? Установка и удаление — классический ответ. Поскольку WAC — .NET-приложение, команда взяла dnSpy и быстро нашла код, отвечающий за uninstall. Он формирует путь к папке uninstall, перечисляет там все .ps1-файлы и запускает их через PowerShell с политикой выполнения AllSigned. То есть процесс WAC по сути доверяет любым PowerShell-скриптам, оказавшимся в этой директории.

Если родительская папка доступна для записи всем, то обычный пользователь может подложить туда полезную нагрузку — хотя есть нюанс: скрипт должен быть подписан. Cymulate подчёркивает, что это не значит «подкинул любой ps1 и готово»: нужно либо найти подписанный скрипт, который можно злоупотребить, либо создать и подписать свой.

Для демонстрации специалисты подписали собственный простой скрипт, который выполнял whoami и сохранял результат в C:\Users\Public, наглядно показывая, что код исполняется в повышенном контексте. Дальше сценарий выглядел так: создать структуру C:\ProgramData\WindowsAdminCenter\Extensions\<ExtensionName>\uninstall, положить туда подписанный «вредоносный» скрипт и инициировать удаление расширения через UI или API — после чего полезная нагрузка выполнялась с привилегиями NETWORK SERVICE или даже SYSTEM.

Второй путь касается механизма обновления и классической DLL-подмены. Команда изучила компонент WindowsAdminCenterUpdater.exe и выяснила, что он загружает DLL из C:\ProgramData\WindowsAdminCenter\Updater. Поскольку эта папка тоже доступна для записи всем пользователям, напрашивается DLL hijacking: подложить нужную библиотеку и дождаться, когда привилегированный процесс её подхватит. На первом тесте всё почти сработало, но DLL не исполнилась: в Event Viewer исследователи увидели, что библиотеку отбраковали из-за отсутствия подписи — в процессе была проверка цифровой подписи.

Однако дальше обнаружился важный момент: валидация выполняется внутри процесса WindowsAdminCenter, а уже после неё он запускает WindowsAdminCenterUpdater.exe. Это позволило построить атаку TOCTOU (time-of-check time-of-use): специалисты использовали PowerShell-скрипт, который как обычный пользователь «слушает» появление процесса WindowsAdminCenterUpdater.exe, и как только тот стартует — мгновенно копирует вредоносный user32.dll в папку Update, чтобы библиотека была подхвачена уже без той самой проверки.

В демонстрации специалисты использовали Register-WmiEvent с реакцией на создание процесса и копированием DLL в нужный путь. По словам исследователей, этот трюк сработал «безупречно»: DLL выполнялась с правами SYSTEM, и главное — весь сценарий запускался обычным пользователем без каких-либо повышенных привилегий. В качестве PoC они собрали user32.dll, которая просто писала файл C:\Users\Public\test.txt, настроили мониторинг старта апдейтера, подложили DLL в Updater, затем инициировали обновление через API-эндпоинт /api/update — и получали выполнение кода как SYSTEM.

Microsoft подтвердила проблему, присвоила ей идентификатор CVE-2025-64669 и выплатила исследователям награду $5 000.