İstemci, KDC, servis ve krbtgt: Kerberos’un aktörleri ve güven ilişkileri.

1. Core Mechanism / Temel mekanizma

Karar, bir principal başka bir principal'a kanıtlanmak istediğinde KDC üzerinde verilir: KDC, sunduğu bileti kimin anahtarıyla mühürleyeceğine ve doğrulayacağına karar verir. Bu dersin sınırı aktörlerin kimliği, anahtar sahipliği ve güven ilişkisidir; AS-REQ/TGS-REQ akışının tam alan yapısı ve ticket ile KDC-reply enc-part'ının ayrımı 06.02'de işlenir. Buradaki soru 'bilet nasıl akıyor' değil, 'hangi anahtar kimin ve neyi mühürlüyor'dur.

Arabirimler ve belirtimler

• Client: olağan parola tabanlı AS yolunda kendi long-term key'ini reply key olarak kullanır. Başka pre-authentication mekanizmaları farklı bir reply key seçebilir. Client, krbtgt anahtarını bilmez ve TGT'nin şifreli içeriğini açmaz.
• KDC: domain'in bir servisidir; iki bileşeni vardır, Authentication Service (AS) TGT verir, Ticket-Granting Service (TGS) service ticket verir. Tek bir process olarak domain controller üzerinde LSA içinde çalışır ve durdurulamaz.
• krbtgt: KDC'nin hesabıdır; domain oluşturulurken otomatik yaratılır, silinemez ve adı değiştirilemez; rastgele bir parolası vardır ve bu paroladan TGT'leri mühürleyen anahtar türetilir. krbtgt anahtarı domain-geneli güvenin köküdür.
• Service: SPN, service instance'ını oturum açtığı hesaba bağlar. KDC service ticket'ın enc-part'ını bu hesabın anahtarıyla korur. Aynı hesap birden fazla SPN veya service instance'ı için kullanılabilir; her instance'a ayrı bir anahtar düşmesi zorunlu değildir.
• Trust (inter-realm): iki realm arasında güven kurulduğunda ortak bir trust account ve ondan türeyen bir inter-realm key oluşur; realm'ler arası referral bilet bu anahtarla mühürlenir.

Dört aktör, dört anahtar sahipliği

Client ve KDC, olağan parola tabanlı yolda client hesabının long-term key'ini kullanır. Pre-authentication gerekiyorsa KDC önce istemcinin sunduğu kanıtı doğrular. Pre-authentication istenmeyen bir AS isteğine de yanıt üretilebilir; bu yanıtın verilmesi, istek sahibinin hesabın sırrını bildiğini tek başına kanıtlamaz.

KDC, istenen SPN'in hangi hesaba kayıtlı olduğunu bulur ve service ticket'ı o hesabın anahtarıyla korur. Client bileti taşır, şifreli içeriğini açmaz. Aynı hesabı kullanan başka instance'lar da aynı anahtar kapsamındadır; SPN adı ile account sınırını ayırmak bu yüzden önemlidir.

KDC'nin kendi anahtarı krbtgt hesabının anahtarıdır. TGT (Ticket-Granting Ticket), tam olarak 'service'i krbtgt olan' özel bir bilettir: KDC, verdiği TGT'yi krbtgt anahtarıyla mühürler, böylece daha sonra o TGT'yi yalnız kendisi (aynı krbtgt anahtarıyla) doğrulayabilir.

KDC bir domain servisidir, ayrı bir kutu değil

KDC soyut bir 'sunucu' değildir; domain'in bir servisidir ve Active Directory'yi hesap veritabanı olarak kullanır. Bir kullanıcı veya makine domain'de tanımlıysa, KDC onun anahtarını dizinden okuyabilir. Bu yüzden KDC her domain controller üzerinde çalışır ve dizinin bir uzantısı gibi davranır.

KDC iki mantıksal bileşenden oluşur ama tek bir process olarak çalışır: Authentication Service (AS) client'a bir TGT verir, Ticket-Granting Service (TGS) ise geçerli bir TGT karşılığında belirli service'ler için bilet verir. Bu ayrım, 'kimliğini bir kez kanıtla, sonra biletle dolaş' modelinin temelidir.

KDC, domain controller üzerinde LSA process'i içinde çalışan ve durdurulamayan bir servistir. Bunun sonucu pratiktir: KDC'yi 'kapatmak' diye bir işlem yoktur; o, DC'nin kimlik doğrulama işlevinin ayrılmaz parçasıdır.

krbtgt: güvenin kökü

krbtgt, KDC'nin hizmet hesabıdır. Domain ilk kurulduğunda otomatik olarak oluşturulur, silinemez ve yeniden adlandırılamaz; hesaba rastgele, bilinmeyen bir parola atanır. Bu parola önemlidir çünkü ondan türetilen anahtar, domain'deki her TGT'yi mühürleyen anahtardır.

Bu, krbtgt anahtarını domain-geneli güvenin kökü yapar. Her client bir TGT taşır; her TGT krbtgt anahtarıyla mühürlüdür; her TGS-REQ, KDC'nin bu TGT'yi aynı anahtarla doğrulamasıyla başlar. Yani domain'deki tüm Kerberos akışı, krbtgt anahtarının gizliliğine dayanır.

Bu dersin artifact'i tam da bunu somutlaştırır: bir Ticket [APPLICATION 1] yapısı; içindeki sname alanı krbtgt/IYELABS.EXAMPLE'dır ve enc-part alanı opaque'tir çünkü krbtgt anahtarıyla mühürlenmiştir. Bilet dış alanları (sürüm, realm, service adı) açık okunur; sırların bulunduğu enc-part ise yalnız krbtgt anahtarını bilen KDC için anlamlıdır.

Ticket enc-part ile KDC yanıtının enc-part'ı kardeştir

AS-REP içinde ticket [5] ve yanıtın enc-part [6] alanı yan yanadır. TGT'nin kendi enc-part'ını krbtgt anahtarı korur; yanıtın enc-part'ını ise client'ın reply key'i korur. Olağan parola tabanlı yolda bu client long-term key'idir; RFC 4120 §5.4.2, pre-authentication mekanizmasıyla seçilen başka bir anahtara da izin verir.

Bu iki alan farklı taraflar içindir: ticket'ın enc-part'ı service (TGT'de krbtgt) tarafından açılır ve session key ile yetki verilerini taşır; yanıtın enc-part'ı client tarafından açılır ve aynı session key'i client'a güvenli iletir. İkisini 'aynı şey' sanmak, hangi anahtarın neyi koruduğunu yanlış okumaktır.

Bu ders aktörlere odaklandığı için artifact yalnız bir bilet yapısını (ticket + onun opaque enc-part'ını) gösterir; yanıtın kendi enc-part'ı ile ticket'ın enc-part'ının kardeşliği ve tam AS/TGS alan yapısı 06.02'nin konusudur. Buradaki amaç, 'TGT'nin enc-part'ı krbtgt anahtarına aittir' sınırını netleştirmektir.

Durum ve veri akışı

1. Bu temel örnekte client hesabının parola tabanlı long-term key'i kullanılır; KDC aynı hesabın key materyaline erişir.
2. Client AS'e başvurur. Pre-authentication gereken yolda KDC kanıtı doğrular; TGT issuance sonucunu, bu koşuldan bağımsız bir kimlik kanıtı sayma.
3. KDC, ürettiği TGT'nin enc-part'ını krbtgt anahtarıyla mühürler; TGT'nin sname alanı krbtgt/<realm>'dir.
4. AS-REP'in ayrı reply enc-part'ı client'ın reply key'iyle korunur: bu örnekte long-term key, başka mekanizmalarda seçilen farklı key olabilir.
5. Client bir service'e erişmek isteyince TGT'sini TGS'e sunar; KDC TGT'yi krbtgt anahtarıyla doğrular.
6. KDC service ticket'ı SPN'in kayıtlı olduğu hesabın anahtarıyla korur; aynı hesap başka SPN'leri de taşıyabilir.
7. Client bileti hedefe sunar. Hedef, SPN hesabının anahtarıyla ticket içeriğini açar; sonraki kaynak yetkilendirmesi ayrı karardır.
8. Farklı realm'e erişimde KDC, trust account'tan türeyen inter-realm key ile referral bilet üretir ve akış hedef realm'in KDC'sine devreder.

2. Exploitation / İstismar

Broken trust assumption

Risk değerlendirmesinde kırılan varsayım, her anahtarın tek bir service instance'ına ait olduğu düşüncesidir. Service account key'inin kapsamı o hesabı kullanan SPN ve instance'ları içerir; krbtgt anahtarı ise domain'in TGT güven sınırına aittir. Aynı 'anahtar sızdı' ifadesi bu iki durumda aynı etkiyi anlatmaz.

Technical prerequisites

• krbtgt anahtarını elde etmek için domain düzeyinde çok yüksek yetki gerekir (örneğin DC üzerinde dizin sırlarına erişim / DCSync tarzı replikasyon hakkı, 05.05). Yani krbtgt sızması bir başlangıç değil, tipik olarak zaten domain'i ele geçirmiş bir konumun kalıcılaştırılmasıdır.
• Service hesabının anahtarı açığa çıktıysa hesabın SPN'lerini ve bu hesabı kullanan instance'ları belirle; etkiyi otomatik olarak tek service ile sınırlama.
• Client anahtarı için client'ın parolası hedeflenir; bu, o client'ın kimliğini etkiler ama başka principal'ların biletlerini mühürleme yeteneği vermez.
• Inter-realm key için trust account'ın anahtarı hedeflenir; kapsam iki realm arasındaki güven yoludur, tek bir realm'in tamamı değil.

Exploitation mechanism / İstismar mekanizması

Anahtar sahipliği, hangi şifreli bölüme güvenildiğini belirler. Service account key'i ticket'ın şifreli içeriği ve içindeki session key ile ilgilidir. Bu, bütün application traffic'inin açılacağı anlamına gelmez: sonraki koruma, uygulama protokolüne ve eldeki mesajlara bağlıdır. krbtgt key'i ise TGT'leri koruyan domain sınırındadır. Savunmada önce hangi anahtarın, hangi account ve message bölümlerinin etkilendiğini belirlemek gerekir.

Neden krbtgt farklı bir kategoridir

Sıradan bir hesabın anahtarı yalnız o hesabın kimliğini korur. krbtgt ise bir kimlik değil, bir mühür sahibidir: domain'deki her TGT onun anahtarıyla mühürlenir. Bu yüzden krbtgt anahtarını bilmek, tek bir hesabı taklit etmek değil, KDC'nin TGT üretme/doğrulama yetkisini paylaşmak demektir.

Bunun pratik sonucu, krbtgt anahtarını bilen birinin istediği kimlik ve yetki iddialarıyla geçerli görünen TGT'ler üretebilmesidir; KDC bu biletleri kendi krbtgt anahtarıyla doğruladığı için ayrım yapamaz. Bu, uzun ömürlü ve domain-geneli bir kalıcılık sınırıdır.

Bu yüzden krbtgt, 'bir parola daha' değil, domain güveninin kök anahtarıdır. Onu bir servis parolasıyla aynı risk sınıfında görmek, en kritik sınırı en sıradan sınırla karıştırmaktır.

Service adı ile hesap kapsamını ayır

Bir hesap iki SPN taşıyorsa iki farklı service adı görünmesi, iki bağımsız key sahibi olduğu anlamına gelmez. Hesabın nerede kullanıldığını görmeden olayın kapsamını tek host veya tek uygulama diye daraltamazsın.

Client anahtarının sızması o client'ın kimliğini verir. Saldırgan client gibi TGT isteyebilir; ama bu, herhangi bir principal'ı taklit etme yeteneği değildir. Client, krbtgt anahtarını bilmediği için başka biletleri mühürleyemez.

Client, service account ve krbtgt anahtarlarının kapsamı farklıdır. Kayıp anahtarın sahibini, hesabın kullanımını ve biletin hangi bölümünü koruduğunu birlikte incele; tek bir önem sırası bütün ortamlar için yeterli değildir.

Sınır: bu bir akış değil, sahiplik dersidir

Bu ders bir bilet üretme/forge tekniğini adım adım anlatmaz; amaç hangi anahtarın hangi sınırı mühürlediğini netleştirmektir. Golden/silver ticket gibi somut teknikler, bu sahiplik haritası üzerine kurulur ve ileri derslerin konusudur.

Anahtar sahipliği tek başına bir güvenlik açığı değildir; tasarımın ta kendisidir. Zafiyet, bu anahtarların (özellikle krbtgt'nin) korunmasındaki eksikliklerden doğar, mekanizmanın kendisinden değil.

Risk önceliğini key sahibi, hesabın kullanım alanı ve erişebildiği kaynaklarla belirle. krbtgt gibi geniş güven sınırları özel koruma gerektirir; bunun yanında kritik bir uygulamanın service hesabı da kendi iş etkisiyle değerlendirilir.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• 4768 TGT talebinin, 4769 service-ticket talebinin KDC'deki sonucudur. Hedefte kabul ve kaynak yetkilendirmesi ayrı kanıt ister; 4624 yalnız bu yol bir logon oluşturuyorsa ilgilidir.
• 4768 DC'de toplanır. Status ve PreAuthType'ı birlikte oku: PreAuthType=0, pre-authentication kullanılmadığını belirtir. Başarılı bir issuance kaydı bu durumda client sırrının kanıtlandığını söylemez.
• Başarılı 4768'de ServiceName tipik olarak krbtgt'tir; failure kaydında krbtgt/REALM_NAME biçimi görülebilir. ServiceSid da failure kaydında NULL SID olabilir.
• krbtgt hesabının kendisiyle ilgili değişiklikler (parola sıfırlama gibi) ayrı bir yüksek-değerli sinyaldir; krbtgt bir servis hesabı gibi rutin yönetilmediği için bu tür olaylar dikkatle incelenir.
• Kerberos denetimi Audit Kerberos Authentication Service (4768/4771) ve Audit Kerberos Service Ticket Operations (4769) alt kategorileriyle yapılandırılır; kapalıysa bu olaylar üretilmez.

Events and relevant fields

• 4768 / TargetUserName ve TargetDomainName: TGT talebindeki principal ve realm; bu alanlar tek başına pre-authentication kanıtı değildir.
• 4768 / ServiceName ve ServiceSid: TGT service bağlamı. Başarıda krbtgt ve krbtgt hesabının SID'i tipiktir; failure'da realm-qualified ad ve NULL SID görülebilir. Status ile birlikte oku.
• 4768 / TicketEncryptionType: TGT'nin enc-part'ının şifreleme türü (örn. 0x12 = AES256-CTS-HMAC-SHA1-96). Bu değer krbtgt anahtarının türünü yansıtır; downgrade'leri fark etmek için izlenir.
• 4768 / PreAuthType ve Status: pre-authentication türü ve sonuç. Başarısız pre-auth (belirli Status kodları) 4771 olarak ayrı raporlanır; issuance başarısı/başarısızlığı buradan okunur.
• 4768 / IpAddress: TGT talebinin geldiği kaynak adres; anormal konum/host analizinde kullanılır.
• 4769 / ServiceName: istenen SPN'in çözümlendiği account/principal; alan birebir SPN string'i olmak zorunda değildir.

Issuance ile erişim kanıtını ayırmak

4768'de önce talebin sonucunu ve pre-authentication türünü incele. Başarılı kayıtla hedefteki dosya erişimi arasında doğrudan eşitlik kurma: TGT alındıktan sonra service ticket talebi, hedefin kabulü ve kaynak yetkilendirmesi farklı kararlar verir.

Örneğin DC'de 4769 görünürken FS01'de istenen dosya erişimi reddedilebilir. İncelenecek sonraki kanıt FS01'deki ilgili session ve kaynak kararıdır; DC'deki TicketEncryptionType bu dosyanın DACL sonucunu açıklamaz.

krbtgt anahtarı neden özel izlenir

krbtgt bir kimlik değil, domain'deki tüm TGT'lerin mührüdür. Bu yüzden krbtgt ile ilgili olaylar (özellikle parola/anahtar değişiklikleri) sıradan bir servis hesabınınkinden çok daha ağır bir sinyaldir ve her zaman gerekçesiyle birlikte incelenir.

İzlemede krbtgt'nin ServiceName olarak göründüğü 4768, normal issuance'tır ve beklenir; asıl dikkat, krbtgt hesabına yapılan yönetim işlemlerine ve o hesabın anahtarına ulaşan yollara (DC üzerinde dizin sırları / replikasyon hakları) verilir.

Sağlam bir savunma, güven-kökü anahtarlarını (krbtgt, trust account) en yüksek koruma katmanında tutar. Bu anahtarların kapsamı tüm domain/forest olduğu için, onları korumak tek tek servisleri korumaktan önce gelir.

Detection logic · KQL

// 4768: TGT request result at the DC; typical success ServiceName=krbtgt.
// Failure names may be realm-qualified. Review Status and PreAuthType separately.
SecurityEvent
| where EventID == 4768
| where TimeGenerated > ago(24h)
| summarize Count = count(), EncTypes = make_set(TicketEncryptionType) by TargetUserName, IpAddress, Status
| order by Count desc

Query assumptions

• 4768 yalnızca Audit Kerberos Authentication Service alt kategorisi etkinse ve olay bir domain controller'da toplanıyorsa görünür; KDC yalnız DC'de çalıştığı için bu olaylar DC loglarından gelir.
• SecurityEvent tablosu ve alan adları (EventID, TargetUserName, TargetDomainName, ServiceName, TicketEncryptionType, Status, IpAddress) Windows Security olaylarını toplayan bir ortam varsayar; farklı bir şemada alan adları değişebilir.
• Bu özet talep sayısını ve TicketEncryptionType'ı gruplar; PreAuthType, hedef service kabulü veya kaynak yetkilendirmesini değerlendirmez. Bunlar olay ayrıntısı ve hedef taraf kanıtıyla ayrıca incelenir.
• TicketEncryptionType değerleri sayısal kodlardır (örn. 0x12 AES256); zayıf türlerin (RC4 vb.) izlenmesi ayrı bir kural gerektirir ve burada yalnız özetlenir.
• Bu sorgu gerçek bir SIEM üzerinde çalıştırılmamıştır; alan adları ve olay anlamı Microsoft 4768 belgesine göre hazırlanmıştır ve kullanılan sürümün şemasına göre doğrulanmalıdır.

False positives

• Normal kullanıcı oturum açma etkinliği: her başarılı domain oturumu bir 4768 üretebilir; yüksek sayım tek başına anormal değildir.
• Toplu iş/otomasyon hesapları: zamanlanmış görevler ve servisler düzenli TGT talebi üretir.
• Yeni cihaz veya VPN aralığı: beklenen bir IpAddress değişimi issuance kaydını değiştirir ama kötü niyet göstermez.
• Negatif örnek: Audit Kerberos Authentication Service kapalıysa veya DC logları toplanmıyorsa 4768 hiç görünmez; kaydın yokluğu 'kimlik doğrulama olmadı' anlamına gelmez. Bu sorgu bir görünürlük katmanıdır, erişim kanıtı değildir.

Hardening

• krbtgt anahtarını en kritik sır olarak yönet: parola sıfırlamayı (iki kez, çoğaltma bekleyerek) yalnız gerekçeli ve planlı yap; krbtgt'yi rutin bir servis hesabı gibi görme, çünkü domain-geneli güvenin köküdür.
• DC issuance kayıtlarıyla hedef service kayıtlarını ayrı topla; aynı principal adını görmek olayları otomatik olarak aynı erişim denemesi yapmaz.
• TicketEncryptionType'ı izle: TGT ve service ticket'larda beklenen güçlü türleri (AES) doğrula, RC4 gibi zayıf türlere düşüşleri araştır.
• Audit Kerberos Authentication Service (4768/4771) ve Audit Kerberos Service Ticket Operations (4769) alt kategorilerini domain controller'larda etkinleştir ve DC güvenlik loglarını merkezî topla; KDC yalnız DC'de çalıştığı için bu olaylar orada üretilir.
• krbtgt ve trust account gibi güven-kökü hesaplarına erişimi Tier-0 olarak kısıtla; bu anahtarlara ulaşan yol (DC üzerinde dizin sırlarına erişim / replikasyon hakkı) doğrudan izlenir ve minimuma indirilir.
• Doğrulama adımı: bir test kullanıcısıyla oturum aç, DC'de 4768 olayının ServiceName=krbtgt ve TargetUserName=<kullanıcı> ile üretildiğini gör; ardından bir dosya paylaşımına service ticket talep et ve akışın 4769 olarak ayrı kaydedildiğini, ServiceName'in KDC'nin çözümlediği hesap/servis principal'ı olduğunu (birebir istenen SPN string'i olmayabilir) gözlemle; 4769'un yalnız issuance olduğunu, gerçek kabulü hedef taraftaki kanıtla karşılaştırarak doğrula.

Örnekler üzerinde oku / Read the examples

61 62 30 60 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 24 30 22
a0 03 02 01 02 a1 1b 30 19 1b 06 6b 72 62 74 67
74 1b 0f 49 59 45 4c 41 42 53 2e 45 58 41 4d 50
4c 45 a3 20 30 1e a0 03 02 01 12 a1 03 02 01 02
a2 12 04 10 c0 ff ee 00 11 22 33 44 55 66 77 88
99 aa bb cc

İki yanlış kanı / Two reality checks

Sanılan: Bir Kerberos anahtarının ele geçirilmesi tek bir hesabı etkiler; krbtgt de sonuçta bir hesaptır.

Gerçekte: Etki anahtarın sahibine bağlıdır. Bir service account birden fazla SPN veya instance'ı kapsayabilir; krbtgt ise domain'in TGT sınırını korur. Service adını account kapsamı yerine koymadan anahtarın kullanım yerlerini incele.

Sanılan: Bir kullanıcının TGT alması (4768), o kullanıcının bir sunucuya/servise eriştiğini gösterir.

Gerçekte: 4768 KDC'deki TGT talebinin sonucudur; pre-authentication kullanımı Status ve PreAuthType ile ayrıca okunur. Sonraki service-ticket talebi ve hedefte kabul farklı kanıtlardır. Bilet verilmesi bir kaynağın DACL'inin izin verdiğini göstermez.

Kaynaklar / Sources

• IETF · RFC 4120 — The Kerberos Network Authentication Service (V5)
  §1.1 aktörler ve anahtar kavramları; §5.3 Ticket ve EncTicketPart yapısı; §3.1/§3.3 AS ve TGS değişimi; ticket enc-part'ının service anahtarıyla, KDC yanıtının client anahtarıyla mühürlenmesi.
• Microsoft · Kerberos authentication overview
  KDC'nin AS+TGS bileşenleri, TGT kavramı, krbtgt ve domain controller üzerinde çalışan KDC servisi.
• Microsoft · Key Distribution Center
  KDC bir domain service; tek process, AS ve TGS; DC üzerinde LSA içinde çalışır, durdurulamaz; krbtgt otomatik oluşturulur, silinemez/adı değişmez, rastgele paroladan TGT anahtarı türetilir; trust'tan inter-realm key.
• Microsoft · 4768(S, F) A Kerberos authentication ticket (TGT) was requested
  Subcategory Audit Kerberos Authentication Service; yalnız DC; ServiceName=krbtgt; alanlar TargetUserName, TargetDomainName, ServiceName, TicketEncryptionType, PreAuthType, Status, IpAddress; 4771 başarısız pre-auth.
• Microsoft · Service principal names
  SPN, instance ve service sign-in account ilişkisi; aynı account üzerinde SPN kapsamı.