Merhaba
Serinin önceki bölümlerinde SYSVOL’de unutulmuş bir parola kalıntısını ele almıştık. Bu bölümde ise, çok daha modern ve giderek daha kritik hale gelen bir saldırı yüzeyine geçiyoruz: Active Directory Certificate Services (AD CS). Sertifikalar artık yalnızca web sunucularını güvenceye almak için değil, kullanıcıları ve bilgisayarları parola olmadan kimlik doğrulamasında (certificate-based authentication, PKINIT) kullanmak için de domain’in ayrılmaz bir parçası haline geldi, ve bu da AD CS’i yanlış yapılandırıldığında domain’in tamamını ele geçirmeye açık, alternatif bir kimlik doğrulama otoritesine dönüştürüyor.
Active Directory Certificate Services (AD CS) – ESC1 İstismarı
AD CS, bir kurumun kendi Public Key Infrastructure’ını (PKI) işletmesini sağlayan bir Windows Server rol hizmetidir. Certificate Authority (CA), sertifika şablonları (certificate templates) aracılığıyla kullanıcılara ve bilgisayarlara sertifika verir; bu şablonlar hangi özneye (subject), hangi genişletilmiş anahtar kullanımına (Extended Key Usage, EKU) ve hangi izinlerle sertifika verileceğini tanımlar. Sertifikalar bir kez verildiğinde, sahibinin parolası olmadan da Kerberos PKINIT üzerinden domain’de kimlik doğrulaması yapmak için kullanılabilir. ESC1 (Escalation Path 1), Will Schroeder ve Lee Christensen’in 2021’de yayımladığı “Certified Pre-Owned” araştırmasında tanımlanan, en yaygın ve en kritik AD CS yanlış yapılandırmasıdır. Bir sertifika şablonu şu üç koşulu AYNI ANDA sağlıyorsa ESC1’e açıktır: (1) şablon, `ENROLLEE_SUPPLIES_SUBJECT` bayrağıyla talep sahibinin sertifikanın öznesini (Subject Alternative Name – SAN dahil) kendisinin belirlemesine izin verir, (2) şablon, İstemci Kimlik Doğrulama (Client Authentication) EKU’suna sahiptir (yani sertifika PKINIT ile oturum açmak için kullanılabilir), (3) düşük yetkili bir grup (genellikle `Domain Users` veya `Authenticated Users`) bu şablon üzerinde Enroll iznine sahiptir ve şablon yönetici onayı (manager approval) gerektirmez. Bu üç koşul bir arada olduğunda, düşük yetkili herhangi bir domain kullanıcısı, sertifika talebinde SAN alanına kendi kullanıcı adı yerine bir Domain Admin’in (hatta bir domain controller bilgisayar hesabının) kullanıcı adını yazarak CA’dan o kimliğe ait geçerli bir sertifika talep edebilir. CA, şablonun izin verdiği bu talebi normal bir işlem olarak onaylar ve saldırgana hedef hesabın kimliğiyle kimlik doğrulaması yapmasını sağlayan bir sertifika verir, bu da tek bir istekle doğrudan Domain Admin ayrıcalığına sıçrama anlamına gelir.
ESC1 İstismarını Mitigasyon Etmek
ESC1 istismarını mitigasyon etmek için aşağıdaki güvenlik kontrolleri uygulanmalıdır:
- Tüm sertifika şablonlarını PSPKIAudit veya Certipy gibi araçlarla düzenli olarak denetleyin. Bu araçlar, `ENROLLEE_SUPPLIES_SUBJECT` bayrağı, Client Authentication EKU’su ve düşük yetkili enroll izinlerinin aynı şablonda bir arada bulunduğu ESC1-ESC8 arası yanlış yapılandırmaları otomatik olarak tespit eder.
- `ENROLLEE_SUPPLIES_SUBJECT` bayrağını yalnızca gerçekten gerekli olan, sıkı şekilde kısıtlanmış şablonlarda kullanın. Çoğu kurumsal senaryoda talep sahibinin kendi sertifika öznesini belirlemesine hiç ihtiyaç yoktur; bu bayrak varsayılan olarak kapalı tutulmalıdır.
- Client Authentication EKU’suna sahip şablonlarda enroll iznini en az ayrıcalık ilkesine göre kısıtlayın. `Domain Users` veya `Authenticated Users` gibi geniş gruplara bu tür şablonlar üzerinde asla enroll izni verilmemelidir.
- Yüksek riskli şablonlar için yönetici onayını (`CT_FLAG_PEND_ALL_REQUESTS`) zorunlu kılın. Bu, her sertifika talebinin bir CA yöneticisi tarafından manuel olarak onaylanmasını gerektirir ve otomatik istismarı engeller.
- CA sunucusunun kendisini bir Tier 0 varlık olarak ele alın ve buna göre koruyun. CA’nın özel anahtarına erişimi olan herkes, teoride domain’in tamamını taklit edebilir (bkz. serinin ileriki bölümünde ele alınacak Golden Certificate tekniği).
ESC1 İstismarını Tespit Etmek
AD CS ile ilgili olaylar varsayılan olarak ayrıntılı loglanmaz; bu yüzden CA sunucusunda Certificate Services denetim ilkelerinin (Object Access) etkinleştirilmiş olması tespit için ön koşuldur. Aşağıdaki Event ID’ler merkezi olarak loglanmalı ve zamanında analiz edilmelidir.
ESC1 İstismarını Tespit Eden Olaylar
| Event ID | Kaynak | Açıklama |
|---|---|---|
| 4886 | Certificate Authority sunucusu | CA’nın bir sertifika talebi aldığında üretilir. Talep sahibinin kimliği ile talep edilen sertifikanın öznesi (SAN dahil) arasındaki uyumsuzluk – özellikle sıradan bir kullanıcının kendi adına değil de ayrıcalıklı bir hesap adına talepte bulunması – ESC1 istismarının en belirgin işaretidir. |
| 4887 | Certificate Authority sunucusu | CA bir sertifika verdiğinde üretilir. Şablon adı ve verilen sertifikanın öznesi burada da görünür; ESC1 kaynaklı bir istismarda, düşük yetkili bir hesabın Domain Admin veya domain controller adına verilmiş bir sertifika elde ettiği bu olayla doğrulanabilir. |
| 4768 | Domain Controller’lar | Bir Kerberos TGT talebi olduğunda üretilir. PKINIT (sertifika tabanlı) kimlik doğrulama kullanıldığında olay, sertifikanın seri numarası ve verenini (issuer) içeren ek alanlar taşır; bir hesabın normalde parolayla oturum açtığı halde aniden sertifikayla PKINIT üzerinden TGT alması, çalınmış/kötüye kullanılmış bir sertifikanın işareti olabilir. |
| 4899 / 4900 | Certificate Authority sunucusu | Bir sertifika şablonu güncellendiğinde (4899) veya CA güvenlik ayarları değiştirildiğinde (4900) üretilir. Bir şablona `ENROLLEE_SUPPLIES_SUBJECT` bayrağının eklenmesi veya enroll izinlerinin genişletilmesi gibi, ESC1 koşullarını yaratan yapılandırma değişikliklerini yakalamak için kritiktir. |
Lab Uygulaması: Windows Server 2025 Üzerinde ESC1 İstismarı
Bu tekniği kendi Windows Server 2025 (W25DC.bakicubuk.local, aynı zamanda Enterprise Root CA) ve Windows 11 (W11CLIENT.bakicubuk.local) lab ortamımda uçtan uca canlı olarak denedim. Aşağıdaki adımlar, gerçek bir düşük yetkili kullanıcının CA’yı nasıl kandırıp Administrator kimliğine ait geçerli bir sertifika elde edebildiğini gösteriyor.
Adım 1 – ESC1’e açık bir şablon oluşturmak. W25DC üzerinde certtmpl.msc ile User şablonunu çoğaltarak ESC1-Demo-Template adında yeni bir şablon oluşturdum ve üç ESC1 koşulunu tek tek yapılandırdım:
Subject Name sekmesinde “Supply in the request” seçili talep sahibinin sertifikanın öznesini (SAN dahil) kendisinin belirlemesine izin veren ENROLLEE_SUPPLIES_SUBJECT bayrağı.
Extensions sekmesinde Application Policies listesinde Client Authentication’ın yer alması sertifikanın PKINIT ile oturum açmak için kullanılabileceğinin kanıtı.
Security sekmesinde Domain Users grubuna Enroll izni verilmiş, yönetici onayı gerektirmeyen yapılandırma.
Şablonu certutil -SetCATemplates +ESC1-Demo-Template ile CA’da yayınladım ve certutil -CATemplates ile listede göründüğünü doğruladım.
Adım 2 – Düşük yetkili test kullanıcısı. lowpriv adında, herhangi bir ayrıcalıklı gruba üye olmayan sıradan bir domain kullanıcısı oluşturdum. İlk parola denemem (LowPriv2026!) parola karmaşıklık politikası tarafından reddedildi. Sebebi parolanın hesap adını (lowpriv) birebir içermesiydi; Bölüm 6’daki gppdemo parola reddiyle aynı kök neden. Hesap adını içermeyen farklı bir parolayla (Qz7#Falcon2026) sorunu çözdüm.
Adım 3 – SAN alanına Administrator’ı yazan sertifika talebi. W11CLIENT üzerinde lowpriv bağlamında (runas /user:bakicubuk\lowpriv) bir PowerShell açıp, talebin Subject Alternative Name alanına administrator@bakicubuk.local UPN’ini gömen bir INF dosyası hazırladım ve certreq -new ile talebi oluşturup certreq -submit ile CA’ya gönderdim:
Pencere başlığında “running as bakicu…” ifadesiyle doğrulanan lowpriv oturumunda, certreq -submit komutunun Certificate retrieved(Issued) Issued çıktısı – CA, düşük yetkili kullanıcının Administrator kimliğine ait talebini sorgusuz onaylamış.
Aldığım sertifikanın içeriğini incelediğimde, Subject alanının CN=lowpriv olmasına rağmen Subject Alternative Name uzantısında administrator@bakicubuk.local UPN’inin açıkça gömülü olduğunu gördüm. ESC1’in istismar edildiğinin doğrudan kanıtı. Bu noktada, elde edilen sertifikayı fiilen kullanıp gerçek bir Administrator kimliğiyle Kerberos TGT almaya (PKINIT) geçmedim; CA’nın bu talebi onaylamış olması tekniğin özünü zaten kanıtlıyor ve makalenin amacı gerçek bir yetki yükseltmesini tamamlamak değil, yanlış yapılandırmayı ve tespit noktalarını göstermek.
Adım 4 – CA denetim kaydı. Certificate Services denetimi varsayılan olarak kapalı olduğu için önce certutil -setreg CA\AuditFilter 127 ve auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable ile etkinleştirdim, CA servisini yeniden başlattım ve ikinci bir talep oluşturarak Event 4886 ile 4887’yi canlı yakaladım:
Event ID 4886 – Requester: BAKICUBUK\lowpriv, SAN from CSR: Principal Name=administrator@bakicubuk.local, Requested Template: ESC1-Demo-Template alanlarıyla, CA’nın talebi tam olarak kimden ve ne için aldığının kaydı.
Event ID 4887 – aynı talebin onaylanıp sertifikanın verildiğini, seri numarasıyla birlikte gösteren kayıt.
Bu iki event, ESC1’in CA tarafındaki en net imzasını oluşturuyor: normalde kendi kimliğiyle işlem yapması beklenen düşük yetkili bir hesabın, talebinde başka (ve çok daha ayrıcalıklı) bir kimliği taşıması. Lab sonrasında sertifikaları (certutil -revoke) iptal edip lowpriv hesabını devre dışı bırakarak ortamı temizledim.
Uyumluluk ve Çerçeve Eşlemesi Tablosu
| Çerçeve | İlgili Kontrol/Madde |
|---|---|
| PCI DSS | Gereksinim 7.1 (Erişim kısıtlaması), Gereksinim 8.2 (Güçlü kimlik doğrulama) |
| HIPAA | 164.312(a)(1) – Erişim Kontrolü |
| ISO 27001 | A.9.2 (Kullanıcı Erişim Yönetimi), A.9.4 (Sistem ve Uygulama Erişim Kontrolü) |
| KVKK | Madde 12 – Veri Güvenliğine İlişkin Yükümlülükler |
| TCMB | Bilgi Sistemleri Yönetimi Tebliğ – Erişim ve Yetkilendirme Kontrolleri |
| NIST CSF | PR.AC-4 (Erişim yetkilerinin yönetimi), PR.AC-1 (Kimlik ve kimlik bilgisi yönetimi) |
| CIS Controls | CIS 5 (Hesap Yönetimi), CIS 6 (Erişim Kontrol Yönetimi) |
MITRE ATT&CK: T1649 (Steal or Forge Authentication Certificates)
Sonuç
ESC1, AD CS’in gücünü parolasız, sertifika tabanlı kimlik doğrulama bir zayıflığa çeviren, tek bir yanlış yapılandırılmış şablonun tüm domain’i ele geçirmeye yetebileceği klasik bir örnektir. CA’nın kendisi hiçbir zaman “hacklenmez”; saldırgan yalnızca CA’nın kendisine verdiği izinleri, tasarlandığı gibi kullanır. Bu yüzden mitigasyon, CA’yı sıkılaştırmaktan çok, şablonların izin verdiği yetkileri periyodik olarak denetlemekten geçer.
Serinin bir sonraki bölümünde, saldırganın CA’nın özel anahtarını ele geçirdiği daha da kritik bir senaryoyu, Golden Certificate tekniğini inceleyeceğiz.