Kimlik bilgisi, yetki ve güven ilişkisi kaynaklı riskleri ayırmak.

1. Core Mechanism / Temel mekanizma

Bu ders bulguyu etkilediği güven varsayımına göre sınıflandırır. Aynı olay üç riske de kanıt olabilir, fakat o olay tek başına üçünü birden ispatlamaz.

Arabirimler ve belirtimler

• credential: password, key, ticket veya certificate gibi doğrulama materyali.
• privilege: token/ACL/delegation üzerinden bir işlem veya object üzerinde etkili olabilme.
• trust: security authority'ler arası kimlik ve authorization bilgisini kabul etme sınırı.
• authentication: principal'ın iddiasının doğrulanması.
• authorization: doğrulanmış principal için istenen erişime karar verilmesi.
• telemetry: olayı gözleyen sistemin sınırlı kaydı; mekanizmanın tamamı değildir.

Risk sınıfı soruyu değiştirir

Credential bulgusunda soru 'hangi sır veya kanıt kullanılabilir, nerede korunuyor ve rotasyonu neyi keser?'dir. Privilege bulgusunda soru 'hangi principal hangi object üzerinde hangi right ile hangi değişikliği yapabilir?'dir. Trust bulgusunda ise 'hangi boundary, hangi authority'nin claim'ini hangi filtering ve scope ile kabul eder?' sorusu gelir.

Bir service account'un SPN'i olması credential riskini otomatik göstermez; parola/key koruması, ticket alma koşulu ve offline işlem olasılığı ayrıca incelenir. Aynı hesapta geniş WriteDacl varsa bu privilege riskidir; trusted domain'den gelen SID'in kabulü ise trust riskidir.

Bir kanıtı sınıfın yerine koyma

KDC'nin ticket vermesi authentication protokolündeki bir adımdır. Bu, hedef service'in erişimi kabul ettiğini, resource ACL'in izin verdiğini veya trust filtering'in beklenen her senaryoda doğru olduğunu göstermez.

Benzer biçimde 4662, SACL tarafından seçilmiş bir directory operation kaydıdır. Bir ACE'in bulunmasıyla veya credential'ın ele geçirildiğiyle eş anlamlı değildir.

Durum ve veri akışı

1. Bulgunun ihlal ettiği varsayımı credential, privilege veya trust olarak adlandır.
2. İddiayı destekleyen artifact'i ve artifact'in gözlem sınırını kaydet.
3. Etki için gerekli ek authorization, ağ ve servis önkoşullarını belirt.
4. Düzeltmeyi risk sınıfına göre sır koruması, least privilege veya boundary kontrolü olarak eşleştir.

2. Exploitation / İstismar

Broken trust assumption

Bir değerlendirici bulguyu yüksek etkiyle etiketlemek istemektedir; bu ders, isim veya tek telemetri kaydından uygulanabilirlik sonucu çıkarılmaması için sınır koyar.

Technical prerequisites

• Credential iddiasında ilgili materyalin exposure surface'i ile principal'ın secret/key/ticket'e erişimi veya doğrulanmış credential kullanım yolu kanıtlanmalıdır.
• Privilege iddiasında doğru principal, object ve authorization right aynı zaman penceresinde doğrulanmıştır.
• Trust iddiasında yön, scope, filtering ve hedef taraf kabul koşulları incelenmiştir.

Exploitation mechanism / İstismar mekanizması

Yanlış sınıflandırma yanlış remediation üretir: yalnız parola rotasyonu geniş ACL'i kapatmaz; yalnız ACE düzeltmek leaked credential'ı geçersizleştirmez; trust filtering ise iki uçtaki resource ACL'in yerine geçmez.

Adlandırma, kanıt zincirinin ilk satırıdır

Bir risk 'credential exposure' diye raporlanırken kullanılan materyal, kullanım penceresi ve doğrulama boundary'si belirtilmelidir. 'Privilege escalation' denirken ise doğrudan verilen right ile gerçek etkili operasyon birbirinden ayrılmalıdır.

Trust riskinde karşı domain'in compromise edilmesi ile bu compromise'ın hedefte hangi SID, ticket veya authorization yoluyla etkili olacağı aynı iddia değildir.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Her finding'e tek bir birincil risk sınıfı ve varsa bağımlı ikincil sınıf ata.
• Credential bulgularında materyal türü, saklama/yayın yüzeyi ve rotasyon kapsamını kaydet.
• Privilege bulgularında trustee, target object, right, inheritance ve deny/allow bağlamını sakla.
• Trust bulgularında direction, transitivity, filtering ve target resource authorization sınırını kaydet.

Events and relevant fields

• 4769, KDC'nin service-ticket işlemine ait gözlemdir; resource access success veya credential compromise kanıtı değildir.
• 4662 yalnız SACL yapılandırılmışsa bir directory operation görünürlüğü sağlar; tüm privilege değişikliklerini kapsadığı varsayılamaz.

Aynı sinyal, üç ayrı araştırma kuyruğu açabilir

Sentetik örnekte busra@OUTREASON.EXAMPLE ticket isteyen hesabı, svc-reports hedef servis hesabını gösterir. Tam SPN bu ServiceName alanından çıkarılamaz; gerekirse ayrı dizin/servis hesabı verisiyle incelenir. KDC kaydı araştırmanın başlangıcıdır: credential, hedef servis kabulü ve resource ACL sonucu için ayrı kanıt gerekir.

Böylece olay korelasyonu, 'bir event gördüm; compromise oldu' gibi kesin olmayan sonuca dönüşmez.

Detection logic · XPath

*[System[(EventID=4769)]]

Query assumptions

• Sorgu yalnız KDC service-ticket operation adaylarını seçer.
• Credential materyali, target service acceptance ve ACL sonucu bu event ile kanıtlanmaz.

False positives

• Normal uygulama erişimi 4769 üretebilir.
• Yalnız EventID'ye dayalı sınıflandırma credential, privilege ve trust risklerini karıştırabilir.

Hardening

• Credential, privilege ve trust bulguları için ayrı owner ve düzeltme doğrulaması ata.
• Privileged ACL delegation'ı görev-temelli, object-specific haklarla sınırla.
• Trust boundary değişikliklerini filtering ve hedef resource authorization review'uyla birlikte değerlendir.

Örnekler üzerinde oku / Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4769</EventID><Version>2</Version><Level>0</Level><TimeCreated SystemTime="2026-10-01T09:14:11.0000000Z"/><EventRecordID>1302001</EventRecordID><Channel>Security</Channel><Computer>dc01.outreason.example</Computer><Security/></System><EventData><Data Name="TargetUserName">busra@OUTREASON.EXAMPLE</Data><Data Name="ServiceName">svc-reports</Data><Data Name="TicketEncryptionType">0x12</Data><Data Name="Status">0x0</Data><Data Name="IpAddress">192.0.2.24</Data></EventData></Event>

İki yanlış kanı / Two reality checks

Sanılan: Bir service account veya 4769 kaydı görmek, credential compromise kanıtıdır.

Gerçekte: Bu veri yalnız mekanizma için araştırma yüzeyi açar; secret erişimi, key hygiene ve gerçek kullanım ayrı kanıt ister.

Sanılan: Trust ayarı varsa veya privileged ACE varsa bulgu tek sınıfta tamamen açıklanır.

Gerçekte: Trust boundary, privilege authorization ve credential doğrulama materyali farklı varsayımlardır; düzeltme ve doğrulama ayrı yürütülür.

Kaynaklar / Sources

• Microsoft · 4769(S, F): A Kerberos service ticket was requested
  Account Name normalized/implicit UPN versus UPN attribute; Service Name target account/computer, not full SPN; updated Version2 field reference and KDC-side observation boundary.
• Microsoft · Best practices for securing Active Directory
  AD attack surface, privileged access and recovery boundary guidance.