Hacker Directory — Understand what you hack.Hacker Directory — Understand what you hack.
Öğrenmeye devam et
EN
İçindekiler15 bölüm · 82 ders
DERS 10.06DERİN TEKNİK İNCELEME

Cross-domain erişim: Kerberos referrals, SIDHistory, SID filtering ve selective authentication.

Cross-domain erişim tek bir trust kontrolü değildir. İstemci önce hedef realm için referral TGT alır; hedef KDC service ticket üretirken PAC içindeki SID'ler trust sınırında filtering kurallarından geçer. SIDHistory migration sürekliliği sağlayabilir ama filtreleme politikası tarafından düşürülebilir. Selective authentication açıksa principal ayrıca hedef computer/service üzerinde Allowed-to-Authenticate hakkını geçmelidir; en son resource ACL authorization kararı verir.

1. Core Mechanism / Temel mekanizma

Bu ders cross-domain Kerberos erişimini referral, PAC/SID filtering, selective authentication ve resource ACL katmanlarına ayırır. Bunlar karar/triage kapılarıdır; hedef KDC içindeki filtering ve selective-authentication denetimleri için sabit bir iç wire sırası iddia edilmez. Ticket ile KDC reply enc-part'ın sibling olduğu model korunur.

Arabirimler ve belirtimler

  • Referral TGT: local KDC'nin hedef domain/realm KDC'sine geçiş için verdiği krbtgt/FOREIGN-REALM ticket'ıdır.
  • TDO inter-realm trust bilgisi: KDC'nin cross-domain referral ve trust key işlemlerinde kullandığı directory durumudur.
  • PAC ExtraSids/SIDHistory: kullanıcının authorization verisine ek SID'ler taşıyabilir.
  • SID filtering: trust türü ve attributes'a göre izin verilmeyen SID sınıflarını PAC'tan çıkaran sınır kontrolüdür.
  • Selective authentication: forest/domain-wide authentication yerine hedef object üzerinde Allowed-to-Authenticate control access right gerektirir.
  • Allowed-to-Authenticate rights GUID: 68b1d179-0d15-4d4f-ab71-46152e79a7bc.
  • Resource ACL: authentication kapıları geçildikten sonra nesneye gerçek read/write/execute yetkisini belirler.

Referral, hedef service ticket değildir

İstemci başka domain'deki SPN için yerel KDC'ye TGS-REQ gönderdiğinde local KDC doğrudan service ticket vermek yerine hedef realm'e referral TGT döndürebilir. İstemci bu ticket ile hedef KDC'ye yeni TGS-REQ yapar.

KDC yanıtındaki ticket [5] ile enc-part [6] ayrı, kardeş alanlardır. İstemci yeni session key’i yanıtın enc-part alanından alır: TGS yanıtını, istekte varsa authenticator sub-session key ile, yoksa istekte kullanılan TGT’nin session key’iyle açar. Bu işlem dönen ticket’ı açmaz; referral ticket ve normal service ticket kendi alıcı anahtarlarıyla korunur.

SIDHistory süreklilik sağlar, sınırsız pasaport değildir

ObjectSID yeni domain kimliğini, SIDHistory ise migration öncesi SID'leri taşıyabilir. KDC/PAC authorization verisi bu ek SID'leri içerebilir; eski ACL'ler böylece migration sırasında çalışmaya devam edebilir.

Trust boundary PAC'ı olduğu gibi kabul etmek zorunda değildir. MS-PAC filtering kuralları trust türü ve boundary sınıfına göre bazı SID'leri çıkarır veya authentication'ı reddeder. Bu nedenle SIDHistory'nin directory'de bulunması hedefte kesin kabul edileceği anlamına gelmez.

Selective authentication ayrı kapıdır

Forest-wide/domain-wide authentication, trusted principal'ın ilgili scope içindeki kaynaklara authentication denemesine izin verir; yine ACL hakkı vermez. Selective authentication seçildiğinde hedef computer veya service account üzerinde Allowed-to-Authenticate hakkı gerekir.

Allowed-to-Authenticate hedef authentication denemesine izin verir; dosya, share veya database hakkı vermez. İstemci ticket’ını sunmalı, servis de kabul etmelidir; ardından istenen kaynak hakkı değerlendirilir. Bu yüzden sorun incelemesinde referral/TGS zinciri, hedef KDC’nin trust/PAC kontrolleri, servisin kabulü ve kaynak izni ayrı ele alınır. Hedef KDC’de filtering ile selective authentication kontrollerinin kesin iç sırası burada iddia edilmez.

Durum ve veri akışı

  1. Kaynak-domain KDC, cross-domain referral gerekiyorsa TDO’daki trust bilgisini kullanıp referral TGT döndürür.
  2. İstemci referral TGT ile hedef-domain KDC’ye yeni TGS-REQ gönderir.
  3. Hedef KDC bu TGS isteğini işlerken trust boundary/PAC SID filtering kurallarını ve configured ise hedef computer/service üzerindeki Allowed-to-Authenticate control access check’ini değerlendirir; bunların sabit bir iç sırası varsayılmaz.
  4. Hedef KDC service ticket verir veya isteği reddeder; 4769 KDC-side TGS request/result gözlemidir.
  5. İstemci verilen service ticket’ı FS-B’ye sunar. Servis authentication koşullarını değerlendirir; ticket verilmesi servisin kabul ettiğini göstermez.
  6. Servis kabulünden sonra kaynak istenen hakkı değerlendirir. Reports üzerindeki izin, ticket’ın kabulünden ayrıdır; örnek gerçek dosya erişimi yapmaz.

2. Exploitation / İstismar

Broken trust assumption

Saldırgan trusted domain'de bir principal veya SIDHistory yazma/trust yönetimi gibi yüksek ayrıcalık elde etmiştir; gerçek sistem üzerinde SID injection adımları verilmez.

Technical prerequisites

  • Trust filtering politikası beklenenden gevşektir veya devre dışı bırakılmıştır.
  • Target resource eski/broad SID'lere yetki vermektedir ya da Allowed-to-Authenticate kapsamı gereksiz geniştir.

Exploitation mechanism / İstismar mekanizması

Saldırgan authorization verisine hedefte güçlü bir SID taşımaya çalışabilir veya migration için bırakılmış SIDHistory/ACL bağlarını kullanabilir. SID filtering bu sınır ihlalini azaltır; selective authentication ise hangi hedeflere ticket kullanımının denenebileceğini daraltır. Hiçbiri resource ACL'in yerine geçmez.

Dört kapıdan birini bütün erişim sanma

Referral alınması yalnız trust path bulunduğunu; service ticket alınması KDC adımının geçildiğini gösterir. Resource access için selective authentication ve ACL kararı ayrıca gerekir.

Filtering'i migration kolaylığı için gevşetmek, trusted forest compromise etkisini büyütebilir. Geçici istisna süreli, kaynak SID listeli ve hedef ACL review'uyla bağlı olmalıdır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

  • Cross-domain failure’ı referral, target TGS request, hedef KDC’deki PAC/SID filtering ve selective-authentication kontrolleri, ardından resource authorization olarak ayrı incele; protokol içi denetim sırasını varsayma.
  • SIDHistory dolu principal'ları migration owner ve expiry ile envanterle.
  • TrustAttributes/SID filtering posture'unu iki uçta doğrula.
  • Allowed-to-Authenticate ACE'lerini hedef computer/service object'lerinde dar grup kapsamıyla denetle.

Events and relevant fields

  • 4769 KDC’de TGS request/result gözlemidir ve yalnız domain controller’da üretilir; resource service’in ticket’ı kabul ettiğini veya ACL’nin izin verdiğini kanıtlamaz.
  • 4769 native XML’de sonuç alanı Status’tur; Event Viewer bunu Failure Code olarak gösterebilir. ServiceName/TargetDomainName ve diğer alanları OS/event Version’a ait yayımlanmış şemaya göre yorumla; collector’ın eşlediği alan adını native XML adı sanma.

Hata yerini ticket zincirinden ayır

Local KDC referral vermiyorsa trust path/name routing incelenir. Hedef KDC ticket vermiyorsa trust key, filtering ve principal kapsamı incelenir. Ticket var ama logon yoksa Allowed-to-Authenticate ve service-side kabul kontrol edilir.

Service ticket kabul edilip resource deny veriyorsa sorun Kerberos referral değil authorization ACL'idir. Bu katmanlı teşhis gereksiz trust gevşetmesini önler.

Detection logic · XPath

*[System[(EventID=4769)]]

Query assumptions

  • 4769 yalnız DC’de TGS ticket request/result gözlemini verir; aynı cross-domain akışın referral ve final target TGS kayıtlarını EventID tek başına ayırmaz, alan ve trust context enrichment gerekir.
  • Windows Server 2016 ve sonrası için 14 Ocak 2025 güncellemesinden sonra Event 4769 Version 2 alanları görülebilir; alan yorumları event Version ve OS şemasıyla yapılır.
  • Canlı Windows dataset üzerinde çalıştırılmadı; artifact 4769 verisi içermez.

False positives

  • Normal cross-domain uygulama erişimi yoğun 4769 üretir.
  • 4769 başarısı, target service veya resource ACL başarısı değildir.

Hardening

  • SID filtering'i trust türüne uygun güvenli varsayılanda tut; istisnaları migration süresiyle sınırla.
  • SIDHistory kullanımına owner, kaynak SID ve kaldırma tarihi ata.
  • Selective authentication kullanıldığında Allowed-to-Authenticate hakkını yalnız hedefe erişmesi gereken gruplara ver.
  • Resource ACL'lerini foreign broad groups yerine görev-temelli domain local groups ile sınırla.

Örnekler üzerinde oku / Read the examples

ÖRNEĞİ BİRLİKTE OKUYALIM

EĞİTİM İÇİN HAZIRLANDI

Hangi kayıt erişim, hangisi audit veya integrity kuralı?

Selective authentication · Allowed-to-Authenticate ACE (SDDL)

01
S-1-5-21-1987654321-1234567890-2468013579-4206OA · Control Access

Nesneye özgü izin kaydı. Maske trustee’ye yönelik allow/deny kaydının kapsamıdır. İstek, token, sıra ve nesne türü incelenmeden effective access sonucu çıkarılmaz.

02
Nesnenin sahibiBuilt-in Administrators

Bu bölüm security descriptor’ın bir parçasıdır. Owner, primary group, DACL ve SACL farklı bilgi taşır.

03
Primary groupBuilt-in Administrators

Bu bölüm security descriptor’ın bir parçasıdır. Owner, primary group, DACL ve SACL farklı bilgi taşır.

04
Erişim kuralları / DACL(OA;;CR;68b1d179-0d15-4d4f-ab71-46152e79a7bc;;S-1-5-21-1987654321-1234567890-2468013579-4206)

Bu bölüm security descriptor’ın bir parçasıdır. Owner, primary group, DACL ve SACL farklı bilgi taşır.

Buradan çıkaracağın fikir

Bir kuralı okumak ile “bu kişi kesin erişebilir” demek farklıdır. Erişim isteği, token, ACE sırası ve nesne türüyle birlikte değerlendirme gerekir.

Bu görünüm SDDL’deki kuralları açıklar; Windows’un erişim kararını çalıştırmaz. SACL audit ve mandatory label kurallarını taşır; izin veren DACL’in yerine geçmez.

Bu örneğin kapsamı

Sentetik target computer DACL kesitidir; gerçek SID içermez. Object-specific allowed ACE, foreign access grubuna Allowed-to-Authenticate control access right GUID'i üzerinde CR verir. Parser ACE'i ayrıştırır; trust direction, SID filtering, token construction veya tam Windows AccessCheck sonucu hesaplamaz.

Ham kaydı aç · SDDL
O:BAG:BAD:(OA;;CR;68b1d179-0d15-4d4f-ab71-46152e79a7bc;;S-1-5-21-1987654321-1234567890-2468013579-4206)

İki yanlış kanı / Two reality checks

Sanılan: Referral TGT aldıysam hedef resource'a erişim tamamlanmıştır.
Gerçekte: Referral yalnız istemciyi hedef KDC'ye taşır. Hedef service ticket, SID filtering, selective authentication ve resource ACL kararları hâlâ ayrı kapılardır.
Sanılan: SIDHistory attribute'undaki her SID forest trust üzerinden hedef token'a aynen geçer.
Gerçekte: Hayır. Trust boundary MS-PAC SID filtering kurallarını uygular; trust türü ve SID sınıfına göre SID düşürülebilir veya authentication reddedilebilir.

SIRA SENDE

Bu hikâyeyi sen çöz.

Bilgiyi hatırlamaktan bir adım ileri: koşulu değiştir, kanıtı oku, kararın nedenini anlat.

1 / 5 · SONUCU TAHMİN ET

WS01 yalnız referral TGT aldı. Hangi yorum doğru?

Bir cevap seç

Bir ipucu

Ticket’ın alıcısını ve amacını düşün.

Cevabın gerekçesini oku

FS01 service ticket’ı, servis kabulü ve Reports READ sonucu henüz kanıtlanmadı.

Referral hedef KDC’ye geçiş içindir; bu sonraki sonuçlar ayrı kalır.

2 / 5 · KANITI OKU

Bu gözlem FS01’de READ olduğunu kanıtlar mı?

Sentetik KDC-side TGS sonuç özeti; pedagojik alan etiketleri.
Gözlem noktası / Observation point
DC02 / 4769
İstenen servis / Requested service
cifs/FS01
KDC sonucu / KDC result
Service ticket issued
FS01 resource observation / Kaynak gözlemi
Not provided
Bir cevap seç

Bir ipucu

Kaydı üreten makine ile resource kararını ayır.

Cevabın gerekçesini oku

Hayır; ticket verilmesi servis kabulünü veya resource READ’i kanıtlamaz.

4769 hedef KDC’de TGS request/result içindir; FS01 tarafı ayrıca gözlenir.

3 / 5 · OLAYLARI SIRALA

Bu bağımlılıkları doğru sıraya koy. KDC içindeki filtering/selective-auth sırasını tahmin etme.

  1. Servis kabulünden sonra istenen Reports hakkı değerlendirilir.
  2. Ticket varsa WS01 FS01’e sunar; servis authentication’ı değerlendirir.
  3. Hedef KDC ilgili trust koşullarını değerlendirip service ticket verir veya reddeder.
  4. WS01 hedef KDC’ye referral TGT ile TGS isteği gönderir.

Bir ipucu

Önce hedef KDC’ye ulaşma, sonra hedef servis, sonra resource kararı.

Cevabın gerekçesini oku
  1. WS01 hedef KDC’ye referral TGT ile TGS isteği gönderir.
  2. Hedef KDC ilgili trust koşullarını değerlendirip service ticket verir veya reddeder.
  3. Ticket varsa WS01 FS01’e sunar; servis authentication’ı değerlendirir.
  4. Servis kabulünden sonra istenen Reports hakkı değerlendirilir.

Bu dış bağımlılık sırası, hedef KDC’de PAC filtering ile selective authentication için sabit iç wire sırası iddia etmez.

4 / 5 · SONUCU TAHMİN ET

Selective authentication açıktır ve Tunahan hedefte Allowed-to-Authenticate hakkına sahiptir. Ne çıkar?

Bir cevap seç

Bir ipucu

Bu control access right hangi kapıya aittir?

Cevabın gerekçesini oku

Bu authentication önkoşulu sağlanır; Reports READ hâlâ ayrı karardır.

Hedefte authentication denemesine izin, dosya/share hakkının yerine geçmez.

5 / 5 · KENDİN ANLAT

Tunahan’ın SIDHistory değeri directory’de var. Hedefin bu SID’e göre izin vermesini neden kesin sayamazsın?

Bir ipucu

Directory değeri → trust boundary → hedefte kullanılan authorization verisi.

Cevabın gerekçesini oku

Directory’de SIDHistory bulunması hedefe aynen geçtiğini göstermez. Trust türü ve boundary kuralları SID’i filtreleyebilir veya authentication’ı reddedebilir; geçerli authorization verisi ve Reports ACL’i ayrıca değerlendirilir.

  • SID filtering’in ek SID’leri etkileyebildiğini belirttim.
  • Resource ACL kararını filtered veriden ve diğer koşullardan ayırdım.

Açıklaman otomatik puanlanmaz. Kontrol noktalarını kendi cevabınla karşılaştır.

Bu pratikler öğrenme amaçlıdır; sertifika sınavının puanını etkilemez.

Kaynaklar / Sources