Автор: Лен Ноу, архитект по решенията в BeyondTrust

Всяка зряла среда на Active Directory има компонент, който тихо притежава повече власт, отколкото хората, които я управляват, обикновено признават: сертифициращият орган (CA). Това е нещото, което цялата ви инфраструктура е съгласна да приема за безусловна истина.

Когато той подпише сертификат, всяка машина, услуга и поток от удостоверяване по веригата третират този подпис като истина. Това е огромно количество доверие, концентрирано в една система, и повечето организации я управляват като услуга, която се инсталира веднъж и никога повече не се мисли за нея.

Certighost, проследяван като CVE-2026-54121, е напомняне за това какво се случва, когато това доверие е погрешно насочено. Изследователите публикуваха работещ доказателствен концептуален код (PoC) на 24 юли 2026 г., демонстрирайки, че потребител с ниски привилегии в Active Directory (притежаващ нищо повече от стандартен домейн акаунт) може да принуди корпоративния сертифициращ орган (Enterprise CA) да издаде валиден сертификат за удостоверяване за Домейн контролер, а след това да използва този сертификат, за да се превърне в самия Домейн контролер.

Microsoft пусна корекция за сигурност на 12 юли 2026 г. и оцени уязвимостта с 8.8 по скалата CVSS.

Active Directory Certificate Services (AD CS) е инфраструктурата на публичния ключ на Microsoft, която издава и управлява сертификатите, поддържащи влизането с смарт карти, удостоверяването на устройства и потребители, както и VPN достъпа. Стандартен потребител на домейн няма никаква работа да получава сертификат, който представлява Домейн контролер, но Certighost преодолява тази граница, без да докосва нито един списък за контрол на достъпа (ACL).

Несъвършенството се намира в поведението за записване на AD CS, известно като функция „chase“ (преследване). Когато корпоративният сертифициращ орган не може веднага да разреши целевия обект локално, той може да последва предоставената от заявителя информация за маршрутизиране (параметър, наречен cdc), за да потърси обекта на друго място.

Дефектът се състои в това, че сертифициращият орган никога не проверява дали крайната точка, посочена в cdc, е легитимен Домейн контролер, преди да се свърже с нея. Атакуващият насочва cdc към машина под негов контрол и сертифициращият орган добросъвестно осъществява изходяща връзка към тази компрометирана крайна точка, която отговаря с фалшифицирани данни за идентичност, включително идентификатора за сигурност (SID) на целевия обект на Домейн контролера и неговото DNS хост име.

Сертифициращият орган се доверява на това, което му е казано, свързва тази идентичност с подписан X.509 сертификат и връчва на атакуващия сертификат, който твърди, че той е Домейн контролер.

Оттук нататък атаката следва добре познат път. Атакуващият използва сертификата с PKINIT (разширението за публичен ключ към Kerberos), за да получи билет за предоставяне на билети (Ticket Granting Ticket - TGT) като акаунт на машина за Домейн контролера. Акаунтите на Домейн контролерите по рождение притежават права за репликация на директорията, достатъчни за изпълнение на DCSync операция срещу реален Домейн контролер и извличане на идентификационни данни, включително хеша на акаунта krbtgt. След като разполагате с krbtgt, можете да фалшифицирате Kerberos билети по желание и домейнът на практика е ваш.

Стандартен акаунт на потребител в домейна (Domain User) беше достатъчен при тестването, тъй като настройките по подразбиране в Active Directory, включително стандартната квота MachineAccountQuota, която позволява на обикновените потребители да създават компютърни акаунти, предоставиха всичко необходимо за веригата от действия.

Към момента на публичното оповестяване няма потвърдена експлоатация в реална среда. Това обаче не е причина за успокоение. Наличието на работещ публичен доказателствен код драстично намалява усилията, необходими за възпроизвеждане на атаката, а времето между „съществуването на PoC“ и „внедряването му в масовите инструменти за хакерство“ се измерва в седмици, а не в години.

Уязвимостта е нова. Скритите привилегии не са.

Certighost разкри как привилегиите, заровени в доверени връзки и пренебрегвани настройки по подразбиране, могат да се превърнат в път за компрометиране на домейна. Безплатната оценка на риска на сигурността на идентичността от BeyondTrust ви помага да разкриете тези скрити излагания на идентичности и привилегии във вашата собствена среда, преди те да станат следващия път, който атакуващите ще експлоатират.

Това не е грешка в сертификатите. Това е провал в управлението на привилегиите и доверието.

Изкушаващо е Certighost да се категоризира като тънкост на PKI инфраструктурата, да се прехвърли на този, който управлява сертифициращия орган, и да се продължи напред, след като се инсталира съответната корекция за сигурност. Но ако премахнем механизма на сертификатите и погледнем формата на атаката, виждаме следното: потребител без привилегии манипулира доверена система, за да гарантира за привилегирована идентичност, а средата няма механизъм да подложи на съмнение резултата. Това е проблем с валидирането на доверието, който стои в ядрото на сигурността на идентичността.

Сертифициращият орган не е пасивно устройство. Той сам по себе си е привилегирована идентичност, която създава доверие от името на целия домейн. Корекцията, която Microsoft издаде, по своята същност е стъпка за проверка, налагаща изискването целта на търсенето при пренасочване (chase lookup) да бъде действително Домейн контролер.

Това е повтарящият се почерк на компрометирането, базирано на идентичност: атакуващият рядко разбива криптографията или удостоверяването. Той просто намира мястото, където системата е решила да се довери без проверка.

Има и втори, по-неудобен урок, скрит в предварителните изисквания. Конфигурацията по подразбиране на Active Directory предоставя на всеки удостоверен потребител малка част от постоянни привилегии: възможността да създава компютърни акаунти, благодарение на MachineAccountQuota, която го позволява по подразбиране.