AD CS Güvenliği Rehberi: ESC1–ESC16 Zafiyetlerini Tespit Etme, Sertleştirme ve İzleme

Active Directory Certificate Services (AD CS), kurumların iç PKI altyapısını yönettiği ve çoğu zaman "kurulup unutulan" bir Windows Server rolüdür. Oysa yanlış yapılandırılmış tek bir sertifika şablonu, düşük yetkili bir etki alanı kullanıcısının birkaç dakika içinde Domain Admin kimliğine bürünmesine yetebilir. Üstelik sertifikalar parola değişikliğinden etkilenmediği için bu erişim aylarca fark edilmeden sürebilir.

Bu rehberde AD CS saldırı sınıflarını (ESC1–ESC16) savunma bakış açısıyla ele alıyor; zafiyetli yapılandırmaları nasıl tespit edeceğinizi, hangi ayarlarla kapatacağınızı ve kötüye kullanımı hangi olay kayıtlarıyla yakalayacağınızı adım adım anlatıyoruz.

1. AD CS neden bu kadar kritik?

AD CS'nin verdiği sertifikalar Kerberos PKINIT ve Schannel üzerinden kimlik doğrulamada kullanılabilir. Bir sertifika "Client Authentication" amaçlı ise ve içinde başka bir kullanıcının kimliği (UPN veya SID) yer alıyorsa, o sertifikayı taşıyan kişi o kullanıcı olarak oturum açabilir.

Özellik	Parola	Sertifika
Parola sıfırlanınca geçersiz olur mu?	Evet	Hayır, süresi dolana veya iptal edilene kadar geçerli
Tipik geçerlilik	Politika ile kısıtlı	Şablona göre 1–2 yıl veya daha uzun
Ele geçirildiğinde görünürlük	Başarısız giriş kayıtları	Çoğu ortamda hiç izlenmez
Kalıcılık etkisi	Düşük	Yüksek

2. ESC saldırı sınıfları: kısa harita

SpecterOps'un 2021'de başlattığı sınıflandırma bugün ESC16'ya kadar genişledi. Savunma açısından en önemli olanlar şunlardır:

Sınıf	Kök neden	Temel düzeltme
ESC1	Şablonda "Supply in the request" açık, Client Authentication EKU var, düşük yetkililer kayıt olabiliyor	Subject bilgisini AD'den oluşturun, kayıt izinlerini daraltın, yönetici onayı ekleyin
ESC2	Any Purpose EKU veya EKU'suz şablon	EKU'yu yalnızca gereken amaçla sınırlayın
ESC3	Certificate Request Agent (enrollment agent) şablonu geniş kitleye açık	Enrollment agent kısıtlamaları tanımlayın
ESC4	Şablon üzerinde düşük yetkililere yazma izni (WriteDacl, WriteOwner, WriteProperty)	Şablon ACL'lerini temizleyin
ESC5	PKI nesnelerinde (CA bilgisayar hesabı, PKI konteynerleri) zayıf ACL	PKI nesnelerini Tier 0 olarak yönetin
ESC6	CA'da EDITF_ATTRIBUTESUBJECTALTNAME2 bayrağı açık	Bayrağı kapatın
ESC7	Düşük yetkililerde ManageCA veya ManageCertificates hakkı	CA yetkilerini yalnızca PKI yöneticilerine bırakın
ESC8	HTTP Web Enrollment uç noktasına NTLM relay	HTTPS + EPA, NTLM kısıtlaması veya rolü kaldırma
ESC9 / ESC10	Güvenlik uzantısının olmaması ve zayıf sertifika eşleme	Güçlü sertifika eşlemeyi (Full Enforcement) uygulayın
ESC11	ICPR RPC arayüzüne şifresiz istek ile NTLM relay	IF_ENFORCEENCRYPTICERTREQUEST bayrağını açın
ESC13	Issuance policy OID'sinin bir AD grubuna bağlanması	OID grup bağlantılarını gözden geçirin
ESC15	Şema v1 şablonlarda uygulama politikası enjeksiyonu (CVE-2024-49019)	Güncellemeleri kurun, v1 şablonları kopyalayıp yeniden yayımlayın
ESC16	CA genelinde güvenlik uzantısının devre dışı bırakılması	szOID_NTDS_CA_SECURITY_EXT uzantısını yeniden etkinleştirin

NTLM relay ile bağlantılı ESC8 senaryosunun ayrıntıları için NTLM relay hardening rehberimize de göz atabilirsiniz.

3. Denetim: zafiyetli yapılandırmaları bulmak

Saldırganın kullandığı araçlarla aynı görünürlüğe sahip olmak savunmanın ilk adımıdır. Aşağıdaki araçlar yalnızca yetkiniz olan ortamlarda ve değişiklik yönetimi kapsamında çalıştırılmalıdır.

Locksmith ile hızlı tarama

Locksmith, PKI yöneticileri için geliştirilmiş açık kaynaklı bir PowerShell modülüdür ve yaygın ESC sorunlarını tespit edip düzeltme önerisi üretir.

CODE TERMINAL

Install-Module -Name Locksmith -Scope CurrentUser
Invoke-Locksmith -Mode 2   # Bulguları ve düzeltme önerilerini ayrıntılı listeler

Certipy ile bağımsız doğrulama

Certipy, kırmızı takım tarafından da kullanılan ancak savunma ekipleri için de değerli bir envanter aracıdır. Yalnızca zafiyetli bulunan şablonları raporlamak için:

CODE TERMINAL

certipy find -u [email protected] -p '' -dc-ip 10.0.0.10 -vulnerable -stdout

Çıktıda her şablon için "Enrollee Supplies Subject", "Extended Key Usage", "Enrollment Rights" ve "[!] Vulnerabilities" alanlarına odaklanın.

Yerleşik araçlarla CA ayarlarını kontrol etmek

CODE TERMINAL

certutil -getreg policy\EditFlags
certutil -getreg CA\InterfaceFlags
certutil -v -dstemplate

İlk komutun çıktısında EDITF_ATTRIBUTESUBJECTALTNAME2 görüyorsanız ESC6, ikinci komutta IF_ENFORCEENCRYPTICERTREQUEST yoksa ESC11 riski vardır.

4. Şablon sertleştirme (ESC1–ESC4)

Sertifika Şablonları konsolunda (certtmpl.msc) her Client Authentication şablonu için şu kontrol listesini uygulayın:

Subject Name sekmesinde "Supply in the request" yerine "Build from this Active Directory information" seçin.
Talepte subject gerçekten gerekiyorsa Issuance Requirements sekmesinde "CA certificate manager approval" seçeneğini etkinleştirin.
Extensions → Application Policies içinde yalnızca gereken EKU'yu bırakın; "Any Purpose" ve boş EKU kullanmayın.
Security sekmesinde "Domain Users", "Authenticated Users" ve "Domain Computers" gruplarının Enroll/Autoenroll hakkını gerçekten gerekmedikçe kaldırın.
Şablon nesnesi üzerinde Write, WriteDacl ve WriteOwner haklarının yalnızca PKI yöneticilerinde olduğunu doğrulayın.
Kullanılmayan şablonları CA'dan yayından kaldırın (Certificate Templates → Delete, şablon AD'de kalır).

Yayımlanan şablonları CA üzerinde listelemek için:

CODE TERMINAL

certutil -CATemplates

5. CA düzeyinde sertleştirme (ESC6, ESC7, ESC11, ESC16)

CODE TERMINAL

:: ESC6 - SAN bayrağını kapat
certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

:: ESC11 - RPC isteklerinde şifrelemeyi zorunlu kıl
certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST

:: Değişikliklerin etkinleşmesi için servisi yeniden başlat
net stop certsvc && net start certsvc

ESC7 için CA konsolunda (certsrv.msc) CA özelliklerindeki Security sekmesini açın ve "Issue and Manage Certificates" ile "Manage CA" haklarının yalnızca adlandırılmış PKI yönetici grubunda olduğunu doğrulayın. ESC16 için CA'nın devre dışı uzantılar listesinde 1.3.6.1.4.1.311.25.2 OID'sinin bulunmadığından emin olun:

CODE TERMINAL

certutil -getreg policy\DisableExtensionList

6. Web Enrollment ve ESC8

Certificate Authority Web Enrollment (certsrv) ve Certificate Enrollment Web Service rolleri gerekli değilse kaldırın. Gerekliyse:

Yalnızca HTTPS kullanın ve HTTP bağlamasını kaldırın.
IIS üzerinde Extended Protection for Authentication (EPA) ayarını "Required" yapın.
Mümkünse NTLM kimlik doğrulamasını kapatıp yalnızca Kerberos'a izin verin.
Etki alanı denetleyicilerinden bu uç noktaya giden kimlik doğrulamaları ağ düzeyinde kısıtlayın.

7. Güçlü sertifika eşleme (ESC9, ESC10)

Microsoft, KB5014754 ile sertifikalara kullanıcının SID bilgisini taşıyan bir güvenlik uzantısı ekledi ve etki alanı denetleyicilerinde güçlü eşlemeyi kademeli olarak zorunlu kıldı. Güncel ve desteklenen Windows Server sürümlerinde uyumluluk modu artık bulunmamaktadır; ancak eski veya güncellenmemiş etki alanı denetleyicilerinde şu kayıt defteri değerini kontrol edin:

CODE TERMINAL

reg query HKLM\SYSTEM\CurrentControlSet\Services\Kdc /v StrongCertificateBindingEnforcement
:: 2 = Full Enforcement (önerilen)

Schannel tarafında CertificateMappingMethods değerinin UPN eşlemesini (0x4) içermediğini doğrulayın. Şablonlarda CT_FLAG_NO_SECURITY_EXTENSION bayrağı bulunmamalıdır.

8. İzleme: kötüye kullanımı yakalamak

AD CS olay kayıtları varsayılan olarak kapalıdır. Önce CA denetimini etkinleştirin:

CODE TERMINAL

certutil -setreg CA\AuditFilter 127
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable
net stop certsvc && net start certsvc

Olay kimliği	Anlamı	Neye bakılmalı?
4886	Sertifika isteği alındı	Olağan dışı hesap veya saat
4887	Sertifika onaylandı ve verildi	İsteyen kullanıcı ile sertifikadaki SAN/UPN farklı mı?
4888	Sertifika isteği reddedildi	Tekrarlayan denemeler
4899 / 4900	Şablon güncellendi / şablon güvenliği değişti	ESC4 izleri
4768	Kerberos TGT isteği	"Certificate Information" alanı dolu PKINIT girişleri

Microsoft Sentinel kullanıyorsanız, istek sahibi ile sertifika konusu farklı olan verilmiş sertifikaları yakalamak için basit bir başlangıç sorgusu:

CODE TERMINAL

SecurityEvent
| where EventID == 4887
| extend Requester = extract(@"Requester:\s+(\S+)", 1, EventData),
         Subject   = extract(@"Subject:\s+(.+?)\s", 1, EventData)
| where isnotempty(Subject) and Subject !contains Requester
| project TimeGenerated, Computer, Requester, Subject, EventData

Sorgu yapısını kendi olay biçiminize göre uyarlayın; KQL ile tehdit avcılığı için Microsoft Sentinel KQL rehberimize bakabilirsiniz.

9. Olay sonrası: sertifika iptali

Şüpheli bir sertifika tespit ettiğinizde kullanıcının parolasını sıfırlamak yeterli değildir. Sertifikayı seri numarasıyla iptal edin ve CRL'yi hemen yayımlayın:

CODE TERMINAL

certutil -revoke  1
certutil -crl

Ardından aynı şablondan son dönemde verilmiş tüm sertifikaları gözden geçirin ve kök nedeni (şablon ACL'si, CA bayrağı vb.) kapatmadan olayı kapanmış saymayın.

10. Kontrol listesi

AD CS sunucularını ve PKI nesnelerini Tier 0 varlık olarak sınıflandırın.
Locksmith veya Certipy ile üç ayda bir ESC taraması yapın.
"Supply in the request" + Client Authentication birleşimini ortadan kaldırın.
EDITF_ATTRIBUTESUBJECTALTNAME2 bayrağını kapatın, IF_ENFORCEENCRYPTICERTREQUEST bayrağını açın.
Gerekmeyen Web Enrollment rollerini kaldırın, kalanlarda HTTPS + EPA uygulayın.
Etki alanı denetleyicilerinde güçlü sertifika eşlemeyi doğrulayın.
CA denetim kayıtlarını açıp 4886/4887/4899 olaylarını SIEM'e aktarın.
Kullanılmayan şablonları yayından kaldırın ve şablon değişikliklerini değişiklik yönetimine bağlayın.

Kaynaklar

TR Siber Ekibi Yazar · TRSiber

Kaynak bağlantısı ← Ana sayfaya dön