60 saniyede AD CS ESC4
Active Directory Certificate Services (AD CS), kimlerin sertifika talep edebileceğini, bu sertifikanın hangi kimlikleri temsil edebileceğini ve ne amaçla kullanılabileceğini belirlemek için şablonlar (Certificate Templates) kullanır. ESC4 özel bir sertifika türü değildir: yetkisiz veya düşük ayrıcalıklı bir kullanıcının güvenli bir şablonu tehlikeli bir şablona dönüştürmesini sağlayan yazma yetkisidir (write access). ESC1 bu yazma yetkisinin üretebileceği tehlikeli sonucu tanımlar; ESC4 ise bu değişikliği mümkün kılan kök izin hatasıdır (root cause).
Ortam tertemiz görünüyordu.
Kerberoasting kapatılmıştı — servis hesapları rastgele uzun parolalara ya da gMSA’ya taşınmıştı. AS-REP roasting hiçbir sonuç vermiyordu. LAPS yalnızca kurulmamış, sahada gerçekten enforce edilmişti. İdari kademelendirme (tiering) mimari şemada ve şaşırtıcı bir şekilde grup üyeliklerinde eksiksiz uygulanmıştı. EDR her sunucuda aktifti, optimize edilmişti ve bir ekip alarmları canlı takip ediyordu.
Böyle ortamlarda kolay saldırı yollarının tükenmesi doğaldır; zaten bu kontroller tam olarak bunun için vardır.
Sonra Sertifika Otoritesine (Certificate Authority - CA) baktım.
Ortam temizdi, ama CA sahipsizdi
AD CS kurulumu daha önce hiçbir güvenlik değerlendirmesinden geçmemişti. İncelenip riski kabul edilmiş değil — varlığı tamamen unutulmuştu. Domain, yıllarca süren iyileştirme çalışmalarıyla sıkılaştırılmıştı; ancak bu domain içinde yaşayan CA bir kez kurulmuş, sertifika dağıttığı teyit edilmiş ve o günden sonra kendi haline bırakılmıştı.
Bu, sahada sürekli karşılaştığım ve tek bir şirkete özgü olmayan kronik bir örüntüdür:
Sertifika Otoritesi (CA) genellikle Active Directory’den farklı bir ekibe aittir. AD, kimlik (Identity) veya dizin ekibinin mülkiyetindedir. CA ise PKI ekibine, altyapı ekibine veya sekiz yıl önce ofisteki kablosuz ağ için sertifikaya ilk ihtiyaç duyan kişiye aittir. Her iki ekip de yetkindir. Her iki ekip de işini yapmaktadır. Ancak hiçbir ekip sertifika şablonlarının kendi sorumluluğu olduğuna inanmaz.
Bu organizasyonel boşluk idari bir aksaklık değildir. Zafiyetin ta kendisidir.
Güvenlik yatırımı sahiplikle birlikte büyür. Bir ekip bir sisteme sahip olduğunda; o sistem periyodik denetim, sıkılaştırma standartları, değişiklik yönetimi biriktirir. Sahiplik belirsiz olduğunda ise bunların hiçbiri birikmez — kimse bunu kasten ihmal ettiği için değil, bu iş tanımında kimsenin görevi olmadığı için.
Olgun bir Active Directory yapısında AD CS kurulumu, çoğu zaman ortamdaki en büyük denetlenmemiş yetki yoğunlaşmasıdır. Ormandaki (forest) herhangi bir kimlik adına anında geçerli bilet (credential) üretebilir. İşlevsel olarak Tier 0’dır. Ve genellikle bir yazıcı sunucusuymuş gibi yönetilir.
ESC1 nihai payload’dur, ESC4 asıl kök nedendir
Yayınlanan AD CS çalışmalarının çoğu aynı yerden başlar: Savunmasız bir sertifika şablonu verildiğinde, onu nasıl istismar edersiniz. ESC1’den ESC16’ya kadar uzanan taksonomi düz bir bulgu listesi gibi sunulur; keşif sırasında bulabileceğiniz bağımsız maddeler gibi.
Birçok AD CS değerlendirmesinin bir adım geride durmasının sebebi bu yanlış bakış açısıdır.
Bir şablonu ESC1 yapan dört koşulu hatırlayın:
- İstekte bulunan süjeyi (subject) belirler:
msPKI-Certificate-Name-FlagiçindeCT_FLAG_ENROLLEE_SUPPLIES_SUBJECTbayrağı açıktır; yani sertifika, talepte bulunanın iddia ettiği kimliği taşır. - Sertifika kimlik doğrulama için kullanılabilir: Şablonda istemci kimlik doğrulamasına (Client Authentication, PKINIT, Smart Card Logon veya Any Purpose) izin veren bir EKU (Extended Key Usage) tanımlıdır.
- Düşük yetkili bir kullanıcı kayıt olabilir (enroll): Enroll hakkı geniş bir kullanıcı grubuna verilmiştir.
- Yolda hiçbir engel yoktur: Yönetici onayı (
CT_FLAG_PEND_ALL_REQUESTS) kapalıdır ve yetkili imza (msPKI-RA-Signature) zorunluluğu yoktur.
Bu dört koşul bir araya geldiğinde yetkisiz bir kullanıcı, kendisini Domain Admin olarak gösteren bir sertifika talep edebilir ve ardından bu sertifikayla Kerberos üzerinden oturum açabilir.
Şimdi ESC4’ü düşünün: ESC4 bir şablon konfigürasyonu değildir. ESC4, şablonun Active Directory nesnesi üzerindeki yazma yetkisidir (write access) — WriteDacl, WriteOwner, WriteProperty, GenericWrite, GenericAll veya doğrudan sahiplik (Ownership).
Bu iki tanımı yan yana koyduğunuzda gerçek apaçık ortaya çıkar:
ESC4 ile, ESC1 koşullarını sağlayan bir şablon aramanıza gerek yoktur. O koşulları kendiniz tanımlarsınız.
ESC4 bulgu listesinde ESC1’in yanında durmaz. Onun tepesinde durur. Bir şablon nesnesi üzerindeki yazma yetkisi, tüm yükseltme taksonomisini tek bir ön koşula indirger; çünkü taksonominin saydığı her bayrak ve ayar, artık sizin yazabileceğiniz bir değere dönüşür. Keşif sorusu “burada tehlikeli bir şablon var mı?” olmaktan çıkar, “tehlikeli bir şablon üretebilir miyim?” haline gelir.
Bu durum kaynak tabanlı kısıtlı delegasyon (RBCD) ile aynı mekanizmadır: payload yanlış yapılandırılmış bir ayar değil, o ayarı oluşturmanıza izin veren nesne yazma yetkisidir.
Bu nedenle raporda yer alan “ESC4 — bir şablonda gereğinden fazla ACL izni var — Orta Seviye” şeklindeki bir tespit, AD CS denetimlerindeki en pahalı yanılgılardan biridir. Şablonun şu anki mevcut ayarlarının hiçbir önemi yoktur; çünkü konfigürasyonu tamamen saldırganın kontrolündedir.
Evidence matrix
| Sinyal | Neyi kanıtlar | Negatif kontrol | Savunmacı doğrulaması |
|---|---|---|---|
| Şablon nesnesinde düşük yetkili hesaba yazma hakkı (DACL) | ESC4: Şablonun istenen ESC1 konfigürasyonuna çevrilebileceğini | Yazma hakkını kaldırıp Set-ADObject veya Certipy ile değişikliği deneyin; erişim reddedilmelidir | CN=Certificate Templates,CN=Public Key Services altındaki DACL’leri denetleyin |
| Şablon üzerinden istenen Domain Admin adına sertifika alınması | ESC1 payload’unun CA tarafından başarıyla imzalandığını | Rastgele sahte bir UPN ile talep açın ve onay mekanizmasını test edin | CA denetim günlüklerinde Event ID 4886 ve 4887 kayıtlarını inceleyin |
| Sertifika ile PKINIT Kerberos TGT alınabilmesi | Sertifikanın KDC tarafından kimlik doğrulama için kabul edildiğini | KB5014754 güçlü eşleme (strong mapping / SID) kurallarını uygulayın | Domain Controller Kerberos Olay Günlüklerinde Event ID 19, 20, 21 kayıtlarını kontrol edin |
Savunmacılara teslim edilmesi gerekenler
Şablon izinlerini Tier 0 kabul edin. AD CS şablonları Active Directory’nin en kritik nesneleridir. Enterprise Admins ve Domain Admins dışındaki hiçbir gruba şablonlar üzerinde WriteDacl, WriteOwner veya GenericWrite izni verilmemelidir.
KB5014754 güçlü sertifika eşlemesini zorunlu kılın. Sertifikalarda szOID_NTDS_CA_SECURITY_EXT (SID) uzantısını şart koşan Full Enforcement moduna geçin. Bu, saldırgan süje adını manipüle etse bile sertifikanın yetkisiz hesaplarla eşleşmesini engeller.
CA sunucularını Tier 0 olarak yönetin. AD CS sunucularını standart uygulama sunucuları gibi değil, Domain Controller seviyesinde izole edin ve ayrıcalıklı erişim kurallarına tabi tutun.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Yazar teknik incelemeyi tamamladı. Bu etiket tek başına laboratuvar yeniden üretimi iddiası taşımaz.