Kerberoasting ve AS-REP Roasting: Tespit ve Korunma

Kerberoasting için etki alanındaki herhangi bir kullanıcı hesabı yeter; saldırı tek bir başarısız oturum denemesi bile üretmez. Saldırgan, hizmet hesabının parolasından türetilen anahtarla şifrelenmiş Kerberos biletlerini ister, sonra parolayı kendi donanımında, çevrimdışı kırmaya çalışır. AS-REP roasting aynı fikri ön kimlik doğrulaması kapalı hesaplara uygular. Aşağıda iki saldırının mekanizmasını savunmacı gözüyle, riskli hesap envanterini, gMSA ve AES ile korunmayı ve olay günlüklerinden tespiti anlatıyoruz.

Kerberos bilet akışı ve saldırının mantığı

Kerberos’ta (RFC 4120) kullanıcı önce Key Distribution Center’dan (KDC; AD’de etki alanı denetleyicisi) bir TGT alır (AS-REQ/AS-REP). Bir hizmete erişmek istediğinde TGT’yi sunup o hizmetin Service Principal Name’i (SPN) için hizmet bileti ister (TGS-REQ/TGS-REP). Hizmet biletinin şifreli kısmı, SPN’in kayıtlı olduğu hesabın uzun vadeli anahtarıyla şifrelenir; bu anahtar o hesabın parolasından türetilir.

Protokol tasarımı gereği KDC, geçerli TGT’si olan her kullanıcıya her SPN için bilet verir; kullanıcının o hizmete yetkisi olup olmadığını kontrol etmek hizmetin işidir. Saldırgan bileti alır, hizmete hiç bağlanmaz, şifreli kısmı parola tahminleriyle çözmeye çalışır. Doğru anahtarla çözülen biletin yapısı geçerli çıktığı için tahminin tuttuğu anlaşılır. DC’de bu yalnız sıradan bir bilet talebi olarak görünür; hesap kilitleme ve başarısız oturum sayaçları hiç devreye girmez. Kilitleme politikası burada işe yaramaz.

Başarıyı iki etken belirler: parolanın gücü ve şifreleme türü. RC4-HMAC (etype 23) kullanıldığında anahtar doğrudan hesabın NT özetidir ve tuz yoktur; tahmin denemeleri çok hızlıdır. AES (etype 17 ve 18) anahtarı ise tuz ve PBKDF2 ile çok sayıda yinelemeyle türetilir, her tahmin belirgin biçimde pahalılaşır. Yine de zayıf parola AES ile de kırılır. Şifreleme türü süreyi uzatır, parola zayıflığını kapatmaz.

Kerberoasting ile AS-REP roasting farkı

Özellik	Kerberoasting	AS-REP roasting
Hedef hesap	SPN tanımlı kullanıcı hesapları	Ön kimlik doğrulaması kapalı hesaplar
Saldırgan gereksinimi	Herhangi bir geçerli etki alanı hesabı	Hesap adı yeterli
Kırılan veri	TGS-REP içindeki hizmet bileti	AS-REP içindeki şifreli kısım
DC olayı	4769	4768 (ön kimlik doğrulama türü 0)
Temel önlem	gMSA veya uzun rastgele parola, AES	Ön kimlik doğrulamayı açmak

Normalde istemci, AS-REQ içinde zaman damgasını kendi anahtarıyla şifreleyerek kimliğini kanıtlar (ön kimlik doğrulama). Hesapta “Do not require Kerberos preauthentication” işaretliyse KDC bu kanıtı istemeden AS-REP döner ve yanıtın bir kısmı kullanıcının anahtarıyla şifrelidir. Sahada bu ayarı çoğunlukla yıllar önce eski bir uygulama ya da Unix entegrasyonu için açılmış ve unutulmuş halde buluyoruz. Kimse hatırlamaz.

Bilgisayar hesapları da SPN taşır, ama parolaları otomatik üretilen uzun rastgele değerlerdir ve varsayılan olarak 30 günde bir değişir. Pratik hedef bu yüzden SPN atanmış kullanıcı hesaplarıdır.

Riskli hesapların envanteri (PowerShell)

Savunma, saldırganın göreceği listeyi ondan önce görmekle başlar. Aşağıdaki sorgular ActiveDirectory modülüyle SPN’li kullanıcı hesaplarını ve ön kimlik doğrulaması kapalı hesapları listeler:

Import-Module ActiveDirectory

# SPN tanımlı kullanıcı hesapları (krbtgt hariç)
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName,
    PasswordLastSet, AdminCount, 'msDS-SupportedEncryptionTypes', Enabled |
  Where-Object SamAccountName -ne 'krbtgt' |
  Select-Object SamAccountName, Enabled, AdminCount, PasswordLastSet,
    @{n='EncTypes';e={$_.'msDS-SupportedEncryptionTypes'}},
    @{n='SPN';e={$_.ServicePrincipalName -join '; '}} |
  Sort-Object PasswordLastSet | Format-Table -AutoSize

# Kerberos ön kimlik doğrulaması kapalı hesaplar
Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth |
  Select-Object SamAccountName, Enabled, DistinguishedName

Önceliklendirme için dört soru sorun: Hesap ayrıcalıklı bir grupta mı (AdminCount 1)? Parolası en son ne zaman değişti? msDS-SupportedEncryptionTypes boş mu, RC4 içeriyor mu? SPN hâlâ çalışan bir hizmete mi ait? Ayrıcalıklı ve parolası yıllardır değişmemiş bir SPN’li hesap, listenin en üstüne yazılır; böyle bir hesabın neden ayrıcalıklı olduğu da AD tier modeli açısından sorgulanmalıdır.

Ön kimlik doğrulaması kapalı hesaplarda düzeltme genelde basittir: ayar kapatılır (Set-ADAccountControl -Identity hesap -DoesNotRequirePreAuth $false) ve ilgili uygulama test edilir. Gerçekten gereken bir istisna varsa hesabın parolası çok uzun ve rastgele olmalı, istisna kayda geçmelidir.

gMSA ve uzun parolalarla korunma

En kalıcı çözüm, hizmet hesaplarını Group Managed Service Account’a (gMSA) taşımaktır. gMSA parolası AD’nin ürettiği uzun rastgele bir değerdir ve varsayılan olarak 30 günde bir kendiliğinden değişir; bu parolayı hiçbir insan bilmez, sözlük saldırısıyla kırılması pratik değildir. gMSA, parolayı yalnız yetkili sunucuların alabileceği şekilde tanımlanır:

# Orman başına bir kez: KDS kök anahtarı (çoğaltma için 10 saat beklenir)
Add-KdsRootKey -EffectiveImmediately

# gMSA oluştur; parolayı yalnız SQL sunucuları grubu alabilir
New-ADServiceAccount -Name gmsa-sql01 -DNSHostName gmsa-sql01.corp.local `
    -PrincipalsAllowedToRetrieveManagedPassword "SQL-Sunuculari" `
    -KerberosEncryptionType AES128,AES256 `
    -ServicePrincipalNames "MSSQLSvc/sql01.corp.local:1433"

# Hedef sunucuda
Install-ADServiceAccount -Identity gmsa-sql01
Test-ADServiceAccount -Identity gmsa-sql01

Add-KdsRootKey -EffectiveImmediately anahtarı hemen oluşturur, ama gMSA açmadan önce anahtarın tüm DC’lere çoğalması için 10 saat beklenir. Bunu atlayıp hemen gMSA oluşturmaya çalışmak, ilk kurulumda en sık takılınan noktadır. Hizmet yapılandırmasında hesap adı CORP\gmsa-sql01$ biçiminde girilir, parola alanı boş bırakılır. SQL Server, IIS uygulama havuzları ve zamanlanmış görevler gMSA’yı destekler; bazı üçüncü taraf uygulamalar desteklemeyebilir.

gMSA’ya taşınamayan hesaplar için:

• Parola uzun (yaygın öneri en az 25 karakter) ve rastgele üretilmiş olmalı, bir parola kasasında saklanmalı.
• Parola düzenli olarak ve hesap sorumlusu ayrıldığında değiştirilmeli.
• Hesap ayrıcalıklı gruplardan çıkarılmalı, yalnız gereken sunucularda yetkili olmalı.
• Kullanılmayan SPN’ler kaldırılmalı; artık çalışmayan bir hizmetin SPN’i yalnız saldırı yüzeyidir.

RC4 kullanımını azaltmak

KDC’nin hizmet bileti için hangi şifreleme türünü seçeceği, hedef hesabın msDS-SupportedEncryptionTypes değerine ve etki alanı ayarlarına bağlıdır. Değeri 24 (0x18) olan hesap yalnız AES128 ve AES256’yı destekler. Bir hesap için AES’i zorunlu kılmak:

Set-ADUser -Identity svc-uygulama -KerberosEncryptionType AES128,AES256
# Parola, AES anahtarları üretilmeden önce belirlendiyse yeniden ayarlanmalıdır
Set-ADAccountPassword -Identity svc-uygulama -Reset

Etki alanı işlevsellik düzeyi 2008’e yükseltilmeden önce belirlenmiş ve o günden beri hiç değişmemiş parolalar için AD’de AES anahtarı bulunmayabilir; bu hesaplarda parola değiştirilmeden AES’e geçmek kimlik doğrulama hatası doğurur. Geçişten önce DC’lerde 4769 olaylarındaki Ticket Encryption Type alanını izleyin, hâlâ RC4 (0x17) bileti alan hizmetleri çıkarın ve uygulama sahipleriyle test planlayın. Microsoft, Kerberos’ta RC4 kullanımını varsayılan olarak kapatmaya yönelik aşamalı değişiklikler duyurdu; takvimi ve gereken hazırlıkları Microsoft’un güncel duyurularından takip edin.

Olay günlüklerinden tespit

Tespit için etki alanı denetleyicilerinde Advanced Audit Policy altında Account Logon > Audit Kerberos Service Ticket Operations ve Audit Kerberos Authentication Service alt kategorileri başarı olaylarını kaydedecek şekilde açık olmalıdır. Kapalıysa ortada tespit edilecek veri yoktur. Kerberoasting için temel sinyaller:

• 4769 olayında TicketEncryptionType 0x17 (RC4) ve hizmet adının bilgisayar hesabı ($ ile biten) veya krbtgt olmaması; AES’e geçmiş ortamlarda bu tek başına güçlü bir sinyaldir.
• Tek bir kullanıcının kısa sürede çok sayıda farklı SPN için bilet istemesi.
• Normalde o hizmete hiç bağlanmayan bir kullanıcıdan veya iş istasyonundan gelen bilet talepleri.

AS-REP roasting için 4768 olayında PreAuthType değerinin 0 olması aranır. Aşağıdaki betik, bir DC’de son 24 saatteki RC4 hizmet bileti taleplerini kullanıcı bazında gruplar:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769;
    StartTime=(Get-Date).AddHours(-24)} |
  ForEach-Object {
    $x = [xml]$_.ToXml(); $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]$d
  } |
  Where-Object { $_.TicketEncryptionType -eq '0x17' -and
                 $_.ServiceName -notlike '*$' -and $_.ServiceName -ne 'krbtgt' } |
  Group-Object TargetUserName |
  Sort-Object Count -Descending |
  Select-Object Count, Name

Üretimde bu mantık SIEM’e taşınır ve tüm DC’lerin olayları birlikte değerlendirilir; tek DC’ye bakan tespit, talebin öteki DC’ye gittiği gün kördür. Microsoft Defender for Identity gibi ürünler de bu davranış için hazır tespitler sunar.

Tuzak SPN ile erken uyarı

Gerçek hizmet hesaplarının 4769 olaylarında yanlış pozitif ayıklamak zaman alır. Tamamlayıcı yöntem, hiçbir meşru işlemin kullanmayacağı bir tuzak hesap kurmaktır:

1. Gerçekçi bir adla (ör. eski bir arşiv veritabanı hizmet hesabı) bir kullanıcı hesabı oluşturun, çok uzun rastgele bir parola atayın, hiçbir gruba eklemeyin.
2. Hesaba inandırıcı bir SPN ekleyin: Set-ADUser -Identity svc-arsivsql -ServicePrincipalNames @{Add='MSSQLSvc/sql-arsiv01.corp.local:1433'}
3. Bu hesap için gelen her 4769 olayını yüksek öncelikli alarm olarak tanımlayın; meşru bir sebeple bu SPN’e bilet istenmez.
4. Hesap için DC’lerde üretilen 4768 (TGT talebi) ve 4771 (ön kimlik doğrulama hatası) olaylarını da alarma bağlayın; bunlar saldırganın tuzak hesabın parolasını denediğini gösterir.

Tuzak hesabı, SPN numaralandırmasında görünecek ama hiçbir gerçek sisteme erişim vermeyecek şekilde tasarlayın. Sızma testinde bu alarmın tetiklenip tetiklenmediğine bakmak, tespit zincirinin baştan sona çalıştığını doğrulamanın pratik yoludur. Alarm gelmiyorsa zincirde kopukluk var demektir.

NTLM tabanlı saldırılar ayrı bir başlık; NTLM denetimi ve kısıtlama yazısında anlatılıyor. Hizmet hesabı ayrıcalıklarının birleşerek etki alanı yöneticiliğine nasıl yol açtığını görmek için AD saldırı yolu analizi yazısına bakın. Ortamınızdaki SPN’li hesapların ve Kerberos yapılandırmasının değerlendirilmesi Active Directory güvenlik denetimi kapsamında, hizmet hesabı parolalarının kasada yönetimi ayrıcalıklı erişim yönetimi kapsamında ele alınabilir.

Sık sorulan sorular

Kerberoasting için saldırganın yönetici yetkisi gerekir mi?

Hayır. Etki alanında geçerli herhangi bir kullanıcı hesabı, SPN tanımlı hesaplar için hizmet bileti isteyebilir. Kimlik avıyla ele geçirilmiş sıradan bir kullanıcı hesabı saldırıyı başlatmaya yeter; savunma, hizmet hesabı parolalarını kırılamaz hale getirmeye ve tespit kurmaya dayanır.

AES’e geçmek Kerberoasting’i tamamen önler mi?

Önlemez. AES her parola tahminini RC4’e göre çok daha pahalı hale getirir ve RC4 bilet talebi gibi belirgin bir tespit sinyali bırakır. Ama zayıf veya sözlükte bulunan bir parola AES ile şifrelenmiş biletten de kırılır. Kalıcı çözüm gMSA ya da çok uzun rastgele parolalardır.

gMSA her uygulamada kullanılabilir mi?

Hayır. Windows hizmetleri, SQL Server, IIS uygulama havuzları ve zamanlanmış görevler gMSA’yı destekler; parolayı yapılandırma dosyasında isteyen veya Windows dışı platformda çalışan bazı uygulamalar desteklemez. Bu hesaplarda uzun rastgele parola, parola kasası, düzenli değişim ve en az ayrıcalık uygulanır.

4769 olaylarında çok fazla RC4 kaydı varsa ne yapılmalı?

Önce hangi hizmet hesaplarının RC4 bileti aldığını ve bu biletlerin hangi istemcilerden istendiğini raporlayın. Hesapların msDS-SupportedEncryptionTypes değerini AES olarak ayarlayıp parolalarını yenileyin, uygulama sahipleriyle test edin. RC4 kayıtları azaldıkça kalan RC4 talepleri daha güçlü bir saldırı sinyaline dönüşür.