AD CS i ataki ESC: audyt bezpieczeństwa certyfikatów

Audyt Active Directory Certificate Services (AD CS) ma ustalić, czy zwykły użytkownik, operator usługi albo przejęty host może uzyskać certyfikat pozwalający uwierzytelnić się jako bardziej uprzywilejowana tożsamość. Najgroźniejsze ścieżki nie wynikają z „złamania kryptografii”, lecz z połączenia praw zapisu, ustawień szablonu, rozszerzeń certyfikatu, mapowania konta i zaufania kontrolera domeny.

Kluczowa odpowiedź brzmi: certyfikat zdolny do logowania jest poświadczeniem. Może pozostać ważny niezależnie od rotacji hasła i nie zawsze jest widoczny w typowym przeglądzie grup administracyjnych. Dlatego AD CS należy traktować jako część płaszczyzny tożsamości Active Directory, a urząd certyfikacji, klucz prywatny CA, szablony oraz endpointy enrollment jako zasoby poziomu krytycznego.

W tym przewodniku wyjaśniamy model techniczny klas ESC, bezpieczną metodykę pentestu i hardening. Nie publikujemy komend służących do pozyskania cudzego certyfikatu ani gotowych łańcuchów przejęcia domeny. Testy aktywne powinny używać dedykowanych kont, zatwierdzonego szablonu laboratoryjnego i nieuprzywilejowanej tożsamości docelowej.

Dlaczego certyfikat może zastąpić hasło?

W logowaniu certyfikatowym klient posiada klucz prywatny i przedstawia certyfikat wystawiony przez zaufany urząd. Dla Kerberos mechanizm PKINIT pozwala użyć kryptografii klucza publicznego podczas uzyskiwania biletu TGT. Kontroler domeny musi następnie ustalić, z którym obiektem AD powiązać certyfikat. To mapowanie — a nie sama nazwa na certyfikacie — decyduje o tożsamości.

Certyfikat zawiera Subject, Subject Alternative Name (SAN), Extended Key Usage (EKU), okres ważności, issuer, serial i inne rozszerzenia. EKU takie jak Client Authentication, Smart Card Logon lub odpowiednie przeznaczenie PKINIT mogą umożliwiać uwierzytelnienie, zależnie od ścieżki i konfiguracji. Pole SAN może zawierać UPN albo inne identyfikatory. Jeżeli requester może wpisać cudzy identyfikator, a CA wydaje certyfikat bez dodatkowej weryfikacji, powstaje ryzyko impersonacji.

Microsoft w KB5014754 wprowadził i następnie wymusił silniejsze wiązanie certyfikatu z kontem. Aktualne kontrolery domeny nie powinny akceptować słabych mapowań tak, jak robiły to dawne konfiguracje. Nie wolno jednak uznać, że aktualizacja usuwa każdą klasę ESC. Błędy uprawnień do szablonu, CA, enrollment agentów, klucza urzędu lub endpointów nadal tworzą istotne ryzyko.

Model zaufania AD CS

Ocena zaczyna się od grafu, nie od listy serwerów. Węzły obejmują:

enterprise CA i standalone CA, ich hierarchię oraz NTAuth store;
konta komputerów urzędów, usługi i klucze prywatne;
obiekty szablonów w partycji Configuration AD;
grupy z prawami Enroll, Autoenroll, Write, WriteDACL i WriteOwner;
role Manage CA i Manage Certificates;
punkty Web Enrollment, CES/CEP, NDES i interfejsy RPC;
obiekty użytkowników i komputerów z mapowaniem certyfikatów;
polityki issuance, application policy i wymagania zatwierdzenia.

Krytyczna ścieżka powstaje wtedy, gdy podmiot kontroluje wystarczający zestaw krawędzi: może zmienić szablon, opublikować go, zapisać się, wpłynąć na tożsamość w certyfikacie, zatwierdzić wniosek albo skierować cudze uwierzytelnienie do endpointu, który nie chroni kanału. Samo Enroll nie zawsze jest błędem. Ryzyko zależy od kombinacji ustawień.

ESC1: requester definiuje tożsamość w certyfikacie

Klasyczna konfiguracja ESC1 łączy szerokie prawo enrollment, możliwość podania Subject/SAN w żądaniu, EKU umożliwiające uwierzytelnienie oraz brak manager approval lub wymaganych podpisów autoryzowanych. Nieuprzywilejowany użytkownik może wtedy poprosić o certyfikat reprezentujący inną tożsamość.

Podczas audytu nie wystarczy znaleźć flagę „Supply in the request”. Trzeba potwierdzić, czy szablon jest opublikowany, kto może go użyć, jakie EKU i application policies zawiera, czy CA honoruje SAN, czy wymagane są podpisy, jak działa mapowanie na aktualnych kontrolerach i czy wynik jest akceptowany w danej ścieżce logowania. Microsoft Defender for Identity opisuje te warunki w swojej ocenie „Prevent users to request a certificate valid for arbitrary users”.

Remediacja zwykle polega na wyłączeniu publikacji do czasu analizy, odebraniu enrollment grupom szerokim, budowaniu Subject z AD, zawężeniu EKU, włączeniu approval/signatures tam, gdzie proces tego wymaga, i ponownym wydaniu certyfikatów. Nie należy usuwać szablonu bez inwentaryzacji zależnych usług.

ESC2 i ESC3: Any Purpose oraz enrollment agent

Szablon z EKU Any Purpose albo bez ograniczającego EKU może nadawać certyfikatowi szersze zastosowanie niż zamierzone. Rzeczywisty wpływ zależy od tego, które usługi i ścieżki walidacji zaakceptują certyfikat. Audyt powinien więc badać konsumentów certyfikatów, a nie oceniać wyłącznie etykietę szablonu.

Enrollment Agent umożliwia uprawnionemu podmiotowi podpisywanie wniosków w imieniu innych. To legalna funkcja biznesowa, ale źle ograniczona tworzy łańcuch: jeden szablon wydaje certyfikat agenta, a drugi akceptuje podpis agenta i pozwala otrzymać certyfikat użytkownika. Kontrole obejmują ograniczenia enrollment agentów na CA, dozwolone szablony i grupy docelowe, approval, rozdział obowiązków oraz monitoring użycia.

Bezpieczny test potwierdza konfigurację i — tylko po akceptacji — wykonuje issuance dla kontrolowanego konta testowego. Nie wybieramy administratora domeny jako celu „dla lepszego dowodu”, ponieważ samo uzyskanie certyfikatu uprzywilejowanej tożsamości tworzy trwałe, wrażliwe poświadczenie.

ESC4 i ESC5: kontrola nad obiektami konfiguracji PKI

Szablon certyfikatu jest obiektem Active Directory z właścicielem i ACL. Jeżeli nieuprzywilejowana grupa może zmienić właściwości, DACL lub właściciela, może potencjalnie stworzyć warunki odpowiadające innej klasie ESC. To właśnie sens ESC4: pozornie bezpieczny szablon staje się niebezpieczny przez kontrolę nad jego konfiguracją.

ESC5 obejmuje szersze obiekty PKI i zależności, których przejęcie zmienia zaufanie: obiekty CA, kontenery publikacji, usługi, hosty lub elementy zarządzające. Oceniamy ACL w partycji Configuration, właścicieli, delegacje, członkostwa grup administracyjnych i możliwość modyfikacji GPO wpływających na serwery CA. Warto połączyć to z pełnym przeglądem bezpieczeństwa Active Directory, bo kontrola hosta CA może wynikać z pozornie odległej ścieżki domenowej.

Poprawka powinna przywrócić znany, minimalny zestaw właścicieli i praw oraz zbudować alerty na zmianę obiektów. Jednorazowy eksport ACL nie wystarcza; drift konfiguracji musi być monitorowany.

ESC6 i ESC7: ustawienia urzędu oraz role CA

Flaga CA pozwalająca przyjmować atrybut SAN ze zgłoszenia może rozszerzyć ryzyko poza szablony jawnie skonfigurowane do budowania Subject przez requester. Po zmianach mapowania certyfikatów wpływ konkretnego wariantu należy oceniać na aktualnych, załatanych kontrolerach, ale sama globalna flaga pozostaje niebezpiecznym rozszerzeniem powierzchni.

Role Manage CA i Manage Certificates są bardzo silne. Zależnie od konfiguracji pozwalają zmienić ustawienia urzędu, opublikować szablon, zatwierdzać oczekujące wnioski albo ominąć kontrolę manager approval. Microsoft zaleca usunięcie tych praw z szerokich, nieuprzywilejowanych grup. Rozdział ról ma sens tylko wtedy, gdy żadna osoba lub przejmowalne konto usługi nie może łatwo zebrać całego łańcucha.

Administracja urzędem powinna korzystać z dedykowanych stacji i czasowej aktywacji zgodnie z PAM dla dostępu uprzywilejowanego. Konto operatora PKI nie powinno służyć do poczty, internetu ani codziennej pracy.

ESC8 i ESC11: relay do endpointów enrollment

ESC8 dotyczy przekaźnikowania NTLM do endpointów HTTP enrollment, takich jak Web Enrollment lub CES, gdy endpoint dopuszcza NTLM bez skutecznego związania uwierzytelnienia z kanałem. HTTPS szyfruje ruch, ale sam nie zatrzymuje relay. Extended Protection for Authentication (EPA) wykorzystuje Channel Binding Token lub service binding, by powiązać uwierzytelnienie z właściwą sesją/usługą.

Microsoft Defender for Identity wskazuje endpointy IIS bez wymuszonego HTTPS albo EPA jako ryzyko ESC8. Najlepsza decyzja to usunąć nieużywane role Web Enrollment. Jeżeli muszą pozostać, wymagamy TLS, EPA, właściwych SPN, ograniczenia NTLM, segmentacji oraz minimalnych praw szablonów osiągalnych przez dany endpoint.

Nowsza nomenklatura badawcza obejmuje również relay do interfejsów RPC enrollment (ESC11) przy niewystarczającej ochronie integralności. Mechanizm i warunki różnią się od HTTP; dlatego raport powinien nazywać protokół, endpoint, wymagane flagi i wersję systemu, zamiast jedynie stwierdzać „AD CS podatne”. Szerszy model relay omawiamy w analizie NTLM relay, SMB signing, LDAP i EPA.

ESC9, ESC10 i ESC14: błędy mapowania certyfikatu

Te klasy koncentrują się na sposobie wiązania certyfikatu z kontem. Brak odpowiedniego security extension w szablonie, słabe metody mapowania albo modyfikowalne jawne mapowanie altSecurityIdentities mogą pozwolić, by certyfikat został przypisany do niezamierzonej tożsamości. Aktualny stan KB5014754 ma tu zasadnicze znaczenie.

Po aktualizacjach z 2025 roku kontrolery domeny przeszły do pełnego egzekwowania silnego mapowania, a później usunięto możliwość powrotu do dawnego trybu kompatybilności zgodnie z harmonogramem Microsoft. Audyt musi sprawdzić poziom poprawek wszystkich DC, rzeczywiste zdarzenia KDC, źródło wydawanych certyfikatów i jawne mapowania. Nie należy automatycznie „naprawiać” problemu przez dodawanie mapowania nazwowego, które ponownie osłabia wiązanie.

Szczególną uwagę poświęcamy prawom zapisu do UPN, DNS host name, SPN i altSecurityIdentities. Kontrola atrybutu może stworzyć ścieżkę nawet wtedy, gdy szablon wygląda poprawnie. Po zmianie mapowania trzeba rewidować istniejące certyfikaty i proces odnowienia, nie tylko nowe wnioski.

ESC13 i ESC15: issuance policy oraz application policies

Issuance policy może zostać powiązana z grupą w AD, a certyfikat spełniający politykę wpływać na autoryzację. Błędne linkowanie OID, szerokie enrollment albo możliwość modyfikacji powiązanych obiektów mogą nadać uprawnienia w sposób mało widoczny dla zespołu IAM. Audyt obejmuje OID, grupy, ACL i aplikacje interpretujące politykę.

ESC15 opisuje nowszą klasę dotyczącą możliwości dostarczenia arbitralnych application policies w określonych warunkach szablonu i niezałatanych AD CS, związaną z CVE-2024-49019. Microsoft dodał odpowiednią ocenę Defender for Identity. Tutaj remediacja wymaga zarówno aktualizacji, jak i przeglądu szablonów; samo ograniczenie UI konsoli nie zmienia zachowania protokołu.

Nazwy ESC są użytecznym językiem branżowym, ale nie są standardem produktu Microsoft i rozwijają się wraz z badaniami. Dobry raport zawsze opisuje pierwotny warunek techniczny, wersję i dowód, aby zalecenie nie zależało od numeru kategorii.

Bezpieczna metodyka pentestu AD CS

1. Inwentaryzacja pasywna

Zbieramy CA, hierarchię, publikowane szablony, konfigurację issuance, ACL, grupy enrollment, endpointy i poziom poprawek. Weryfikujemy NTAuth, CDP/AIA, okresy ważności i algorytmy. Odczyt katalogu wykonujemy kontem standardowym, aby zobaczyć to, co widzi zwykły użytkownik domeny.

2. Analiza grafu uprawnień

Dla każdego szablonu łączymy prawa enrollment, kontrolę obiektu, możliwość modyfikacji atrybutów podmiotu, ustawienia CA, EKU, approval i mapping. Oddzielamy ścieżki bezpośrednie od wymagających przejęcia hosta lub relay. Graf jest hipotezą; warunki potwierdzamy indywidualnie.

3. Kontrolowana walidacja

Aktywne issuance wykonujemy tylko po zatwierdzeniu, dla syntetycznej tożsamości bez dostępu biznesowego. Nie eksportujemy klucza CA, nie żądamy certyfikatu administratora i nie pozostawiamy aktywnego certyfikatu po teście. Rejestrujemy request ID, serial, template, issuer, czas i sposób unieważnienia.

4. Sprzątanie i retest

Unieważniamy wydane certyfikaty, publikujemy CRL zgodnie z procedurą, usuwamy artefakty z bezpiecznych magazynów i potwierdzamy brak trwałych zmian. Po remediacji powtarzamy odczyt konfiguracji i negatywny scenariusz, a nie tylko oglądamy zrzut konsoli.

Detekcja i monitoring AD CS

Advanced Audit Policy „Audit Certification Services” generuje zdarzenia związane z wnioskami, wydaniem, zmianami ustawień i bazą CA. Szczególnie użyteczne są zdarzenia 4886 (otrzymanie wniosku), 4887 (zatwierdzenie i wydanie), 4888 (odmowa) oraz zmiany konfiguracji urzędu i szablonów. Konkretny zestaw zależy od systemu i włączonych kategorii, dlatego najpierw walidujemy telemetrię kontrolowanym wnioskiem.

Korelacja powinna łączyć requester, template, SAN/Subject, issuer, request ID, konto docelowe i późniejsze logowanie certyfikatem. Alarmy wysokiej wartości obejmują:

wydanie certyfikatu logowania dla konta uprzywilejowanego przez nietypowego requestera;
użycie rzadkiego lub nowo opublikowanego szablonu;
zmianę ACL, ownera, EKU, application policy albo flagi Subject;
włączenie globalnego przyjmowania SAN lub zmianę ról CA;
serię wniosków po wymuszonym uwierzytelnieniu do endpointu enrollment;
logowania certyfikatem po zmianie hasła albo poza typowym urządzeniem.

Logi i backupy konfiguracji powinny trafiać poza administracyjną granicę domeny. Jeżeli napastnik kontroluje CA lub Domain Admin, lokalny ślad może zostać zmodyfikowany. Monitoring AD CS uzupełnia, a nie zastępuje ochrony opisanej w bezpieczeństwie Microsoft 365 dla warstwy chmurowej tożsamości.

Hardening AD CS krok po kroku

Usuń nieużywane endpointy i szablony z publikacji. Najpierw potwierdź właściciela oraz zależności.
Ogranicz Enroll i Autoenroll. Unikaj szerokich grup, jeśli certyfikat ma zastosowanie do uwierzytelniania.
Buduj Subject z AD. Supply in request pozostaw tylko dla udokumentowanych przypadków i z dodatkowymi kontrolami.
Zawęź EKU i application policies. Certyfikat powinien mieć tylko niezbędne przeznaczenie.
Wymuś silne mapowanie. Utrzymuj poprawki DC i CA, analizuj zdarzenia KB5014754 i reissue problematyczne certyfikaty.
Włącz TLS oraz EPA na IIS enrollment. Następnie ogranicz lub usuń NTLM tam, gdzie to możliwe.
Chroń role i host CA. Dedykowana administracja, JIT, MFA, segmentacja, EDR, backup HSM/klucza i kontrola eksportu.
Audytuj konfigurację jako kod/stabilny baseline. Alertuj na drift szablonów, ACL, OID, CA i NTAuth.
Skróć okresy ważności adekwatnie do ryzyka. Zaplanuj automatyczne odnowienie i skuteczne unieważnienie.
Ćwicz kompromitację CA. Procedura musi obejmować odwołanie zaufania, nową hierarchię, reissue i zależności usług.

Podejście Zero Trust oznacza tu ciągłą weryfikację issuance i użycia certyfikatu, a nie uznanie każdego artefaktu z zaufanego CA za bezwarunkowo bezpieczny.

Checklista audytu AD CS

Wniosek

Bezpieczne AD CS nie polega na uruchomieniu skanera z listą ESC. Trzeba zrozumieć pełne powiązanie: kto może zmienić konfigurację, kto może się zapisać, jaką tożsamość umieszcza certyfikat, jak KDC ją mapuje i gdzie certyfikat zostanie zaakceptowany. Dopiero ten model pozwala odróżnić niegroźną flagę od ścieżki prowadzącej do przejęcia domeny.

Jeżeli potrzebujesz niezależnego przeglądu szablonów, CA i łańcuchów certyfikatowych w kontrolowanym zakresie, skontaktuj się z Breachroad. Raport będzie zawierał warunki techniczne, priorytety remediacji, bezpieczne dowody i scenariusze detekcyjne — bez pozostawiania nowych poświadczeń uprzywilejowanych.