Merhaba
Bu seride 18 bölüm boyunca, CISA/NSA/ASD/Five Eyes ortaklığının yayınladığı Detecting and Mitigating Active Directory Compromises raporundaki teknikleri tek tek ele aldık: Kerberoasting’den başlayıp AS-REP Roasting, Password Spraying, MachineAccountQuota istismarı, Unconstrained Delegation, GPP şifreleri, AD CS (ESC1), Golden Certificate, DCSync, ntds.dit dökümü, Golden Ticket, Silver Ticket, Golden SAML, Microsoft Entra Connect ele geçirmesi, tek yönlü trust bypass, SID History enjeksiyonu, Skeleton Key ve son olarak Shadow Credentials’a kadar uzandı. Her bölümde teknik açıklamayı, mitigasyonu, tespit yöntemini ve kendi iki forest lab ortamımızdaki (bakicubuk.local / nihatcubuk.local) gerçek komut çıktılarını paylaştık.
Bu kapanış bölümünde iki şey yapacağız: önce raporun önerdiği, tek başına tüm bu tekniklerin büyük bir kısmını yakalayabilen canary objeler tekniğini inceleyeceğiz; ardından serinin tamamını özetleyen bir mitigasyon kontrol listesi ve bir olay ID (Event ID) master tablosu ile seriyi kapatacağız.
Canary Objelerle Active Directory Ele Geçirmelerini Tespit Etmek
Active Directory ele geçirmelerinin tespiti, olgun bir SIEM (security information and event management güvenlik bilgi ve olay yönetimi) ve SOC (Security Operations Centre) kapasitesine sahip kuruluşlar için bile zor, zaman alıcı ve kaynak yoğun bir iştir. Bunun temel nedeni, bu bölümde gördüğümüz tekniklerin çoğunun meşru Active Directory işlevselliğini istismar etmesi ve normal etkinlikle aynı olay kayıtlarını üretmesidir. Kötü niyetli etkinliği normal etkinlikten ayırt etmek genellikle farklı kaynaklardan gelen olayların ilişkilendirilmesini ve bu olayların tutarsızlıklar açısından analiz edilmesini gerektirir. Bazı tekniklerde ise tespit, bir olayın varlığına ve başka bir olayın yokluğuna dayanır. Bu karmaşıklık, Active Directory ele geçirmelerinin başarısının ve kuruluşlar arasındaki yaygınlığının en önemli nedenlerinden biridir.
Canary objeler, bu karmaşıklığı ortadan kaldıran alternatif bir yaklaşımdır. Bu teknik, olay kayıtlarının ilişkilendirilmesine dayanmaz; bunun yerine bir ele geçirmenin gerçekleştiğine dair güçlü ve doğrudan bir gösterge sağlar. Önemli bir nokta, bu tekniğin kötü niyetli aktörlerin kullandığı aracı (tooling) tespit etmeye çalışan diğer tespit yöntemlerinin aksine, doğrudan ele geçirmenin kendisini tespit etmesidir. Bu sayede ele geçirmeleri daha yüksek doğrulukla yakalama olasılığı vardır. Açık kaynaklı ve ticari araçlar (örneğin Airbus tarafından geliştirilen canary çözümleri) bu ve benzeri teknikleri kullanır.
Canary Objeler Nasıl Çalışır
Canary objeler, Everyone güvenlik grubu üzerinden tüm kullanıcı nesnelerine okuma erişimini reddedecek şekilde yapılandırılabilir. Bu, Directory Service Access denetim ilkesinin hem Success hem de Failure; için yapılandırılmasıyla birleştiğinde, herhangi biri canary objelerden birinin özniteliklerini okumaya çalıştığında bir denetim başarısızlığı olayı (Event ID 4662) üretilmesini sağlar. Bu olay, canary objelerin GUID’i (Globally Unique Identifier) ile yapılandırılmış bir SIEM’e alınabilir ve bu GUID’i içeren herhangi bir karşılık gelen olayda uyarı verecek şekilde ayarlanabilir. Bu, canary objelerden birini numaralandırma (enumeration) girişiminde bulunulduğuna dair yüksek değerli bir uyarı sağlar bu da Active Directory’ye karşı bir ele geçirmenin göstergesidir.
Active Directory’deki nesneleri numaralandıran herhangi bir ele geçirme bu teknikle tespit edilebilir. Bu önemlidir çünkü Active Directory’ye yönelik çoğu ele geçirme, SharpHound gibi bir araç kullanılarak domain’deki tüm nesnelerin numaralandırılmasıyla başlar. Kötü niyetli aktörler, ayrıcalık yükseltme (privilege escalation) ve yanal hareket (lateral movement) için istismar edilebilecek yanlış yapılandırmaları, zayıflıkları ve güvenlik açıklarını belirlemek için bu taktiği kullanır. Bu tür numaralandırma bu teknikle tespit edilir ve kuruluşlara Active Directory ele geçirmesinin devam ettiğine dair erken bir uyarı sağlayabilir.
Bu teknikle tespit edilebilen bu seride ele aldığımız teknikler şunlardır:
Tekniğin Sınırlaması
Bu tekniğin bir sınırlaması, kötü niyetli aktörlerin yalnızca tek bir veya küçük sayıda kullanıcı nesnesini hedef almayı tercih edebilmesidir. Bu durumda, canary objeleri okumaya çalışmaları olası değildir. Sonuç olarak, bu teknik istenen denetim başarısızlığı olayını üretmez ve dolayısıyla SIEM tarafından tespit edilmez. Bu nedenle canary objeler, geniş çaplı numaralandırmaya karşı güçlü bir erken uyarı katmanı olsa da, tek başına yeterli bir tespit stratejisi değildir bu serinin önceki 18 bölümünde işlediğimiz teknik bazlı tespit yöntemleriyle (Event ID tabloları, SACL’ler (System Access Control List), audit policy yapılandırmaları) birlikte kullanılmalıdır.
Lab Uygulaması
Bu bölümün lab uygulaması için W25DC (bakicubuk.local) üzerinde bir canary kullanıcı nesnesi oluşturup, raporun önerdiği tespit mekanizmasının gerçekten çalışıp çalışmadığını uçtan uca test ettik. Bu son bölüm, serinin en fazla beklenmedik bulgu çıkaran laboratuvar uygulamalarından biri oldu hem gerçek bir altyapı sorunuyla hem de tekniğin kendisinin öngördüğü bir kilitlenme senaryosuyla karşılaştık.
1. Adım – Canary Kullanıcı Nesnesi Oluşturma
Gerçek bir kullanıcıymış gibi görünen ama hiçbir meşru işlemde kullanılmayan bir hesap oluşturmaya çalıştık:
New-ADUser -Name "Canary01" -SamAccountName "canary01" -Path "OU=LAPS,DC=bakicubuk,DC=local" -Enabled $true -AccountPassword (ConvertTo-SecureString "N0tR3al!Passw0rd" -AsPlainText -Force)Gerçek bulgu – RID (Relative Identifier) havuzu bozulması: İlk denemede komut The directory service was unable to allocate a relative identifier hatasıyla başarısız oldu. dcdiag /test:ridmanager /v çıktısı, rIDPreviousAllocationPool değerinin geçersiz olduğunu ve rIDNextRID değerinin 0 göründüğünü ortaya çıkardı. Kök nedeni araştırdığımızda, domaindeki ikinci Domain Controller olan W25ADC‘nin kapalı olduğunu ve bu yüzden RID Master W25DC ile replikasyon yapamadığını gördük. W25ADC‘yi tekrar açıp repadmin /replsummary ile replikasyonun hatasız tamamlandığını doğruladıktan sonra, dcdiag /test:ridmanager /v passed test RidManager sonucunu verdi ve New-ADUser komutu sorunsuz çalıştı. Bu, canary tekniğiyle doğrudan ilgili olmasa da, gerçek bir Active Directory ortamında ikinci bir Domain Controller’ın kapalı kalmasının RID havuzu tahsisini nasıl kilitleyebileceğini gösteren değerli bir yan bulgu oldu.
Nesnenin oluşturulduğunu ve öznitelik değerlerini doğruladık:
Buradaki ObjectGUID (22c15fca-ca1f-490b-b8d2-ae752c203a48) değeri, ilerleyen adımlarda SIEM’e alınacak ve Event ID 4662 olaylarıyla eşleştirilecek olan kritik tanımlayıcıdır.
2. Adım – Everyone Grubuna Okuma Erişimini Reddetme (Deny ACE)
Canary nesnesinin ACL’sine (Access Control List), Everyone güvenlik grubu için GenericRead iznini reddeden bir ACE (Access Control Entry) ekledik. Bunu PowerShell’de System.DirectoryServices ile, hedef nesnenin ObjectSecurity özelliğine bir ActiveDirectoryAccessRule (Deny türünde) ekleyerek yaptık:
$canaryDN = (Get-ADUser canary01).DistinguishedName
$canary = [ADSI]"LDAP://$canaryDN"
$everyoneSid = New-Object System.Security.Principal.SecurityIdentifier("S-1-1-0")
$denyRule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
$everyoneSid,
[System.DirectoryServices.ActiveDirectoryRights]::GenericRead,
[System.Security.AccessControl.AccessControlType]::Deny
)
$canary.ObjectSecurity.AddAccessRule($denyRule)
$canary.CommitChanges()
Komut hatasız tamamlandı ve ACE (Access Control Entry) güncellendi.
Gerçek bulgu kendi kendini kilitleme:
ACE (Access Control Entry) değişikliğinin ardından, ACL’yi (Access Control Entry) doğrulamak için Administrator hesabıyla canary nesnesini tekrar okumaya çalıştığımızda, Get-ADUser canary01 komutu bile Cannot find an object with identity: 'canary01' hatası verdi. Domain Admin ve nesnenin sahibi (owner) olan Administrator hesabı da dahil olmak üzere kimse artık nesneyi normal yollarla okuyamıyordu. Bunun nedeni, Administrator hesabının da Everyone grubunun bir üyesi olması ve Windows ACE (Access Control Entry) değerlendirmesinde açık (explicit) Deny kurallarının, ayrıcalık seviyesinden bağımsız olarak açık Allow kurallarından önce değerlendirilmesidir. Bu, raporun canary objeler için tarif ettiği mekanizmanın (Everyone güvenlik grubu üzerinden tüm kullanıcı nesnelerine okuma erişimini reddetme) tam olarak beklendiği gibi çalıştığının kanıtıydı sadece hedeflenen saldırganları değil, gerçekten herkesi engelliyordu:
Erişimi geri kazanmak için dsacls.exe kullandık bu araç yalnızca DACL’yi (Discretionary Access Control List) yönetir ve WRITE_DAC hakkını doğrudan kullandığı için, tam bir nesne bağlama/okuma gerektiren [ADSI]/DirectoryEntry erişiminin aksine, Deny kuralı tarafından engellenmedi:
dsacls "CN=Canary01,OU=LAPS,DC=bakicubuk,DC=local" /R "Everyone"Bu komutla Deny kuralını kaldırdıktan sonra Get-ADUser canary01 tekrar başarılı oldu ve normal erişim geri geldi.
3. Adım – Directory Service Access Denetimini Etkinleştirme
Bu alt kategori için hem Success hem Failure denetimini açtık:
auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable
Gerçek bulgu – denetim alt kategorisi tek başına yeterli değil:
Bu noktada sadece auditpol alt kategorisini etkinleştirmenin Event ID 4662 üretmek için yeterli olmadığını keşfettik bu, Bölüm 18‘de msDS-KeyCredentialLink ve Event 5136 için karşılaştığımız sorunla birebir aynıydı. Microsoft Learn dokümantasyonunun da doğruladığı gibi, denetim olayları yalnızca yapılandırılmış bir SACL’e (System Access Control List) sahip nesnelerde ve bu nesneler SACL (System Access Control List) ayarlarıyla eşleşen bir şekilde erişildiğinde üretilir. Yani nesne düzeyinde ayrıca bir SACL (System Access Control List) yapılandırmamız gerekiyordu.
Bunu yaparken üç ayrı teknik engelle karşılaştık: dsacls yalnızca DACL’yi (Discretionary Access Control List) yönetebiliyor, SACL’ye (System Access Control List) dokunamıyor. DirectoryEntry.ObjectSecurity özelliği varsayılan olarak yalnızca DACL’yi (Discretionary Access Control List) getiriyor; SACL’yi (System Access Control List) okuyabilmek/yazabilmek için .ObjectSecurity‘ye ilk erişimden önce Options.SecurityMasks değerine Sacl bayrağının eklenmesi gerekiyor. Son olarak, Options.SecurityMasks özelliğine doğrudan atama yapmaya çalıştığımızda (“$canary.Options.SecurityMasks = ...“) PowerShell’in COM (Component Object Model) etkileşim katmanı üzerinden dinamik bağlama nedeniyle “property not found” hatası aldık. Çözüm, Options nesnesini açıkça DirectoryEntryConfiguration türüne tür dönüştürmekten (cast) geçti:
$canaryDN = (Get-ADUser canary01).DistinguishedName
$canary = [ADSI]"LDAP://$canaryDN"
[System.DirectoryServices.DirectoryEntryConfiguration]$secOptions = $canary.get_Options()
$secOptions.SecurityMasks = [System.DirectoryServices.SecurityMasks]"Dacl, Sacl"
$everyoneSid = New-Object System.Security.Principal.SecurityIdentifier("S-1-1-0")
$auditRule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
$everyoneSid,
[System.DirectoryServices.ActiveDirectoryRights]::GenericRead,
"Success, Failure"
)
$canary.ObjectSecurity.AddAuditRule($auditRule)
$canary.CommitChanges()Bu son kombinasyon hatasız çalıştı. Ardından Deny ACE’yi (2. Adım’daki script ile) tekrar ekleyerek canary nesnesini yeniden kilitledik – artık hem Deny kuralı hem de nesne düzeyinde SACL yerinde olduğu için tespit mekanizması tam olarak yapılandırılmıştı.
4. Adım – Canary Tetikleme ve Event ID 4662 Doğrulaması
Farklı bir kullanıcı bağlamından (nihat.cubuk ile) canary nesnesini okumaya çalıştık:
Get-ADUser canary01
Beklendiği gibi erişim reddedildi. Ardından W25DC‘nin Security Log’unu kontrol ettik:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662} -MaxEvents 5 | Format-List
Sonuç, raporun önerdiği tespit mekanizmasının gerçekten çalıştığının nihai kanıtı oldu: Account Name: nihat.cubuk, Object Name: %{22c15fca-ca1f-490b-b8d2-ae752c203a48} (canary01’in tam GUID’i ile eşleşiyor), Operation Type: Object Access, Accesses: Read Property, Access Mask: 0x10. Bir SIEM’e bu GUID için önceden tanımlanmış bir uyarı kuralı eklendiğinde, bu tek olay tek başına bir Active Directory numaralandırma girişimine dair yüksek güvenilirlikli, doğrudan bir uyarı üretecektir olay ilişkilendirmesi veya karmaşık korelasyon kurallarına gerek kalmadan.
Lab Uygulamasından Çıkarımlar
Bu lab uygulaması, raporun canary objeler için tarif ettiği tekniğin iki yönünü de doğruladı: hem Everyone/GenericRead üzerine kurulu Deny mekanizmasının gerçekten herkesi (Administrator dahil) engellediğini, hem de doğru yapılandırılmış bir SACL ile bu engelleme girişimlerinin Event ID 4662 olarak güvenilir şekilde yakalandığını gördük. Ayrıca, denetim alt kategorisinin tek başına yeterli olmadığı ve nesne düzeyinde ayrı bir SACL yapılandırması gerektiği – Bölüm 18’de karşılaştığımız aynı dersin bir tekrarı – bu bölümün en pratik operasyonel bulgusu oldu.
Serinin Özeti: Mitigasyon Kontrol Listesi
Aşağıdaki tablo, serinin 1-18. bölümlerinde ele alınan her tekniğin en kritik mitigasyonlarını özetliyor. Her satırdaki tam mitigasyon listesi için ilgili bölüme bakılabilir.
| Bölüm | Teknik | Öncelikli Mitigasyonlar |
|---|---|---|
| 1 | Kerberoasting | SPN’li (Service Principal Name) hesaplarda sayıyı minimize etmek, gMSA kullanmak veya 30+ karakterlik yönetilen şifre |
| 2 | AS-REP Roasting | Kerberos ön kimlik doğrulamasını (pre-authentication) zorunlu kılmak, istisnalara minimum ayrıcalık vermek |
| 3 | Password Spraying | Uzun/yönetilen şifreler, 5 hatalı denemede kilitleme, NTLM’i devre dışı bırakmak |
| 4 | MachineAccountQuota | ms-DS-MachineAccountQuota değerini sıfırlamak, Domain Computers grubunun yazma yetkisini kısıtlamak |
| 5 | Unconstrained Delegation | Bilgisayar nesnelerinde unconstrained delegation’ı kaldırmak, ayrıcalıklı hesapları Protected Users grubuna almak |
| 6 | Password in GPP | Tüm GPP şifrelerini kaldırmak, KB2962486 yamasını uygulamak |
| 7 | AD CS (ESC1) | ‘Enrollee Supplies Subject’ bayrağını kaldırmak, sertifika şablonu izinlerini kısıtlamak |
| 8 | Golden Certificate | AD CS CA’lar için MFA (multi-factor authentication – çok faktörlü kimlik doğrulama), HSM (hardware security module – donanımsal güvenlik modülü) ile anahtar koruması, uygulama denetimi |
| 9 | DCSync | DCSync izinli hesap sayısını minimize etmek, bu hesapların SPN’li (Service Principal Name) olmamasını sağlamak, NTLMv1’i devre dışı bırakmak |
| 10 | Dumping ntds.dit | Domain Controller erişimini kısıtlamak, Print Spooler ve SMBv1’i devre dışı bırakmak |
| 11 | Golden Ticket | KRBTGT şifresini her 6 ayda bir (veya şüpheli ele geçirmede) değiştirmek |
| 12 | Silver Ticket | Bilgisayar nesnesi şifrelerini 30 günde bir değiştirmek, SPN’li (Service Principal Name) hesapları gMSA yapmak |
| 13 | Golden SAML | AD FS servis hesabını gMSA yapmak, token imzalama sertifikalarını 12 ayda bir döndürmek |
| 14 | Entra Connect | Hard/soft match takeover’ı devre dışı bırakmak, ayrıcalıklı hesapları senkronize etmemek |
| 15 | One-Way Trust Bypass | Domain Controller erişimini kısıtlamak, günlükleri merkezi analiz etmek |
| 16 | SID History | sIDHistory özniteliğinin kullanılmadığından emin olmak, haftalık kontrol, SID Filtering’i etkinleştirmek |
| 17 | Skeleton Key | LSASS sürecini korumalı modda (RunAsPPL) çalıştırmak, imzasız sürücüleri engellemek |
| 18 | Shadow Credentials | Key Admins/Enterprise Key Admins üyeliğini kısıtlamak, msDS-KeyCredentialLink değişikliklerini düzenli incelemek |
Serinin Özeti: Olay ID (Event ID) Master Tablosu
Aşağıdaki tablo, seri boyunca kullandığımız temel Event ID’leri, hangi teknik(ler)i tespit ettiklerini ve ilgili bölümü bir arada listeliyor.
| Event ID | Kaynak Teknik(ler) | Bölüm | Açıklama |
|---|---|---|---|
| 1102 | Dumping ntds.dit, One-Way Trust Bypass, SID History, Skeleton Key | 10, 15, 16, 17 | Security denetim günlüğü temizlendi |
| 2889 | Password Spraying | 3 | İmzasız LDAP bind denemesi |
| 3033 / 3063 | Skeleton Key | 17 | İmzasız veya güvensiz sürücü yüklenemedi |
| 4103 / 4104 | Dumping ntds.dit, One-Way Trust Bypass, SID History, Skeleton Key, Golden SAML, Entra Connect | 10, 13, 14, 15, 16, 17 | PowerShell modül/script blok günlüğü |
| 4624 | Password Spraying, MachineAccountQuota, Unconstrained Delegation, Silver Ticket | 3, 4, 5, 12 | Hesap başarıyla oturum açtı |
| 4625 | AS-REP Roasting, Password Spraying | 2, 3 | Hesap oturum açamadı |
| 4656 / 4663 | Dumping ntds.dit, Skeleton Key | 10, 17 | Nesneye erişim istendi/denendi |
| 4662 | DCSync, Golden SAML, Canary Objeler | 9, 13, 19 | Nesne üzerinde işlem gerçekleştirildi |
| 4674 | AD CS (ESC1) | 7 | Ayrıcalıklı nesne üzerinde işlem denendi |
| 4675 | SID History (domain hopping) | 16 | SID’ler filtrelendi |
| 4738 | Kerberoasting, AS-REP Roasting, SID History | 1, 2, 16 | Kullanıcı hesabı değiştirildi |
| 4768 | AS-REP Roasting, AD CS, Golden Ticket, One-Way Trust Bypass | 2, 7, 11, 15 | Kerberos TGT (Ticket Granting Ticket) istendi |
| 4769 | Kerberoasting, Golden Ticket | 1, 11 | TGS (Ticket Granting Service) istendi |
| 5136 | Kerberoasting, AS-REP Roasting, Shadow Credentials | 1, 2, 18 | Dizin hizmeti nesnesi değiştirildi |
| 39/40/41 | AD CS | 7, 8 | KDC (Key Distribution Center) sertifika eşleme sorunları |
| 4876/4886/4887/4899/4900 | AD CS, Golden Certificate | 7, 8 | Sertifika hizmeti istekleri ve şablon değişiklikleri |
| 70/307/510/1007/1200/1202 | Golden SAML | 13 | AD FS federasyon yapılandırma ve token olayları |
| 611/650/651/656/657 | Microsoft Entra Connect | 14 | Parola senkronizasyonu (PHS) olayları |
Uyumluluk ve Çerçeve Eşlemesi Tablosu
| Çerçeve | İlgili Kontrol/Madde |
|---|---|
| PCI DSS | Gereksinim 7.1 (Erişim kısıtlaması), Gereksinim 10.2 (Denetim izleri) |
| HIPAA | 164.312(a)(1) – Erişim Kontrolü, 164.312(b) – Denetim Kontrolleri |
| ISO 27001 | A.9.2 (Kullanıcı Erişim Yönetimi), A.12.4 (Günlükleme ve İzleme) |
| KVKK | Madde 12 – Veri Güvenliğine İlişkin Yükümlülükler |
| TCMB | Bilgi Sistemleri Yönetimi Tebliğ – Erişim ve Yetkilendirme Kontrolleri |
| NIST CSF | PR.AC-4 (Erişim izinleri ve yetkilendirmeleri yönetilir), DE.CM-1 (Ağ izlenir) |
| CIS Controls | CIS 5 (Hesap Yönetimi), CIS 6 (Erişim Kontrol Yönetimi) |
MITRE ATT&CK: T1087 (Account Discovery), T1482 (Domain Trust Discovery) canary objelerin doğrudan hedef aldığı numaralandırma (enumeration) davranışı
Sonuç
Bu seri boyunca 18 farklı Active Directory ele geçirme tekniğini kendi iki forest lab ortamımızda (bakicubuk.local / nihatcubuk.local, Windows Server 2025) canlı olarak test ettik. Bazı teknikler (Skeleton Key, Shadow Credentials, Golden Ticket, Silver Ticket) beklendiği gibi çalıştı ve mitigasyonların (LSA koruması gibi) gerçekten etkili olduğunu doğruladık. Diğerlerinde (SID History enjeksiyonu gibi) modern Windows Server 2025 ortamının eski teknikleri artık büyük ölçüde engellediğini gördük bu da raporun temel mesajını doğrulayan güçlü bir bulgu oldu.
Bu son bölümde ele aldığımız canary objeler tekniği, serinin genelinde işlediğimiz teknik bazlı, olay korelasyonuna dayalı tespit yöntemlerini tamamlayan, daha basit ve daha güvenilir bir erken uyarı katmanı sunuyor. Ancak yukarıdaki sınırlamada belirttiğimiz gibi, tek başına yeterli değil gerçek bir savunma derinliği (defense in depth) stratejisi, bu 19 bölümde işlediğimiz mitigasyonların, tespit mekanizmalarının ve canary objelerin birlikte, katmanlı şekilde uygulanmasını gerektiriyor.
Serinin tamamına ve kaynak rapora bu blogdaki ilgili yazılardan ulaşılabilir. Okuduğunuz için teşekkürler.
