Kerberos Delegasyon Mimarisi: Çok Katmanlı Windows Uygulamaları Neden İhtiyaç Duyar ve Nerede Kırılır?

Series · 3 partsActive Directory Architecture & InternalsPart 2 · You are here

1. 1Çok Ormanlı Active Directory Mimarisi: Ormanlar, Güven İlişkileri, DNS ve Katmanlı Servisler Gerçekte Nasıl Çalışır?
2. 2Kerberos Delegasyon Mimarisi: Çok Katmanlı Windows Uygulamaları Neden İhtiyaç Duyar ve Nerede Kırılır?You are here
3. 3Yönlü Bir Çizge Olarak Active Directory: Security Descriptor ve Nesne ACL'leri Gerçekte Nasıl Çalışır?

Kurumsal Mimaride Kerberos Çift Sıçrama (Double-Hop) Problemi

Standart tek sıçramalı Kerberos kimlik doğrulamasında (RFC 4120), bir etki alanı istemcisi Key Distribution Center (KDC) ile AS-REQ alışverişi yaparak Ticket Granting Ticket (TGT) alır ve ardından hedef servis için TGS-REQ isteğinde bulunur. Uygulama sunucusu (örneğin 192.168.56.22 adresindeki CASTELBLACK üzerinde barındırılan bir IIS web portalı), gelen Servis Biletini (TGS) kendi gizli anahtarıyla çözerek biletin içindeki Privilege Attribute Certificate (PAC) üzerinden istemcinin kimliğini doğrular.

Mimari problem, bu orta katman uygulama sunucusunun arka uçtaki bağımsız bir kaynakla (örneğin 192.168.56.11 adresindeki WINTERFELL üzerindeki bir veritabanı veya SMB dosya paylaşımı) oturum açmış istemcinin güvenlik bağlamında konuşması gerektiğinde ortaya çıkar.

Kerberos servis biletleri sıkı bir biçimde aracı servisin gizli anahtarıyla (HTTP/castelblack) şifrelendiğinden, CASTELBLACK gelen bileti WINTERFELL sunucusuna doğrudan iletemez. Hedef servis, kendi anahtarıyla çözemediği bu bileti reddeder ve bağlantı kurulmaz. Dahası, uygulama sunucusu kullanıcının açık metin parolasına veya ana anahtarına (master key) sahip olmadığından istemci adına bağımsız bir AS-REQ ya da TGS-REQ başlatamaz. Yani ortada ne iletilebilir bir bilet ne de kullanıcının sırrı vardır.

Microsoft bu çift sıçrama (double-hop) sınırını aşabilmek için üç nesil Kerberos delegasyon mimarisi geliştirdi. Her model, kurumsal çok katmanlı operasyon ihtiyacı ile en düşük yetki ilkesi (least-privilege) arasındaki gerilimi çözmeyi hedefler. Her yeni nesil, bir öncekinin bıraktığı yetki fazlasını daraltmak için tasarlanmıştır; ama her biri kendi istismar yüzeyini de beraberinde getirir. Aşağıdaki model karşılaştırması, bu dengeyi ve her neslin hangi güven varsayımına dayandığını gösterir.

---

1. Nesil: Kısıtlamasız Delegasyon (TRUSTED_FOR_DELEGATION)

Windows 2000, delegasyonu istemcinin birincil kimlik doğrulama belirtecini (TGT) doğrudan aracı sunucuya iletmesine izin vererek uyguladı. Bu modelde aracı sunucu, kullanıcının kimliğini yalnızca o anki istek için değil, sonraki tüm istekler için elinde tutar.

Bir bilgisayar veya kullanıcı nesnesinin userAccountControl özniteliğinde TRUSTED_FOR_DELEGATION (0x80000 / 524288) biti ayarlandığında, KDC bilet istekleri sırasında bu bayrağı inceler.

GOAD laboratuvarında bit düzeyinde LDAP filtresi (LDAP_MATCHING_RULE_BIT_AND için 1.2.840.113556.1.4.803) ile yapılan sorgu:

$ ldapsearch -x -H ldap://192.168.56.10 -D "[email protected]" -w "Heartsbane" \
    -b "DC=sevenkingdoms,DC=local" "(userAccountControl:1.2.840.113556.1.4.803:=524288)" \
    sAMAccountName dNSHostName userAccountControl | grep -E "^(sAMAccountName|dNSHostName|userAccountControl)"
sAMAccountName: KINGSLANDING$
userAccountControl: 532480
dNSHostName: kingslanding.sevenkingdoms.local

Dönen userAccountControl değeri 532480, 0x80000 (TRUSTED_FOR_DELEGATION) | 0x2000 (SERVER_TRUST_ACCOUNT) bayraklarının birleşimidir.

Protokol Mekaniği ve İstismar Dinamikleri

1. Bir istemci kısıtlamasız delegasyona sahip bir sunucu için servis bileti istediğinde KDC, TGS-REP yanıtında OK-AS-DELEGATE bayrağını işaretler.
2. İstemcinin Kerberos Güvenlik Sağlayıcısı (SSP), KDC’den iletilebilir bir TGT (forwardable TGT) talep eder.
3. İstemci, elde ettiği bu delege TGT’yi AP-REQ alışverişinin GSS-API doğrulayıcı sağlama toplamı içindeki KRB_CRED yapısına gömer.
4. AP-REQ paketini çözen aracı sunucu, çağıranın TGT’sini ayıklar ve doğrudan LSASS süreç belleğinde, çağıranın LSA logon session’ı altında önbelleğe alır.
5. Aracı sunucu artık bu TGT ile çağıran adına ormanın tamamındaki herhangi bir hosttaki herhangi bir servise bilet talep edebilir.

Domain Controller olmayan bir üye sunucuya kısıtlamasız delegasyon verilmesi, bu nedenle kritik bir güvenlik açığıdır. Bu sunucuda yerel yönetici hakkı elde eden bir saldırgan, zorlama primitiflerini (MS-RPRN RpcRemoteFindFirstPrinterChangeNotificationEx veya MS-EFSR EfsRpcOpenFileRaw) kullanarak bir Domain Controller makine hesabını (DC01$) kimlik doğrulamaya zorlayabilir. DC01$’ın TGT’si saldırganın LSASS belleğine düşer ve orman köküne DCSync atılarak tam etki alanı kontrolü sağlanır. Buradaki kilit nokta, TGT’nin çalınması değil, hedefin kendi iradesiyle o bileti saldırganın belleğine bırakmasıdır. Bu yüzden kısıtlamasız delegasyon, tek bir sunucunun ele geçirilmesini tüm ormanın ele geçirilmesine çevirebilir.

---

2. Nesil: Klasik Kısıtlı Delegasyon (KCD / [MS-SFU])

Windows Server 2003, orta katman sunucuların belleğinde sınırsız TGT tutulmasını engellemek için Service for User ([MS-SFU]) protokol uzantılarını getirdi. Kısıtlı delegasyonda orta katman sunucusu, yalnızca msDS-AllowedToDelegateTo özniteliğinde önceden tanımlanmış açık SPN listesi için bilet talep edebilecek şekilde sınırlandırılır. Buradaki fark, kimin hangi servise gidebileceğini artık ön uç nesnesinin belirlemesidir; hedef kaynak bu kararın dışında kalır.

$ ldapsearch -x -H ldap://192.168.56.11 -D "[email protected]" -w "Heartsbane" \
    -b "DC=north,DC=sevenkingdoms,DC=local" "(msDS-AllowedToDelegateTo=*)" \
    sAMAccountName userAccountControl msDS-AllowedToDelegateTo | grep -E "^(sAMAccountName|userAccountControl|msDS-Allowed)"
sAMAccountName: CASTELBLACK$
userAccountControl: 4096
msDS-AllowedToDelegateTo: HTTP/winterfell.north.sevenkingdoms.local
msDS-AllowedToDelegateTo: HTTP/winterfell

sAMAccountName: jon.snow
userAccountControl: 16842752
msDS-AllowedToDelegateTo: CIFS/winterfell.north.sevenkingdoms.local
msDS-AllowedToDelegateTo: CIFS/winterfell

Protokol Geçişi (S4U2Self) ve Kısıtlı Vekil (S4U2Proxy)

Klasik Kısıtlı Delegasyon, userAccountControl bayraklarına bağlı olarak iki farklı modda çalışır:

1. Standart Kısıtlı Delegasyon (Yalnızca Kerberos - CASTELBLACK$, UAC = 4096): CASTELBLACK$, protocol transition olmadan WORKSTATION_TRUST_ACCOUNT (0x1000) bayrağını taşır. Yalnızca S4U2Proxy çağırabilir; KDC’nin hedef SPN için bilet vermesi için, sunucuya gerçekten Kerberos ile oturum açmış bir istemciden aldığı geçerli ve iletilebilir servis biletini (evidence ticket) sunmak zorundadır.
2. Protocol Transition’lı Kısıtlı Delegasyon (jon.snow, UAC = 16842752): jon.snow hesabında 0x1000000 (TRUSTED_TO_AUTH_FOR_DELEGATION) biti açıktır. Bu bit, istemcilerin web formları, NTLM veya SAML ile giriş yaptığı ve hiç Kerberos bileti almadığı ortamlar için tasarlanmış Protocol Transition’ı etkinleştirir. Yani sunucu, kullanıcı adına bir bilet “üretebilir”; kullanıcının önceden Kerberos ile oturum açmış olması gerekmez.

Saldırı Vektörü: SPN Servis Sınıfı Değişimi (sname Mutasyonu)

Kerberos bilet doğrulamasında kritik bir tasarım ayrımı vardır:

• Bir TGS-REP içinde hedef servis kimliği iki yerde görünür: şifrelenmemiş dış sname alanı (Ticket.sname) ve biletin içindeki PAC imza alanları.
• Target Host gelen AP-REQ isteğini doğrularken bileti kendi host gizli anahtarıyla (WINTERFELL$) çözer. winterfell üzerinde makine hesabı altında çalışan tüm servisler (CIFS, HOST, LDAP, HTTP) aynı makine hesabı anahtarını paylaştığından, bilet servis sınıfından bağımsız olarak başarıyla çözülür.
• Rubeus tgssub veya impacket-tgssub gibi araçlar, şifrelenmemiş dış sname değerini CIFS/winterfell yerine LDAP/winterfell olarak yeniden yazar. KDC PAC’ı imzalar ama dış sname alanını servis sınıfına kriptografik olarak bağlamaz; bu yüzden hedef DC bileti LDAP üzerinden kabul eder ve saldırgan doğrudan DCSync yetkisine ulaşır. Bu ayrım, biletin gerçekten hangi servise ait olduğunu doğrulamayı zorlaştırır; çünkü imza bütünlüğü korunurken dış alan değiştirilebilir.

---

3. Nesil: Kaynak Tabanlı Kısıtlı Delegasyon (RBCD)

Klasik Kısıtlı Delegasyon ciddi bir yönetimsel darboğaz yaratıyordu: msDS-AllowedToDelegateTo ön uç servis üzerinde tanımlı bir giden yetki olduğu için delegasyon kurmak Domain Admin kimlik bilgilerini (SeEnableDelegationPrivilege) gerektiriyordu. Bu da her delegasyon değişikliğini merkezi ve ağır bir işleme dönüştürüyordu. Delegasyon yönetimi merkezileşirken en küçük yetki ilkesi de zayıflıyordu; çünkü her yeni ihtiyaç için tekrar Domain Admin’e başvurmak gerekiyordu.

Windows Server 2012, kontrol modelini tersine çevirerek Resource-Based Constrained Delegation (RBCD) modelini getirdi. RBCD’de yetkilendirme mantığı tamamen arka uçtaki hedef bilgisayara taşınır. Hedef host, kendisine hangi ön uç servislerinin delege edebileceğini kendi msDS-AllowedToActOnBehalfOfOtherIdentity özniteliğine ikili bir Güvenlik Tanımlayıcısı (Security Descriptor) yazarak belirler.

# Active Directory Machine Account Quota Configuration
$ ldapsearch -x -H ldap://192.168.56.10 -D "[email protected]" -w "Heartsbane" \
    -b "DC=sevenkingdoms,DC=local" -s base ms-DS-MachineAccountQuota | grep ms-DS-MachineAccountQuota
ms-DS-MachineAccountQuota: 10

Protokol Dinamiği: İletilemez Bilet İstisnası (Non-Forwardable Exception)

RBCD’nin en kritik mimari özelliği, TRUSTED_TO_AUTH_FOR_DELEGATION bayrağı yokken KDC’nin S4U2Self biletlerini nasıl işlediğidir:

1. ms-DS-MachineAccountQuota ile oluşturulmuş sıradan bir bilgisayar hesabı bile Administrator adına S4U2Self isteği çalıştırabilir.
2. İstekte bulunan makine hesabında TRUSTED_TO_AUTH_FOR_DELEGATION (0x1000000) olmadığı için KDC, verilen servis biletini iletilemez (non-forwardable, forwardable: 0) olarak işaretler.
3. Klasik Kısıtlı Delegasyonda bu iletilemez bilet S4U2Proxy’ye sunulursa işlem KDC_ERR_BADOPTION hatasıyla başarısız olur.
4. RBCD’de ise KDC, hedef hostun msDS-AllowedToActOnBehalfOfOtherIdentity DACL’ini inceler. Çağıranın SID’si hedefin DACL’inde varsa KDC, iletilemez bilet kontrolünü açıkça geçersiz kılar ve hedef host için geçerli bir delege servis bileti üretir.

Bu istisna, RBCD’nin neden bu kadar güçlü olduğunu açıklar: Delegasyon kararı artık merkezi bir yönetici iznine değil, hedef nesnenin kendi DACL’ine bağlıdır. Sonuç olarak bir bilgisayar nesnesi üzerinde GenericWrite, GenericAll veya WriteProperty (msDS-AllowedToActOnBehalfOfOtherIdentity) yetkisine sahip herhangi bir Active Directory principal’ı, RBCD istismarıyla o bilgisayarda yerel yönetici erişimi elde edebilir. Bu özellik, RBCD’yi hem meşru yönetim hem de saldırı açısından çekici kılar.

---

Telemetri ve Savunma Mühendisliği

Delegasyon istismarı çoğu zaman tek bir olayda görünmez; bilet istekleri, dizin değişiklikleri ve makine hesabı oluşturma birlikte okunmalıdır.

Delegasyon Telemetri Matrisi

// KQL Query: Detect Suspicious RBCD Security Descriptor Modifications
SecurityEvent
| where EventID == 5136
| where AttributeLDAPDisplayName =~ "msDS-AllowedToActOnBehalfOfOtherIdentity"
| project TimeGenerated, Computer, SubjectUserName, ObjectDN, AttributeValue

Sıkılaştırma ve İyileştirme Protokolleri

1. Makine Hesabı Kotasını Kapatın: Standart kullanıcıların makine hesabı açmasını engellemek için ms-DS-MachineAccountQuota değerini tüm etki alanlarında 0 yapın. Bu tek ayar, RBCD için gereken sahte makine hesabı yolunu kapatır.
2. Protected Users Güvenlik Grubunu Uygulayın: Yönetici hesaplarını CN=Protected Users,CN=Users,DC=... altına alın. Bu grubun üyeleri kısıtlamasız veya kısıtlı delegasyonla delege edilemez (bForwardable zorunlu olarak false yapılır).
3. NOT_DELEGATED Bayrağını Yapılandırın: Tüm Tier-0 servis ve kullanıcı hesaplarında Account is sensitive and cannot be delegated bayrağını (userAccountControl biti 0x100000) ayarlayın.
4. Çapraz Servis SPN Delegasyonunu Denetleyin: msDS-AllowedToDelegateTo içindeki joker karakterli veya Domain Controller’a işaret eden delegasyon yollarını (CIFS/winterfell) kaldırın.

---

Delegasyon Modellerinin Karşılaştırması

---

Kanıt ve sınırlar

LDAP öznitelikleri, bilet geçişleri ve istismar örnekleri, çevredeki walkthrough’larda kullanılan GOAD etki alanlarında kontrol edildi. Laboratuvarın tek başına kanıtlayamadığı kısımlar için Microsoft protokol spesifikasyonları kullanıldı: bilet bayrağı semantiği, S4U istek yapısı ve KDC’nin delegasyon kuralları. Komut çıktısı bu yapılandırmanın kanıtıdır; protokol tanımlarının yerine geçmez. Bu nedenle laboratuvar çıktısını bir tarama sonucu değil, belirli bir yapılandırmanın kanıtı olarak değerlendirmek gerekir.

Yazı, her delegasyon kaydının istismar edilebilir olduğunu iddia etmez. Hesap hassasiyeti, servis sınıfı davranışı, yama düzeyi, SPN sahipliği, şifreleme türleri ve erişilebilen servisler sonucu değiştirir. Tespit alanları da denetim ilkesine ve günlük toplamaya bağlıdır; listelenen Event ID’ler savunmacının kendi ortamında doğrulaması gereken başlangıç noktalarıdır.

Kaynaklar

• Microsoft Open Specifications, [MS-SFU] Kerberos Protocol Extensions: Service for User: learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu
• Microsoft Open Specifications, [MS-PAC] Privilege Attribute Certificate Data Structure: learn.microsoft.com
• Microsoft, Kerberos Constrained Delegation Overview: learn.microsoft.com
• RFC 4120, The Kerberos Network Authentication Service (V5): datatracker.ietf.org/doc/html/rfc4120
• MITRE ATT&CK, Steal or Forge Kerberos Tickets (T1558): attack.mitre.org/techniques/T1558

Kaynaklar ve güncellik

Bu teknik not ne kadar güncel?

Kontrol edilen kaynaklar3 Kasım 2026

En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.

İnceleme DurumuKamuya açık kaynaklar incelendi

Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.

Birincil referanslar

• orange-cyberdefense.github.io · GOAD ↗
• learn.microsoft.com · ms-sfu ↗
• learn.microsoft.com · kerberos-con…ation-overview ↗
• datatracker.ietf.org · rfc4120 ↗
• attack.mitre.org · T1558 ↗