AD Certificate Services снова течёт: ESC-атаки и Certipy 5 — закрываете или живёте с этим?

[Bill2001]

Закономерность, от которой уже подёргивается глаз: почти на каждом внутреннем пентесте ADCS отдаёт домен. ESC1, ESC8 — как будто 2021 год так и не закончился. Certipy довели до состояния нажми кнопку: пара команд, и у тебя сертификат на администратора домена.

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

[go9]

@Bill2001, ESC8 самый надёжный в бою. Координируешь принуждение аутентификации (PetitPotam или Coercer) на CA, ловишь NTLM и релеишь на эндпоинт certsrv веб-энроллмента:

certipy relay -target ca01 -template DomainController

Дальше принуждаешь контроллер домена, получаешь его сертификат, и через него DCSync. ESC1 ещё проще, если найдётся шаблон с EnrolleeSuppliesSubject и правом enroll у обычных юзеров:

certipy req -ca 'CORP-CA' -template 'VulnTemplate' -upn administrator -dc-ip 10.0.0.10

На поиск всего этого хватает certipy find -vulnerable. В 5.x вывод стал заметно чище, сразу маркирует ESC1-ESC16.

[Austkin]

@Bill2001, Расскажу, как мы это вычищали полгода, потому что просто закройте не работает, когда на автоэнролле висят принтеры, VPN и половина легаси.

Первое — инвентаризация. Прогнали PSPKIAudit и руками через certutil, выписали ВСЕ шаблоны с msPKI-Certificate-Name-Flag, где взведён ENROLLEE_SUPPLIES_SUBJECT. Таких нашлось шесть, два из них с правом enroll у Domain Users. Это и был наш ESC1.

Второе — на самом CA сняли флаг EDITF_ATTRIBUTESUBJECTALTNAME2 (закрывает ESC6), перезапустили certsvc. Проверяется через certutil -getreg policy\EditFlags.

Третье, по ESC8 — выпилили HTTP-энроллмент полностью, оставили только то, что реально нужно, поверх HTTPS с EPA (Extended Protection for Authentication) и channel binding. Принуждение через релей после этого отваливается.

Четвёртое — мониторинг: события 4886/4887 на CA (запрос и выдача сертификата), алерт на выдачу с SAN, не совпадающим с реквестором. Поймали так один странный запрос уже через неделю.

И да, поверх всего накатили усиление маппинга (StrongCertificateBindingEnforcement в Full). Вот это далось больнее всего: пара старых сервисов с самоподписанными отвалилась, разгребали отдельно. Но без этого ESC-цепочки на слабом маппинге живут даже после чистки шаблонов.

[lorenzinoarq]

Про усиление маппинга соглашусь — Microsoft с февраля 2025 двигает StrongCertificateBindingEnforcement в полный режим, но по факту половина контор сидит в Compatibility, потому что Full ломает совместимость со старьём. А пока ты в compatible — слабый маппинг по UPN никуда не делся, и часть атак живёт. Это не баг, который закрыли патчем, это архитектурная мина, которую надо разминировать руками.

[grahamd]

@Bill2001, Самое дешёвое правило на входе: веб-энроллмент CA не должен быть доступен ни из пользовательского сегмента, ни тем более снаружи. Если он реально нужен — только HTTPS плюс EPA. Весь остальной ESC-зоопарк закрывается уже спокойнее, когда отрезан главный релей-вектор.