Certighost (CVE-2026-54121): przejęcie domeny przez AD CS

24 lipca 2026 roku badacze H0j3n i Aniq Fakhrul opublikowali działający exploit dla podatności CVE-2026-54121, nazwanej Certighost. Skutek jest tak poważny, jak to tylko możliwe w środowisku Windows: zwykły użytkownik domeny — bez uprawnień administracyjnych, bez interakcji ofiary — może uzyskać certyfikat uwierzytelniający go jako kontroler domeny, a następnie wykonać DCSync i wyciągnąć hash konta krbtgt. To pełna kompromitacja domeny startująca z konta stażysty.

Microsoft załatał błąd 14 lipca 2026, dziesięć dni przed publikacją exploita. Jeśli Twoje kontrolery domeny i serwery CA dostały lipcowe poprawki — jesteś w dobrej sytuacji. Jeśli nie, właśnie skończył się czas. Poniżej trzymamy się faktów potwierdzonych przez Microsoft i autorów analizy; tam, gdzie coś jest zależne od konfiguracji, mówimy o tym wprost.

Kontekst: dlaczego AD CS jest tak wdzięcznym celem

Active Directory Certificate Services to wewnętrzne PKI. W praktyce oznacza to, że urząd certyfikacji (CA) jest maszyną, która na żądanie wystawia dowody tożsamości honorowane przez całą domenę. Jeśli potrafisz nakłonić CA do wystawienia certyfikatu na cudzą tożsamość, nie musisz łamać żadnego hasła — po prostu dostajesz legitymację i logujesz się jako ktoś inny (PKINIT → bilet TGT → Kerberos).

Od 2021 roku znamy całą rodzinę takich błędów oznaczanych jako ESC1–ESC16 (misconfiguracje szablonów, nadmiarowe uprawnienia, NTLM relay na endpointy zapisu). Opisaliśmy je szerzej w tekście o atakach na certyfikaty w AD CS. Certighost jest o tyle ciekawszy, że nie jest błędem konfiguracji administratora — to błąd w samym kodzie CA, w mechanizmie, o którego istnieniu większość zespołów nie wiedziała.

Anatomia: czym jest „chase” i gdzie się złamał

Sednem podatności jest mało znany mechanizm rozwiązywania obiektów katalogowych po stronie CA, nazywany w kodzie chase („pogoń”). Gdy CA przetwarza żądanie certyfikatu, musi ustalić, kim jest podmiot żądania — a więc odpytać katalog o jego atrybuty. Certighost wykorzystuje ścieżkę awaryjną tego procesu.

Mechanika w skrócie:

1. Atakujący steruje tym, kogo CA zapyta. Podając w żądaniu odpowiednie atrybuty (m.in. cdc), napastnik sprawia, że CA — zamiast odpytać zaufany kontroler domeny — sięga po dane tożsamości do hosta kontrolowanego przez atakującego.
2. Fałszywe usługi po stronie napastnika. Atakujący wystawia własne, podstawione usługi LSA i LDAP. To one odpowiadają na pytania CA o tożsamość.
3. Relay uwierzytelnienia przez Netlogon. Żeby ta podstawiona usługa wyglądała wiarygodnie, wyzwanie uwierzytelniające od CA jest przekazywane (relayowane) do prawdziwego kontrolera domeny kanałem Netlogon. Napastnik nie zna sekretu — po prostu przepuszcza rozmowę przez siebie.
4. Zwrócenie atrybutów ofiary. Podstawiony LDAP zwraca CA atrybuty docelowego kontrolera domeny: objectSid oraz dNSHostName.
5. CA podpisuje cudzą tożsamość. CA, nie zweryfikowawszy, że host, którego zapytał, faktycznie jest kontrolerem domeny, wpisuje otrzymane dane do certyfikatu i go podpisuje.

Warunkiem wejścia jest posiadanie konta komputera. I tu druga zła wiadomość: w domyślnej konfiguracji AD atrybut ms-DS-MachineAccountQuota wynosi 10, co oznacza, że każdy uwierzytelniony użytkownik może samodzielnie utworzyć do dziesięciu kont komputerów. Napastnik nie potrzebuje więc żadnego przywileju — wystarczy mu konto w Domain Users.

Od certyfikatu do krbtgt

Sam certyfikat to jeszcze nie koniec, ale droga dalej jest krótka i całkowicie „legalna” z punktu widzenia protokołów:

1. Napastnik używa certyfikatu do uwierzytelnienia PKINIT i otrzymuje bilet TGT jako konto kontrolera domeny.
2. Konta kontrolerów domeny posiadają uprawnienia replikacji katalogu (DS-Replication-Get-Changes i DS-Replication-Get-Changes-All).
3. Mając te uprawnienia, napastnik wykonuje DCSync — czyli mówi prawdziwemu kontrolerowi: „jestem kontrolerem, zreplikuj mi dane” — i pobiera hashe, w tym krbtgt.

Wyciek krbtgt to scenariusz najgorszy z możliwych: pozwala wystawiać Golden Tickets, czyli dowolne bilety Kerberos dla dowolnego użytkownika, ważne aż do dwukrotnej rotacji tego konta. Samo załatanie Certighosta nie usuwa takiego dostępu — to ta sama lekcja, co przy każdym poważnym włamaniu: kradzież sekretu uodparnia atakującego na łatkę.

Warto zauważyć, że Certighost łączy techniki, które osobno są dobrze znane: podstawianie usług katalogowych, relay uwierzytelnienia (jak w NTLM relay na SMB/LDAP) i nadużycie tożsamości maszynowej (jak w delegacji Kerberos i RBCD). Nowy jest wyłącznie punkt, w którym CA daje się oszukać.

Co zrobił Microsoft

Poprawka z 14 lipca 2026 dokłada do biblioteki certpdef.dll funkcję walidującą cel operacji chase — w publicznych analizach wskazywaną jako CRequestInstance::_ValidateChaseTargetIsDC. Innymi słowy: CA zaczyna sprawdzać, czy host, do którego zamierza „pogonić” po dane tożsamości, rzeczywiście jest kontrolerem domeny, zamiast ufać temu, co podsunął mu autor żądania.

Microsoft sklasyfikował błąd jako improper authorization z oceną CVSS 8.8. Wektor wymaga dostępu sieciowego i konta domenowego, ale nie wymaga uprawnień administratora ani interakcji użytkownika — dlatego w praktyce traktuj go jak krytyczny, niezależnie od tego, że nie ma „dziesiątki”. To klasyczny przypadek, w którym ocena CVSS nie oddaje realnego ryzyka: 8.8 opisuje pojedynczy krok, a nie skutek końcowy, którym jest przejęcie całego lasu AD.

Plan działania — kolejność ma znaczenie

1. Załataj serwery CA i kontrolery domeny. Poprawki z lipca 2026 (lub nowsze). To jedyna czynność, która faktycznie zamyka lukę. Priorytet: każdy serwer z rolą AD CS, następnie kontrolery domeny.

2. Sprawdź, czy nie jest już za późno. Przy publicznym exploicie zakładaj możliwość wcześniejszego użycia. Konkretne miejsca do przejrzenia:

• Log CA (CertUtil -view / dziennik „CertificateServicesClient”, zdarzenia wystawienia certyfikatu 4886/4887) — szukaj certyfikatów wystawionych z tożsamością kontrolera domeny, o które nikt nie prosił, zwłaszcza żądanych przez świeżo utworzone konta komputerów.
• Tworzenie kont komputerów — zdarzenie 4741 (A computer account was created) zainicjowane przez zwykłego użytkownika to sygnał wart uwagi w każdej domenie.
• Uwierzytelnienia PKINIT — zdarzenie 4768 (TGT) z użyciem certyfikatu dla konta kontrolera domeny z nietypowego adresu.
• DCSync z nieoczekiwanego źródła — zdarzenie 4662 z DS-Replication-Get-Changes-All wykonane przez podmiot, który nie jest kontrolerem domeny. To jedna z najważniejszych reguł detekcyjnych, jakie w ogóle warto mieć.

3. Jeśli widzisz ślady — potraktuj to jako pełną kompromitację domeny. Oznacza to podwójną rotację krbtgt (z odstępem pozwalającym na replikację i wygaśnięcie biletów), przegląd członkostw w grupach uprzywilejowanych i utrwalonych mechanizmów dostępu.

4. Utwardź to, co i tak powinno być utwardzone. Niezależnie od tej konkretnej luki:

• Ustaw ms-DS-MachineAccountQuota na 0 i deleguj tworzenie kont komputerów wskazanym zespołom. To jedno ustawienie wycina wektor wejścia dla całej rodziny ataków, nie tylko dla Certighosta.
• Ogranicz ekspozycję ról CA — interfejsy zapisu/enrollmentu nie powinny być osiągalne z całej sieci użytkowników.
• Włącz wymuszanie EPA/podpisywania tam, gdzie to możliwe, by utrudnić klasyczne scenariusze relay.
• Monitoruj AD CS jak system krytyczny — bo nim jest. Serwer CA ma w domenie realną władzę porównywalną z kontrolerem domeny, a bywa traktowany jak „ta stara maszyna od certyfikatów”.

Te punkty to fundament szerszego bezpieczeństwa Active Directory i element stałego procesu zarządzania podatnościami, a nie jednorazowa reakcja na jeden CVE.

Najczęstsze pytania (FAQ)

Nie mamy AD CS — czy jesteśmy bezpieczni? W zakresie Certighosta tak: podatna jest rola urzędu certyfikacji. Zweryfikuj to jednak faktami, a nie pamięcią — AD CS bywa wdrożone „przy okazji” (np. pod Wi-Fi 802.1X, VPN czy podpisywanie dokumentów) i działa latami bez właściciela. Sprawdź, czy w lesie nie ma zapomnianego serwera z tą rolą.

Mamy AD CS, ale nie używamy uwierzytelniania certyfikatem. To nas chroni? Nie w oczywisty sposób. Problem leży po stronie procesu wystawiania certyfikatu przez CA, a uzyskany certyfikat służy do uwierzytelnienia w Kerberos (PKINIT), które w domenie działa niezależnie od tego, czy „używacie certyfikatów” w codziennej pracy.

Czy ms-DS-MachineAccountQuota = 0 zastępuje łatkę? Nie. Podniesie poprzeczkę i wytnie najwygodniejszą ścieżkę (samodzielne utworzenie konta komputera), ale napastnik dysponujący już jakimkolwiek kontem maszynowym nadal ma warunki do ataku. Ustaw quotę i załataj.

Załataliśmy w lipcu. Temat zamknięty? Zamknięty jest wektor. Otwarte pozostaje pytanie, czy przed łatką nikt z niego nie skorzystał — dlatego przejrzyj logi CA, tworzenie kont komputerów i zdarzenia replikacji wstecz. Jeśli znajdziesz cokolwiek nietypowego, prowadź to jak incydent, nie jak ciekawostkę.

Jak sprawdzić naszą odporność na tę klasę ataków? Test wewnętrzny AD z perspektywy zwykłego użytkownika pokazuje realną ścieżkę od konta pracownika do administratora domeny — łącznie z konfiguracją AD CS, quotą kont maszynowych i możliwościami relay. Odezwij się, jeśli chcesz to zweryfikować u siebie.

Podsumowanie

Certighost (CVE-2026-54121) to podręcznikowy przykład podatności, w której pojedynczy brak walidacji zamienia zwykłe konto użytkownika w administratora całej domeny. Łańcuch jest krótki, w pełni zautomatyzowany i publicznie dostępny od 24 lipca 2026: konto komputera → oszukanie CA przez mechanizm chase → certyfikat kontrolera domeny → PKINIT → DCSync → krbtgt. Załatanie zajmuje jedno okno serwisowe; odbudowa domeny po Golden Ticketach — tygodnie. Jeśli chcesz wiedzieć, jak daleko w Twojej sieci zajdzie napastnik startujący z konta zwykłego pracownika, sprawdźmy to kontrolowanym testem.

---

Źródła i dalsza lektura: Microsoft MSRC — CVE-2026-54121, The Hacker News, analiza techniczna H0j3n, SpecterOps — Certified Pre-Owned.