AS, TGS ve AP akışı: TGT ile service ticket arasındaki fark.

1. Core Mechanism / Temel mekanizma

Kerberos istemcisi (WS01), KDC rolündeki domain controller (DC01) ve hedef servisin çalıştığı host (FS01) arasında, TCP/UDP 88 üzerinden yürüyen üç mesaj değişimi. Karar noktaları Windows'ta LSA/Kerberos SSP (istemci), KDC servisi (DC) ve servis tarafındaki SSPI kabulüdür. Bu dersin sınırı KDC yanıtının yapısıdır: PAC içeriği 06.05'te, SPN sahipliği 06.03'te, pre-authentication ayrıntısı 06.04'tedir.

Arabirimler ve belirtimler

• RFC 4120 §5.4.2: AS-REP ::= [APPLICATION 11] KDC-REP, TGS-REP ::= [APPLICATION 13] KDC-REP.
• RFC 4120 §5.3: Ticket ::= [APPLICATION 1] SEQUENCE { tkt-vno, realm, sname, enc-part }.
• RFC 4120 §5.2.9: EncryptedData ::= SEQUENCE { etype [0], kvno [1] OPTIONAL, cipher [2] }.
• RFC 4120 §7.5.1 key usage: 2 (ticket enc-part, servis anahtarı), 3 (AS-REP enc-part, istemci anahtarı), 8/9 (TGS-REP enc-part, TGS oturum anahtarı veya authenticator subkey).
• RFC 4120 §5.5.1: AP-REQ ::= [APPLICATION 14] SEQUENCE { pvno, msg-type, ap-options, ticket, authenticator }.
• Windows Security kanalı: 4768 (AS), 4769 (TGS), 4771 (pre-auth hatası); yalnız domain controller üzerinde.

Üç değişim, tek soru: bu mesajı kim açabilir?

tunahan kullanıcısı WS01'de oturum açtığında istemci önce AS değişimini yürütür ve krbtgt/IYELABS.EXAMPLE için bir TGT alır. Daha sonra \\FS01\ortak paylaşımına eriştiğinde istemci bu TGT'yi kullanarak TGS değişimini yürütür ve cifs/FS01.iyelabs.example için bir service ticket alır. Son olarak AP değişiminde bileti FS01'e sunar.

Üç adımın da aynı soruyu farklı taraflara sorduğunu fark et: elindeki şifreli bölümü açacak anahtara kim sahip? Kerberos'ta bir mesajın "kime ait" olduğunu belirleyen şey mesajın adı değil, o bölümü hangi uzun süreli veya oturum anahtarının koruduğudur.

Bu yüzden TGT ile service ticket arasındaki fark yapısal değildir. İkisi de aynı Ticket tipidir. Fark sname alanında ve enc-part'ı koruyan anahtarda ortaya çıkar: TGT'nin sname'i krbtgt/REALM'dir ve enc-part'ı krbtgt hesabının anahtarı korur; service ticket'ın sname'i hedef SPN'dir ve enc-part'ı o SPN'in kayıtlı olduğu hesabın anahtarı korur.

KDC yanıtında ticket ve enc-part kardeş alanlardır

Yaygın çizimler KDC yanıtını iç içe geçmiş iki zarf gibi gösterir. RFC 4120 §5.4.2'deki tanım bunu desteklemez: ticket [5] ve enc-part [6] aynı SEQUENCE içinde yan yana duran iki alandır.

İstemci ticket [5] alanını okuyabilir, fakat içindeki ticket.enc-part.cipher içeriğini açamaz. Yanıtın kendisine yönelik enc-part [6] alanındaki cipher içeriğini ise uygun anahtarla açar. Bilette tkt-vno, realm ve sname açıkça görülebilir. Ayrıca EncryptedData içindeki etype ve varsa kvno da okunabilir; şifreli olan cipher içeriğidir. Bu alanları görmek, biletteki oturum anahtarını veya authorization-data içeriğini öğrenmek anlamına gelmez.

İstemcinin servis oturum anahtarı Kc,s'yi öğrenmesinin yolu bileti açmak değil, kendi yanıt bölümünü açmaktır. Kc,s hem biletin içine (servis için) hem de yanıtın kendi bölümüne (istemci için) ayrı ayrı yerleştirilmiştir.

KDC-REP ::= SEQUENCE {
        pvno            [0] INTEGER (5),
        msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
        padata          [2] SEQUENCE OF PA-DATA OPTIONAL,
        crealm          [3] Realm,
        cname           [4] PrincipalName,
        ticket          [5] Ticket,          -- servis anahtariyla korunur
        enc-part        [6] EncryptedData    -- istemciye ait bolum
}

EncryptedData ::= SEQUENCE {
        etype   [0] Int32,
        kvno    [1] UInt32 OPTIONAL,
        cipher  [2] OCTET STRING
}

TGS-REP'i açan anahtar kullanıcının parolası değildir

AS-REP'in reply enc-part'ı olağan parola tabanlı akışta client long-term key'iyle korunur; RFC 4120 §5.4.2, pre-authentication mekanizmasının seçtiği başka reply key'e de izin verir. TGS-REP'te ise authenticator subkey varsa o, yoksa TGT session key'i kullanılır. Bu dersin AS adımları parola tabanlı örnektir; TGS yanıtını açmak için kullanıcının parolası yeniden kullanılmaz.

Aynı paragraf biçimsel bir iz de verir: TGS-REP yanıt bölümünde kvno alanı bulunmaz. Bunun nedeni RFC 4120 §5.2.9'daki kuraldır; kvno yalnızca uzun ömürlü anahtarlarla şifrelenmiş mesajlarda anlamlıdır. Oturum anahtarının sürümü yoktur, çünkü oturum anahtarı zaten o değişime özgüdür.

Key usage numaraları bu ayrımı sayısallaştırır (RFC 4120 §7.5.1): ticket enc-part için 2, AS-REP yanıt bölümü için 3, TGS-REP yanıt bölümü için TGS oturum anahtarı kullanılıyorsa 8, authenticator subkey kullanılıyorsa 9. Yani "aynı AES anahtarı" bile olsa farklı amaçlar için farklı türetilmiş anahtar kullanılır.

Pratik sonuç: kullanıcı parolasını değiştirdiğinde eldeki TGT geçerli kalır ve o TGT ile yeni service ticket'lar alınmaya devam edilebilir. Çünkü TGS değişimi kullanıcının uzun süreli anahtarına hiç dokunmaz.

AP değişiminde iki kilit sırayla açılır

FS01 bir AP-REQ aldığında önce bileti kendi anahtarıyla çözer. RFC 4120 §3.2.3 bu sırayı zorunlu kılar: bilet çözülür, çözülen EncTicketPart içinden oturum anahtarı çıkarılır, ardından authenticator bu oturum anahtarıyla çözülür.

Sıra önemlidir çünkü servis, authenticator'ı açacak anahtarı ancak bileti açtıktan sonra öğrenir. Bu yüzden servis anahtarı yanlışsa hata bütünlük hatası ailesindedir (KRB_AP_ERR_BAD_INTEGRITY), authenticator zamanı toleransın dışındaysa hata KRB_AP_ERR_SKEW'dir. İkisi farklı aşamaların hatasıdır ve aynı kutuya konulamaz.

Biletin kvno alanı da burada iş görür: servis, biletin hangi anahtar sürümüyle şifrelendiğini dış alanlardan okur. O sürüme ait anahtar artık elinde yoksa RFC 4120 §3.2.3 uyarınca KRB_AP_ERR_BADKEYVER döner. Servis hesabının parolası yakın zamanda değiştiyse bu hata beklenen bir davranıştır.

AP-REQ’i göndermek ile servisin kabul kararı aynı işlem değildir. FS01 bileti ve authenticator’ı kendi üzerinde işler; örneğin zaman denetimi burada KRB_AP_ERR_SKEW ile reddedilebilir. Bu görselde ret, servisin yerel kararını gösterir. Gerçek protokolde KRB-ERROR ayrı bir yanıttır; gönderilmiş AP-REQ’in geri sıçraması değildir.

Bilet almak yetki almak değildir

RFC 4120 §1.4 ve §10 bu konuda kesindir: bir servis bileti düzenlenmiş olması, istemcinin o servisi kullanmaya yetkili olduğu anlamına gelmez. Kerberos kimliği doğrular; yetkilendirme ayrı bir karardır.

Windows'ta bu ayrım somut olarak görünür. tunahan, cifs/FS01.iyelabs.example için bilet alabilir; FS01 bileti başarıyla doğrulayabilir; ve yine de dosyaya erişim DACL değerlendirmesinde reddedilebilir. Kerberos katmanının sonucu "kim" sorusunu, AccessCheck'in sonucu "ne yapabilir" sorusunu yanıtlar.

Bu yüzden 4769 başarı kaydı ile dosya erişiminin gerçekleşmesi aynı olay değildir. Telemetride bunları ayrı tutmak, ders boyunca izlediğimiz tek örneğin sonunu doğru okumayı sağlar.

AP-REP her akışta zorunlu değildir

İstemci mutual-required seçeneğini açtıysa servis AP-REP ile karşılık verir. Seçenek kapalıysa bu karşılıklı doğrulama yanıtı atlanabilir. İki durumda da kaynak izni ayrıca değerlendirilir; AP-REP almak READ hakkı kazanmak değildir.

RFC 4120 §3.2.4, AP-REP’in enc-part alanını biletten alınan Kc,s ile korur. AP authenticator içinde isteğe bağlı bir subkey bulunsa bile AP-REP’i açan anahtar o subkey değildir. TGS-REP yanıtında ise authenticator subkey varsa onu kullanma kuralı geçerlidir (§5.4.2).

Yukarıdaki modelin alan açma düğmeleri, seçili gözlemcinin anahtar erişimini inceletir. Kriptografi çalıştırmaz. Önceki adım, doğrudan adım seçimi ve gözlemci değişimi mesaj göndermez; aşağıdaki dokuz açıklama adımı, modeldeki sekiz durumla bire bir eşleşmek zorunda değildir.

KDC reddi ile kaynak reddi aynı karar değildir

Geçerli TGT ve kayıtlı SPN, talebin mutlaka başarılı olacağı anlamına gelmez. Örnekte KDC policy’si TGS-REQ’i reddederse KDC_ERR_POLICY (12 / 0x0C) sonucu oluşur ve service ticket düzenlenmez. FS01 henüz bir bilet doğrulamamış veya dosya iznini değerlendirmemiştir. Buna karşılık başarılı bilet düzenleme ve AP doğrulamasından sonraki READ reddi, FS01’in kaynak kararıdır. Modelde iki senaryoyu seçip karar yerini karşılaştır; bunlar sabit öğretim sonuçlarıdır, gerçek bir KDC policy motoru çalışmaz.

Buradan sonraki mekanizmaya

02.03’te process token’ının hangi kimlik bağlamında oluştuğunu gördün. Ticket içindeki PAC bilgisi ile hedefin kullandığı access token aynı nesne değildir; hedefte context oluşturma ve requested right kontrolü ayrı adımlardır. 08.01’de directory üyeliği sonradan değişince bu eski context’in neden kendiliğinden yenilenmediğini karşılaştıracağız.

Durum ve veri akışı

1. WS01 oturum açılışında AS-REQ gönderir; KDC AS-REP ile TGT'yi (sname=krbtgt/IYELABS.EXAMPLE) ve Kc,tgs içeren yanıt bölümünü döner.
2. Bu parola tabanlı örnekte client AS reply enc-part'ını long-term key'iyle açıp Kc,tgs'yi alır; TGT'yi açmaz. Başka pre-authentication yollarında reply key farklı seçilebilir.
3. Kullanıcı \\FS01\ortak yoluna eriştiğinde istemci TGS-REQ hazırlar: padata içinde TGT'yi taşıyan AP-REQ ve Kc,tgs ile şifrelenmiş authenticator, req-body içinde sname=cifs/FS01.iyelabs.example.
4. KDC TGT'yi krbtgt anahtarıyla açar, authenticator'ı Kc,tgs ile doğrular ve istenen SPN'in hangi hesaba kayıtlı olduğunu dizinde çözer.
5. KDC yeni bir Kc,s üretir; service ticket'ın enc-part'ını FS01 hesabının anahtarıyla, TGS-REP enc-part'ını Kc,tgs veya sunulan subkey ile şifreler. DC01 bu noktada 4769 üretir.
6. İstemci TGS-REP enc-part'ını açar, Kc,s'yi alır; service ticket'ı açmadan saklar.
7. İstemci AP-REQ ile bileti ve Kc,s ile şifrelenmiş yeni bir authenticator'ı FS01'e sunar.
8. FS01 önce bileti kendi anahtarıyla açar, içinden Kc,s'yi alır, sonra authenticator'ı doğrular; mutual authentication istendiyse AP-REP döner.
9. Kimlik doğrulandıktan sonra FS01 istenen erişim için ayrı bir yetkilendirme kararı verir; bu karar Kerberos mesajı değildir.

2. Exploitation / İstismar

Broken trust assumption

Yanlış varsayım, TGS’in hedef kaynaktaki erişim iznini verdiğini düşünmektir. Geçerli TGT sahibi bir principal, kaynakta erişim hakkı olmasa da kayıtlı bir SPN için service ticket isteyebilir. Ancak biletin düzenlenmesi koşulsuz değildir: KDC policy’si, desteklenen istek seçenekleri ve etype gibi kontroller talebi reddedebilir. Başarılı standart TGS değişiminde biletin şifreli içeriğini hedef hesabın uzun süreli anahtarı korur; kaynak servisteki kimlik doğrulama ve erişim kararı daha sonra yapılır.

Technical prerequisites

• Domain hesabı ve geçerli TGT. Ayrıcalıklı üyelik tek başına gerekli değildir; KDC’nin talebi policy ve protokol kontrolleri açısından kabul etmesi de gerekir.
• DC01'e 88/tcp erişimi.
• Hedef SPN'in servicePrincipalName özniteliği üzerinden bir hesaba kayıtlı olması; SPN yoksa KDC KDC_ERR_S_PRINCIPAL_UNKNOWN (0x7) döner.
• Hedef hesabın anahtarının tahmin edilebilir bir parolaya dayanması. Bu şart sağlanmazsa elde edilen ciphertext üzerinde çevrimdışı deneme anlamlı sonuç vermez.
• Hedef hesabın RC4 gibi zayıf bir etype ile bilet vermeye razı olması denemeyi hızlandırır; yalnız AES kabul eden bir yapılandırma işi belirgin biçimde zorlaştırır.

Exploitation mechanism / İstismar mekanizması

Mekanizma bir zafiyet değil, protokolün tasarımının yanlış anlaşılmasıdır. TGS-REP'in ticket [5] alanı, hedef hesabın uzun süreli anahtarı ile ve key usage 2 altında şifrelenmiş bir ciphertext'tir. Bu ciphertext ağdan alınabilir ve çevrimdışı olarak parola adayları denenebilir; doğru aday bulunduğunda hedef hesabın anahtarı elde edilir. Elde edilen şey erişim değil, o hesabın kimliğini üstlenme imkanıdır. Kerberos açısından hiçbir kural çiğnenmemiştir; çiğnenen şey "servis hesabı parolası insan tarafından seçilebilir" varsayımıdır.

Bilet talebi neden bir yetki kontrolü değildir

KDC, bilet üretirken hedef kaynağın DACL'ine bakmaz. Bakamaz da: kaynak üzerindeki izin kararı o kaynağı barındıran hostta, istenen erişim maskesi ve güvenlik bağlamıyla birlikte verilir. KDC bu bilgilerin hiçbirine sahip değildir.

Bu yüzden 4769 kaydında Status 0x0 görmek, istemcinin hedefe erişebildiğini göstermez. Aynı şekilde erişimin reddedilmiş olması da 4769'un başarısız olmasını gerektirmez.

Saldırgan açısından bu, hedefe hiç dokunmadan hedefin anahtar materyaline dayalı bir ciphertext elde etmek demektir. Hedef servis bu talepten haberdar olmaz; kayıt DC'dedir.

Hangi alanlar işi kolaylaştırır

Ticket içindeki EncryptedData'nın etype alanı, çevrimdışı denemenin maliyetini doğrudan belirler. Eski RC4 tabanlı etype'lar, AES tabanlı olanlara göre çok daha ucuz denenir.

kvno alanı hangi anahtar sürümünün kullanıldığını söyler. Servis hesabının parolası yakın zamanda döndürüldüyse eski ciphertext üzerinde yapılan çalışma güncel anahtarı vermez.

sname alanı hedefi açıkça yazar. Bu alan şifreli değildir; dolayısıyla elde edilen ciphertext'in hangi hesaba ait olduğu belirsiz değildir.

Nerede etkisiz kalır

Hedef hesabın anahtarı insan tarafından seçilmiş bir paroladan türetilmiyorsa mekanizma sonuç vermez. Grup yönetilen servis hesaplarında parola otomatik üretilir ve düzenli döndürülür; bu durumda çevrimdışı deneme pratik bir yol olmaktan çıkar.

Makine hesaplarına kayıtlı SPN'ler de benzer durumdadır, çünkü makine hesabı parolaları otomatik yönetilir.

Etki, ele geçirilen servis hesabının kapsamıyla sınırlıdır. "Servis hesabı ele geçti" ifadesi tek başına domain'in ele geçtiği anlamına gelmez; o hesabın üyelikleri, kayıtlı olduğu SPN'ler ve üzerindeki nesne hakları ayrı ayrı değerlendirilir.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Audit Kerberos Service Ticket Operations alt kategorisi, Success: 4769 kayıtlarını üretir. Failure ayarı 4769'un başarısız örneklerini üretir.
• Audit Kerberos Authentication Service alt kategorisi: 4768 ve 4771. AS ve TGS aşamalarını karıştırmamak için ikisi birlikte açılır.
• Her iki olay da yalnızca domain controller üzerinde oluşur. Nesne SACL'i gerekmez; bunlar dizin nesnesi erişim denetimi değil, KDC işlem kayıtlarıdır.
• Kaynak tarafındaki erişim kanıtı ayrı bir kaynaktan gelir: FS01 üzerindeki logon ve nesne erişim denetimi. Bu ders kapsamında ayrı bir gözlem noktası olarak ele alınır.
• 4769 hacmi yüksektir. Toplama kararı, saklama süresi ve filtreleme önceden planlanmazsa kayıtlar analiz edilemeyecek kadar büyür.

Events and relevant fields

• 4769 / ServiceName: biletin düzenlendiği hesap veya bilgisayar adı. Makine hesapları $ ile biter.
• 4769 / ServiceSid: hedef hesabın SID'i. Başarısız kayıtlarda NULL SID görülebilir.
• 4769 / TargetUserName: istemci, normalize edilmiş UPN biçiminde. Bu alan hesabın userPrincipalName özniteliğinin birebir değeri değildir.
• 4769 / TicketEncryptionType: düzenlenen service ticket'ın etype'ı, yani servis hesabının anahtarıyla korunan bölümün algoritması. 0x12 = AES256-CTS-HMAC-SHA1-96, 0x17 = RC4-HMAC.
• 4769 / SessionKeyEncryptionType: Version 2 kaydında bulunur ve oturum anahtarının etype'ıdır. Bu iki alanın farklı olabilmesi, dersin anahtar ayrımını telemetride doğrudan gösterir.
• 4769 / Status: KDC sonucu. 0x0 hata yok; 0x20 KRB_AP_ERR_TKT_EXPIRED, rutin ve çoğunlukla güvenlik anlamı taşımaz.
• 4769 / LogonGuid: hedef bilgisayardaki 4624, 4648 ve 4964 kayıtlarıyla korelasyon için kullanılabilir. Yakalanamadığında sıfır GUID görünür.
• 4769 / Version: klasik kayıt 0, 14 Ocak 2025 ve sonrası güvenlik güncellemesini almış Windows Server 2016+ üzerinde 2. Sürüm farkı hangi alanların var olduğunu belirler; sorgular bunu varsaymadan yazılmalıdır.

Hangi kaydın hangi soruyu yanıtladığını ayır

Başarılı 4768 kaydı TGT, başarılı 4769 kaydı service ticket düzenleme sonucunu gösterir. Başarısız 4769 ise TGS talebinin hata sonucudur; 4771 pre-authentication hatasını gösterir. Bunlar KDC tarafındaki işlemlerle ilgilidir; hedef kaynaktaki erişimi tek başına kanıtlamaz.

Bir erişimin gerçekten gerçekleştiğini görmek için kaynak tarafına bakmak gerekir. DC üzerindeki 4769 ile FS01 üzerindeki oturum ve nesne erişim kayıtları farklı gözlem noktalarıdır ve saat farkı, kayıt gecikmesi ve toplama kapsamı nedeniyle birebir eşleşmeyebilir.

LogonGuid alanı bu iki noktayı bağlamak için tasarlanmıştır fakat her kayıtta dolu olmayabilir. Yakalanamadığı durumda sıfır GUID görünür ve korelasyon zaman ile hesap üzerinden, daha zayıf bir kesinlikle kurulur.

DC01’deki bilet düzenleme kaydı, FS01’deki AP doğrulamasını veya dosya erişim kararını tek başına doğrulamaz. Saat farkı senaryosunda incelemen gereken sınır servisin AP kontrolüdür; READ reddinde ise kaynak iznidir. Model bu ayrımı gösterir, gerçek Windows kayıtlarını üretmez.

İki etype alanı, iki farklı anahtar

Güncel 4769 kaydında TicketEncryptionType ve SessionKeyEncryptionType ayrı alanlardır. Birincisi biletin servis anahtarıyla korunan bölümünün algoritmasıdır; ikincisi oturum anahtarının algoritmasıdır.

Bu ayrım dersin çekirdek fikrinin telemetrideki karşılığıdır: aynı yanıtta birden fazla anahtar vardır ve hepsi aynı tarafa ait değildir. Sertleştirme ölçerken hangi alanı izlediğini bilmek gerekir.

Version 0 kayıtlarında SessionKeyEncryptionType bulunmaz. Sorgu bu alanı zorunlu sayarsa eski kayıtlarda sessizce hiçbir şey döndürmez. Eksik alan davranışı sorgunun bir parçası olarak yazılmalıdır.

Gozlem noktasi        Kayit            Yanitladigi soru
--------------------  ---------------  ------------------------------------
DC01 (KDC)            4768 success     TGT duzenlendi mi?
DC01 (KDC)            4769 success     Hedef hesap icin bilet duzenlendi mi?
DC01 (KDC)            4769 failure     TGS talebi basarisiz mi oldu?
DC01 (KDC)            4771             Pre-auth basarisiz mi oldu?
FS01 (kaynak host)    oturum/erisim    Kaynakta erisim izni verildi mi?

ServiceName sayısı neden SPN sayısı değildir?

Sentetik örnekte svc_files hesabına cifs/FS01 ve cifs/dosyalar SPN’leri kayıtlı olsun. İki farklı SPN için yapılan talepler 4769’da aynı svc_files ServiceName değeriyle görünebilir. Distinct ServiceName sayımı bunu tek hedef hesap olarak sayar; iki ayrı SPN olarak sayamaz. Directory envanteri hangi SPN’lerin hesaba kayıtlı olduğunu gösterebilir, fakat bu kayıttan talepteki tam SPN’yi tek başına geri çıkarmaz.

Detection logic · Sigma

title: Basarili TGS kayitlari - hedef hesap korelasyonu icin aday secimi
id: 5f3f0f2a-0b2e-4f5b-9c11-06e0b2a0c102
status: experimental
description: >
  Basarili 4769 kayitlarini secer. ServiceName hedef hesap veya bilgisayar adidir,
  talepteki tam SPN metni degildir. Zaman penceresi ve distinct ServiceName sayimi
  bu selection disinda uygulanmalidir. Tek basina alarm veya saldiri kaniti degildir.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    Status: '0x0'
  filter_machine_accounts:
    ServiceName|endswith: '$'
  filter_krbtgt:
    ServiceName|startswith: 'krbtgt'
  condition: selection and not 1 of filter_*
fields:
  - TargetUserName
  - ServiceName
  - ServiceSid
  - TicketEncryptionType
  - IpAddress
  - LogonGuid
falsepositives:
  - Envanter, yedekleme ve izleme ajanlari
  - Cok sayida servise baglanan uygulama sunuculari
level: low

Query assumptions

• Bu Sigma selection, korelasyona aday başarılı kayıtları seçer; zaman penceresinde gruplama veya distinct sayım yapmaz. IpAddress ve TargetUserName ile gruplama, farklı ServiceName değerlerini sayma ve eşik karşılaştırması backend tarafında ayrıca kurulmalıdır.
• ServiceName, ticket istenen hesap veya bilgisayar adıdır; doğrudan SPN ya da servis-instance sayısı değildir. ServiceSid ve directory envanteri hesap bağlamını zenginleştirebilir, fakat tek ServiceName değeri talepte hangi SPN’nin kullanıldığını belirlemez.
• Alan adları Windows Security kanalındaki EventData adlarıdır. Backend farklı isimlendirme kullanıyorsa (örneğin normalize edilmiş bir şema) field mapping ayrıca yapılmalıdır.
• Status alanı bazı backendlerde tamsayı, bazılarında '0x0' biçiminde metin olarak saklanır. Eşleşme türü hedef şemaya göre doğrulanmalıdır.
• Makine hesabı ve krbtgt filtreleri gürültüyü azaltır fakat kapsamı da daraltır; makine hesabına kayıtlı SPN'ler bu kuralla görünmez.
• Bu kural bu oturumda gerçek bir SIEM üzerinde çalıştırılmadı. Yalnızca alan adları ve olay semantiği birincil kaynağa göre doğrulandı.

False positives

• Yedekleme, envanter ve izleme ajanları kısa sürede farklı servis hesapları için bilet isteyebilir. Bu nedenle kayıtlardaki artışı normal davranışla karşılaştır.
• Bir uygulama sunucusunun arka uç servislerine toplu bağlanması aynı deseni üretir.
• Kullanıcı oturum açılışında istemci birkaç servise sırayla bilet ister; tek başına oturum açma da desene benzeyebilir.
• Negatif örnek: hedef hesabın anahtarı zaten elde edilmişse saldırganın yeni bilet istemesine gerek kalmaz ve bu kural hiçbir şey görmez. Kural bir kapsam sınırıdır, kanıt değildir.

Hardening

• Önce envanter: hangi SPN hangi hesapta kayıtlı, hangi hesabın parolası insan tarafından yönetiliyor? Bu liste çıkarılmadan yapılan etype veya hesap değişiklikleri servis kesintisi üretir.
• İnsan yönetimli servis hesaplarını, parolası otomatik üretilen ve döndürülen hesap türlerine taşı. Bu, çevrimdışı deneme mekanizmasını hedefsiz bırakır.
• Etype politikasını aşamalı sertleştir: önce mevcut kullanımı TicketEncryptionType dağılımıyla ölç, sonra pilot kapsamda uygula, geri dönüş yolunu hazır tut. Doğrudan domain genelinde RC4 kapatmak bağımlı uygulamaları kırabilir.
• Kullanılmayan SPN kayıtlarını temizle. Kayıtlı olmayan bir SPN için bilet üretilemez.
• Denetim tarafında 4769 toplamayı planla: hacim, saklama ve filtre kuralları önceden belirlenmezse kayıt ya toplanmaz ya da kullanılamaz hale gelir.
• Doğrulama adımı: değişiklik sonrası aynı iş akışını tekrarla ve 4769 kayıtlarında TicketEncryptionType değerinin beklenen seviyeye geçtiğini, Status'un 0x0 kaldığını gör.

Örnekler üzerinde oku / Read the examples

6d 81 b4 30 81 b1 a0 03 02 01 05 a1 03 02 01 0d
a3 11 1b 0f 49 59 45 4c 41 42 53 2e 45 58 41 4d
50 4c 45 a4 14 30 12 a0 03 02 01 01 a1 0b 30 09
1b 07 74 75 6e 61 68 61 6e a5 63 61 61 30 5f a0
03 02 01 05 a1 11 1b 0f 49 59 45 4c 41 42 53 2e
45 58 41 4d 50 4c 45 a2 27 30 25 a0 03 02 01 02
a1 1e 30 1c 1b 04 63 69 66 73 1b 14 46 53 30 31
2e 69 79 65 6c 61 62 73 2e 65 78 61 6d 70 6c 65
a3 1c 30 1a a0 03 02 01 12 a1 03 02 01 03 a2 0e
04 0c a5 5a a5 5a 01 02 03 04 05 06 07 08 a6 17
30 15 a0 03 02 01 12 a2 0e 04 0c f0 0f f0 0f 09
0a 0b 0c 0d 0e 0f 10

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4769</EventID>
    <Version>2</Version>
    <Level>0</Level>
    <Task>14337</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-28T09:14:31.7420000Z" />
    <EventRecordID>10486</EventRecordID>
    <Correlation />
    <Execution ProcessID="712" ThreadID="1048" />
    <Channel>Security</Channel>
    <Computer>DC01.iyelabs.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">tunahan@IYELABS.EXAMPLE</Data>
    <Data Name="TargetDomainName">IYELABS.EXAMPLE</Data>
    <Data Name="ServiceName">FS01$</Data>
    <Data Name="ServiceSid">S-1-5-21-111111111-222222222-333333333-1108</Data>
    <Data Name="TicketOptions">0x40810000</Data>
    <Data Name="TicketEncryptionType">0x12</Data>
    <Data Name="IpAddress">::ffff:192.0.2.21</Data>
    <Data Name="IpPort">51477</Data>
    <Data Name="Status">0x0</Data>
    <Data Name="LogonGuid">{8f2a4c11-5d90-4a37-9be2-71c4ad0f3e55}</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="SessionKeyEncryptionType">0x12</Data>
  </EventData>
</Event>

İki yanlış kanı / Two reality checks

Sanılan: Bir servis için bilet alabiliyorsam o servise erişebilirim.

Gerçekte: Hayır. RFC 4120 §1.4 ve §10, bilet düzenlenmesinin yetkilendirme sayılmamasını açıkça belirtir; uygulama sunucusu ayrı bir yetkilendirme kararı vermelidir. Windows'ta bu karar kaynak hostta, istenen erişim maskesi ve güvenlik bağlamı ile DACL üzerinden verilir. Pratik sonuç: 4769 Status 0x0 kaydı ile dosyaya erişimin gerçekleşmesi iki ayrı olaydır; ilki ikincisinin kanıtı değildir.

Sanılan: TGS-REP'in şifreli bölümünü açmak için kullanıcının parolasından türetilen anahtar gerekir; bu yüzden parola değişince eldeki biletler işe yaramaz.

Gerçekte: TGS-REP'in enc-part'ı, RFC 4120 §5.4.2 uyarınca authenticator'daki sub-session key ile, o yoksa TGT'nin oturum anahtarıyla şifrelenir; kullanıcının uzun süreli anahtarı kullanılmaz. Biçimsel iz de bunu doğrular: bu EncryptedData'da kvno alanı bulunmaz, çünkü §5.2.9 uyarınca kvno yalnızca uzun ömürlü anahtarlar için anlamlıdır. Bu yüzden parola değiştirildikten sonra da eldeki TGT ile yeni service ticket alınabilir; bilet ömrü parola değişikliğiyle değil, kendi endtime ve renew-till değerleriyle sınırlıdır.

Kaynaklar / Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §5.4.2 KRB_KDC_REP (ticket [5] ve enc-part [6]; TGS-REP enc-part sub-session key veya TGT oturum anahtarı, kvno yok), §5.2.9 EncryptedData/kvno, §5.3 Ticket ve EncTicketPart, §7.5.1 key usage 2/3/8/9, §3.2.3 AP-REQ doğrulama sırası ve KRB_AP_ERR_BADKEYVER, §1.4 ve §10 yetkilendirme ayrımı, §6.2 NT-PRINCIPAL/NT-SRV-INST.; §§3.2.3–3.2.5 local AP validation, mutual-required and AP-REP encrypted with ticket session key (not AP authenticator subkey).
• Microsoft · 4769(S, F) A Kerberos service ticket was requested
  Subcategory Audit Kerberos Service Ticket Operations; Task 14337; Version 0 ve Version 2 Event XML örnekleri; EventData alan tanımları (ServiceName, ServiceSid, TicketEncryptionType, SessionKeyEncryptionType, Status, LogonGuid); etype tablosu 0x12 ve 0x17; Failure Code 0x0 ve 0x20.
• Microsoft · Kerberos authentication overview
  Windows'ta KDC rolünün domain controller üzerinde konumlanması ve AS/TGS ayrımının ürün terminolojisindeki karşılığı.
• Microsoft · How DACLs control access to an object
  Erişim kararının kaynak üzerinde, istenen erişim hakları ve güvenlik bağlamı ile verilmesi; kimlik doğrulamadan ayrı bir adım olması.
• Microsoft Service principal names
  Service instance identifiers, aliases/multiple SPNs, registration on account object