Yönlü Bir Çizge Olarak Active Directory: Security Descriptor ve Nesne ACL'leri Gerçekte Nasıl Çalışır?

Active Directory Neden Yönlü Bir Çizge (graph) Veritabanı Gibi Davranır?

Bir yönetici Active Directory Users and Computers konsolunu açtığında dizin, Organizational Unit (OU) hiyerarşisinden oluşan bir ağaç gibi görünür. Ancak bu kurumsal hiyerarşi yalnızca nesnelerin LDAP içinde nerede durduğunu (distinguishedName) belirler. Kimin hangi nesne üzerinde yönetim hakkı olduğu konusunda neredeyse hiçbir şey söylemez. Bu yüzden bir denetimde yalnızca OU yapısına bakmak, yanlış bir güvenlik izlenimi verebilir.

Kaputun altında Active Directory, ntds.dit içindeki her dizin nesnesine ikili bir nTSecurityDescriptor ([MS-DTYP §2.4.6]) özniteliği ekler. Bu güvenlik tanımlayıcısının içinde, Access Control Entry (ACE) kayıtlarından oluşan sıralı bir Discretionary Access Control List (DACL) bulunur. Her ACE, kimlik doğrulamış bir kimliği (Trustee SID) hedef nesne üzerindeki belirli bir işlem kümesiyle (AccessMask ve isteğe bağlı ObjectType GUID) eşleştirir. Dizin nesnelerini düğüm (node), varsayılan dışı ACE kayıtlarını da yönlü kenar (directed edge) olarak düşündüğünde, dizin karmaşık bir yönlü çizgeye dönüşür. Bu modelin gücü, saldırı yollarını görselleştirmeyi ve tek tek izinlerin birleşerek nasıl büyük bir yetkiye dönüştüğünü anlamayı sağlamasıdır.

GOAD (Game of Active Directory) ortamında BloodHound, sevenkingdoms.local içinde tywin.lannister hesabından (parolası bir SYSVOL betiğinden kurtarılır) başlayıp Forest Root Domain Controller KINGSLANDING$ (192.168.56.10) sunucusuna uzanan kesintisiz sekiz adımlı bir yol çizer. Bu yolu parçalarına ayırmak, Windows Güvenlik Referans Monitörünün (SRM) erişim denetimlerini nasıl yaptığını ve bunun idari ele geçirmeye nasıl dönüştüğünü gösterir. Yani çizge yalnızca bir görsel değil, işletim sisteminin karar mekanizmasının modelidir.

1. Nesneye Özgü ACE Kaydının Anatomisi (ACCESS_ALLOWED_OBJECT_ACE)

NTFS dosya sistemi izinlerinde erişim maskesi genel okuma, yazma ve çalıştırma bayraklarını kodlar. Active Directory nesneleri ise bundan çok daha zengindir: onlarca ayrı öznitelik (member, servicePrincipalName, msDS-KeyCredentialLink) ve özel işlem (User-Force-Change-Password, DS-Replication-Get-Changes-All) içerir. Bu yüzden tek bir genel “yazma” biti, dizin nesnelerinin ihtiyaç duyduğu ince ayarı karşılayamaz.

Active Directory, 32 bitlik maskede bit tüketmeden ince taneli delegasyon sağlamak için Nesneye Özgü ACE’leri (ACCESS_ALLOWED_OBJECT_ACE, Tip 0x05) kullanır. Bu yapı iki parçalıdır:

1. AccessMask (ActiveDirectoryRights): İşlem sınıfını kodlar (0x00000020 = ADS_RIGHT_DS_WRITE_PROP, 0x00000100 = ADS_RIGHT_DS_CONTROL_ACCESS, 0x00040000 = WRITE_DAC, 0x00080000 = WRITE_OWNER, 0x10000000 = GENERIC_ALL).
2. ObjectType (128-bit GUID): AccessMask’ı belirli bir öznitelik şema GUID’ine veya Extended Right GUID’ine daraltır. ObjectType boş (GUID_NULL) olduğunda izin, nesnedeki tüm öznitelikler veya tüm işlemler için koşulsuz geçerlidir.

sevenkingdoms.local içindeki sekiz hedefte miras alınmamış ACE kayıtlarını impacket-dacledit ile incelediğimizde zincirin tamamı tek bir tabloda görünür:

Principal (Trustee SID)                  RightName            Inherited  Target Object (SID)
---------------------------------------  -------------------  ---------  ---------------------------------------------
TYWIN.LANNISTER (...-1113)               ForceChangePassword  False      JAIME.LANNISTER (...-1114)
JAIME.LANNISTER (...-1114)               GenericWrite         False      JOFFREY.BARATHEON (...-1118)
JOFFREY.BARATHEON (...-1118)             WriteDacl            False      TYRON.LANNISTER (...-1116)
TYRON.LANNISTER (...-1116)               AddSelf              False      SMALL COUNCIL (...-1108)
SMALL COUNCIL (...-1108)                 AddMember            False      DRAGONSTONE (...-1109)
DRAGONSTONE (...-1109)                   WriteOwner           False      KINGSGUARD (...-1110)
KINGSGUARD (...-1110)                    GenericAll           False      STANNIS.BARATHEON (...-1120)
STANNIS.BARATHEON (...-1120)             GenericAll           False      KINGSLANDING.SEVENKINGDOMS.LOCAL (...-1001)

Tablodaki Inherited = False değeri önemlidir: bu izinler üst kaptan miras alınmamış, doğrudan nesneye yazılmıştır. Yani birisi bu ACE’leri bilinçli olarak eklemiştir. BloodHound gibi araçların yolu çizebilmesi de tam olarak bu açık kayıtlar sayesindedir.

2. Genişletilmiş Haklar (Extended Rights): Öznitelik Yazmanın Ötesi

1. adım, iki parçalı ACE yapısının neden var olduğunu gösterir. Bir kullanıcının parolası LDAP üzerinden düz metin bir dize yazılarak güncellenemez; unicodePwd özel bir protokol sarmalaması gerektirir. Mevcut parolayı bilmeden parola sıfırlamak ise bir Extended Right (ADS_RIGHT_DS_CONTROL_ACCESS / 0x100) işlemidir. Yani “parola yazma” gibi görünen şey, aslında ayrı bir işlem sınıfıdır:

$ impacket-dacledit -action read -principal tywin.lannister -target jaime.lannister \
    'sevenkingdoms.local/samwell.tarly:Heartsbane' -dc-ip 192.168.56.10
[*] ACE[0] info:
[*]   ACE Type                  : ACCESS_ALLOWED_OBJECT_ACE
[*]   AccessMask                : ControlAccess (0x00000100)
[*]   ObjectType                : User-Force-Change-Password (00299570-246d-11d0-a768-00aa006e0529)

AccessMask değeri 0x00000100 olduğunda KDC, ObjectType GUID’ini CN=Extended-Rights,CN=Configuration altındaki tanımlarla eşleştirir. Bu iki GUID, bu yazıda en çok karşılaşacağın örneklerdir:

• 00299570-246d-11d0-a768-00aa006e0529 (User-Force-Change-Password): tywin.lannister’ın jaime.lannister üzerinde RPC SamrSetInformationUser (net rpc password) veya LDAPS parola değişikliği (bloodyAD set password) yapmasını sağlar.
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All): Etki alanı bölümü kökünde (DC=sevenkingdoms,DC=local) verildiğinde, DC olmayan hesapların DRSGetNCChanges (DCSync) çağırarak orman genelindeki parola hash’lerini çekmesini sağlar.

Bu ayrımın pratik sonucu şudur: bir hesabın “yazma” izni olduğunu görmek, onun parola sıfırlayabileceği anlamına gelmez. Extended Rights, işlemin türünü ayrı bir GUID ile tanımlar; yanlış hakkı okumak, saldırıyı da yanlış planlamana yol açar.

3. Öznitelik Yazma İzinleri: Kapsamlı Haklar ve GenericWrite

2., 4. ve 5. adımlar öznitelik yazma delegasyonunu gösterir. Buradaki ince nokta, WriteProperty hakkının hangi özniteliğe daraltıldığıdır:

1. AddMember (SMALL COUNCIL → DRAGONSTONE): AccessMask = 0x20 (WriteProperty) ile ObjectType = bf9679c0-0de6-11d0-a285-00aa003049e2 (yani member özniteliğinin şema GUID’i) birleşir. SMALL COUNCIL üyesi olan herkes DRAGONSTONE grubuna istediği kullanıcı hesabını ekleyebilir.
2. AddSelf (tyron.lannister → SMALL COUNCIL): ADS_RIGHT_DS_SELF (0x08) bayrağını Self-Membership GUID’i (bf9679c0-0de6-11d0-a285-00aa003049e2) ile birleştirir. tyron.lannister yalnızca kendi kimliğini gruba eklemekle sınırlıdır.
3. GenericWrite (jaime.lannister → joffrey.baratheon): GUID filtresi olmadan tüm korumasız öznitelikler üzerinde WriteProperty (0x20) verir. Kritik olarak GenericWrite içinde ControlAccess (0x100) yoktur; bu yüzden jaime doğrudan joffrey’nin parolasını zorla sıfırlayamaz.

Buna karşılık GenericWrite, üç modern hesap ele geçirme tekniğini açar. Bunların her biri, aynı geniş yazma hakkının farklı bir özniteliğe uygulanmasıdır:

• Shadow Credentials (msDS-KeyCredentialLink): msDS-KeyCredentialLink (5b47d60f-6090-40b2-9f37-2a4de88f3063) alanına bir X.509 sertifika açık anahtarı yazmak, kullanıcının parolasını değiştirmeden PKINIT üzerinden Kerberos TGT’si almayı ve NT hash’ini kurtarmayı sağlar.
• Hedefli Kerberoasting (servicePrincipalName): servicePrincipalName alanına sahte bir SPN yazıp servis bileti istemek ve parola hash’ini çevrimdışı kırmak mümkün olur.
• Bilgisayarda RBCD (msDS-AllowedToActOnBehalfOfOtherIdentity): Hedef bir bilgisayar olduğunda, msDS-AllowedToActOnBehalfOfOtherIdentity alanına bir makine hesabı SID’i yazmak, Administrator olarak S4U2Proxy çalıştırılmasını sağlar.

Bu üç yolun ortak noktası şudur: hepsi tek bir GenericWrite hakkıyla başlar, ama hangisinin işe yarayacağı hedefin türüne ve ortamda AD CS bulunup bulunmadığına bağlıdır.

4. Güvenlik Tanımlayıcısını Değiştirmek: WriteDacl, WriteOwner ve GenericAll

3., 6., 7. ve 8. adımlar doğrudan nTSecurityDescriptor ikili yapısını hedef alır. Bu, “nesnenin verisini değiştirmek” ile “nesne hakkındaki kuralları değiştirmek” arasındaki farktır:

• WriteDacl (0x00040000, joffrey → tyron): Hedefin DACL’ini yeniden yazma izni verir; böylece hedefe açık bir GenericAll ACE’si enjekte edilebilir.
• WriteOwner (0x00080000, DRAGONSTONE → KINGSGUARD): Nesnenin Sahip SID değerini değiştirmeye izin verir. Windows SRM mimarisinde ([MS-DTYP]), bir nesnenin sahibi, DACL açıkça erişimi reddetse bile örtük READ_CONTROL ve WRITE_DAC (0x00040000) haklarına sahiptir. Bu nedenle WriteOwner, matematiksel olarak WriteDacl ile eşdeğerdir.
• GenericAll (0x10000000, stannis → KINGSLANDING$): Tüm standart, özel ve genel hakları kapsar. Bir Domain Controller’ın bilgisayar nesnesi üzerinde GenericAll tutmak, RBCD veya Shadow Credentials yoluyla anında ele geçirme ve ardından DCSync ile etki alanı hakimiyeti demektir.

Buradaki ortak ders, izinlerin birbirine dönüşebilmesidir. WriteOwner doğrudan üye ekleme hakkı vermez, ama WriteDacl’a, o da GenericAll’a dönüşür. Bu yüzden bir nesnedeki “sadece sahiplik” gibi görünen küçük bir sapma, zincirin en tehlikeli halkası olabilir.

Telemetri ve Savunma Mühendisliği

Dizin Erişim Denetimi Telemetri Matrisi

// KQL Query: Detect Unauthorized Modifications to Active Directory Security Descriptors
SecurityEvent
| where EventID == 5136
| where AttributeLDAPDisplayName in~ ("nTSecurityDescriptor", "msDS-AllowedToActOnBehalfOfOtherIdentity", "msDS-KeyCredentialLink")
| project TimeGenerated, Computer, SubjectUserName, ObjectDN, AttributeLDAPDisplayName, OperationType

Sıkılaştırma ve Sınır Uygulaması

1. AdminSDHolder Korumasını Zorunlu Kıl: Yüksek ayrıcalıklı nesneler (Domain Admins, Enterprise Admins) AdminSDHolder tarafından korunmaya devam etmelidir. SDProp süreci her 60 dakikada bir çalışarak yetkisiz DACL değişikliklerinin üzerine yazar.
2. Tier-0 Nesne Sahipliğini Denetle: Tier-0 hesap ve grupların Sahip SID değerinin yalnızca Domain Admins veya Enterprise Admins olduğundan emin ol.
3. Geçişli İzin Zincirlerini Ortadan Kaldır: BloodHound kullanarak Tier-2 veya Tier-1 kimliklerini Tier-0 varlıklarına bağlayan geçişli izin zincirlerini denetle ve buda.

ACL Primitiflerinin Özeti

Kanıt ve sınırlar

ACE dökümleri, GUID’ler ve sekiz adımlı örnekler, Bölüm 3’te kullanılan GOAD dizininden gelir. impacket-dacledit çıktısı, ilgili BloodHound kenarları ve Microsoft’un ACCESS_ALLOWED_OBJECT_ACE, erişim maskeleri ve nesneye özgü hak tanımlarıyla karşılaştırıldı. Bu nedenle yazı BloodHound’u bir yol bulucu, dizin güvenlik tanımlayıcısını ise otorite olarak ele alır. Bir çizge kenarı, kesin ACE ve hedef davranışı doğrulanana kadar test edilebilir bir hipotezdir.

Bu yazı eksiksiz bir Windows yetkilendirme modeli değildir. Miras alma, deny ACE sıralaması, AdminSDHolder, korumalı nesneler, doğrulanmış yazmalar (validated writes) ve uygulamaya özgü kontroller etkin erişimi değiştirebilir. Buradaki örnekler yalnızca izole GOAD laboratuvarında doğrulandı; üretimde aynı ACE’yi görsen bile hedefin davranışını ayrıca test etmen gerekir.

Kaynaklar

• Microsoft Open Specifications, [MS-ADTS] §5.1.3 Authorization: learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts
• Microsoft Open Specifications, [MS-DTYP] §2.4.6 SECURITY_DESCRIPTOR and ACE Structures: learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp
• Orange Cyberdefense, GOAD (Game of Active Directory): orange-cyberdefense.github.io/GOAD
• MITRE ATT&CK, File and Directory Permissions Modification: Windows (T1222.001): attack.mitre.org/techniques/T1222/001