SCCM под угрозой: устраняем ошибки конфигурации
Введение
Microsoft Configuration Manager, более известный как System Center Configuration Manager (SCCM), — программный комплекс Microsoft, позволяющий администраторам централизованно управлять серверами и рабочими станциями из единой консоли.
По данным BI.ZONE SOC, он развернут в 25% российских организаций, преимущественно крупных, где особенно актуален из‑за большого числа пользователей и устройств. Это делает его привлекательным вектором для атак. Успешный захват управления SCCM, как правило, дает полный контроль над инфраструктурой компании, в частности, позволяет:
- получить доступ к административным привилегиям,
- горизонтально перемещаться внутри инфраструктуры,
- собирать информации о пользователях и устройствах,
- закрепиться в инфраструктуре и выполнять произвольный код на любом подконтрольном устройстве,
- управлять политиками и соответствием клиентов.
Также контроль над SCCM помогает злоумышленнику маскировать свою активность под стандартные операции обслуживания инфраструктуры и оставаться практически незаметным для СЗИ. Учетные записи (УЗ), используемые SCCM для управления клиентами, обладают привилегиями администраторов на конечных устройствах и нередко имеют высокие привилегии в Active Directory (AD). Получить их можно и без захвата самой инфраструктуры SCCM — с помощью методов, эксплуатирующих ошибки конфигурации, допущенные при настройке системы.
Эксплуатация ошибочных настроек SCCM — один из типичных путей компрометации корпоративной инфраструктуры. Поэтому обнаружение и исправление мисконфигураций — одна из ключевых задач кибербезопасности. В статье мы подробно рассмотрим распространенные ошибки конфигурации, которые регулярно возникают при развертывании и использовании SCCM. Также предложим варианты усиления безопасности системы с учетом особенностей эксплуатации.
Базовые принципы безопасного построения SCCM
Планирование инфраструктуры
Правильное проектирование инфраструктуры SCCM на этапе развертывания значительно сокращает поверхность атаки. Ниже — ключевые рекомендации по сегментации, изоляции и ограничению доступа.
Изоляция
Ограничьте сетевое взаимодействие клиентов и ролей сайт‑сервера только необходимыми для работы портами и протоколами. Как минимум роли Site Server, SMS Provider и Site Database Server должны располагаться на серверах в самом защищенном сегменте сети уровня Tier 0. Клиентам не требуется прямое взаимодействие с этим ролями: они обеспечивают функционирование всего комплекса, хранят и обрабатывают данные, выполняют операции обслуживания и являются первоочередными целями для злоумышленников.
Перечисленные роли не рекомендуется совмещать на одном сервере с ролями, с которыми напрямую взаимодействуют клиенты. Для подключения клиентов, находящихся вне корпоративной инфраструктуры, настройте выделенные серверы в зоне DMZ. Эти серверы не должны одновременно управлять и локальными, и интернет‑устройствами. Для инженеров, выполняющих административные операции, используйте jump‑хосты.
От чего защищаемся
При компрометации любого клиентского устройства или учетной записи пользователя возникают риски захвата инфраструктуры SCCM и компрометации критически важных для бизнеса систем.
Tier‑модель
Не используйте одну инфраструктуру SCCM для управления активами из двух и более сегментированных лесов Active Directory или уровней безопасности (security tiers) в рамках одной иерархии. Не рекомендуется применять SCCM для управления сущностями контура Tier 0 (контроллеры домена, гипервизоры и другие). Если необходимо, разверните для этих целей отдельную изолированную структуру.
От чего защищаемся
Компрометация менеджера конфигураций в отдельном домене не должна приводить к компрометации критически важной инфраструктуры или других доменов и лесов Active Directory, связанных доверительными отношениями с данным доменом.
Доступ к базе данных сайта (БД)
Рекомендуется использовать отдельный экземпляр SQL для базы данных SCCM и ограничить число пользователей, имеющих доступ к БД с возможностью чтения и изменения, включая пользователей с правами sysadmin.
От чего защищаемся
В базе данных сайта хранятся все параметры работы системы, в том числе учетные данные, используемые SCCM. Они находятся в таблице SC_UserAccount, в которой содержатся не только имена, но и секреты. Если злоумышленник получит эти данные, он сможет расшифровать секреты с помощью скомпрометированного ключа сайт‑сервера или непосредственно на самом сайт‑сервере SCCM. Любой пользователь с правами редактирования БД может внести изменения в работу системы и повысить права до уровня администратора инфраструктуры SCCM.
Принцип минимальных привилегий
SCCM использует несколько типов учетных записей. Избыточные привилегии у любой из них — прямой путь к компрометации инфраструктуры. В этом подразделе разберем, как настроить минимально необходимые права для каждой роли.
Network Access Account (NAA)
Учетная запись сетевого доступа NAA используется клиентами для аутентификации при получении содержимого с точек распространения. Для этого пароль УЗ должен быть доступен клиентам, что требует его передачи и локального хранения на каждом управляемом устройстве в зашифрованном виде. Однако такое шифрование не является существенным препятствием для злоумышленника, обладающего правами локального администратора: он может легко расшифровать и извлечь учетные данные с помощью общедоступных инструментов, таких как SharpSCCM, SharpDPAPI или mimikatz.
Откажитесь от использования NAA в инфраструктуре и настройте использование HTTPS или Enhanced HTTP на точке распространения SCCM. Все ранее использовавшиеся в качестве NAA учетные записи должны быть заблокированы в Active Directory, так как клиенты могут еще долго хранить информацию о них в локальных хранилищах.
Если отказаться от NAA нельзя, минимизируйте поверхность атаки:
- Используйте отдельную сервисную учетную запись для NAA.
- Минимизируйте привилегии, предоставляемые этой УЗ.
- Ограничьте права входа — запретите интерактивный вход, вход через службы удаленных рабочих столов, вход в качестве сервиса и пакетного задания.
- Настройте мониторинг активности УЗ. Например: событие — 4624/4625, тип входа — 3, имя пользователя — <имя NAA>, компьютер, на котором зарегистрированы события, — не является сервером SCCM с ролью точки распространения.
В соответствии с принципом минимальных привилегий учетной записи NAA достаточно возможности получить доступ к контенту на точке распространения. Административные права на хосте или в домене ей не требуются.
Чтобы определить используемые NAA‑аккаунты, в консоли SCCM перейдите по пути: Administration → Overview → Site Configuration → Sites (выберите сайт) → контекстное меню → Configure Site Components → Software Distribution → вкладка Network Access Account. В списке будут показаны учетные записи, используемые клиентами для доступа к точке распространения ПО.
От чего защищаемся
Часто NAA обладает избыточными правами, например членством в группе локальных администраторов или Domain Admins. Однако на начальных этапах атаки даже обладание УЗ, входящей в Domain Users, дает возможности для разведки и перемещения внутри периметра организации. Из‑за особенностей работы агента SCCM с очисткой данных из WMI‑репозитория в локальных файлах клиента и WMI могут оставаться сведения о ранее использованных NAA, даже если в текущей конфигурации NAA не применяется. Кроме того, информация об актуальных учетных записях и их пароли могут быть извлечены из клиентских политик и последовательностей задач по установке ОС. Поэтому отказ от NAA — один из приоритетных шагов по усилению безопасности инфраструктуры SCCM.
Client Push Account
Client Push Account — учетная запись для автоматической установки клиента на подконтрольных устройствах, должна обладать правами администратора на целевых устройствах.
Если для распространения SCCM на устройства в инфраструктуре организации используется метод принудительной установки клиента сайт‑сервером (client‑push‑установка), минимизируйте поверхность атаки:
- Для автоматической установки клиентов используйте отдельную сервисную УЗ.
- Не используйте принудительную установку агента в рамках одного сайта для устройств из разных контуров безопасности, например, рабочих станций и серверов.
- Минимизируйте привилегии: вместо добавления учетных записей в группы Domain Admins или аналогичные создайте отдельные группы безопасности, включите в них используемые для установки УЗ и с помощью групповых политик добавьте эти группы в локальные администраторы на соответствующие группы устройств.
- Ограничьте права входа в систему для УЗ, используемой для установки агента. Запретите интерактивный вход, вход через службы удаленных рабочих столов, вход в качестве сервиса и пакетного задания.
- Настройте мониторинг активности УЗ. Например: событие — 4624/4625, тип входа — 3, имя пользователя — <имя Client Push Account>, адрес источника — не сервера SCCM.
Чтобы определить используемые учетные записи для принудительной установки клиента, в консоли SCCM перейдите по пути: Administration → Overview → Site Configuration → Sites (выберите сайт) → в верхней части окна выберите Client Installation Settings → в выпадающем списке выберите Client Push Installation → вкладка Accounts.
В списке будут представлены УЗ, используемые сервером для установки агентов.
От чего защищаемся
Компрометация Client Push Account облегчает злоумышленнику горизонтальное перемещение внутри организации и открывает новые возможности для развития атаки. Часто привилегии этой УЗ избыточны: она может входить в Domain Admins, иметь права в базе данных SCCM или предоставлять административные права не только на контролируемых SCCM узлах.
Учетная запись компьютера с ролью сервера сайта
Проведите аудит привилегий УЗ компьютера с ролью сервера сайта в Active Directory, а также сценариев ее использования:
- Для отдельных функций по возможности настраивайте ограниченные сервисные аккаунты, вместо того чтобы наделять дополнительными привилегиями УЗ компьютера с ролью сервера сайта.
- Не допускайте членства такой УЗ в привилегированных группах AD (Domain Admins, Enterprise Admins и других).
- Настройте мониторинг активности УЗ. Например: событие — 4624/4625, имя пользователя — <имя компьютера сервера сайта>, адрес источника — не сервер сайта SCCM.
От чего защищаемся
УЗ компьютера с ролью сервера сайта по умолчанию используется во многих сценариях работы SCCM: установка клиентов и ролей на подконтрольные сервера, работа с базой данных сайта, расширение схемы AD при развертывании SCCM в инфраструктуре, обнаружение объектов AD и другие. Часто эта запись обладает избыточными привилегиями (Domain Admins, Enterprise Admins и аналогичные), что делает ее приоритетной целью для захвата.
Учетная запись для ввода устройств в домен
Проведите аудит последовательностей задач по установке ОС средствами SCCM:
- Не используйте одни и те же УЗ для последовательностей задач в разных границах безопасности (например, серверы и рабочие станции, рабочая и тестовая среда).
- Не добавляйте сервисную УЗ для ввода устройств в домен в группы Domain Admins. Руководствуясь принципом минимальных привилегий, создайте отдельное временное организационное подразделение (OU) для ввода устройств и назначьте сервисной записи только необходимые права и только на это OU. После установки ОС и ввода устройства в домен переместите УЗ из временного OU в соответствующее вашим политикам. Для всех дочерних объектов типа Computer временного OU делегируйте следующие права:
Create Computer objects Delete Computer objects Read All Properties Reset Password Validate Write to DNS hostname Validate Write to Service Principal Name - Ограничьте права входа: запретите интерактивный вход, вход через службы удаленных рабочих столов, вход в качестве сервиса и пакетного задания.
- Настройте мониторинг активности. Например: событие — 4624/4625, имя пользователя — <имя учетной записи для ввода в домен>, адрес источника — несоответствие границе безопасности или адресам, где доступно развертывание ОС.
Чтобы определить УЗ, используемые для ввода устройств в домен, в консоли SCCM перейдите по пути: Software Library → Overview → Operating Systems → Task Sequences → для каждой последовательности задач выберите Edit → шаг Apply Network Settings (название по умолчанию). Если на этом шаге реализован ввод в домен, будут заполнены поля Domain, Domain OU, Account.
От чего защищаемся
В ходе выполнения последовательности задач SCCM по установки ОС на устройство один из шагов настраивает ввод устройства в домен. Для этого в последовательности указывается учетная запись Active Directory с соответствующими привилегиями. Информация о ней и пароль в зашифрованном виде хранятся в самой последовательности задач. Злоумышленник, имея доступ к инфраструктуре компании, может загрузить образ установки системы или политики развертывания через PXE и выполнить офлайн‑подбор пароля. Часто такие УЗ обладают излишними привилегиями (например, членство в Domain Admins), что приводит к быстрому захвату домена.
Административный доступ
Ограничьте административный доступ к серверам SCCM. Сервис предоставляет гибкую ролевую модель для управления правами пользователей и позволяет разделить управление сервисом и клиентами. Не используйте обезличенные УЗ для выполнения операций.
Чтобы определить УЗ, используемые для административных задач, в консоли SCCM перейдите по пути: Administration → Overview → Security → Administrative Users.
В разделе отображается список принципалов безопасности и назначенные им роли. Информацию о ролях и уровнях доступа можно посмотреть во вкладке Security Roles. Роль Full Administrator — роль администратора сервиса с максимальными привилегиями.
От чего защищаемся
Администратор SCCM имеет неограниченные возможности по компрометации обслуживаемой инфраструктуры. Компрометация его УЗ приведет к контролю сервиса злоумышленником. Обезличенные учетные данные затрудняют расследование инцидента и увеличивают риск утечки паролей.
Мисконфигурации при развертывании ОС
Выше мы рассмотрели базовые принципы безопасного построения SCCM. Теперь перейдем к конкретным ошибкам конфигурации, которые часто допускаются при внедрении и эксплуатации системы.
Отсутствие сетевой изоляции PXE
PXE‑развертывание — один из самых критичных векторов атак на SCCM. Злоумышленник, получивший возможность загрузить устройство по сети с помощью PXE, может не только развернуть легальное устройство для своих целей, но и извлечь учетные данные из загрузочного образа или последовательности задач для установки ОС.
Рекомендации
Изолируйте развертывание PXE в отдельных VLAN с помощью настроек сетевого оборудования. Это позволит:
- Ограничить доступ к PXE‑образам только для устройств в контролируемом сегменте.
- Предотвратить ошибочный вызов загрузки по PXE авторизованными пользователями и устройствами, не нуждающимися в развертывании.
- Снизить риск компрометации загрузочных образов и учетных данных.
Включена поддержка неизвестных устройств
В свойствах роли Distribution Point (DP) есть возможность разрешить любым неизвестным устройствам использовать установку ОС средствами SCCM. Используя эту функцию, злоумышленник, проникнув в инфраструктуру, может развернуть легальную доменную машину для своих целей или получить образ ОС и информацию о развертывании, содержащие чувствительные данные, в том числе учетную запись NAA или учетную запись, используемую для ввода устройств в домен.
Проверить, используется ли эта функциональность, можно с помощью командлета PowerShell Get‑CMDistributionPointInfo:
Get-CMDistributionPointInfo | select ServerName, SupportUnknownMachines ServerName SupportUnknownMachines ---------- ---------------------- SCCM01.TEST.LAB False
Рекомендации
Ограничьте поверхность атаки: не используйте поддержку неизвестных устройств в PXE. Для подготовки новых устройств создайте коллекции, содержащие MAC‑адреса или SMSBIOS GUID, и распространяйте задачи по установке ОС на эти коллекции.
Чтобы отключить поддержку неизвестных устройств для загрузки по PXE, в консоли пройдите по пути: Administration → Overview → Distribution point → выберите DP и откройте свойства → вкладка PXE. Снимите галочку с чекбокса Enable unknown computer support.
Добавить новое устройство в коллекцию для установки ОС по MAC‑адресу можно с помощью командлета PowerShell:
Import-CMComputerInformation -CollectionName "ComputersToDeploy" -ComputerName "test-ws-01" -MacAddress "00:12:34:56:78:9a"
Отсутствие пароля при PXE‑загрузке
Пароль необходим, чтобы предотвратить несанкционированный доступ к развертываниям ОС. Злоумышленники с помощью инструментов могут обнаружить загрузочные образы PXE в сети и, если они не защищены паролем, скачать их. В образах можно найти информацию о переменных и УЗ (например, Network Access Account) и использовать ее для дальнейшего продвижения в инфраструктуре. Установка пароля не гарантирует безопасность образа и учетных данных, но затрудняет доступ. Атакующий может использовать хеш для офлайн‑подбора, поэтому пароль должен быть сложным и стойким к перебору.
Получить информацию о требовании пароля при загрузке с PXE можно с помощью командлета PowerShell (в примере хеш пароля в поле PXEPassword) Get‑CMDistributionPointInfo:
Get-CMDistributionPointInfo | select Name, SiteCode, IsPXE, PXEPassword Name SiteCode IsPXE PXEPassword ---- -------- ----- ----------- SCCM01.MYHOME.LAB TST True 0C01000008000000010200001066000000A40000682BD... ADM01.MYHOME.LAB TST False
Рекомендации
Используйте сложный пароль для загрузки образа установки ОС.
Чтобы задать пароль, в консоли пройдите по пути: Administration → Overview → Distribution point → выберите DP и перейти в свойства → вкладка PXE. Отметьте чекбокс Require a password when computer use PXE и задайте пароль.
Включен доступ к командной строке в загрузочном образе
В загрузочном образе можно разрешить запуск интерпретатора командной строки, чтобы диагностировать ошибки развертывания ОС. Если опция активна, при загрузке с помощью этого образа нажатие F8 запускает cmd с правами системы без аутентификации. Злоумышленник может выполнить поиск чувствительных данных в загруженном образе, включая учетные записи и переменные, и взаимодействовать с инфраструктурой организации.
Получить информацию об использовании командной строки в загрузочном образе можно с помощью командлета PowerShell Get‑CMBootImage:
Get-CMBootImage | select name, EnableLabShell name EnableLabShell ---- -------------- Boot image (x64) True Boot image (arm64) False
Рекомендации
Используйте эту опцию только для диагностики ошибок и отключайте доступ к оболочке после завершения диагностики.
Чтобы отключить функцию, в консоли пройдите по пути: Software Library → Overview → Operating Systems → Boot Images → выберите boot‑образ → свойства → вкладка Customization. Снимите галочку с чекбокса Enable command support (testing only).
Избыточные права владельца компьютера в Active Directory
Если учетной записи делегированы права на создание компьютеров в домене, то владельцем созданного объекта становится та УЗ, которая выполнила ввод устройства в домен. В SCCM это, как правило, учетная запись, указанная в шаге Apply Network Settings последовательности задач по установке ОС. Права владельца позволяют читать и изменять атрибуты объекта, включая пароль LAPS.
Однако возможен и другой сценарий, когда права на создание компьютеров не делегированы явно. Тогда возможность создания объектов определяется привилегией SeMachineAccountPrivilege и квотой ms‑DS‑MachineAccountQuota домена. Учетная запись получит право создать компьютер, только если у нее есть эта привилегия, квота не равна нулю и лимит созданных ею устройств не исчерпан. В таком случае УЗ, использованная для ввода устройства в домен, также получает явные разрешения в ACL объекта на изменение его атрибутов, а ее идентификатор записывается в атрибут mS‑DS‑CreatorSID созданного компьютера.
Поэтому злоумышленник, завладевший учетной записью SCCM для ввода устройств в домен, сможет изменять созданные с ее помощью объекты. Это открывает возможности для горизонтального перемещения и повышения привилегий.
Получить список компьютеров AD и их владельцев можно с помощью PowerShell и командлета Get‑ADComputer:
Get-ADComputer -Filter * -Properties nTSecurityDescriptor, DistinguishedName | select DistinguishedName, @{ Name = 'Owner'; Expression = {$_.nTSecurityDescriptor.Owner} }
DistinguishedName Owner
----------------- -----
CN=AD01,OU=Domain Controllers,DC=test,DC=lab TEST\Domain Admins
CN=WS001,OU=Domain Computers,DC=test,DC=lab TEST\Domain Admins
CN=testws03,OU=Domain Computers,DC=test,DC=lab TEST\usr
CN=TESTPC02,OU=Domain Computers,DC=test,DC=lab TEST\Domain Admins
...Рекомендации
- Запретите пользователям самостоятельно вводить устройства в домен (MachineAccountQuota = 0).
- Используйте отдельную служебную запись для ввода устройств в домен. Не применяйте одну и ту же запись для разных контуров безопасности.
- Регулярно ищите компьютеры в AD, у которых владелец отличается от значений по умолчанию (Domain Admins), и меняйте владельца.
Мисконфигурации при установке клиента (client push)
Использование client push по умолчанию
Из всех методов установки агента client push — самый трудозатратный с точки зрения кибербезопасности. Он требует:
- учетную запись с административными правами на клиентских устройствах,
- настройку исключений фаервола,
- доступа к служебному общему ресурсу admin$ на клиентах.
Некорректно сконфигурированный процесс установки создает дополнительную нагрузку на вычислительные ресурсы. Сам процесс установки может быть уязвим для атак типа NTLM‑relay. Microsoft рекомендует использовать альтернативные методы распространения агента.
Рекомендации
Отключите автоматическую установку агентов методом client push. Используйте более безопасные методы: установку через групповые политики или через функцию обновления ПО.
Чтобы отключить использование client push, в консоли перейдите по пути: Software Library → Overview → Sites → выберите сайт → Client Installation Settings → Client Push Installation. Снимите галочку с чекбокса Enable automatic side‑wide client push installation.
Автоматическая установка агента на контроллеры домена
Если используется автоматическая установка агента методом client push, не рекомендуется устанавливать агенты SCCM на системы уровня Tier 0, включая контроллеры домена. В случае компрометации учетной записи для client‑push‑установки агента или учетной записи администратора SCCM злоумышленник получит возможность управления Active Directory.
Рекомендации
Не используйте автоматическую установку агента на контроллеры домена.
Чтобы отключить ее, в консоли перейдите по пути: Software Library → Overview → Sites → выберите сайт → Client Installation Settings → Client Push Installation. Выберите вариант Never install the Configuration Manager client on domain controllers unless specified in the Client Push Installation Wizard.
Разрешение понижения аутентификации до NTLM
Параметр разрешает серверу сайта использовать NTLM‑аутентификацию в качестве резервного варианта при автоматической установке агента. Если Kerberos‑аутентификация между сервером и клиентом невозможна, происходит откат на NTLM. Это делает процесс аутентификации уязвимым к атакам типа NTLM‑relay и открывает злоумышленнику возможности для горизонтального перемещения и повышения привилегий.
Рекомендации
Отключите использование NTLM в настройках автоматической установки клиента. Для этого в консоли перейдите по пути: Software Library → Overview → Sites → выберите сайт → Client Installation Settings → Client Push Installation. Снимите галочку с чекбокса Allow connection fallback to NTLM.
Мисконфигурации защищенных соединений (TLS)
Для безопасного взаимодействия компонентов SCCM между собой и с клиентами рекомендуется использовать TLS‑сертификаты. В актуальных версиях SCCM (2403+) TLS‑сертификаты для ролей уже обязательны, однако в более старых допускается использование незащищенного соединения. Оно делает процессы взаимодействия компонентов и клиентов уязвимыми для атак типа man‑in‑the‑middle (MitM), перехвата чувствительных данных и снижает общую безопасность системы. Для реализации защищенного соединения могут применять сертификаты корпоративного центра PKI (Public Key Infrastructure) или самоподписанные сертификаты SCCM (eHTTP).
Сертификаты корпоративного центра PKI — выбор в пользу максимальной безопасности, централизованного контроля и соответствия стандартам. Они предоставляют возможность в реальном времени отзывать доступ скомпрометированным устройствам, что критически важно для зрелых служб безопасности. Также сертификаты не ограничивают использование функций SCCM для управления только локальными клиентами.
Самоподписанные сертификаты SCCM — выбор в пользу простоты и удобства. Microsoft рассматривает Enhanced HTTP как безопасную альтернативу и рекомендует использовать этот тип сертификатов в небольших организациях без развернутой PKI, где клиенты находятся исключительно в локальной сети и нет необходимости управлять клиентами из интернета. Однако предпочтительнее использовать корпоративный PKI.
Незащищенное соединение с точкой распространения ПО
Точка распространения ПО отвечает за размещение ПО, доступного для установки клиентам. При использовании незашифрованного соединения доступ к дистрибутивам требует наличия учетной записи NAA. Информация о NAA хранится в политиках SCCM, последовательностях установки ОС и локально на клиентах, что позволяет злоумышленникам скомпрометировать эту запись и получить стартовую точку для работы в домене или при наличии расширенных прав у NAA повысить свои привилегии. Кроме того, при использовании незащищенных HTTP‑соединений трафик между серверами и клиентами передается в незашифрованном виде, что позволяет перехватывать и подменять контент, скачиваемый с DP.
Рекомендации
Используйте инфраструктуру открытых ключей корпоративного PKI, чтобы обеспечить безопасность всех коммуникаций в SCCM.
Чтобы проверить тип используемого соединения с ролью DP, в консоли перейдите по пути: Administration → Servers and Site System Roles → выберите сервер → Site System Roles → откройте свойства роли Distribution Point. Убедитесь, что выбран вариант использования корпоративного PKI, или установите сертификат.
Незащищенное соединение с точкой управления клиентами
Точка управления взаимодействует с клиентами и другими ролями сайта. Использование незащищенного соединения делает взаимодействие уязвимым для MitM‑атак и перехвата чувствительных данных. Самоподписанные сертификаты SCCM защищают соединение, но не выполняют проверку подлинности устройств и сервера. Сертификаты корпоративного центра PKI помимо защиты канала связи позволяют проверять подлинность сервера и клиента. Валидный сертификат на точке управления (Management Point, MP) доказывает клиенту, что тот подключается к легитимному серверу, а наличие сертификата у клиента идентифицирует этот клиент как легальное устройство и не допускает подключения неавторизованных или поддельных клиентов.
Рекомендации
Включите использование сертификатов корпоративного центра PKI на точке управления, чтобы защитить соединения с клиентами.
Чтобы проверить тип используемого соединения с ролью MP в консоли перейдите по пути: Administration → Servers and Site System Roles → выберите сервер → Site System Roles → откройте свойства роли Management Point. Убедитесь, что выбран вариант использования корпоративного PKI или установите сертификат.
Мисконфигурации прочих компонентов SCCM
Отсутствие аутентификации клиентов по PKI‑сертификатам
При использовании сертификатов корпоративного центра PKI можно настроить доверие между клиентом и точкой управления на основе этих сертификатов. Это защитит систему от атак, при которых злоумышленник подделывает запросы политик от имени валидных корпоративных устройств, чтобы найти учетные данные в клиентских политиках. Также это создаст дополнительные препятствия для атак с переадресацией NTLM‑аутентификации, эксплуатирующих автоматическую установку агента.
Рекомендации
Настройте требования к клиентским сертификатам PKI на стороне точки управления клиентами SCCM.
Чтобы проверить статус использования сертификатов для аутентификации клиентов, в консоли перейдите по пути: Administration → Site Configuration → выберите сайт → контекстное меню → Management Point → вкладка Communication Security. Убедитесь, что в чекбоксе Use PKI client certificate (client authentication capability) when vailable поставлена галочка. Также рекомендуется включить проверку сертификатов клиентов в списках отзыва (CRL).
Автоматическое одобрение всех устройств
Если аутентификация с помощью сертификатов PKI при установлении связи с новым клиентом невозможна, механизм одобрения клиентов позволяет принудительно идентифицировать доверенный компьютер. Доступны следующие режимы одобрения:
- Ручное одобрение администратором.
- Автоматическое одобрение компьютеров в доверенных доменах.
- Автоматическое одобрение всех компьютеров.
Если разрешить автоматическое одобрение компьютеров из недоверенных доменов, злоумышленник сможет использовать это для получения отправной точки в инфраструктуре.
Рекомендации
Настройте автоматическое одобрение только для компьютеров из доверенных доменов или выберите ручное одобрение.
Чтобы изменить поведение функции, в консоли перейдите по пути: Administration → Site Configuration → Sites → Hierarchy Settings → вкладка Client Approval and Conflicting Records. Выберите варианты Automatic approve computers in trusted domains или Manual approve each computer.
Разрешен анонимный доступ к точке распространения
В настройках DP присутствует возможность разрешения анонимного доступа к содержимому директорий с доступным для клиентов программным обеспечением. Если анонимный доступ на DP включен, файлы, хранящиеся на DP, можно проиндексировать и загрузить без аутентификации. Анонимный доступ к контенту, как правило, не требуется. Некоторые инструменты злоумышленников используют эту мисконфигурацию для поиска и извлечения учетных данных, хранящихся в теле скриптов для установки программного обеспечения на точках распространения.
Рекомендации
Не разрешайте клиентским устройствам подключаться анонимно к точкам распространения ПО SCCM. Эта функциональность используется, чтобы диагностировать ошибки или работать с устаревшими версиями агентов.
Чтобы изменить настройки доступа к точке распространения, в консоли перейдите по пути: Administration → Servers and Site System Roles → выберите сервер → Site System Roles → свойства роли Distribution Point. Снимите галочку с чекбокса Allow client to connect anonymously.
Отсутствие MFA для доступа к SMS Provider
При компрометации УЗ администратора SCCM злоумышленники получают полный контроль над управляемой инфраструктурой через стандартные механизмы SCCM. Предотвратить несанкционированный административный доступ можно с помощью внедрения второго фактора аутентификации (MFA) для SMS‑провайдера SCCM.
Рекомендации
Настройте требование многофакторной аутентификации для доступа к WMI/AdminService на SMS‑провайдерах сайтов. Подробности о внедрении MFA для SCCM можно найти на сайте вендора.
Использование устаревшей версии сервера SCCM
Регулярное обновление SCCM необходимо не только для совместимости с современными версиями ОС, но и для своевременного закрытия уязвимостей. Некоторые из них активно эксплуатируются злоумышленниками, а появление публичных эксплоитов сокращает время на установку исправлений. Рассмотрим наиболее значимые уязвимости.
CVE‑2022‑37972. Уязвимость, связанная с некорректным откатом на NTLM, если Kerberos‑аутентификация невозможна. Система игнорирует ограничение на использование NTLM в настройках установки клиента и все равно выполняет понижение уровня проверки подлинности. Уязвимые версии SCCM: c 2103 по 2207 включительно, если не установлено обновление KB15498768.
CVE‑2024‑43468. Критическая уязвимость удаленного выполнения кода из‑за недостаточной изоляции пользовательского ввода, приводящая к SQL‑инъекциям. Неаутентифицированный злоумышленник может отправить специально сформированные HTTP‑запросы и выполнить произвольные SQL‑команды с правами sysadmin. Это позволяет ему выполнять произвольные команды из‑под SYSTEM без аутентификации и получить полный контроль над сервером и базой данных. Уязвимость исправлена в октябре 2024 года, а в феврале 2026‑го CISA добавила ее в каталог активно эксплуатируемых после появления публичного эксплоита. Уязвимые версии:
- 2303 (до версии 5.00.9106).
- 2309 (до версии 5.00.9122).
- 2403 (до версии 5.00.9128).
CVE‑2025‑47178. Уязвимость, позволявшая выполнить SQL‑инъекции из‑за некорректной обработки специальных символов в SQL‑командах SCCM. Авторизованный злоумышленник с низким уровнем прав (например, роль Read‑Only Analyst), может выполнить произвольный SQL‑код, читать, изменять или удалять данные, а также повысить привилегии до sysadmin в базе данных, что соответствует правам Full Administrator в иерархии SCCM. Исправление доступно в версии 5.00.9135.1003.
CVE‑2025‑47179. Уязвимость локального повышения привилегий из‑за нарушений контроля доступа (Improper Access Control). Аутентифицированный злоумышленник с членством в группе CMPivot Administrator может повысить свои привилегии до уровня SYSTEM, так как группе ошибочно предоставлены права на создание и изменение пользователей и ролей SCCM. Затрагивает версии 2403, 2409 и 2503. Исправлена в обновлениях 5.00.9128.1037, 5.00.9132.1031, 5.0.9135.1013.
Учитывая 18‑месячный цикл поддержки каждой версии и быстрое появление эксплоитов для критических уязвимостей, рекомендуется обновлять инфраструктуру Configuration Manager не реже одного раза в год и устанавливать соответствующие обновления безопасности. Это минимизирует риски, связанные с неактуальными и неподдерживаемыми версиями ПО.
Мисконфигурации управления приложениями и удаленного доступа
Интерактивная установка приложений с правами SYSTEM
Установка приложений средствами SCCM должна быть автоматизирована, чтобы обеспечить однотипность конфигураций и сократить действия пользователя (предотвратить вмешательства в процесс установки). Однако иногда требуется дать пользователю возможность взаимодействовать с программой установки приложения. Это может создать сценарий повышения привилегий до уровня SYSTEM, если:
- установка запускается от имени SYSTEM,
- пользователю предоставлена возможность взаимодействия с окном процесса установки,
- установка идет не в скрытом режиме.
Если есть возможность запустить произвольный исполняемый файл через интерфейс установщика, злоумышленник может использовать это для повышения привилегий до уровня SYSTEM. Это справедливо и для установки приложения, и для установки пакета средствами SCCM.
Рекомендации
Исключите возможность взаимодействия пользователя с программой установки приложения от имени SYSTEM. Если это невозможно, ограничьте развертывание приложения и используйте механизмы одобрения администратором запросов на установку.
Чтобы проверить настройки типа распространения, в консоли перейдите по пути: Software Library → Application Management → Applications → выберите приложение → свойства → вкладка Deployment Types → выберите тип → нажмите Edit → User Experience. Измените настройки взаимодействия: автоматизируйте процесс и запретите пользователю взаимодействовать с установщиком или измените контекст установки на Install for user, если это возможно. В качестве альтернативы ограничьте распространение приложения и используйте одобрение установки администратором.
Удаленное подключение без подтверждения пользователя
Политики SCCM определяют, как клиентские устройства и пользователи взаимодействуют с сервером Configuration Manager и какие локальные настройки применяются. С помощью политик можно предопределить правила работы операторов удаленного управления. Если политика разрешает удаленное подключение к пользовательским сеансам без одобрения со стороны пользователя, то при компрометации УЗ оператора злоумышленник получает возможность кражи учетных данных других пользователей или горизонтального перемещения с помощью функции удаленного управления SCCM.
Рекомендации
Настройте политику удаленного управления так, чтобы оператор запрашивал разрешение у текущего пользователя системы перед подключением к его сеансу.
Чтобы проверить настройки, в консоли перейдите по пути: Administration → Client Settings → выберите политику → откройте ее свойства → Remote Tools. Для подключения оператора к клиенту необходимо, чтобы параметр Enable Remote Control on clients находился в статусе Enabled, а параметр Access level allowed был установлен в значение, отличное от No Access.
Если значение Prompt user for Remote Control permission равно No, разрешение у пользователя не требуется. Рекомендуется изменить это значение на Yes.
Мисконфигурации на клиентских устройствах
Удаленное управление без подтверждения пользователя на клиенте
SCCM предоставляет функции удаленного подключения к клиентам, часто используемые службами поддержки. Управление осуществляется через клиентские политики. Удаленное управление без подтверждения со стороны пользователя возможно, если на устройстве под управлением агента SCCM одновременно выполнены следующие условия:
- Удаленный доступ разрешен.
- Разрешено управлять рабочим столом или просматривать его.
- Подтверждения пользователя при подключении не требуется.
Если УЗ с правами на такие действия скомпрометирована, злоумышленник может использовать ее для горизонтального перемещения.
Рекомендации
Настройте требование подтверждения пользователем для подключения к сессии или принудительно отключите функцию удаленного управления с помощью клиентских политик SCCM.
Избыточные права на папку локального кеша
В папке ccmcahe на клиентской стороне кешируются установочные файлы ПО, исправлений и обновлений. Агент SCCM управляет этой папкой, устанавливая срок жизни контента и очищая ее в соответствии с настройками. Ручное удаление файлов не рекомендуется. Обладая правами на изменение, злоумышленник может подменить кешированные исполняемые файлы приложений и, если сценарий установки приложения SCCM предусматривает запуск от имени SYSTEM, повысить привилегии до SYSTEM. Вместе с установочными файлами в директории могут присутствовать скрипты для установки ПО, которые могут содержать учетные данные для доступа к ресурсам компании. Эти данные можно использовать для горизонтального перемещения или повышения привилегий.
Рекомендации
По умолчанию локальный кеш агента SCCM хранится в каталоге %windir%\ccmcache. Права на папку должны соответствовать рекомендуемым:
- Полный доступ — у администраторов и учетной записи SYSTEM.
- У остальных принципалов безопасности доступ на изменение отсутствует.
- Владелец папки — administrators или system.
Обнаружение мисконфигураций SCCM с помощью BI.ZONE EDR
Многие из описанных выше мисконфигураций можно обнаружить автоматически с помощью BI.ZONE EDR. Ниже приведены примеры срабатывания детектов решения.
Безопасность компонентов вокруг SCCM
Безопасность SCCM не исчерпывается настройкой самого менеджера конфигураций. Требуется системный подход к защите смежных компонентов: SQL, SMB‑протокола, служб каталогов и удостоверяющего центра.
Атаки на SCCM часто строятся на возможности ретрансляции NTLM‑аутентификации. Злоумышленник принуждает один из ключевых серверов (обычно сервер сайта или SQL Server) пройти аутентификацию на подконтрольном устройстве, а затем перенаправляет эту сессию на другой критический компонент. Успешная реализация позволяет выполнить произвольный код на сервере базы данных, изменить учетные записи в Active Directory или получить сертификат на имя привилегированной УЗ для повышения привилегий или закрепления в домене. Поскольку SCCM глубоко интегрирована в общую инфраструктуру компаний и сервисы Microsoft, говорить о харденинге системы в отрыве от харденинга используемых компонентов невозможно. Ниже приведены базовые рекомендации по защите инфраструктуры SCCM в корпоративной среде.
Харденинг SQL‑сервера
База данных SCCM — приоритетная цель для злоумышленников. Получив доступ на изменение БД, атакующий получит права администратора инфраструктуры SCCM.
Рекомендации
- Настройте требование расширенной защиты аутентификации (Extended Protection for Authentication, EPA). Эта мера привязывает сеанс NTLM к конкретному TLS‑каналу, делая ретрансляцию невозможной. Включение EPA требует планирования, так как поддерживается не всем ПО и работает с шифрованными каналами, что увеличивает нагрузку на сервер.
- На всех экземплярах SQL используйте Windows‑аутентификацию, а не смешанный тип.
- Переименуйте и отключите SA — встроенную учетную запись администратора SQL.
- Используйте отдельный выделенный сервер баз данных для SCCM, чтобы сократить количество принципалов безопасности с доступом к базе.
Ограничение использования NTLM‑аутентификации
Исследования показывают: если NTLM разрешен и не ограничен дополнительными параметрами безопасности, техники принуждения и переадресации NTLM‑аутентификации сайт‑сервера способны привести к быстрому захвату инфраструктуры SCCM. Один из вариантов противодействия — запрет использования NTLM для аутентификации. Полный запрет NTLM в домене может привести к неработоспособности некоторых сервисов, если отсутствует или не настроена поддержка Kerberos. Подобные изменения должны быть предварительно протестированы. Однако отказ от NTLM серьезно повысит общий уровень защищенности инфраструктуры, не только в контексте SCCM. Рекомендуется свести использование NTLM к небольшому документированному и отслеживаемому списку исключений, а в идеале полностью заменить Kerberos.
Рекомендации
Настройте запрет исходящего NTLM‑трафика для серверов с ролями SCCM: Site Server, Site Database Server, SMS Provider, Management Point, Distribution Point. С помощью редактора групповых политик перейдите по пути: Computer Configuration — Policies — Windows Settings — Security Settings — Local Policies — Security Options.
- Параметр Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers определяет, разрешено ли серверу инициировать NTLM‑аутентификацию. Доступные значения: 0 — разрешено, 1 — регистрировать все попытки, 2 — запретить. Сначала установите значение 1 и назначьте политику на серверы с ролями SCCM. Проанализируйте журналы событий и в случае необходимости примите решение о включении запретительных мер.
- Параметр Network Security: Restrict NTLM: Add remote server exceptions for NTLM authentication задает список исключений из политики Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers. В этот список можно внести удаленные серверы, для которых исходящая NTLM‑аутентификация останется разрешенной даже после включения запрета основным параметром.
Настройте политику и примените ее к серверам с перечисленными ролями.
Также с помощью групповых политик настройте запрет входящего NTLM трафика для этой же группы серверов:
- Параметр Network Security: Restrict NTLM: Incoming NTLM traffic управляет получением сервером NTLM‑аутентификации от клиентов. Доступные значения: 0 — разрешено, 1 — регистрация попыток, 2 — запрет. Начните с режима регистрации (1), проанализируйте события и после проверки переведите параметр в значение 2.
- Параметр Network Security: Restrict NTLM: Add server exceptions in this domain задает список исключений из этой политики для конкретных серверов в домене.
С помощью параметра Network security: LAN Manager authentication level можно запретить использование клиентами протоколов LM и NTLMv1. Это не защитит от переадресации NTLM, но предотвратит понижение уровня согласования до уязвимых протоколов. Политика должна применяться ко всем компьютерам домена.
Управлять возможностью NTLM‑аутентификации в домене также можно через групповую политику Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Restrict NTLM: NTLM authentication in this domain. Она применяется ко всем контроллерам домена и имеет несколько уровней безопасности, от разрешения до полного запрета. Эта политика не исключает необходимости настройки предыдущих параметров на серверах SCCM. Перед внедрением тщательно изучите влияние на инфраструктуру. Параметр Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain позволяет задать список исключений для этой настройки.
Харденинг удостоверяющего центра
Злоумышленник может заставить сервер сайта SCCM или контроллер домена аутентифицироваться по NTLM на подконтрольном веб‑сервере, а затем ретранслировать сессию на веб‑интерфейс удостоверяющего центра (CertSrv, CES). Если веб‑службы удостоверяющего центра используются без расширенной защиты аутентификаци (EPA), злоумышленник успешно проходит проверку подлинности и запрашивает сертификат с возможностью аутентификации — например, для сервера сайта SCCM или для SQL‑сервера.
Рекомендации
Ограничьте использование NTLM центром сертификации, ограничьте доступ к HTTP‑интерфейсам сервера, настройте EPA на сервере удостоверяющего центра. Подробнее об этих мерах — в нашей статье об атаках на инфраструктуру корпоративных центров сертификации.
Защита LDAP
Отсутствие требования к подписи на уровне LDAP позволяет злоумышленнику ретранслировать NTLM‑сессию для внесения изменений в Active Directory. Ретранслировав УЗ с подходящими правами, атакующий может создавать сущности AD с нужными параметрами.
Рекомендации
Откажитесь от NTLM‑аутентификации в инфраструктуре, где это возможно. Дополнительно настройте принудительное требование подписи LDAP‑пакетов и привязку каналов (Channel Binding) на всех контроллерах домена.
Изменение этих параметров безопасности оказывает влияние на всю инфраструктуру компании. Перед внедрением предварительно изучите требования и оцените влияние на управляемую вами среду.
Требование подписи SMB
По умолчанию протокол SMB не требует цифровой подписи пакетов. Это позволяет злоумышленнику ретранслировать перехваченную аутентификацию напрямую на SMB‑сервер — например, на точку распространения или на сервер SQL.
Рекомендации
Включите требование подписи SMB (SMB Signing) на серверах инфраструктуры, в том числе с ролью базы данных и серверах сайта. Это сделает ретрансляцию NTLM‑аутентификации невыполнимой: сервер откажется принимать неподписанные запросы.
Включение требования подписи оказывает влияние на всю инфраструктуру компании. Перед внедрением предварительно изучите требования и оцените влияние на управляемую вами среду.
Служба WebClient
SMB Signing защищает от ретрансляции NTLM через SMB, но если на сервере сайта работает служба WebClient, то злоумышленник может имитировать недоступность своего устройства по SMB, заставив сервер сайта перейти на более простой протокол WebDAV, не поддерживающий проверку подписи. Атакующий принуждает сервер сайта аутентифицироваться через WebDAV, а затем ретранслирует сессию на критический компонент (например, SQL) и получает права dbowner в базе, а значит, права администратора в SCCM.
Рекомендации
SCCM не использует службу WebClient, однако ее присутствие на серверах с ролями SCCM создает риск: злоумышленнику может заставить сервер аутентифицироваться через WebDAV и обойти настройки SMB Signing при NTLM‑ретрансляции. Поэтому рекомендуется удалить или отключить службу (именно отключить, а не остановить) на всех серверах с ролями SCCM. Чтобы отключить службу и остановить ее, воспользуйтесь PowerShell:
Set-Service Webclient -StartupType Disabled; Stop-Service WebClient -Force
Заключение
Недостатки настройки компонентов SCCM — будь то избыточные привилегии УЗ, отсутствие требований к подписи сетевых протоколов (SMB, LDAP) или использование слабых методов аутентификации — создают предпосылки для атак класса NTLM Relay, повышения привилегий и несанкционированного доступа к иерархии управления клиентами.
Планомерное устранение мисконфигураций целесообразно не только с точки зрения снижения рисков, но и с учетом соотношения затрат и результата. Исправление настроек менеджера конфигураций не требует дополнительных финансовых вложений или внедрения сложных технических решений. Для существенного повышения защищенности достаточно провести ревизию действующих политик и применить рекомендации из этой статьи. Каждая из мер закрывает конкретный класс атак и не требует кардинальной перестройки среды.
Борьба с мисконфигурациями SCCM — обязательный элемент поддержания безопасного состояния инфраструктуры. В условиях, когда злоумышленники активно автоматизируют поиск типовых ошибок конфигурации, игнорирование этой задачи равносильно добровольному снижению уровня защищенности. Приведение настроек системы в соответствие с актуальными рекомендациями Microsoft — минимальный, но критически важный шаг к построению устойчивой к атакам системы управления конфигурациями.