Certighost: уязвимость в Certification Authority даёт хакерам контроль над доменом

Зрелые среды Active Directory содержат компонент, который незаметно концентрирует в себе больше власти, чем принято признавать: Certification Authority (CA). Это система, которой доверяет вся инфраструктура. Когда CA подписывает сертификат, каждая машина, служба и процесс аутентификации воспринимают эту подпись как истину. Слишком большая ответственность для одного компонента, который часто настраивают один раз и забывают о нём.

Уязвимость Certighost, отслеживаемая как CVE-2026-54121, демонстрирует, что происходит, когда доверие оказывается ошибочным. Исследователи опубликовали рабочий proof-of-concept 24 июля 2026 года. Он показывает, как низкопривилегированный пользователь Active Directory (с обычной учётной записью домена) может заставить Enterprise CA выдать действительный сертификат аутентификации для контроллера домена, а затем использовать его для получения прав контроллера домена.

Microsoft выпустила исправление 14 июля 2026 года, оценив серьёзность в 8,8 балла по шкале CVSS.

Механика атаки Certighost

Active Directory Certificate Services — это инфраструктура открытых ключей Microsoft, которая выпускает и управляет сертификатами для входа по смарт-картам, аутентификации устройств и пользователей, а также доступа к VPN. Обычный пользователь домена не должен получать сертификат, представляющий контроллер домена, однако Certighost нарушает эту границу, не прикасаясь к спискам контроля доступа.

Уязвимость кроется в поведении регистрации AD CS, известном как «chase»-функциональность. Когда Enterprise CA не может немедленно разрешить целевой объект локально, он может следовать переданной запрашивающей стороной информации о маршрутизации (параметр cdc), чтобы найти объект в другом месте. Дефект в том, что CA никогда не проверяет, является ли конечная точка, указанная в cdc, легитимным контроллером домена, прежде чем обратиться к ней.

Злоумышленник указывает на машину под своим контролем в cdc, и CA послушно устанавливает исходящее соединение с этим мошенническим endpoint’ом. Тот отвечает поддельными данными идентификации, включая SID целевого контроллера домена и его DNS-имя. CA доверяет полученной информации, привязывает эту идентичность к подписанному сертификату X.509 и выдаёт атакующему сертификат, который говорит: «Вы — контроллер домена».

Далее атака развивается по известному сценарию. Злоумышленник использует сертификат с PKINIT (расширение Kerberos на основе открытых ключей), чтобы получить Ticket Granting Ticket для учётной записи машины контроллера домена. Учётные записи контроллеров домена по своей природе обладают правами репликации каталога, которых достаточно для выполнения операции DCSync против реального контроллера домена и извлечения учётных данных, вплоть до хэша учётной записи krbtgt. Получив krbtgt, злоумышленник может подделывать билеты Kerberos по своему усмотрению, и домен фактически оказывается под его контролем.

Для тестирования было достаточно стандартной учётной записи пользователя домена, поскольку настройки Active Directory по умолчанию, включая MachineAccountQuota, которая позволяет обычным пользователям создавать учётные записи машин, предоставили всё необходимое для цепочки атаки.

На момент публичного раскрытия подтверждённых случаев эксплуатации в дикой природе не было. Однако наличие рабочего proof-of-concept существенно снижает порог входа для воспроизведения атаки, а разрыв между «PoC существует» и «включено в инструментарий злоумышленников» измеряется неделями, а не годами.

Уязвимость новая, скрытая привилегия — старая

Certighost показал, как привилегии, скрытые в доверенных отношениях и overlooked defaults, могут стать путём к компрометации домена. Это не ошибка сертификатов, а провал в управлении привилегиями и доверием.

Если убрать всю «сертификатную» механику и посмотреть на форму атаки, то мы увидим: непривилегированная идентичность манипулирует доверенной системой, заставляя её поручиться за привилегированную идентичность, а среда не имеет механизма, чтобы усомниться в результате. Это проблема валидации доверия, лежащая в основе безопасности идентичности.

Certification Authority — не пассивное устройство. Это привилегированная идентичность, которая производит доверие от имени всего домена. Исправление Microsoft, по сути, добавляет шаг проверки, гарантирующий, что цель chase-запроса действительно является контроллером домена. Это типичный признак атак, нацеленных на идентичность: злоумышленник редко взламывает криптографию или аутентификацию. Он находит место, где система решила доверять без проверки.

Второй, более неприятный урок кроется в предусловиях. Конфигурация Active Directory по умолчанию даёт каждому аутентифицированному пользователю немного постоянных привилегий: возможность создавать учётные записи машин благодаря MachineAccountQuota, разрешающей это по умолчанию. Certighost — одна из многих цепочек атак, которые тихо зависят от этой постоянной возможности. Конкретный CVE новый, но скрытая привилегия, на которую он опирается, присутствует в домене годами.

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

«Если ваша защита ограничивается номером KB, организация не извлекает долговременных уроков, потому что конкретная ошибка никогда не была главной проблемой».

Рекомендации по защите

• Установите обновление. Примените обновление Microsoft от 14 июля 2026 года ко всем издающим Certification Authority, так как оно вводит проверку назначения, которая блокирует конкретное злоупотребление chase-функциональностью. Если развёртывание задерживается, исследователи задокументировали обходной путь, отключающий уязвимую chase-функциональность. Но перед развёртыванием протестируйте его: этот путь существует для поддержки легитимных сценариев регистрации, и его отключение может их сломать.
• Уменьшите постоянные привилегии. Установите MachineAccountQuota в домене на ноль, чтобы убрать возможность обычных пользователей создавать учётные записи машин. Это значительно сократит поверхность атаки для данного класса техник. Однако учтите, что некоторые процессы provisioning’а и legacy-инструменты предполагают, что пользователи могут присоединять машины к домену. Инвентаризируйте такие зависимости и направьте создание машин через контролируемые делегированные учётные записи, а не оставляйте его открытым для всех.
• Ограничьте CA. Ограничьте исходящий SMB и LDAP от ваших Certification Authorities, чтобы они могли взаимодействовать только с известными, авторизованными контроллерами домена. Это напрямую подрывает шаг с мошенническим endpoint’ом в цепочке.
• Проведите аудит разрешений. Пересмотрите развёртывания Enterprise CA, шаблоны сертификатов и разрешения на регистрацию: какие принципалы могут запрашивать сертификат, и должна ли эта группа иметь право владеть идентичностью, которую представляет сертификат? Большинство сред никогда не проверяли права на регистрацию сертификатов по этому стандарту, а именно здесь зарождаются пути атак AD CS.
• Мониторьте правильный уровень. Следите за аномальным созданием учётных записей машин, необычной активностью регистрации сертификатов и операциями DCSync. Обращайте внимание на события регистрации CA, а не предполагайте, что телеметрия конечных точек поймает атаку на идентичность, для обнаружения которой она не предназначена. DCSync от кого-либо, кроме контроллера домена, заслуживает немедленной реакции. Если ваша система обнаружения не может это выявить, это пробел, который стоит закрыть.

Главный вывод: Certighost будет исправлен, каталогизирован и в основном забыт в течение квартала. Это ловушка. Если реакция остановится на номере KB, организация не извлечёт долговременных уроков, потому что конкретная ошибка никогда не была главной проблемой. Главная мысль в том, что доверие на предприятии — это то, что нужно проектировать и постоянно проверять, а не свойство, которое настраивается один раз и наследуется навсегда.

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

Читайте также: Как компьютерные вирусы используют уязвимости для захвата систем

Источник: BleepingComputer