SID, RID ve objectGUID: İsimden bağımsız kimlik.

1. Core Mechanism / Temel mekanizma

Bu ders isimden bağımsız kimlik sabitlerini ele alır: objectSid'in bileşenleri, RID'in atanması ve objectGUID'in kalıcılığı. Adlar (cn/DN/UPN/sAMAccountName) 03.02'de; SID'lerin access token'a nasıl konduğu ve access check 02.03–02.04'te; forest genelindeki dağıtım 03.04'te ele alınır. SID'in RPC/paket marshalling ayrıntısı MS-DTYP'a bırakılır; burada string gösterim ve bileşen anlamı incelenir.

Arabirimler ve belirtimler

• objectSid: security principal'ı tanımlayan binary SID; hesap oluşturulurken atanır, rename/same-domain OU move sırasında sabit kalır, cross-domain move'da yenilenir.
• Revision (R): SID yapısının sürümü (pratikte 1).
• Identifier authority (X): SID'i veren en üst otorite; NT Authority için 5, World Authority için 1.
• Domain identifier: subauthority dizisinin RID'e kadarki bölümü; bir domain'i forest içinde ayırır (ör. 21-...).
• RID: dizideki son subauthority; hesabı domain içinde ayırır ve asla yeniden kullanılmaz.
• objectGUID: her nesneye oluşumda atanan, dünya çapında benzersiz 128-bit kimlik; rename/move'da değişmez.
• sIDHistory: nesne başka domain'e taşındığında eski objectSid'lerin eklendiği multi-valued attribute.

SID bir hiyerarşidir, tek bir sayı değil

String biçiminde bir SID S-R-X-Y1-Y2-...-Yn olarak yazılır: S sabit önektir, R revision, X identifier authority ve Y'ler bir dizi subauthority değeridir. Örneğin S-1-5-21-3623811015-3361044348-303003820-1108 SID'inde revision 1, identifier authority 5 (NT Authority), 21-3623811015-3361044348-303003820 domain identifier ve 1108 RID'dir.

Domain hesaplarında SID, domain SID'i ile hesaba özgü bir RID'in birleştirilmesiyle üretilir. Domain identifier bir domain'i forest içindeki diğerlerinden ayırır; RID ise o domain içindeki hesabı diğerlerinden ayırır. Built-in gruplar farklıdır: her makinede aynı domain identifier 32 ile gelirler, örneğin Administrators için S-1-5-32-544.

RID nasıl atanır ve neden benzersizdir

Bir domain'de birden çok domain controller olabilir ve her biri hesap veritabanının bir master kopyasını tutar. RID çakışmasını önlemek için RID ataması tek-master bir işlemdir: RID master rolündeki DC, her DC'ye bir RID bloğu tahsis eder; her DC bir bloktaki her değeri yalnız bir kez kullanır ve blok bittikçe RID master'dan yenisini ister.

Bunun güvenlik sonucu şudur: security authority aynı SID'i iki kez vermez ve silinen hesapların SID'ini yeniden kullanmaz. Bir kullanıcı işten ayrılıp hesabı silinir ve sonra dönerse, açılan yeni hesap yeni bir RID ile yeni bir SID alır; eski erişimlerinin hiçbiri bu yeni principal'a taşınmaz.

objectGUID: değişmeyen çapa

objectGUID, Active Directory'nin bir nesne oluşturulurken atadığı 128-bit değerdir ve yalnız enterprise içinde değil dünya çapında benzersizdir. Nesnenin distinguishedName'i rename veya move ile değişse bile objectGUID hiçbir zaman değişmez; bu yüzden bir nesneyi bulmanın en güvenilir yolu çoğu zaman objectGUID'dir.

Bu ayrım pratikte kritik: objectSid access check'in kullandığı güvenlik kimliğidir; objectGUID ise directory nesnesinin çapasıdır. Rename ve aynı-domain OU move sırasında ikisi de sabit kalır; domainler arası move objectSid'i değiştirir ve eski SID'i sIDHistory'ye taşır, objectGUID ise nesneyle kalır. Bir soruşturmada 'aynı adı taşıyan iki farklı nesne' problemini GUID/SID kanıtıyla çözersiniz.

sIDHistory: taşımanın kimlik izi

Domainler arası move yeni objectSid üretir ve eski SID sIDHistory’ye eklenir. Bu directory attribute’u tek başına bir erişim kararı değildir. Geçerli logon ve trust koşullarında kabul edilen SID’ler access token’a katılır; kaynakta yapılan access check bu token’daki SID’leri DACL ACE’lerinin trustee SID’leriyle karşılaştırır. Trust üzerinden taşınan authorization data için SID filtering, hangi eski SID’lerin kabul edileceğini sınırlayabilir. Bu nedenle aynı sIDHistory kaydı her hedefte aynı erişim sonucu demek değildir.

Bu kolaylık bir güven yüzeyidir: erişim SID karşılaştırmasıyla verildiğinden, bir hesabın sIDHistory'sine ayrıcalıklı bir SID koyabilmek, o ayrıcalığı isimden bağımsız olarak taşımak demektir. Red katmanı bu varsayımı işler.

Durum ve veri akışı

1. Yeni bir domain hesabı oluşturulur; DC, domain SID'ine RID master'dan gelen bloktan bir RID ekleyerek objectSid'i üretir.
2. Sistem nesneye aynı anda benzersiz bir objectGUID atar; bu değer ömür boyu sabittir.
3. Hesap rename veya aynı domain içindeki OU move edilir: cn/DN değişir, objectSid ve objectGUID sabit kalır, SID'e dayalı ACE'ler aynı hesaba uygulanmaya devam eder.
4. Hesap silinip aynı adla yeniden oluşturulur: yeni bir RID ile yeni bir objectSid üretilir; eski ACE'ler yeni principal'a uymaz.
5. Domainler arası move’da objectGUID korunur, objectSid yenilenir, eski SID sIDHistory’ye eklenir. Logon/trust koşullarında kabul edilen SID’ler yeni token’a katılır.
6. Kaynak, token SID’lerini ACE trustee SID’leriyle karşılaştırır. Rename aynı principal’ı korur; aynı adla recreate eski SID’i geri getirmez. SID eşleşmesi, ACE sırası ve istenen hak gibi diğer access-check koşullarının yerine geçmez.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: Kimlik adla eşdeğerdir; adı geri almak erişimi geri getirir ve sIDHistory yalnızca zararsız bir taşıma kaydıdır.

Technical prerequisites

• Erişim kararlarının güncel objectSid yerine ada veya eski/temizlenmemiş SID referanslarına dayanması.
• sIDHistory'ye SID ekleyen ayrıcalıklı migration akışına veya domain controller/directory store üzerinde daha geniş yetkiye sahip olunması. Örneğin interforest migration için belgelenen DsAddSidHistory API'si hedef domain'de Domain Admin, kaynak domain'de ise Administrator ya da Domain Admin yetkisi gerektirir.
• İlgili cross-domain trust boundary'sinin kaynak SID'in hedef authorization data'ya geçmesine izin vermesi; hangi SID'lerin kabul edildiği trust type ve filtering yapılandırmasına bağlıdır.
• Silinen hesaplara ait ACE'lerin (orphaned SID) kaynaklarda temizlenmeden kalması.

Exploitation mechanism / İstismar mekanizması

Bir token'ın yetkileri current objectSid, grup SID'leri ve sIDHistory değerlerinden kurulur; access check adları değil SID'leri karşılaştırır. Bu yüzden yetkili bir migration işlemiyle sIDHistory'ye privileged SID eklemek (veya o SID'in ilgili trust boundary'sinden geçmesine izin verilmesi), hesabın görünen adını değiştirmeden erişim taşıyabilir. Örneğin interforest migration için belgelenen DsAddSidHistory API'si hedef domain'de Domain Admin ve kaynak domain'de Administrator/Domain Admin yetkisi gerektirir; genel bir Write Property delegasyonu tek başına bu API'nin denetimini karşılamaz. Aynı SID-temelli mantık ters yönde de varsayımı bozar: silinip yeniden oluşturulan hesap yeni bir RID aldığından, silinen hesabın ACE'lerini miras almaz; 'aynı isim = aynı erişim' beklentisi yanlıştır. Kapsam, trust type/configuration ve sIDHistory yazma yetkisinin kimde olduğudur; engelleyici kontrol trust boundary'nin uygun SID filtering kurallarını uygulamak, sIDHistory yazımını Domain Admin/migration akışlarıyla sınırlamak ve orphaned SID'leri temizlemektir.

İki yönlü yanılma

İlk yönde tehlike, privileged SID'in sIDHistory ya da trust boundary'nin kabul ettiği authorization data yoluyla hesaba iliştirilmesidir; hesap adı sıradan görünse de token yüksek ayrıcalık taşıyabilir. İkinci yönde ise güvenlik yanılması vardır: 'eski adı geri aldık, eski erişimler döner' beklentisi RID yeniden kullanılmadığı için gerçekleşmez. interforest migration için belgelenen DsAddSidHistory yolu hedef domain'de Domain Admin, kaynak domain'de Administrator/Domain Admin yetkisi gerektirir; sıradan bir attribute delegasyonu bu şartı otomatik karşılamaz.

Değerlendirme, erişimi hangi alanın belirlediğini netleştirmelidir. Karar objectSid'e bağlıysa rename dayanıklıdır; ada veya temizlenmemiş eski SID'lere bağlıysa yanlış eşleşme ve ayrıcalık taşınması riski doğar.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• sIDHistory eklenmesi Audit User Account Management alt kategorisinde 4765 (SID History was added to an account) olarak kaydedilir; bu olay yalnız domain controller'larda üretilir ve Version 0'dır.
• 4765 belgesinde örnek Event XML ve adlandırılmış EventData alanı yayımlanmaz; şema Subject, Target Account, Source Account ve SID List bölümlerini tarif eder.
• sIDHistory bir directory attribute olduğundan değişimi ayrıca Directory Service Changes altında 5136 (AttributeLDAPDisplayName='sIDHistory', AttributeSyntaxOID='2.5.5.17') olarak da yüzeye çıkabilir ve nesnenin SACL'ini gerektirir.
• objectGUID, rename/move boyunca sabittir; objectSid de rename ve aynı-domain OU move'da sabit kalır, ancak cross-domain move'da yenilenir ve eski SID sIDHistory'ye taşınır. 5136'daki ObjectGUID alanı değişiklik kaydını isimden bağımsız doğru nesneye bağlar.

Events and relevant fields

• 5136 kaydında ObjectGUID alanı, nesnenin adı değişmiş olsa bile kaydı doğru nesneye sabitler; aynı adlı iki nesneyi ObjectGUID ayırır.
• AttributeLDAPDisplayName='sIDHistory' ve AttributeSyntaxOID='2.5.5.17' (String(Sid)) bir sIDHistory yazımını schema tanımına bağlar.
• 4765 dedicated olay; adlandırılmış alanları yayımlanmadığından bu derste 4765 için named-field XPath üretilmez, yalnız Event ID ile seçilir.
• 5136’nın belgelenmiş XML’inde SubjectUserSid ve SubjectLogonId, değişikliği isteyen principal ve onun oturumunu gösterir; aynı DC’deki 4624 ile aday korelasyon kurulabilir. 4765 belgesi ise Subject / Security ID ve Logon ID şema etiketlerini verir; bu derste bu etiketlerden EventData alan adı türetilmez. Logon ID tek başına kimlik doğrulama ya da kötüye kullanım kanıtı değildir.

Aynı adı GUID/SID ile ayır

İki nesne aynı görünen adı taşıyabilir; hangisinin hangisi olduğunu ad değil, objectGUID ve objectSid söyler. 5136 kaydındaki ObjectGUID alanı bu yüzden soruşturmanın çapasıdır: rename veya recreate olsa bile kaydı doğru nesneye bağlar.

sIDHistory izlemesi ise 'bu hesap hangi eski kimlikleri taşıyor' sorusunu yanıtlar. Bir yetki beklenmedik biçimde çalışıyorsa, token'daki sIDHistory değerleri ve kaynaktaki SID-temelli ACE'ler birlikte incelenmelidir; ada bakmak yanıltır.

Detection logic · XPath

*[System[EventID=5136]] and *[EventData[Data[@Name='AttributeLDAPDisplayName']='sIDHistory']]

Query assumptions

• İfade tek bir Windows Event Log belgesinde 5136'nın sIDHistory değişimlerini seçer; 4765 dedicated olayı Event ID ile ayrıca izlenmelidir.
• Named-field seçimi yalnız EventData/Data/@Name değerleri bu adlarla üretiliyorsa çalışır; backend'in düzleştirmesi doğrulanmalıdır.
• 5136 üretimi hedef nesnenin SACL'ine bağlıdır; SACL sIDHistory'yi kapsamıyorsa olay hiç oluşmaz.
• Sorgu bu oturumda gerçek bir DC veya SIEM üzerinde çalıştırılmadı; eşik ve veri kümesi yoktur.

False positives

• Meşru domain migration ve konsolidasyon projelerinde sIDHistory eklenmesi beklenen bir işlemdir.
• Migration araçlarının toplu çalışması çok sayıda 4765/5136 üretebilir; olay tek başına kötü niyet göstermez.
• Bağlam (kaynak SID'in ayrıcalık düzeyi, kim ekledi, hangi trust) olmadan tek bir olay zayıf sinyaldir.
• Olayın yokluğu sIDHistory kullanılmadığını değil, SACL'in bu attribute'u kapsamadığını da gösterebilir.

Hardening

• Domain'ler arası trust'larda SID filtering/quarantine durumunu envanterle ve gerekmedikçe dış SID'leri filtrele; kaldırmayı ancak migration ihtiyacı ve doğrulama ile yap.
• sIDHistory yazımını ayrıcalıklı migration süreçleriyle sınırla; hangi hesapların bu attribute'u değiştirebildiğini least-privilege ile gözden geçir.
• Yetkilendirmeyi güncel objectSid'e bağla; silinen hesaplara ait orphaned SID ACE'lerini kaynaklarda düzenli temizle.
• 4765 ve sIDHistory 5136 olaylarını yüksek değerli SID'ler için özel izle; kontrolü uygulamadan önce pilot kapsamda etkisini ölç ve geri dönüş planı tut.

Örnekler üzerinde oku / Read the examples

O:DAG:DUD:(A;;GRGWGX;;;S-1-5-21-3623811015-3361044348-303003820-1108)(D;;GA;;;S-1-5-21-3623811015-3361044348-303003820-1109)(A;;GRGX;;;S-1-5-21-3623811015-3361044348-303003820-513)S:(AU;SA;GWGA;;;S-1-5-21-3623811015-3361044348-303003820-1108)

İki yanlış kanı / Two reality checks

Sanılan: Bir çalışan işten ayrılıp geri dönünce eski adıyla yeni hesap açmak, onun eski dosya ve grup erişimlerini geri getirir.

Gerçekte: Silinen hesabın SID'i (dolayısıyla RID'i) asla yeniden kullanılmaz; yeni hesap yeni bir SID alır. SID'e dayalı ACE'ler ve grup üyelikleri eski SID'e bağlı olduğundan yeni principal'a taşınmaz. Erişimin geri gelmesi ancak açık yeniden yetkilendirme veya sIDHistory ile eski SID'in taşınmasıyla olur.

Sanılan: objectGUID ve objectSid aynı şeyin iki yazımıdır; biri diğerinden türetilir.

Gerçekte: objectGUID ve objectSid farklı amaçlara hizmet eder: objectSid access check'te kullanılan SID'dir; objectGUID oluşumda atanan 128-bit nesne kimliğidir. Rename ve aynı-domain OU move'da ikisi de sabittir; nesne başka domain'e taşındığında yeni objectSid atanır ve eski SID sIDHistory'ye eklenir, objectGUID sabit kalır.

Kaynaklar / Sources

• Microsoft · Security Identifiers
  SID architecture, S-R-X-Y notasyonu, RID allocation ve SID'lerin yeniden kullanılmaması
• Microsoft Open Specifications · [MS-DTYP] SID
  SID string sözdizimi, 96-bit account-store identifier ve 32-bit RID
• Microsoft · User Naming Attributes
  objectGUID (oluşumda atanır, değişmez), objectSid ve sIDHistory (cross-domain move)
• Microsoft · ACE strings
  SDDL ACE sözdizimi; A/D/AU türleri ve GR/GW/GX/GA generic rights
• Microsoft · 4765(S) SID History was added to an account
  Event Schema (Subject/Target/Source Account, SID List), DC-only, Version 0
• Microsoft · 5136(S) A directory service object was modified
  ObjectGUID, AttributeLDAPDisplayName ve syntax OID (String(Sid) 2.5.5.17)
• Microsoft · DsAddSidHistoryW function
  Security-sensitive sIDHistory addition; source/destination account parameters and privilege requirements linked through Using DsAddSidHistory
• Microsoft · Using DsAddSidHistory
  Authorization Requirements, Threat Models, and requirements for Domain Admin at destination and Administrator/Domain Admin at source
• Microsoft Open Specifications · [MS-PAC] SID Filtering and Claims Transformation
  §4.1.2.2 trust boundary types and SID filtering rules; effective filtering depends on trust boundary