Merhaba
Serinin ilk bölümünde Kerberoasting’i ele almış, SPN (Service Principal Name) 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 (Ticket Granting Ticket)’yi içeren AS-REP mesajıyla yanıt verir.
- Saldırgan, TGT (Ticket Granting Ticket)’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 Granting Ticket) 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 (Ticket Granting Ticket) 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 (Ticket Granting Ticket) taleplerinin yapıldığı durumları tespit etmektir.
Aşağıdaki Event ID’ler merkezi olarak loglanmalı ve zamanında analiz edilmelidir.
AS-REP Roasting’i Tespit Eden Olaylar
| Event ID | Kaynak | Açıklama |
|---|---|---|
| 4625 | Domain Controller’lar | Bir hesap oturum açmayı başaramadığında üretilir. AS-REP Roasting, kimlik doğrulamadan önce çalıştırılabilir; yani saldırganların yalnızca domain’e bağlı olması yeterlidir, geçerli bir kullanıcı objesine ihtiyaç yoktur. AS-REP ticket’i yine de alınır, ancak ticket talep edilirken geçerli kimlik bilgileri sağlanmadığından event 4625 üretilir. AS-REP Roasting geçerli bir kullanıcı objesi bağlamında çalıştırılırsa, AS-REP ticket’i alınır, geçerli kimlik bilgileri sağlanır ve event 4625 üretilmez. Event 4625, AS-REP Roasting’in geçerli bir domain kullanıcı objesi bağlamında çalıştırılıp çalıştırılmadığını doğrulamak için event 4768 ile ilişkilendirilebilir. |
| 4738, 5136 | Domain Controller’lar | Bir kullanıcı hesabı değiştirildiğinde üretilir. Saldırganlar, AS-REP ticket’ini almak için bir teknik olarak kullanıcı objelerini değiştirip Kerberos ön kimlik doğrulamasını gerektirmeyecek şekilde yapılandırabilir. AS-REP ticket servisi alındıktan sonra kullanıcı objesi tekrar değiştirilir ve Kerberos ön kimlik doğrulaması yeniden gerektirilir. Bu olaylar Kerberos ön kimlik doğrulamasındaki değişiklikler için üretiliyorsa, AS-REP Roasting’in gerçekleştiğine işaret edebilir. |
| 4768 | Domain Controller’lar | Bir TGT (Ticket Granting Ticket) talep edildiğinde üretilir. AS-REP Roasting uygulayan saldırganlar, Domain Controller’dan dönen AS-REP mesajının bir TGT (Ticket Granting Ticket) içermesi nedeniyle bu olayı tetikler. Bu olay kısa bir zaman aralığında birden fazla kez tetikleniyorsa, AS-REP Roasting’in gerçekleştiğine işaret edebilir. Saldırganlar genellikle Rivest Cipher 4 (RC4) şifrelemesiyle TGT (Ticket Granting Ticket) ticket’ları talep eder, çünkü bu ticket’lar kırılarak düz metin parola elde etmek daha kolaydır. RC4 şifrelemesiyle TGT (Ticket Granting Ticket) 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 event’lerin daha az olması beklenir, bu da potansiyel AS-REP Roasting aktivitesini tespit etmeyi kolaylaştırır. |
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 "[email protected]" -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.
