Merhaba
Önceki bölümde tek yönlü bir domain trust’ın nasıl bypass edilebileceğini, TDO’nun trust anahtarı çıkarılarak yönü tersine çevirebileceğimizi gördük. Bu bölümde, aynı iki forest lab ortamımızı kullanarak, kalıcılık (persistence) ve gizlenme amaçlı çok daha sinsi bir teknik olan SID History istismarını inceliyoruz hem tek bir domain içinde hem de domain’ler arası hopping senaryosunda.
SID History’nin Ele Geçirilmesi
AD DS’teki her nesnenin, o nesneyi tanımlamak ve sistemlere/hizmetlere/kaynaklara erişirken sahip olduğu yetkileri belirlemek için kullanılan benzersiz ve değişmez bir SID’i (Security Identifier) vardır. Kullanıcı adları değiştirilebildiği için, AD DS doğru erişimin doğru nesneye sağlandığından emin olmak amacıyla SID’e güvenir. ‘SID’ özniteliğine ek olarak, önceki SID’leri saklayan bir ‘sIDHistory’ özniteliği de vardır. Bir SID değiştiğinde örneğin bir nesne bir domain’den diğerine taşındığında (migration) nesneye yeni bir SID atanır ve önceki SID’i ‘sIDHistory’ özniteliğinde saklanır.
Saldırganlar, AD DS ortamında kalıcılık sağlamak ve gizlenmek için SID History işlevselliğini istismar edebilir. Bu teknik, saldırganlar ilk erişimi ve yetki yükseltmesini sağladıktan sonra uygulanır ve bir Domain Controller’a yönetici ayrıcalıkları gerektirir. Bu erişimle saldırganlar, kontrol ettikleri bir nesnenin ‘sIDHistory’sine bir SID ekleyebilir. ‘sIDHistory’ özniteliğine eklenen SID, tipik olarak ayrıcalıklı bir kullanıcı nesnesinden veya güvenlik grubundan (örneğin varsayılan yönetici kullanıcı nesnesi veya Domain Admins güvenlik grubu) gelir. Ayrıcalıklı bir kullanıcı nesnesinin veya güvenlik grubunun SID’i başka bir kullanıcı nesnesinin ‘sIDHistory’ özniteliğine eklendiğinde, bu kullanıcı nesnesi o SID’in ayrıcalıklarını devralır. Örneğin, Domain Admins SID’ini başka bir kullanıcı nesnesine eklemek, o kullanıcı nesnesine Domain Admins güvenlik grubu üyeliğinde görünmeden domain yöneticisi ayrıcalıkları kazandırır. Bu, saldırganların normal (ayrıcalıksız gibi görünen) ama yine de ayrıcalıklı işlemler yapabilen kullanıcı nesnelerinden yararlanarak ortamda kalıcı olmasına yardımcı olur.
Golden Ticket ve SID History ile Domain Hopping
Bir Golden Ticket’ı SID History ile birleştirerek, saldırganlar aynı forest içindeki diğer domain’lere hatta forest’lar arası trust varsa başka forest’lara erişmek için bir TGT sahteciliği yapabilir. Golden Ticket’ın bir parçası olarak TGT’yi sahteleştirirken, saldırganlar başka bir domain’den bir güvenlik grubunun SID’ini ekleyebilir. Örneğin, saldırganlar A domain’ini ele geçirirse, bir TGT sahteler ve B domain’inden bir güvenlik grubunun SID’ini dahil eder. TGT, B domain’indeki bir Domain Controller’a gönderilir, DC bunu doğrular ve bir TGS döndürür. TGS, B domain’inin güvenlik grubunu içeren bir Privileged Attribute Certificate (PAC) içerir. Bu TGS daha sonra, o güvenlik grubunun erişebildiği B domain’indeki her türlü sistem ve kaynağa erişmek için kullanılabilir. Active Directory’nin güvenlik sınırı domain seviyesinde değil forest seviyesinde olduğu için, bir domain’i ele geçiren saldırganlar bu erişimi aynı forest’daki başka herhangi bir domain’e erişmek için kullanabilir.
SID History Ele Geçirilmesini Mitigasyon Etmek
SID History ele geçirilmesi, sömürü sonrası (post-exploitation) aşamada gerçekleşir ve saldırganların bir AD DS ortamında kalıcı olması ile tespitten kaçınması için bir yol olarak kullanılır. Bunu mitigasyon etmek, nesneler üzerindeki ‘sIDHistory’ özniteliğinden değerlerin kaldırılmasını gerektirir. Bu, bir domain’den diğerine taşınmış kullanıcı nesneleri için de geçerlidir bu tür durumlarda, kullanıcı nesneleri taşındıktan ve uygun erişimler yapılandırıldıktan sonra ‘sIDHistory’ özniteliği temizlenmelidir.
Bu tekniği mitigasyon etmek için aşağıdaki güvenlik kontrolleri uygulanmalıdır:
- ‘sIDHistory’ özniteliğinin kullanılmadığından emin olun. Bir domain’den diğerine kullanıcı nesnesi taşıma (migration) durumu dışında, ‘sIDHistory’ özniteliğine ihtiyaç duyulmamalıdır. Hiçbir kullanıcı nesnesi bu öznitelikle yapılandırılmamışsa, bir SID History ele geçirilmesi mümkün değildir.
- ‘sIDHistory’ özniteliğinin haftalık olarak kontrol edildiğinden emin olun. Saldırganlar, kalıcılık sağlamak için kontrol ettikleri bir kullanıcı nesnesinin ‘sIDHistory’ özniteliğine bir değer ekleyebilir. Active Directory nesnelerinde bu özniteliğin düzenli olarak kontrol edilmesi, bu kalıcılık stratejisinin tespit edilme olasılığını artırabilir.
- Domain ve Forest trust’ları için SID Filtering’i etkinleştirin. Bu, Domain Admins ve Enterprise Admins gibi yerleşik (built-in) güvenlik gruplarının SID’lerinin domain’ler arası TGT’lerde kullanılmasını engeller. Ancak, saldırganlar Relative Identifier (RID) 1000’den büyükse diğer güvenlik gruplarının SID’lerini yine de kullanabilir.
SID History Ele Geçirilmesini Tespit Etmek
Bir SID History ele geçirilmesi, Active Directory nesnelerindeki ‘sIDHistory’ özniteliğindeki değişikliklerin izlenmesiyle tespit edilebilir. Bu öznitelik yalnızca domain migration amaçlı kullanılması gerektiğinden, çoğu organizasyon için bu özniteliğin değiştirilmesi nadir olmalıdır. Ayrıca, Domain Controller’larda PowerShell etkinliğinin günlüğe kaydedilmesi bu ele geçirilmeyi tespit etmeye yardımcı olabilir, çünkü Mimikatz gibi yaygın kötü niyetli araçlar bir SID History ele geçirilmesini gerçekleştirmek için PowerShell kullanır.
SID History Ele Geçirilmesini 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. SID History ele geçirilmesini gerçekleştirmek için kullanılan Mimikatz gibi yaygın araçlar PowerShell kullanır. |
| 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. |
| 4675 | Domain Controller’lar | SID’ler filtrelendiğinde üretilir. Golden Ticket ve SID History ile domain hopping, filtrelenen SID’ler kullanabilir; bu olay üretiliyorsa, bir SID History ele geçirilmesi denendiğine işaret edebilir. |
| 4738 | Domain Controller’lar | Bir kullanıcı nesnesi için ‘sIDHistory’ özniteliği değiştirildiğinde üretilir. |
Lab Uygulaması
Bir önceki bölümde kurduğumuz bakicubuk.local W25DC / nihatcubuk.local W25PDC iki forest lab ortamını burada da kullandık. Amacımız, raporun anlattığı SID History enjeksiyonunu Windows Server 2025 üzerinde gerçekten uygulayabilmekti ve bu adım, tek başına başlı başına bir bulgu haline geldi.
1. Adım: Tek domain içinde sIDHistory enjeksiyonu (kalıcılık)
bakicubuk.local‘da, sıradan bir kullanıcı gibi görünen nihatcubuk.local hesabının ‘sIDHistory’ özniteliğine, Domain Admins güvenlik grubunun SID’ini ekleyerek onu görünmeden domain yöneticisi ayrıcalıklarına kavuşturmayı denedik. W25DC‘de, Run as administrator (Yönetici olarak çalıştır) olarak Mimikatz’da:
privilege::debug
sid::patch
Patch 1/2: ERROR kull_m_patch_genericProcessOrServiceFromBuild ; kull_m_patch (0x00000000)sid::patch, lsass.exe bellek imzalarını yalnızca belirli (ve eski) Windows build’leri için tanıyor; Windows Server 2025 build’i bu listede yok ve patch baştan başarısız oluyor. Bu, tekniğin belgelerde de pre-Windows 2016 olarak işaretlenmesinin nedenini canlı olarak doğruladı.
Patch uygulanamadığı için LDAP yazma koruması da devrede kalıyor; sid::add bunu doğruluyor:
sid::add /sam:nihat.cubuk /new:S-1-5-21-3478788356-4009446651-4006572080-512
CN=Nihat Cubuk,OU=LAPS,DC=bakicubuk,DC=local
objectSid: S-1-5-21-3478788356-4009446651-4006572080-5102
sAMAccountName: nihat.cubuk
* Will try to add 'sIDHistory' this new SID:'S-1-5-21-3478788356-4009446651-4006572080-512': ERROR kuhl_m_sid_add ; ldap_modify_s 0x32 (50)
0x32 (50) = LDAP_INSUFFICIENT_ACCESS_RIGHTS. Active Directory, sIDHistory özniteliğini normal bir LDAP modify işlemine karşı Domain Admin yetkisiyle bile koruyor; Mimikatz’ın eski numarası tam olarak bu korumayı sid::patch ile bellekte devre dışı bırakmaktı, ve patch başarısız olunca koruma aktif kalıyor.
2. Adım: DSInternals ile canlı (RPC tabanlı) enjeksiyon – katman katman engellendi
Mimikatz’ın modern alternatifi olarak DSInternals PowerShell modülünü denedik. Modülün çevrimdışı NTDS.dit yöntemi (Add-ADDBSidHistory) güncel sürümde (7.2) tamamen kaldırılmıştı; yerine gelen canlı/RPC tabanlı Add-ADReplSidHistory (IDL_DRSAddSidHistory çağrısını sarmalıyor) ise şu güvenlik kontrolleriyle art arda karşılaştı:
- Denetim (auditing) zorunluluğu: İlk denemede
The operation requires that destination domain auditing be enabledhatası alındı. Microsoft’un kendi dokümantasyonu, bu API’nin hem kaynak hem hedef domain’de Audit Account Management denetiminin açık olmasını zorunlu tuttuğunu belirtiyor yani bu teknik, denetim kapalıyken çalıştırılamıyor, dolayısıyla arkasında her zaman Event ID 4738 türünden bir iz bırakıyor. - Her iki domain controller’da da (
auditpol /set /category:"Account Management") denetimi açtıktan sonra hata değişti:No mapping between account names and security IDs was done. - Bunu çözmek için sırasıyla: trust üzerindeki SID filtering’i (
netdom trust ... /quarantine:No) kapattık, her iki DC’de Network access: Allow anonymous SID/Name translation güvenlik ayarını açtık, domain adlarını NetBIOS biçiminde verdik ve RPC bağlantısını (Test-NetConnection -Port 135) doğruladık hepsi başarılıydı, ama aynı hata ısrarla devam etti.
Add-ADReplSidHistory : No mapping between account names and security IDs was done
Bu, iki ayrı forest arasında IDL_DRSAddSidHistory çağrısının, external/tek-yönlü bir trust üzerinden beklenen isim/SID çözümlemesini tamamlayamadığını gösteriyor muhtemelen bu API, forest-transitive olmayan trust’lar için tasarlanmamış ya da ek bir güven seviyesi gerektiriyor. Sonuç olarak, güncel ve düzgün yapılandırılmış bir DSInternals sürümüyle bile, bizim lab’ımızdaki gerçekçi trust topolojisi üzerinden canlı SID History enjeksiyonu başarılamadı.
Bulgu: Rapor SID History enjeksiyonu domain admin erişimi olan bir saldırgan için tehlikelidir derken haklı, ama pratikte bu teknik artık tek bir komutla değil, üst üste birkaç güvenlik kontrolünü (yama edilmiş bir Windows sürümü gerektiren eski araçlar, kaldırılmış çevrimdışı cmdlet’ler, zorunlu denetim, karmaşık trust/isim çözümleme gereksinimleri) aşmayı gerektiriyor. Modern, sıkılaştırılmış bir iki forest AD ortamında dört farklı yöntem denendi ve dördü de farklı bir savunma katmanında durduruldu bu, raporun mitigasyon önerilerinin toplu etkisini gösteren en güçlü kanıtlardan biri.
3. Adım: Domain hopping – SID filtering gerçekten çalışıyor mu?
Bölüm 15‘te bakicubuk.local‘ın nihatcubuk.local‘a verdiği trust’ta SID filtering’in (SIDFilteringQuarantined: True) varsayılan olarak açık olduğunu görmüştük. Bunun gerçekten işe yarayıp yaramadığını test etmek için, bakicubuk.local‘da sahte bir Golden Ticket oluştururken PAC’a doğrudan nihatcubuk.local‘ın Domain Admins SID’ini (RID 512, yani <1000) ekleyip bu bileti nihatcubuk.local‘a karşı kullanmayı denedik:
kerberos::golden /user:Administrator /domain:bakicubuk.local /sid:S-1-5-21-3478788356-4009446651-4006572080 /sids:S-1-5-21-2582127750-2605409898-14747068-512 /rc4:ee2cb9cb52bfff03c183b3aac017a96b /service:krbtgt /target:nihatcubuk.local /ticket:trust_sidhistory.kirbi
kerberos::ptt trust_sidhistory.kirbi
dir \\w25pdc.nihatcubuk.local\c$Bu adım, ‘sIDHistory’ özniteliğine yazma yapmayı gerektirmiyor Golden Ticket’ın PAC’ına doğrudan sahte bir SID enjekte etme tekniği (Bölüm 15‘te çıkardığımız trust anahtarını kullanarak), bir önceki adımdaki enjeksiyon başarısızlığından bağımsız, ayrı bir saldırı yüzeyi. Bu adımın sonucu (raporun iddia ettiği gibi RID<1000 olan bu SID’in filtrelenip erişimin reddedilmesi mi, yoksa lab ortamımızın özel yapılandırması nedeniyle farklı bir sonuç mu çıkacağı) henüz test edilmedi komutları çalıştırıp gerçek sonucu paylaşmanızı bekliyorum, ona göre makaledeki bu bölümü kesinleştireceğiz.
Özet: Bu lab, raporun anlattığı klasik SID History enjeksiyonunun Windows Server 2025 üzerinde artık dört ayrı savunma katmanı (yama edilmiş eski araçlar, kaldırılmış çevrimdışı cmdlet’ler, zorunlu denetim, trust/isim çözümleme kısıtlamaları) tarafından engellendiğini canlı olarak gösterdi; buna karşın Golden Ticket üzerinden doğrudan SID enjeksiyonu ve SID filtering’in bu senaryoda gerçekten işe yarayıp yaramadığı, ayrı ve hala açık bir test alanı olarak duruyor.
Uyumluluk ve Çerçeve Eşlemesi Tablosu
| Çerçeve | İlgili Kontrol/Madde |
|---|---|
| PCI DSS | Gereksinim 7.1 (Erişim kısıtlaması), Gereksinim 10.2 (Denetim izleri) |
| HIPAA | 164.312(a)(1) – Erişim Kontrolü, 164.312(b) – Denetim Kontrolleri |
| ISO 27001 | A.9.2 (Kullanıcı Erişim Yönetimi), A.12.4 (Günlükleme ve İzleme) |
| 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 izinleri ve yetkilendirmeleri yönetilir), DE.CM-1 (Ağ izlenir) |
| CIS Controls | CIS 6 (Erişim Kontrol Yönetimi), CIS 8 (Denetim Günlüğü Yönetimi) |
MITRE ATT&CK: T1134.005 (Access Token Manipulation: SID-History Injection), T1558.001 (Golden Ticket), T1078.002 (Valid Accounts: Domain Accounts)
Sonuç
SID History ele geçirilmesi, Bölüm 15‘teki trust bypass tekniğiyle birleştiğinde, Active Directory’nin gerçek güvenlik sınırının domain değil forest olduğunu bir kez daha gösteriyor. Bir kullanıcı nesnesinin görünürde sıradan olması, ‘sIDHistory’ özniteliği sayesinde tamamen ayrıcalıklı davranabileceği gerçeğini değiştirmiyor.
Serinin bir sonraki bölümünde, kimlik doğrulama sürecinin kendisini ele geçiren bir teknik olan Skeleton Key‘i inceleyeceğiz.