🎫 Golden Ticket
یکی از خطرناک ترین سناریوهای Kerberos
فرض کن مهاجم somehow به Key مربوط به KRBTGT دسترسی پیدا کرده.
از اینجا به بعد، داستان دیگه مثل Kerberoasting نیست که دنبال Password یک Service Account باشیم.
اینجا مهاجم میتونه یک TGT جعلی بسازه و خودش تعیین کنه این Ticket با چه Identity و چه Privilegeهایی مورد استفاده قرار بگیره.
اگر بخوایم خیلی ساده ببینیم:
🔴 KRBTGT Key
⬇️
🎫 Forged TGT
⬇️
🔑 Service Tickets
⬇️
🌐 Domain Services
یعنی اگر KRBTGT واقعاً compromise شده باشه، پتانسیل Impersonation در سطح Domain وجود داره.
اما سؤال مهمتر برای Defender اینه:
چطور متوجه Golden Ticket بشیم؟
یکی از مواردی که میشه بررسی کرد، ارتباط بین Eventهای:
4768 → TGT Request
و
4769 → TGS Request
مثلاً اگر برای یک User و Source مشخص، فعالیت TGS داشته باشیم اما TGT منطقی قبل از اون در لاگها دیده نشه، میتونه یک Signal مشکوک باشه.
ولی اینجا یک نکته خیلی مهم وجود داره:
❌ نبودن Event 4768 بهتنهایی یعنی Golden Ticket نداریم یا داریم؟ هیچکدوم.
ا TGTها Cache میشن، لاگها ممکنه کامل نباشن و سناریوهایی مثل Cross-Domain Authentication هم میتونن تحلیل رو پیچیدهتر کنن.
برای همین Detection واقعی باید چند نشونه رو کنار هم بذاره:
🔹 User & Source IP
🔹 Events 4768 / 4769
🔹 Events 4624 / 4672 on the Target System
🔹 Actual Account Status
🔹 Ticket Lifetime
🔹 Encryption Type
🔹 Normal & Abnormal User Behavior
🔹 Evidence of DCSync or Credential Dumping
و اگر در نهایت مشخص بشه که KRBTGT واقعاً compromise شده، دیگه با یک Incident معمولی طرف نیستیم.
باید باهاش مثل یک Tier-0 / Domain Compromise برخورد کرد.
در مرحله Recovery هم، بعد از Containment و بررسی دقیق، یکی از اقدامات اصلی Reset کنترل شده Password حساب KRBTGT در دو مرحله است؛ با توجه جدی به Replication بین Domain Controllerها و وضعیت کل محیط.
به نظرم این دقیقاً یکی از جاهاییه که نشون میده:
فهمیدن Kerberos خیلی مهم تر از حفظ کردن چندتا کامنده.
وقتی بفهمی Ticketها چطور کار میکنن، بهتر متوجه میشی چرا compromise شدن KRBTGT میتونه کل Domain رو تحت تأثیر قرار بده.
@KavehOffSec
#ActiveDirectory #GoldenTicket #Kerberos #RedTeam
Post #238
869
- ❤ 6
- 🔥 2