T1098PersistenceUzman

Active Directory ACL/DACL Suistimali: GenericAll'dan Gölge Kimlik Bilgilerine ve AdminSDHolder Kalıcılığına

HARDEC · Savunma Güvenliği Ekibi·Yayın: 13 Haziran 2026·Güncelleme: 25 Temmuz 2026·43 dk okuma

Active Directory'de her nesneye eklenmiş DACL üzerindeki tehlikeli haklar (GenericAll, WriteDACL, WriteOwner, AllExtendedRights, ForceChangePassword, AddMember) ele geçirildiğinde saldırgan parola sıfırlama, gruba ekleme, hedefli Kerberoasting, gölge kimlik bilgisi ekleme ve DCSync yetkisi verme zincirlerini yalnızca birkaç LDAP işlemiyle tetikleyebilir. AdminSDHolder nesnesine eklenen tek bir ACE, SDProp mekanizmasıyla 60 dakikalık döngüde tüm korumalı nesnelere yayılarak kendini onarabilen bir arka kapı oluşturur. Tespit; Event 5136/4662/4670 üzerinde nitelik bazlı davranışsal izleme, önlem ise asgari ayrıcalık, katmanlı yapı ve periyodik BloodHound ACL denetimine dayanır.

Exploit

Prevention

Detection

Savunma profili:15 detection kuralı 9 önlem 16 baseline kontrolü 6 müdahale playbook'u

Kaydırarak veya oklarla bölümler arasında geçin

Bölüm 1 / 3

Zafiyet (Vulnerability)

Tehdit bağlamı, zafiyet ve istismar senaryosu

Mimari, Zafiyet Yüzeyi ve Suistimal Zincirleri

1.1 Yönetici Özeti

Active Directory’deki kullanıcı, grup, bilgisayar, OU, GPO ve domain gibi nesneler, güvenlik tanımlayıcısıyla korunan erişim denetimine tabi nesnelerdir. DACL içindeki ACE’ler, hangi güvenlik principal’ının hangi nesne üzerinde ne yapabileceğini belirler.

Bu bir CVE değildir. Sorun; meşru yönetim ve delegasyon için tasarlanmış hakların yanlış principal’a, yanlış nesneye veya gereğinden geniş kapsamda verilmesidir.

Düşük ayrıcalıklı hesap
  → tehlikeli doğrudan/devralınan ACE
  → hedef nesne üzerinde kontrol
  → parola sıfırlama, grup üyeliği, SPN yazma,Shadow Credentials, RBCD veya DCSync
  → ayrıcalık yükseltme / kalıcılık / domain compromise

Hak	Tipik etki
`GenericAll`	Hedef nesne üzerinde tam denetim
`GenericWrite`	Çok sayıda özelliği ve validated write işlemini değiştirme
`WriteDACL`	Yeni ACE ekleme veya mevcut ACE’leri kaldırma
`WriteOwner`	Sahipliği alarak DACL kontrolüne ilerleme
`ForceChangePassword`	Mevcut parolayı bilmeden sıfırlama
`AddMember` / `AddSelf`	Gruba üyelik ekleme
`WriteSPN`	Hedefli Kerberoasting
`AddKeyCredentialLink`	Shadow Credentials
`AddAllowedToAct`	Resource-Based Constrained Delegation
Replikasyon hakları	DCSync

Not: AD güvenliği yalnızca “kim Domain Admin?” sorusuyla ölçülemez. Asıl soru, kimin hangi ACL zinciri üzerinden Domain Admin veya eşdeğer Tier 0 yetkisine ulaşabildiğidir.

1.2 Amaç ve Kapsam

Bu bölüm:

1. Security descriptor, DACL, SACL ve ACE mimarisini
2. Generic, object-specific ve validated write haklarını
3. Tehlikeli BloodHound sınırlarını
4. ACL hakkından ayrıcalık yükseltmeye giden zincirleri
5. AdminSDHolder ve GPO tabanlı kalıcılığı
6. Test doğrulama yaklaşımını

ele alır.

Cok uzun olmaması sınırların net olması icin aşagıdaki başlıklar Kapsam dışı bırakılmıştır:

Entra ID RBAC,
AD CS ESC teknikleri,
Kerberoasting parola kırma ayrıntıları,
NTLM relay ile ACL yazımı,
tam GPO içerik enjeksiyonu,
prevention ve detection kuralları.

1.3 Güvenlik Tanımlayıcısının Yapısı

AD nesnesinin nTSecurityDescriptor niteliği temel olarak şu bileşenleri içerir:

Bileşen	İşlev
Owner SID	Nesnenin sahibi
Primary Group SID	AD erişim kararlarında pratik kullanımı sınırlı tarihsel alan
DACL	Erişime izin veren veya erişimi reddeden ACE listesi
SACL	Hangi işlemlerin denetim olayı üreteceğini belirler
Control flags	Inheritance ve DACL/SACL davranışını belirler

SACL nüansı

SACL özellikle şu olayların güvenilir üretilmesi için önemlidir:

4662 — An operation was performed on an object

5136 — A directory service object was modified

Ancak parola sıfırlama olayı olan 4724, nesne SACL’ından değil Account Management audit politikasından gelir. Bu nedenle “SACL yoksa 4724 üretilmez” denmemelidir.

1.4 Empty DACL ve Null DACL

Durum	Sonuç
Empty DACL	DACL vardır ancak ACE yoktur; erişim reddedilir
Null DACL	DACL yoktur; normal access check uygulanmaz ve herkese erişim verilir

AD DS, normal LDAP güncellemesiyle bir nesneye Null DACL yazılmasını desteklemez ve bunu reddeder. Bunun nedeni “her schema class mutlaka defaultSecurityDescriptor içerir” şeklinde genellenmemelidir. Daha doğru ifade etmek gerekirse, AD DS’nin Null DACL saklanmasına izin vermemesidir.

1.5 ACE Yapısı

Bir ACE şu temel alanlardan oluşur:

Alan	Açıklama
ACE type	Allow, Deny veya object-specific varyant
Access mask	Verilen veya reddedilen hak bitleri
Trustee SID	Hakkın uygulandığı principal
Object Type GUID	Özellik, property set, validated write veya control-access right
Inheritance flags	ACE’nin alt nesnelere uygulanma biçimi

Object Type GUID boş olduğunda sonuç ACE’deki access-mask türüne bağlıdır. Örneğin WriteProperty ile birlikte boş GUID görülmesi tüm yazılabilir özellikleri kapsayabilir ama bu durum “ACE nesne üzerindeki her türlü hakkı verir” anlamına gelmez.

1.6 ACE Değerlendirme Mantığı

Tercih edilen canonical sıra genel olarak şöyledir:

1. Explicit Deny

2. Explicit Allow

3. Inherited ACE’ler:

a. en yakın atadan en uzağa,

b. her seviyede Deny önce Allow

Ancak “ilk eşleşen ACE tüm isteğin sonucunu belirler” ifadesi aşırı basitleştirmedir. Windows erişim denetimi, talep edilen access mask içindeki izin bitlerini toplu olarak değil, hak bazında değerlendirir. Allow ACE'ler talep edilen hakların bir kısmını veya tamamını karşılayabilir; buna karşılık uygun bir Deny ACE, henüz verilmemiş haklardan herhangi birini açıkça reddedebilir

Ayrıca object-specific ACE'ler, property set'ler, extended rights ve çok seviyeli inheritance yapıları değerlendirme sürecini daha karmaşık hâle getirir. Bu nedenle erişim kontrolünün sonucu yalnızca ACE sırasına bakılarak değil, talep edilen haklar ile tüm ilgili ACE'lerin birlikte değerlendirilmesiyle belirlenir.

1.7 Owner ve WriteOwner Gerçeği

Bir nesnenin sahibi (owner), varsayılan olarak aşağıdaki haklara sahiptir:

"READ_CONTROL" & "WRITE_DAC"

Haklarına sahip olur.

Owner doğrudan GenericAll almaz.

Ancak owner olmak, tek başına GenericAll (Full Control) hakkı vermez. Bunun yerine yetki yükseltme zinciri genellikle şu şekilde işler:

Owner
  ↓
WRITE_DAC
  ↓
DACL'i değiştirebilme
  ↓
Kendisine gerekli ACE'leri ekleyebilme
  ↓
Full Control (GenericAll)

İstisnalar

Owner'a tanınan bu örtük (implicit) haklar her durumda geçerli değildir:

DACL içerisinde OWNER RIGHTS (S-1-3-4) SID'i için tanımlanmış ACE'ler bulunuyorsa, owner'ın varsayılan READ_CONTROL ve WRITE_DAC hakları sınırlandırılabilir veya tamamen kaldırılabilir.
Active Directory'de BlockOwnerImplicitRights davranışı etkin olduğunda, belirli koşullar altında owner'ın sahiplikten kaynaklanan WRITE_DAC yetkisi göz ardı edilebilir. Bu mekanizma özellikle bilgisayar nesneleri (computer objects) ve bunlardan türetilen nesnelerde yetki yükseltme senaryolarını engellemek amacıyla uygulanır.
BlockOwnerImplicitRights davranışının kapsamı ve uygulanma şekli işletim sistemi sürümüne göre değişebildiğinden, değerlendirme yapılırken güncel Microsoft dokümantasyonu esas alınmalıdır.

WriteOwner

WRITE_OWNER sahibi normalde owner değerini kendisine veya token’ında owner olarak kullanılabilen bir SID’e değiştirebilir. Başka bir principal’ı keyfî biçimde owner yapmak için tipik olarak SeRestorePrivilege gerekir. SeTakeOwnershipPrivilege, erişim verilmemiş olsa bile sahipliği almayı sağlar ancak keyfî üçüncü taraf atama hakkı değildir.

1.8 Tehlikeli Haklar

Hak	Teknik kapsam	Suistimal
`GenericAll`	Genel tam denetim	Hedef nesne türüne göre tüm kritik işlemler
`GenericWrite`	`READ_CONTROL`, property write ve validated write eşlemeleri	SPN, script path, delegation ve benzeri özellikler
`WriteDACL`	DACL değiştirme	Kendine yeni hak veya DCSync hakkı verme
`WriteOwner`	Owner değiştirme	Owner → `WRITE_DAC` zinciri
`WriteProperty`	GUID ile hedeflenen özellik/property set	`member`, SPN, KeyCredentialLink vb.
`AllExtendedRights`	Nesneye uygulanabilen control-access rights	ForceChangePassword, replikasyon hakları vb.
`ADS_RIGHT_DS_SELF`	Validated write (`0x8`)	Self-Membership gibi doğrulanan yazımlar
`ForceChangePassword`	Control-access right	Mevcut parola olmadan reset
`AddMember`	`WriteProperty(member)`	İstenen hesabı gruba ekleme

AllExtendedRights, düz bir attribute olan msDS-KeyCredentialLink için otomatik olarak write hakkı sağlamaz.

1.9 Validated Write Nüansı

Validated write, normal WriteProperty işleminden farklıdır. AD, yazılan değere ek semantik kurallar uygular.

Bu konu açısından örnekler:

Validated write	Uygulandığı nesne	GUID
Self-Membership	Group	`bf9679c0-0de6-11d0-a285-00aa003049e2`
Validated-DNS-Host-Name	Computer	`72e39547-7b18-11d1-adef-00c04fd8d5cd`
Validated-SPN	Computer / uygun managed service account sınıfları	`f3a64788-5306-11d1-a9c5-0000f80367c1`

NOT:

bf967a7f-... Validated-SPN GUID’i değildir. Validated-SPN ve servicePrincipalName için ilgili GUID f3a64788-5306-11d1-a9c5-0000f80367c1 değeridir.

Validated-SPN yalnızca hedef bilgisayarın izin verilen DNS kimliğiyle uyumlu SPN değerlerine izin verir. Kullanıcı hesabına keyfî SPN ekleyerek hedefli Kerberoasting yapmak için normal property-write yolu gerekir.

1.10 Suistimal Zincirleri

1.10.1 ForceChangePassword

GUID: 00299570-246d-11d0-a768-00aa006e0529

Zincir:

ForceChangePassword
  → hedef parolasını mevcut parola olmadan sıfırla
  → hedef hesapla kimlik doğrula
  → hedefin yetkilerini kullan

Birincil audit olayı: 4724— An attempt was made to reset an account's password

4738, genel kullanıcı hesabı değişikliği bağlamı sağlayabilir ancak parola resetinin kanonik olayı değildir.

Not: Parola sıfırlama, daha önce verilmiş Kerberos biletlerini anında evrensel biçimde iptal etmez. Biletlerin kullanımı, geçerlilik süreleri ve ilgili Kerberos politikalarına bağlı olarak devam edebilir.

BloodHound: ForceChangePassword MITRE: T1098

1.10.2 AddMember ve AddSelf

Primitifler:

WriteProperty(member)
  → istenen hesabı gruba ekleme

ADS_RIGHT_DS_SELF
  → principal'ın kendisini gruba eklemesi

Not: Tier 0 gruplara üyelik doğrudan kritik etki yaratır. DNSAdmins, Backup Operators veya özel yönetim gruplarının etkisi ise ortam ve yapılandırmaya bağlıdır; bunların üyeliği her zaman otomatik Domain Admin anlamına gelmez

BloodHound: AddMember, AddSelf MITRE: T1098.007

1.10.3 WriteSPN ve Hedefli Kerberoasting

Zincir:

GenericAll / GenericWrite / WriteProperty(servicePrincipalName)
  → hedef kullanıcıya SPN ekleme
  → TGS isteme
  → offline parola tahmini/kırma

Not: Validated-SPN, bilgisayar nesnelerinde değer doğrulaması uyguladığı için keyfî kullanıcı SPN yazımıyla aynı primitive değildir.

SPN değişikliği için 5136 olayının üretilme şartları:

A. Audit Directory Service Changes açıksa,
B. ilgili kullanıcı/OU üzerinde uygun SACL varsa

BloodHound: WriteSPN MITRE: T1558.003

1.10.4 Shadow Credentials

Shadow Credentials, hedef kullanıcı veya bilgisayarın msDS-KeyCredentialLink özelliğine saldırgan kontrollü bir KeyCredential eklenmesidir.

Zincir:

Attribute write access
  → asimetrik anahtar üret
  → public key/KeyCredential hedef nesneye ekle
  → private key ile PKINIT
  → hedef hesap adına TGT

Ön koşullar

• Domain Functional Level: Windows Server 2016 veya üzeri
• En az bir uygun Windows Server 2016+ DC
• Kullanılan KDC’de PKINIT’i destekleyen güvenilir sertifika ve private key
• Hedef msDS-KeyCredentialLink niteliğine yazma hakkı
• LDAP ve Kerberos erişimi

Yazma hakkı şu yollardan gelebilir:

• GenericAll
• GenericWrite
• WriteProperty(msDS-KeyCredentialLink)
• WriteDACL → kendine attribute-write ACE
• Owner → WRITE_DAC → attribute-write ACE

Not: AllExtendedRights tek başına yeterli değildir.

PKINIT ile TGT alınması temel sonuçtur. Bazı KDC, hesap ve araç kombinasyonlarında U2U/Kerberos credential-retrieval zincirleriyle NT hash de elde edilebilir; bu sonuç her ortam için garanti değildir.

Kullanıcılar varsayılan olarak kendi msDS-KeyCredentialLink değerlerini yazamaz. Bilgisayar hesaplarının self-write davranışı ise ek doğrulama ve değer durumu kısıtlarına tabidir ve arbitrary write ile eşdeğer sayılmamalıdır.

BloodHound: AddKeyCredentialLink MITRE: T1098, T1556

1.10.5 Resource-Based Constrained Delegation

Bir bilgisayar nesnesinin msDS-AllowedToActOnBehalfOfOtherIdentity niteliğine yazabilen saldırgan, saldırgan kontrollü bir computer/service principal'ı hedef bilgisayar adına delegation yapabilecek şekilde tanımlayabilir.

Zincir:

AddAllowedToAct hakkı
  → saldırgan kontrollü principal'ı attribute'a ekle
  → S4U Kerberos zinciri
  → hedef host servislerine başka kullanıcı adına erişim

Ön koşul: Uygun SPN'e sahip saldırgan kontrollü bir principal ve Kerberos erişimi

BloodHound: AddAllowedToAct

Not: Bu teknik kalıcı olarak "hedef hostta local admin" vermekle eş anlamlı değildir; elde edilen etki, erişilebilen SPN/servis ve impersonate edilen kimliğin yetkilerine bağlıdır

1.10.6 WriteDACL

WriteDACL
  → saldırgan kontrollü principal için ACE ekle
  → GenericAll / WriteProperty / AddMember / Shadow Credentials / DCSync

Hedef	Olası sonuç
User	Parola sıfırlama veya Shadow Credentials
Group	Üyelik değiştirme
Computer	RBCD veya Shadow Credentials
Domain naming context	DCSync hakları
AdminSDHolder	Protected-account kalıcılığı
GPO/GPC	GPO delegasyonunu değiştirme

BloodHound: WriteDACL MITRE: Ortaya çıkan davranışa göre T1098, T1003.006, T1484.001

1.10.7 WriteOwner

Zincir:

WriteOwner
  → owner = saldırgan
  → örtük WRITE_DAC
  → DACL'a gerekli ACE
  → hedef nesne üzerinde kontrol

Bu zincir Koşullu olabilir çünkü:

•OWNER RIGHTS ACE’leri,
•BlockOwnerImplicitRights,
• Computer-derived object davranışı

BloodHound: WriteOwner

1.10.8 DCSync

Domain naming context üzerinde temel replikasyon hakları:

Hak	GUID
DS-Replication-Get-Changes	`1131f6aa-9c07-11d1-f79f-00c04fc2dcd2`
DS-Replication-Get-Changes-All	`1131f6ad-9c07-11d1-f79f-00c04fc2dcd2`
DS-Replication-Get-Changes-In-Filtered-Set	`89e95b76-444d-4c62-991a-0facbeda640c`

Not: İlk iki hak, secret domain data içeren tam DCSync için temel ikilidir. Filtered-set hakkı her DCSync için zorunlu değildir; RODC-filtered/confidential attribute senaryolarında önem kazanır

Zincir:

WriteDACL / GenericAll on domain NC
  → replication ACE'leri
  → MS-DRSR/DRSUAPI ile replication request
  → krbtgt ve domain hesap sırları

Not: DC'ye interaktif oturum veya LDAP, DCSync protokolünün zorunlu parçası değildir. Temel gereksinim RPC Endpoint Mapper/MS-DRSR erişimi ve gerekli replikasyon haklarıdır; kullanılan araçlar discovery için LDAP'tan da yararlanabilir.

MITRE: T1003.006

1.11 AdminSDHolder ve SDProp

Mekanizma:

AdminSDHolder (CN=AdminSDHolder,CN=System,DC=...), korunan hesap ve gruplar için security descriptor şablonudur.

SDProp, PDC Emulator üzerinde varsayılan olarak yaklaşık 60 dakikada bir çalışır ve korunan nesnelerin izinlerini AdminSDHolder ile hizalar.

Korumalı nesne örnekleri:

• Domain Admins
• Enterprise Admins
• Schema Admins
• Administrators
• Account Operators
• Backup Operators
• Server Operators
• Print Operators
• Sürüm/domain özelliklerine göre diğer korunan gruplar ve üyeleri

Liste eksiksiz sabit liste olarak görülmemeli Microsoft Appendix C esas alınmalıdır.

Suistimal:

AdminSDHolder DACL'ına saldırgan ACE
  → SDProp
  → ACE korunan nesnelere uygulanır
  → yalnızca hedef hesaptan silinen ACE yeniden gelebilir

Kök neden AdminSDHolder DACL’ıdır.

Manuel çalıştırma:

SDProp, gerekli yetkiye sahip bir principal tarafından rootDSE üzerinde RunProtectAdminGroupsTask = 1 işlemiyle manuel tetiklenebilir.

Admin Count:

`adminCount=1`, nesnenin halen korunan grupta olduğunu kanıtlamaz.

Nesne gruptan çıkarıldıktan sonra:

• adminCount
• inheritance-disabled durumu

otomatik olarak geri alınmayabilir.

Görünürlük:

4780, SDProp protected account ACL'ını AdminSDHolder ile yeniden hizalayıp gerçekten değiştirdiğinde üretilebilir. Bazı OS sürümlerinde güvenilir biçimde oluşmayabileceği için tek detection kaynağı olmamalıdır.

1.12 GPO ACL Suistimali

Bir GPO iki parçadan oluşur:

Parça	Konum	İçerik
GPC	Active Directory	Metadata, sürüm ve `gPCFileSysPath`
GPT	SYSVOL	`Registry.pol`, scriptler, scheduled-task ve policy dosyaları

Not: gPLink, GPO nesnesinde değil; site, domain veya OU nesnesinde bulunur.

Bu nedenle iki ayrı yetki yüzeyi vardır:

GPC/GPT üzerinde modify
  → mevcut GPO içeriğini değiştirme
  → AD ve SYSVOL izinlerine bağlı

OU/domain/site üzerinde gPLink write
  → GPO'yu hedef kapsama bağlama
  → ayrı bir haktır

Not: GPC üzerindeki yalnızca WriteProperty, SYSVOL'daki GPT dosyalarını otomatik olarak değiştirmenizi sağlamaz. Standart yönetim araçları çoğu zaman GPC/GPT izinlerini birlikte delege etse de iki katman ayrı denetlenmelidir..

MITRE: T1484.001

1.13 ACL Görünürlüğünü Zorlaştıran Teknikler

Teknik	Gerçek etki
Owner’ı saldırgan hesaba taşıma	Koşullara bağlı olarak DACL kontrolüne ilerleme
`READ_CONTROL` kısıtlama	ACL görünürlüğünü azaltabilir
`LIST_CHILDREN` / `LIST_OBJECT` kısıtlama	List Object Mode ve parent/child izinlerine bağlı olarak nesne görünürlüğünü azaltabilir
Meşru principal/grup adı kullanma	Analist ve allowlist yanıltma
AdminSDHolder	Silinen ACE’nin şablondan geri gelmesi

Owner’ın örtük READ_CONTROL hakkı ve ayrıcalıklı sahiplik alma yolları nedeniyle “Everyone Deny ile yöneticiler dahil kimse ACL’ı göremez” gibi mutlak ifadeler kullanılmamalıdır.

1.14 MITRE ATT&CK Eşlemesi

Davranış	MITRE
Parola veya account attribute manipülasyonu	T1098
Local/domain group üyeliği ekleme	T1098.007
Hedefli Kerberoasting	T1558.003
Shadow Credentials	T1098, T1556
DCSync	T1003.006
GPO modification/link manipulation	T1484.001
Elde edilen domain hesabını kullanma	T1078
Group/account discovery	T1069 / T1087, gerçekleştirilen keşfe göre

AD nesnesi DACL değişikliği için T1222 kullanılmamalıdır; T1222 dosya ve dizin izinleri bağlamındadır. ACL primitive’leri, ürettikleri nihai davranışa göre eşlenmelidir.

1.15 Güvenli Lab PoC

Ana lab amacı exploitation değil, ACL hakkının attack-path'e nasıl dönüştüğünü doğrulamaktır.

Lab düzeni:

 Lab OU
├── lab-attacker
├── lab-target
└── lab-delegated-group

1.15.1. ACL keşfi

Get-DomainObjectAcl -Identity "lab-target" -ResolveGUIDs |
    Select-Object IdentityReference,
                  ActiveDirectoryRights,
                  ObjectType,
                  IsInherited

1.15.2. Güvenli grup üyeliği doğrulaması

Önceden yalnızca disposable lab-delegated-group üzerinde verilen AddSelf/WriteMembers delegation'ı doğrulayın:

Add-ADGroupMember -Identity "lab-delegated-group" -Members "lab-attacker"
Get-ADGroupMember -Identity "lab-delegated-group"

1.15.3. Temizleme

Remove-ADGroupMember -Identity "lab-delegated-group" `
    -Members "lab-attacker" `
    -Confirm:$false

Lab ilkeleri:

• Domain Admins, AdminSDHolder veya domain root hedeflenmemeli.
• DCSync çalıştırılmamalı.
• Gerçek servis hesabının parolası sıfırlanmamalı.
• Meşru msDS-KeyCredentialLink değerleri silinmemeli.
• Her ACE ve attribute değişikliği için cleanup planı hazırlanmalı.
• SACL ve event üretimi aynı testte gözlemlenmeli.

Not: Shadow Credentials, AdminSDHolder ve DCSync gibi Tier 0 etkili teknikler kavramsal olarak açıklanmalı; operasyon komutları ayrı, kontrollü purple-team prosedüründe tutulmalıdır.

1.16 Bölüm 1 Sonuçları

AD ACL/ACE suistimali, meşru delegasyon mekanizmasının yanlış principal, hedef veya kapsamla kullanılmasından doğar. GenericAll, WriteDACL, WriteOwner, ForceChangePassword, WriteSPN, Shadow Credentials, RBCD ve replikasyon hakları farklı attack-path'lerle aynı sonuca ulaşabilir: ayrıcalık yükseltme, kalıcılık veya domain compromise.

Owner doğrudan GenericAll değildir; gücü WRITE_DAC üzerinden gelir. gPLink GPO'da değil hedef site/domain/OU üzerindedir. Shadow Credentials için attribute-write yanında PKINIT yapabilen KDC altyapısı gerekir. AdminSDHolder ise yalnızca hedef hesaptaki ACE temizlenerek ortadan kaldırılamayan şablon tabanlı bir kalıcılık yüzeyidir.

AD güvenliğinde asıl soru yalnızca “kim Domain Admin?” değildir; “kim, hangi nesne üzerinde, hangi ACE zinciriyle Domain Admin veya eşdeğer Tier 0 yetkisine dönüşebilir?” sorusudur.

Bölüm 2 / 3

Prevention & Hardening

Savunma teknolojileri, policy ve sertleştirme

Prevention & Hardening

2.1 Yönetici Özeti

Bölüm 1'in tezi: AD ACL suistimali bir CVE değil, meşru delegasyon hakkının yanlış principal / yanlış nesne / gereğinden geniş kapsam ile verilmesidir. Önlem de tek yamayla değil, birbirini tamamlayan katmanlarla sağlanır:

 ACL grafiğini çıkar
    → Tier 0 attack path'lerini bul
    → doğrudan kullanıcı yerine yönetilen gruba delege et
    → generic hakları object/attribute-specific'e daralt
    → owner + inheritance yüzeyini sertleştir
    → Shadow Credentials / RBCD / DCSync haklarını sınırla
    → AdminSDHolder + GPO baseline
    → SACL + change control ile görünürlüğü zorunlu kıl
    → BloodHound ile sürekli doğrula

Hardening/Sıkılaştırma "tehlikeli hakları kaldırmak" değildir. Hangi principal'ın hangi nesnede hangi hakkı neden taşıdığını bilmek ve bunun Tier 0'a attack path üretmediğini doğrulamaktır. Hiçbir kontrol diğerinin yerine geçmez: DCSync yüzeyini kapatmak Shadow Credentials'ı önlemez; tiering AdminSDHolder'ı korumaz.

2.2 Bu Kontrollerin Sınırı

Hardening şunları yapmaz:

• Önceden eklenmiş zararlı ACE'leri otomatik kaldırmaz
• Ele geçirilmiş meşru Tier 0 hesabını durdurmaz
• AD CS ESC, Entra RBAC, Kerberos ticket saldırılarını tek başına kapatmaz

Başlangıç olarak envanterinizi kontrol edin:

  DACL · Owner · Inheritance · GPO GPC/GPT 
  Attribute-specific rights ·  AdminSDHolder
  Control-access rights · Domain-root replikasyon hakları

2.3 Önceliklendirilmiş Kontrol Listesi

Öncelik	Kontrol	Amaç
P0	Tier 0 ACL attack-path envanteri	Mevcut domain-compromise yolları
P0	Domain-root replikasyon hakları denetimi	DCSync yüzeyi
P0	AdminSDHolder + privileged-group baseline	Kalıcı Tier 0 ACE
P0	GPO/GPT + gPLink denetimi	Policy tabanlı execution
P1	Generic hakları daraltma	GenericAll/WriteDACL/WriteOwner yüzeyi
P1	Shadow Credentials / RBCD attribute hakları	Passwordless takeover / delegation abuse
P1	Helpdesk reset + group-mgmt kapsamı	Account takeover
P1	Owner + inheritance hijyeni	Dolaylı DACL kontrolü
P1	Protected Users / authentication policy	Privileged credential etkisi
P1	Servis hesabı modernizasyonu (gMSA) + dMSA/BadSuccessor farkındalığı	Kerberoasting + yeni escalation
P2	SPN/service-account hijyeni	Targeted Kerberoasting
P2	SACL + change-control	Görünürlük
P2	Sürekli BloodHound/ACL graph doğrulaması	Yeni attack path

2.4 ACL Envanteri ve Attack-Path Baseline

Öncelikli nesneler:

 domain naming context · Domain Controllers OU · AdminSDHolder
 krbtgt · privileged groups/users · DC computer objects
 Entra Connect/identity-sync · PKI/AD CS
 Tier 0 GPO'ları · PAW/yönetim sunucuları

Aranacak haklar:

 GenericAll · GenericWrite · WriteDACL · WriteOwner
 AllExtendedRights · ForceChangePassword · AddMember/AddSelf
 WriteSPN · AddKeyCredentialLink · AddAllowedToAct
 DCSync (replikasyon) · GPO edit / gPLink write

Baseline alanları:

 Principal SID · Hedef DN · Access mask · Object Type GUID
 Inheritance kaynağı · Owner · iş gerekçesi
 sistem sahibi · değişiklik kaydı · son doğrulama

Not: Bir ACE'nin "meşru görünmesi" yetmez oluşturduğu tüm transitive BloodHound yolları da dikkate alınarak değerlendirilmelidir.

2.5 En Az Ayrıcalıklı Delegasyon

Kullanıcı yerine grup:

Yanlış:
user01 → GenericWrite → OU

Doğru:
Delegated-Helpdesk-Reset grubu
  → yalnız ilgili OU'da yalnız Reset Password
  → onaylı kullanıcılar gruba üye

Generic yerine object-specific (GUID bazlı)

Somut Karşılığı: Delegation of Control Wizard veya dsacls ile hak verirken ObjectType GUID belirt.

Kaçın	Tercih et
GenericAll	Yalnız gerekli extended right/attribute
GenericWrite	Belirli WriteProperty GUID'i
AllExtendedRights	Yalnız gerekli control-access GUID
OU'da geniş write	Belirli object class + inherited-object type
Kullanıcıya doğrudan ACE	Rol tabanlı delegasyon grubu

Uyarı: OU kökünde "Full Control" veya kapsamsız "Create/Delete All Child Objects"'ten kaçının bu, §2.11'deki dMSA/BadSuccessor kapısını da açar.

Not: Hangi object class'a, yalnız bu nesneye mi yoksa child'lara mı, Tier 0'a ulaşır mı, protected object'lerde nasıl davranır açıkça belirlenmeli.

2.6 Tier 0 İzolasyonu / Enterprise Access Model

Microsoft'un klasik Tier Modeli (T0: DC + domain nesnesi, T1: sunucular, T2: iş istasyonları) 2026'da Enterprise Access Model (EAM) ile beş düzleme genişletildi (Control, Management, Data/Workload, User Access, App Access).

Ancak EAM klasik tiering'in yerine geçmez, üzerine kurulur hibrit/on-prem AD'de Tier 0/1/2 segmentasyonunda hâlâ zorunludur.

ACL karşılığı:

• Bir T2 hesabı/grubu, hiçbir koşulda bir T0 nesnesi (DC, domain NC, AdminSDHolder, Tier 0 hesapları) üzerinde doğrudan/devralınan ACE taşımamalı.
• T1 yönetim grubu domain root veya DC OU'ya yazamamalı.
• T0 hesapları T1/T2 host'lara interaktif oturum açmamalı → PAW/jump host (aksi halde ACL değil, credential theft ile aynı sonuç).
• Tier 0 üyelikleri JIT/PAM ile sınırlandırılmalı.

2.7 Owner ve WriteOwner Sertleştirmesi

Bölüm 1: Owner örtük READ_CONTROL + WRITE_DAC alır. İki katman bunu koşullu yapar:

BlockOwnerImplicitRights

dSHeuristics'in 29. karakteri (KB5008383 / CVE-2021-42291). Enforcement (1) modunda, computer-derived nesnelerde ve owner Domain/Enterprise Admins üyesi değilse örtük owner hakları engellenir. "Owner olmak" artık otomatik WRITE_DAC değildir.

OWNER RIGHTS SID

S-1-3-4nesnenin DACL'ına açık ACE eklenerek owner'ın örtük hakkı nesne bazında sınırlanır.

nesnenin DACL'ına açık ACE eklenerek owner'ın örtük hakkı nesne bazında sınırlanır.

Not: Her iki mekanizma da mutlak değildir ve OS/senaryo bağımlıdır. Forest-wide değişiklik öncesi DC sürümleri + Microsoft güncel rehberi + compatibility testi doğrulanmalı; pilot ve recovery planı olmadan geniş ölçekte uygulanmamalı. WriteOwner ACE eklenmesi ayrıca izlenmeli (Bölüm 3).

Baseline'a alınacak owner'lar:

domain root · AdminSDHolder · privileged users/groups
DC computer objects · Tier 0 OU'ları · kritik GPO'lar
Entra Connect/PKI

2.8 ForceChangePassword Delegasyonu

Helpdesk reset hakkı:

• yalnız yönetilen kullanıcı OU'larında,
• dedicated gruba,
• privileged/service hesapları dışlanarak,
• inheritance kapsamı açık.

Kapsam dışı bırakılacaklar:

 Domain/Enterprise Admins · Tier 0 yöneticileri
 krbtgt · servis hesapları · Entra Connect
 break-glass · PKI yöneticileri

Ek kontroller:

 reset sonrası güçlü kimlik doğrulama
 talep doğrulama prosedürü
 ticket/approval
 Event 4724 merkezi izleme

Not: Protected Users, ForceChangePassword'u kaldırmaz. Bu kimlik doğrulama öncesi bir ACL işlemidir. ACL delegasyonu ayrıca düzeltilmeli.

2.9 Grup Üyeliği Delegasyonu

AddMember / AddSelf hakları Tier 0 gruplarda yalnız yetkili Tier 0 yönetim gruplarına ait olmalı.

• Member WriteProperty ACE'lerini + Self-Membership validated-write haklarını ayrı incele.
• Nested üyelikleri ve transitive yetkileri dahil et.
• Group Policy Creator Owners, DNSAdmins, Backup Operators'ı otomatik "düşük risk" sayma.
• Privileged üyeliği JIT/approval'a bağla.

Not: Deny ACE eklemek yerine gereksiz Allow ACE'yi kaldır. Deny ACE inheritance ve uygulama davranışını karmaşıklaştırır.

2.10 Shadow Credentials Sertleştirmesi (`msDS-KeyCredentialLink`)

Esas kontrol: attribute'a yazma yetkisini daraltmak.

Riskli yollar:

 GenericAll · GenericWrite
 WriteProperty(msDS-KeyCredentialLink)
 WriteDACL · WriteOwner/Owns

SpecterOps önleyici kontrolü: hedeflenmemiş hesaplar için (özellikle Tier 0) attribute'a Everyone: Deny ACE.

Sınır: WriteOwner/WriteDACL sahibi bu Deny'yi kaldırabilir → tek başına yetmez, SACL ile bu ACE'nin kaldırılması izlenmeli (Event 5136)

Bu attribute'a yazma normalde Key Admins / Enterprise Key Admins (WHfB key trust) gruplarındadır.

• WHfB kullanılıyorsa onaylı cihaz/hesapları belgele; kullanılmıyorsa Tier 0 hesaplarının sessizce anahtar biriktirmediğini doğrula.
• AdminSDHolder korumalı hesaplarda kontrollü WHfB kaydı isteniyorsa AdminSDHolder şablonuna dar kapsamlı hak eklenmeli (dsacls ... /G ...:RPWP;msDS-KeyCredentialLink) aksi halde SDProp her seferinde geri alır.
• Kullanıcılar varsayılan olarak kendi KeyCredentialLink'ini yazamaz; bilgisayar hesapları yalnız öznitelik boşsa yeni değer ekleyebilir (mevcutu değiştiremez). computer takeover otomatik sınırsız primitive vermez.
• Mevcut KeyCredential'ı körlemesine silme (WHfB/hybrid bozar).

Uyarı: PKINIT/DC sertifikalarını sırf bu riski azaltmak için kapatmak yanlış çözümdür asıl kök neden attribute-write yetkisidir.

2.11 Servis Hesabı Modernizasyonu: gMSA / dMSA + BadSuccessor

Statik parolalı servis hesaplarını gMSA'ya taşımak, otomatik dönen karmaşık parola nedeniyle Kerberoasting'i pratikte anlamsız kılar. Kullanılmayan SPN'ler kaldırılmalı.

Güncel kritik uyarı, BadSuccessor (CVE-2025-53779):
Windows Server 2025'teki dMSA'ya geçişte dikkat: bir OU üzerinde CreateChild / Create msDS-DelegatedManagedServiceAccount hakkına sahip düşük ayrıcalıklı hesap, msDS-ManagedAccountPrecededByLink yazarak sahte bir "migration" simüle edip KDC'yi dMSA'yı hedef hesabın (Domain Admin dahil) yerine geçmiş kabul etmeye ikna edebiliyordu.
Microsoft'un Ağustos 2025 yaması (kdcsvc.dll, karşılıklı/mutual link zorunluluğu) tek yönlü istismarı kapattı; ancak teknik, saldırgan hem dMSA'yı hem hedefi kontrol ettiğinde (ör. WriteDACL zinciri) yaşamaya devam ediyor (Akamai).

dMSA'ya geçiş yapan ortamlarda

• OU'larda Create msDS-DelegatedManagedServiceAccount / "Create All Child Objects" hakkını yalnız gerçekten gereken rollere daralt.
• BlockOwnerImplicitRights enforcement modunda tut (§2.7). Orijinal saldırı zincirin bir adımı oluşturan hesabın owner olupWRITE_DAC ile ilgili attribute'lara yazmasına dayanıyordu.
• Forest'ta KDS Root Key yoksa dMSA zaten oluşturulamaz (savunma katmanı).
• İzle: Event 4662 (attribute), 4741 (hesap oluşturma), 2946 (dMSA TGT).

2.12 RBCD Sertleştirmesi

Korunacak Attribute:

msDS-AllowedToActOnBehalfOfOtherIdentity

• AddAllowedToAct attack path'lerini çıkar; computer nesnelerinde GenericWrite/GenericAll/ilgili WriteProperty'yi daralt.
• DC ve Tier 0 computer object'lerinde bu attribute'a yazma yalnız Tier 0'da olmalı.
• Meşru RBCD değerlerini owner + gerekçeyle belgele; kullanılmayanı temizle.

MachineAccountQuota

Varsayılan ms-DS-MachineAccountQuota, standart kullanıcıların computer hesabı oluşturmasını kolaylaştırır.

Uygunsa:

ms-DS-MachineAccountQuota = 0

Domain join dedicated/denetlenen gruba verilmeli.
Not1: MAQ=0, RBCD'yi tamamen engellemez. Saldırgan mevcut bir computer/service principal'ı kontrol edebilir.

Delegasyondan korunacak insan hesapları:

 Protected Users
 "Account is sensitive and cannot be delegated"
 authentication policies/silos

2.13 SPN ve Service Account Hijyeni

• Gereksiz/duplicate SPN'leri temizle
• Kullanıcı tabanlı hesapları gMSA/dMSA'ya taşı (§2.11)
• Uzun/otomatik dönen parola
• AES zorunlu, RC4 bağımlılığını kaldır
• Service account'ları privileged gruplardan çıkar
• WriteSPN + Public Information property-set delegasyonlarını denetle

Not: Bilgisayarların meşru SPN yönetimi için Validated-SPN gerekli olabilir; bunu düz WriteProperty(servicePrincipalName) ile aynı riskte saymadan önce semantik farkı değerlendir

2.14 DCSync Yüzeyini Daraltma

Domain root üzerinde şunları taşıyan principal'lar envanterlenmeli:

 DS-Replication-Get-Changes
 DS-Replication-Get-Changes-All
 DS-Replication-Get-Changes-In-Filtered-Set
 GenericAll · WriteDACL · AllExtendedRights

Varsayılan meşru principal'lar:

 DC makine hesapları · Domain/Enterprise Admins
 BUILTIN · (PHS kullanılıyorsa) Entra Connect AD DS Connector hesabı
 belgelenmiş backup/sync araçları

Operasyonel tuzak
Bazı ortamlarda adprep /domainprep, Enterprise Key Admins grubuna sessizce replikasyon ACE ekledi — haklar yalnız kötü niyetle değil, rutin şema/domain hazırlığıyla da genişleyebilir. Şema güncellemesi sonrası yeniden denetim şart.
Her non-DC principal için sorulacaklar:

 İş gerekçesi?
 Hangi özellik için?
 Connector host Tier 0 korunuyor mu?
 İnteraktif oturum kapalı mı?
 Credential nasıl saklanıyor?

Entra Connect PHS kullanmıyorsa connector'a replikasyon-secret haklarının gerekli olduğu varsayılmamalı.

Not: DCSync gerçekleştiği doğrulanmışsa krbtgt parolası iki kez sıfırlanmalıdir. History=2 olduğu için tek rotasyon yetersiz. Aralarda replikasyon + max ticket lifetime kadar (varsayılan ≥10 saat) beklenmelidir. Art arda hızlı çift sıfırlama yalnız acil breach recovery içindir ve risklidir

2.15 AdminSDHolder Sertleştirmesi

• Yazma erişimini daralt: CN=AdminSDHolder,CN=System,... üzerinde WriteDACL/WriteOwner/FullControl yalnız Domain/Enterprise Admins'te olmalı; hiçbir servis hesabında olmamalı.
• Baseline karşılaştırması: SDDL/ACE bilinen-iyi referansı sakla, aylık karşılaştır; owner + inheritance bayraklarını doğrula.
• adminCount=1 temizliği: korumalı grupta olmayan "yetim" hesapları tara; tespitte adminCount temizle + inheritance yeniden etkinleştir (Bölüm 1: otomatik geri alınmaz).
• Change control: her değişiklik Tier 0 sürecine tabi.
• SDProp aralığı: varsayılan ~60 dk yeterli; değiştirme (AdminSDProtectFrequency) önerilmez.
• RunProtectAdminGroupsTask yalnız kontrollü test/remediation'da, PDC Emulator'da, yetkili change ile.

Not: adminCount=1'i körlemesine sıfırlamak veya inheritance'ı toplu açmak aktif protected hesapları bozabilir. öncelikle gerçek üyelik çözülmeli

2.16 GPO, SYSVOL ve gPLink Sertleştirmesi

Üç ayrı yüzey ayrı ayrı denetlenmeli:

Yüzey	Korunacak
GPC	AD groupPolicyContainer ACL
GPT	SYSVOL {GUID} klasörü NTFS ACL
Scope	OU/domain/site üzerindeki gPLink + gPOptions

• GPO delegasyonu GPMC'den rol bazlı; kritik GPO'lara yalnız Tier 0 yazabilmeli.
• GPC ve GPT izinleri tutarlı olmalı; SYSVOL klasörlerinde beklenmeyen write olmamalı.
• gPLink yazma hakkı, GPO içeriği düzenleme hakkından bağımsızdır ayrı listelenmeli.
• Default Domain Policy / Default Domain Controllers Policy değişiklikleri sıkı change-control'a; kritik GPO yedekleri tutulmalı; referans verilen external script/share yolları da korunmalı.
• Group Policy Creator Owners üyeliği dar tutulmalı.

2.17 Protected Users ve Authentication Policy

Protected Users üyeliği (privileged insan hesapları için):

• NTLM/Digest/CredSSP engeller
• Kerberos'ta DES/RC4 devre dışı (yalnız AES)
• constrained/unconstrained delegasyona izin vermez
• TGT ömrünü sabit 240 dk'ya (yenilemesiz) indirir
• cached credential/offline logon yok

Not: Bu korumalar yapılandırılamaz; tek çıkış gruptan çıkmak.

Ön koşullar/sınırlar:

• Tam koruma (DC tarafı dahil) için DFL ≥ 2012 R2, host'lar ≥ Windows 8.1/2012 R2; aksi halde yalnız kısmi (istemci tarafı) koruma.
• Servis/bilgisayar hesapları eklenmemeli (credential zaten host'ta; ek koruma yok, auth hataları oluşur).
• ForceChangePassword'u önlemez (bu auth öncesi ACL işlemi); DACL/attribute write'ı, Shadow Credentials ACE'sini temizlemez.
• Legacy uygulama/oturum akışlarını bozabilir → AES, NTLM bağımlılığı, delegasyon ihtiyacı, legacy istemci, break-glass doğrulanmalı.

Servis hesapları için:

 gMSA/dMSA
 "Account is sensitive and cannot be delegated"
 authentication policy silo

2.18 SACL ve Denetim Ön Koşulları

Prevention odaklı olsa da hardening'in doğrulanması için audit zemini gerekir.

Öncelikli SACL kapsamı:

 domain root · AdminSDHolder · privileged users/groups
 DC computer objects · Tier 0 OU'ları · kritik GPC
 msDS-KeyCredentialLink
 msDS-AllowedToActOnBehalfOfOtherIdentity
 servicePrincipalName · nTSecurityDescriptor
 gPLink/gPOptions
 msDS-ManagedAccountPrecededByLink (BadSuccessor)

Audit policy:

 Directory Service Changes
 Directory Service Access
 User Account Management
 Security Group Management

Not: "Audit policy açık" tek başına yetmez; 4662/5136 için ilgili nesne/attribute üzerinde uygun SACL da gerekir. Detay Bölüm 3.

2.19 Change Control ve ACL Governance

Her ACL değişikliğinde zorunlu alanlar:

 Hedef DN · Principal SID · Hak/GUID · Inheritance
 Owner · iş gerekçesi · süre (kalıcı/geçici)
 onaylayan (asset/Tier owner) · rollback
 attack-path sonucu (Tier 0 yolu oluşturuyor mu?)

Not: Acil değişiklikler ilk kontrol noktasında bağımsız doğrulanmalı.

2.20 Sürekli BloodHound / ACL Graph Doğrulaması

BloodHound bir pentest aracı değil, delegasyon değişikliklerinin güvenlik etkisini ölçen denetim aracıdır.

Öncelikli sorgular:

 Shortest Paths to Tier 0
 DCSync principals
 non-Tier-0 → Tier 0 kontrol
 WriteDACL/WriteOwner paths
 AddKeyCredentialLink
 AddAllowedToAct
 GPO control
 foreign/orphaned SID ACE

Çalıştırma tetikleyicileri — takvim değil, değişim:

 delegasyon değişikliği
 yeni yönetim ürünü
 birleşme/migrasyon
 privileged group değişimi
 collector/schema güncellemesi
 şema güncellemesi/adprep sonrası (§2.14)
 periyodik risk denetimi (30–90 gün)

Not: Yalnız "Shortest Path to Domain Admins" yetmez; PKI, identity-sync, virtualization ve backup Tier 0-eşdeğeri yolları da modellenmeli.

2.21 Güvenli Remediation

ACE kaldırmadan önce:

 security descriptor'ın tam yedeği
 owner/DACL/inheritance/GUID kapsamı kaydı
 ACE'yi hangi uygulamanın kullandığı
 ortaya çıkan BloodHound yollarının karşılaştırması
 pilot OU testi
 rollback hazırlığı

Kaçın:

 tüm Deny ACE'leri silmek
 tüm GenericWrite'ı körlemesine kaldırmak
 adminCount=1'i toplu sıfırlamak
 tüm KeyCredential'ı temizlemek
 SYSVOL ACL'ını AD ACL'ına bakarak varsaymak
 owner'ları kör toplu değiştirmek

ACE Kaldırıldıktan sonra:

 grafiği yeniden topla
 attack path'in kapandığını doğrula
 uygulama/auth regresyonlarını kontrol et

2.22 Hardening Etkinlik Matrisi

Kontrol	Önlediği zincir	Etki
Generic → object-specific daraltma	Genel ACL takeover	Çok yüksek
Tier 0 izolasyonu	Alt katmandan compromise	Çok yüksek
DCSync hak temizliği	Credential replication	Çok yüksek
AdminSDHolder baseline	Protected-account kalıcılığı	Çok yüksek
GPC/GPT/gPLink sertleştirme	GPO tabanlı execution	Çok yüksek
BloodHound graph validation	Yeni attack-path keşfi	Çok yüksek
msDS-KeyCredentialLink hijyeni	Shadow Credentials	Yüksek
RBCD/MAQ + dMSA daraltma	Delegation abuse / BadSuccessor	Yüksek
Owner/WriteOwner hijyeni	Dolaylı DACL kontrolü	Yüksek
Helpdesk reset kapsamı	ForceChangePassword	Yüksek
gMSA + SPN hijyeni	Targeted Kerberoasting	Orta/Yüksek
Protected Users	Credential theft/delegation	Orta
SACL/audit	Önleme değil, doğrulama	Görünürlük

2.23 En Sık Hardening Hataları

Hata	Sonuç
Yalnız grup üyeliklerini denetlemek	ACL attack path'leri kalır
GenericAll→GenericWrite ile yetinmek	Kritik attribute-write yolları sürer
AllExtendedRights'ı attribute write sanmak	Yanlış risk değerlendirmesi
Deny ACE ile örtmek	Inheritance/operasyon karmaşası
Yalnız Domain Admins'e bakmak	Eşdeğer Tier 0 yolları kaçar
DCSync hesabını "sync" diye düşük riskli saymak	Domain credential compromise
KeyCredential'ı kör silmek	WHfB/hybrid bozulur
MAQ=0 ile RBCD bitti sanmak	Mevcut principal'larla abuse sürer
Yalnız GPC ACL denetlemek	GPT/gPLink yüzeyi kalır
AdminSDHolder yerine yalnız hesabı temizlemek	ACE geri gelir
adminCount=1'i toplu düzeltmek	Aktif protected hesaplar bozulur
SACL olmadan 5136 beklemek	Detection körlüğü
gMSA/dMSA'ya uyarısız geçmek	BadSuccessor escalation yüzeyi

2.24 Uygulama Sırası

1. Domain-root, AdminSDHolder, Tier 0, GPO ACL baseline
2. DCSync taşıyan tüm non-DC principal'ları doğrula (+ adprep sonrası kontrol)
3. Tier 0'a giden BloodHound path'lerini önceliklendir
4. Generic/inherited hakları object-specific'e daralt
5. Shadow Credentials + RBCD attribute-write yollarını temizle
6. Helpdesk reset + group-mgmt kapsamını daralt
7. Owner/WriteOwner + orphaned SID temizliği
8. GPC/GPT/gPLink'i birlikte düzelt
9. AdminSDHolder baseline + stale adminCount süreci
10. gMSA geçişi + (dMSA ise) BadSuccessor kontrolleri
11. Protected Users/authentication policy pilotu
12. SACL/change-control + sürekli graph doğrulaması

2.25 Kapsamadığı Alanlar

AD CS ESC1–ESC16
Entra ID RBAC/Graph
Golden/Silver Ticket
Pass-the-Ticket
NTLM relay
AD DB/DC OS exploitleri
ele geçirilmiş meşru Tier 0 hesabının meşru işlemleri

Ayrı savunma katmanları gerekir.

2.26 Bölüm 2 Sonuçları

AD ACL hardening, tehlikeli hakları kaldırmak değil; meşru delegasyonu rol + nesne + attribute GUID + inheritance kapsamı + iş gerekçesi ile sınırlamaktır. Her Bölüm 1 zincirinin bir önleme katmanı var, ama hiçbiri tek başına yeterli değil:

 Tier 0 izolasyonu
  + object-specific delegation
  + DCSync/AdminSDHolder/GPO baseline
  + Shadow Credentials & RBCD ACL hijyeni
  + dMSA/BadSuccessor farkındalığı
  + owner/inheritance kontrolü (BlockOwnerImplicitRights)
  + Protected Users (yalnız doğru hesap sınıfı)
  + SACL + change control
  + sürekli BloodHound doğrulaması

Kaynaklar

Enterprise Access Model
Protected Users
Appendix C — Protected Accounts/AdminSDHolder
krbtgt reset — Forest Recovery
SpecterOps — Shadow Credentials
SpecterOps — Understanding & Mitigating BadSuccessor
Akamai — BadSuccessor (dMSA); patch analizi (CVE-2025-53779)
Tenable — BadSuccessor FAQ
Semperis — DCSync rights
adsecurity.org — AdminSDHolder/SDProp

Bölüm 3 / 3

Detection

Davranış, loglama ve detection kuralları

Bölüm 3: Detection, Threat Hunting & DFIR

Seri: AD ACL/ACE Suistimali (3/3) · Önceki: Bölüm 1 — Mimari & Suistimal Zincirleri · Bölüm 2 — Prevention & Hardening

3.1 Yönetici Özeti

AD ACL suistimalinin tespiti tek bir Event ID'ye indirgenemez. ACL/ACE suistimi meşru bir mekanizmanın kötüye kullanımıdır; bu yüzden görünürlük varsayılan olarak yoktur. AD, DACL/Owner/attribute değişikliklerini normal LDAP loglama seviyesinde tutmaz bunları görmek için değişiklik olmadan önce SACL + audit policy kurmuş olmanız gerekir.

Temel detection zinciri:

SACL + Advanced Audit Policy
  → 5136 (attribute/ACL değişimi) · 4662 (hakkın kullanımı) · hesap-yönetimi olayları
  → SID / GUID / DN / Logon ID zenginleştirmesi
  → bilinen-iyi ACL/owner/SDDL baseline karşılaştırması
  → Kerberos / grup üyeliği / ağ telemetrisi korelasyonu
  → attack-path (BloodHound) etkisi
  → önceliklendirilmiş alarm

İki çekirdek tez:

• Detection proaktif bir tasarım kararıdır. SACL'siz domainde saldırgan GenericAll/WriteDACL/AddKeyCredentialLink ekler ve hiçbir olay üretilmez. "Olay yok" ≠ "saldırı yok"; = "izlemediniz"
• "Event oluşmadı" işlemin gerçekleşmediğini kanıtlamaz. Yanlış SACL, eksik audit policy, log rollover, forwarding gecikmesi veya izlenmeyen DC'de yapılan değişiklik boşluk yaratır. Bu yüzden SACL yoksa bile DFIR için replikasyon metadata (§3.16) bir geri-dönüş katmanıdır.

Güvenilir bir alarm şunu söyleyebilmelidir: "Şu SID, şu kaynak host'tan, şu DC üzerinden, şu nesnenin şu hakkını değiştirdi; bu değişiklik şu principal'a şu yetkiyi verdi ve Tier 0'a şu yeni attack-path'i açtı."

3.2 Kapsam

Audit/SACL ön koşulları, event ID referans haritası, 5136/4662 anatomisi, enrichment, her Bölüm 1 zinciri için tespit mantığı (ForceChangePassword, grup üyeliği, WriteSPN, Shadow Credentials, RBCD, WriteDACL/WriteOwner, DCSync, AdminSDHolder/SDProp, GPO/gPLink, BadSuccessor/dMSA), önceliklendirme, generic + Sigma kural taslakları, audit-tampering, BloodHound sürekli hunting, honeytoken/canary, DFIR (SACL yokken retrospektif, timeline, scoping, containment), triage, güvenli test.

Kapsam dışı

Prevention (Bölüm 2), AD CS ESC* tespiti, Entra ID/Graph audit, NTLM relay, Golden/Silver Ticket forensics, endpoint/EDR (Sysmon/ETW ayrı katman), NTDS.dit offline forensics, SIEM ürününe özel dashboard/lisans.

3.3 Detection Veri Kaynakları

Windows Security Log (DC)

• 5136 · 5137 · 5139 · 5141 (dizin değişimi/oluşturma/taşıma/silme)
• 4662 · 4670 (nesne işlemi / izin değişimi)
• 4724 · 4738 (parola reset / hesap değişimi)
• 4728/4729 · 4732/4733 · 4756/4757 (grup üyeliği)
• 4741 · 4742 (computer hesabı)
• 4768 · 4769 · 4771 (Kerberos)
• 4624 · 4625 · 4648 (logon / kaynak host)
• 4719 · 4907 · 1102 (audit tampering)

Directory Service Log

SDProp/dizin olayları · 2946 (dMSA TGT)

SYSVOL / dosya erişimi

4663 · 5145 · dosya bütünlük (hash) · GPC/GPT sürüm karşılaştırma

Ağ telemetrisi

LDAP/LDAPS · Kerberos · RPC EPM (TCP 135) · MS-DRSR/DRSUAPI (DRSUAPI arayüz UUID: e3514235-4b06-11d1-ab04-00c04fc2dcd2)

Durum / graph

  periyodik nTSecurityDescriptor (SDDL) snapshot · owner/inheritance baseline
  BloodHound differential collection · onaylı delegasyon envanteri
  AD replikasyon metadata (repadmin /showobjmeta), SACL yoksa DFIR için

Hiçbir kaynak tek başına yeterli değildir: 5136 RBCD attribute değişimini gösterir; kullanıldığını kanıtlamak için Kerberos + hedef host telemetrisi gerekir.

3.4 Audit Policy Ön Koşulları

DC'lerde en az (GPO ile, tüm DC'lere):

Kategori	Alt kategori	Ayar
DS Access	Directory Service Changes	Success
DS Access	Directory Service Access	Success
Account Management	User Account Management	Success/Failure
Account Management	Computer Account Management	Success/Failure
Account Management	Security Group Management	Success/Failure
Account Logon	Kerberos Authentication Service	Success/Failure
Account Logon	Kerberos Service Ticket Operations	Success/Failure
Logon/Logoff	Logon	Success/Failure
Object Access	File System / Detailed File Share	Kritik SYSVOL yolları
Policy Change	Audit Policy Change	Success

Doğrulama: auditpol /get /category:* ile etkin sonuç kontrol edilmeli (yalnız GPO'da tanımlı olması yetmez); Legacy ↔ Advanced Audit Policy çakışması aranmalı.

3.5 SACL Tasarımı

İki bağımsız katman aynı anda gerekir; biri olmadan diğeri sıfır olay üretir:

1. Audit policy (Directory Service Changes = Success) tüm DC'lere.
2. Object-level SACL hedef nesnede/OU'da (inherited) Everyone: Success + ilgili haklar (ör. "Write all properties").

Microsoft'un ifadesiyle: SACL'da uygun Write ACE yoksa subcategory açık olsa bile 5136 üretilmez.

Öncelikli SACL hedefleri:

domain NC root · AdminSDHolder · privileged users/groups · 
Domain Controllers OU · DC computer objects · Tier 0 OU'ları · 
kritik GPC · OU/domain/site (gPLink) · 
Entra Connect/identity-sync · PKI/backup/virtualization yönetim hesapları.

Öncelikli işlemler:

WriteDACL 
WriteOwner 
WriteProperty  
Control Access  
CreateChild/DeleteChild

Öncelikli attribute'lar:

nTSecurityDescriptor · member · servicePrincipalName
msDS-KeyCredentialLink · msDS-AllowedToActOnBehalfOfOtherIdentity
gPLink · gPOptions · msDS-ManagedAccountPrecededByLink · msDS-DelegatedMSAState

Domain root'ta izlenecek control-access GUID'leri: 1131f6aa-… (Get-Changes), 1131f6ad-… (Get-Changes-All), 89e95b76-… (Get-Changes-In-Filtered-Set).

Özel durum (çoğu ortamda kaçırılır): msDS-KeyCredentialLink varsayılan domain SACL'ında güvenilir kapsanmaz. Genel "Write all properties" SACL'ı bunu otomatik kapsamayabilir;
özniteliğin schemaIDGUID = 5b47d60f-6090-40b2-9f37-2a4de88f3063 değeriyle özel bir audit rule (ör. Set-AuditRule) eklenmelidir. Bu yapılmazsa Shadow Credentials sessizce geçer
Not: Domain geneli tüm attribute + tüm başarısız erişim için geniş SACL ciddi event hacmi ve DC yükü yaratır. Tier 0 + kritik attribute ile başlayan hedefli SACL tercih edilmeli

3.6 Event 5136 Anatomisi

Kritik alanlar: SubjectUserSid/Name, SubjectLogonId, ObjectDN, ObjectClass, AttributeLDAPDisplayName, AttributeValue, OperationType, CorrelationID.

• OperationType: %%14674 = Value Added (yeni değer), %%14675 = Value Deleted (eski değer). Tek bir değişiklik genelde iki 5136 üretir (önce Delete, sonra Add).
• CorrelationID: Aynı LDAP işlemindeki tüm 5136/5137/5139 olaylar aynı Correlation ID ile birleştirilip tam işlem yeniden kurulmalı.
• Pratik: Genelde "Value Added" yeni değeri verir; eski değeri görmek için aynı Correlation ID'li "Value Deleted" aranır.

Güçlü olduğu alanlar: hangi attribute, kim, hangi DN, yeni/kaldırılan değer. Sınırları: SACL yoksa üretilmez · yalnız değişikliği kabul eden DC'de görülür · büyük/binary değer SIEM'de kesilebilir · nTSecurityDescriptor için SDDL parse gerekir · tek başına "kullanıldı" demez.

3.7 Event 4662 Anatomisi

Kritik alanlar: SubjectUserSid/Name, SubjectLogonId, ObjectType, ObjectName, OperationType, AccessMask, Properties.

Kritik access-mask değerleri:

• 0x100 Control Access (extended right; replikasyon = DCSync)
• 0x20 Write Property
• 0x40000 WRITE_DAC (WriteDACL)
• 0x80000 WRITE_OWNER (WriteOwner)

ObjectType/Properties collector'a göre GUID veya çözülmüş ad içerebilir; kural her iki gösterimi de desteklemeli. 4662 yüksek hacimlidir → nesne/GUID/access-mask/principal filtresi olmadan açılmamalı.

3.8 Enrichment (SID / GUID / DN / Logon ID)

SID   
 • güncel ad 
 • hesap türü 
 • Tier 
 • privileged-group üyeliği 
 • orphaned mı?

Object GUID 
 • schema attribute / property set / validated write / extended right
 
Object DN  
 • sınıf 
 • OU 
 • Tier/asset owner 
 • AdminSDHolder korumalı mı? 
 • domain root/kritik GPO mu?

SubjectLogonId 
 • aynı DC'de 4624 
 • source IP 
 • workstation 
 • logon type 
 • auth package

5136/4662 çoğu zaman istemci IP'sini doğrudan vermez. aynı DC + SubjectLogonId üzerinden 4624 korelasyonu, değişikliğin geldiği yönetim host'unu belirlemek için kritiktir. Ada değil SID'e güvenin (rename riski)

3.9 Event ID Referans Haritası

Olay	Anlam	SACL'a bağlı?	Bölüm 1 zinciri
5136	Nesne değiştirildi	Evet (bazı attr. için özel SACL)	WriteDACL/WriteOwner, WriteSPN, Shadow Creds, RBCD, AdminSDHolder, GPO
5137/5139/5141	Oluşturuldu/taşındı/silindi	Evet	dMSA/computer oluşturma, inheritance manip., iz kapatma
4662	Nesne üzerinde işlem	Evet	DCSync, WRITE_DAC/WRITE_OWNER, Shadow Creds fallback
4724	Parola reset	Hayır	ForceChangePassword
4738	Hesap değişti	Hayır	Genel bağlam; nTSD değişince de tetiklenebilir (attr. detayı yok)
4728/4732/4756	Gruba üye eklendi	Hayır	AddMember/AddSelf
4729/4733/4757	Gruptan çıkarıldı	Hayır	"ekle-kullan-sil" korelasyonu
4741/4742	Computer oluşturuldu/değişti	Hayır	RBCD (MAQ), BadSuccessor
4768	TGT istendi	Hayır	Shadow Creds → PKINIT
4769	TGS istendi	Hayır	Targeted Kerberoasting, RBCD S4U
4780	Admin ACL uygulandı (SDProp)	Hayır	AdminSDHolder — ikincil, güvenilmez
2946	dMSA TGT	—	BadSuccessor/dMSA
4719/4907/1102	Audit değişti/temizlendi	Hayır	Audit tampering

3.10 Teknik Bazlı Tespit

ForceChangePassword

Birincil sinyal: 4724 (Subject ≠ Target ve Subject helpdesk allowlist dışında). Hedef Tier 0/servis/krbtgt ise kritik.

Korelasyon: 4724 → hedef için 4768/4624 → yeni source IP.

Not: 4738 kanonik değildir; 4724 nesne SACL'ı değil, User Account Management audit'inden gelir.

BloodHound	MITRE
`ForceChangePassword`	`T1098`

AddMember / AddSelf

Birincil sinyal: 4728/4732/4756 (+ 5136 member ile LDAP doğrulama; AddSelf'te Subject=Target).

Korelasyon: Tier 0 gruplara ekleme her zaman incelenir; nested/transitive üyelik event-log ile görünmez → §3.11 BloodHound diff ile tamamlanır.

Yüksek sinyal: Kısa süreli "ekle→kullan→çıkar" (4756 ardından 4757).

BloodHound	MITRE
`AddMember`, `AddSelf`	`T1098.007`

WriteSPN → Targeted Kerberoasting

Birincil sinyal: SPN yazımı 5136 servicePrincipalName (kullanıcı hesabına; Validated-SPN bilgisayara özgüdür).

Korelasyon 4769 ile:

TicketEncryptionType = 0x17 (RC4; AES-only ortamda anomali, 0x11/0x12 beklenir)
ServiceName $/krbtgt değil
FailureCode = 0x0
Kısa sürede çok sayıda benzersiz SPN (Rubeus/Invoke-Kerberoast imzası)

Not: Tek RC4 4769 kanıt değildir; 5136 SPN-write + ardından anomalik 4769 zinciri esastır. Kör nokta: SACL yoksa 5136 SPN-write üretmez — en yaygın gözden kaçan durum.

BloodHound	MITRE
`WriteSPN`	`T1558.003`

Shadow Credentials

Birincil sinyal: 5136 msDS-KeyCredentialLink (Value Added) — §3.5'teki özel SACL (schemaIDGUID) şart.

Fallback: 5136 yoksa 4662 ile aynı GUID'e erişim.

Kullanım korelasyonu: ekleme → hedef için 4768 (PKINIT; pre-auth type 16 / PA-PK-AS-REQ; sertifika alanları dolu).

Not: WHfB/smart-card aynı mekanizmayı kullanır → Azure AD Connect / ADFS servis hesaplarını bilinen istisna listesine al (filtreleme değil, allowlist). Beklenmeyen KeyCredential → dakikalar içinde ilk kez PKINIT + kayıtsız cihaz + Tier 0 hedef.

BloodHound	MITRE
`AddKeyCredentialLink`	`T1098`, `T1556`

RBCD

Birincil sinyal: 5136 msDS-AllowedToActOnBehalfOfOtherIdentity (binary SD → parse et: eklenen/silinen SID, access mask, hedef computer).

Üç olaylık zincir:

1.5136 — attribute değişimi
2.4769 — S4U2Self
3.4769 — S4U2Proxy (Transited Services alanı dolu — RBCD imzası)

Ek sinyal: Varsa başa 4741 (MAQ ile yeni computer) eklenir; oluşturan = değiştiren genelde aynı SID (erken tespit fırsatı).
Baseline: Bu attribute normalde çok nadir değişir → her yazım incelenmeli. DC/Tier 0 computer'da yalnız Tier 0 meşru.

BloodHound	MITRE
`AddAllowedToAct`	`T1098`

WriteDACL

Birincil sinyal: 5136 nTSecurityDescriptor (SDDL "Value Added"). İkincil: 4662 0x40000.

SDDL diff zorunlu: eklenen/silinen ACE, trustee SID, Allow/Deny, access mask, Object/Inherited Object Type GUID, inheritance flag, owner, DACL protection.

Not: Domain root DACL'ına replikasyon GUID'i eklenmesi = gerçek DCSync görülmese bile kritik. Baseline SDDL ile karşılaştır (özellikle Tier 0).

BloodHound	MITRE
`WriteDACL`	Davranışa göre `T1098` / `T1003.006` / `T1484.001`

WriteOwner

Birincil sinyal: 5136 nTSecurityDescriptor içinde Owner (O:) değişimi.

İkincil: 4662 0x80000.

Korelasyon: owner değişimi → kısa süre içinde nTSD (D:) ACE ekleme.

Not: BlockOwnerImplicitRights/OWNER RIGHTS nedeniyle owner→DACL takeover her zaman başarılı olmaz; yine de Tier 0'da yetkisiz owner değişimi kritiktir.

BloodHound	MITRE
`WriteOwner`	`T1098`

DCSync

İki aşama ayrı izlenir:

1. Hakkın verilmesi: 5136 domain NC'de nTSD'ye replikasyon GUID'li yeni ACE (özellikle non-DC principal'a).

2. Kullanımı: 4662 AccessMask=0x100 + Properties replikasyon GUID'i.

• Filtre: SubjectUserName $ ile bitiyor (DC) veya MSOL_ (Entra Connect) → hariç.
• Ağ: non-DC kaynak → TCP 135/RPC EPM → dinamik port → DRSUAPI UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2.

Not: Statik $/MSOL_ filtresi güvenlik sınırı değildir (saldırgan computer/DC hesabı kullanabilir) → 30 günlük gözlemle "bilinen meşru kaynak" baseline'ı kurup sapmayı alarma çevir.

Containment: Doğrulanırsa domain compromise kabul edilir; krbtgt çift reset (Bölüm 2.14) containment'ın parçasıdır, sonraya bırakılmaz.

BloodHound	MITRE
`GetChanges`/`GetChangesAll`	`T1003.006`

AdminSDHolder/SDProp

Birincil sinyal (kök-neden): 5136 — ObjectDN = CN=AdminSDHolder,CN=System,… (bu nesne nadiren meşru değişir; her değişim Tier 0). Correlation ID ile birleştirip eklenen ACE'nin tam SDDL'i çıkarılır.

İkincil: 4780 güvenilmez (bazı OS'te üretilmez; normal SDProp'ta da görülür) → tek kaynak olmaz.

Not: "20 hesap değişti" değil, "AdminSDHolder'a eklenen ACE SDProp ile 20 hesaba yayıldı" şeklinde alarm kök nesneyi göstermeli.

Doğrulama: Containment sonrası ~60 dk içinde temizliğin protected hesaplara yayıldığı 5136/4780 ile doğrulanır

BloodHound	MITRE
`WriteDACL`/`GenericAll`	`T1098`

GPO / SYSVOL / gPLink

Üç ayrı yüzey:

GPC (AD): 5136 ObjectClass=groupPolicyContainer (nTSD, versionNumber, gPCFileSysPath, displayName); 5137 (oluşturma); 5141 (silme).

GPT (SYSVOL): AD log'u SYSVOL içeriğini görmez → 4663 (dosya erişimi, File System SACL şart), 4670, 5145 + dosya bütünlük (GPT.ini, Registry.pol, Scripts, ScheduledTasks.xml, Services.xml, Groups.xml).

Scope: 5136 gPLink/gPOptions (OU/domain/site) GPO içerik değişiminden bağımsız, ayrı kural.

Not: GPC sürümü ≠ GPT.ini sürümü, operasyonel hata veya manipülasyon göstergesi (tek başına kötü niyet kanıtı değil).

BloodHound	MITRE
`WriteGPLink` / GPO edit edge'leri	`T1484.001`

BadSuccessor / dMSA

Birincil sinyal:

· 5137 msDS-DelegatedManagedServiceAccount oluşumu

· 5136 msDS-ManagedAccountPrecededByLink / msDS-DelegatedMSAState

· 4741 (Tier 0 dışı hesabın OU'da oluşturması) · 2946 dMSA TGT (KERB-DMSA-KEY-PACKAGE bağlamı) → hedef ayrıcalıklarıyla işlem.

Not: Ağustos 2025 yaması tek yönlü istismarı kapattı ama saldırgan hem dMSA hem hedefi kontrol ettiğinde (WriteDACL zinciri) sürer → detection kaldırılmaz. Ek sinyal: Devre dışı hesabın aniden dMSA'ya bağlanması veya msDS-ManagedPassword'ün beklenmedik okunması, patch-sonrası kullanım işaretidir.

BloodHound	MITRE
—	`T1098`

3.11 ACL Graph / Baseline Detection (Sürekli Hunting)

Event tabanlı tespit yalnız değişiklik anını yakalar, zaten var olan/retention dışına düşmüş yanlış delegasyonu yakalamaz.

Snapshot N 
 → Snapshot N+1 
  → owner/DACL/inheritance diff 
   → BloodHound edge diff 
    → yeni Tier 0 path

İzlenecek yeni ayrıcalıklar:

GenericAll · GenericWrite · WriteDACL · WriteOwner/Owns · ForceChangePassword · AddMember/AddSelf · AddKeyCredentialLink
AddAllowedToAct · DCSync · GPO control/gPLink · Tier 0'a yeni shortest path · foreign/orphaned SID ACE.

Tetikleyiciler: Bölüm 2.20 (delegasyon/şema/adprep/birleşme) + 30–90 gün periyodik. BloodHound Enterprise vb. bunu sürekli attack-path management programına çevirir.

Not: Bir ACE'nin riski yalnız hak adına göre değil, transitive sonucuna göre değerlendirilir (düşük riskli grup Tier 0'a nested olabilir)

3.12 Honeytoken / Canary

• Sahte ayrıcalıklı hesap (adminCount=1, gerçekte kullanılmayan, SACL'li): buna gelen herhangi 4662 (ACL keşfi), 4724, 5136, 4768/4769 neredeyse kesin kötü niyetli → düşük false positive.
• Honey-SPN (hiç çalışmayan servis): bu SPN'e gelen her 4769 kesin Kerberoasting keşif sinyali.
• AdminSDHolder canary ACE (izlenen, gerçek hak vermeyen trustee): DACL'a yazma girişimini yakalar.

Honeytoken önlemenin yerine geçmez; erken uyarı katmanıdır. Tuzak nesnenin gerçek yetki taşımadığından ve otomasyonun onu meşru çağırmadığından emin olun.

3.13 Audit Tampering Detection

Detection altyapısının zayıflatılması da izlenir: 4719 (audit policy değişti), 4907 (nesne SACL'ı değişti), 1102 (Security log temizlendi).

Ek göstergeler:

• DC log boyutunun küçültülmesi
• Event forwarding'in durması
• Collector kopması
• Kritik nesne SACL'ının kaldırılması
• GPO ile audit'in kapatılması
• Bir DC'den 5136/4662 akışının aniden kesilmesi

"Hiç event gelmemesi" izlenmeli → DC başına heartbeat + event-volume baseline

3.14 Detection Önceliklendirme

P0 (Kritik):
 • Domain root'a yeni DCSync ACE
 • Non-DC'den başarılı replikasyon
 • AdminSDHolder DACL/owner değişimi
 • Tier 0'a yeni GenericAll/WriteDACL/WriteOwner
 • Tier 0 hesaba msDS-KeyCredentialLink
 • DC computer'da RBCD
 • Tier 0 OU/domain'de yetkisiz gPLink
 • Privileged hesaba bağlı şüpheli dMSA migration

P1 (Yüksek):
 • Privileged hesapta parola reset
 • Privileged gruba üye ekleme
 • Tier 0 dışından kritik GPO değişimi
 • Kullanıcıya SPN + hemen TGS
 • Yeni computer'ın hemen RBCD'de kullanımı

P2 (Orta):
 • Düşük etkili OU'da yeni delegasyon
 • Onaylı hesaptan ama change-dışı ACL değişimi
 • WHfB kullanıcıda doğrulanmamış yeni KeyCredential
 • Beklenmeyen owner/inheritance drift

Risk skoru = hedef kritiklik + hak etkisi + principal seviyesi + kaynak host güveni + change-control durumu + downstream kullanım + attack-path sonucu.

3.15 Generic Detection Mantığı + Sigma Taslakları

Pseudo mantık (SID + kaynak host + hedef DN + beklenen işlem birlikte; ad-tabanlı statik allowlist değil):

ACL değişimi: 5136 AND attr=nTSecurityDescriptor AND ObjectDN∈kritik AND SubjectSID∉allowlist
Shadow Creds: 5136 AND attr=msDS-KeyCredentialLink AND ValueAdded AND yazan∉provisioning-allowlist
RBCD:         5136 AND attr=msDS-AllowedToActOnBehalfOfOtherIdentity AND (hedef kritik OR eklenen SID∉baseline)
DCSync:       4662 AND AccessMask=0x100 AND Properties∈replikasyon-GUID AND principal/source∉beklenen
Kerberoast:   5136(SPN add) → 4769(aynı SPN, etype 0x17) → 5136(SPN delete)  [kısa pencere]

Sigma taslakları (experimental — ortama göre alan adları/collector normalizasyonu ayarlanmalı):

AdminSDHolder Nesnesi DACL Değiştirildi

title: AdminSDHolder Nesnesi DACL Değiştirildi
status: experimental
logsource: { product: windows, service: security }
detection:
  selection:
    EventID: 5136
    ObjectDN|contains: 'CN=AdminSDHolder'
    AttributeLDAPDisplayName: 'nTSecurityDescriptor'
    OperationType: 'Value Added'
  condition: selection
level: high
tags: [attack.persistence, attack.t1098]

DCSync Replikasyon GUID — Non-DC Hesap

title: DCSync Replikasyon GUID — Non-DC Hesap
status: experimental
logsource: { product: windows, service: security }
detection:
  selection:
    EventID: 4662
    Properties|contains:
      - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'
      - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
  filter_dc:  { SubjectUserName|endswith: '$' }
  filter_sync: { SubjectUserName|startswith: 'MSOL_' }
  condition: selection and not (filter_dc or filter_sync)
level: critical
tags: [attack.credential_access, attack.t1003.006]
# Not: $/MSOL_ filtresi güvenlik sınırı değil; baseline sapması ile birlikte kullan.

msDS-KeyCredentialLink Yazımı (Shadow Credentials)

title: msDS-KeyCredentialLink Yazımı (Shadow Credentials)
status: experimental
logsource: { product: windows, service: security }
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: 'msDS-KeyCredentialLink'
    OperationType: 'Value Added'
  filter_known: { SubjectUserName: ['MSOL_*','ADFS_svc*'] }   # WHfB/sync istisnaları
  condition: selection and not filter_known
level: high
tags: [attack.persistence, attack.t1556, attack.t1098]
# Ön koşul: schemaIDGUID 5b47d60f-6090-40b2-9f37-2a4de88f3063 için özel SACL.

3.16 DFIR — SACL Yoksa: Retrospektif Analiz

Gerçek dünyada olay anında SACL çoğu zaman yoktur. Bu durumda event log'a değil, AD replikasyon metadata'sına dönülür (AD veritabanında saklanır, event log'dan bağımsız):

• repadmin /showobjmeta <DC> "<DN>" (veya Get-ADReplicationAttributeMetadata): her attribute için son değişim zamanı, versiyon sayacı, originating DSA (ilk değişikliğin yapıldığı DC).
• Sınır: metadata kim değiştirdiğini söylemez; yalnız hangi DC + ne zaman. "Kim" için bulunan DC + zaman damgasıyla o DC'nin Security log'unda (varsa) 4738 vb. aranır.
• Linked attribute'lar (ör. member): repadmin /showobjmeta … /linked geçmişte eklenip çıkarılmış üyeleri gösterebilir (versiyon sıfırlanmaz) → "şimdi üye değil ama kısa süre eklenmişti" (ekle-kullan-çıkar kalıcılığı) ortaya çıkar.

Sonuç: SACL yokken bile "ne zaman + hangi DC" cevaplanır; "kim" ancak dolaylı korelasyonla (4738, oturum, ağ) kısmen çıkar. Bu, SACL'ın "iyi olur" değil zorunlu kontrol olduğunun kanıtıdır.

3.17 DFIR — Timeline, Scoping, Containment

Timeline: Her DC kendi Security log'unu tutar; 5136/4662/4724 yalnız değişikliğin işlendiği DC'de görülür → merkezi toplama yoksa tüm DC'ler taranır.

Minimum kaynaklar: DS Access (5136/4662) + Account Mgmt (4724/4728/4738/4741/4780) + Kerberos (4768/4769/4771) + Logon (4624/4625/4648) + ağ/proxy.

Not: Correlation ID + ±birkaç saniye penceresi ile "önce ACE, sonra reset, sonra logon" zinciri doğru sırayla kurulur.

Scoping / blast radius:

• Her kötü ACE için: hangi principal, hangi nesne, ne zaman, principal başka yerde de ayrıcalıklı mı (yeni BloodHound taraması).
• DCSync doğrulandıysa tüm domain sırları (krbtgt + Tier 0) tehlikede.
• AdminSDHolder doğrulandıysa tüm protected gruplar/üyeler.
• Shadow Creds/RBCD'de ekleme zamanı ↔ ilk kullanım (4768/4769) farkı = saldırganın dwell time'ı; yalnız ekleme zamanına bakmak yetersiz.

Containment/Eradication (Bölüm 2.21 + DFIR ek):

• ACE silmeden adli kopya al (remediation kanıtı yok etmemeli).
• AdminSDHolder'da hem hedef hesaptan hem şablondan sil (yoksa SDProp geri getirir).
• DCSync'te krbtgt çift reset containment'ın parçasıdır, sonraya bırakılmaz.
• Shadow Creds'te yalnız saldırgan key'i sil, meşru WHfB key'lerini körlemesine silme.
E• radication sonrası grafiği yeniden topla, path kapandı mı ve saldırganın orijinal erişimi hangi ACE'den geliyor (kök neden) doğrula.

3.18 Triage Soruları

Değişikliği yapan SID? 
 → hesap ele geçirilmiş mi/meşru rol mü? 
  → hangi DC? 
   → SubjectLogonId hangi 4624/source IP? 
    → kaynak onaylı PAW/jump host mu? 
     → hedef Tier 0 (veya transitively bağlı) mı? 
      → tam olarak hangi ACE/attribute eklendi/silindi? 
       → kalıcı mı, geri alındı mı? 
        → sonrasında 4724/grup/4768/4769/4662/hedef logon var mı? 
         → yeni BloodHound path? 
          → change/ticket kaydı? 
           → aynı subject başka nesnelerde benzer değişiklik yaptı mı?

İlk müdahalede SD/owner/attribute/loglar korunmalıdır. Kanıt toplanmadan körlemesine ACE/KeyCredential silmek meşru servisleri bozar.

3.19 Güvenli Detection Testi

Disposable lab OU'da: test grubuna üye ekle/çıkar · lab kullanıcısını kontrollü resetle · lab nesnesinde test ACE ekle/kaldır · geçici SPN ekle/kaldır · lab GPO metadata değişimi.

Her testte kontrol edilecekler:

• Beklenen olay oluştu mu
• Doğru DC'den toplandı mı
• Subject SID doğru mu
• Source IP 4624 ile eşleşti mi
• Attribute/GUID parse edildi mi
• Add/Delete tek değişiklik olarak korele edildi mi
• Alarm doğru Tier/öncelikle üretildi mi
• Cleanup sonrası baseline döndü mü

Tier 0 testleri (DCSync, AdminSDHolder, DC'de RBCD, gerçek privileged'a Shadow Creds, BadSuccessor) üretim/standart labta yapılmaz → ayrı purple-team + açık onay.

3.20 En Sık Detection Hataları

Hata	Sonuç
SACL'sız audit policy yeterli sanmak	Sıfır olay, tam körlük
msDS-KeyCredentialLink için varsayılan SACL'a güvenmek	Shadow Credentials sessizce geçer
Yalnız 5136 toplamak	Parola reset (4724), grup, gerçek DCSync (4662) kaçar
Yalnız bir DC'nin logu	Başka DC'deki değişiklik kaçar
Correlation ID izlememek	5136 işlemi eksik/yanlış yorumlanır
Ada göre allowlist	Rename/benzer ad/ele geçirilmiş hesap kaçar
`$`/`MSOL_` statik dışlama, baseline yok	adprep sonrası meşru-beklenmedik hesap kaçar / alarm yorgunluğu
RC4 4769'u otomatik saldırı saymak	Legacy servis false positive
RBCD binary SD'yi parse etmemek	Eklenen SID görülmez
Yalnız hedef hesaptaki ACE'yi izlemek	AdminSDHolder kök nedeni kaçar
Yalnız GPC izlemek	GPT/SYSVOL + gPLink kaçar
Yalnız 4780'e güvenmek	SDProp görünürlüğü eksik
4662'yi filtresiz toplamak	Aşırı hacim/maliyet
Son-durum snapshot'ına güvenmek	Kısa süreli ekle-kullan-sil kaçar
Change kaydı varsa alarmı kapatmak	Ele geçirilmiş yönetim hesabı kaçar
Event log'u tek gerçeklik saymak	SACL yokken repadmin metadata atlanır

3.21 Detection Etkinlik Matrisi

Zincir	Birincil sinyal	Destekleyici korelasyon
WriteDACL	5136 nTSecurityDescriptor	4662 0x40000, SDDL diff
WriteOwner	5136 owner (O:) değişimi	4662 0x80000, ardından WriteDACL
ForceChangePassword	4724	4768/4624 yeni auth
AddMember/AddSelf	4728/4732/4756	nested Tier 0 graph, privileged logon
WriteSPN	5136 servicePrincipalName	4769 (0x17) + hızlı SPN kaldırma
Shadow Credentials	5136 msDS-KeyCredentialLink	4768 PKINIT (type 16), kayıtsız cihaz
RBCD	5136 msDS-AllowedToAct…	4741 + 4769 S4U2Proxy (Transited Services), hedef 4624
DCSync — hak verme	5136 domain-root DACL, replikasyon GUID'li ACE	—
DCSync — kullanım	4662 0x100	DRSUAPI ağı, non-DC source
AdminSDHolder	5136 AdminSDHolder DACL	4780/protected-object yayılımı (kök neden gruplama)
GPO	5136/5137/5141 (GPC)	4663/5145 (GPT hash), gPLink
BadSuccessor/dMSA	5137 + 5136 (PrecededByLink)	2946, 4741, 4769
Audit tampering	4719/4907/1102	DC event-volume/heartbeat baseline

3.22 Kapsamadığı Alanlar

Endpoint/EDR (Sysmon/ETW/LSASS) · Entra ID/Graph audit · NTLM relay · Golden/Silver Ticket forensics · NTDS.dit offline forensics · SIEM ürünü kurulum/lisans. Ayrı katmanlar gerekir.

3.23 Bölüm 3 ve Seri Sonuçları

AD ACL detection'ın temeli tek Event ID değil, değişiklik + kullanımın birlikte izlenmesidir:

SACL + audit 
 → 5136 (attr/ACL) 
 → 4662 (hak kullanımı) 
 → 4724/grup (hesap etkisi)
 → 4768/4769 (Kerberos) 
 → 4624 (kaynak host) 
 → DRSUAPI (ağ) 
 → BloodHound (attack-path)

En kritik ilkeler:

· tüm DC'lerden merkezi toplama · SID/GUID/DN/LogonID enrichment · nTSD için gerçek SDDL diff · Shadow Creds için özel SACL (schemaIDGUID) + PKINIT korelasyonu
· RBCD binary SD'den SID çıkarma · DCSync hak-verme ↔ kullanımı ayrı izleme · AdminSDHolder'ı kök-neden olarak ele alma · GPC/GPT/gPLink ayrı yüzeyler
· event-tabanlıyı periyodik ACL-graph diff ile tamamlama · SACL yoksa DFIR için replikasyon metadata.

Seri özeti: Bölüm 1 hangi hakkın hangi zincire dönüştüğünü, Bölüm 2 bu zincirleri önceden nasıl kapatacağınızı, Bölüm 3 kapatamadığınız/kaçırdığınız zincirleri nasıl göreceğinizi verdi. Üçü birlikte, sürekli çalışan bir program olarak yürütülmedikçe her biri yalnız kısmi güvenlik sağlar

Kaynaklar

Microsoft Learn — Audit Directory Service Changes; Event 5136, 4662, 4724, 4768/4769, 4780
Microsoft Defender for Identity — Windows event auditing yapılandırması
Microsoft — Appendix C: Protected Accounts and Groups
SpecterOps — Shadow Credentials; Understanding & Mitigating BadSuccessor; BloodHound / Attack Path Management
harmj0y / SpecterOps — Hunting With Active Directory Replication Metadata
Akamai — BadSuccessor (dMSA) detection & Event 2946; patch analizi (CVE-2025-53779)
SigmaHQ — win_security_dcsync.yml, win_security_susp_possible_shadow_credentials_added.yml
Elastic — AdminSDHolder Backdoor prebuilt rule; Audit Directory Service Changes rehberi
Splunk Security Content — AD Domain Replication ACL Addition; AdminSDHolder ACL Modified; Kerberoasting RC4
Azure Sentinel — AdminSDHolder_Modifications.yaml
FalconForce — FalconFriday (RBCD & Shadow Credentials detection)
DefensiveOrigins / Black Hills InfoSec — Detect-msDS-KeyCredentialLink; deception/honeytoken yaklaşımları
TrustedSec — The Art of Detecting Kerberoast Attacks
MITRE ATT&CK — T1098, T1098.007, T1003.006, T1558.003, T1484.001, T1556

Bilgilendirme notu

Tespit inceliği: Active Directory DACL suistimali; standart günlüklerde sessiz kaldığı için uzun süre fark edilmeden kalabilir. BloodHound'un düzenli çalıştırılması ve WriteDACL/GenericAll haklarının servis ve bilgisayar hesaplarına atandığı nesnelerin raporlanması erken uyarı sağlar. Shadow Credentials saldırısında msDS-KeyCredentialLink özniteliğindeki beklenmedik değişiklikler Windows Güvenlik olayı ID 5136 ile izlenebilir (MITRE ATT&CK T1484.001). Sık yapılan hata: AdminSDHolder üzerindeki ACL'yi yalnızca kurulum sırasında kontrol etmek.

Detection kuralları

Bu tekniği tespit eden, doğrudan kopyalanabilir kurallar (Sigma/KQL/…). Her kuralın gereken telemetrisi, olgunluğu ve kaynağı belirtilir.

Active Directory User Backdoors

Detects scenarios where one can control another users or computers account without having to use their credentials.

high

sigmaTest

Kuralı gösterKuralı gizle

title: Active Directory User Backdoors
id: 300bac00-e041-4ee2-9c36-e262656a6ecc
status: test
description: Detects scenarios where one can control another users or computers account without having to use their credentials.
references:
    - https://msdn.microsoft.com/en-us/library/cc220234.aspx
    - https://adsecurity.org/?p=3466
    - https://blog.harmj0y.net/redteaming/another-word-on-delegation/
author: '@neu5ron'
date: 2017-04-13
modified: 2024-02-26
tags:
    - attack.privilege-escalation
    - attack.t1098
    - attack.persistence
logsource:
    product: windows
    service: security
    definition: 'Requirements: Audit Policy : Account Management > Audit User Account Management, Group Policy : Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\Account Management\Audit User Account Management, DS Access > Audit Directory Service Changes, Group Policy : Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\DS Access\Audit Directory Service Changes'
detection:
    selection1:
        EventID: 4738
    filter_empty:
        AllowedToDelegateTo:
            - ''
            - '-'
    filter_null:
        AllowedToDelegateTo: null
    selection_5136_1:
        EventID: 5136
        AttributeLDAPDisplayName: 'msDS-AllowedToDelegateTo'
    selection_5136_2:
        EventID: 5136
        ObjectClass: 'user'
        AttributeLDAPDisplayName: 'servicePrincipalName'
    selection_5136_3:
        EventID: 5136
        AttributeLDAPDisplayName: 'msDS-AllowedToActOnBehalfOfOtherIdentity'
    condition: (selection1 and not 1 of filter_*) or 1 of selection_5136_*
falsepositives:
    - Unknown
level: high

Doğrulanmadı

Çalışması için gereken telemetri: windows; securitywindows / securitywindows

Yanlış pozitif: Unknown

Kaynak: SIGMA · Detection Rule License (DRL) 1.1 · orijinal kural

Önlemler

Bu tekniği azaltan/engelleyen prevention ve hardening önlemleri.

Active Directory Configuration

Hardening

AD saldiri yuzeyini (Kerberos/RC4, delegasyon, krbtgt, gMSA, ACL) azaltan yapilandirma sertlestirmeleri.

Bilgilendirme notu

Bilgilendirme notu: Active Directory yapılandırmasında Unconstrained Delegation devre dışı bırakılmalı, Constrained Delegation gözden geçirilmeli ve Kerberos ön kimlik doğrulaması tüm hesaplarda zorunlu tutulmalıdır (AS-REP Roasting'i önler). KRBTGT hesabı parolası periyodik olarak çift döndürme ile yenilenmelidir. DCSync yetkisi olan hesaplar (DS-Replication izinleri) denetlenmeli ve bu işlem için ayrılmış, izlenen hesaplar kullanılmalıdır.

Disable or Remove Feature or Program

Hardening

Gereksiz/eski ozellikleri kaldir: SMBv1, LLMNR/NBT-NS, kullanilmayan servisler.

Bilgilendirme notu

Bilgilendirme notu: Özellik ve program devre dışı bırakma mitigasyonunda LLMNR, NetBIOS-NS, NTLMv1, Wpad otomatik proxy keşfi ve kullanılmayan IPv6 gibi saldırıya açık protokollerin kapatılması temel önceliklerdendir. Linux sistemlerde gereksiz daemon'lar kaldırılmalı, ağ cihazlarında legacy servisler (bootp, fingerd) kapatılmalıdır. PowerShell v2'nin kaldırılması, indirme cradle ve obfuskasyon tekniklerini daha az etkili kılar.

Bu tekniğe karşı baseline kontrolleri

Aşağıdaki güvenlik baseline kontrolleri bu tekniği azaltır. Kurumunuzun yapılandırmasını ilgili baseline ile .

Müdahale playbook'ları

Bu teknik tespit edildiğinde izlenecek NIST/SANS fazlı müdahale akışları.

Persistence tactic'indeki teknikler

T1053.005Persistenceİleri

Windows Görev Zamanlayıcısı (schtasks.exe / Schedule.Service COM), saldırganlar tarafından hem kalıcılık hem uzaktan yürütme (lateral hareket) için yaygın biçimde kullanılır. Yazı; schtasks sözdizimi, XML görev yapısı, TaskCache kayıt defteri, EID 4698/4699/4700/4701/4702 + TaskScheduler/Operational 106/140/141/200/201 telemetrisi, Sigma kuralı ve sertleştirme kontrollerini kapsar.

13 Haziran 202610 dk okuma

Exploit

Prevention

Detection

Referanslar

MITRE ATT&CK — T1098: Active Directory ACL/DACL Suistimali: GenericAll'dan Gölge Kimlik Bilgilerine ve AdminSDHolder Kalıcılığına ↗

Bu makale MITRE ATT&CK çerçevesine dayanır; tespit, savunma ve müdahale içeriği bağımsız olarak hazırlanmıştır.

Active Directory ACL/DACL Suistimali: GenericAll'dan Gölge Kimlik Bilgilerine ve AdminSDHolder Kalıcılığına

Mimari, Zafiyet Yüzeyi ve Suistimal Zincirleri

1.1 Yönetici Özeti

1.2 Amaç ve Kapsam

1.3 Güvenlik Tanımlayıcısının Yapısı

SACL nüansı

1.4 Empty DACL ve Null DACL

1.5 ACE Yapısı

1.6 ACE Değerlendirme Mantığı

1.7 Owner ve WriteOwner Gerçeği

İstisnalar

WriteOwner

1.8 Tehlikeli Haklar

1.9 Validated Write Nüansı

1.10 Suistimal Zincirleri

1.10.1 ForceChangePassword

1.10.2 AddMember ve AddSelf

1.10.3 WriteSPN ve Hedefli Kerberoasting

1.10.4 Shadow Credentials

Ön koşullar

1.10.5 Resource-Based Constrained Delegation

1.10.6 WriteDACL

1.10.7 WriteOwner

1.10.8 DCSync

1.11 AdminSDHolder ve SDProp

Suistimal:

Manuel çalıştırma:

Admin Count:

adminCount=1, nesnenin halen korunan grupta olduğunu kanıtlamaz.

Nesne gruptan çıkarıldıktan sonra:

1.12 GPO ACL Suistimali

1.13 ACL Görünürlüğünü Zorlaştıran Teknikler

1.14 MITRE ATT&CK Eşlemesi

1.15 Güvenli Lab PoC

1.16 Bölüm 1 Sonuçları

Prevention & Hardening

2.1 Yönetici Özeti

2.2 Bu Kontrollerin Sınırı

2.3 Önceliklendirilmiş Kontrol Listesi

2.4 ACL Envanteri ve Attack-Path Baseline

2.5 En Az Ayrıcalıklı Delegasyon

2.6 Tier 0 İzolasyonu / Enterprise Access Model

2.7 Owner ve WriteOwner Sertleştirmesi

2.8 ForceChangePassword Delegasyonu

2.9 Grup Üyeliği Delegasyonu

2.10 Shadow Credentials Sertleştirmesi (msDS-KeyCredentialLink)

2.11 Servis Hesabı Modernizasyonu: gMSA / dMSA + BadSuccessor

dMSA'ya geçiş yapan ortamlarda

2.12 RBCD Sertleştirmesi

2.13 SPN ve Service Account Hijyeni

2.14 DCSync Yüzeyini Daraltma

Operasyonel tuzak

2.15 AdminSDHolder Sertleştirmesi

2.16 GPO, SYSVOL ve gPLink Sertleştirmesi

2.17 Protected Users ve Authentication Policy

2.18 SACL ve Denetim Ön Koşulları

2.19 Change Control ve ACL Governance

2.20 Sürekli BloodHound / ACL Graph Doğrulaması

2.21 Güvenli Remediation

2.22 Hardening Etkinlik Matrisi

2.23 En Sık Hardening Hataları

2.24 Uygulama Sırası

2.25 Kapsamadığı Alanlar

2.26 Bölüm 2 Sonuçları

Kaynaklar

Bölüm 3: Detection, Threat Hunting & DFIR

3.1 Yönetici Özeti

3.2 Kapsam

3.3 Detection Veri Kaynakları

3.4 Audit Policy Ön Koşulları

3.5 SACL Tasarımı

3.6 Event 5136 Anatomisi

3.7 Event 4662 Anatomisi

3.8 Enrichment (SID / GUID / DN / Logon ID)

3.9 Event ID Referans Haritası

3.10 Teknik Bazlı Tespit

ForceChangePassword

AddMember / AddSelf

WriteSPN → Targeted Kerberoasting

Shadow Credentials

`adminCount=1`, nesnenin halen korunan grupta olduğunu kanıtlamaz.

2.10 Shadow Credentials Sertleştirmesi (`msDS-KeyCredentialLink`)

WMI Event Subscription Kalıcılığı: EventFilter / EventConsumer / __FilterToConsumerBinding ile Gizli Arka Kapılar