Active Directory’yi Ele Geçirme Teknikleri Serisi – Bölüm 11: Golden Ticket

bakicubuk

2 saat önce

Merhaba

Son iki bölümde, saldırganın domaindeki hesapların parola hash’lerine iki farklı yoldan (DCSync ve ntds.dit‘in dökülmesi) nasıl ulaşabildiğini gördük. Bu bölümde, bu hash’lerden en kritik olanının krbtgt hesabının hash’inin ele geçirilmesi durumunda ne olduğunu inceliyoruz: Golden Ticket. Bu teknik, Kerberos kimlik doğrulamasının temelini oluşturan güven zincirini doğrudan hedef alır ve saldırgana domain üzerinde, neredeyse hiçbir sınırı olmayan bir kalıcılık (persistence) mekanizması sağlar.

Golden Ticket

Kerberos protokolünde, bir kullanıcı domain’e kimlik doğruladığında kendisine bir Ticket Granting Ticket (TGT) verilir. Bu TGT, krbtgt adlı özel bir hesabın parola hash’i ile şifrelenir ve imzalanır yani krbtgt hesabı, tüm domain’in Kerberos güven zincirinin kök anahtarı işlevi görür. Kullanıcı daha sonra bu TGT’yi kullanarak, herhangi bir hizmete erişmek için domain controller’dan servis bileti (service ticket) talep eder; domain controller da TGT’nin gerçekten kendisi tarafından imzalanmış olduğunu, yalnızca krbtgt hash’ini bilerek doğrulayabildiği için güvenir. Golden Ticket tekniği, bir saldırganın krbtgt hesabının NTLM hash’ini (DCSync, ntds.dit dökümü veya başka bir yolla) ele geçirdiğinde, bu hash’i kullanarak kendi TGT’sini offline olarak, hiçbir domain controller’a danışmadan sahte olarak imzalayabilmesidir. Bu sahte TGT içine, saldırgan istediği herhangi bir kullanıcı adını, istediği herhangi bir grup üyeliğini (Domain Admins, Enterprise Admins dahil) ve istediği bir geçerlilik süresini (varsayılan olarak 10 yıla kadar) yazabilir çünkü bilet, gerçek bir domain controller tarafından değil, doğrudan saldırgan tarafından, ele geçirilen anahtarla imzalanmaktadır. Bu tekniğin en tehlikeli yönü, sahte TGT’nin domain controller’a hiçbir zaman bir “TGT talebi” (AS-REQ) olarak ulaşmamasıdır saldırgan doğrudan servis bileti talebiyle (TGS-REQ) domain controller’a gelir ve TGT’nin geçerliliği yalnızca imzanın doğru olup olmadığına bakılarak kontrol edilir. Bu yüzden Golden Ticket, klasik “başarısız/başarılı oturum açma” loglarında görünmez; saldırgan sanki gerçek bir kullanıcıymış gibi doğrudan kaynaklara erişir. Ayrıca krbtgt hesabının parolası döndürülmediği sürece, bu sahte biletler yıllarca geçerliliğini korur bu da tekniği yalnızca bir saldırı aracı değil, aynı zamanda son derece kalıcı bir arka kapı (backdoor) haline getirir.

Golden Ticket’ı Mitigasyon Etmek

Bu tekniği mitigasyon etmek için aşağıdaki güvenlik kontrolleri uygulanmalıdır:

krbtgt hesabının parolasını (ve dolayısıyla NTLM hash’ini) düzenli olarak iki kez art arda döndürün. Bu, hem henüz kullanılmamış hem de zaten üretilmiş Golden Ticket’ları geçersiz kılan tek etkili mitigasyondur. Tek seferlik bir döndürme yeterli değildir; Kerberos’un krbtgt için eski ve yeni parolayı belirli bir süre kabul etmesi nedeniyle, iki kez art arda döndürmek gerekir.
DCSync ve ntds.dit dökümü gibi öncül teknikleri sıkı biçimde tespit edin ve engelleyin (serinin önceki iki bölümü) Golden Ticket, krbtgt hash’i ele geçirilmeden gerçekleştirilemez, bu yüzden en etkili savunma önceki aşamada durdurmaktır.
Anormal derecede uzun geçerlilik sürelerine sahip Kerberos biletlerini izleyin. Varsayılan domain politikasında TGT geçerlilik süresi genellikle 10 saattir; bunun çok üzerinde bir süreye sahip biletler (örneğin 10 yıl) güçlü bir gösterge olabilir.
Var olmayan veya silinmiş kullanıcı hesapları adına üretilmiş biletleri izleyin. Golden Ticket’lar genellikle gerçek bir Active Directory nesnesine karşılık gelmeyen kullanıcı adlarıyla (veya silinmiş hesaplarla) üretilebilir.
Microsoft’un PAC (Privilege Attribute Certificate) doğrulama mekanizmasını etkinleştirin ve izleyin. Bu, servis bileti sunan sunucuların, biletin içindeki grup üyeliği bilgisini periyodik olarak domain controller’a tekrar doğrulatmasını sağlar; bu da bazı Golden Ticket varyantlarını (özellikle uzun ömürlü olanları) yakalayabilir.

Golden Ticket’ı Tespit Etmek

Golden Ticket’ın tespiti, klasik oturum açma loglarına değil, Kerberos bilet kullanım desenlerindeki anomalilere dayanır.

Golden Ticket’ı Tespit Eden Olaylar

Event ID	Kaynak	Açıklama
4769	Domain Controller’lar	Bir servis bileti (TGS) talep edildiğinde üretilir. Golden Ticket kullanımında, karşılık gelen bir 4768 (TGT talebi) event’i OLMADAN doğrudan 4769 event’lerinin görülmesi güçlü bir göstergedir çünkü sahte TGT hiçbir zaman domain controller’dan talep edilmemiştir.
4624	Hedef Sunucu/İstasyon	Bir hesap oturum açtığında üretilir. Golden Ticket ile erişilen kaynaklarda, `Logon Process` alanının `Kerberos` olduğu ama daha önce hiç görülmemiş ya da mantıksız bir kullanıcı kaynak kombinasyonu içeren oturumlar incelenmelidir.
4771	Domain Controller’lar	Kerberos ön kimlik doğrulaması başarısız olduğunda üretilir. Doğrudan bu event’i atlayan (yani hiç başarısız denemeden gelen) anormal derecede “kusursuz” erişim desenleri incelenmeye değer olabilir.
4670	Hedef Sunucu	Bir nesnenin izinleri değiştirildiğinde üretilir; `krbtgt` hesabının parola değişikliğiyle ilişkili olarak izlenmesi, mitigasyonun (parola döndürmenin) gerçekten uygulandığını doğrulamak için kullanılabilir.

Lab Uygulaması: Windows Server 2025 Üzerinde Golden Ticket

Bu bölümde tekniği kendi lab ortamımızda (W25DC.bakicubuk.local domain controller, W11CLIENT.bakicubuk.local istemci) uyguladık ama beklediğimizden farklı, öğretici bir sonuçla karşılaştık: Windows Server 2025’in KDC’si, klasik RC4 tabanlı sahte biletleri reddediyor. Bu, tekniği tamamen tamamlayamadığımız ama gerçek dünyada karşılaşılabilecek bir sertleştirme örneğini somut olarak gözlemlediğimiz bir gösterim oldu.

Adım 1: krbtgt Hash’ini Elde Etmek

Bölüm 9’da oluşturduğumuz lowpriv test hesabı, zaten DCSync haklarına (Replicating Directory Changes / Replicating Directory Changes All) sahip olduğu için, gerçek bir saldırganın izleyeceği yolu birebir takip ederek krbtgt hesabının kimlik bilgilerini bu hesap üzerinden çektik:

mimikatz # lsadump::dcsync /domain:bakicubuk.local /user:krbtgt

Sonuç, krbtgt hesabının hem NTLM/RC4 hash’ini hem de daha güçlü AES anahtarlarını döndürdü:

Hash NTLM: 1dcf950cb4cf4206bb0222fe48c3cb85
aes256_hmac (4096): 9ad885ca9fec8618f4c3b0bd84560e1c60a4e8b04e4d25981c4d87e47635c821
aes128_hmac (4096): e4b7993921b5689a9cd83609afd96d06

Adım 2: Sahte TGT’yi Üretmek (RC4 ile – İlk Deneme)

Gerçek bir Domain Admin kimliğine bürünmek yerine, Active Directory’de hiç var olmayan bir kullanıcı adı (goldendemo) ve rastgele bir RID (9999) kullanarak, yalnızca teknik mekanizmayı kanıtlayacak bir sahte TGT ürettik:

mimikatz # kerberos::golden /user:goldendemo /domain:bakicubuk.local /sid:S-1-5-21-3478788356-4009446651-4006572080 /krbtgt:1dcf950cb4cf4206bb0222fe48c3cb85 /id:9999 /groups:512 /ptt

Mimikatz bileti başarıyla üretti ve mevcut oturuma enjekte etti:

Lifetime : 24/09/2026 01:50:54 ; 21/09/2036 01:50:54 ; 21/09/2036 01:50:54
Golden ticket for 'goldendemo @ bakicubuk.local' successfully submitted for current session

Lifetime alanı, tekniğin en dikkat çekici özelliğini gösteriyor: sahte bilet 10 yıllık bir geçerlilik süresine sahip normal bir TGT’nin (genellikle 10 saat) yüz binlerce katı. klist ile bu biletin bellekte doğru şekilde önbelleğe alındığını (Client: goldendemo @ bakicubuk.local, End Time: 9/21/2036) doğruladık.

Adım 3: KDC’nin RC4’ü Reddetmesi

Bu sahte TGT’nin gerçekten çalışıp çalışmadığını, doğrudan bir servis bileti (TGS) talebiyle test ettik. Windows’un klist.exe aracı, bir SPN için doğrudan LSA üzerinden servis bileti talep etmeyi sağlayan get alt komutuna sahip bu, SMB oturum önbelleği gibi karmaşık faktörlerden bağımsız, temiz bir test sağlıyor:

klist get cifs/W25DC.bakicubuk.local

Sonuç, beklenmedik ama önemli bir hata oldu:

Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x80090342
klist failed with 0xc00002fd/-1073741059: The encryption type requested is not supported by the KDC.

Bu hata, Windows Server 2025’in KDC’sinin, RC4-HMAC şifrelemeli TGT’lerle yapılan servis bileti taleplerini reddettiğini gösteriyor. Bunun nedeni muhtemelen, domain’in (ya da varsayılan olarak Windows Server 2025’in) Kerberos şifreleme politikasının artık yalnızca AES tabanlı şifreleme türlerini kabul etmesi. Bu, klasik Mimikatz kılavuzlarında sıkça görülen /krbtgt: parametresiyle üretilen RC4 tabanlı Golden Ticket’ların, güncel bir Windows Server 2025 ortamında artık tek başına yeterli olmayabileceği anlamına geliyor saldırganın AES anahtarlarını da ele geçirmiş olması gerekiyor (ki DCSync ve ntds.dit dökümü, RC4 hash’inin yanı sıra bu AES anahtarlarını da zaten döktüğü için, bu ek bir engel oluşturmuyor, ama tekniğin “yalnızca NTLM hash’i yeterli” şeklindeki eski varsayımının artık geçerli olmadığını gösteriyor).

Adım 4: AES256 ile Yeniden Deneme

krbtgt‘in DCSync çıktısında zaten elimizde olan AES256 anahtarını kullanarak bileti yeniden ürettik:

mimikatz # kerberos::golden /user:goldendemo /domain:bakicubuk.local /sid:S-1-5-21-3478788356-4009446651-4006572080 /aes256:9ad885ca9fec8618f4c3b0bd84560e1c60a4e8b04e4d25981c4d87e47635c821 /id:9999 /groups:512 /ptt

Bilet bu sefer AES-256-CTS-HMAC-SHA1-96 şifrelemesiyle üretildi ve klist ile doğru şekilde önbelleğe alındığı doğrulandı. Ancak klist get cifs/W25DC.bakicubuk.local ile servis bileti talep edildiğinde, bu sefer farklı bir hata alındı (No credentials are available in the security package) ve talep sonrasında bilet önbellekten tamamen silindi. Bu, KDC’nin isteği bir şekilde reddettiğinde LSA’nın şüpheli bileti önbellekten temizlediğini düşündürüyor; kesin kök nedeni (PAC imzalama detayı, ek bir Windows Server 2025 doğrulama katmanı, ya da ortam özelinde bir ayrıntı) daha derin bir analiz gerektiriyor.

Bulgunun Değerlendirilmesi

Bu lab denemesi, tekniği eksiksiz tamamlayamamış olsa da, makalenin amacı açısından değerli bir sonuç üretti: Windows Server 2025 varsayılan yapılandırması, klasik RC4 tabanlı Golden Ticket saldırılarına karşı ek bir direnç gösteriyor. Bu, mitigasyon bölümünde belirttiğimiz “krbtgt parolasını döndürün” önerisinin yanına, “ortamınızda zayıf Kerberos şifreleme türlerinin (RC4, DES) tamamen devre dışı bırakıldığından emin olun” önerisini de ekleyebileceğimiz anlamına geliyor çünkü bu, en azından bazı Golden Ticket varyantlarını KDC seviyesinde engelleyen ek bir savunma katmanı sağlıyor. Saldırganın hala AES anahtarlarını ele geçirmiş olması durumunda teknik yine de işleyebilir (nitekim AES anahtarıyla bilet üretimi ve önbelleğe alınması başarılı oldu), bu yüzden bu bulgu tekniği tamamen etkisiz kılmıyor, ama saldırganın önündeki engeli bir kademe yükseltiyor.

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ü, 164.312(d) – Kimlik Doğrulama
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-1 (Kimlik ve kimlik bilgisi yönetimi), PR.AC-7 (Kimlik doğrulama mekanizmaları)
CIS Controls	CIS 5 (Hesap Yönetimi), CIS 6 (Erişim Kontrol Yönetimi)

MITRE ATT&CK: T1558.001 (Steal or Forge Kerberos Tickets: Golden Ticket)

Sonuç

Golden Ticket, Active Directory’nin en köklü ve en tehlikeli ele geçirme tekniklerinden biridir. Çünkü tespit edilmesi zor, geçerliliği yıllarca sürebilir ve tek bir hash’in (krbtgt) kontrolüne dayanır. Bu, aynı zamanda savunmanın da neden bu kadar net olduğunu gösteriyor: krbtgt hash’ini korumak ve düzenli olarak döndürmek, tekniğin kökünü kurutur.

Serinin bir sonraki bölümünde, Golden Ticket’ın daha hedefli ve daha az gürültülü kuzeni olan Silver Ticket tekniğini yani yalnızca belirli bir hizmet hesabının hash’i ele geçirildiğinde neler olabileceğini inceleyeceğiz.