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) ve 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.
Kimlik Doğrulama Protokolleri
- NTLM (NT LAN Manager)
- Kerberos
Kerberos Nedir?
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 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. 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. Kerberos ile korunan hedef servistir.
Key Distribution Center (KDC)
Kerberos'un en kritik bileşeni 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): İstemciden gelen kimlik doğrulama isteğinde belirtilen kullanıcının Active Directory üzerinde mevcut ve aktif olup olmadığını kontrol eder.
- Ticket Granting Server (TGS): AS tarafından verilen TGT'yi kullanan istemcilerin, erişmek istedikleri servisler için bilet almasını sağlar. İstemcinin talep ettiği servisin geçerli bir SPN ile tanımlı olup olmadığını kontrol eder (ör. CIFS, MSSQL, HTTP) ve Service Ticket üretir.
Kerberos Mimarisinin Temel Bileşenleri
KDC Database: KDC üzerinde tutulan merkezi kimlik veritabanıdır. Tüm kullanıcı hesapları, servis hesapları, SPN bilgileri ve her kullanıcı/servise karşılık gelen gizli anahtarlar (secret keys) burada bulunur. Bu bilgiler ticket'ların oluşturulması ve doğrulanmasında kullanılır.
SPN (Service Principal Name): Bir servisin Kerberos içindeki benzersiz kimliğidir. Domain içerisindeki herhangi bir kullanıcı, herhangi bir SPN için service ticket talep edebilir. Bilet, ilgili servis hesabının hash'ini içerdiğinden saldırgan bu hash'i offline olarak kırmaya çalışabilir.
PAC (Privilege Attribute Certificate): Kullanıcının kimlik bilgileriyle birlikte yetkilerini, grup üyeliklerini ve diğer authorization verilerini içerir. 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 — özellikle Golden Ticket'a — kapı aralayabilir.
Mutual Authentication: Karşılıklı kimlik doğrulamadır. Yalnızca istemci sunucuya kendisini kanıtlamakla kalmaz, sunucu da istemciye kimliğini doğrular. Bu çift yönlü doğrulama, Man-in-the-Middle saldırılarına karşı güçlü bir koruma sağlar — Kerberos'u NTLM'den ayıran temel özelliklerden biri.
Single Sign-On (SSO): Kullanıcı bir kez giriş yaptıktan sonra, tekrar parola girmeden farklı servislere erişebilir. Kullanıcının ilk girişinde elde ettiği TGT istemcinin belleğinde saklanır ve sonraki tüm servis taleplerinde kullanılır. Bu durum kritik bir risk de doğurur: saldırgan TGT'yi ele geçirirse Pass-the-Ticket veya Golden Ticket saldırıları gerçekleştirebilir.
krbtgt hesabı: Domain içerisindeki tüm TGT'lerin 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 — Golden Ticket saldırısının temeli budur. Bu nedenle krbtgt parolasının periyodik ve iki aşamalı şekilde değiştirilmesi kritik bir önlemdir.
Kerberos 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 Service Ticket ister.
- KRB_TGS_REP: KDC, istemciye istediği servis için Service Ticket 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).
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. İstek KDC'nin Authentication Service (AS) bileşenine gönderilir.
İstek içeriği:
- 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
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.
Pre-authentication
Client ilk isteği pre-auth olmadan gönderir. Eğer Do not require Kerberos preauthentication kapalıysa hata alınır (KRB5KDC_ERR_PREAUTH_REQUIRED) ve client ikinci istekte timestamp ekler.
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.
AS-REP Roasting Nedir?
AS-REP Roasting, Kerberos kimlik doğrulamasının ilk aşamasında (AS → Authentication Service) oluşan bir zafiyetten yararlanılarak yapılan bir saldırıdır. Yalnızca “Do not require Kerberos preauthentication” ayarı AÇIK olan kullanıcı hesaplarında mümkündür.
Pre-auth AÇIK: Kullanıcı Kerberos akışının ilk adımında AS 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; çözebilirse, kimlik doğrulama başarılı kabul edilir ve TGT döner.
Pre-auth KAPALI: Bu güvenlik katmanı tamamen ortadan kalkar. Kullanıcı AS'e istek gönderirken şifreli zaman damgası göndermek zorunda değildir. KDC, kullanıcının gerçekten parolaya sahip olup olmadığını doğrulayamaz; buna rağmen sistem yapılandırması gereği AS-REP yanıtı üretir. Bu yanıtın içeriği (özellikle session key) kullanıcının parola türevi anahtarıyla şifrelenmiştir. Saldırgan bu paketi ele geçirirse, içindeki şifreli veriyi offline olarak kırabilir. Kapalı kalmak zorundaysa 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 mesajdaki 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; Kerberoasting saldırıları bu süreçte ortaya çıkar.
Bu aşamadaki en kritik nokta krbtgt hesabıdır. 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.
3. KRB_TGS_REQ ve KRB_TGS_REP
İstemci, sahip olduğu TGT'yi kullanarak hedef servis için Service Ticket talep eder. KDC'nin TGS bileşeni, talep edilen servisin SPN'inin geçerli olduğunu doğruladıktan sonra, hedef servisin hash'i ile şifrelenmiş Service Ticket üretir ve istemciye gönderir.
Kerberoasting
Bir saldırgan, geçerli bir domain kullanıcı hesabı ile herhangi bir SPN için Service Ticket talep edebilir. Dönen ticket, hedef servis hesabının hash'i ile şifrelendiğinden, saldırgan bu ticket'ı offline olarak kırarak servis hesabının parolasını elde etmeye çalışır. RC4 destekli servis hesapları bu saldırıya karşı özellikle savunmasızdır.
4. KRB_AP_REQ / KRB_AP_REP — Servise Erişim
İstemci, aldığı Service Ticket'ı hedef servise sunar (KRB_AP_REQ). Hedef servis, kendi gizli anahtarıyla ticket'ı doğrular ve isteğe bağlı olarak kendi kimliğini de istemciye doğrular (KRB_AP_REP — mutual authentication).
NTLM ve Downgrade Riskleri
NTLM, Kerberos ile birlikte çalışan eski bir kimlik doğrulama protokolüdür. Kerberos enforced bir ortam oluşturulmadıkça, NTLM üzerinden downgrade saldırıları, NTLM Relay ve Pass-the-Hash teknikleri etkili olmaya devam eder.
NTLM Sertleştirme Policy Ayarları
1. Network security: LAN Manager authentication level
Send NTLMv2 response only. Refuse LM & NTLM — güvenilir seçenektir.
2. Network security: Restrict NTLM: Audit NTLM authentication — Enable ile NTLM fallback log'larını gör.
3. Network security: Restrict NTLM: Incoming NTLM traffic — Deny ile NTLM engellenir.
4. Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers — Deny ile NTLM kullanımı kesilir.
Double Hop Problemi ve Delegation
Double hop problemi, bir kullanıcının kimlik bilgilerinin ilk sunucudan ikinci sunucuya varsayılan olarak iletilememesi sorunudur. Tipik örnek: Kullanıcı → Web sunucusu → SQL sunucusu.
Çözüm: Delegation. Kerberos delegation mekanizmaları, 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, kendisine bağlanan kullanıcıların TGT'sini 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 privilege escalation ve 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. 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).
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.
3. Resource-Based Constrained Delegation (RBCD)
RBCD modelinde kontrol kaynak (target) tarafına verilmiştir. Hedef sistem, hangi hesapların kendi adına işlem yapabileceğini belirler. Bu yapı 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.
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. Hedef sistem üzerinde yanlış yapılandırılmış ACL izinleri varsa, düşük yetkili bir kullanıcı bile bu attribute'u değiştirebilir ve kendisini yetkili bir principal olarak ekleyebilir. Bu da RBCD'yi modern AD saldırılarında sık kullanılan bir teknik haline getirir.
Bu mekanizma tamamen Kerberos ü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 aktivitelerin tespiti zordur — Event log'larda yalnızca standart ticket talepleri (örn. 4769) görülür.
Kerberos'ta Trust İlişkileri
Kerberos mimarisinde trust ilişkileri, farklı güvenlik sınırları arasında kimlik doğrulamanın güvenli şekilde yapılmasını sağlayan temel yapılardır. 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
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. Domain controller'lar arasında paylaşılan güven ilişkileri ve kriptografik anahtarlar üzerinden ç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. Kullanıcı önce kendi realm'inden TGT alır, ardından bu TGT kullanılarak hedef realm için bir referral TGT elde edilir. 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.
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. AD Forest yapılarında bu tür trust ilişkileri varsayılan olarak geçişkendir. 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
Yalnızca iki domain arasında geçerli olan ve başka domain'lere genişlemeyen bir güven modelidir. Güven yalnızca tanımlanan iki taraf arasında geçerlidir ve üçüncü bir domain'e otomatik aktarılmaz. Yüksek güvenlik gereksinimi olan ortamlarda tercih edilir.
Kerberos Hardening
Maximum Lifetime for Service Ticket
Service ticket'ın maksimum geçerlilik süresi, potansiyel bir güvenlik ihlalinde saldırganın erişim süresini doğrudan etkiler. Kısa süreler yetki değişikliklerinin daha hızlı uygulanmasını sağlar; ancak çok kısa süreler KDC yükünü artırabilir.
Enforce User Logon Restrictions
Etkinleştirildiğinde, KDC her service ticket talebinde kullanıcının güncel yetkilerini ve logon kısıtlamalarını yeniden kontrol eder. Devre dışı bırakılırsa, kullanıcıya daha önce verilmiş yetkiler kaldırılmış olsa bile ticket süresi boyunca geçerli kalabilir — privilege revocation senaryolarında ciddi zafiyet.
Maximum Lifetime for User Ticket (TGT)
TGT'nin geçerlilik süresi ne kadar uzunsa, ele geçirilmesi durumunda saldırganın operasyon süresi de o kadar uzar. Golden Ticket veya Pass-the-Ticket saldırılarında ciddi risk.
Maximum Tolerance for Computer Clock Synchronization
Kerberos, replay saldırılarını önlemek için timestamp kullanır. Tolerans çok yüksek ayarlanırsa replay penceresi genişler; çok düşük ayarlanırsa kimlik doğrulama hataları artar.
Maximum Lifetime for User Ticket Renewal
TGT yenilenebilirlik süresi, persistence riskini belirler. Ele geçirilmiş bir TGT, renewal süresi boyunca yenilenebilir ve uzun süreli erişim sağlayabilir.
Kriptografik Ayarlar (Encryption Type Hardening)
Zayıf veya eski algoritmalar (özellikle DES ve RC4) aktif bırakıldığında Kerberoasting kolaylaşır. Yalnızca AES128 ve AES256 kullanılması önerilir.
Service Account Güvenliği
Servis hesapları, Kerberos saldırılarında en sık hedeflenen bileşenlerdir. gMSA (Group Managed Service Account) kullanımı, otomatik parola rotasyonu ve minimal yetki prensibi servis hesap güvenliğini ciddi ölçüde artırır.
Account Lockout Policies
Brute-force ve password spraying saldırılarını sınırlandırır. Çok düşük eşik servis kesintilerine, çok yüksek eşik brute force riskine yol açar; izleme ile desteklenmelidir.
Ticket Forwarding ve Delegation Ayarları
Unconstrained delegation, saldırganın TGT toplamasına olanak tanır. Constrained delegation ve özellikle RBCD daha kontrollü model sunar. Delegation kullanımı minimuma indirilmelidir.
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'nin aşamalı olarak devre dışı bırakılması önerilir.
Protected Users Group
Yüksek ayrıcalıklı hesapların ek güvenlik katmanları ile korunmasını sağlar. NTLM, zayıf şifreleme ve delegation yasaklanır; TGT süreleri kısaltılır; credential caching engellenir.
Authentication Policies & Silos
Hangi hesapların hangi makinelerde oturum açabileceğini kontrol eder. Yönetici hesapları yalnızca belirli yönetim workstation'larında kullanılabilir — lateral movement riskini azaltır.
Pre-Authentication Enforcement
Pre-auth disabled hesaplar AS-REP Roasting'e açıktır. Tüm hesaplarda pre-auth zorunlu olmalı ve düzenli denetlenmelidir.
KRBTGT Hesabı ve Parola Rotasyonu
KRBTGT parolası değiştirilmeden kalırsa Golden Ticket saldırıları uzun süre geçerli olabilir. Yılda en az 2 kez ve 24 saat arayla çift reset uygulanmalıdır.
PAC (Privilege Attribute Certificate) Doğrulaması
PAC alanı kullanıcının grup üyeliklerini taşır. Doğrulama yapılmazsa yetki manipülasyonu riski oluşur. PAC validation devre dışı bırakılmamalıdır.
Audit Policy
Kerberos 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.
