Merhaba
Serinin önceki bölümünde, varsayılan bir Active Directory ayarının nasıl istismar edilebildiğini gördük. Bu bölümde ise, çoğu zaman geriye dönük uyumluluk ya da eski uygulama gereksinimleri yüzünden hala ortamlarda varlığını sürdüren, oldukça güçlü ve tehlikeli bir yapılandırma hatasını ele alıyoruz: Unconstrained Delegation.
Unconstrained Delegation
Kerberos delegation, bir servisin, kendisine kimlik doğrulaması yapan bir kullanıcı adına başka bir servise erişebilmesini sağlayan bir mekanizmadır. Unconstrained delegation (kısıtlamasız yetki devri) yapılandırıldığında, bir bilgisayar ya da servis objesi “Trust this computer for delegation to any service” (herhangi bir servise yetki devri için bu bilgisayara güven) ayarıyla işaretlenir. Bu, `userAccountControl` özniteliğinde `TRUSTED_FOR_DELEGATION` bayrağının ayarlanması anlamına gelir. Bu yapılandırma etkinleştirildiğinde, bu sisteme Kerberos ile kimlik doğrulaması yapan HERHANGİ bir kullanıcının Ticket Granting Ticket’ı (TGT), o sistemin belleğinde (LSASS) önbelleğe alınır. Bu sistemi ele geçiren bir saldırgan, bu önbelleğe alınmış TGT’leri çıkarabilir ve bunları kullanarak o kullanıcı gibi davranabilir. Eğer bir Domain Admin ya da başka bir yüksek yetkili hesap, unconstrained delegation’a sahip bir sisteme (örneğin bir dosya sunucusuna, bir web uygulamasına ya da hatta bir yazıcı sunucusuna) herhangi bir nedenle kimlik doğrulaması yaparsa – bir paylaşıma erişerek, bir zamanlanmış görev çalıştırarak ya da uzaktan yönetim aracı kullanarak – o hesabın TGT’si de bu sistemde önbelleğe düşer ve saldırgan tarafından çalınabilir hale gelir. Bu teknik özellikle tehlikelidir çünkü saldırganın hedef hesabın parolasını ya da hash’ini bilmesine gerek yoktur; yalnızca o hesabın unconstrained delegation’a sahip bir sisteme kimlik doğrulaması yapmasını beklemesi (ya da buna zorlaması) yeterlidir. PrinterBug, PetitPotam gibi zorlanmış kimlik doğrulama (coerced authentication) teknikleri, tam olarak bu senaryoyu tetiklemek için kullanılır: saldırgan, bir domain controller’ı kendi kontrolündeki unconstrained delegation’lı bir sisteme kimlik doğrulaması yapmaya zorlar ve domain controller’ın makine hesabının TGT’sini ele geçirir.
Unconstrained Delegation’ı Mitigasyon Etmek
Unconstrained delegation’ı mitigasyon etmek için aşağıdaki güvenlik kontrolleri uygulanmalıdır:
- Unconstrained delegation kullanımını tamamen ortadan kaldırın. Domain controller’lar dışında hiçbir sistemin unconstrained delegation’a ihtiyacı olmamalıdır. Bu ihtiyaç varsa, bunun yerine constrained delegation ya da resource-based constrained delegation (RBCD) kullanılmalıdır; bu yöntemler bir sistemin yalnızca belirli servislere yetki devri yapmasına izin verir.
- Yüksek yetkili hesapları “Account is sensitive and cannot be delegated” (Hesap hassastır ve yetki devri yapılamaz) bayrağıyla işaretleyin. Bu, Domain Admin gibi hesapların TGT’lerinin herhangi bir sistemde – unconstrained delegation’a sahip olsa bile – önbelleğe alınmasını engeller.
- Domain’deki tüm unconstrained delegation’lı bilgisayar ve servis objelerini düzenli olarak envanterleyin ve gözden geçirin. `userAccountControl` özniteliğinde `TRUSTED_FOR_DELEGATION` bayrağı bulunan objeler periyodik olarak taranmalı ve gerekçesiz olanlar kaldırılmalıdır.
- PrinterBug, PetitPotam gibi zorlanmış kimlik doğrulama tekniklerine karşı mitigasyon uygulayın. Bu, RPC filtreleme, Print Spooler servisinin domain controller’larda devre dışı bırakılması ve LDAP/LDAPS için imzalama ile kanal bağlama (channel binding) zorunluluğunun getirilmesini içerir.
Unconstrained Delegation’ı Tespit Etmek
Unconstrained delegation istismarını tespit etmek, hem yapılandırma seviyesinde (hangi objelerin bu yetkiye sahip olduğu) hem de davranış seviyesinde (bu yetkinin kim tarafından, ne zaman kullanıldığı) izleme gerektirir. Aşağıdaki Event ID’ler merkezi olarak loglanmalı ve zamanında analiz edilmelidir.
Unconstrained Delegation’ı Tespit Eden Olaylar
| Event ID | Kaynak | Açıklama |
|---|---|---|
| 4624 | Domain Controller’lar ve unconstrained delegation’lı sistemler | Bir hesap bu sistemlerden birine oturum açtığında üretilir. Özellikle yüksek yetkili bir hesabın unconstrained delegation’a sahip bir sisteme kimlik doğrulaması yaptığını tespit etmek için kritik önemdedir; bu durum, o hesabın TGT’sinin çalınma riski taşıdığı anlamına gelir. |
| 4738 | Domain Controller’lar | Bir kullanıcı hesabı değiştirildiğinde üretilir. Bir hesabın `userAccountControl` özniteliğine `TRUSTED_FOR_DELEGATION` bayrağının eklendiği durumlarda bu olay tetiklenir ve yeni bir unconstrained delegation yapılandırmasının işareti olabilir. |
| 5136 | Domain Controller’lar | Bir directory service objesi değiştirildiğinde üretilir. Bu olay, `userAccountControl` gibi belirli özniteliklerdeki değişiklikleri (eski/yeni değerleriyle birlikte) gösterir ve unconstrained delegation bayrağının kim tarafından, ne zaman eklendiğini tespit etmek için Event 4738’e göre daha ayrıntılı bir kanıt sağlar. |
Lab Uygulaması: Windows Server 2025 Üzerinde Unconstrained Delegation
Bu bölümdeki gösterim için kendi Windows Server 2025 domain controller ve Windows 11 client lab ortamımızda ilerledik. İlk adımda, W11CLIENT bilgisayar objesini unconstrained delegation için işaretledik:
Set-ADComputer -Identity "W11CLIENT" -TrustedForDelegation $trueBu değişiklik, DC’nin Security log’unda bir Event ID 4742 (A computer account was changed) kaydı üretti.
DC üzerinde oluşan Event ID 4742 kaydının genel görünümü. Computer Account That Was Changed: W11CLIENT$ alanı, değişikliğin doğru bilgisayar objesine uygulandığını gösteriyor.
Aynı olayın devamı – Old UAC Value: 0x80 → New UAC Value: 0x2080 değişikliği ve bunun altında Windows’un kendi yorumu: 'Trusted For Delegation' - Enabled. Bu satır, unconstrained delegation bayrağının tam olarak bu anda, BAKICUBUK\Administrator hesabı tarafından etkinleştirildiğini tartışmasız şekilde kanıtlıyor.
Ardından, gerçek bir Domain Admin hesabını kullanmadan, yalnızca bu demo için geçici bir test hesabı oluşturduk ve W11CLIENT’a yönetimsel paylaşım erişimi sağlaması için Domain Admins grubuna ekledik:
New-ADUser -Name "testadmin.fake" -SamAccountName "testadmin.fake" -AccountPassword (ConvertTo-SecureString "P@ssw0rd2026!" -AsPlainText -Force) -Enabled $true
Add-ADGroupMember -Identity "Domain Admins" -Members "testadmin.fake"Bu hesapla W11CLIENT’a bir network authentication tetikledik:
net use \\W11CLIENT\C$ /user:BAKICUBUK\testadmin.fake P@ssw0rd2026!
W11CLIENT üzerinde oluşan Event ID 4624 kaydının genel görünümü. Computer: W11CLIENT.bakicubuk.local alanı olayın doğru makinede (unconstrained delegation’a sahip sistemde) oluştuğunu, New Logon > Account Name: testadmin.fake alanı ise kimlik doğrulamasını yapan hesabı gösteriyor. Logon Type: 3 (network) ve Authentication Package: Kerberos alanları, bu bağlantının Kerberos üzerinden gerçekleştiğini teyit ediyor – yani testadmin.fake‘in TGT’si tam bu noktada, teoride W11CLIENT’ın belleğinde önbelleğe düşmüş olması gerekiyor.
Bir sonraki adım, bu önbelleğe düşen TGT’yi Mimikatz’ın sekurlsa::tickets komutuyla çıkarmaktı ki bu, unconstrained delegation’ın asıl tehlikesini somutlaştıran adım. Ancak burada beklemediğimiz, yazıya değer bir bulguyla karşılaştık: W11CLIENT’ta privilege::debug komutu (SeDebugPrivilege’i etkinleştiren adım) sorunsuz çalıştı, ama sekurlsa::tickets her seferinde ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005) (erişim reddedildi) hatasıyla sonuçlandı.
Araştırdığımızda bunun tek bir nedeni olmadığını, iki ayrı güvenlik katmanının üst üste bindiğini gördük:
- LSA Protection (
RunAsPPL) varsayılan olarak etkin geliyor (HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL=2, yani UEFI lock olmadan etkin) ve bu, lsass.exe’yi korumalı bir process (PPL) olarak çalıştırarak Mimikatz gibi araçların normal bir yönetici oturumundan bile bellek handle’ı açmasını engelliyor. - Bu ayarı registry üzerinden kapatıp (
Set-ItemProperty ... -Value 0) yeniden başlattığımızda bile değer kendiliğinden2‘ye geri döndü. Nedenini araştırdığımızda,gpresult /hçıktısında bu ayarı zorlayan herhangi bir domain GPO’su olmadığını, ancak Windows Defender Tamper Protection‘ın (Get-MpComputerStatusçıktısındaIsTamperProtected: True) bu tür güvenlik ilgili registry değişikliklerini sessizce geri aldığını tespit ettik.
Yani bu spesifik lab ortamında, unconstrained delegation’ın teorik zafiyeti tam olarak beklendiği gibi çalıştı (TGT önbelleğe düşme noktasına kadar), ama Windows Server 2025/Windows 11’in güncel varsayılan sertleştirmeleri (LSA Protection + Tamper Protection’ın birlikte çalışması), bu TGT’nin klasik Mimikatz yöntemiyle çıkarılmasını fiilen imkansız hale getirdi. Bu, serinin Bölüm 4’ünde MachineAccountQuota için gördüğümüz sertleştirme bulgusuyla aynı temayı taşıyor: kaynak raporun tarif ettiği teknikler kavramsal olarak hala geçerli, ama modern Windows varsayılanları saldırganın işini eskisi kadar kolaylaştırmıyor. Bu da mitigasyon bölümünde belirtilen kontrollerin (unconstrained delegation’ın tamamen kaldırılması, hassas hesapların delegasyona kapatılması) neden hala birincil savunma hattı olması gerektiğini gösteriyor – çünkü LSA Protection ve Tamper Protection her ortamda, her Windows sürümünde ya da her donanımda aynı şekilde devreye girmeyebilir.
Uyumluluk ve Çerçeve Eşlemesi Tablosu
| Çerçeve | İlgili Kontrol/Madde |
|---|---|
| PCI DSS | Gereksinim 7.1 (Erişim kısıtlaması), Gereksinim 8.2 (Güçlü kimlik doğrulama) |
| HIPAA | 164.312(a)(1) – Erişim Kontrolü |
| ISO 27001 | A.9.2 (Kullanıcı Erişim Yönetimi), A.9.4 (Sistem ve Uygulama Erişim Kontrolü) |
| KVKK | Madde 12 – Veri Güvenliğine İlişkin Yükümlülükler |
| TCMB | Bilgi Sistemleri Yönetimi Tebliğ – Erişim ve Yetkilendirme Kontrolleri |
| NIST CSF | PR.AC-4 (Erişim yetkilerinin yönetimi), PR.AC-1 (Kimlik ve kimlik bilgisi yönetimi) |
| CIS Controls | CIS 5 (Hesap Yönetimi), CIS 6 (Erişim Kontrol Yönetimi) |
MITRE ATT&CK: T1558 (Steal or Forge Kerberos Tickets)
Sonuç
Unconstrained delegation, Active Directory’nin en eski ve en tehlikeli yanlış yapılandırmalarından biri olmaya devam ediyor; çünkü tek bir sistemin ele geçirilmesini, o sisteme kimlik doğrulaması yapan HERHANGİ bir hesabın (potansiyel olarak Domain Admin dahil) ele geçirilmesine dönüştürebiliyor. Bu riskin ortadan kaldırılması genellikle basit: unconstrained delegation’a gerçek bir ihtiyaç yoksa kaldırılmalı, varsa constrained delegation ya da RBCD ile değiştirilmeli. Serinin bir sonraki bölümünde, Group Policy Preferences (GPP) içinde saklanan parolaların nasıl ele geçirilebildiğini inceleyeceğiz.