Merhaba
Bir önceki bölümde, bir sertifika şablonunun yanlış yapılandırılmasının (ESC1) nasıl domain admin ayrıcalığına sıçramaya yol açtığını gördük. Bu bölümde ise, AD CS’e yönelik tekniklerin en kritiği olan ve şablon yapılandırmasından tamamen bağımsız çalışan bir senaryoyu ele alıyoruz: saldırganın Certificate Authority’nin kendi özel anahtarını ele geçirdiği Golden Certificate tekniği. ESC1’de saldırgan CA’yı “kandırır”; Golden Certificate’te ise saldırgan CA’nın ta kendisi haline gelir.
Golden Certificate
Bir Certificate Authority, verdiği her sertifikayı kendi özel anahtarıyla (private key) imzalar; bu imza, sertifikanın gerçekten o CA tarafından verildiğini ve güvenilir olduğunu kanıtlar. Domain’deki her üye sistem ve kullanıcı, Enterprise CA’nın kök sertifikasına (ve dolayısıyla o özel anahtarla atılan her imzaya) örtük olarak güvenir. Bir saldırgan, CA sunucusunun kendisini ele geçirir ve CA’nın özel anahtarını çalarsa (örneğin CA sunucusunda yerel yönetici olarak `certutil -exportPFX` benzeri bir işlemle, ya da anahtar bir HSM’de değil yazılımsal olarak saklanıyorsa), CA’nın normal talep/onay sürecinden tamamen geçmeden, kendi bilgisayarında istediği herhangi bir kullanıcı (bir Domain Admin, hatta krbtgt hesabı) adına, istediği geçerlilik süresiyle, tamamen geçerli görünen bir sertifika üretebilir. Bu sahte sertifika, gerçek CA’nın anahtarıyla imzalandığı için domain’deki hiçbir sistem tarafından sahte olarak ayırt edilemez ve PKINIT üzerinden o kimlikle sorunsuz bir Kerberos TGT almak için kullanılabilir. Bu teknik, Golden Ticket tekniğiyle (serinin ileriki bir bölümünde ele alınacak, krbtgt hesabının NTLM hash’inin çalınmasına dayanan teknik) kavramsal olarak akrabadır; ikisi de bir “kök güven” materyalinin (krbtgt hash’i veya CA özel anahtarı) ele geçirilmesiyle, o güven zincirine bağlı herhangi bir kimliğin sınırsız ve kalıcı şekilde taklit edilebilmesini sağlar. Farkı, Golden Certificate’in sertifika tabanlı kimlik doğrulama (PKINIT) üzerinden çalışmasıdır. Bu özelliği son derece tehlikeli kılan asıl unsur ise kalıcılığıdır: saldırgan CA’nın özel anahtarını bir kez ele geçirdiğinde, domain’deki tüm parolalar sıfırlansa, krbtgt hesabı iki kez döndürülse (rotate edilse) bile, CA sertifikası ve anahtarı yenilenmediği sürece saldırgan istediği zaman yeni sahte sertifikalar üreterek domain’e geri dönebilir.
Golden Certificate’i Mitigasyon Etmek
Golden Certificate tekniğini mitigasyon etmek için aşağıdaki güvenlik kontrolleri uygulanmalıdır:
- CA’nın özel anahtarını bir Hardware Security Module (HSM) içinde saklayın. Anahtar donanımsal olarak korunduğunda, CA sunucusunun işletim sistemi ele geçirilse bile özel anahtar dışa aktarılamaz (export edilemez).
- CA sunucusunu Tier 0 varlık olarak sınıflandırın ve buna göre izole edin. CA sunucusuna yönetici erişimi, domain controller’lara erişimle aynı sıkılıkta kısıtlanmalı; RDP, uzak yönetim ve yerel oturum açma en az ayrıcalık ilkesine göre denetlenmelidir.
- CA özel anahtarının dışa aktarılabilir olarak yapılandırılmadığından emin olun. CA kurulumunda anahtarın “exportable” (dışa aktarılabilir) olarak işaretlenmesi, tek başına büyük bir risktir; bu ayar varsayılan olarak kapalı tutulmalıdır.
- CA private key erişimini ve export girişimlerini aktif olarak izleyin. HSM kullanılıyorsa, HSM’in kendi denetim kayıtları bu tür girişimleri raporlamalıdır.
- Bir CA anahtarının ele geçirildiğinden şüpheleniliyorsa, CA’yı tamamen yeniden kurun ve yeni bir kök sertifika/anahtar çifti oluşturun. Bu, domain’deki tüm sertifikaların yeniden verilmesini gerektiren büyük ve kesintili bir operasyondur, ama anahtar sızdıysa tek gerçek çözüm budur eski CA’ya güven asla geri kazanılamaz.
Golden Certificate’i Tespit Etmek
Golden Certificate’in tespiti, ESC1’e göre çok daha zordur; çünkü sahte sertifika CA’nın normal talep/onay sürecinden hiç geçmez, bu yüzden Event 4886/4887 gibi olağan CA denetim kayıtları üretilmez. Tespit, CA’nın kendi kayıtları ile sertifikanın kullanıldığı kimlik doğrulama olayları arasındaki tutarsızlığa odaklanmalıdır.
Golden Certificate’i Tespit Eden Olaylar
| Event ID | Kaynak | Açıklama |
|---|---|---|
| 4768 | Domain Controller’lar | Bir Kerberos TGT talebi olduğunda üretilir. PKINIT kullanıldığında sertifikanın seri numarasını içerir; bu seri numarasının CA’nın kendi verdiği sertifikalar veritabanında (`certutil -view`) karşılığı YOKSA, bu sertifikanın CA’nın normal süreci dışında (yani sahte olarak) üretildiğinin güçlü bir işaretidir. |
| 4886 / 4887 | Certificate Authority sunucusu | Bir Golden Certificate saldırısında bu event’ler ÜRETİLMEZ çünkü sahte sertifika hiçbir zaman CA’ya bir talep olarak sunulmaz. Bu event’lerin YOKLUĞU, 4768’de görülen bir PKINIT kimlik doğrulamasıyla birlikte değerlendirildiğinde, dolaylı ama önemli bir kanıttır. |
| 4662 | CA sunucusu (Active Directory) | Bir nesne üzerinde belirli bir işlem (özel bir erişim hakkı kullanılarak) gerçekleştirildiğinde üretilir; CA’nın yapılandırma nesnesine veya anahtar materyaline yönelik anormal erişimleri yakalamak için CA sunucusunda ve AD CS yapılandırma container’ında izlenmelidir. |
| 1102 | CA sunucusu | Security event log’unun temizlendiğinde üretilir. Saldırganların CA sunucusundaki izlerini örtme girişimlerinin klasik bir işaretidir ve CA sunucusunda her zaman en yüksek öncelikle izlenmelidir. |
Lab Uygulaması: Windows Server 2025 Üzerinde Golden Certificate Ön Koşulu
Bu tekniği kendi Windows Server 2025 lab ortamımda (W25DC.bakicubuk.local, Enterprise Root CA) denedim ama Bölüm 7’den farklı olarak, tekniği sonuna kadar tamamlamadım. Golden Certificate, CA’nın özel anahtarını ele geçirip bununla sınırsız sayıda sahte, tamamen geçerli görünen kimlik bilgisi üretebilmeye dayanıyor; bu üretimi fiilen gerçekleştirmek, tespiti son derece zor ve kalıcı bir saldırı aracı ortaya çıkarmak anlamına gelir. Bu yüzden lab’ı, tekniğin ön koşulunu (anahtarın ele geçirilebilirliği) kanıtlayacak ve tespit mantığını somutlaştıracak noktada durdurdum.
Adım 1 – CA’nın özel anahtarının dışa aktarılabilirliğini kontrol etmek. `certutil -store My` ile CA sunucusunun kendi sertifika deposunu inceledim:
certutil -store My çıktısında iki sertifika görünüyor – CA’nın kendi kök sertifikası (Certificate 0, Provider = Microsoft Software Key Storage Provider, dışa aktarılabilirlik hakkında herhangi bir kısıtlama belirtilmemiş) ve W25DC’nin DomainController sertifikası (Certificate 1, açıkça Private key is NOT exportable diyor). Bu karşılaştırma, domain controller sertifikaları gibi hassas materyallerde uygulanan korumanın, CA’nın kendi kök anahtarında uygulanmadığını gösteriyor.
Adım 2 – Dışa aktarımı fiilen denemek. certutil -exportPFX ile CA sertifikasını ve özel anahtarını bir PFX dosyasına aktarmayı denedim:
CertUtil: -exportPFX command completed successfully – CA’nın özel anahtarı, ek bir donanımsal koruma (HSM) veya CNG/KSP tabanlı bir kısıtlama olmadan, yerel bir yöneticinin erişimine tamamen açık. Bu, Windows Server 2025’in varsayılan Enterprise CA kurulumunda beklenmedik bir sertleştirme eksikliği ve tekniğin gerçek dünyada hala neden bu kadar tehlikeli olduğunun kanıtı.
Bu noktada dışa aktarılan ca_export_test.pfx dosyasını, sahte bir sertifika üretmeden güvenli şekilde sildim (Remove-Item -Force). Golden Certificate’in asıl gücü, saldırganın bu anahtarla CA’nın normal talep/onay sürecinin tamamen dışında, istediği kimlik adına sertifika üretebilmesinde; bunu fiilen göstermek yerine, CA’nın kendi kayıtlarının bu sahteciliği neden yakalayamayacağını gösterdim.
Adım 3 – CA’nın gerçek sertifika defterini incelemek. certutil -view -restrict "Disposition=20" ile CA’nın normal süreçte verdiği tüm sertifikaların listesini çektim:
CA’nın verdiği ilk sertifikalar – W25DC$ ve W25ADC$ domain controller sertifikaları, Administrator‘ın WebServer sertifikası.
Listenin devamı – Bölüm 7’den tanıdık lowpriv hesabının iki ESC1-Demo-Template talebi (Request ID 7 ve 9). Toplamda 5 satır, CA’nın bugüne kadar verdiği HER sertifikayı eksiksiz kapsıyor.
Bu liste, makalenin asıl noktasını somutlaştırıyor: CA’nın özel anahtarını ele geçiren bir saldırgan, bu deftere hiç dokunmadan, bu 5 satırın dışında, kendi ürettiği herhangi bir sahte sertifikayla domain’de dolaşabilir. Normal sertifika denetimi (Event 4886/4887, ya da bu certutil -view sorgusu) bu sahte sertifikayı asla yakalayamaz çünkü sahte sertifika CA’nın talep/onay sürecinden hiç geçmemiştir. Tek gerçek tespit noktası, bir PKINIT kimlik doğrulamasında (Event 4768) görülen sertifika seri numarasının, CA’nın kendi verdiği sertifikalar listesinde karşılığının olup olmadığını çapraz kontrol etmektir ve bu karşılaştırma, otomatikleştirilmiş bir izleme kuralı olmadan pratikte neredeyse imkansızdır.
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ç
Golden Certificate, AD CS’e yönelik tekniklerin doruk noktasıdır: şablon yapılandırmasından bağımsız, tamamen CA’nın kendi güven kökünü hedef alan ve tespiti son derece zor, kalıcılığı ise son derece yüksek bir tekniktir. Bu yüzden CA sunucusunun korunması, tek bir sunucunun güvenliğinden çok daha fazlasıdır domain’in tüm sertifika tabanlı güven zincirinin temelidir.
Serinin bir sonraki bölümünde, saldırganların domain controller’ları taklit ederek parola hash’lerini toplu halde çekmesini sağlayan DCSync tekniğini inceleyeceğiz.