Bir bulguyu değerlendirmek: Önkoşul, etki alanı, kanıt, istisna ve düzeltme.

1. Core Mechanism / Temel mekanizma

Ders önce mekanizma iddiasını, sonra uygulanabilirlik ve iş etkisini ayırır. Artifact bir ACE'in varlığını kanıtlayabilir; o ACE'in her principal için etkili olduğunu, ağ yolunun açık olduğunu veya üretim etkisinin gerçekleştiğini tek başına kanıtlayamaz.

Arabirimler ve belirtimler

• precondition: finding'in uygulanması için gerçekten gerekli teknik veya yönetsel durum.
• impact scope: hangi object, principal, boundary ve zaman penceresinin etkilendiği.
• evidence: iddiayı doğrudan destekleyen, kaynak ve toplama zamanı belirtilmiş veri.
• exception: mekanizmayı kapatan deny, scope, control veya iş gereksinimi.
• remediation: risk varsayımını azaltan, owner ve doğrulama kriteri olan değişiklik.
• confidence: kanıtın mekanizma, uygulanabilirlik ve etkideki eksiklerini görünür tutan seviye.

Bulgu bir neden-sonuç zinciridir

Başlangıç iddiası dar olmalıdır: 'Bu trustee bu object üzerinde şu ACE'e sahip.' Ardından 'bu ACE hangi işlemi mümkün kılar?', 'hangi ek koşullar sağlanmalı?' ve 'hangi principal/asset etkilenir?' soruları gelir. Bu katmanlar tek bir severity etiketiyle gizlenmemelidir.

Etki kapsamı object'in bulunduğu OU, inherited ACE'in yayıldığı child object'ler, trustee'nin gerçek üyelikleri ve resource boundary ile sınırlıdır. Bir domain object üzerindeki geniş hak ciddi olabilir; yine de her durumda forest-wide impact diye yazılamaz.

İstisna, bulguyu zayıflatmak değil doğru yapmak içindir

Deny ACE, object-specific GUID, protected object davranışı, service-side control veya geçici change window mekanizmayı daraltabilir. Bunlar 'false positive' olarak sessizce atılmamalı; hangi iddiayı etkilediği yazılmalıdır.

Düzeltme de aynı kesinlikte olmalıdır: gereksiz ACE'i kaldırmak, trustee'yi dar gruba taşımak veya property-specific delegation kullanmak. Düzeltme sonrası aynı artifact ve gerekli iş akışıyla tekrar doğrulama planlanır.

Durum ve veri akışı

1. Mekanizma iddiasını object, trustee ve right ile sınırlı yaz.
2. Uygulanabilirlik için eksik authorization, network ve service koşullarını listele.
3. Etki alanını asset/boundary/principal olarak belirle.
4. İstisnayı ve kanıt boşluklarını açıkça yaz.
5. En dar düzeltmeyi owner, rollback ve doğrulama kriteriyle tanımla.

2. Exploitation / İstismar

Broken trust assumption

Bir değerlendirme sonucu, geniş bir right veya şüpheli artifact yüzünden yüksek etkili olarak raporlanmak üzeredir; ders doğrulama yapılmadan gerçek ortamda değişiklik veya istismar yönlendirmez.

Technical prerequisites

• Artifact'in object kimliği, trustee'si, ACE kapsamı ve toplama zamanı doğrulanmıştır.
• İddia edilen işlemin ek AccessCheck/token, inheritance, servis ve ağ koşulları belgelenmiştir.

Exploitation mechanism / İstismar mekanizması

Finding'in etkisi, yalnız temel ACE'in gücünden değil, bunun doğru target'a uygulanmasından doğar. GenericAll geniş bir başlangıç sinyalidir; fakat current trustee membership, object role ve sonraki kontrol noktaları görülmeden gerçek business impact ölçülmez.

Severity, mekanizmanın yerine geçmez

Yüksek severity etiketi, okuyucunun hangi ACE'i değiştireceğini veya hangi sistemin etkilenebileceğini açıklamaz. Kanıt zinciri kopuksa severity düşürmek yerine confidence ile impact scope ayrılmalıdır.

Bu yaklaşım hem false positive'leri görünür kılar hem de gerçek geniş hakların owner/rollback planı olmadan riskli biçimde kaldırılmasını engeller.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Finding artifact'ini hash/collection zamanı, object DN ve source system ile sakla.
• Her assertion için evidence, inference ve doğrulanmamış varsayımı farklı alanlarda yaz.
• Exception'ı kontrol türü, kapsamı ve geçerlilik zamanı ile kaydet.
• Remediation için owner, change window, rollback ve post-change verification kriteri ata.

Events and relevant fields

• 4662, SACL ile görünür olan operation için kanıt olabilir; ACE'in mevcut state'ini, tüm AccessCheck sonucunu veya business impact'i tek başına taşımaz.
• Directory audit görünmüyorsa önce SACL ve audit policy coverage araştırılır; yokluk success veya failure kararı değildir.

Rapora kanıt sınırını koy

Sentetik SDDL, belirli trustee için Generic All ACE'i gösterir. Parser bunu 'Generic All' olarak çözer; trustee'nin gerçek üyeliğini, inherited object kapsamını veya live AccessCheck sonucunu hesaplamaz.

Bu sınır rapora yazıldığında, bulgu sahibi sonraki doğrulama işini açıkça görür ve değişikliğin istemeden iş kesintisi üretme riski azalır.

Detection logic · XPath

*[System[(EventID=4662)]]

Query assumptions

• Sorgu denetlenmiş directory operation adaylarını seçer; DACL state için ayrı directory artifact gerekir.
• SACL/audit coverage bilinmeden event yokluğu yorumlanmaz.

False positives

• Yetkili yönetim operasyonları aynı event'i üretebilir.
• Event korelasyonu değişikliğin etkisini veya düzeltmenin güvenli olduğunu tek başına doğrulamaz.

Hardening

• Geniş Generic All/WriteDacl delegasyonlarını object-specific, görev-temelli ACE'lerle değiştir.
• Hassas object ACL değişikliklerini iki kişilik review ve rollback planıyla yönet.
• Remediation sonrası hem ACE artifact'ini hem de gerekli iş akışını ayrı doğrula.

Örnekler üzerinde oku / Read the examples

O:BAG:BAD:(A;;GA;;;S-1-5-21-1987654321-1234567890-2468013579-5178)

İki yanlış kanı / Two reality checks

Sanılan: Geniş bir ACE bulmak, domain-wide iş etkisinin kanıtıdır.

Gerçekte: ACE mekanizma kanıtıdır; uygulanabilirlik ve etki, target scope, trustee state, runtime koşulları ve istisnalarla ayrıca doğrulanır.

Sanılan: İstisna veya eksik kanıt bulguyu kapatmak için saklanmalıdır.

Gerçekte: İstisna ve confidence sınırı bulguyu denetlenebilir yapar; en dar, geri alınabilir düzeltmenin seçilmesini sağlar.

Kaynaklar / Sources

• Microsoft · How DACLs control access to an object
  Requested access, token and DACL evaluation; deny/allow decision context.
• Microsoft · 4662(S, F): An operation was performed on an object
  SACL-dependent DS object operation auditing and event-field scope.