AD CS Bölüm 1: Mimari, Şablon Semantiği ve ESC Taksonomisi

Kimlik Köprüsü: Sertifikalar Nasıl Kerberos Biletine Dönüşür?

Active Directory ortamlarında Active Directory Certificate Services (AD CS), yalnızca web sunucuları veya VPN uçları için ikincil bir PKI hizmeti değildir. RFC 4556 (Kerberos PKINIT) aracılığıyla doğrudan Kerberos Key Distribution Center (KDC) ile entegre çalışan yetkili bir kimlik sağlayıcıdır. Bu entegrasyon, AD CS’yi yalnızca bir sertifika dağıtım sistemi olmaktan çıkarıp kimlik doğrulama zincirinin merkezine yerleştirir.

AD CS istismarını kavramak için temel bir ilkeyi görmek gerekir: İstemci kimlik doğrulama yeteneği taşıyan bir X.509 sertifikası, kısıtlanmamış bir kimlik bilgisidir. Bir hesap kendi kimliğini belirten bir sertifika aldığında süreç şöyle işler:

1. İstemci, 16 numaralı ön doğrulama verisini (PA-PK-AS-REQ) içeren bir Kerberos AS-REQ paketi oluşturur.
2. İstemci, bu isteği sertifikadaki açık anahtara karşılık gelen özel anahtarıyla imzalar.
3. KDC, sertifikayı dizindeki NTAuthCertificates deposuna (CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=...) karşı doğrular.
4. KDC, sertifikanın Subject Alternative Name (SAN) alanından veya Nesne SID uzantısından asıl kimliği çıkarır ve içine Privilege Attribute Certificate (PAC) gömülü bir Kerberos Ticket Granting Ticket (TGT) üretir.

Bu kimlik doğrulama yolu parola doğrulamasını, NTLM hash kontrolünü ve hesap parolası döndürmeyi tamamen atlar. Yani sertifika, parolanın yerine geçen ve parola değişse bile geçerliliğini koruyabilen bir kimlik bilgisi gibi davranır. Sertifika kayıt parametrelerini kontrol eden taraf, sonuçta elde edilecek Kerberos biletini de doğrudan kontrol eder.

+------------------+         MS-WCCE / RPC          +----------------------+
|  Domain User     | ----------------------------> |  Enterprise CA       |
|  (Enrollee)      | <---------------------------- |  (Issues X.509 Cert) |
+------------------+     Issued Cert (SAN: Target)  +----------------------+
         |
         |  AS-REQ (Pre-Auth Type 16: PA-PK-AS-REQ)
         v
+------------------+                                +----------------------+
|  Kerberos KDC    | =============================> |  Target TGT + PAC    |
|  (Validates PKI) |   Returns TGT for SAN User     |  (Full Impersonation)|
+------------------+                                +----------------------+

Active Directory içindeki her sertifika şablonu yapılandırması dört temel teknik soruya yanıt verir. Bu sorular, bir şablonun kimlik üretme yetkisini nereden aldığını ve nerede yanlış yapılabileceğini anlamanın en kısa yoludur. Bir şablon bu sorulardan birini ya da birkaçını güvensiz yanıtladığında yetki yükseltme açığı doğar:

1. Kimler kayıt olabilir? LDAP üzerindeki şablon nesnesinin Discretionary Access Control List (DACL) yapısıyla belirlenir.
2. Subject Alternative Name (SAN) bilgisini kim belirler? mspki-certificate-name-flag (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) veya CA geneli kayıt defteri bayraklarıyla kontrol edilir.
3. Sertifika hangi amaçla kullanılabilir? pKIExtendedKeyUsage içinde tanımlanan Extended Key Usage (EKU) OID değerleriyle sınırlandırılır.
4. KDC, sertifikayı dizin hesabıyla nasıl eşleştirir? szOID_NTDS_CA_SECURITY_EXT varlığı ve KDC kayıt defterindeki StrongCertificateBindingEnforcement değeriyle yönetilir.

Bu dört soruyu akılda tutmak, ileride göreceğin ESC numaralarını ezberlemek yerine neden oluştuklarını anlamayı sağlar. Her ESC, bu sorulardan en az birinin yanlış yanıtlanmasıdır; dolayısıyla düzeltme de ilgili yanıtı doğru vermekten geçer.

Sertifika Otoritelerini ve Şablonları Keşfetmek

Game of Active Directory (GOAD) çok ormanlı laboratuvarında, orman sınırının iki yakasında iki farklı Kurumsal CA bulunur. Her iki ortama karşı certipy-ad find çalıştırmak, sıkılaştırılmış bir temel çizgi ile istismara açık bir yapılandırma arasındaki farkı netleştirir.

Temel Çizgi CA: SEVENKINGDOMS-CA (Orman Kökü)

$ certipy-ad find -u [email protected] -p powerkingftw135 -dc-ip 192.168.56.10 -vulnerable -stdout
Certificate Authorities
  0
    CA Name             : SEVENKINGDOMS-CA
    DNS Name            : kingslanding.sevenkingdoms.local
    User Specified SAN  : Disabled
    Enforce Encryption for Requests : Enabled
    Permissions
      Enroll            : SEVENKINGDOMS.LOCAL\Authenticated Users
    [!] Vulnerabilities
      ESC8              : Web Enrollment is enabled over HTTP.

Orman kökündeki CA şifrelemeyi zorunlu tutar, kullanıcı tanımlı SAN bayraklarını kapatır ve şablon değişikliklerini sınırlar. Tek işaretlenen zafiyet ESC8’dir: HTTP web kaydı üzerinden kimlik doğrulamasız NTLM relay. Bu, CA’nın tamamen güvenli olduğu anlamına gelmez; yalnızca certipy’nin bu yapılandırmada gördüğü tek açık yüzeyin bu olduğunu gösterir.

İstismara Açık CA: ESSOS-CA (Ormanlar Arası Hedef)

$ certipy-ad find -u [email protected] -p fr3edom -dc-ip 192.168.56.12 -vulnerable -stdout
Certificate Authorities
  0
    CA Name             : ESSOS-CA
    DNS Name            : braavos.essos.local
    User Specified SAN  : Enabled        # CA-wide ESC6
    [!] ESC8            : Web Enrollment is enabled over HTTP.
    [!] ESC11           : Encryption is not enforced for ICPR (RPC) requests.

Certificate Templates
  Template Name: ESC1     -> Enrollee supplies subject + Client Authentication EKU
  Template Name: ESC2     -> Any Purpose EKU / No EKU defined
  Template Name: ESC3-CRA -> Certificate Request Agent EKU
  Template Name: ESC4     -> Insecure DACL allows low-priv user GenericWrite
  Template Name: ESC9     -> No Security Extension (Missing Object SID)
  Template Name: WebServer -> Schema version 1 / Server Authentication

ESSOS-CA neredeyse tüm temel soruları güvensiz yanıtlar. Gerçek bir kurumsal sızma testinde şablonlar nadiren ESC1 gibi açık zafiyet adlarıyla adlandırılır. Ancak WebServer_Internal veya VPN_AutoEnroll adını taşıyan ve aynı bitmask bayraklarını içeren bir şablon birebir aynı saldırı yolunu sunar. Bu yüzden savunmada önemli olan şablonun adı değil, taşıdığı özniteliklerdir.

Mimari Kök Nedene Göre ESC Taksonomisi

SpecterOps’un Certified Pre-Owned taksonomisini numaralandırılmış bir zafiyet listesi gibi görmek yerine, ESC vektörlerini oluştukları teknik hata alanına göre gruplamak gerekir. Bu yaklaşım, bir şablonun neden savunmasız olduğunu ve düzeltmenin nerede yapılması gerektiğini gösterir:

Ayrıntılı Kök Neden Analizi

1. Subject Alternative Name Belirleme (ESC1 ve ESC6)

Subject Alternative Name (SAN) uzantısı, bir X.509 sertifikasının hangi kimliğe bağlı olduğunu tanımlar. Normal kayıt süreçlerinde CA, SAN’ı talep edenin Active Directory hesap özniteliklerinden (örneğin userPrincipalName veya sAMAccountName) otomatik üretir. Böylece sertifika ile dizin nesnesi arasında dolaylı bir bağ kurulur.

Şablonun mspki-certificate-name-flag özniteliğinde 0x00010000 (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) biti açık olduğunda CA, sertifika imzalama isteğinde (CSR) gönderilen keyfi SAN değerini kabul eder:

# CSR Attribute indicating arbitrary SAN supply:
szOID_SUBJECT_ALT_NAME2 (2.5.29.17) = UPN: [email protected]

Şablon aynı zamanda Client Authentication (1.3.6.1.5.5.7.3.2) veya Smart Card Logon (1.3.6.1.4.1.311.20.2.2) EKU’sunu içeriyorsa bu yapılandırma ESC1’dir. Düşük yetkili bir domain kullanıcısı, bir Domain Admin’in UPN’ini belirten sertifika ister, PKINIT ile kimlik doğrular ve ayrıcalıklı hesabın TGT’sini alır. Bu nedenle bir şablonun yalnızca adına değil, SAN bayrağına ve EKU’suna birlikte bakmak gerekir.

ESC6, bu zafiyeti tek şablondan CA servisinin kendisine taşır. CA kayıt defterinde EDITF_ATTRIBUTESUBJECTALTNAME2 (0x00040000) bayrağı açıldığında, istemci tarafından belirlenen SAN öznitelikleri o CA’nın yayımladığı her şablonda kabul edilir. CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT = False olarak ayarlanmış şablonlar bile istemci kimlik doğrulamayı destekliyorsa savunmasız hale gelir. Bu fark, tek bir kayıt defteri anahtarının tüm CA davranışını değiştirebildiğini gösterir.

2. Genişletilmiş Anahtar Kullanımı Semantiği (ESC2, ESC3 ve ESC17)

pKIExtendedKeyUsage özniteliği, üretilen sertifikanın istemci uygulamaları tarafından hangi amaçlarla kullanılabileceğini kısıtlar:

Client Authentication      : 1.3.6.1.5.5.7.3.2
Smart Card Logon           : 1.3.6.1.4.1.311.20.2.2
Any Purpose (All Purpose)  : 2.5.29.37.0
Certificate Request Agent  : 1.3.6.1.4.1.311.20.2.1
Server Authentication      : 1.3.6.1.5.5.7.3.1

• ESC2 (Any Purpose EKU): Şablon Any Purpose OID’ini (2.5.29.37.0) içeriyorsa veya EKU uzantısını tamamen atlıyorsa sertifika evrensel bir kimlik bilgisine dönüşür. Hem istemci kimlik doğrulamasında hem de ikincil sertifika isteklerini imzalamada kullanılabilir.
• ESC3 (Certificate Request Agent): Certificate Request Agent EKU’suyla yapılandırılmış şablonlar, kaydolanın bir kayıt vekili gibi davranmasına izin verir. Saldırgan bir Enrollment Agent sertifikası ister, ardından bunu ikincil bir şablona karşı hedef ayrıcalıklı kullanıcı adına kayıt isteğini birlikte imzalamak için kullanır ve standart kimlik doğrulama kontrollerini atlar.
• ESC17 (Sunucu Kimlik Doğrulama Geçişi): Savunmacılar şablonları sıklıkla Client Authentication için denetler; oysa Server Authentication (1.3.6.1.5.5.7.3.1) içeren ve kullanıcı tanımlı subject’e izin veren şablonlar, saldırganın bilgisayar hesapları adına sertifika istemesine yol açar. Elde edilen makine sertifikası Kerberos Constrained Delegation (S4U2Self / S4U2Proxy) saldırılarını mümkün kılar.

3. Kimlik Bağlama ve Güvenlik Uzantıları (ESC9 ve ESC10)

KDC’nin PKINIT isteğini işleyebilmesi için sertifikayı bir dizin hesabıyla eşleştirmesi gerekir. Eski ortamlarda KDC, sertifikanın SAN alanındaki UPN’i okur ve LDAP’taki userPrincipalName özniteliğiyle karşılaştırırdı. Bu yöntem, UPN değiştirilebildiği için taklit ve hesap çakışması saldırılarına açıktı.

UPN taklidini ve hesap çakışması saldırılarını (örneğin CVE-2022-26923) önlemek için Microsoft, Nesne SID güvenlik uzantısını devreye aldı:

szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2) = ASN.1 Encoded Object SID

Bu uzantı mevcut olduğunda KDC, sertifikadaki gömülü SID’nin kimlik doğrulayan hesabın objectSid değeriyle eşleştiğini doğrular.

• ESC9: Şablon mspki-enrollment-flag içinde 0x00080000 (CT_FLAG_NO_SECURITY_EXTENSION) bayrağını taşır ve verilen sertifikada SID uzantısı bulunmaz. KDC, SID doğrulaması yapamadığı için UPN eşlemesine geri döner. Bir hesabın userPrincipalName değeri üzerinde GenericWrite yetkisi olan saldırgan, kurbanın UPN’ini geçici bir değere çevirir, kendi hesabıyla kurbanın UPN’ini kullanarak sertifika alır, değişikliği geri alır ve kurban olarak kimlik doğrular.
• ESC10: Domain Controller kayıt defterindeki HKLM\System\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement değeriyle yönetilir. Değer 0 (Devre Dışı) veya 1 (Uyumluluk Modu) ise KDC, SID uzantısı taşımayan sertifikaları güçlü bağlama denetimi yapmadan kabul eder. Yalnızca StrongCertificateBindingEnforcement = 2 katı eşlemeyi zorunlu kılar ve ESC9 fallback’ini etkisizleştirir.

4. PKI Nesnesi Erişim Kontrolü (ESC4, ESC5 ve ESC7)

Active Directory içinde sertifika şablonları ve Sertifika Otoritesi tanımları, Configuration adlandırma bağlamı altında standart LDAP nesneleri olarak saklanır:

Templates : CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=essos,DC=local
CA Object : CN=ESSOS-CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=essos,DC=local

Bu nesneler için tüm standart DACL kuralları geçerlidir:

• ESC4: Düşük yetkili bir hesap, bir sertifika şablonu nesnesi üzerinde WriteProperty, WriteDacl veya GenericAll hakkına sahiptir. Saldırgan mspki-certificate-name-flag değerini değiştirerek CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bayrağını açar, şablonun Enroll ACE’sine Domain Users grubunu ekler ve ayrıcalıklı olmayan bir şablonu aktif bir ESC1 vektörüne çevirir.
• ESC7: Bir hesap, Sertifika Otoritesi nesnesi üzerinde ManageCA veya ManageCertificates yetkisine sahiptir. ManageCertificates, yönetici onayı gerektiren bekleyen sertifika isteklerini onaylamaya yarar. ManageCA ise RPC üzerinden CA yapılandırma parametrelerini değiştirmeye, örneğin EDITF_ATTRIBUTESUBJECTALTNAME2 bayrağını açmaya veya ast CA sertifikaları yayımlamaya olanak tanır.

Savunma Mühendisliği ve Tespit Telemetrisi

Active Directory Certificate Services ortamlarını denetlemek ve korumak, hem CA üzerindeki sertifika yaşam döngüsü olaylarını hem de Domain Controller’lardaki kimlik doğrulama trafiğini izlemeyi gerektirir. Tek bir kaynağa bakmak yeterli değildir; sertifika isteği, verilişi ve sonraki PKINIT kullanımı farklı günlüklerde görünür.

AD CS İzleme İçin Kritik Olay Kimlikleri

// KQL Query: Detect PKINIT TGT Requests by Non-Standard Accounts
SecurityEvent
| where EventID == 4768
| extend PreAuthType = tostring(parse_xml(EventData).Data[4].["#text"])
| where PreAuthType == "16"
| extend TargetAccount = tostring(parse_xml(EventData).Data[0].["#text"])
| project TimeGenerated, Computer, TargetAccount, IpAddress, PreAuthType

İyileştirme Protokolü

1. Kaydolanın Belirlediği Subject’i Ortadan Kaldırın: certipy-ad find -vulnerable ile tüm yayımlanmış şablonları denetleyin; bu tarama, kayıt izinlerini ve şablon bayraklarını birlikte gösterir. Yönetici olmayan principal’ların erişebildiği her şablondan CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (0x00010000) bayrağını kaldırın.
2. CA Geneli SAN Enjeksiyonunu Kapatın: Tüm Kurumsal CA’larda şu komutu çalıştırın:

   certutil -config "braavos.essos.local\ESSOS-CA" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
   net stop certsvc && net start certsvc

3. Güçlü Sertifika Bağlamayı Zorunlu Kılın: Tüm Domain Controller’larda şu ayarı yapın:

   reg add "HKLM\SYSTEM\CurrentControlSet\Services\Kdc" /v StrongCertificateBindingEnforcement /t REG_DWORD /d 2 /f

4. Şablon Erişim Kontrolünü Sıkılaştırın: Yönetici olmayan kullanıcıların CN=Certificate Templates altındaki nesneler üzerinde GenericWrite, WriteDacl veya WriteProperty haklarına sahip olmadığından emin olun. Bu haklar, sıradan bir şablonu sessizce ESC1 vektörüne çevirmeye yeter.
5. Düz Metin Web Kaydını Kapatın: IIS üzerindeki CertSrv sanal dizinini kaldırın veya Genişletilmiş Kimlik Doğrulama Koruması (EPA) ile HTTPS kullanımını zorunlu kılın.

Sıradaki Bölüm

Mimari temellerin ortaya konmasının ardından Bölüm 2: ESC1 İstismarı yazısında ESSOS-CA hedefine karşı ESC1 zincirinin canlı işletimi inceleniyor: RPC uç noktası hedefleme, PKINIT kimlik doğrulama alışverişi ve orman kökü kimlik bilgilerini döken DRSUAPI DCSync adımları ele alınıyor.

Kanıt ve sınırlar

Sertifika Otoritesi ve şablon numaralandırmaları, izole GOAD laboratuvarı içindeki SEVENKINGDOMS-CA (192.168.56.10) ve ESSOS-CA (192.168.56.23) üzerinde yürütülmüştür. Tüm şablon öznitelikleri, OID’ler ve DACL’ler GOAD’ın bilerek zafiyetli bırakılmış PKI yapılandırmasını yansıtır. Bu nedenle buradaki bulgular, gerçek bir kurumun PKI yapısının tamamı hakkında değil, incelenen yapılandırma hakkında kanıt sunar. Ölçümü tekrarlarken aynı certipy-ad find komutunu ve aynı kimlik bilgilerini kullanmak, sonuçların karşılaştırılabilir kalmasını sağlar.

Kaynaklar

• Orange Cyberdefense, GOAD: orange-cyberdefense.github.io/GOAD
• SpecterOps, Certified Pre-Owned: posts.specterops.io
• The Hacker Recipes, Active Directory Certificate Services: thehacker.recipes/ad/movement/adcs
• Microsoft, AD CS Architecture and Protocol Overview: learn.microsoft.com
• Microsoft, KB5014754: Certificate-based authentication changes: support.microsoft.com
• MITRE ATT&CK, Steal or Forge Authentication Certificates (T1649): attack.mitre.org/techniques/T1649