Active Directory ortamlarında güvenliğin temelini oluşturan kimlik doğrulama ve yetkilendirme mekanizmalarını, merkezinde yer alan Kerberos protokolünü ve bu protokole yönelik saldırı yüzeyini gerçek senaryolarla inceleyelim. KDC, TGT, Service Ticket, AS-REP Roasting, Kerberoasting, delegation modelleri ve Kerberos hardening adımlarına dair uçtan uca rehber.
Kimlik Doğrulama:
Kimlik doğrulama, bir kullanıcının, sistemin veya servisin iddia ettiği kimliğin doğruluğunu teyit etmeyi amaçlayan temel bir güvenlik sürecidir. Bu süreç, erişim kontrol mekanizmalarının ilk adımını oluşturur ve yalnızca doğrulanmış varlıkların sistem kaynaklarına erişebilmesini sağlar.
Authentication vs Authorization
Active Directory ortamlarında güvenlik, temelde iki ana kavram üzerine kuruludur:
Authentication (kimlik doğrulama)
Authorization (yetkilendirme).
Bu iki süreç, kullanıcıların sisteme güvenli şekilde giriş yapmasını ve yalnızca yetkili oldukları kaynaklara erişmesini sağlar. Kurumsal yapılarda bu mekanizmaların merkezinde ise Active Directory ve onunla entegre çalışan Kerberos protokolü bulunur.
Authentication, bir kullanıcının, cihazın veya servisin gerçekten iddia ettiği kimliğe sahip olup olmadığını doğrulama işlemidir. Active Directory ortamında bu süreç genellikle Kerberos aracılığıyla gerçekleştirilir. Kullanıcı domain’e giriş yaptığında, kimliğini doğrudan erişmek istediği servislere kanıtlamak yerine merkezi bir yapı olan Domain Controller’a başvurur. Domain Controller üzerinde çalışan Kerberos servisi, kullanıcının kimliğini doğrular ve ona bir oturum bileti (ticket) verir. Bu sayede kullanıcı her işlemde şifresini tekrar göndermek zorunda kalmaz ve ağ üzerinde parola dolaşımı engellenmiş olur.
Authentication tamamlandıktan sonra devreye authorization girer. Authorization, doğrulanmış bir kullanıcının hangi kaynaklara erişebileceğini ve hangi işlemleri yapabileceğini belirler. Active Directory ortamında bu kararlar genellikle kullanıcının ait olduğu gruplara, rolüne ve sistemde tanımlı güvenlik politikalarına göre verilir. Örneğin bir kullanıcı sisteme giriş yapabilir ancak yalnızca belirli klasörleri görüntüleme yetkisine sahip olabilir. Daha yetkili bir kullanıcı ise aynı sistemde yönetimsel işlemler gerçekleştirebilir. Bu farklılık authorization mekanizması sayesinde sağlanır.
Kimlik Doğrulama Protokolleri
NTLM (NT LAN Manager)
Kerberos
KERBEROS NEDİR?
Kerberos: Kerberos protokolünün ana amacı ağ üzerindeki kullanıcıların ve servislerin kimliğini güvenli bir şekilde doğrulamak ve bunu yaparken parola gibi hassas bilgilerin ağ üzerinde açık şekilde iletilmesini engellemektir.
Kerberos, kullanıcıların parolalarını doğrudan sunuculara göndermesini engeller. Bunun yerine kullanıcı, merkezi bir doğrulama sistemi olan KDC’den (Key Distribution Center) ticket (bilet) alır ve bu bileti kullanarak servislere erişir. Böylece parola hiçbir zaman ağda dolaşmaz ve credential theft riski ciddi şekilde azalır. Kerberos, “güvenilen bir üçüncü taraf” üzerinden çalışan, ticket tabanlı, simetrik kriptografiye dayalı bir kimlik doğrulama sistemidir.
Kerberos Bileşenleri
Kerberos protokolü 3 ana bileşenden oluşur
Client
Server
Key Distribution Center (KDC)
Client
Client, Kerberos kimlik doğrulama sürecini başlatan taraftır. Client, sisteme erişmek isteyen kullanıcıyı veya cihazı temsil eder.
Server
Server, erişilmek istenen kaynaktır. Bu bir dosya sunucusu, web sunucusu, veritabanı veya herhangi bir servis olabilir. Server, Kerberos ile korunan hedef servistir
Key Distribution Center (KDC)
Kerberos’un en kritik bileşenidir ve merkezi kimlik doğrulama otoritesidir. Active Directory ortamında KDC, Domain Controller üzerinde çalışır. 2 alt bileşenden oluşur
Authentication Server (AS)
Ticket Granting Server (TGS)
Authentication Service (AS)
Authentication Server (AS), Kerberos mimarisinde kimlik doğrulama sürecinin ilk aşamasıdır. AS’in temel görevi, istemciden gelen kimlik doğrulama isteğinde belirtilen kullanıcının Active Directory üzerinde mevcut olup olmadığını ve hesabın aktif bir durumda bulunup bulunmadığını kontrol etmektir. Bu aşamada kullanıcıya ait kimlik doğrulama verisinin geçerliliği de doğrulanır.
Ticket Granting Service (TGS)
Ticket Granting Server (TGS), Authentication Server tarafından verilen TGT’yi kullanan istemcilerin, erişmek istedikleri servisler için bilet almasını sağlar. TGS’in ilk görevi, istemcinin talep ettiği servisin geçerli bir Service Principal Name (SPN) ile Active Directory üzerinde tanımlı olup olmadığını kontrol etmektir (ör. CIFS, MSSQL, HTTP servisleri). Bu kontrolün ardından TGS, istemciye ilgili servis için bir Service Ticket (ST) üretir.
Kerberos Mimarisinin Temel Bileşenleri
KDC Database: KDC Database, Kerberos mimarisinde Key Distribution Center (KDC) üzerinde tutulan merkezi kimlik veritabanıdır. Bu veritabanı; Kerberos ortamında kimlik doğrulama ve bilet üretimi için gerekli olan tüm bilgileri içerir. İçerisinde tüm kullanıcı hesapları, tüm servis hesapları ve bunlara ait Service Principal Name (SPN) bilgileri ile her kullanıcı ve servise karşılık gelen gizli anahtarlar (secret keys) yer alır. Bu bilgiler, Kerberos tarafından ticket’ların oluşturulması ve doğrulanması sırasında kullanılır.
SPN: (Service Principal Name) Bir servisin Kerberos içindeki benzersiz kimliğidir Kerberos mimarisinde servislerin kimliklendirilmesi Service Principal Name (SPN) ile gerçekleştirilir. SPN, bir servisin domain içerisindeki benzersiz kimliğini temsil eder ve genellikle bir service account ile ilişkilendirilir. TGS, hangi servise bilet vereceğini bu SPN üzerinden belirler. Domain içerisindeki herhangi bir kullanıcı, herhangi bir SPN için service ticket talep edebilir. (Bu bilet, ilgili servis hesabının hash’ini içerdiğinden, saldırgan bu hash’i offline olarak kırmaya çalışır.)
PAC: (Privilege Attribute Certificate) Kullanıcının authorization bilgilerini taşıyan veri yapısıdır PAC, kullanıcının kimlik bilgileriyle birlikte yetkilerini, grup üyeliklerini ve diğer authorization verilerini içerir. Bu veri yapısı hem TGT hem de service ticket içerisinde bulunur. KDC yalnızca bileti üretir. yetkilendirme kararı, hedef servis tarafından yapılır. Bu durum, PAC manipulation gibi saldırılara kapı aralayabilir. Özellikle Golden Ticket saldırılarında, sahte PAC oluşturularak yüksek yetkiler elde edilebilir.
Mutual Authentication: mutual authentication, yani karşılıklı kimlik doğrulamadır. Bu mekanizma sayesinde yalnızca istemci sunucuya kendisini kanıtlamakla kalmayıp aynı zamanda sunucu da istemciye kimliğini doğrular. Bu çift yönlü doğrulama, özellikle Man-in-the-Middle saldırılarına karşı güçlü bir koruma sağlar ve Kerberos’u NTLM gibi tek yönlü kimlik doğrulama mekanizmalarından ayıran temel özelliklerden biridir.
Single Sign-On (SSO)
Kullanıcı sisteme bir kez giriş yaptıktan sonra, tekrar parola girmeden farklı servis ve kaynaklara erişebilir. Bu mekanizma, kullanıcının ilk girişinde elde ettiği Ticket Granting Ticket (TGT) sayesinde çalışır. TGT, istemcinin belleğinde saklanır ve sonraki tüm servis taleplerinde kullanılır. Bu durum, güvenlik açısından kritik bir risk de doğurur. Eğer bir saldırgan TGT’yi ele geçirirse, Pass-the-Ticket veya Golden Ticket gibi saldırılar gerçekleştirerek kullanıcının kimliğine bürünebilir.
krbtgt hesabı: Bu hesap, domain içerisindeki tüm Ticket Granting Ticket’ların imzalanmasından sorumludur. krbtgt hesabının hash’i, TGT’lerin şifrelenmesinde kullanılan anahtardır. Eğer bu hash bir saldırgan tarafından ele geçirilirse, saldırgan istediği gibi sahte TGT üretebilir. Bu durum Golden Ticket saldırısının temelini oluşturur ve saldırgana domain üzerinde neredeyse sınırsız yetki sağlar. Bu nedenle krbtgt hesabının parolasının periyodik olarak ve iki aşamalı şekilde değiştirilmesi kritik bir güvenlik önlemidir.
Protokol adımları
- KRB_AS_REQ: İstemci, KDC'den bir TGT (Ticket Granting Ticket) talep eder.
- KRB_AS_REP: KDC, istemciye TGT ve TGS oturum anahtarını gönderir.
- KRB_TGS_REQ: İstemci, sahip olduğu TGT'yi kullanarak belirli bir servis için bilet (Service Ticket) ister.
- KRB_TGS_REP: KDC, istemciye istediği servis için Service Ticket (TGS) gönderir.
- KRB_AP_REQ: İstemci, aldığı Service Ticket'ı kullanarak hedef servise erişim talebinde bulunur.
- KRB_AP_REP: Servis, istemciye kimliğini doğrulayarak karşılıklı kimlik doğrulama yanıtı gönderir (opsiyonel).
Adımları Tek Tek İnceleyelim
1. KRB_AS_REQ->Client -> KDC
Kullanıcı, Active Directory’ye kimliğini doğrulamak için KRB_AS_REQ isteği gönderir. Bu istekte kullanıcı adı bulunur ve zaman damgası kullanıcının parolasından türetilen anahtar ile şifrelenir. Bu aşamadaki istek KDC’nin Authentication Service (AS) bileşenine gönderilir. İstek içeriğini inceleyelim.
PA-ENC-TIMESTAMP = Şifreli zaman damgası = Authentication
PA-PAC-REQUEST = PAC talebi (kullanıcının yetkisi)
Cname = Kullanıcı adı = Login olan principal
ETYPE
Kerberos AS-REQ mesajında yer alan etype listesi, istemcinin desteklediği şifreleme algoritmalarını belirtir. Bu listede zayıf algoritmaların (özellikle RC4 ve DES) bulunması, KDC’nin bu algoritmaları seçmesi durumunda Kerberoasting gibi offline parola kırma saldırılarını mümkün hale getirir
Do not require Kerberos preauthentication
Client ilk isteği pre-auth olmadan gönderir, Eğer Do not require Kerberos preauthentication kapalıysa Error alırız (KRB5KDC_ERR_PREAUTH_REQUIRED) ve Client ikinci istekte timestamp ekler.
Do not require Kerberos preauthentication ayarı
Bu aşamadaki en kritik zafiyet pre-authentication kapalı hesaplardır. Eğer bir kullanıcı hesabında “Do not require Kerberos preauthentication” ayarı açıksa, saldırgan kullanıcı adına AS-REQ gönderip AS-REP cevabı alabilir. Bu durum AS-REP Roasting riskini doğurur.
Peki AS-REP Roasting Nedir?
AS-REP Roasting, Kerberos kimlik doğrulamasındaki ilk aşamada (AS → Authentication Service) oluşan bir zafiyetten yararlanılarak yapılan bir saldırıdır. Bu saldırı yalnızca “Do not require Kerberos preauthentication” ayarı AÇIK olan (preauth kapalı olan) kullanıcı hesaplarında mümkündür.
Pre-auth: AÇIK
Pre-authentication açık olduğunda, kullanıcı Kerberos akışının ilk adımında, yani AS (Authentication Service) aşamasında KDC’ye bir istek gönderir. Bu isteğin en önemli özelliği, kullanıcının kendi parolasından türetilmiş bir anahtarla şifrelenmiş zaman damgası (timestamp) içermesidir.
Bu, kullanıcının parolasını doğrudan göndermeden “ben parolayı biliyorum” demesinin kriptografik yoludur. KDC bu şifreli veriyi çözmeye çalışır. Eğer çözebilirse, kullanıcının doğru parolaya sahip olduğu anlaşılır ve kimlik doğrulama başarılı kabul edilir. Ardından KDC, kullanıcıya bir AS-REP mesajı gönderir ve bu mesaj içinde TGT (Ticket Granting Ticket) bulunur. YANİİİ, KDC, kullanıcıya TGT vermeden önce kullanıcının kimliğini doğrulamış olur.
Pre-auth KAPALI
Pre-authentication kapalı olduğunda ise bu güvenlik katmanı tamamen ortadan kalkar. Kullanıcı AS’e istek gönderirken artık şifreli zaman damgası göndermek zorunda değildir. Bu durumda KDC, kullanıcının gerçekten parolaya sahip olup olmadığını doğrulayamaz. Buna rağmen, sistem yapılandırması gereği KDC kullanıcı adına bir AS-REP yanıtı üretir ve gönderir. Bu yanıtın kritik özelliği, içeriğinin (özellikle session key kısmının) kullanıcının parola türevi anahtarıyla şifrelenmiş olmasıdır. Yani KDC doğrulama yapmadan şifreli bir cevap üretir.
Sonuç olarak pre-authentication kapalıysa AS, kullanıcıyı doğrulamadan AS-REP döner. Saldırgan bu paketi ele geçirirse, içindeki şifreli veriyi offline olarak kırabilir. (Kapalı kalmak zorunda ise güçlü şifreler kullanılmalıdır.)
2. KRB_AS_REP->KDC -> Client
TGS-REQ mesajı, istemcinin daha önce aldığı TGT’yi kullanarak belirli bir servis için service ticket talep ettiği aşamadır. Bu mesaj içerisinde yer alan PA-TGS-REQ alanı, istemcinin TGT’ye bağlı session key’e sahip olduğunu kanıtlayan authenticator’ı içerir. Hedef servis (sname) ve desteklenen şifreleme türleri (etype) bu aşamada belirlenir ve Kerberoasting gibi saldırılar bu süreçte ortaya çıkar.
Bu aşamadaki en kritik nokta krbtgt hesabıdır. Çünkü TGT’lerin güvenliği krbtgt hesabının anahtarına bağlıdır. Eğer krbtgt hash’i ele geçirilirse saldırgan sahte TGT üretebilir.
İstek içeriğini inceleyelim
Kdc-options
kdc-options alanı, biletlerin davranışlarını belirleyen önemli flagler içerir. Bu flaglere bakarak sistemde delegation kullanımı, biletlerin ne kadar süre geçerli olduğu ve yetkilendirme süreçleri hakkında fikir edinebiliriz.
Forwardable: True = Ticket başka servislere taşınabilir (unconstrained / constrained delegation saldırıları)
Forwarded: False = Ticket başka yerden forward edilmemiş
Renewable: True = Ticket süresi dolsa bile yenilenebilir
Proxiable / proxy: False = Proxy delegation yok
3. KRB_TGS_REQ ->Client -> KDC
Bu aşamada client, sahip olduğu TGT’yi kullanarak belirli bir servis için Service Ticket ister. Bu aşamadaki en önemli zafiyet Kerberoasting riskidir. Domain içindeki normal bir authenticated user bile SPN atanmış servis hesapları için TGS isteyebilir. KDC servis bileti üretir ve bu biletin bir kısmı servis hesabının anahtarıyla şifrelenir. zayıf parolaya sahip servis hesapları biletleri offline kırılabilir.
İstek içeriğini inceleyelim
TGS-REQ = login oldum şimdi şu servise erişmek istiyorum. Bana onun için bir bilet ver.
Sname = Hedef servis
Till = İstenen ticket süresi
Etype = Kullanılabilecek şifreleme türleri
4. KRB_TGS_REP->KDC -> Client
Bu aşamada KDC, client’a hedef servis için Service Ticket döner. Client bu ticket’ı hedef servise sunacaktır. Ticket, hedef servisin anahtarıyla şifrelenmiştir.
TGS-REP mesajı, istemcinin talep ettiği servis için oluşturulan service ticket’ı içerir ve Kerberos güvenlik modelinde en kritik aşamalardan biridir. Bu mesaj içerisindeki şifreli ticket verisi, hedef servisin anahtarı ile korunur ve istemci tarafından okunamaz.
Kerberoasting zafiyeti tam olarak bu adımda ortaya çıkar. Çünkü TGS, herhangi bir domain kullanıcısına, yetkisi olup olmadığını kontrol etmeden, istenen servise ait biletleri üretip teslim eder.
TGS-REP
Saldırganın şifre kırabileceği veri burada oluşur
Peki Kerberoasting Nedir?
Kerberos mimarisinde TGS (Ticket Granting Service) aşaması, kimlik doğrulama ile yetkilendirme arasındaki ayrımın en net görüldüğü noktadır. Kullanıcı, daha önce aldığı TGT ile KDC’ye başvurarak belirli bir servis için Service Ticket (TGS) talep eder. Bu aşamada KDC’nin yaptığı temel kontrol şudur: “Bu TGT geçerli mi ve bu isteği yapan kişi gerçekten bu TGT’nin sahibi mi?”
Ancak kritik bir nokta vardır: TGS, servise erişim yetkisini kontrol etmez. Yani KDC, kullanıcının o servise erişmeye gerçekten yetkili olup olmadığını doğrulamaz. Bu kontrol, daha sonra servisin kendisi tarafından yapılır. KDC’nin görevi yalnızca geçerli bir kimlik doğrulama sonucuna dayanarak ticket üretmektir.
Bu ticket’ın kritik özelliği şudur: ticket içindeki bir bölüm, hedef servisin hesabına ait parola türevi anahtar ile şifrelenmiştir. Yani KDC aslında saldırgana şu veriyi verir: Bu servis hesabına ait, parolasıyla şifrelenmiş bir veri.
Bu veri doğrudan parola değildir, ancak offline olarak brute-force veya sözlük saldırısına tabi tutulabilir. Saldırgan bu ticket’ı alır, kendi makinesinde analiz eder ve farklı parola tahminleri deneyerek şifreyi kırmaya çalışır. Bu sürece offline cracking denir ve en tehlikeli yönü, domain controller ile herhangi bir etkileşim gerektirmemesidir. Yani bu aşamada saldırganın aktiviteleri çoğu zaman tespit edilmesi zor hale gelir. Eğer servis hesabı zayıf bir parolaya sahipse veya eski şifreleme algoritmaları kullanılıyorsa, saldırgan kısa sürede parolayı elde edebilir. Daha da kritik olan, bu servis hesabının yüksek yetkilere sahip olmasıdır. Örneğin servis hesabı Domain Admin grubuna üyeyse, bu hesap ele geçirildiğinde saldırgan doğrudan domain kontrolü elde edebilir.
…
Kerberoasting’in Mümkün Olmasının Sebepleri
Kerberos TGS, çoğu durumda servis erişim yetkisini doğrulamadan service ticket üretir.
Authenticated herhangi bir domain kullanıcısı SPN’e sahip servisler için TGS talebinde bulunabilir.
TGS içerisindeki service ticket, servis hesabının NT hash’i/anahtarı kullanılarak şifrelenir.
Saldırgan elde ettiği ticket’ı offline olarak crack ederek servis hesabının parolasını ele geçirmeye çalışır.
Kerberos şifreleme algoritmaları
Active Directory ortamlarında Kerberos protokolü, kimlik doğrulama süreçlerini bilet tabanlı bir yapıyla güvenli hale getirdiğini biliyoruz. Bu biletlerin şifrelenmesinde RC4, AES128 ve AES256 algoritmaları kullanıyoruz
Kerberos’ta kullanılan şifreleme algoritmaları sistem güvenliğini doğrudan etkiler Modern ortamlarda yalnızca AES tabanlı algoritmalar kullanılmalıdır. Zayıf algoritmaların aktif olması, parola kırma ve yetki yükseltme saldırılarına zemin hazırlar.
DES (Data Encryption Standard)
DES, Kerberos’un eski sürümlerinde kullanılan şifreleme algoritmasıdır. 56-bit anahtar yapısına sahip olduğu için günümüzde güvenli kabul edilmez. Düşük anahtar uzunluğu nedeniyle brute-force saldırılarına karşı savunmasızdır
RC4-HMAC
RC4-HMAC, uzun yıllar boyunca Active Directory ortamlarında yaygın olarak kullanılmıştır. NTLM hash tabanlı çalışır ve özellikle geriye dönük uyumluluk amacıyla tercih edilmiştir. Ancak Kerberoasting saldırılarında sıkça hedef alınır. Özellikle zayıf servis account parolaları kullanıldığında ciddi güvenlik riski oluşturur.
AES128-CTS-HMAC-SHA1–96
AES128, Kerberos’un daha modern ve güvenli şifreleme yöntemlerinden biridir. AES-128 algoritmasını kullanır ve RC4’e göre çok daha güçlü bir güvenlik sağlar. Windows Server 2008 ve sonrası sistemlerde desteklenmektedir.
AES256-CTS-HMAC-SHA1–96
AES256, günümüzde Active Directory ortamlarında önerilen en güvenli Kerberos şifreleme algoritmalarından biridir. AES-256 şifreleme kullanır ve güçlü anahtar yapısı sayesinde brute-force ve kriptografik saldırılara karşı oldukça dayanıklıdır.
Kerberos etype:Encryption Type
etype 23 -> RC4-HMAC
etype 17 -> AES128
etype 18 -> AES256
- AES256 ve AES128 algoritmaları aktif tutulmalıdır
- RC4 desteği mümkünse devre dışı bırakılmalıdır
- DES algoritmaları tamamen kapatılmalıdır
- Domain policy üzerinden desteklenen algoritmalar sınırlandırılmalıdır
kerberos AES Uyumluluğu ve Trust Yapılarında Şifreleme Yönetimi:
Bir domain ile Trust ilişkisi kurulan başka bir domain arasında Kerberos trafiğinin sağlıklı akabilmesi için her iki tarafın da ortak bir şifreleme algoritmasında mutabık kalması şarttır.
Uyumsuzluk durumunda Kerberos biletleri oluşturulamaz ve sistem daha az güvenli olan NTLM protokolüne fallback yapabilir veya erişim tamamen kesilebilir.
Trust edilen tarafın desteklediği şifreleme türleri msDS-SupportedEncryptionTypes özniteliği (attribute) ile belirlenir. Eğer bu değer tanımlanmamışsa, sistem geriye dönük uyumluluk adına yalnızca RC4 kullanmaya çalışır.
Arayüz üzerinden kontrol
Active Directory Users and Computers -> Advanced Features -> Properties-> Attribute Editor
PowerShell üzerinden control
24 -> AES128 + AES256 28 -> RC4 + AES 4 -> sadece RC4 0 -> Attribute explicit olarak ayarlanmamış.Sistem default davranışa geçer.Default: RC4 kullanılabilir, AES olsa bile fallback olabilir.
msDS-SupportedEncryptionTypes özniteliğinin not set olması, Active Directory’nin bu Trust ilişkisi için varsayılan (legacy) davranış sergilemesine neden olur. Sistem varsayılan olarak RC4-HMAC algoritmasına yönelir.
-Risk: RC4 güvensiz kabul edilmektedir brute-force veya Kerberoasting gibi saldırılara karşı AES’e oranla çok daha savunmasızdır.
-Güncel Windows 10/11 ve Server 2019/2022 sürümleri, güvenlik politikaları gereği RC4'ü reddedebilir. Bu da iki domain arasındaki kaynak erişiminde beklenmedik kimlik doğrulama hatalarına yol açar.
Ticket Saldırıları
Golden Ticket
krbtgt hesabının hash’i ele geçirilir ve bu hash ile sahte bir TGT (Ticket Granting Ticket) oluşturulur. Saldırgan istediği kullanıcıyı (örneğin Domain Admin) taklit edebilir ve domain içindeki tüm servislere erişim sağlayabilir. Domain controller’a bağımlılık minimumdur ve genelde kalıcı (persistence) erişim için kullanılır.
Silver Ticket
Bir servis hesabının (örneğin CIFS, HTTP, MSSQL) hash’i ele geçirilir ve o servise özel sahte bir service ticket üretilir. Bu sayede yalnızca hedef servise erişim sağlanır. Domain controller ile iletişim gerektirmediği için tespit edilmesi daha zordur ve daha “sessiz” çalışır.
Diamond Ticket
Saldırgan önce geçerli bir Kerberos TGT elde eder, ardından bu ticket’ın içeriğini (özellikle yetkileri/PAC bilgisini) değiştirerek daha yüksek yetkili hale getirir. Tamamen sahte üretmek yerine mevcut bileti manipüle ettiği için daha gerçekçi görünür ve tespiti daha zordur.
Pass the hash
Pass-the-Hash, saldırganın kullanıcının parolasını bilmeden, sadece NTLM hash’ini kullanarak kimlik doğrulaması yapmasıdır. Normalde bir kullanıcı sisteme giriş yaparken parola girer. NTLM protokolünde ise bu parola hash’e çevrilir ve doğrulama bu hash üzerinden yapılır. Eğer saldırgan bu hash’i ele geçirirse, parolayı çözmesine gerek kalmadan doğrudan bu hash ile başka sistemlere bağlanabilir. Bu teknik tamamen NTLM tabanlı kimlik doğrulama ile çalışır. Yani Kerberos değil, NTLM kullanılan ortamlarda geçerlidir.
✓ NTLM kullanımı mümkün olduğunca kapatılmalı✓ NTLMv1 kesinlikle devre dışı bırakılmalı✓ Sadece NTLMv2 kullanımına izin verilmeli
Pass the ticket
Pass-the-Ticket ise Kerberos ortamlarında kullanılan bir tekniktir. Burada saldırgan, bir kullanıcının Kerberos ticket’ını (TGT veya service ticket) ele geçirir ve bu ticket’ı kullanarak o kullanıcı gibi sisteme erişir. Kerberos’ta kimlik doğrulama parola ile değil, ticket (bilet) ile yapılır. Eğer saldırgan bu ticket’ı elde ederse, kullanıcı parolasına veya hash’ine ihtiyaç duymadan doğrudan erişim sağlayabilir.
✓ Kerberos’ta AES encryption kullanılmalı, RC4 kapatılmalı ✓ Kerberos pre-authentication zorunlu hale getirilmeli ✓ Kerberos ticket süreleri (TGT lifetime) düşürülmeli
NTLM Fallback Durumu
NTLM fallback, bir ortamda öncelikli olarak Kerberos kullanımı söz konusu olsa bile bazı nedenlerle Kerberos kimlik doğrulaması gerçekleştirilemediğinde sistemin otomatik olarak NTLM protokolüne geri dönmesi durumudur.
NTLM Fallback Durumları
Kerberos, servis kimliklerini belirlemek için Service Principal Name (SPN) kullanır ve bu SPN genellikle hostname üzerinden çözülür. Eğer istemci hedef sistemi IP adresi ile çağırırsa veya DNS çözümlemesi başarısız olursa, SPN eşleşmesi yapılamaz. Bu durumda Kerberos ticket üretilemez ve sistem NTLM’e fallback yapar.
SPN yapılandırmasının eksik veya hatalı olması da Kerberos’un devre dışı kalmasına neden olur. Bir servise ait SPN Active Directory’de doğru şekilde tanımlanmamışsa, Key Distribution Center (KDC) hangi hesap için service ticket oluşturacağını belirleyemez. Bu durumda Kerberos başarısız olur ve kimlik doğrulama NTLM üzerinden gerçekleşir. Özellikle IIS, MSSQL gibi servislerde SPN hataları NTLM fallback’in en sık görülen nedenlerindendir.
Farklı domain’ler arasında çalışan sistemlerde trust ilişkilerinin eksik veya hatalı olması da bu duruma yol açabilir. Eğer istemci ile hedef servis arasında uygun bir güven ilişkisi yoksa veya authentication path doğru şekilde oluşturulamıyorsa, Kerberos üzerinden ticket alınamaz. Bu durumda sistem alternatif olarak NTLM’i kullanır. Bu durum, özellikle yanlış yapılandırılmış inter domain trust senaryolarında ortaya çıkar
Kerberos’un zaman hassasiyeti de önemli bir faktördür. Protokol, replay saldırılarını önlemek amacıyla zaman senkronizasyonuna dayanır ve istemci ile domain controller arasındaki saat farkı belirli bir toleransın üzerine çıktığında kimlik doğrulama reddedilir. Böyle bir durumda Kerberos başarısız olur ve sistem NTLM’e fallback yapabilir.
Kullanılan uygulamanın veya servisin Kerberos’u desteklememesi ya da yanlış yapılandırılmış olması da NTLM kullanımına neden olur. Özellikle legacy uygulamalar, Kerberos negotiation sürecini başlatamaz veya yalnızca NTLM destekler. Bu da doğrudan NTLM ile kimlik doğrulama yapılmasına yol açar.
Group Policy ayarları veya güvenlik konfigürasyonları Kerberos kullanımını sınırlayabilir ya da NTLM’i açık bırakabilir. Bu durumda Kerberos başarısız olduğunda otomatik olarak NTLM devreye girer.
NTLM Policy İncelemesi Yapalım
Computer Configuration-> Policies-> Windows Settings-> Security Settings-> Local Policies-> Security Options
1. Policy
[Network security: LAN Manager authentication level]
Send LM & NTLM response -> Fallback riski
Send NTLMv2 response only. Refuse LM & NTLM -> Güvenilir
2. Policy
[Network security: Restrict NTLM: Audit NTLM authentication]
Enable -> NTLM fallback log’larını görmek
3. Policy
[Network security: Restrict NTLM: Incoming NTLM traffic]
Allow -> NTLM serbest (fallback olur)
Deny -> NTLM engellenir
4. Policy
[Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers ]
Allow -> fallback olabilir
Deny -> NTLM kullanımını keser
Double hop problemi nedir?
Double hop problemi bir kullanıcının kimlik bilgilerinin ilk sunucudan ikinci sunucuya varsayılan olarak iletilememesi problemidir.
çok katmanlı yapılardan örnek: (kullanıcı -> web sunucusu -> SQL sunucusu)
Çözüm: Delegation
Delegation Nedir
Kerberos delegation mekanizmaları ise servislerin kullanıcı adına başka servislere erişebilmesini sağlar.
Delegation sayesinde servisler kullanıcı adına Kerberos ticket alarak diğer servislere erişebilir. Ancak yanlış yapılandırılmış delegation, özellikle Unconstrained Delegation, saldırganların ticket çalmasına, kullanıcı impersonation yapmasına ve lateral movement ile yetki yükseltmesine neden olabilir
Delegation Türleri
1. Unconstrained Delegation
Unconstrained delegation en eski ve en riskli yöntemdir. Bu modelde, bir servis kullanıcının TGT’sini alarak herhangi bir servise erişebilir. Eğer bu servis ele geçirilirse, saldırgan kullanıcıların TGT’lerini elde ederek ciddi yetki yükseltme ve lateral movement gerçekleştirebilir.
2. Constrained Delegation
riski azaltmak için geliştirilmiştir ve yalnızca belirli servislerle sınırlı erişime izin verir.
3. Resource-Based Constrained Delegation (RBCD)
Bu modelde kontrol, kaynak tarafına verilmiştir. Hedef sistem, hangi hesapların kendi adına işlem yapabileceğini belirler. Ancak bu yapı da yanlış yapılandırıldığında, özellikle msDS-AllowedToActOnBehalfOfOtherIdentity attribute’ünün kötüye kullanılmasıyla saldırganların yetki yükseltmesine olanak tanıyabilir.
---
1. Unconstrained Delegation
Unconstrained Delegation: Unconstrained Delegation, Kerberos mimarisinde bir sistemin kendisine bağlanan kullanıcıların TGT (Ticket Granting Ticket) biletlerini alabilmesine izin veren en geniş delegasyon modelidir.
Bu yapılandırmaya sahip bir sunucuya bir kullanıcı (özellikle yüksek yetkili bir kullanıcı) bağlandığında, kullanıcının Kerberos bileti bellekte tutulur. Eğer bu sistem ele geçirilirse, saldırgan bu biletleri elde ederek kullanıcı adına başka sistemlere erişebilir. Özellikle domain yöneticisinin bu tür bir sunucuya bağlanması durumunda, elde edilen bilet ile yetki yükseltme ve domain içinde yatay hareket (lateral movement) mümkün hale gelir.
2. Constrained Delegation
Constrained Delegation daha kontrollü bir modeldir ve bir servisin yalnızca belirli hedef servislere kullanıcı adına erişmesine izin verir.
Bu yapılandırma, Kerberos’un S4U (Service for User) mekanizmaları olan S4U2Self ve S4U2Proxy ile çalışır. Servis, önce kullanıcı adına bir ticket alır (S4U2Self), ardından bu ticket’ı kullanarak yalnızca izin verilen servisler için erişim talep eder (S4U2Proxy).
Ancak bu yetkiye sahip bir hesap ele geçirilirse, saldırgan bu mekanizmayı kullanarak yetkili kullanıcıları taklit edebilir ve izin verilen servisler üzerinde yetki elde edebilir.
Her ne kadar unconstrained delegation’a göre daha güvenli olsa da, yanlış yapılandırıldığında kritik sistemlere erişim sağlayabilecek bir saldırı vektörü oluşturur.
3.Resource-Based Constrained Delegation
Gerçekleştirdiğimiz yapılandırmada
THENOOB bilgisayarı → hedef (resource) sistem
CLIENT01 bilgisayarı → delegation yetkisi verilen principal
Bu yapılandırma sonucunda, CLIENT01 sistemi Kerberos delegation mekanizmalarını (S4U2Self ve S4U2Proxy) kullanarak belirli kullanıcılar adına service ticket talep edebilir ve bu ticket’lar aracılığıyla THENOOB üzerindeki servislere erişim sağlayabilir. Bu süreçte kullanıcı parolası kullanılmaz; kimlik doğrulama tamamen Kerberos ticket mekanizması üzerinden gerçekleştirilir.
Bu durumun güvenlik açısından kritik olmasının temel nedeni,
bu yetkinin doğrudan impersonation (kimliğe bürünme) kabiliyeti sağlamasıdır. Eğer delegation yetkisine sahip olan sistem (örneğin CLIENT01) bir saldırgan tarafından ele geçirilirse, saldırgan bu sistem üzerinden farklı kullanıcılar adına Kerberos ticket üreterek hedef sistemlere erişebilir. Bu noktada saldırganın başarısı, hedeflenen kullanıcının özelliklerine bağlıdır. Örneğin yüksek yetkili bir kullanıcı (Domain Admin gibi) impersonate edilirse, bu durum doğrudan privilege escalation ve lateral movement ile sonuçlanır.
RBCD’nin özellikle tehlikeli olmasının bir diğer sebebi,
kontrolün klasik delegation modelinin aksine hedef sistemde bulunmasıdır. Geleneksel constrained delegation’da hangi servisin nereye erişebileceği source tarafında tanımlanırken, RBCD’de bu kontrol target tarafına verilmiştir. Bu durum, hedef sistem üzerinde yanlış yapılandırılmış Access Control List (ACL) izinleri varsa, düşük yetkili bir kullanıcının bile bu attribute’u değiştirebilmesine ve kendisini yetkili bir principal olarak ekleyebilmesine yol açabilir. Bu da RBCD’yi modern Active Directory saldırılarında sık kullanılan bir teknik haline getirir.
bu mekanizma tamamen Kerberos protokolü üzerinden çalıştığı için, NTLM tabanlı saldırılara karşı alınmış önlemleri by-pass edebilir. Üstelik Kerberos trafiği çoğu zaman “normal” kabul edildiğinden, bu tür aktivitelerin tespiti daha zor olabilir. Event log’larda yalnızca standart ticket talepleri (örneğin 4769) görülür ve bu durum çoğu zaman anomali olarak işaretlenmez.
Kerberos’ta trust ilişkisi
Kerberos mimarisinde trust (güven) ilişkileri, farklı güvenlik sınırları arasında kimlik doğrulamanın sürdürülebilir ve güvenli şekilde yapılmasını sağlayan temel yapılardır. Özellikle büyük ölçekli kurumsal ortamlarda, tek bir domain ya da realm yeterli olmadığında, kullanıcıların farklı sistemlere erişebilmesi bu trust mekanizmaları sayesinde mümkün olur.
inter-domain trust
Cross-realm authentication
transitive/non-transitive trust
Inter-domain Trust
Inter-domain trust, farklı domain’ler arasında kurulan güven ilişkisidir ve kullanıcıların başka bir domain’deki kaynaklara erişebilmesini sağlar. Bu yapı, domain controller’lar arasında paylaşılan güven ilişkileri ve kriptografik anahtarlar üzerinden çalışır. Bir kullanıcı, kendi domain’inde kimlik doğrulaması yaptıktan sonra, hedef domain’e erişmek istediğinde bu trust ilişkisi sayesinde yönlendirilir ve gerekli service ticket’ı alır. Parent-child domain yapılarında bu trust ilişkisi varsayılan olarak otomatik oluşturulur.
Cross-realm authentication
Farklı Kerberos realm’leri arasında kimlik doğrulama yapılmasını sağlayan mekanizmadır.
Her realm kendi Key Distribution Center (KDC)’ına sahip bağımsız bir güvenlik alanıdır. Bir realm’deki kullanıcı, başka bir realm’deki bir servise erişmek istediğinde doğrudan hedef realm’den service ticket alamaz. Bunun yerine, iki realm arasında önceden kurulmuş bir güven ilişkisi bulunur.
Kullanıcı önce kendi realm’inden bir Ticket Granting Ticket (TGT) alır, ardından bu TGT kullanılarak hedef realm için bir referral TGT elde edilir. Bu referral süreci, istemcinin hedef realm’in KDC’sine yönlendirilmesini sağlar. Son aşamada kullanıcı, hedef realm’den gerekli service ticket’ı alarak erişimi tamamlar. Bu yapı, farklı organizasyonlar veya federated sistemler arasında güvenli erişim sağlamak için kullanılır. Ancak bir realm’in ele geçirilmesi durumunda, trust ilişkisi üzerinden diğer realm’lere sıçrama riski doğabilir.
Transitive Trust
Trust ilişkilerinin en kritik özelliklerinden biri geçişkenliktir (transitivity). Transitive trust, bir domain’in güvendiği başka bir domain’in de güvendiği üçüncü bir domain’e dolaylı olarak güvenmesi anlamına gelir. Örneğin bir domain başka bir domain’e, o domain de üçüncü bir domain’e güveniyorsa, bu güven ilişkisi zincirleme şekilde genişler. Bu yaklaşım, özellikle büyük organizasyonlarda yönetimi kolaylaştırır çünkü her domain için ayrı ayrı trust tanımlamaya gerek kalmaz. Active Directory Forest yapılarında bu tür trust ilişkileri varsayılan olarak geçişkendir. Ancak bu kolaylık, aynı zamanda ciddi bir güvenlik riski oluşturur. Zincirdeki herhangi bir domain’in compromise edilmesi, tüm güven ilişkisi boyunca ilerleyen saldırılara zemin hazırlayabilir.
Non-transitive Trust
Buna karşılık non-transitive trust, yalnızca iki domain arasında geçerli olan ve başka domain’lere genişlemeyen bir güven modelidir. Bu yapı, trust ilişkisini sınırlı tutarak daha kontrollü bir erişim sağlar. Güven yalnızca tanımlanan iki taraf arasında geçerlidir ve üçüncü bir domain’e otomatik olarak aktarılmaz. Bu yaklaşım, yüksek güvenlik gereksinimi olan ortamlarda tercih edilir çünkü saldırı yüzeyini daraltır. Ancak yönetimsel açıdan daha fazla konfigürasyon gerektirir ve esneklik açısından transitive trust’a göre daha sınırlıdır.
Kerberos Hardening
Maximum Lifetime for Service Ticket
Bu ticket’ın maksimum geçerlilik süresi, potansiyel bir güvenlik ihlalinde saldırganın erişim süresini doğrudan etkiler. Eğer service ticket süresi uzun yapılandırılmışsa, kullanıcı hesabı devre dışı bırakılsa veya yetkileri değiştirilse bile saldırgan mevcut ticket’ı kullanarak servise erişmeye devam edebilir. Bu durum özellikle lateral movement senaryolarında kritik risk oluşturur.
Daha kısa service ticket süreleri, yetki değişikliklerinin daha hızlı uygulanmasını sağlar ve ele geçirilmiş kimlik bilgilerinin operasyonel kullanım süresini sınırlar. Ancak çok kısa süreler KDC yükünü artırabilir. Güvenlik ve performans dengesi gözetilerek yapılandırma yapılmalıdır.
Enforce User Logon Restrictions
Bu ayar etkinleştirildiğinde, KDC her service ticket talebinde kullanıcının güncel yetkilerini ve logon kısıtlamalarını yeniden kontrol eder. Bu mekanizma, statik yetkilendirme yerine dinamik doğrulama sağlar.
Bu ayar devre dışı bırakılırsa, kullanıcıya daha önce verilmiş yetkiler, kaldırılmış olsa dahi ticket süresi boyunca geçerli kalabilir. Özellikle privilege revocation senaryolarında bu ciddi bir zafiyet oluşturur.
Maximum Lifetime for User Ticket (TGT)
Ticket Granting Ticket (TGT), kullanıcının domain içerisinde yeni service ticket’lar almasını sağlayan ana kimlik doğrulama token’ıdır. TGT’nin geçerlilik süresi ne kadar uzunsa, ele geçirilmesi durumunda saldırganın operasyon süresi de o kadar uzar. Uzun TGT süreleri, özellikle Golden Ticket veya Pass-the-Ticket saldırılarında ciddi risk oluşturur. Kullanıcı hesabı disable edilse bile, geçerli bir TGT ile belirli süre boyunca yeni service ticket alınabilir.
Kısa TGT süreleri güvenliği artırırken, çok agresif kısaltma KDC üzerinde ek yük oluşturabilir. Bu nedenle süre dikkatli bir şekilde alınarak belirlenmelidir.
Maximum Tolerance for Computer Clock Synchronization
Kerberos, replay saldırılarını önlemek için zaman damgası (timestamp) mekanizması kullanır. Bu nedenle istemci ve Domain Controller saatlerinin senkron olması zorunludur.
Zaman toleransı çok yüksek ayarlanırsa replay saldırılarının uygulanabileceği pencere genişler. Çok düşük ayarlanırsa ise üretim ortamında kimlik doğrulama hataları artabilir.
Maximum Lifetime for User Ticket Renewal
TGT’nin yenilenebilirlik süresi, bir kullanıcının sürekli oturum deneyimini etkiler. Ancak güvenlik perspektifinden bakıldığında, bu süre aynı zamanda persistence riskini belirler. Ele geçirilmiş bir TGT, renewal süresi boyunca yenilenebilir ve uzun süreli erişim sağlayabilir. Bu durum kalıcılık tekniklerinde kullanılır.
Renewal süresi, dikkatli bir şekilde belirlenmelidir. Uzun süreli yenilenebilirlik saldırganlar için avantaj sağlar.
Kriptografik Ayarlar (Encryption Type Hardening)
Zayıf veya eski algoritmalar (özellikle DES ve RC4) aktif bırakıldığında, Kerberoasting ve offline parola kırma saldırıları kolaylaşır.
yalnızca AES128 ve AES256 algoritmalarının kullanılması önerilir. RC4’nin devre dışı bırakılması, NTLM hash tabanlı cracking riskini azaltır.
Service Account Güvenliği
Servis hesapları, Kerberos saldırılarında en sık hedeflenen bileşenlerdir. Özellikle manuel oluşturulmuş, uzun süre parola değişmemiş ve geniş yetkilere sahip servis hesapları yüksek risk taşır. Zayıf parolalı servis hesapları Kerberoasting ile kolayca ele geçirilebilir. SPN yanlış yapılandırmaları da saldırı yüzeyini artırır.
Group Managed Service Account (gMSA) kullanımı, otomatik parola rotasyonu ve minimal yetki prensibi, servis hesap güvenliğini ciddi ölçüde artırır. Servis hesapları Tier modeline uygun şekilde konumlandırılmalıdır.
Account Lockout Policies
Brute-force ve password spraying saldırılarını sınırlandırmak için hesap kilitleme politikaları kritik rol oynar. Ancak bu politika yanlış yapılandırılırsa, saldırganlar Denial of Service oluşturabilir.
Çok düşük eşik değeri, servis kesintilerine neden olabilir. Çok yüksek eşik değeri ise brute force riskini artırır.
Kilitleme politikaları tek başına yeterli değildir,izleme ile desteklenmelidir.
Ticket Forwarding ve Delegation Ayarları
Delegation mekanizması, bir servisin başka bir servis adına kimlik doğrulama yapmasını sağlar. Ancak yanlış yapılandırılmış delegation, domain compromise ile sonuçlanabilir.
Unconstrained delegation, saldırganın TGT toplamasına ve domain içerisinde serbest hareket etmesine olanak tanır.
Constrained delegation ve özellikle Resource-Based Constrained Delegation (RBCD), daha kontrollü ve güvenli bir model sunar.
➔ Delegation kullanımının minimuma indirilmesi gerekir.
Disable NTLM (Kerberos Enforced Environment)
NTLM açık bırakıldığında, Kerberos ortamı dahi downgrade saldırılarına açık hale gelir. NTLM relay ve Pass-the-Hash teknikleri hala yaygın olarak kullanılmaktadır.
Kerberos enforced bir mimari oluşturulmadıkça, NTLM üzerinden sistemlere sızılabilir.
NTLM’nin aşamalı olarak devre dışı bırakılması ve yalnızca Kerberos’un kullanılması önerilmektedir.
Protected Users Group
Protected Users grubu, yüksek ayrıcalıklı hesapların ek güvenlik katmanları ile korunmasını sağlar. Bu gruba dahil edilen hesaplar için NTLM, zayıf şifreleme ve delegation yasaklanır.
Ayrıca TGT süreleri kısaltılır ve credential caching engellenir. Bu özellikler, özellikle Domain Admin ve Tier-0 hesaplar için büyük güvenlik avantajı sağlar.
Yüksek ayrıcalıklı hesapların bu gruba dahil edilmesi, credential theft riskini azaltır.
Authentication Policies & Silos
Authentication Policies ve Authentication Silos, hangi hesapların hangi makinelerde oturum açabileceğini kontrol eder. Bu yapı, tiered administration modelinin teknik uygulamasıdır.
Bu mekanizma sayesinde yönetici hesapları yalnızca belirli yönetim workstation’larında kullanılabilir. Böylece kimlik bilgileri düşük güvenlikli sistemlerde expose olmaz. Bu yapılandırma, lateral movement riskini azaltır.
Pre-Authentication Enforcement
Kerberos pre-authentication mekanizması, kullanıcının parola bilgisi olmadan AS-REP alınmasını engeller. Eğer bir hesapta pre-auth devre dışı bırakılmışsa, AS-REP Roasting saldırısına açık hale gelir.
Tüm kullanıcı hesaplarında pre-auth zorunlu olmalıdır. Pre-auth disabled hesaplar düzenli olarak denetlenmelidir.
KRBTGT Hesabı ve Parola Rotasyonu
KRBTGT hesabı, domain içindeki tüm TGT’leri imzalayan kritik hesap olduğundan Bu hesabın parolası değiştirilmeden kalırsa, Golden Ticket saldırıları uzun süre geçerli olabilir.
Saldırgan tarafından KRBTGT hash’i elde edilmişse, parola değiştirilmedikçe üretilen sahte TGT’ler geçerli kalır.
- KRBTGT parolasının periyodik olarak değiştirilmelidir
- Incident sonrası çift reset uygulanması (iki kez parola değişimi)
Replikasyon problemleri yaşanmaması için bu işlem dikkatli planlanmalıdır. Yılda en az 2 kez (24 saat arayla)
PAC (Privilege Attribute Certificate) Doğrulaması
Kerberos ticket içindeki PAC alanı kullanıcının grup üyeliklerini taşır. Eğer PAC doğrulaması yapılmazsa, yetki manipülasyonu riski oluşur.
Modern Windows sürümlerinde PAC doğrulaması varsayılan olarak aktiftir, ancak legacy sistemlerde kontrol edilmelidir.
PAC validation devre dışı bırakılmamalıdır.
Audit Policy
Kerberos ile ilişkili log kayıtları, Kerberoasting, password spraying, Golden Ticket ve delegation abuse gibi saldırıları tespit etmek için kullanılabilir.
Anormal TGT yaşam süreleri, aşırı sayıda service ticket isteği, pre-auth başarısızlıkları ve yetkisiz delegation davranışları güvenlik operasyonları tarafından izlenmelidir.
Bazı Kritik Event ID'ler
Bu yazı, gerçek Active Directory ortamlarındaki Kerberos akışları ve saldırı yüzeyi üzerinde yapılan uygulamalı çalışmaya dayanmaktadır.
