Active Directory Certificate Services, yani çoğumuzun bildiği adıyla AD CS, uzun yıllar boyunca kurumlarda daha çok “sertifika dağıtan altyapı servisi” olarak görüldü. VPN, Wi-Fi, smart card logon, web server sertifikaları, internal TLS ihtiyaçları derken AD CS pek çok kurumda sessiz sedasız çalışan ama çok kritik bir rol üstlenen servislerden biri oldu.
Fakat 2021 yılından sonra bu bakış açısı ciddi şekilde değişti.
Bunun en önemli kırılma noktalarından biri, SpecterOps tarafından yayınlanan Certified Pre-Owned çalışmasıydı. Bu whitepaper, AD CS’in sadece bir PKI bileşeni olmadığını, yanlış yapılandırıldığında doğrudan privilege escalation, credential theft, NTLM relay ve hatta domain compromise zincirlerinin merkezine oturabileceğini çok net şekilde gösterdi.
Ben de bu yazıda, 2021’den 2026’ya kadar AD CS tarafında yayınlanan saldırı araştırmalarını ve Microsoft’un buna karşı çıkardığı yama / iyileştirme adımlarını özetlemek istiyorum.
2021: AD CS İçin Paradigma Değişimi
2021 yılı AD CS güvenliği açısından bir dönüm noktasıydı.
SpecterOps’un yayınladığı Certified Pre-Owned çalışması ile birlikte AD CS ortamlarındaki zayıf yapılandırmalar sistematik olarak sınıflandırıldı. Bugün hala konuştuğumuz ESC1, ESC2, ESC3… ESC8 gibi tekniklerin temeli bu çalışma ile atıldı.
Buradaki asıl mesaj şuydu:
AD CS doğru yapılandırılmadıysa, sertifika almak sadece sertifika almak değildir; bazen domain admin olmaya giden yolun başlangıcıdır.
Özellikle sertifika template izinleri, subject alternative name kontrolleri, enrollment hakları ve client authentication EKU gibi konuların ne kadar kritik olduğu bu dönemden sonra daha iyi anlaşıldı.
Aynı yıl bir diğer önemli konu da PetitPotam oldu. PetitPotam, NTLM relay saldırıları açısından AD CS’i yeniden gündeme taşıdı. Saldırganın belirli Windows servislerini zorlayarak NTLM authentication tetiklemesi ve bunu AD CS web enrollment gibi servislere relay etmesi, ciddi bir risk oluşturuyordu.
Microsoft bu dönemde KB5005413 / ADV210003 ile PetitPotam mitigasyon rehberi yayınladı. Ardından CVE-2021-36942 için ilk binary fix geldi.
Ancak burada önemli bir nokta var: Microsoft’un yayınladığı rehberler ve yamalar önemliydi ama tek başına yeterli değildi. Çünkü AD CS risklerinin büyük kısmı sadece ürün açığından değil, aynı zamanda kurumların kendi yapılandırmalarından kaynaklanıyordu.
2022: Certifried ve Sertifika Eşleştirme Problemleri
2022 yılında AD CS tarafında en çok ses getiren konulardan biri Certifried, yani CVE-2022-26923 oldu.
Bu zafiyet, sertifika tabanlı kimlik doğrulama ve hesap eşleştirme mekanizmalarının ne kadar hassas olduğunu gösterdi. Özellikle makine hesabı manipülasyonu üzerinden privilege escalation yapılabilmesi, AD CS’in domain güvenliği içindeki yerini tekrar tartışmaya açtı.
Microsoft bu konuya karşı KB5014754 ile önemli değişiklikler getirdi. Bu güncelleme ile birlikte sertifika eşleştirme tarafında daha sıkı kontroller ve SID security extension gibi mekanizmalar devreye girdi.
Ama iş burada bitmedi.
Araştırmacılar, bu yamaların etrafındaki yeni saldırı yüzeylerini incelemeye devam etti. Aynı dönemde ESC9, ESC10 ve ESC11 gibi teknikler gündeme geldi.
Özellikle ESC11 RPC relay konusu, AD CS’in sadece web enrollment arayüzleri üzerinden değil, farklı protokoller ve servisler üzerinden de saldırı zincirlerine dahil edilebileceğini gösterdi.
Yani 2022 bize şunu öğretti:
AD CS güvenliğinde sadece template kontrolü yapmak yetmez. Sertifika eşleştirme, NTLM relay yüzeyi, RPC erişimleri ve domain authentication davranışları birlikte değerlendirilmelidir.
2023: CA Altyapısının Daha Derinine İnen Saldırılar
2023 yılına geldiğimizde araştırmalar artık daha derin katmanlara inmeye başladı.
Bu dönemde dikkat çeken konulardan biri ESC12 oldu. ESC12, CA altyapısına ve özellikle HSM kullanılan ortamlara yönelik daha ileri seviye saldırı senaryolarını gündeme taşıdı.
Normalde birçok kurum HSM kullanımını “CA private key artık güvende” şeklinde yorumlar. Bu kısmen doğru olsa da tek başına yeterli değildir. Çünkü saldırganın hedefi her zaman sadece private key’i almak olmayabilir. CA üzerinde kod çalıştırmak, issuance sürecini manipüle etmek veya sertifika üretim zincirine müdahale etmek de aynı derecede kritik sonuçlar doğurabilir.
Bu nedenle AD CS güvenliği konuşurken sadece “private key nerede tutuluyor?” sorusunu değil, şu soruları da sormak gerekir:
- CA sunucusuna kimler erişebiliyor?
- CA üzerinde local admin kim?
- CA servis hesabı nasıl korunuyor?
- HSM entegrasyonu nasıl yapılmış?
- Sertifika issuance süreci kimler tarafından yönetiliyor?
- CA üzerinde audit loglar gerçekten izleniyor mu?
Bu soruların cevabı, ortamın gerçek risk seviyesini belirler.
2024: Yeni ESC Teknikleri ve EKUwu
2024 yılı AD CS araştırmaları açısından oldukça hareketli geçti.
Bu dönemde ESC13, ESC14 ve ESC15 gibi yeni teknikler gündeme geldi.
ESC13, issuance policy kullanımları üzerinden group claim ve OID ilişkilerinin nasıl kötüye kullanılabileceğini gösterdi.
ESC14, explicit certificate mapping tarafındaki zayıflıklara odaklandı. Özellikle altSecurityIdentities gibi alanların yanlış veya gevşek yönetilmesi, saldırganlara kimlik eşleştirme tarafında fırsat verebiliyor.
Daha sonra ESC15, yani kamuoyunda daha çok bilinen adıyla EKUwu, gündeme geldi. Bu teknik, sertifika template ve application policy davranışları üzerinden kötüye kullanım senaryolarını ortaya koydu.
Microsoft bu konu için CVE-2024-49019 yamasını yayınladı.
Aynı dönemde Windows Server 2025 GA ile birlikte önemli bir güvenlik değişikliği daha geldi: AD CS tarafında EPA, yani Extended Protection for Authentication, varsayılan olarak daha güçlü bir konuma taşındı. Bu, özellikle NTLM relay saldırılarını azaltmak açısından önemli bir adımdı.
Burada yine altını çizmek lazım:
EPA’nın aktif olması çok önemlidir ama AD CS güvenliği sadece EPA ile çözülmez.
Eğer ortamda zayıf template’ler, geniş enrollment izinleri, yanlış EKU’lar veya gevşek mapping ayarları varsa risk devam eder.
2025: Strong Mapping Enforcement ve Devam Eden Bypass Araştırmaları
2025 yılında Microsoft tarafında en kritik adımlardan biri, KB5014754 strong mapping enforcement davranışının varsayılan hale gelmesi oldu.
Bu ne anlama geliyor?
Kısaca, sertifika ile AD hesabı arasındaki eşleştirme artık daha sıkı doğrulanıyor. Eski ve gevşek mapping davranışları azaltılıyor. Bu da özellikle Certifried sonrası ortaya çıkan riskleri azaltmak için oldukça önemli.
Ancak güvenlikte klasik kural burada da geçerli:
Bir kontrolün varsayılan hale gelmesi, ortamın otomatik olarak güvenli olduğu anlamına gelmez.
Bu dönemde ESC16 gibi yeni teknikler yayınlandı. ESC16, security extension’ın CA genelinde devre dışı bırakılması gibi durumlarda, CA çapında global bir ESC9 etkisi oluşabileceğini gösterdi.
Yani Microsoft strong mapping tarafında daha güvenli varsayılanlar getirse bile, kurumların legacy uyumluluk, eski template’ler veya yanlış registry ayarları nedeniyle bu korumaları zayıflatması mümkün.
Aynı yıl WSUS is SUS çalışması da dikkat çekti. Bu araştırma doğrudan klasik bir AD CS açığı gibi görünmese de NTLM relay ve AD CS saldırı zincirleri açısından önemli bir öncül olarak değerlendirilebilir.
Bu da bize tekrar aynı şeyi söylüyor:
AD CS güvenliğini tek başına AD CS üzerinde aramak yeterli değildir. NTLM relay’e sebep olabilecek diğer servisler de bu zincirin parçasıdır.
2026: ESC17 ve Bitmeyen AD CS Hikayesi
Timeline’ın 2026 tarafında ESC17 — Server Auth abuse konusu öne çıkıyor.
Buradaki ana fikir, daha önce düzeltilmiş veya azaltılmış gibi görünen bazı senaryoların, farklı sertifika kullanımları ve Server Authentication abuse üzerinden yeniden exploit edilebilir hale gelebilmesi.
Özellikle “ESC1 fix” olarak görülen bazı kontrollerin her ortamda yeterli olmayabileceği vurgulanıyor.
Bu da aslında AD CS tarafındaki genel problemi çok iyi özetliyor:
Microsoft bir açık için yama yayınlıyor. Araştırmacılar bu yamanın sınırlarını inceliyor. Yeni bypass veya yeni kötüye kullanım yolu bulunuyor. Microsoft tekrar sıkılaştırma yapıyor. Kurumlar ise bu süreçte hem patch yönetimini hem de konfigürasyon yönetimini doğru yapmak zorunda kalıyor.
Peki Kurumlar Ne Yapmalı?
Benim bu timeline’dan çıkardığım en önemli sonuç şu:
AD CS güvenliği sadece “sunucular güncel mi?” sorusu ile ölçülemez.
Evet, patch yönetimi şart. Microsoft’un yayınladığı KB’ler, CVE düzeltmeleri ve strong mapping enforcement gibi değişiklikler mutlaka takip edilmeli.
Ama AD CS tarafında asıl risk çoğu zaman şu noktalarda ortaya çıkıyor:
- Yanlış yapılandırılmış certificate template’ler
- Gereğinden geniş enrollment izinleri
- Client Authentication içeren riskli EKU’lar
- Kullanıcının subject veya SAN alanını kontrol edebildiği template’ler
- Manager approval olmadan kritik sertifika alınabilmesi
- EPA kapalı web enrollment servisleri
- NTLM relay’e açık endpoint’ler
- Legacy uyumluluk için gevşetilmiş certificate mapping ayarları
- CA üzerinde gereksiz admin hakları
- Security extension’ın devre dışı bırakılması
- CA ve template değişikliklerinin izlenmemesi
Bu nedenle AD CS güvenliği için düzenli olarak aşağıdaki kontroller yapılmalı:
- Certificate template analizi
- Enrollment ve auto-enrollment haklarının gözden geçirilmesi
- ESC1–ESC17 tekniklerine göre exposure analizi
- NTLM relay yüzeyinin incelenmesi
- EPA durumunun kontrol edilmesi
- Strong mapping enforcement seviyesinin doğrulanması
- CA sunucusu local admin ve servis hesaplarının incelenmesi
- CA audit loglarının merkezi olarak izlenmesi
- Legacy ayarların ve registry değişikliklerinin kontrol edilmesi
- AD CS değişikliklerinin change management sürecine dahil edilmesi
AD CS, Microsoft ekosisteminde uzun süre hak ettiği güvenlik ilgisini görmeyen bileşenlerden biriydi. Ancak 2021’den itibaren yayınlanan araştırmalar, bu servisin domain güvenliği açısından ne kadar kritik olduğunu açıkça ortaya koydu.
Bugün geldiğimiz noktada AD CS için şunu söylemek yanlış olmaz:
AD CS, doğru yapılandırıldığında güçlü bir kurumsal PKI altyapısıdır. Yanlış yapılandırıldığında ise saldırgan için domain compromise yoludur.
Microsoft son yıllarda önemli yamalar ve güvenlik varsayılanları yayınladı. Ancak AD CS risklerinin önemli bir bölümü hala kurumların kendi yapılandırmalarına bağlı.
Bu yüzden kurumların sadece patch seviyesine değil, AD CS tasarımına, template yapılandırmalarına, enrollment haklarına, mapping davranışlarına ve NTLM relay yüzeyine düzenli olarak bakması gerekiyor.
Kısacası AD CS güvenliği bir kere yapılan bir kontrol değil; sürekli izlenmesi gereken bir güvenlik alanıdır.
Bu noktada ki en iyi tavsiyem düzenli olarak AD ortamlarınız için sağlık taraması hizmeti almanız olacaktır, bu sayede bu tür güncellemeleri takip eden uzman ekipler tarafından her 6 ayda bir sistemleriniz taranıp bu tür zafiyetlere karşı hazırlıklı olabilirsiniz.
Eğer bir danışmanlık bütçeniz yok ise ÇözümPark Bilişim Portalı üzerinden ücretsiz olarak aşağıdaki makaleleri inceleyebilirsiniz;
Bilişim Danışmanlığı – ITSTACK
Active Directory Güvenlik Serisi – Bölüm 1: NTLMv1’i Devre Dışı Bırakmak – ÇözümPark
Deep Dive: Active Directory Federation Services (ADFS) Bölüm 1 – ÇözümPark
Resim Kaynakları: SpecterOPS
