Certighost: обычный пользователь домена превращает центр сертификации в контроллер домена

В каждой зрелой инфраструктуре Active Directory есть компонент, власть которого обычно недооценивают сами администраторы, — центр сертификации (CA). Когда он подписывает сертификат, все машины, службы и потоки аутентификации ниже по цепочке принимают эту подпись как истину. Уязвимость Certighost (CVE-2026-54121) — напоминание о том, что бывает, когда это доверие оказывается ничем не подкреплённым.

Как работает атака

24 июля 2026 года исследователи опубликовали рабочий proof-of-concept: пользователь с обычной доменной учётной записью, не имеющий никаких дополнительных прав, способен заставить корпоративный CA выпустить действительный сертификат аутентификации для контроллера домена — а затем с его помощью стать этим контроллером.

Дефект скрыт в механизме перенаправления запросов enrollment, известном как «chase». Когда CA не может найти целевой объект локально, он следует за маршрутной информацией, переданной запрашивающей стороной (параметр cdc), и обращается за данными к указанному узлу. Проблема в том, что CA не проверяет, действительно ли этот узел является легитимным контроллером домена. Злоумышленник указывает в cdc собственную машину, та отвечает поддельными идентификационными данными — SID и DNS-имя нужного контроллера, — и CA послушно связывает эту личность с подписанным сертификатом X.509.

Дальше путь известен. Через PKINIT сертификат обменивается на билет Kerberos от имени машинной учётной записи контроллера, а такие учётки обладают правами репликации каталога. Операция DCSync против настоящего контроллера позволяет вытащить учётные данные вплоть до хэша krbtgt — после чего домен фактически принадлежит атакующему. Хватало обычного пользователя, потому что параметр MachineAccountQuota по умолчанию разрешает всем создавать машинные учётные записи.

Дело не в сертификатах

Microsoft выпустила исправление 14 июля 2026 года, оценив уязвимость в 8.8 балла по CVSS; патч добавляет проверку, что цель chase-запроса — действительно контроллер домена. Подтверждённых случаев эксплуатации в реальной среде на момент раскрытия не было, но публичный PoC резко снижает порог входа.

Автор материала подчёркивает: соблазн свести всё к номеру KB и забыть — и есть главная ловушка. Уязвимость новая, но привилегия, на которую она опиралась, лежала в домене годами. Атакующий здесь не ломает криптографию — он находит место, где система решила доверять без проверки. Центр сертификации сам по себе является привилегированной идентичностью, изготавливающей доверие от имени всего домена.

Что делать

Первым делом — установить июльское обновление на все выпускающие CA. Если развёртывание откладывается, есть документированный обходной путь — отключение уязвимой функции chase, но его нужно тестировать, поскольку она поддерживает легитимные сценарии enrollment. Дальше стоит сократить фоновые привилегии: установка MachineAccountQuota в ноль убирает право рядовых пользователей создавать машинные учётки, хотя это может сломать часть процессов присоединения к домену. Полезно ограничить исходящий SMB и LDAP от CA только к доверенным контроллерам, пересмотреть права на шаблоны сертификатов и наладить мониторинг аномального создания машинных учёток, необычного enrollment и операций DCSync — особенно DCSync, исходящих не от контроллера домена.

Общий вывод прост: доверие в корпоративной среде — то, что проектируют и постоянно проверяют, а не свойство, которое настраивают однажды и наследуют навсегда.

Источник: Bleeping Computer