Исследователи H0j3n и Aniq Fakhrul опубликовали 24 июля рабочий эксплойт под названием Certighost, который бьёт по службе сертификатов Active Directory (AD CS). Уязвимости присвоили номер CVE-2026-54121, классифицировали как некорректную авторизацию и оценили в 8.8 баллов по CVSS — показатель, при котором обычно начинают шевелиться все, кто отвечает за инфраструктуру. Суть проста и от этого неприятна: пользователь с минимальными правами в домене может получить сертификат контроллера домена и, по сути, стать им. Дальше остаётся только запустить DCSync и вытащить секрет krbtgt — ключ, которым шифруется буквально всё в Kerberos-инфраструктуре Windows.
История раскрытия заняла чуть больше двух месяцев. 14 мая исследователи сообщили о находке в Microsoft, 22 мая компания подтвердила проблему. Патч вышел 14 июля, а публичное раскрытие с proof-of-concept состоялось десятью днями позже, 24 июля. На момент публикации уязвимости не было в каталоге известных эксплуатируемых уязвимостей CISA (KEV), и, судя по источникам, которые проверял The Hacker News, случаев эксплуатации в реальных атаках зафиксировано не было. Но отсутствие отчётов ещё не значит, что атак не было — просто о них никто не заявил.
Корень проблемы прячется в механизме под названием "chase" — это резервный сценарий регистрации сертификатов, который включается, когда центр сертификации (CA) не может самостоятельно найти информацию о конечном объекте. В такой ситуации протокол регистрации Windows позволяет запросу самому указать два параметра: cdc — сервер Active Directory, к которому нужно обратиться, и rmd — машинный объект, который требуется разрешить. Именно здесь и открывается лазейка.
Схема атаки выглядит так. Злоумышленник действует от имени обычной учётной записи Domain Users. Он создаёт учётную запись компьютера — по умолчанию параметр ms-DS-MachineAccountQuota разрешает каждому пользователю завести до 10 таких записей — либо использует уже подконтрольную машину. Затем на своей стороне поднимает поддельные службы LSA и LDAP, перехватывает challenge от CA и релеит его на настоящий контроллер домена через Netlogon. В ответ он получает objectSid и dNSHostName целевого контроллера домена. Подконтрольная машинная учётная запись подтверждает подлинность в домене, CA продолжает обработку запроса, аутентифицирует эту учётную запись и — вот в чём фокус — подписывает в сертификат идентичность настоящего контроллера домена, а не атакующей машины.
Дальше в ход идёт PKINIT, механизм аутентификации в Kerberos через сертификаты открытого ключа. С его помощью атакующий заходит в систему уже как контроллер домена. А поскольку учётные записи контроллеров домена по умолчанию обладают правами репликации каталога, полученный Kerberos-билет позволяет запустить DCSync и выкачать секреты всех учётных записей, включая krbtgt. Для всего этого не нужны права администратора и не требуется никакого взаимодействия с жертвой — только сетевой доступ и обычная учётная запись домена.
Исследователи выпустили и публичный инструмент, автоматизирующий всю цепочку. Он сам создаёт учётную запись компьютера либо принимает уже готовую через параметр --computer-name, поднимает слушатели на портах 445 и 389, релеит challenge CA на настоящий контроллер домена, подставляет параметры cdc и rmd и на выходе выдаёт PFX-файл вместе с кэшем Kerberos-билетов — то есть всё, что нужно для входа под видом контроллера домена.
Бинарный анализ июльского обновления Microsoft показал, что компания добавила новую функцию проверки — CRequestInstance::_ValidateChaseTargetIsDC — в компонент certpdef. Логика проверки теперь отсекает IP-адреса вместо имён, слишком длинные имена, LDAP-метасимволы в запросе и требует, чтобы нашёлся ровно один компьютерный объект в Active Directory, чьё DNS-имя совпадает с целевым и у которого в userAccountControl выставлен флаг SERVER_TRUST_ACCOUNT (значение 8192). Отдельно добавлена сверка SID, которая блокирует попытки подмены объекта.
В лабораторных условиях исследователи проверяли атаку на лесу Windows Server 2016 и новее, с корпоративным CA, стандартным шаблоном сертификата Machine и стандартной квотой машинных учётных записей. Но список в базе NVD заметно шире: туда включены версии от Windows Server 2012 до Windows Server 2025, включая соответствующие редакции Server Core, а также Windows 10 версий 1607 и 1809.
Основная рекомендация одна — установить июльские обновления от 14 июля на всех хостах AD CS, где работает Enterprise CA. Это единственное решение, которое можно считать постоянным. Для тех, кто по каким-то причинам не может обновиться немедленно, исследователи предложили временную меру — отключить резервный механизм "chase" командами:
certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force
Оговорка здесь важная: этот способ проверялся только в контролируемой лабораторной среде, и он способен сломать легитимные сценарии регистрации сертификатов в живой инфраструктуре. Прежде чем применять его на продакшене, исследователи советуют сначала прогнать изменения на тестовом стенде.
На 24 июля данных о реальной эксплуатации в дикой природе не поступало, а сама уязвимость ещё не попала в каталог KEV от CISA. Но рабочий эксплойт уже лежит в открытом доступе, и это меняет расклад — время между публикацией PoC и первой волной атак в подобных историях обычно измеряется днями, а не месяцами.
История раскрытия заняла чуть больше двух месяцев. 14 мая исследователи сообщили о находке в Microsoft, 22 мая компания подтвердила проблему. Патч вышел 14 июля, а публичное раскрытие с proof-of-concept состоялось десятью днями позже, 24 июля. На момент публикации уязвимости не было в каталоге известных эксплуатируемых уязвимостей CISA (KEV), и, судя по источникам, которые проверял The Hacker News, случаев эксплуатации в реальных атаках зафиксировано не было. Но отсутствие отчётов ещё не значит, что атак не было — просто о них никто не заявил.
Корень проблемы прячется в механизме под названием "chase" — это резервный сценарий регистрации сертификатов, который включается, когда центр сертификации (CA) не может самостоятельно найти информацию о конечном объекте. В такой ситуации протокол регистрации Windows позволяет запросу самому указать два параметра: cdc — сервер Active Directory, к которому нужно обратиться, и rmd — машинный объект, который требуется разрешить. Именно здесь и открывается лазейка.
Схема атаки выглядит так. Злоумышленник действует от имени обычной учётной записи Domain Users. Он создаёт учётную запись компьютера — по умолчанию параметр ms-DS-MachineAccountQuota разрешает каждому пользователю завести до 10 таких записей — либо использует уже подконтрольную машину. Затем на своей стороне поднимает поддельные службы LSA и LDAP, перехватывает challenge от CA и релеит его на настоящий контроллер домена через Netlogon. В ответ он получает objectSid и dNSHostName целевого контроллера домена. Подконтрольная машинная учётная запись подтверждает подлинность в домене, CA продолжает обработку запроса, аутентифицирует эту учётную запись и — вот в чём фокус — подписывает в сертификат идентичность настоящего контроллера домена, а не атакующей машины.
Дальше в ход идёт PKINIT, механизм аутентификации в Kerberos через сертификаты открытого ключа. С его помощью атакующий заходит в систему уже как контроллер домена. А поскольку учётные записи контроллеров домена по умолчанию обладают правами репликации каталога, полученный Kerberos-билет позволяет запустить DCSync и выкачать секреты всех учётных записей, включая krbtgt. Для всего этого не нужны права администратора и не требуется никакого взаимодействия с жертвой — только сетевой доступ и обычная учётная запись домена.
Исследователи выпустили и публичный инструмент, автоматизирующий всю цепочку. Он сам создаёт учётную запись компьютера либо принимает уже готовую через параметр --computer-name, поднимает слушатели на портах 445 и 389, релеит challenge CA на настоящий контроллер домена, подставляет параметры cdc и rmd и на выходе выдаёт PFX-файл вместе с кэшем Kerberos-билетов — то есть всё, что нужно для входа под видом контроллера домена.
Бинарный анализ июльского обновления Microsoft показал, что компания добавила новую функцию проверки — CRequestInstance::_ValidateChaseTargetIsDC — в компонент certpdef. Логика проверки теперь отсекает IP-адреса вместо имён, слишком длинные имена, LDAP-метасимволы в запросе и требует, чтобы нашёлся ровно один компьютерный объект в Active Directory, чьё DNS-имя совпадает с целевым и у которого в userAccountControl выставлен флаг SERVER_TRUST_ACCOUNT (значение 8192). Отдельно добавлена сверка SID, которая блокирует попытки подмены объекта.
В лабораторных условиях исследователи проверяли атаку на лесу Windows Server 2016 и новее, с корпоративным CA, стандартным шаблоном сертификата Machine и стандартной квотой машинных учётных записей. Но список в базе NVD заметно шире: туда включены версии от Windows Server 2012 до Windows Server 2025, включая соответствующие редакции Server Core, а также Windows 10 версий 1607 и 1809.
Основная рекомендация одна — установить июльские обновления от 14 июля на всех хостах AD CS, где работает Enterprise CA. Это единственное решение, которое можно считать постоянным. Для тех, кто по каким-то причинам не может обновиться немедленно, исследователи предложили временную меру — отключить резервный механизм "chase" командами:
certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force
Оговорка здесь важная: этот способ проверялся только в контролируемой лабораторной среде, и он способен сломать легитимные сценарии регистрации сертификатов в живой инфраструктуре. Прежде чем применять его на продакшене, исследователи советуют сначала прогнать изменения на тестовом стенде.
На 24 июля данных о реальной эксплуатации в дикой природе не поступало, а сама уязвимость ещё не попала в каталог KEV от CISA. Но рабочий эксплойт уже лежит в открытом доступе, и это меняет расклад — время между публикацией PoC и первой волной атак в подобных историях обычно измеряется днями, а не месяцами.