Kerberos Kimlik Doğrulama Güvenliği: Saldırılar ve Savunma Yöntemleri

Yazar:komut.io ekibi
0 Yorum

Kurumsal ağlarda kimlik doğrulama deyince aklına ilk gelen protokollerden biri Kerberos’tur. MIT tarafından geliştirilen ve Active Directory’nin temel taşı olan bu protokol, doğru yapılandırılmadığında ciddi güvenlik açıklarına kapı aralayabilir. Bu yazıda Kerberos güvenliğini hem saldırgan hem de savunmacı perspektiften ele alacağız. Gerçek dünya senaryolarıyla nelerin yanlış gidebileceğini ve bunlara karşı nasıl önlem alabileceğini inceleyeceğiz.

Kerberos Nasıl Çalışır: Temel Mekanizma

Kerberos’un güvenliğini anlamak için önce nasıl çalıştığını kavramak gerekir. Protokol üç temel bileşen üzerine kuruludur:

  • KDC (Key Distribution Center): Kimlik doğrulama merkezinin beyni. Active Directory ortamında Domain Controller bu rolü üstlenir.
  • AS (Authentication Service): Kullanıcının ilk kimlik doğrulamasını yapar ve TGT verir.
  • TGS (Ticket Granting Service): TGT’yi alır ve servis biletlerini üretir.

Akış şöyle işler: Kullanıcı oturum açtığında AS’a bir istek gönderir. AS, kullanıcının şifresiyle türetilen anahtarla şifrelenmiş bir TGT (Ticket Granting Ticket) döner. Kullanıcı bir servise erişmek istediğinde bu TGT’yi TGS’ye sunar ve karşılığında o servise özel bir bilet alır. Servis bu bileti kendi anahtarıyla doğrular ve erişim sağlar.

Teoride mükemmel bir sistem. Pratikte ise yanlış yapılandırmalar bu zinciri kırabilir.

Yaygın Kerberos Saldırı Vektörleri

Kerberoasting

Kerberoasting, kurumsal ağlarda en sık karşılaşılan Kerberos saldırısıdır. Saldırgan, SPN (Service Principal Name) kayıtlı herhangi bir servis hesabı için TGS bileti talep eder. Bu biletin bir kısmı servis hesabının NTLM hash’iyle şifrelenmiştir ve çevrimdışı kırılmaya açıktır.

Saldırının tehlikeli yanı şudur: Normal bir domain kullanıcısı bile bu işlemi yapabilir. Özel bir ayrıcalık gerekmez.

# Impacket ile Kerberoasting
python3 GetUserSPNs.py domain.local/kullanici:sifre -dc-ip 192.168.1.10 -request

# Hashcat ile elde edilen hash'i kırma
hashcat -m 13100 kerberos_hashes.txt wordlist.txt --rules-file best64.rule

Savunma tarafında yapılması gerekenler:

  • Servis hesapları için güçlü, uzun ve karmaşık şifreler kullan (minimum 25 karakter, otomatik döndürme ile birlikte)
  • Gereksiz SPN kayıtlarını temizle
  • Managed Service Account (MSA) veya Group Managed Service Account (gMSA) kullan
# Ortamındaki tüm SPN'leri listele
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName | 
    Select-Object Name, ServicePrincipalName

# gMSA hesabı oluşturma
New-ADServiceAccount -Name "svc-webapp" -DNSHostName "webapp.domain.local" -PrincipalsAllowedToRetrieveManagedPassword "WebApp-Servers"

AS-REP Roasting

Bu saldırı, Kerberos ön kimlik doğrulaması (pre-authentication) devre dışı bırakılmış hesapları hedef alır. Pre-authentication normalde şifreyi bilmeden TGT talep etmeyi engeller. Devre dışıysa saldırgan şifre bilmeden AS yanıtını alabilir ve çevrimdışı kırmaya çalışabilir.

# Pre-auth devre dışı olan hesapları bul
Get-ADUser -Filter * -Properties DoesNotRequirePreAuth | 
    Where-Object {$_.DoesNotRequirePreAuth -eq $true} | 
    Select-Object Name, SamAccountName

# Impacket ile AS-REP Roasting
python3 GetNPUsers.py domain.local/ -usersfile users.txt -no-pass -dc-ip 192.168.1.10

Savunma için pre-authentication’ı tüm hesaplarda zorunlu kıl:

# Tüm kullanıcılar için pre-auth zorunlu hale getir
Get-ADUser -Filter * | Set-ADAccountControl -DoesNotRequirePreAuth $false

# Group Policy ile de kontrol edebilirsin
# Computer Configuration > Windows Settings > Security Settings > 
# Account Policies > Kerberos Policy

Pass-the-Ticket (PtT)

Pass-the-Ticket saldırısında, saldırgan bellekten Kerberos biletlerini çalar ve bunları farklı bir sistemde kullanır. Mimikatz bu konuda en bilinen araçtır.

# Mimikatz ile bellekteki biletleri listele
sekurlsa::tickets /export

# Bileti başka bir oturuma enjekte et
kerberos::ptt ticket.kirbi

Bu saldırıya karşı korunmak için:

  • Protected Users güvenlik grubunu kullan. Bu grup üyeleri için Kerberos biletleri bellekte farklı şekilde saklanır ve çalınması zorlaşır.
  • Credential Guard’ı etkinleştir
# Kullanıcıyı Protected Users grubuna ekle
Add-ADGroupMember -Identity "Protected Users" -Members "admin_kullanici"

# Credential Guard durumunu kontrol et
Get-ComputerInfo | Select-Object -Property DeviceGuard*

Golden Ticket Saldırısı

Golden Ticket, KRBTGT hesabının hash’ini ele geçiren bir saldırganın keyfi TGT üretmesine olanak tanır. Bunu ele geçiren saldırgan teorik olarak domain üzerinde kalıcı ve tamamen yetkili erişime sahip olur.

# Mimikatz ile Golden Ticket oluşturma (simülasyon amaçlı)
# Önce KRBTGT hash'ini al
lsadump::dcsync /domain:domain.local /user:krbtgt

# Golden Ticket oluştur
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-XXXX /krbtgt:HASH /endin:600 /renewmax:10080 /ptt

Golden Ticket saldırısına karşı savunma:

  • KRBTGT hesabının şifresini düzenli olarak iki kez sıfırla (iki kez çünkü önceki şifre de saklanır)
  • Domain Controller’lara erişimi sıkı denetle
  • Tier model uygula (Admin hesaplarını katmanlandır)
# KRBTGT şifresini sıfırla (bunu iki defa, 10 saat arayla yap)
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "YeniKarmasikSifre123!" -Force)

# KRBTGT son şifre değişikliği tarihini kontrol et
Get-ADUser krbtgt -Properties PasswordLastSet | Select-Object PasswordLastSet

Kerberos Güvenlik Politikaları ve Yapılandırma

Bilet Sürelerini Doğru Ayarla

Varsayılan Kerberos yapılandırması çoğu ortam için kabul edilebilir olsa da güvenlik gereksinimlerinize göre bilet sürelerini ayarlamak önemlidir.

  • Maximum lifetime for user ticket: Varsayılan 10 saat. Yüksek güvenlikli ortamlarda 4-8 saate düşürmek mantıklıdır.
  • Maximum lifetime for service ticket: Varsayılan 600 dakika.
  • Maximum tolerance for computer clock synchronization: Varsayılan 5 dakika. Bu değeri küçültme, NTP sorunlarına yol açabilir.
# Mevcut Kerberos politikasını görüntüle
Get-ADDefaultDomainPasswordPolicy

# Domain Kerberos politikasını GPO üzerinden yapılandır
# Group Policy Management Console > Default Domain Policy >
# Computer Configuration > Policies > Windows Settings > 
# Security Settings > Account Policies > Kerberos Policy

Kerberos Delegation Güvenliği

Kerberos delegation, bir servisin kullanıcı adına başka servislere erişmesine izin verir. Üç türü vardır ve en tehlikeli olanı unconstrained delegation‘dır.

# Unconstrained delegation yapılandırılmış hesapları bul
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, ServicePrincipalName

Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation

# Constrained delegation yapılandırılmış hesapları bul
Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo

Unconstrained delegation bulunan sistemlerde saldırgan, o sisteme bağlanan herhangi bir kullanıcının TGT’sini çalabilir. Bu nedenle:

  • Domain Controller ve kritik sunucuların unconstrained delegation ile yapılandırılmamasına dikkat et
  • Resource-Based Constrained Delegation (RBCD) kullanımını tercih et
  • Unconstrained delegation gereçekten gerekiyorsa o sistemleri izole et
# Constrained delegation'a geç
Set-ADComputer -Identity "AppServer" -TrustedForDelegation $false
Set-ADAccountControl -Identity "svc-appservice" -TrustedForDelegation $false

# Belirli servislere constrained delegation tanımla
Set-ADUser -Identity "svc-webapp" -Add @{'msDS-AllowedToDelegateTo'="MSSQLSvc/sqlserver.domain.local:1433"}

Kerberos Olaylarını İzleme ve Tespit

Saldırıları fark etmek için doğru olayları izlemek şarttır. Windows Event Log’unda Kerberos ile ilgili kritik olay kimlikleri şunlardır:

  • 4768: Kerberos kimlik doğrulama bileti (TGT) istendi
  • 4769: Kerberos servis bileti istendi
  • 4770: Kerberos servis bileti yenilendi
  • 4771: Kerberos ön kimlik doğrulaması başarısız oldu
  • 4672: Özel ayrıcalıklar atandı
# Başarısız Kerberos kimlik doğrulama olaylarını sorgula
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4771
    StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message | Format-List

# Kerberoasting tespiti: Kısa sürede çok sayıda 4769 olayı
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4769
    StartTime = (Get-Date).AddMinutes(-10)
} | Where-Object {$_.Message -match "0x17"} | 
    Group-Object -Property {$_.Properties[1].Value} | 
    Where-Object Count -gt 10

Kerberoasting tespitinde dikkat edilecek nokta, RC4 şifreleme kullanımıdır (0x17). Modern ortamlarda AES kullanılmalıdır, RC4 istekleri şüpheli sayılabilir.

# Servis hesaplarını AES şifreleme kullanacak şekilde yapılandır
Set-ADUser -Identity "svc-webapp" -KerberosEncryptionType AES256,AES128

# Tüm servis hesapları için kontrol et
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties KerberosEncryptionType |
    Where-Object {$_.KerberosEncryptionType -notmatch "AES"} |
    Select-Object Name, KerberosEncryptionType

Gerçek Dünya Senaryosu: Bir Kurumda Kerberoasting Tespiti

Geçen yıl bir fintech şirketinde yaptığım güvenlik değerlendirmesinde ilginç bir durumla karşılaştım. Şirket, servis hesapları için yıllardır “Sifre123!” formatında şifreler kullanıyordu. SPN’leri tarayan bir iç saldırgan simülasyonunda 15 dakika içinde üç servis hesabının şifresini kırabildik.

Problemi çözmek için şu adımları izledik:

# Adım 1: Tüm SPN hesaplarını listele ve raporla
$report = Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties * |
    Select-Object Name, SamAccountName, ServicePrincipalName, 
                  PasswordLastSet, KerberosEncryptionType, 
                  PasswordNeverExpires

$report | Export-Csv -Path "spn_audit.csv" -NoTypeInformation -Encoding UTF8

# Adım 2: Zayıf şifre politikasına sahip hesapları belirle
$report | Where-Object {
    $_.PasswordLastSet -lt (Get-Date).AddDays(-90) -or 
    $_.PasswordNeverExpires -eq $true
}
# Adım 3: gMSA'ya geçiş planla
# KDS kök anahtarının mevcut olduğunu doğrula
Get-KdsRootKey

# Yoksa oluştur (lab ortamında anında kullanmak için -EffectiveTime)
Add-KdsRootKey -EffectiveImmediately

# gMSA oluştur
New-ADServiceAccount -Name "svc-fintech-api" `
    -Description "FinTech API Servis Hesabi" `
    -DNSHostName "api.domain.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "FinTech-AppServers" `
    -KerberosEncryptionType AES256

# Servisi gMSA ile çalıştır
Install-ADServiceAccount -Identity "svc-fintech-api"

Bu değişiklikten sonra söz konusu hesapların şifreleri artık 240 karakterlik rastgele değerlerle otomatik olarak her 30 günde bir değiştiriliyor. Kerberoasting pratikte imkansız hale geldi.

AES Şifrelemeye Geçiş

Ortamında hala RC4 (DES/3DES dahil) kullanılıyorsa bu ciddi bir güvenlik riskidir. Modern tüm ortamlar AES128 veya AES256 kullanmalıdır.

# Domain'de RC4 kullanımını kısıtla
# Default Domain Controllers Policy üzerinden:
# Computer Configuration > Administrative Templates > 
# Network > Kerberos > Supported Kerberos encryption types

# Şifrelemeyı sadece AES'e kısıtlama (dikkatli ol, eski sistemleri kırabilir)
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemKerberosParameters" `
    -Name "SupportedEncryptionTypes" -Value 0x18 -Type DWord

# Değer açıklaması:
# 0x1: DES-CBC-CRC
# 0x2: DES-CBC-MD5  
# 0x4: RC4-HMAC
# 0x8: AES128-CTS-HMAC-SHA1-96
# 0x10: AES256-CTS-HMAC-SHA1-96
# 0x18 = AES128 + AES256 kombinasyonu

Honeypot Stratejisi: Kerberos ile Saldırı Tuzakları

Proaktif güvenlik için sahte SPN’lere sahip tuzak hesapları oluşturabilirsin. Bu hesaplar hiçbir zaman gerçek servislerde kullanılmadığından bunlara yapılan her istek anında alarm verir.

# Tuzak servis hesabı oluştur
New-ADUser -Name "svc-backup-legacy" `
    -SamAccountName "svc-backup-legacy" `
    -Description "DO NOT USE - Monitoring Account" `
    -Enabled $true `
    -PasswordNeverExpires $true

# SPN ata (bu hesap gerçekte hiçbir serviste kullanılmayacak)
Set-ADUser -Identity "svc-backup-legacy" `
    -ServicePrincipalNames @{Add="BackupService/backup-server.domain.local"}

# Bu hesaba yapılan 4769 olaylarını izle ve alert üret
$trigger = New-EventTrigger -LogName Security -EventId 4769

# SIEM kuralı örneği (pseudo-code)
# IF EventID=4769 AND TargetUserName="svc-backup-legacy" THEN ALERT CRITICAL

Sonuç

Kerberos, doğru yapılandırıldığında son derece güvenli bir protokoldür. Ancak yıllarca biriken yanlış yapılandırmalar, unutulmuş servis hesapları ve eski sistemlerle uyumluluk adına yapılan tavizler ciddi güvenlik açıklarına zemin hazırlar.

Öncelik sırasıyla şunları yapmanı öneririm: İlk olarak SPN envanterini çıkar ve zayıf şifreli servis hesaplarını gMSA’ya taşı. Ardından pre-authentication’ı tüm hesaplarda zorunlu kıl ve RC4 şifrelemeyi devre dışı bırak. Unconstrained delegation yapılandırmalarını gözden geçir ve gereksiz olanları kaldır. Son olarak KRBTGT şifresini planlanmış bir bakımda iki kez sıfırla ve bu işlemi yılda en az bir kez tekrarla.

İzleme tarafında ise 4768, 4769, 4771 olaylarını SIEM’ine alarak kısa sürede yoğunlaşan RC4 tabanlı bilet isteklerini tespit eden kurallar yaz. Kerberos güvenliği bir kere yapıp unutulacak bir iş değil; ortam değiştikçe, yeni sistemler eklenip çıkarıldıkça sürekli gözden geçirilmesi gereken dinamik bir süreçtir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir