🛡 SCCM под угрозой: устраняем ошибки конфигурации SCCM развернут в 25% российских организаций, преимущественно крупных. Захват менеджера конфигураций даёт полный контроль над инфраструктурой: административные привилегии, горизонтальное перемещение, выполнение произвольного кода на любом подконтрольном устройстве. Типичный путь — не уязвимость нулевого дня, а ошибка в настройке. В свежем разборе habr_infosec специалист BI.ZONE перечисляет, что проверять. Самый опасный артефакт — Network Access Account. Пароль NAA локально хранится на каждом клиенте в зашифрованном виде. Локальный администратор расшифрует его с помощью mimikatz или SharpSCCM. Отказ от NAA в пользу HTTPS или Enhanced HTTP — приоритетный шаг. Но даже после отказа старые учётки остаются в WMI-репозитории и локальных файлах агента. Их надо блокировать в Active Directory. Client Push Account и PXE-развертывание — два других вектора атаки. Client Push часто входит в Domain Admins. PXE без изоляции VLAN позволяет загрузить легальную доменную машину или извлечь учётки из последовательности задач. Поддержка неизвестных устройств в PXE делает этот сценарий тривиальным. Проверять PowerShell: Get-CMDistributionPointInfo. Мониторинг: события 4624/4625, тип входа 3, имя NAA или Client Push Account, источник — не сервер SCCM. Это аномалия. Роли Site Server, SMS Provider и Site Database должны находиться в Tier 0. Клиентам не нужен прямой сетевой доступ к ним. Для меня SCCM — это Active Directory внутри Active Directory. Если роли сервера сайта не изолированы в Tier 0, а NAA всё ещё используется, атакующий получает легитимный канал управления, который SOC не отличит от штатной работы. Я бы начал не с сигнатур, а с аномалий в поведении сервисных учёток. #SCCM #Microsoft #ActiveDirectory #SOC #PXE #конфигурация