Вы администратор? Тогда мы идём к вам: как дыра в Windows Admin Center оставляет ваши сервера голыми

Уязвимость в Windows Admin Center

Знаете, что самое обидное в работе злоумышленника?

Ему не нужно изобретать гиперсложные эксплойты. Достаточно найти одну глупую, детскую ошибку в настройках — такую, на которую все годами не обращали внимания. И всё. Ключи от kingdom’а у него в кармане. Сегодня разберём именно такую историю — про уязвимость в Windows Admin Center (CVE-2025-64669), которая заставила меня лично пересмотреть подход к аудиту привилегий на сотнях серверов. И да, это прямая угроза выполнению 152-ФЗ и требований ФСТЭК. Если у вас в инфраструктуре есть WAC, читайте до конца — в конце вас ждёт чек-лист действий, который я вывел горьким опытом.

Пару месяцев назад ко мне обратились из одного крупного ритейла — их SOC зафиксировал подозрительную активность на одном из административных хостов. Не атаку, нет. Просто… странные попытки чтения системных папок от имени рядового пользователя из отдела логистики. Начали копать. Оказалось, на этой машине стоял Windows Admin Center для удобного управления виртуальной фермой. И знаете, что мы нашли? Каталог C:\ProgramData\WindowsAdminCenter с правами на запись для… всех аутентифицированных пользователей. Да-да, вы не ослышались. Любой, кто мог зайти на этот хост (хоть через скомпрометированный аккаунт, хоть через уязвимость в другом ПО), получал возможность писать туда, куда не следует.

Классический пример того, как мелочь в конфигурации ломает всю оборону.

WAC — мощный инструмент, по сути, браузерный пульт управления вашими серверами. Но внутри него крутятся службы, работающие от имени SYSTEM — самой высокой учётной записи в Windows. И если эти службы по какой-то причине начинают доверять содержимому папки, которая доступна всем на запись… Дальше вы понимаете.

Честно говоря, когда исследователи из Cymulate описали этот вектор, я лишь грустно улыбнулся. Потому что сталкивался с подобным раньше, просто в другом софте. Вся драма не в каком-то нулевом дне, а в банальном пренебрежении базовым принципом минимальных привилегий. И Microsoft, признав проблему и выплатив 5000$ за баг, по сути, подтвердила: да, это серьёзный просчёт.

Как именно эту дыру можно использовать? Тут даже два интересных пути, оба — учебник по эксплуатации.

Первый путь: через PowerShell и доверие к скриптам.

Расскажу, как это работает, на пальцах. В WAC есть механизм удаления расширений. Когда вы нажимаете кнопку «Удалить», сервис WAC ищет в специальной подпапке (uninstall) скрипты PowerShell и запускает их. С политикой AllSigned, что должно означать: «запускаем только подписанные скрипты». Но ключевое слово — «ищет в папке». А если злоумышленник, имеющий права на запись в C:\ProgramData\WindowsAdminCenter, подложит туда свой evil.ps1? Сервис от SYSTEM добросовестно его выполнит. И это уже не гипотеза — это рабочий Proof-of-Concept от исследователей.

На практике такое часто всплывает в сегментах, где админы любят автоматизировать всё подряд, но забывают о разграничении прав. Однажды я видел, как через подобную схему скомпрометировали хост, с которого управляли виртуалками банковского процессинга. И знаете, что самое неприятное? Инцидентная команда два дня не могла понять, откуда утекли данные, потому что в логах всё выглядело как штатная работа службы.

Второй путь: классический, как мир, DLL Hijacking.

Тут ещё проще. Есть процесс WindowsAdminCenterUpdater.exe. Он отвечает за обновления и, как многие программы, при старте ищет и загружает необходимые DLL-библиотеки. Один из путей поиска — как раз наша злополучная папка C:\ProgramData\WindowsAdminCenter\Updater. Что делает злоумышленник? Правильно, кладёт туда свою вредоносную dll с красивым именем вроде legit_library.dll. И ждёт. Рано или поздно служба обновления запустится (или её перезапустят) — и подгрузит троянскую библиотеку с правами SYSTEM. Это как подменить ингредиент в рецепте шеф-повара — блюдо будет приготовлено и подано, но последствия окажутся катастрофическими.

И нет, это не теоретическая угроза из презентации. В российских реалиях, где порой на одном хосте крутятся и админские инструменты, и какие-нибудь учётные системы из-за нехватки ресурсов, такой сценарий — прямая дорога к полному контролю злоумышленника над сетью. Особенно если этот хост находится в одном сегменте с системами, подпадающими под 187-ФЗ о КИИ.

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

Получается, уязвимость бьёт не по какой-то одной отрасли — она бьёт по технологическому фундаменту.

Под ударом:

• Шлюзы WAC Gateway, которые часто выносят для удалённого доступа.
• Все расширения, которые вы там понаустанавливали — от мониторинга до управления гипервизором.
• Любые сценарии, которые выполняются через центр администрирования.
• Фактически, все Windows Server-хосты, где есть WAC.

И если ваш CISO говорит, что это «не критично, потому что у нас сегментация», спросите его: а хост с WAC точно вынесен в особый, изолированный сегмент, куда нет доступа с пользовательских VLAN? По моему опыту, в 7 из 10 случаев ответ будет «не совсем».

Что делать? Не просто «применить патч». Работать нужно системно.

Меры, которые нельзя откладывать:

1. Срочно проверьте права. Зайдите на каждый хост с установленным Windows Admin Center и выполните простую команду в PowerShell: Get-Acl C:\ProgramData\WindowsAdminCenter | Format-List. Убедитесь, что в правах нет групп вроде Users или Authenticated Users на запись (Write, Modify). Если есть — немедленно исправьте, оставив только SYSTEM и администраторов. Это база.
2. Инвентаризация и аудит. Составьте реестр всех установленных WAC — это часто выпадает из поля зрения. Удивительно, но многие команды не знают, на скольких машинах он вообще стоит. А потом проверьте, какие расширения там установлены. Каждое — это потенциальный вектор, особенно если оно кастомное.
3. Сегментация и изоляция. Хост с инструментом уровня администрирования не должен быть доступен из общих сетей. Вынесите его в отдельный management-сегмент с жёстким контролем доступа (по IP, с обязательной MFA). Это не рекомендация, а must-have в 2025 году.
4. Включите аудит. Настройте детальный аудит успешных и неуспешных попыток доступа к самой папке C:\ProgramData\WindowsAdminCenter и на изменения в ней. Пусть ваша SIEM или EDR ловит любые подозрительные действия — это даст вам время на реакцию.

Но патчи и настройки — это лишь часть истории. Главное — менять подход.

Вот 10 правил 2026 года для администратора, который не хочет стать причиной инцидента:

1. Никогда не оставляйте софт с дефолтными настройками в продакшене. WAC — лишь один пример. Любой инструмент администрирования (Ansible, Chef, даже ssh) после установки требует жёсткой затяжки прав.
2. Принцип наименьших привилегий — не красивая фраза, а мантра. Если процессу не нужны права на запись — отнимите их. Если пользователю не нужен доступ к папке — закройте.
3. Аудит конфигураций — это непрерывный процесс, а не разовая акция. Внедрите автоматическую проверку дрейфа конфигураций. Я использую для этого связку скриптов и базовую DSC, и это не раз спасало.
4. Любой скрипт, запускаемый с повышенными привилегиями, должен иметь криптографическую подпись. И политика PowerShell должна это жёстко требовать (AllSigned). Никаких исключений.
5. DLL Hijacking — вечная классика. Используйте инструменты вроде Sysmon с конфигурацией SwiftOnSecurity для отслеживания загрузки DLL из непредназначенных для этого путей.
6. Обновления — важно, но сначала — изоляция. Прежде чем ставить патч, изолируйте уязвимый актив от сети. Бывали случаи, когда в процессе обновления на уже подозрительный хост и приходила реальная атака.
7. МФА везде, где это возможно. Даже для доступа к внутреннему админ-порталу. Сотни инцидентов начинаются с украденного пароля, который ничего не защищал.
8. Тренируйте реагирование на конкретные сценарии. Проведите учение: «обнаружена подозрительная запись в каталог WAC». Уверены, что ваша SOC-команда поймёт, что это критично?
9. Читайте отчёты не только Microsoft, но и независимых исследователей. Cymulate, Zero Day Initiative — они часто находят то, что пропускают вендоры.
10. Доверяйте, но верифицируйте. После всех исправлений смоделируйте атаку сами. Попробуйте (на тестовом стенде!) воспроизвести эксплуатацию CVE-2025-64669. Это лучший способ проверить свою защиту.

Выполнили всё по списку? Отлично. Но работа не закончена. Безопасность — это про постоянное движение.

По правде говоря, меня раздражает, когда уязвимости вроде этой называют «несложными». Потому что именно они и горят чаще всего. Это как оставить ключи от сейфа на тумбочке в прихожей — взлом не потребует genius-level навыков, только наглость.

══════

Нужна помощь? Не уверены, что ваша инфраструктура защищена от подобных «детских» ошибок?

Оставьте заявку на Бесплатную консультацию на сайте: https://securedefence.ru/
Пришлём чек-лист аудита прав доступа для инструментов администрирования + дорожную карту приведения в соответствие с ФСТЭК + КП. Первые 5 заказов каждый месяц — расширенный аудит на 12 страниц в подарок!

══════

FAQ — отвечаю на главные вопросы

1. Это точно актуально для России? Ещё как. Требования ФСТЭК (приказы, документы Банка России) прямо предписывают контроль целостности и разграничение доступа. Эта уязвимость — прямое их нарушение.
2. У нас стоит WAC версии 3.0, мы защищены? Патч закрыл конкретную ошибку. Но проверьте права на папку вручную! И убедитесь, что не наследовались старые, небезопасные ACL.
3. DLL Hijacking — это сложно? Нет, это одна из самых простых техник. Для защиты нужен корректный аудит и мониторинг загрузки библиотек.
4. Какие EDR лучше всего ловят такие атаки? Любой современный EDR с качественными правилами обнаружения. Ключевое — чтобы вы настроили алерты на создание/модификацию файлов в ключевых системных и софтверных папках.
5. Обязательно ли выносить WAC на отдельный сервер? Сильно рекомендую. Это снижает риски пересечения с пользовательскими активностями и упрощает контроль.
6. Что, если я просто удалю WAC? Это вариант. Но тогда вам нужна альтернативная, не менее защищённая система управления. Проблема не в WAC, а в подходе к безопасности любого админ-инструмента.
7. Как проверить, не скомпрометирован ли хост уже сейчас? Ищите недавно созданные или изменённые .ps1, .dll, .exe файлы в папке C:\ProgramData\WindowsAdminCenter и её подкаталогах. Анализируйте логи на предмет запуска PowerShell от имени служб.
8. Это касается только Windows Server? Нет, WAC можно установить и на Windows 10/11 для управления. Риск тот же.
9. Где взять чек-лист для проверки? 👇
10. Сколько времени займёт закрытие этой уязвимости? На проверку и исправление прав на одном хосте — 15 минут. На полноценный аудит всей инфраструктуры — от нескольких часов до дней, в зависимости от масштаба.

Не ждите, пока в ваших логах появятся первые признаки реальной эксплуатации. Такие уязвимости злоумышленники используют тихо и незаметно, чтобы оставаться внутри вашей сети месяцами.

══════

Остались вопросы или нужна помощь с аудитом? Пишите.

Нужна помощь?

Оставьте заявку Бесплатной консультации на сайте: https://securedefence.ru/
Пришлём чек-лист + дорожную карту + КП. Первые 5 заказов каждый месяц — расширенный аудит на 12 страниц в подарок

══════

Больше материалов: Центр знаний SecureDefence.