Традиционный подход к мониторингу конечных точек сосредоточен на обнаружении вредоносного ПО: сигнатурный анализ, поведенческий детект, EDR. Это необходимо, но недостаточно для защиты критических информационных систем — таких, как Microsoft Configuration Manager (SCCM / ConfigMgr). Тот, кто управляет SCCM-сервером, управляет инфраструктурой целого предприятия. Именно поэтому SCCM требует особого режима мониторинга, аудита и контроля изменений.
В этой статье мы покажем, как логическая уязвимость CVE-2025-47179 позволяет получить полный контроль над SCCM, и как нужно мониторить подобные атаки, которые не детектируются традиционными средствами защиты от вредоносного ПО.
Уязвимость в модели ролей#
Встроенная роль CMPivot Administrator по документации должна давать единственное право — запускать CMPivot, диагностический инструмент для выборки данных с клиентов в реальном времени. Минимально необходимый набор разрешений для этого: Collection.Read и Collection.Run CMPivot. Но как обнаружили исследователи SpecterOPS, роль содержала три дополнительных разрешения:
| Разрешение | Что позволяет |
|---|---|
| Users.Add | Создать нового административного пользователя и назначить ему любую security role |
| Users.Modify | Изменить существующего административного пользователя и назначить ему любую security role |
| Security Roles.Modify | Изменить существующую кастомную роль и добавить в неё любые permissions |
Таким образом, любой участник роли CMPivot Administrator мог в несколько API-вызовов назначить себе или любому другому аккаунту роль Full Administrator — и получить полный контроль над SCCM.
Это логическая уязвимость: здесь нет переполнения буфера, инъекции или обхода аутентификации. SCCM работал строго по правилам, которые в него заложили. Ошибка — в самих правилах: задокументированное назначение роли и её фактические полномочия противоречат друг другу.
Подобные уязвимости особенно опасны именно потому, что не детектируются традиционными средствами защиты: нет аномального сетевого трафика, нет эксплойта, нет вредоносного файла. Есть только легитимный администратор, выполняющий легитимные API-вызовы с легитимными правами — но не теми, которые ему должны были быть выданы.
Техника эксплуатации#
Механика атаки сводится к трём шагам, реализуемым через нативный WMI-интерфейс SCCM.
Шаг 1. Атакующий, обладающий правом Users.Add, создаёт экземпляр класса SMS_Admin — запись об административном пользователе в хранилище SCCM.
Шаг 2. К этому экземпляру прикрепляется массив объектов SMS_APermission, каждый из которых описывает одно назначение прав:
RoleID = “SMS0001R” — идентификатор роли Full Administrator
CategoryID = “SMS00ALL” — область видимости «All»
CategoryTypeID = 1 / 29 — тип категории (коллекция / security scope)
Шаг 3. Вызов ManagementObject.Put() сохраняет экземпляр на SCCM-сервере.
Никаких дополнительных инструментов не требуется — всё реализуется через System.Management (.NET), доступный в любой версии PowerShell. Запрос к SCCM выглядит неотличимо от штатных действий консоли Configuration Manager.
Именно эту технику воспроизводит скрипт AddSMSAdmin_Hybrid.ps1, использованный при верификации уязвимости (это логическая уязвимость, поэтому это не эксплоит, а просто скрипт):
Скрипт запускался от имени пользователя, у которого из прав на SCCM — только Users.Add / Users.Modify. Этого достаточно:
Как детектировать#
Наш инструмент SCCMInfo реализует мониторинг SCCM-сервера через подписку на события WMI. Для каждого из контролируемых классов регистрируется watcher:
SELECT * FROM __InstanceCreationEvent WITHIN 1
WHERE TargetInstance ISA 'SMS_Admin'Событие срабатывает в момент создания любой новой записи об административном пользователе, то есть именно при эксплуатации CVE-2025-47179 через Users.Add.
Компонент SmsAdminEnricher извлекает из события и записывает в структурированный лог (может и в журнал Windows) поля, которые показывают, что добавили Административного пользователя с таким SID:
Можно увидеть, что этого пользователя добавил некто LOGAN_CABRERA…
…И назначил ему роли администратора сайта:
Логика детектирования использует два независимых сигнала тревоги:
CreatedBy — неизвестный пользователь. Штатное добавление администраторов SCCM производится сайт-администраторами (в подавляющем большинстве случаев). Если CreatedBy — учётная запись, которая не входит в список известных сайт-администраторов, это повод немедленно начать расследование. Именно такая ситуация и возникает при эксплуатации через Users.Add: пользователь с ограниченной ролью (CMPivot Administrator) выступает инициатором.
RoleNames содержит Full Administrator. Назначение самой привилегированной роли в иерархии — само по себе событие, требующее верификации. В сочетании с нестандартным CreatedBy — это однозначный индикатор компрометации.
Добавление новых SCCM-админов можно также мониторить на событии аудита 4732. Однако важно учесть, что из данного события невозможно точно выявить, кто именно добавил админа, так как SubjectUserName всегда будет указывать на машинную учётную запись SCCM:
Универсальность подхода#
Уязвимость CVE-2025-47179 исправлена в ноябре 2025 года, затронутые версии — Configuration Manager 2403, 2409, 2503. Однако это лишь один частный случай, на котором мы можем показать универсальный подход к мониторингу SCCM. Инструмент SCCMInfo отслеживает несколько классов WMI-событий:
| WMI-класс | Что означает срабатывание |
|---|---|
| SMS_Admin | Новый административный пользователь — изменение модели доступа |
| SMS_Scripts | Добавлен новый скрипт — потенциальный механизм выполнения кода |
| SMS_SCI_Reserved | Изменение конфигурации сайта — изменение параметров инфраструктуры |
| SMS_DeploymentInfo | Новое развёртывание — выполнение кода/установка ПО на конечных точках |
| SMS_CombinedDeviceResources | Новое устройство в инвентаре — расширение периметра управления |
Ни одно из этих событий не связано с вредоносным ПО напрямую. Каждое из них — легитимное действие в рамках штатной работы SCCM. Именно поэтому их важно мониторить: атакующие, получившие доступ к SCCM, действуют через штатные механизмы, а не через эксплойты; такие атаки не детектируются традиционными средствами защиты.
Выводы#
Microsoft Configuration Manager (SCCM) заслуживает особого уровня мониторинга, поскольку при захвате злоумышленниками он превращается в настоящий центр управления атаками:
Хранилище секретов. Учётные данные, используемые для сетевых операций SCCM, хранятся в базе данных сайта и доступны Full Administrator.
Централизованное исполнение кода. Один скрипт или пакет — и он выполняется на тысячах устройств одновременно.
Изменения конфигурации без следов на конечных точках. Модификация политики через SMS_SCI_Reserved не оставляет артефактов на управляемых машинах до момента применения политики.
Поэтому добавление пользователей с высокими правами, появление новых скриптов, изменение конфигурации сайта — всё это должно фиксироваться, верифицироваться и при необходимости расследоваться. Мониторинг SCCM на уровне WMI-событий позволяет детектировать именно такие изменения в модели управления — в реальном времени, без агентов на стороне SCCM-сервера. Это ортогонально традиционным средствам защиты и закрывает слепые зоны, которые те не видят.
О других техниках атак на SCCM, а также о методах их детектирования вы можете узнать, если посмотрите запись нашего доклада “Что может пойти не так, если SCCM окажется не в тех руках”.