Merhaba
Serinin ilk bölümünde Kerberoasting’i ele almış, SPN ile yapılandırılmış kullanıcı objelerinin nasıl hedef alındığını ve Event ID 4769 üzerinden nasıl tespit edilebileceğini kendi Windows Server 2025 lab ortamımdan örneklerle göstermiştim. Bu bölümde, rapordaki sıralamayı takip ederek benzer mantıkla çalışan ama farklı bir zafiyeti istismar eden AS-REP Roasting tekniğine geçiyorum.
AS-REP Roasting
Authentication Server Response (AS-REP) Roasting, Kerberos ön kimlik doğrulamasını (pre-authentication) gerektirmeyecek şekilde yapılandırılmış kullanıcı objelerini istismar eder. Kerberoasting’e benzer şekilde, domain’deki herhangi bir kullanıcı objesi (yetkisiz kullanıcılar dahil), Kerberos ön kimlik doğrulaması gerektirmeyecek şekilde yapılandırılmış herhangi bir kullanıcı objesi için bir Authentication Server Request (AS-REQ) gönderip AS-REP ticket’ini alabilir. AS-REP ticket’i, kullanıcı objesinin parola hash’i ile şifrelenir; bu hash çevrimdışı kırılarak düz metin parola ortaya çıkarılabilir. Saldırganlar AS-REP ticket’ini kırıp düz metin parolayı elde ederse, o kullanıcı objesi olarak kimlik doğrulaması yapabilir. AS-REP Roasting, saldırganların Active Directory domain’ine ilk erişimi elde ettikten kısa süre sonra yetki yükseltmek ve yanal hareket etmek için uyguladığı bir tekniktir.
AS-REP Roasting Nasıl İşler
- Saldırgan, Kerberos ön kimlik doğrulaması gerektirmeyecek şekilde yapılandırılmış bir kullanıcı objesi için Domain Controller’a bir AS-REQ mesajı gönderir.
- Domain Controller, TGT’yi içeren AS-REP mesajıyla yanıt verir.
- Saldırgan, TGT’yi kırarak düz metin parolayı ortaya çıkarır ve kullanıcı objesi olarak kimlik doğrulaması yapar.
AS-REP Roasting’i Mitigasyon Etmek
Saldırganların AS-REP Roasting uygulama fırsatı Kerberoasting’e kıyasla daha sınırlıdır, çünkü AD DS’de kullanıcı objeleri varsayılan olarak Kerberos ön kimlik doğrulaması gerektirecek şekilde yapılandırılır ve AS-REP Roasting yalnızca ön kimlik doğrulaması gerektirmeyecek şekilde yapılandırılmış kullanıcı objeleri için mümkündür. Kerberos versiyon 5’te tanıtılan Kerberos kimlik doğrulama protokolü, Active Directory’nin kullandığı birincil kimlik doğrulama protokolüdür. Ön kimlik doğrulamasını gerektirmeme yapılandırması yalnızca Kerberos’u desteklemeyen sistemleri (genellikle eski/legacy sistemler olarak kabul edilir ve günümüzde daha az yaygındır) desteklemek amacıyla var olmaya devam eder. Kerberos versiyon 5’ten daha eski bir sürüm kullanan uygulama ve sistemleri olan kurumlar, kullanıcı objelerini ön kimlik doğrulaması gerektirmeyecek şekilde yapılandırabilir; bu da ortamı AS-REP Roasting’e karşı savunmasız bırakır. AS-REP Roasting’i mitigasyon etmek için aşağıdaki güvenlik kontrolü uygulanmalıdır:
- Kullanıcı objelerinin Kerberos ön kimlik doğrulaması gerektirmesini sağlayın. Tüm kullanıcı objeleri Kerberos ön kimlik doğrulaması gerektiriyorsa, AS-REP Roasting mitigasyon edilmiş olur. Ancak bazı kullanıcı objelerinin Kerberos ön kimlik doğrulamasını atlayacak şekilde yapılandırılması zorunluysa, bu kullanıcı objelerine işlevlerini yerine getirmek için gereken minimum yetkiler atanmalı ve Domain Admins gibi yüksek yetkili güvenlik gruplarının üyesi olmamalıdır. Ayrıca servis hesapları için minimum 30 karakterlik, kullanıcılar için ise minimum 15 karakterlik, benzersiz, tahmin edilemez ve yönetilen bir parola belirlenmelidir.
AS-REP Roasting’i Tespit Etmek
Uygulama veya sistemler Kerberos versiyon 5’ten daha eski bir sürüm kullanıyorsa, AS-REP Roasting meşru Active Directory aktivitesini yansıtacak ve aynı olayları tetikleyecektir; bu da tespiti zorlaştırabilir. AS-REP Roasting tipik olarak, ön kimlik doğrulaması devre dışı bırakılmış tüm kullanıcı objeleri için TGT ticket’larının eş zamanlı olarak alınmasını içerir. Bu nedenle, AS-REP Roasting’i tespit etmenin bir yöntemi (Kerberoasting’i tespit etmeye benzer şekilde) TGT talep olaylarını (event 4768) analiz etmek ve kısa bir zaman aralığında, Kerberos ön kimlik doğrulaması devre dışı bırakılmış birden fazla kullanıcı objesi için TGT taleplerinin yapıldığı durumları tespit etmektir. Aşağıdaki Event ID’ler merkezi olarak loglanmalı ve zamanında analiz edilmelidir.
Tablo 1. AS-REP Roasting’i Tespit Eden Olaylar
| Event ID | Kaynak | Açıklama |
|---|---|---|
| 4738, 5136 | Domain Controller’lar | Bir kullanıcı hesabı değiştirildiğinde üretilir. Saldırganlar kullanıcı objelerini değiştirip Kerberos service ticket’i alabilmek için SPN ekleyebilir. TGS ticket alındıktan sonra kullanıcı objesi tekrar değiştirilir ve SPN kaldırılır. |
| 4769 | Domain Controller’lar | Bir TGS ticket’i talep edildiğinde üretilir. Saldırganlar Kerberoasting uyguladığında, talep edilen her TGS ticket’i için bu olay üretilir. Saldırganlar genellikle Rivest Cipher 4 (RC4) şifrelemesiyle TGS talep eder, çünkü bu ticket’lar kırılarak düz metin parola elde etmek daha kolaydır. RC4 şifrelemesiyle TGS talep edilirse, event 4769 için Ticket Encryption type değeri ‘0x17’ olur. Bu şifreleme türü daha az kullanıldığından, bu türle üretilen 4769 olaylarının daha az olması beklenir, bu da potansiyel Kerberoasting aktivitesini tespit etmeyi kolaylaştırır. Ayrıca yaygın offensive security araçları Ticket Options değerini ‘0x40800000’ veya ‘0x40810000’ olarak ayarlar; bu değerler Kerberoasting’i tespit etmek için kullanılabilir. |
Bu teknik, Active Directory canary’leri yardımıyla da tespit edilebilir; bu konuyu serinin son bölümünde ele alacağım.
Lab Uygulaması: Windows Server 2025 Üzerinde AS-REP Roasting
Yukarıdaki teoriyi kendi lab ortamımda pratikte gösterelim. Kerberoasting’in aksine, AS-REP Roasting için .NET’in hazır sınıflarıyla tek satırlık bir native PowerShell yöntemi yok; çünkü teknik, ön kimlik doğrulama alanı olmadan kasıtlı olarak gönderilen bir AS-REQ paketi kurmayı gerektiriyor ve bu paket seviyesinde bir işlem. Bu yüzden Kerberoasting bölümünde raporun da andığı offensive security araçlarından birini, Impacket’in `GetNPUsers.py` script’ini kullandım; komut yine de kurbanın parolasına hiçbir şekilde ihtiyaç duymuyor. Test ortamında `svc-legacyapp` adında bir servis hesabı oluşturup Kerberos ön kimlik doğrulamasını devre dışı bıraktım:
New-ADUser -Name "svc-legacyapp" -SamAccountName "svc-legacyapp" -UserPrincipalName "svc-legacyapp@bakicubuk.local" -AccountPassword (ConvertTo-SecureString "GucluBirParola!2026x" -AsPlainText -Force) -Enabled $true -PasswordNeverExpires $true
Set-ADAccountControl -Identity svc-legacyapp -DoesNotRequirePreAuth $trueKerberoasting’de olduğu gibi, DC ve hesap varsayılan olarak AES’i de desteklediği için ilk denemede AS-REP hash’i AES256 (etype 18) ile döndü. Rapordaki RC4 tespit kriterini göstermek için hesabı RC4’e zorladım:
Set-ADUser -Identity svc-legacyapp -Replace @{"msDS-SupportedEncryptionTypes"=4}Ardından, domain’e katılı bir Windows 11 client’tan, hiçbir kimlik bilgisi girmeden AS-REP talebini gönderdim:
GetNPUsers.py bakicubuk.local/ -usersfile users.txt -no-pass -dc-ip 192.168.1.200Komutun çalıştırılması ve dönen AS-REP hash’i. Hash’in başındaki $23$ ifadesi, ticket’ın RC4-HMAC (etype 23) ile şifrelendiğini gösteriyor; bu hash, hashcat veya John the Ripper gibi araçlarla çevrimdışı kırılmaya hazır: Komut çalıştığı anda DC üzerinde Event ID 4768 (A Kerberos authentication ticket (TGT) was requested) kaydı oluşuyor. Event Viewer’da bu kaydın üst kısmında talep eden hesabın (svc-legacyapp) MSDS-SupportedEncryptionTypes: 0x4 (RC4) olarak ayarlandığı görülüyor:
Event ID 4768 detayı – hesap bilgileri: Kaydın devamında, Additional Information bölümünde asıl aradığımız kanıt yer alıyor: Ticket Encryption Type: 0x17 (RC4) ve, daha da belirleyici olarak, Pre-Authentication Type: 0 ile Pre-Authentication EncryptionType: 0x0 – yani ticket, hiçbir ön kimlik doğrulaması sağlanmadan verilmiş. Normal bir oturum açmada bu alan dolu ve genellikle ‘2’ değerinde olurdu; Bölüm 1’deki Kerberoasting örneğinde de bunu görmüştük:
Event ID 4768 detayı – RC4 şifreleme ve pre-authentication yokluğu kanıtı: Bu üç görsel birlikte AS-REP Roasting’in imzasını net biçimde ortaya koyuyor: RC4 şifreleme, pre-authentication alanının boş olması ve komutun kurbanın parolasına hiç ihtiyaç duymadan çalışması. Hesap Kerberos ön kimlik doğrulaması gerektirecek şekilde bırakılsaydı (varsayılan durum), aynı komut `KDC_ERR_C_PRINCIPAL_UNKNOWN` veya ön kimlik doğrulaması hatasıyla başarısız olacaktı.
Uyumluluk ve Çerçeve Eşlemesi
| Çerçeve | İlgili Kontrol/Madde |
|---|---|
| PCI DSS | Gereksinim 8.2 (Güçlü kimlik doğrulama), Gereksinim 8.3 (MFA) |
| HIPAA | 164.312(d) – Kişi veya Varlık Kimlik Doğrulaması |
| 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) |
| CIS Controls | CIS 5 (Hesap Yönetimi), CIS 6 (Erişim Kontrol Yönetimi) |
MITRE ATT&CK: T1558.004 (Steal or Forge Kerberos Tickets: AS-REP Roasting)
Sonuç
AS-REP Roasting, Kerberoasting’e kıyasla daha dar bir saldırı yüzeyine sahip olsa da, ön kimlik doğrulaması devre dışı bırakılmış tek bir kullanıcı objesi bile saldırganlara yeterli olabilir. Tüm kullanıcı objelerinde Kerberos ön kimlik doğrulamasının zorunlu tutulması, bu tekniği tamamen etkisiz hale getiriyor. Serinin bir sonraki bölümünde, MFA korumasını dolanarak doğrudan Domain Controller’a karşı çalışan Password Spraying tekniğini ele alacağız.