Kerberoasting tespitini uzun süre tek bir kritere indirgemiştim: event ID 4769'da şifreleme türü 0x17 (RC4) görürsem şüphelenir, 0x12 (AES256) görürsem rahatlardım. Kendi test kümemde Rubeus'u /rc4opsec bayrağıyla çalıştırıp AES destekleyen hesaplara karşı denediğimde bu varsayımın çöktüğünü gördüm. Aşağıda hangi varyantın hangi telemetride iz bıraktığı, hangisinin bırakmadığı sıralı.
1. RC4 tabanlı klasik Kerberoasting'i yakala. msds-supportedencryptiontypes değeri ayarlanmamış SPN'li hesaplarda TGS-REQ varsayılan olarak RC4 ister. Domain Controller'da event ID 4769'u filtrele, Ticket Encryption Type alanı 0x17 olanları çek. Doğrulamak için kendi lab AD'nizde setspn -a HTTP/testsvc.lab.local svc_test ile SPN oluşturup Rubeus kerberoast komutunu çalıştırın, ardından Security log'da 4769'u arayın.
2. AES'e zorlanmış (opsec) varyantı ayrı kuralla ele al. /rc4opsec ya da /aes bayrağı kullanıldığında talep AES256 ile gelir ve şifreleme türü artık ayırt edici değildir. Bunun yerine TGS-REQ sıklığına, aynı kaynaktan kısa sürede birden fazla farklı SPN için istek gelmesine bak:
index=wineventlog EventCode=4769 | stats count by Account_Name, Service_Name | where count > 5
3. Kendi ortamınızda hangi hesapların RC4'e düşebileceğini önceden çıkarın. Local Elasticsearch üzerinden 4769 kayıtlarındaki encryption type dağılımını sorgulayabilirsiniz:
curl -i -X GET "http://192.168.1.50:9200/winlogbeat-*/_search" \
-H 'Content-Type: application/json' \
-d '{"query":{"match":{"event.code":"4769"}},"aggs":{"enc":{"terms":{"field":"winlog.event_data.TicketEncryptionType"}}}}'
Yanıt HTTP/1.1 200 OK ile döner, agregasyon bloğunda "key":"0x17" ve "key":"0x12" sayımları görülür. RC4 payının yüksekliği hâlâ düzeltilmemiş eski hesapların varlığını gösterir.
4. SPN taramasını CI pipeline'ına göm. Manuel denetim unutulur, otomasyon unutmaz. GitLab CI'da haftalık bir job:
ad-spn-audit:
stage: audit
script:
- python3 check_spn_enctype.py --domain lab.local --output report.json
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
report.json içinde msds-supportedencryptiontypes değeri boş ya da RC4 destekleyen hesapların listesi çıkar; liste boşsa opsec-uyumlu bir ortamınız var demektir.
5. Silver ticket üretimini ayrı izle. Kerberoasting sadece TGS kırmakla bitmez, kırılan hash ile üretilen silver ticket'lar 4769 üretmeden servise erişebilir. Bunun tek güvenilir izi hedef serviste anormal oturum açma zaman damgalarıdır; DC log'unda görünmez.
6. msds-supportedencryptiontypes değerini toplu düzelt. Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties msds-supportedencryptiontypes ile RC4'e açık hesapları listeleyip değeri 24 (yalnızca AES) olarak zorlamak tespit kuralınızın kör noktasını daraltır, ortadan kaldırmaz.