--- title: "AD CS Bölüm 4: Kataloğun Geri Kalanı ve Nasıl Kilitleneceği" description: "AD CS serisini kapatmak: ESC2'nin any-purpose EKU'su, ESC3'ün kayıt temsilcisi üzerinden yükseltmesi, ESC9'un kimlik eşleme zayıflıkları ve relay tabanlı ESC8/ESC11 — sonra tüm taksonomiyi geri bağlayan dört soruluk sıkılaştırma kontrol listesi." date: 2026-11-05 author: Sevban Dönmez (@jankesec) canonical: https://jankesec.com/tr/yazilar/ad-cs-rest-hardening/ --- ## Subject konusunun ötesindeki katalog [Bölüm 1](/tr/yazilar/ad-cs-esc-taxonomy/) AD CS'yi bir şablonun yanıtladığı dört soru olarak çerçeveliyordu: kim kaydolabilir, subject'i kim sağlar, sertifika ne için kullanılabilir ve bir kimliğe nasıl eşlenir. [Bölüm 2](/tr/yazilar/ad-cs-esc1-domain-admin/) ve [Bölüm 3](/tr/yazilar/ad-cs-esc4-esc6/) subject sağlama ailesini — yani tacın mücevherlerini — kapsadı. Bu bölüm kataloğun geri kalanını ele alıyor ve sonunda hepsini tek bir sıkılaştırma kontrol listesinde topluyor. Amaç, tek tek teknikleri ezberletmek değil; hangi hatanın hangi soruya karşılık geldiğini göstermek. ## ESC2: "her şey" anlamına gelen bir EKU `ESC1` *hangi* EKU'yu taşıdığı için tehlikelidir. `ESC2` ise hiçbir EKU taşımadığı ya da "Any Purpose" EKU'su taşıdığı için tehlikelidir. Böyle bir sertifika adeta açık çektir: Client Authentication için de, bir subordinate CA için de, talep edenin istediği her şey için de kullanılabilir. Onu bir `-upn` ile istediğinde, tıpkı bir ESC1 gibi Domain Admin sertifikasına dönüşür: ```bash $ certipy-ad req -u missandei@essos.local -p fr3edom -ca ESSOS-CA -template ESC2 \ -upn daenerys.targaryen@essos.local -target braavos.essos.local -dc-ip 192.168.56.12 [*] Successfully requested certificate [*] Got certificate with UPN 'daenerys.targaryen@essos.local' ``` Düzeltme ESC1 ile aynıdır: any-purpose EKU'yu ve kayıt haklarını sök. Ama *tanıma* aşaması farklıdır, çünkü burada açıkça "yanlış" görünen bir yapılandırma yoktur; yalnızca sınırsız bırakılmış, fazla esnek bir şablon vardır. Çoğu denetimde gözden kaçan da tam olarak bu tür "fazla izin verici" ayarlardır. Bir şablonun yalnızca bariz biçimde yanlış görünmesini beklemek, denetimde en sık yapılan hatadır; asıl risk, doğru görünen ama sınırı olmayan yapılandırmadır. ## ESC3: kayıt temsilcisi senin için tırmanır Bir kayıt temsilcisi (`Certificate Request Agent` EKU'su), *başka kullanıcılar adına* sertifika kaydı yapabilen özel yetkili bir hesaptır. `ESC3-CRA`, bu EKU'yu herhangi bir `Domain User`'a verir. Önce temsilci olarak kaydolursun, sonra o sertifikayı `daenerys.targaryen` adına sertifika istemek için kullanırsın: ```bash $ certipy-ad req -u missandei@essos.local -p fr3edom -ca ESSOS-CA -template ESC3-CRA \ -target braavos.essos.local -dc-ip 192.168.56.12 [*] Successfully requested certificate [*] Got certificate with UPN 'missandei@essos.local' [*] Saving certificate and private key to 'missandei.pfx' ``` Temsilci sertifikası basamak taşıdır; ondan `daenerys` adına yapılan bir istek onun sertifikasını üretir. ESC3, ESC1'in daha eski ve Kerberos gerektirmeyen kuzenidir. Hedef şablon doğrudan kaydolmayı engellediğinde ama bir temsilciye güvendiğinde önem kazanır; yani ESC1'in "kendi subject'ini seç" yolunu kapatmak tek başına yeterli değildir. ## ESC9 ve kimlik eşleme ailesi ESC1-8'in hepsi *hangi sertifikayı aldığını* değiştirir. `ESC9` farklıdır: sertifika gerçektir ama `NoSecurityExtension` taşır — yani SID yoktur — bu yüzden KDC onu UPN ile eşlemeye geri düşer. Bir kullanıcının `userPrincipalName` değerini de değiştirebiliyorsan (bir `GenericWrite` yeterlidir), UPN'leri çakıştırır ve o kullanıcı olarak kimlik doğrularsın. Bu, Bölüm 2'deki ESC1 sertifikamızın "no object SID" ile çalışmasını sağlayan zayıf bağlama zayıflığının aynısıdır: bu lab'ın KDC'si güçlü bağlamayı zorunlu kılmaz. Yani sertifikanın gerçek olması tek başına güvenlik sağlamaz; önemli olan, sertifikanın hangi kimliğe bağlandığının sağlam biçimde doğrulanmasıdır. Bu ailenin geri kalanı da aynı geri düşüş mekanizmasıyla ilgilidir. `ESC11`, ICPR (RPC) isteklerinde şifreleme gereksinimini kaldırır; `ESC8` ise web enrollment'ı HTTP üzerinden açar. İkisi de taşıma düzeyindedir ve ikisi de relay vektörüdür: CA'ya doğru bir NTLM kimlik doğrulaması zorlar, ardından CA'nın kurban adına sertifika üretmesini sağlarsın. `ESC15` ve `ESC17`, `WebServer` şablonundaki tarihsel kazalar sonucu ortaya çıkmış girdilerdir (schema-v1 EKU uyuşmazlığı ve server-auth subject sağlama). Bunların hiçbiri *yeni* bir fikir değildir; her biri kimlik eşlemesinin ya da taşımanın kötüye kullanılmasına izin veren farklı bir yoldur. Relay ailesini (`ESC8`/`ESC11`) bu Kali kutusundan demo edemedim, çünkü lab alt ağına bridged değil routed bağlı; zorlanan bir makinenin benim dinleyicime dönüş yolu yok. Yapılandırma gerçektir (`ESC8: Web Enrollment over HTTP`, `ESC11: encryption not enforced`) ve Bölüm 1'de numaralandırılmıştır. İstismar ise saldırganın aynı L2 segmentinde olmasını gerektirir. Bu ayrımı belirtmek önemli: yapılandırmanın varlığını kanıtlamak ile onu ağ üzerinden sömürmek aynı şey değildir. Bir denetimde hangi kanıtı topladığını net söylemek, abartılı bir iddiadan her zaman daha değerlidir.
ESC KATALOĞUNUN GERİ KALANI · KÖK NEDENE GÖRE Ne yapabilir? (EKU) ESC2 · any purpose ESC3 · request agent Kime eşlenir? (binding) ESC9 · SID uzantısı yok UPN çakışması → zayıf binding Nasıl taşınır? (taşıma) ESC8 · web enrollment HTTP ESC11 · ICPR şifrelemesiz ESC15 / ESC17 · WebServer şablonundaki tarihsel kazalar (schema-v1 EKU, server-auth subject)
Taksonominin geri kalanı, kırdıkları dört sorudan hangisine göre gruplanmış — EKU, kimlik eşleme ya da taşıma.
## Kilitlemek: dört soru, yanıtlanmış Bu serideki her ESC, [Bölüm 1](/tr/yazilar/ad-cs-esc-taxonomy/)'in dört sorusundan birinin yanlış yanıtlanmasıdır. Yani iyileştirme, aynı dört soruya doğru yanıtları vermekten ibarettir: | Soru | Düzeltme | Neyi kapatır | | --- | --- | --- | | Kim kaydolabilir? | `Enroll` hakkını yalnızca ihtiyacı olan hesaplara ver | ESC1/2/3/4/6 | | Subject'i kim sağlar? | `EnrolleeSuppliesSubject`'i sök + CA `User Specified SAN` bayrağını temizle | ESC1/4/6/17 | | Ne için kullanılabilir? | Yalnızca Client/Server Auth EKU; "any purpose" yok, request agent yok | ESC2/3/15 | | Kimliğe nasıl eşlenir? | SID uzantısını koru, `StrongCertificateBindingEnforcement = 2` | ESC9/10 | Buna taşıma satırını da ekle: HTTP web enrollment'ı (`ESC8`) kapat, ICPR şifrelemesini zorunlu kıl (`ESC11`) ve — hepsinden önce — Enterprise CA sunucusunu nerede durursa dursun **Tier 0** olarak ele al. Bir CA, sertifika üretebildiği her orman için fiilen kimlik kaynağıdır; bu yüzden onu sıradan bir uygulama sunucusu gibi değerlendirmek, tüm sertifika zincirini riske atmak demektir. ## Seriyi kapatırken Dört yazı, tek sonuç: **bir sertifika bir kimlik bilgisidir ve bir şablon bayrağı bir saldırı yüzeyi kararıdır.** Taksonomiden çok, kurduğu içgüdü önemlidir: `EnrolleeSuppliesSubject: True`, `Any Purpose` ya da `User Specified SAN: Enabled` gördüğün anda, *hangi sorunun yanlış yanıtlandığını* bildiğin için bir Domain Admin sertifikasının tek bir istek uzağında olduğunu da bilirsin. Bu, araçlar değişse bile işe yarayan kalıcı bir bakış açısıdır. Yeni bir ESC numarası duyduğunda paniğe kapılmak yerine tek bir soru sor: bu teknik dört sorudan hangisini atlıyor? Cevap genellikle iyileştirmeyi de beraberinde getirir. ## Kanıt ve sınırlar Kalan ESC şablonları (`ESC2`, `ESC3`, `ESC8`, `ESC9`, `ESC11`) izole GOAD laboratuvarındaki `ESSOS-CA` ve `SEVENKINGDOMS-CA` üzerinde numaralandırılmıştır. Ağ relay primitifleri (`ESC8`/`ESC11`) ise saldırı makinesi lab segmentine bridged değil routed bağlı olduğu için dört soruluk sıkılaştırma matrisiyle birlikte mimari düzeyde analiz edilmiştir. Yani bu tekniklerin yapılandırma kanıtı gerçek, ağ üzerinden sömürü kanıtı ise bu ortamın sınırları nedeniyle yoktur. ## Referanslar - **Orange Cyberdefense, GOAD:** [orange-cyberdefense.github.io/GOAD](https://orange-cyberdefense.github.io/GOAD/) - **The Hacker Recipes, AD CS:** [thehacker.recipes/ad/movement/adcs](https://www.thehacker.recipes/ad/movement/adcs) - **SpecterOps, Certified Pre-Owned:** [posts.specterops.io](https://posts.specterops.io/certified-pre-owned-d95910965cd2) - **Microsoft, AD CS Overview:** [learn.microsoft.com](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/active-directory-certificate-services-overview) - **MITRE ATT&CK, Steal or Forge Authentication Certificates (T1649):** [attack.mitre.org/techniques/T1649](https://attack.mitre.org/techniques/T1649/)