Active Directory Odaklı Red Team'de En Sık Zincirlenen Zafiyetler · AD Red Team

Bir kurumun iç ağında standart bir domain kullanıcısına ait erişim elde edildiğini düşünelim. Kullanıcının Domain Admin üyeliği yok. İş istasyonunda local admin yetkisi bulunmuyor. Domain controller güncel, EDR kurulu ve internete doğrudan açık bir yönetim servisi de görünmüyor.

İlk bakışta saldırganın ilerleyemeyeceği düşünülebilir.

Fakat aynı kullanıcı, yıllar önce açılmış bir service account için Kerberos service ticket isteyebiliyor. Service account zayıf ve uzun süredir değiştirilmemiş bir parola kullanıyor. Hesap bir uygulama sunucusunda local admin. O sunucuda yakın zamanda oturum açmış operasyon hesabının credential materyali bulunuyor. Operasyon hesabı doğrudan Domain Admin değil fakat bir Group Policy Object üzerinde edit yetkisine sahip. İlgili GPO, domain controller dışındaki yüzlerce sunucuya uygulanıyor ve bu sunuculardan biri Entra Connect yönetim ağına erişebiliyor.

Bu senaryoda kritik sonuç tek bir yüksek severity zafiyetten doğmaz. Birbiriyle ilişkilendirilmeyen beş ayrı karar, düşük yetkili bir identity'den identity control plane'e uzanan attack path oluşturur.

Rapor yalnız “zayıf service account parolası bulundu” derse gerçek risk eksik anlatılır. Yalnız “GPO yetkileri fazla geniş” denirse de yönetim, düzeltme sırasını belirleyemez. Active Directory odaklı Red Team çalışmasının görevi bu parçaları toplamak, gerçekten kullanılabilir zinciri kontrollü biçimde doğrulamak ve savunmanın zincirin hangi aşamasında görünürlük kaybettiğini göstermektir.

Bu yazıda AD red team yaklaşımını saldırı komutları üzerinden değil, attack path mantığı, güvenli doğrulama, detection engineering ve kalıcı remediation üzerinden ele alacağız.

Active Directory odaklı Red Team nedir?

Active Directory odaklı Red Team, kurumun identity control plane'ine yönelik gerçekçi adversary behavior'ları belirli bir objective çerçevesinde simüle eden çalışmadır. Objective, “mümkün olan her sistemi ele geçirmek” gibi sınırsız bir hedef değildir. Ölçülebilir ve iş etkisine bağlanabilir olmalıdır.

Örnek objective'ler şunlardır:

• Standart bir domain user erişiminden Tier 0 yönetim yetkisine ulaşılabiliyor mu?
• Workstation katmanındaki compromise, server veya identity control plane katmanına taşınabiliyor mu?
• Bir service account compromise edildiğinde kritik ERP sistemine veya yedekleme altyapısına erişim oluşuyor mu?
• AD CS üzerindeki enrollment ve template kontrolleri ayrıcalıklı bir identity'nin impersonation riskini engelliyor mu?
• SOC, Kerberos abuse, directory object modification ve şüpheli lateral movement zincirini tek bir incident olarak ilişkilendirebiliyor mu?
• On-premises AD compromise, Entra ID veya Microsoft 365 yönetim düzlemine etki edebiliyor mu?

Bu soruların tamamı Active Directory ile ilgilidir fakat aynı test tekniğini gerektirmez. Bazısı assumed breach ile başlar. Bazısı endpoint compromise gerektirir. Bazısı yalnız güvenli configuration validation ile kanıtlanabilir. Bazısında production üzerinde aktif doğrulama kabul edilemez ve ayrılmış test identity'si gerekir.

Red Team nedir kapsamlı rehberimizde açıkladığımız gibi çalışma, araç listesi değil ölçüm tasarımıdır. Active Directory yalnız teknik scope'un adı değildir. Kurumun kimlik, yetki, yönetim ve güven ilişkilerinin birleştiği control plane'dir.

AD security assessment ile AD Red Team aynı çalışma değildir

Bir AD security assessment genellikle yapılandırmaları, hesapları, protokolleri, trust ilişkilerini, privileged group üyeliklerini ve hardening seviyesini geniş bir envanter üzerinden değerlendirir. Amaç mümkün olduğunca çok riskli durumu tespit etmektir.

AD Red Team ise seçilmiş bir threat scenario içinde ilerler. Her misconfiguration'ı bulmayı taahhüt etmez. Belirli bir başlangıç noktasından belirli bir objective'e ulaşılıp ulaşılamadığını ve savunmanın bu ilerlemeyi nasıl karşıladığını ölçer.

İki çalışma birbirinin alternatifi değildir. Olgun kurumlarda assessment geniş attack surface'i çıkarır, Red Team yüksek değerli path'leri doğrular, Purple Team ise detection ve response iyileştirmelerini tekrar oynatır.

Active Directory'de neden tek zafiyetten çok attack path önemlidir?

Active Directory bir graph gibi düşünülebilir.

• User, group, computer, service account, GPO, OU, certificate template ve domain birer node'dur.
• Group membership, local admin, session, delegation, enrollment, object control ve replication right birer edge'dir.
• Bir edge tek başına kritik görünmeyebilir.
• Birden fazla edge birleştiğinde Tier 0'a ulaşan yol oluşabilir.

Örneğin help desk grubunun bir workstation OU'sunda local admin olması normal kabul edilebilir. Aynı help desk hesabının server yönetiminde kullanılması ayrı bir operational shortcut olabilir. Privileged bir yöneticinin help desk tarafından yönetilen cihaza oturum açması da münferit olay gibi görülebilir. Bu üç durum birleştiğinde credential exposure ve tier geçişi meydana gelir.

Bu nedenle gerçek risk şu basit ifadeyle temsil edilemez:

Risk = en yüksek CVSS skoru

AD attack path için daha doğru düşünme biçimi şöyledir:

Path risk = başlangıç erişilebilirliği
          × edge kullanılabilirliği
          × hedefin iş kritikliği
          × privilege artışı
          × detection ve containment boşluğu

Bu matematiksel bir standart değildir. Ekiplerin risk konuşmasını doğru eksene taşımak için kullanılan bir modeldir. Bir attack path'in pratik riski, graph üzerinde var olmasından fazlasıdır. Gerekli ön koşullar, zaman, erişim, operasyonel gürültü, güvenlik kontrolleri ve iş etkisi birlikte değerlendirilmelidir.

Attack path varlığı ile exploitability aynı şey değildir

Graph tabanlı analiz araçları önemli bir görünürlük sağlar fakat çizilen her yol fiilen çalışmaz. Stale data, çözümlenmemiş nested membership, kapalı firewall yolu, artık kullanılmayan session bilgisi veya uygulanmayan GPO bir false path üretebilir.

Tersi de mümkündür. Araçta görünmeyen business context, bir edge'i beklenenden daha değerli yapabilir. Örneğin “uygulama yönetim sunucusu” olarak görülen bir sistem gerçekte tüm üretim credential'larının dağıtıldığı orchestration noktası olabilir.

Red Team şu üç soruyu ayırır:

1. 1Teorik path: Directory ilişkileri bu yolu mümkün gösteriyor mu?
2. 2Pratik path: Network, host ve authentication koşulları yolun ilerlemesine izin veriyor mu?
3. 3Operasyonel path: Gerçek adversary bu yolu kabul edilebilir maliyet ve gürültüyle kullanabilir mi?

Rapor yalnız graph ekran görüntüsü sunmamalı, bu üç seviyenin hangisinin doğrulandığını açıkça yazmalıdır.

AD Red Team kapsamı nasıl belirlenir?

Active Directory gibi merkezi bir sistemde “iç ağ dahil” ifadesi yeterli scope tanımı değildir. Scope, hem teknik sınırları hem de korunacak iş süreçlerini açıkça göstermelidir.

En az şu varlıklar konuşulmalıdır

• Forest ve domain sayısı
• Child domain ve external trust ilişkileri
• Domain controller'lar ve Read-Only Domain Controller kullanımı
• AD Sites and Services topolojisi
• Privileged Access Workstation ve jump server yapısı
• Windows client ve server segmentleri
• AD CS, CA hierarchy, enrollment endpoint'leri ve certificate template'ler
• Entra Connect, Cloud Sync, AD FS, Application Proxy ve password writeback bileşenleri
• PAM, password vault, Windows LAPS ve gMSA kullanımı
• Backup, virtualization, endpoint management ve software deployment altyapısı
• SIEM, EDR, Microsoft Defender for Identity ve network telemetry kapsamı
• Kritik uygulamalar, service account'lar ve Tier 0'a dolaylı etki eden platformlar

Başlangıç koşulu açık yazılmalıdır

Üç yaygın model vardır:

Assumed breach, Red Team'in “kolaylaştırılmış” biçimi değildir. Initial access başarısını denklemden çıkarıp internal identity controls, segmentation ve SOC görünürlüğüne daha fazla zaman ayırır.

Rules of Engagement güvenli kanıtın sınırını belirler

AD Red Team'de aşağıdaki eylemler varsayılan olarak serbest kabul edilmemelidir:

• Gerçek kullanıcı parolalarını değiştirmek
• Production account'a kalıcı MFA veya authentication method eklemek
• Domain Admins gibi kritik gruplara izinsiz üye eklemek
• Tüm domain hash'lerini toplamak
• KRBTGT materyalini almak veya ticket forging uygulamak
• Root CA private key'e erişmek ya da sertifika üretmek
• Production GPO üzerinden komut dağıtmak
• Domain controller üzerinde service interruption riski oluşturmak
• Gerçek backup, EDR, SIEM veya identity controls'u devre dışı bırakmak
• Kullanıcı mailbox veya dosya içeriğini gereksiz yere görüntülemek

Doğrulama için canary account, ayrılmış test OU, kontrollü share, hash yerine fingerprint ve path ownership kanıtı kullanılabilir. Red Team senaryosu nasıl yazılır rehberimiz, objective, constraint ve success criteria'nın engagement başlamadan önce nasıl tanımlanacağını ayrıntılı biçimde ele alır.

En sık görülen AD Red Team zincirlerinin ortak anatomisi

Sahadaki zincirler birbirinden farklı görünse de çoğu aşağıdaki aşamalardan geçer:

Önemli nokta şudur: Bir aşamadaki çıktı, bir sonrakinin girdisidir. Service account parolası bulmak tek başına sonuç değildir. O hesabın hangi hostlara, application pool'lara, database'lere, group'lara ve management plane'lere eriştiği belirlenmeden zincir tamamlanmaz.

1. Service account + Kerberoasting + ayrıcalıklı erişim zinciri

Kerberoasting, Active Directory ortamlarında en çok bilinen Credential Access tekniklerinden biridir. MITRE ATT&CK bunu T1558.003 olarak sınıflandırır. Geçerli bir domain identity, SPN ile ilişkilendirilmiş service account için Kerberos service ticket isteyebilir. Ticket'ın service account secret'ı ile korunan bölümü offline parola tahminine konu olabilir.

Risk yalnız RC4 kullanımından ibaret değildir. AES kullanımı riski azaltır fakat zayıf parola kullanan, yüksek yetkili ve geniş alanda çalışan klasik service account yapısını güvenli hale getirmez. Zincirin tehlikesi şu koşullar birleştiğinde büyür:

• Account bir veya daha fazla SPN taşıyor
• Parola insan tarafından oluşturulmuş veya başka yerde kullanılmış
• Password never expires etkin
• Parola yaşı çok yüksek
• RC4 halen kullanılabiliyor
• Account local admin, database owner veya application administrator
• Account privileged group'a doğrudan ya da nested üye
• Aynı identity birden fazla service ve environment için kullanılıyor
• Normal service ticket davranışı için baseline bulunmuyor

Microsoft, 2026 guidance'ında RC4 kullanımının tespit edilmesini ve mümkün olan ortamlarda kapatılmasını öneriyor. Ancak uzun vadeli çözüm yalnız encryption type değiştirmek değildir. Uygun workload'larda gMSA veya yeni dMSA modelleri, otomatik secret rotation ve daha dar entitlement gerekir.

Savunma amaçlı service account envanteri

Aşağıdaki PowerShell örneği parola materyali toplamaz. SPN taşıyan user account'ları review etmek için read-only bir envanter üretir:

Import-Module ActiveDirectory

$query = @{
  LDAPFilter = '(&(objectCategory=person)(objectClass=user)(servicePrincipalName=*))'
  Properties = @(
    'ServicePrincipalName'
    'PasswordLastSet'
    'PasswordNeverExpires'
    'msDS-SupportedEncryptionTypes'
    'MemberOf'
    'Enabled'
  )
}

Get-ADUser @query |
  Select-Object SamAccountName,
                Enabled,
                PasswordLastSet,
                PasswordNeverExpires,
                msDS-SupportedEncryptionTypes,
                @{Name='SPNCount'; Expression={$_.ServicePrincipalName.Count}},
                @{Name='DirectGroupCount'; Expression={$_.MemberOf.Count}}

Bu çıktı “Kerberoastable account bulundu” diye otomatik kritik bulgu üretmemelidir. Account'ın parola politikası, effective privilege, hangi service'i çalıştırdığı, supported encryption type ve network reachability birlikte incelenmelidir.

Detection tarafında ne izlenmeli?

Kerberos service ticket istekleri normaldir. Bu nedenle Event ID 4769 için yalnız hacim alarmı üretmek gürültülüdür. Daha güçlü analytic şu context'leri birleştirir:

• RC4 0x17 kullanan TGS istekleri
• Tek source account'ın kısa sürede çok sayıda farklı SPN istemesi
• Normalde erişmediği service account'lara yönelmesi
• Workstation'dan server-class SPN'lere sıra dışı istek gelmesi
• Request sonrasında ilgili account ile yeni hostlarda 4624 oturumlarının oluşması
• EDR üzerinde ticket işlemleriyle ilişkili şüpheli process davranışı

Microsoft Sentinel'de connector schema'sına göre uyarlanabilecek örnek bir hunting sorgusu şöyledir:

WindowsEvent
| where EventID == 4769
| extend Account = tostring(EventData.TargetUserName),
         Service = tostring(EventData.ServiceName),
         ClientIP = tostring(EventData.IpAddress),
         EncType = tostring(EventData.TicketEncryptionType)
| where EncType =~ "0x17"
| summarize ServiceCount=dcount(Service),
            Services=make_set(Service, 25),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated)
  by Account, ClientIP, bin(TimeGenerated, 15m)
| where ServiceCount >= 8

Eşik doğrudan production'a kopyalanmamalıdır. Backup, monitoring ve application server'lar yüksek hacimde meşru istek üretebilir. Red Team çıktısı, kurumun kendi baseline'ına uygun analytic geliştirmeye yardımcı olmalıdır.

2. Local admin tekrar kullanımı + privileged session zinciri

Birden fazla endpoint'te aynı local administrator parolasının kullanılması, tek host compromise'ını yatay bir soruna dönüştürür. Windows LAPS'in temel güvenlik faydalarından biri her cihaz için yönetilen ve düzenli dönen unique local admin secret sağlamasıdır.

Fakat LAPS'in “kurulu olması” tek başına yeterli değildir. Aşağıdaki operational boşluklar zinciri açık bırakabilir:

• Policy tüm OU'lara uygulanmıyor
• Legacy LAPS ve Windows LAPS migration'ı yarım kalmış
• Password backup başarısız fakat izlenmiyor
• Decryption right geniş bir help desk grubuna verilmiş
• Password rotation süresi gereğinden uzun
• Account kullanıldıktan sonra rotation tetiklenmiyor
• Aynı domain account birçok cihazda local admin
• Tier 0 yöneticileri düşük güvenli cihazlara interaktif oturum açıyor

Bu zincirde ilk problem local privilege olabilir. Asıl sıçrama, ele geçirilen host üzerinde daha yüksek yetkili identity'nin session, token veya credential materyalinin bulunmasıyla gerçekleşir.

Tier violation neden kritik?

Microsoft'un güncel Tier Model tanımında Tier 0, directory service'i ve enterprise-wide yetkileri doğrudan veya dolaylı kontrol eden identity ve varlıkları kapsar. Tier 0 account'ın Tier 1 veya workstation üzerinde oturum açması, alt katmandaki compromise'ın üst katmana taşınmasına neden olabilir.

Bu yüzden yalnız şu soru sorulmamalıdır:

Bu sunucuda kim local admin?

Şu sorular da cevaplanmalıdır:

Bu sunucuya son 30 günde hangi privileged identity'ler oturum açtı?
Bu identity'ler başka hangi control plane'leri yönetiyor?
Bu host'ta credential protection gerçekten etkin mi?
Remote administration yalnız hardened jump host üzerinden mi yapılıyor?

Remediation

• Windows LAPS coverage ve rotation health merkezi olarak izlenmeli
• Local admin entitlement cihaz sınıfına göre sınırlandırılmalı
• Tier 0 hesapları alt tier hostlara logon deny policy ile engellenmeli
• Privileged işlem için ayrı account ve hardened workstation kullanılmalı
• Credential Guard ve uygun endpoint protections devreye alınmalı
• Reused domain admin veya server admin account modeli kaldırılmalı
• Interactive, network, batch ve service logon hakları role göre ayrılmalı

3. Kerberos delegation + ayrıcalıklı oturum zinciri

Delegation, bir service'in kullanıcı adına başka bir service'e erişebilmesini sağlar. İş gereksinimi meşrudur. Risk, delegation scope'unun genişliği ve ilgili account ya da computer object'sinin compromise edilmesiyle ortaya çıkar.

Unconstrained delegation

Unconstrained delegation etkin bir host, kendisine gelen uygun Kerberos authentication context'i üzerinden başka service'lere erişim için kullanılabilecek materyali tutabilir. Bu host üzerinde yüksek yetkili bir kullanıcının authentication gerçekleştirmesi, host compromise'ını önemli ölçüde büyütebilir.

Domain controller'lar özel bir role sahip olsa da business server'larda unconstrained delegation bulunması istisna olarak ele alınmalıdır. “Uygulama çalışmıyor” gerekçesiyle yıllar önce açılan delegation ayarı, sonraki mimari değişikliklerle Tier 0 attack path'e dönüşebilir.

Constrained delegation

Kerberos Constrained Delegation, service'in hangi downstream service'lere kullanıcı adına erişebileceğini sınırlar. Unconstrained delegation'a göre daha dar bir modeldir fakat ilgili principal compromise edildiğinde izin verilen hedefler hâlâ risk altındadır. Protocol transition ve “use any authentication protocol” gibi ayarlar ayrıca incelenmelidir.

Resource-Based Constrained Delegation

RBCD'de hangi principal'ın delegation yapabileceği resource tarafındaki msDS-AllowedToActOnBehalfOfOtherIdentity attribute'u üzerinden belirlenir. Buradaki attack path çoğu zaman delegation ayarının kendisinden önce başlar. Bir computer object üzerinde bu attribute'u değiştirebilen principal, yeni bir privilege escalation edge oluşturabilir.

Read-only delegation envanteri

Import-Module ActiveDirectory

$unconstrainedQuery = @{
  LDAPFilter = '(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))'
  Properties = @('DNSHostName', 'OperatingSystem', 'userAccountControl')
}

$rbcdQuery = @{
  LDAPFilter = '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)'
  Properties = @('DNSHostName', 'msDS-AllowedToActOnBehalfOfOtherIdentity')
}

$unconstrained = Get-ADComputer @unconstrainedQuery
$rbcd = Get-ADComputer @rbcdQuery

$unconstrained | Select-Object Name, DNSHostName, OperatingSystem
$rbcd | Select-Object Name, DNSHostName

Bu envanter yalnız işaretleyicidir. Her delegation kaydı için owner, business need, source principal, target service, tier ve change history incelenmelidir.

Detection noktaları

• msDS-AllowedToActOnBehalfOfOtherIdentity değişiklikleri
• userAccountControl üzerinde delegation bit değişiklikleri
• Service account veya computer account SPN değişiklikleri
• Beklenmeyen source host'tan S4U2Self ve S4U2Proxy davranışları
• Privileged account'ın delegation-enabled host'a authentication yapması
• Aynı zaman penceresinde computer object modification ve yeni service ticket istekleri

4. Tehlikeli ACL + group, GPO veya computer object kontrolü zinciri

Active Directory'de yetki yalnız group membership ile verilmez. Object ACL'leri, bir principal'a hedef object üzerinde doğrudan veya dolaylı kontrol sağlayabilir.

Sık riskli edge'ler şunlardır:

• GenericAll
• GenericWrite
• WriteDACL
• WriteOwner
• Group membership yazma hakkı
• User password reset hakkı
• Computer object attribute yazma hakkı
• GPO edit veya link yönetimi
• OU üzerinde child object oluşturma ve silme
• Certificate template ACL kontrolü
• Domain root üzerinde replication extended rights

Bir help desk grubunun user password reset yetkisi meşru olabilir. Aynı grubun Tier 0 hesaplarını da kapsayan OU üzerinde bu hakka sahip olması privilege boundary'yi bozar. Benzer biçimde bir application team'in kendi GPO'sunu düzenlemesi normaldir. GPO yanlış OU'ya linkliyse veya security filtering genişse bu yetki yüzlerce server üzerinde execution path oluşturabilir.

WriteDACL neden özellikle önemlidir?

WriteDACL, mevcut yetkinin sınırlı görünmesine rağmen object izinlerini değiştirme gücü verir. Bu nedenle “şu anda kritik bir işlem yapamıyor” değerlendirmesi yanıltıcı olabilir. Principal kendi kontrol alanını genişletebilir, başka bir account'a hak verebilir veya persistence edge oluşturabilir.

GPO zinciri

MITRE ATT&CK, Group Policy Modification davranışını T1484.001 altında ele alır. GPO üzerinde write yetkisi, hedeflenen user veya computer kapsamına bağlı olarak scheduled task, startup script, security setting veya service configuration gibi geniş etkiler oluşturabilir.

Production-safe Red Team doğrulaması gerçek kullanıcı ve sunuculara komut dağıtmamalıdır. Bunun yerine:

1. 1GPO write edge'i configuration ve ACL ile doğrulanır.
2. 2GPO'nun link, inheritance, security filtering ve WMI filtering kapsamı hesaplanır.
3. 3Control Team tarafından ayrılan test OU ve canary computer kullanılır.
4. 4Zararsız bir marker veya önceden onaylı configuration değişikliği uygulanır.
5. 5Event, EDR ve SIEM visibility ölçülür.
6. 6Değişiklik geri alınır ve replication tamamlanması doğrulanır.

Directory modification için örnek hunting sorgusu

Event ID 5136, Directory Service object modification için önemli bir kaynaktır. Aşağıdaki KQL, attack path açısından yüksek değer taşıyan bazı attribute değişikliklerini öne çıkarır:

WindowsEvent
| where EventID == 5136
| extend Actor = tostring(EventData.SubjectUserName),
         ObjectDN = tostring(EventData.ObjectDN),
         Attribute = tostring(EventData.AttributeLDAPDisplayName),
         Operation = tostring(EventData.OperationType)
| where Attribute in~ (
    "member",
    "servicePrincipalName",
    "msDS-AllowedToActOnBehalfOfOtherIdentity",
    "userAccountControl",
    "nTSecurityDescriptor",
    "gPLink"
)
| project TimeGenerated, Actor, ObjectDN, Attribute, Operation, Computer

5136 kaydının alınması için uygun auditing ve SACL kapsamı gerekir. Log gelmiyorsa analytic yazmak sorunu çözmez. Önce telemetry prerequisite'i doğrulanmalıdır.

5. AD CS misconfiguration + certificate-based identity zinciri

Active Directory Certificate Services, kurum içi trust modelinin kritik parçalarından biridir. AD CS tarafından üretilen authentication certificate'ları parola gibi kullanılabilir. Bu nedenle yanlış certificate template, geniş enrollment permission veya zayıf CA configuration yalnız PKI problemi değildir. Identity privilege escalation ve persistence problemi olabilir.

MITRE ATT&CK, authentication certificate'larının çalınmasını veya üretilmesini T1649 altında sınıflandırır. Microsoft Defender for Identity de ESC1, ESC2, ESC3, ESC4 ve devam eden certificate risk sınıfları için posture assessment'lar sunar.

En sık karşılaşılan risk sınıfları

ESC numaraları tek başına bulgu değildir. Exploitability, template'ın publish edilmiş olmasına, enrollment right'a, manager approval'a, authorized signatures'a, EKU'ya, subject construction'a ve domain authentication mapping davranışına bağlıdır.

Certificate neden parola resetinden sonra da önemini koruyabilir?

Geçerli bir authentication certificate, validity süresi ve revocation durumuna bağlı olarak parola resetinden bağımsız kullanılabilir. Incident Response yalnız account parolasını değiştirirse certificate tabanlı access devam edebilir. Bu nedenle AD CS chain doğrulandığında containment planı şunları kapsamalıdır:

• Issued certificate inventory
• Serial number ve thumbprint
• Certificate validity ve EKU
• Revocation işlemi ve CRL yayın durumu
• İlgili template ve CA configuration düzeltmesi
• Account authentication event'lerinin geriye dönük incelenmesi
• CA private key etkilenmişse PKI recovery planı

Production-safe doğrulama

Gerçek Domain Admin adına certificate üretmek, “PoC” gerekçesiyle varsayılan doğrulama yöntemi olmamalıdır. Daha güvenli model şöyledir:

• Control Team tarafından canary privileged identity oluşturulur
• Template'ın riskli koşulları read-only incelenir
• Enrollment yalnız canary identity için ve belirlenmiş CA üzerinde test edilir
• Certificate'ın authentication kabiliyeti ayrılmış test resource'una karşı doğrulanır
• Private key export ve saklama sınırları belirlenir
• Certificate hemen revoke edilir
• CA ve identity loglarındaki visibility ölçülür

İzlenmesi gereken telemetry

• Certificate request ve issuance event'leri
• Beklenmeyen requester ile subject veya SAN farklılığı
• Authentication EKU taşıyan yeni template publication
• Template ACL, owner, EKU veya enrollment flag değişikliği
• CA configuration değişiklikleri
• Web enrollment endpoint'ine anormal NTLM authentication
• Certificate ile gerçekleşen beklenmeyen account sign-in'ları
• Private key export veya certificate store access davranışları

6. NTLM relay koşulları + LDAP veya AD CS zinciri

NTLM relay tek bir ürün açığı değildir. Authentication'ın bir service'ten diğerine relay edilebilmesini mümkün kılan protokol ve configuration koşullarının birleşimidir.

AD ortamında risk şu bileşenlerle büyüyebilir:

• SMB signing zorunlu değil
• LDAP signing uygulanmıyor
• LDAP channel binding yetersiz
• AD CS web enrollment HTTPS ve Extended Protection olmadan çalışıyor
• NTLM kullanımı gereksiz ölçüde geniş
• Authentication coercion oluşturabilen service'ler açık
• Network segmentation, source ile yüksek değerli endpoint arasını ayırmıyor
• Computer account veya service account'ın hedef object üzerinde yazma hakkı bulunuyor

Zincir örneği şu şekildedir:

Compromised host
  → controlled authentication attempt
  → relay kabul eden service
  → computer object veya certificate üzerinde yeni yetki
  → Kerberos ya da certificate-based access
  → lateral movement veya privilege escalation

Bu path'i kapatmak için yalnız “NTLM'i kapatın” demek operasyonel olarak yetersiz olabilir. Legacy uygulamalar ve cihazlar dependency oluşturabilir. Güvenli geçiş şu sırayla yapılmalıdır:

1. 1NTLM kullanımını ve source-target ilişkilerini audit edin.
2. 2SMB signing, LDAP signing ve channel binding compatibility'sini ölçün.
3. 3AD CS enrollment endpoint'lerinde HTTPS ve Extended Protection uygulayın.
4. 4Relay riski yüksek segmentler arasında erişimi sınırlandırın.
5. 5Exception'ları owner ve expiry ile yönetin.
6. 6Policy enforcement sonrasında authentication failure ve business impact'i izleyin.

Microsoft, LDAP signing ve channel binding için Directory Service event'leri üzerinden hazırlık ve uyumluluk izlemesi yapılmasını önerir. Red Team, enforcement yapılmadan önce path'i doğrulayabilir. Purple Team ise policy sonrası residual davranışları ve detection'ı yeniden test etmelidir.

7. DCSync hakkı + domain credential exposure zinciri

DCSync, Domain Controller'ın replication API'sini kullanarak başka bir Domain Controller gibi directory replication verisi isteme davranışıdır. MITRE ATT&CK bunu T1003.006 olarak sınıflandırır.

Risk yalnız Domain Admin membership ile oluşmaz. Domain root ACL üzerinde aşağıdaki replication extended rights yanlış principal'lara verilmiş olabilir:

• Replicating Directory Changes
• Replicating Directory Changes All
• Replicating Directory Changes In Filtered Set

Bu haklar migration, identity synchronization, backup veya eski ürün entegrasyonları nedeniyle service account'lara devredilmiş olabilir. Ürün kaldırıldıktan sonra permission kalabilir. Account privileged group'ta görünmediği için klasik üyelik review'unda gözden kaçabilir.

Neden domain dominance kabul edilir?

Replication erişimi, current ve historical password hash'leri dahil kritik directory secret'larına ulaşma potansiyeli oluşturur. KRBTGT materyali gibi değerler persistence ve ticket abuse riskini büyütür. Bu nedenle DCSync-capable principal bir Tier 0 identity olarak ele alınmalıdır.

Güvenli Red Team doğrulaması

Tüm domain account hash'lerini çekmek gereksiz veri toplama ve operasyonel risk yaratır. Daha güvenli kanıt seçenekleri şunlardır:

• Extended right'ın effective permission analizi
• Control Team tarafından oluşturulmuş canary account için sınırlı replication doğrulaması
• Password hash yerine yalnız doğrulama fingerprint'i kaydetme
• DRS trafiğinin yalnız izin verilen source host'tan üretilmesi
• Test sonrasında credential rotation ve artifact cleanup
• SOC'un source host, account ve DRS operation'ı ilişkilendirme başarısının ölçülmesi

DCSync detection

En güçlü network sinyallerinden biri DRS replication davranışının Domain Controller olmayan bir host'tan gelmesidir. Host inventory ile network telemetry ilişkilendirilebiliyorsa yüksek değerli bir analytic üretilebilir.

Directory auditing tarafında Event ID 4662, uygun SACL ile replication right kullanımını gösterebilir. Aşağıdaki GUID'ler environment doğrulamasında önemlidir:

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

Alarm yalnız GUID match etmemelidir. Actor, source host, destination DC, account baseline ve authorized replication principal listesiyle zenginleştirilmelidir.

8. Stale account + nested privilege + zayıf governance zinciri

Stale account, uzun süredir kullanılmadığı için zararsız değildir. Tam tersine owner'ı değişmiş, monitoring'i zayıflamış ve parolası unutulmuş account'lar sessiz attack path oluşturabilir.

Sık görülen örnekler şunlardır:

• İşten ayrılan çalışanın disable edilmemiş ikinci hesabı
• Proje bittikten sonra açık kalan vendor account
• Yıllardır kullanılmayan service account
• Doğrudan privileged görünmeyen fakat nested group üzerinden yetkili user
• Disabled group içinde aktif member veya tersi
• Password never expires kullanan eski automation identity
• Account description, script veya custom attribute içinde credential ipucu
• Kerberos preauthentication kapalı eski account

Microsoft Defender for Identity'nin 2026 posture assessment'ları, 90 gündür oturum açmayan stale account'ları ve AD attribute'larında discoverable password risklerini ayrıca ele alıyor. Bu, identity hygiene'ın yalnız compliance konusu olmadığını gösterir.

Nested membership neden gözden kaçar?

Bir user'ın doğrudan Domain Admins üyesi olmaması güvenli olduğu anlamına gelmez. Group nesting, local group assignment, GPO ve application role birleşimi effective privilege'i yükseltebilir.

Read-only review için:

Import-Module ActiveDirectory

$domainSid = (Get-ADDomain).DomainSID.Value
$forestRoot = (Get-ADForest).RootDomain
$forestRootSid = (Get-ADDomain -Identity $forestRoot).DomainSID.Value

$criticalGroupSids = @(
  "$domainSid-512"      # Domain Admins
  "$forestRootSid-519"  # Enterprise Admins
  "$forestRootSid-518"  # Schema Admins
  'S-1-5-32-544'         # BUILTIN\Administrators
  'S-1-5-32-548'         # Account Operators
  'S-1-5-32-549'         # Server Operators
  'S-1-5-32-551'         # Backup Operators
)

foreach ($sid in $criticalGroupSids) {
  $group = Get-ADGroup -Identity $sid -ErrorAction SilentlyContinue
  if (-not $group) { continue }

  Get-ADGroupMember -Identity $group -Recursive |
    Select-Object @{Name='CriticalGroup'; Expression={$group.Name}},
                  Name, SamAccountName, ObjectClass
}

Bu liste tek başına yeterli değildir. WriteDACL, password reset, GPO edit, LAPS decrypt, virtualization administration ve backup control gibi dolaylı Tier 0 etkileri ayrıca modellenmelidir.

9. GPO, software deployment veya backup control zinciri

Active Directory dominance yalnız Domain Admins grubuyla ölçülmemelidir. Aşağıdaki platformlar Tier 0 üzerinde dolaylı kontrol sağlayabilir:

• Endpoint management ve software deployment
• Virtualization management
• Backup ve recovery altyapısı
• Privileged password vault
• EDR veya remote response console
• DNS, DHCP ve PKI yönetimi
• Configuration management
• Hypervisor veya cloud management plane

Örneğin bir endpoint management service account'ı domain controller'a agent dağıtabiliyorsa account'ın group membership'i düşük görünse bile etkisi Tier 0'dır. Backup operator, offline NTDS verisine erişebiliyorsa benzer risk oluşur. Hypervisor yöneticisi Domain Controller sanal diskine veya snapshot'ına erişebiliyorsa directory permission modelini dolanabilir.

AD Red Team'in önemli katkısı, “AD object” sınırının dışındaki bu control plane ilişkilerini aynı graph içinde göstermesidir.

Remediation önceliği

• Tier 0'a code, configuration, backup veya console erişimi sağlayan tüm platformları Tier 0 envanterine alın
• Bu platformların admin identity'lerini ayrı tutun
• Management traffic'i dedicated segment üzerinden sınırlandırın
• MFA ve phishing-resistant authentication kullanın
• Privileged action loglarını değiştirilemez merkezi alana gönderin
• Break-glass hesaplarını sürekli kullanılan admin hesabına dönüştürmeyin
• Backup restore ve identity recovery prosedürlerini düzenli test edin

10. On-premises AD + hybrid identity zinciri

Birçok kurumda Active Directory artık yalnız on-premises sistemleri yönetmez. Entra Connect, Cloud Sync, AD FS, password writeback ve benzeri bileşenler on-premises identity ile cloud identity arasında güven köprüsü kurar.

Microsoft, Entra Connect server'ını Tier 0 component olarak değerlendirmeyi açıkça önerir. Bunun nedeni yalnız server'ın domain'e üye olması değildir. Sync engine, connector account'lar, credential materyali ve directory write yetkileri hybrid impact oluşturabilir.

Sık riskli durumlar

• Entra Connect server sıradan server OU'sunda ve aynı admin grubu tarafından yönetiliyor
• Tier 1 admin'ler server üzerinde local admin
• EDR veya application allowlisting eksik
• AD DS Connector account izinleri gereğinden geniş
• Legacy MSOL_ account permission'ları migration sonrası kalmış
• Password writeback veya Seamless SSO account'ları yeterince korunmuyor
• Entra privileged account ile on-premises privileged account aynı kişi ve aynı endpoint üzerinde kullanılıyor
• Sync rule değişiklikleri için yeterli change monitoring bulunmuyor
• AD FS token-signing certificate ve service account koruması zayıf
• Hybrid infrastructure logları Tier 0 seviyesinde arşivlenmiyor

On-prem compromise otomatik cloud compromise değildir

Bu önemli bir ayrımdır. Her Domain Admin erişimi doğrudan Global Administrator anlamına gelmez. Etki, sync modeline, account scope'una, federation kullanımına, cloud-only privileged account ayrımına, Conditional Access ve PIM yapılandırmasına bağlıdır.

Rapor şu tür aşırı genellemelerden kaçınmalıdır:

Domain Admin elde edildi, dolayısıyla tüm Microsoft 365 ele geçirildi.

Bunun yerine hangi bridge'in doğrulandığı yazılmalıdır:

Compromised identity, Entra Connect server üzerinde local administration sağladı.
Connector permission analizi on-premises directory write kabiliyetini doğruladı.
Cloud privileged role elde edilmedi.
Hybrid identity impact, ayrılmış canary object ile sınırlandırılarak doğrulandı.

Bu dil hem teknik olarak doğrudur hem yönetimin gerçek risk ile varsayımı ayırmasını sağlar.

11. AS-REP Roasting ve legacy authentication ayarları zinciri

Kerberos preauthentication, normal koşullarda user'ın secret'a sahip olduğunu TGT verilmeden önce kanıtlamasını sağlar. DONT_REQ_PREAUTH flag'i bulunan account'larda AS-REP verisi offline parola tahmini için risk oluşturabilir. MITRE ATT&CK bu davranışı T1558.004 olarak sınıflandırır.

Bu risk çoğunlukla legacy integration veya troubleshooting sırasında bırakılmış account'larda görülür. Tek başına account'ın varlığı domain compromise anlamına gelmez. Zincir için şu context gerekir:

• Account enabled mı?
• Parola yaşı ve politikası nedir?
• Account hangi group ve application yetkilerine sahip?
• Network logon yapabiliyor mu?
• MFA arkasında olmayan başka service'lere erişiyor mu?
• Parola başka environment'ta tekrar kullanılmış olabilir mi?

Read-only inventory:

Import-Module ActiveDirectory

$query = @{
  LDAPFilter = '(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))'
  Properties = @('Enabled', 'PasswordLastSet', 'PasswordNeverExpires', 'MemberOf')
}

Get-ADUser @query |
  Select-Object SamAccountName, Enabled, PasswordLastSet,
                PasswordNeverExpires,
                @{Name='DirectGroupCount'; Expression={$_.MemberOf.Count}}

Remediation, preauthentication'ı etkinleştirmekle başlamalı fakat account'ın gerçek kullanımını doğrulamadan production değişikliği yapılmamalıdır. Legacy dependency varsa owner, expiry ve migration planı tanımlanmalıdır.

Zincirleri tek tabloda nasıl okumalıyız?

Tablodaki her satır teorik bir risk hipotezidir. Red Team'in görevi, RoE kapsamında zincirin hangi edge'lerinin gerçekten çalıştığını ve hangi control'ün ilerlemeyi durdurduğunu kanıtlamaktır.

AD Red Team'de SOC neyi görmelidir?

AD Red Team yalnız attack path bulursa eksik kalır. Savunma değerlendirmesi, her aşamada prevention, telemetry, detection, investigation ve containment ayrımını yapmalıdır.

Gerekli telemetry katmanları

1. 1Domain Controller Security logs: Kerberos, NTLM, group ve object değişiklikleri
2. 2Directory Service logs: LDAP signing, channel binding ve directory diagnostics
3. 3AD CS logs: Request, issuance, denial, template ve CA değişiklikleri
4. 4Endpoint telemetry: Process, LSASS access, token, remote service ve script behavior
5. 5Network telemetry: SMB, LDAP, LDAPS, Kerberos, RPC ve DRS source-target ilişkileri
6. 6Identity analytics: Risky lateral movement path, sensitive account ve abnormal authentication
7. 7Hybrid logs: Entra Connect, AD FS, connector, audit ve sign-in logları
8. 8Change records: Planned admin activity ve approved exception context'i

Temel Windows event haritası

Event listesi detection değildir. Örneğin 4769 her gün milyonlarca kez oluşabilir. Detection, event'i asset criticality, account baseline, source role, sequence ve time window ile anlamlandırır.

Zincir korelasyonu örneği

Tekil alert'ler şu şekilde görünebilir:

10:02  Standard user çok sayıda SPN için TGS istedi
10:47  Aynı user yeni bir server'a oturum açtı
10:51  Server üzerinde privileged logon oluştu
11:03  Bir computer object'in delegation attribute'u değişti
11:09  Yeni target service için Kerberos ticket istendi

Beş alert ayrı queue'lara düşerse analist zinciri kaçırabilir. Red Team raporu yalnız “4769 alarmı gelmedi” dememelidir. Aşağıdaki ölçümleri sunmalıdır:

• Time to first telemetry
• Time to first alert
• Time to triage
• Time to correlate
• Time to declare incident
• Time to contain account
• Time to isolate host
• Time to revoke certificate veya privilege
• Analyst'ın attack path'i doğru kurup kuramadığı

Purple Team, Red Team ve BAS farklarını ele aldığımız yazıda açıkladığımız gibi eksik detection, Purple Team replay ile ölçülebilir ve tekrar edilebilir use case'e dönüştürülmelidir.

Production-safe AD Red Team nasıl yürütülür?

Active Directory merkezi ve stateful bir sistemdir. Küçük bir değişiklik replication ile geniş alana yayılabilir. Bu nedenle güvenli çalışma, “dikkatli olacağız” cümlesinden fazlasını gerektirir.

1. Canary identity ve canary object kullanın

• Canary standard user
• Canary privileged user
• Test computer object
• Ayrılmış test OU
• Test GPO
• Test certificate template veya kontrollü template clone
• İzole file share ve marker object

Bu varlıklar gerçek privilege sınırlarını temsil etmeli fakat production business process'i etkilememelidir.

2. Proof standard'ını önceden belirleyin

3. Stop condition tanımlayın

Örnek stop condition'lar:

• Domain controller health veya replication error oluşması
• Authentication failure rate'in baseline dışına çıkması
• EDR/SOC'un olayı gerçek incident olarak declare etmesi ve containment başlatması
• Canary dışındaki gerçek credential veya kişisel veriye erişim
• Backup, PKI veya identity service availability etkisi
• Scope dışı trust veya tenant bağlantısı görülmesi
• Yetkisiz üçüncü taraf sistemine geçiş riski

4. Cleanup doğrulanabilir olmalı

Cleanup listesi yalnız operator notuna bırakılmamalıdır. Aşağıdaki artefact'lar kayıt altına alınmalıdır:

• Oluşturulan veya değiştirilen account ve group'lar
• Değiştirilen ACL ve attribute'lar
• Issued ve revoked certificate'lar
• GPO ve SYSVOL değişiklikleri
• Scheduled task, service veya remote management artefact'ları
• Uploaded test files
• Temporary firewall veya proxy değişiklikleri
• Token, ticket ve credential rotation gereksinimleri

Her artefact için created_at, owner, purpose, cleanup_action, cleanup_at ve verified_by alanları tutulmalıdır.

artifact:
  id: AD-RT-ART-014
  type: certificate
  subject: CN=canary-ad-admin
  serial_number: "redacted"
  created_at: "2026-08-02T10:14:00+03:00"
  cleanup_action: revoke-and-publish-crl
  cleanup_at: "2026-08-02T10:42:00+03:00"
  verified_by: control-team
  evidence: certificate-status-revoked

AD Red Team raporu nasıl yazılmalıdır?

İyi rapor, on farklı tekil bulguyu yan yana koymaz. Zinciri önce yönetimin anlayacağı iş etkisiyle, sonra teknik ekibin tekrar üretebileceği kanıtlarla açıklar.

Executive narrative

Assumed breach olarak sağlanan standard user ve managed workstation erişimi,
doğrudan privileged group membership içermiyordu.

Service account password governance, server local administration ve GPO
delegation kararları zincirlenerek 4 saat 18 dakika içinde Tier 1 server estate
üzerinde kontrollü execution kabiliyeti doğrulandı.

Tier 0'a geçiş, privileged account logon restriction sayesinde engellendi.
SOC ilk Kerberos anomalisini gördü fakat GPO modification ile aynı incident
altında ilişkilendiremedi. Objective kısmen gerçekleşti.

Bu anlatı üç önemli şeyi aynı anda yapar:

• Hangi path'in kullanıldığını söyler
• Hangi control'ün çalıştığını teslim eder
• Red Team başarısını savunmanın başarısızlığıyla eşitlemez

Her attack path kaydında bulunması gerekenler

1. 1Objective ve business impact
2. 2Starting condition
3. 3Precondition'lar
4. 4Node ve edge sırası
5. 5ATT&CK technique mapping
6. 6Her edge için evidence
7. 7Prevention sonucu
8. 8Telemetry sonucu
9. 9Detection ve response timeline
10. 10Data access ve operational impact
11. 11Cleanup kaydı
12. 12Root cause
13. 13Tactical remediation
14. 14Structural remediation
15. 15Owner ve target date
16. 16Retest acceptance criteria

CVSS neden tek başına yetmez?

CVSS, software vulnerability severity için yararlı olabilir. Fakat AD attack path çoğu zaman CVE olmayan permission ve architecture kararlarından oluşur. “WriteDACL = 9.8” gibi keyfi skor, kurumun düzeltme sırasını yanlış yönlendirebilir.

Daha iyi önceliklendirme şu alanları kullanır:

• Path'in başladığı identity popülasyonu
• Attack complexity ve required access
• Edge'in reliability'si
• Hedef varlığın tier ve business criticality'si
• Blast radius
• Existing compensating control
• Detection ve containment maturity
• Remediation'ın path üzerinde kaç rotayı birden kırdığı

Bir Windows LAPS rollout'u onlarca lateral movement path'ini aynı anda kırabilir. Tek bir stale account'ı kapatmak ise yalnız bir edge'i kaldırabilir. Bu fark aksiyon sırasına yansıtılmalıdır.

Düzeltme sırası nasıl belirlenir?

Her bulguyu severity sırasına dizmek yerine attack path choke point'leri bulunmalıdır. Choke point, birden fazla zincirin geçtiği ortak edge veya node'dur.

İlk 30 gün

• Yetkisiz replication right'ları kaldırın
• Tier 0'a doğrudan etki eden stale ve shared account'ları kapatın
• Tier 0 account logon sınırlarını uygulayın
• Unconstrained delegation kullanan non-DC sistemleri review edin
• Riskli AD CS template'larını unpublish veya sınırlandırın
• Entra Connect ve AD CS'yi Tier 0 asset olarak izole edin
• Domain controller dışından gelen DRS behavior için detection oluşturun
• Windows LAPS coverage boşluklarını çıkarın

30 ile 90 gün

• Service account'ları gMSA veya dMSA'ya taşıyın
• RC4 dependency'lerini azaltın ve AES transition planını tamamlayın
• GPO delegation ve OU inheritance modelini sadeleştirin
• SMB signing, LDAP signing, channel binding ve Extended Protection rollout'unu tamamlayın
• Privileged workstation ve jump host modelini devreye alın
• AD CS template governance ve issuance monitoring kurun
• Nested privilege ve shadow admin review'unu periyodik hale getirin

90 gün ve sonrası

• Identity attack path management'i sürekli programa dönüştürün
• Tier 0 asset inventory'yi on-premises, hybrid ve management plane boyunca güncel tutun
• Detection'ları Purple Team ile tekrar oynatın
• Backup ve forest recovery senaryolarını test edin
• Exception'lara owner, expiry ve compensating control zorunluluğu getirin
• Yeni GPO, template, connector ve service account değişikliklerini CI veya change gate'e bağlayın

AD Red Team sonucunda hangi başarı ölçütleri kullanılmalı?

“Domain Admin olduk” tek başına iyi bir metric değildir. Hatta objective'e ulaşılsa bile güçlü bir savunma bazı aşamalarda doğru çalışmış olabilir.

Attack path metric'leri

• Objective reached, partially reached veya blocked
• Tier transition sayısı
• Doğrulanan critical edge sayısı
• En kısa teorik path ile pratik path arasındaki fark
• Choke point sayısı
• Kullanılan valid account sayısı
• Erişilen asset tier'i ve blast radius

Savunma metric'leri

• Prevention rate
• Telemetry coverage
• Detection coverage
• Mean time to detect
• Mean time to correlate
• Mean time to contain
• Analyst hypothesis accuracy
• Identity ve endpoint alert correlation başarısı
• Cleanup ve recovery süresi

Remediation metric'leri

• Kırılan attack path sayısı
• Kapatılan Tier 0 exposure sayısı
• Stale privileged account azalması
• gMSA/dMSA migration coverage
• Windows LAPS coverage
• RC4 kullanım oranı
• Riskli certificate template sayısı
• Unauthorized replication principal sayısı
• Privileged account tier violation sayısı

Active Directory Red Team hizmeti alırken 12 kontrol maddesi

1. 1Objective yalnız “Domain Admin olmak” olarak mı yazılmış, iş etkisine bağlanmış mı?
2. 2Starting condition full-scope ve assumed breach olarak açıkça ayrılmış mı?
3. 3Forest, trust, AD CS ve hybrid identity bileşenleri scope'ta mı?
4. 4Tier 0 tanımı yalnız Domain Controller'larla mı sınırlı?
5. 5DCSync, GPO, AD CS ve delegation için production-safe proof standard'ı var mı?
6. 6Gerçek kullanıcı secret'larının toplanmasını sınırlayan veri minimizasyonu yaklaşımı var mı?
7. 7Rules of Engagement içinde stop condition ve emergency contact tanımlı mı?
8. 8SOC visibility, detection ve containment ayrı ayrı ölçülüyor mu?
9. 9Attack path graph yalnız tool çıktısı mı, manuel doğrulama içeriyor mu?
10. 10Rapor root cause, choke point ve remediation dependency'lerini gösteriyor mu?
11. 11Cleanup artefact bazında kayıt altına alınıyor mu?
12. 12Retest ve Purple Team replay için kabul kriterleri sunuluyor mu?

SECNODEX'in kurumsal Red Team hizmeti, Active Directory ortamını yalnız configuration checklist üzerinden değerlendirmez. OSCP ve OSWE sertifikalarına sahip uzmanlarımız attack path'leri objective, Rules of Engagement, manuel doğrulama, SOC visibility ve business impact ile birlikte ele alır. Daha sınırlı ve bulgu coverage odaklı bir çalışma gerekiyorsa sızma testi hizmeti ayrı bir engagement olarak planlanmalıdır.

Sonuç: Active Directory'de kritik risk çoğu zaman tek bulguda değil, aradaki bağlantıdadır

Active Directory ortamları genellikle tek bir dramatik zafiyet yüzünden compromise edilmez. Yıllar içinde açılan service account'lar, yarım kalan migration'lar, geniş delegation hakları, yanlış GPO scope'u, unutulmuş certificate template'lar ve tier ihlalleri birbirine bağlanır.

Bu yüzden iyi bir AD Red Team raporu “şu araçla şu teknik çalıştırıldı” anlatısında kalmaz. Standard user'dan hangi edge'lerle ilerlendiğini, hangi control'ün çalıştığını, SOC'un neyi gördüğünü, hangi choke point'in birden fazla yolu kıracağını ve düzeltmenin nasıl doğrulanacağını gösterir.

Red Team ile sızma testi arasındaki farkın araçta değil sorulan soruda başladığını daha önce vurgulamıştık. Active Directory için de aynı ilke geçerlidir. Amaç yalnız Domain Admin olmak değil, kurumun identity control plane'inin gerçek bir adversary karşısında ne kadar dayanıklı olduğunu ölçmektir.

SECNODEX ile Active Directory, AD CS ve hybrid identity attack path'lerinizi objective odaklı bir Red Team engagement'ında değerlendirmek için iletişim sayfamızdan kapsam görüşmesi planlayabilirsiniz.

Kaynaklar

• Microsoft: Best practices for securing Active Directory
• Microsoft: Tier Model for Active Directory Domain Services
• Microsoft: Protected Users security group
• Microsoft: Windows LAPS overview
• Microsoft: Detect and remediate RC4 usage in Kerberos
• Microsoft: LDAP signing for Active Directory Domain Services
• Microsoft: Certificate security posture assessments
• Microsoft: Entra Connect prerequisites and Tier 0 guidance
• MITRE ATT&CK: Kerberoasting T1558.003
• MITRE ATT&CK: DCSync T1003.006
• MITRE ATT&CK: Steal or Forge Authentication Certificates T1649
• MITRE ATT&CK: Group Policy Modification T1484.001
• CISA: Red Team findings for network monitoring and hardening
• CISA and NSA: Top ten cybersecurity misconfigurations