Merhaba

Önceki iki bölümde AD CS’e yönelik teknikleri ele aldık. Bu bölümde ise, domain controller’ların birbirleriyle konuşurken kullandığı meşru bir replikasyon protokolünün, bir saldırgan tarafından nasıl silah haline getirilebildiğini inceliyoruz: DCSync. Bu teknik, hiçbir dosyaya dokunmadan, hiçbir exploit kullanmadan, sadece Active Directory’nin kendi replikasyon mekanizmasını normal şekilde kullanarak domain’deki her hesabın parola hash’ini çekebilmeyi sağlıyor.

DCSync

Domain controller’lar birbirleriyle sürekli veri senkronize eder; bu senkronizasyon, Microsoft’un MS-DRSR (Directory Replication Service Remote Protocol) adını verdiği bir RPC protokolü üzerinden yürütülür. Bir domain controller, diğerine “bana son değişiklikleri gönder” dediğinde, bu istek DRSGetNCChanges adlı bir fonksiyon çağrısıyla gerçekleşir ve karşı taraf, parola hash’leri dahil tüm nesne özniteliklerini içeren replikasyon verisini gönderir. DCSync tekniği, bu protokolü bir domain controller’a hiç ihtiyaç duymadan, sıradan bir domain üyesi bilgisayardan tetikler. Tek gereken şey, saldırganın kontrolündeki hesabın domain nesnesi (domain root) üzerinde iki özel genişletilmiş hakka (extended right) sahip olmasıdır: Replicating Directory Changes ve Replicating Directory Changes All. Bu haklar normalde yalnızca Domain Admins, Enterprise Admins gruplarına ve domain controller bilgisayar hesaplarına verilidir – ama bu haklar bazen istemeden ya da farkında olmadan başka hesaplara da devredilir: Azure AD Connect / Microsoft Entra Connect senkronizasyon hesabı bunun en yaygın örneğidir, çünkü bu hesabın bulut senkronizasyonu için parola hash’lerini okuyabilmesi gerekir. Bu haklara sahip herhangi bir hesap ele geçirildiğinde, saldırgan Mimikatz’ın lsadump::dcsync modülü veya Impacket’in secretsdump.py aracıyla, kendi bilgisayarından, sanki kendisi bir domain controller’mış gibi, domain controller’a bağlanıp istediği herhangi bir hesabın (bir kullanıcının, bir Domain Admin’in, hatta krbtgt hesabının) NTLM hash’ini talep edebilir. Bu tekniğin en kritik yönü, domain controller’ın disk sistemine hiç dokunulmamasıdır – saldırgan ne ntds.dit dosyasına erişir ne de bir Volume Shadow Copy oluşturur (bu, serinin ileriki bir bölümünde ele alınacak farklı bir teknik). Tamamen ağ üzerinden, meşru bir protokolün meşru bir fonksiyonu çağrılarak gerçekleştirilir – bu da DCSync’i, hem çok hızlı hem de klasik dosya erişim izleme araçları tarafından görünmez kılan bir teknik haline getirir.

DCSync’i Mitigasyon Etmek

DCSync tekniğini mitigasyon etmek için aşağıdaki güvenlik kontrolleri uygulanmalıdır:

• Domain nesnesi üzerindeki “Replicating Directory Changes” ve “Replicating Directory Changes All” haklarını düzenli olarak denetleyin. BloodHound gibi bir araçla, bu haklara sahip TÜM sorumluları (Domain Admins/Enterprise Admins/domain controller’lar dışında kalan her hesabı) tespit edin ve gerekçesiz olanları kaldırın.
• Azure AD Connect / Microsoft Entra Connect senkronizasyon hesabını Tier 0 varlık olarak koruyun. Bu hesap, meşru olarak bu haklara sahip olması gereken en yaygın istisna olduğundan, bu hesabın kimlik bilgilerinin ve çalıştığı sunucunun güvenliği domain controller’larla aynı titizlikte ele alınmalıdır.
• Domain nesnesi üzerinde nesne erişim denetimini (Object Access auditing) etkinleştirin. Bu, Replicating Directory Changes haklarının kullanıldığı her olayın Event 4662 olarak loglanmasını sağlar.
• Domain controller olmayan kaynaklardan gelen DRSUAPI (MS-DRSR) trafiğini ağ düzeyinde izleyin. Bir domain controller’a, bilinen domain controller IP’leri dışında bir kaynaktan gelen replikasyon trafiği, güçlü bir DCSync göstergesidir.
• krbtgt hesabının parolasını (ve dolayısıyla NTLM hash’ini) düzenli olarak iki kez art arda döndürün. Bu, DCSync ile çalınmış olabilecek eski bir krbtgt hash’inin Golden Ticket üretmek için kullanılmasını (serinin ileriki bir bölümü) geçersiz kılar.

DCSync’i Tespit Etmek

DCSync’in tespiti, domain nesnesi üzerindeki denetim ilkelerinin doğru yapılandırılmasına bağlıdır; bu denetim varsayılan olarak kapalıdır. Aşağıdaki Event ID merkezi olarak loglanmalı ve zamanında analiz edilmelidir.

DCSync’i Tespit Eden Olaylar

Lab Uygulaması: Windows Server 2025 Üzerinde DCSync

Bu bölümde DCSync tekniğini kendi lab ortamımızda (W25DC.bakicubuk.local domain controller ve W11CLIENT.bakicubuk.local domain üyesi istemci) baştan sona uyguladık: önce domain nesnesi üzerinde doğru denetim ayarlarını kurduk, ardından düşük yetkili bir test hesabına bilinçli olarak aşırı geniş bir replikasyon izni verdik, bu hesap üzerinden gerçek bir DCSync saldırısı gerçekleştirdik ve son olarak domain controller’ın bu işlemi Event 4662 ile nasıl yakaladığını doğruladık.

Adım 1: Directory Service Access Denetimini Etkinleştirmek

DCSync’in tespit edilebilmesi için önce domain controller üzerinde Object Access denetim kategorisini açmak, ardından domain nesnesinin kendisine bir SACL (System Access Control List) denetim kuralı eklemek gerekiyor – çünkü bu denetim varsayılan olarak kapalı. İlk adımda auditpol ile kategoriyi etkinleştirdik:

auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable

Ardından domain nesnesi (DC=bakicubuk,DC=local) üzerine, hem Replicating Directory Changes hem de Replicating Directory Changes All extended right’ları için Everyone kapsamında bir başarı denetimi (audit rule) eklemek üzere PowerShell kullandık:

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl -Path "AD:\$domainDN"
$replChanges = [GUID]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"
$replChangesAll = [GUID]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
$everyone = New-Object System.Security.Principal.SecurityIdentifier("S-1-1-0")
$noInheritance = [System.DirectoryServices.ActiveDirectorySecurityInheritance]::None
$rule1 = New-Object System.DirectoryServices.ActiveDirectoryAuditRule($everyone,"ExtendedRight","Success",$noInheritance,$replChanges)
$rule2 = New-Object System.DirectoryServices.ActiveDirectoryAuditRule($everyone,"ExtendedRight","Success",$noInheritance,$replChangesAll)
$acl.AddAuditRule($rule1)
$acl.AddAuditRule($rule2)
Set-Acl -Path "AD:\$domainDN" -AclObject $acl

İlk denemede ActiveDirectoryAuditRule yapıcısına dördüncü parametre olarak boş bir metin ("") verildi, bu da şu hatayla sonuçlandı: Cannot convert argument "3", with value: "", for "ActiveDirectoryAuditRule" to type "System.DirectoryServices.ActiveDirectorySecurityInheritance". Sorun, bu parametrenin bir metin değil, ActiveDirectorySecurityInheritance enum tipinden bir değer beklemesiydi. Düzeltme, $noInheritance = [System.DirectoryServices.ActiveDirectorySecurityInheritance]::None şeklinde açıkça bir enum değeri oluşturup bunu geçirmek oldu; script bu haliyle hatasız tamamlandı.

Adım 2: Düşük Yetkili Hesaba Replikasyon Haklarını Vermek

Gerçek dünyada bu haklar genellikle kasıtlı olarak değil, yanlışlıkla veya aşırı geniş bir delegasyon sonucunda sıradan bir hesaba geçer (Microsoft Entra Connect senkronizasyon hesabının yanlış yapılandırılması bunun en tipik örneğidir). Bu senaryoyu simüle etmek için, serinin önceki bölümlerinde oluşturduğumuz düşük yetkili lowpriv domain hesabına, dsacls ile domain nesnesi üzerinde her iki hakkı da açıkça verdik:

dsacls "DC=bakicubuk,DC=local" /G "BAKICUBUK\lowpriv:CA;Replicating Directory Changes"
dsacls "DC=bakicubuk,DC=local" /G "BAKICUBUK\lowpriv:CA;Replicating Directory Changes All"

Doğrulama sorgusu (dsacls "DC=bakicubuk,DC=local" | Select-String "lowpriv"), lowpriv için her iki hakkın da Allow olarak eklendiğini gösterdi.

Adım 3: DCSync’i Gerçekleştirmek

Hedef olarak, Domain Admin veya krbtgt gibi kritik bir hesap yerine, yalnızca bu gösterim için oluşturulmuş sınırlı bir demo hesabı (dcsyncdemo) kullandık. Ardından W11CLIENT üzerinde, runas /user:bakicubuk\lowpriv powershell ile lowpriv bağlamına geçip, daha önceki bir bölümde bu istemciye yerleştirdiğimiz Mimikatz’ı çalıştırdık:

mimikatz # privilege::debug
ERROR kuhl_m_privilege_simple ; RtlAdjustPrivilege (20) c0000061

mimikatz # lsadump::dcsync /domain:bakicubuk.local /user:dcsyncdemo

privilege::debug komutunun başarısız olması beklenen bir durumdu, çünkü lowpriv W11CLIENT üzerinde yerel yönetici değil ama DCSync tekniği zaten yerel bir ayrıcalık gerektirmiyor, tamamen domain nesnesi üzerindeki replikasyon haklarına dayanıyor. Nitekim lsadump::dcsync komutu bu ayrıcalık hatasından bağımsız olarak sorunsuzca çalıştı ve dcsyncdemo hesabının NTLM hash’i, LM hash’i, Kerberos AES256/AES128/DES anahtarları ve WDigest kimlik bilgileri dahil tam kimlik bilgisi setini domain controller’a hiç bağlanmadan (bir oturum açma bile yapmadan), sadece replikasyon protokolü üzerinden çekti. Bu, W11CLIENT’ın hiçbir zaman bir domain controller olmamasına rağmen, sahip olunan iki extended right sayesinde domain controller’a “ben de bir domain controller’ım, bana son değişiklikleri gönder” diyebildiğini somut olarak gösterdi.

Adım 4: Event 4662 Kanıtını Doğrulamak

DCSync çalıştırıldıktan sonra W25DC üzerinde Event Viewer’da Security günlüğünü, işlemin gerçekleştiği saat aralığında Event 4662 için sorguladık:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662; StartTime=(Get-Date "2026-09-23 22:17:00"); EndTime=(Get-Date "2026-09-23 22:18:00")} |
    Where-Object { $_.Message -match 'lowpriv' } |
    Format-List TimeCreated, Id, Message

Sonuç, aynı saniyede (22:17:18) üretilmiş, hepsi lowpriv hesabından kaynaklanan üç ayrı Event 4662 kaydı döndürdü:

Üçünde de Subject alanı BAKICUBUK\lowpriv, Object Name alanı DC=bakicubuk,DC=local, Access Mask ise 0x100 (Control Access) olarak görünüyor, yani sıradan bir okuma/yazma işlemi değil, doğrudan bir extended right kullanımı söz konusu. İlk hakkın (Replicating Directory Changes) iki kez loglanması, MS-DRSR replikasyon döngüsünün bu kontrolü birden fazla aşamada yapmasından kaynaklanıyor; tekniğin mekanizmasını değiştirmiyor.

 Event 4662 – lowpriv hesabının domain nesnesi üzerinde Replicating Directory Changes hakkını (Control Access, GUID {1131f6aa-…}) kullandığını gösteren ilk kayıt.

Aynı hakkın (Replicating Directory Changes) ikinci kez loglandığı, yine lowpriv kaynaklı Event 4662 kaydı.

Event 4662 – lowpriv hesabının Replicating Directory Changes All hakkını (GUID {1131f6ad-…}) kullandığını gösteren üçüncü kayıt; bu, DCSync’in parola hash’lerini okuyabilmek için ihtiyaç duyduğu ikinci ve son hak.

Bu üç kayıt birlikte, DCSync tespitinin temel mantığını net biçimde ortaya koyuyor: kaynak hesap (lowpriv) bir domain controller bilgisayar hesabı değil, sıradan bir kullanıcı hesabı; buna rağmen domain nesnesi üzerinde bir domain controller’a özgü iki extended right’ı fiilen kullanmış durumda. Bir SOC’ta bu üç şartın (Control Access, doğru GUID, domain controller olmayan Subject) birlikte görülmesi, gerçek zamanlı bir DCSync uyarısı üretmek için yeterli bir kural tabanı oluşturur.

Uyumluluk ve Çerçeve Eşlemesi Tablosu

MITRE ATT&CK: T1003.006 (OS Credential Dumping: DCSync)

Sonuç

DCSync, Active Directory’nin en temel işlevlerinden birinin (domain controller replikasyonu) bir saldırı aracına dönüşebileceğinin çarpıcı bir örneğidir. Zafiyet bir yazılım hatası değil, tamamen bir yetkilendirme sorunudur, bu yüzden mitigasyon da tamamen yetkilendirme denetiminden geçer: domain nesnesi üzerinde bu iki hakka kimlerin sahip olduğunu bilmek ve bunu düzenli olarak doğrulamak.

Serinin bir sonraki bölümünde, DCSync’in dosya tabanlı kuzeni olan ve doğrudan ntds.dit veritabanının çalınmasına dayanan tekniği inceleyeceğiz.