Oturum, Kerberos ve dizin değişikliklerini olay kayıtlarında ilişkilendirmek.

1. Core Mechanism / Temel mekanizma

Korelasyon, zaman damgalarını yan yana koymak değildir. Zamana dayalı eşleştirme her zaman olasılıklıdır; alan tabanlı eşleştirme ise belirli sınırlar içinde kesindir. Bu sınırları bilmek, bir inceleme sonucunun gücünü belirler. Logon ID yalnız onu üreten makinede ve yeniden başlatmalar arasında benzersizdir; iki farklı sunucudaki aynı sayısal değer aynı oturum anlamına gelmez. Logon GUID, Kerberos ile oluşan oturumlarda istemci tarafındaki oturum kaydı ile domain controller'daki bilet kayıtları arasında bir bağ kurabilir. Dizin tarafında ise tek bir LDAP işlemi birden çok özniteliği değiştirdiğinde her değişiklik ayrı bir kayıt üretir ve bu kayıtlar ortak bir operasyon korelasyon kimliğiyle gruplanır. Üç mekanizma farklı kapsamlara sahiptir ve biri diğerinin yerine kullanılamaz.

Arabirimler ve belirtimler

• Logon ID (TargetLogonId / SubjectLogonId): Bir oturum açma olayında üretilen ve aynı makinedeki sonraki olaylarda tekrar görünen oturum tanımlayıcısı. Oturum kapanışı ve ayrıcalık kullanımı gibi kayıtlar bu alan üzerinden aynı oturuma bağlanır.
• Logon ID'nin kapsamı: Değer yalnız onu üreten bilgisayarda ve yeniden başlatmalar arasında benzersizdir. Farklı makinelerdeki eşit değerler aynı oturumu göstermez.
• Logon GUID: Kerberos ile oluşan oturumlarda üretilen ve domain controller'daki Kerberos bilet olaylarıyla eşleştirilebilen bir tanımlayıcı. Kerberos dışı oturumlarda anlamlı bir değer taşımayabilir.
• Kerberos olay ailesi: TGT ve servis bileti talepleri yalnız domain controller'larda kaydedilir; bu kayıtlarda istemci tarafındaki oturum kimliği bulunmaz, bağ farklı alanlar üzerinden kurulur.
• Dizin değişikliği kayıtları: Bir dizin nesnesi değiştiğinde üretilen olay, değişikliği yapan oturumun bilgilerini ve değiştirilen özniteliği taşır; operasyon korelasyon kimliği aynı işlemden doğan kayıtları gruplar.
• Açık kimlik bilgisiyle başlatılan erişim: Bir hesabın başka bir hesabın kimlik bilgisiyle işlem başlatması ayrı bir olay ailesiyle kaydedilir ve zincirin kopma noktalarından biridir.

Aynı makine içinde: logon ID zinciri

En güvenilir korelasyon, tek bir makinenin içinde kurulur. Bir oturum açıldığında üretilen logon ID, o oturum tarafından yapılan işlemlerin kayıtlarında yeniden görünür. Oturumun kapanışı, ayrıcalıklı hakların atanması ve oturum altında başlatılan işlemler bu alanla aynı zincire dizilir.

Bu zincirin gücü, alanın bir tanımlayıcı olmasından gelir: eşleşme tahmin değil, aynı değerin tekrarıdır. Ancak kapsam dardır. Değer yalnız onu üreten bilgisayarda benzersizdir ve makine yeniden başlatıldığında aynı sayısal değerler yeniden kullanılabilir. Bu yüzden korelasyon anahtarı her zaman makine adı ve zaman aralığıyla birlikte düşünülmelidir.

Pratikte bu, bir sorgunun 'logon ID eşittir' koşuluyla yetinmemesi demektir. Doğru sorgu, bilgisayar adı, logon ID ve makul bir zaman penceresini birlikte kullanır. Aksi halde farklı sunuculardan gelen ilgisiz oturumlar aynı zincire karışır.

Makineden DC'ye: Kerberos köprüsü

Bir domain hesabı Kerberos ile oturum açtığında iki ayrı makinede kayıt doğar: domain controller bilet taleplerini, erişilen makine ise oturum oluşumunu kaydeder. Bu iki tarafı birbirine bağlamak için oturum kaydındaki logon GUID alanı kullanılır; aynı değer domain controller tarafındaki Kerberos olaylarında da görünebilir.

Bu köprü güçlüdür ama koşulludur. Oturum Kerberos ile oluşmadıysa alan anlamlı bir değer taşımaz ve köprü kurulamaz. Ayrıca domain controller tarafındaki kaydın bulunabilmesi için ilgili denetim alt kategorisinin o DC'de etkin olması ve doğru DC'ye bakılması gerekir; çok sayıda DC bulunan ortamda talep başka bir DC tarafından karşılanmış olabilir.

Köprü kurulamadığında geriye zaman ve kullanıcı adı üzerinden sezgisel eşleştirme kalır. Bu eşleştirme bir hipotez üretir, kanıt üretmez ve rapor dilinde böyle ifade edilmelidir.

Dizin tarafı: tek işlem, çok kayıt

Dizin değişiklikleri çoğu zaman tek bir kayıtla temsil edilmez. Bir LDAP işlemi birden çok özniteliği değiştirdiğinde her öznitelik değişikliği ayrı bir olay olarak yazılır. Bu kayıtların aynı işlemden geldiğini gösteren şey, paylaştıkları operasyon korelasyon kimliğidir.

Aynı kayıtlar değişikliği yapan oturumun kimlik bilgilerini de taşır. Böylece 'hangi hesap, hangi oturumda, hangi nesnenin hangi özniteliğini değiştirdi?' sorusu tek bir kayıt ailesinden cevaplanabilir. Ancak bu kayıtların oluşabilmesi için ilgili alt kategorinin etkin olması ve nesnenin SACL kapsamında bulunması gerekir.

Üç mekanizmanın birleşimi, bir olay anlatısını uçtan uca kurmanın temelidir: dizin değişikliğini yapan oturum, o oturumun açıldığı makinedeki zincir ve gerekiyorsa domain controller tarafındaki bilet kayıtları. Her halkanın kendi koşulu ve kendi kapsam sınırı vardır.

Durum ve veri akışı

1. Erişilen makinede oturum açılır ve bir logon ID üretilir; bu değer aynı makinedeki sonraki kayıtlarda tekrar görünür.
2. Oturum Kerberos ile oluştuysa kayıt bir logon GUID taşır; aynı değer, talebi karşılayan domain controller'ın bilet olaylarında aranabilir.
3. Kullanıcı dizinde bir değişiklik yaptığında, değişikliği işleyen domain controller değişiklik kaydını üretir ve kayıt değişikliği yapan oturumun bilgilerini taşır.
4. Tek bir dizin işlemi birden çok özniteliği değiştirdiyse, oluşan kayıtlar ortak bir operasyon korelasyon kimliğiyle gruplanır.
5. Zincir, açık kimlik bilgisiyle başlatılan erişim veya kapsam dışı bir denetim ayarı nedeniyle koptuğunda, kopma noktası raporda açıkça belirtilir; zaman tabanlı eşleştirme hipotez olarak işaretlenir.

2. Exploitation / İstismar

Broken trust assumption

“Kullanıcı adı ve zaman damgası aynıysa bu kayıtlar aynı etkinliğe aittir” varsayımı. Buradan da farklı makinelerden gelen oturum, bilet ve dizin değişikliği kayıtlarının tek bir zaman çizelgesinde yan yana dizilerek nedensel bir anlatı kurulabileceği sonucuna varılır.

Technical prerequisites

• Korelasyon kuralları yalnız hesap adı ve zaman penceresi üzerine kuruludur; kayıtlardaki tanımlayıcı alanlar kullanılmaz.
• Logon ID'nin makine kapsamında benzersiz olduğu bilinmediği için sorgular bilgisayar adını eşleşme anahtarına dahil etmez.
• Ortamda birden çok domain controller vardır, ancak hangi DC'nin talebi karşıladığı incelemede dikkate alınmaz.
• Dizin değişikliği kayıtlarının tek bir işlemden çoğalabileceği bilinmez; her kayıt ayrı bir eylem sayılır.
• Saat senkronizasyonu ve farklı kaynakların zaman damgası davranışı doğrulanmamıştır.

Exploitation mechanism / İstismar mekanizması

Hata, olasılıklı eşleştirmenin kesin eşleştirme gibi raporlanmasıdır. Kullanıcı adı birçok kayıtta görünür; aynı hesap aynı dakika içinde birden çok makinede, birden çok servis bileti talebiyle ve birden çok dizin okumasıyla temsil edilebilir. Bu kayıtları yalnız ada ve zamana bakarak birleştirmek, ortada tek bir eylem varmış gibi bir anlatı üretir. İkinci hata kaynağı kapsam karışmasıdır: logon ID yalnız üreten makinede benzersiz olduğundan, bilgisayar adı eşleşmeye katılmadığında farklı sunucuların ilgisiz oturumları aynı zincire dizilir. Üçüncü hata kaynağı sayım şişmesidir: tek bir dizin işlemi birden çok öznitelik değiştirdiğinde her öznitelik için ayrı kayıt oluşur; operasyon korelasyon kimliği kullanılmadığında bu, çok sayıda ayrı değişiklik gibi okunur. Dördüncüsü, zincirin gerçekten koptuğu noktaları görünmez kılmaktır: Kerberos dışı bir oturumda logon GUID köprüsü yoktur ve kapsam dışı bir denetim ayarı nedeniyle hiç oluşmamış bir kayıt, zaman çizelgesinde boşluk olarak değil yokluk olarak görünür. Bu ders bir saldırı tekniği anlatmaz; anlatılan şey, korelasyon iddiasının gücünün kullanılan alana göre değiştiğidir.

Tanımlayıcı ile sezgisel eşleştirmeyi ayır

Bir inceleme raporunda iki tür ifade vardır: 'aynı tanımlayıcıyı taşıyor' ve 'aynı zaman aralığında görünüyor'. Birincisi, alanın kapsamı içinde kesin bir bağdır. İkincisi bir hipotezdir ve başka kanıtla desteklenmesi gerekir. İkisini aynı cümle yapısıyla yazmak, raporun kanıt değerini düşürür.

Pratik kural şudur: korelasyon kuralı yazarken önce hangi alanın tanımlayıcı olduğunu ve kapsamının ne olduğunu belirt. Logon ID için kapsam makinedir; logon GUID için koşul Kerberos ile oluşan bir oturumdur; operasyon korelasyon kimliği için kapsam tek bir dizin işlemidir.

Zincirin kopma noktalarını önceden işaretle

Her zincirin bilinen kopma noktaları vardır. Bir hesabın başka bir hesabın kimlik bilgisiyle işlem başlatması, oturum zinciriyle sonraki etkinlik arasındaki doğrudan bağı değiştirir. Çok sayıda domain controller bulunan ortamda bilet talebini başka bir DC karşılamış olabilir. Denetim alt kategorisi kapalıysa veya nesne SACL kapsamı dışındaysa beklenen halka hiç oluşmaz.

Bu kopma noktaları incelemeden önce bilindiğinde, boşluk gördüğünde analist doğru soruyu sorar: 'bu halka neden yok?' Cevap çoğu zaman saldırgan davranışı değil, telemetri kapsamıdır. Raporun iki durumu ayırması, yanlış sonuç üretmeyi engeller.

Sayı değil, işlem say

Dizin değişikliği metriklerinde en sık görülen çarpıtma, kayıt sayısını eylem sayısı sanmaktır. Tek bir işlemde birkaç öznitelik değiştiğinde kayıt sayısı birkaç katına çıkar. Operasyon korelasyon kimliği kullanılmadan üretilen 'bugün şu kadar dizin değişikliği oldu' metriği, gerçek işlem sayısını yansıtmaz.

Aynı sorun eşik tabanlı uyarılarda da görülür. İşlem başına gruplama yapılmadan belirlenen eşikler, rutin bir toplu güncellemede yanlış pozitif üretir ve zamanla kural güvenilirliğini düşürür.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Korelasyon kurallarında eşleşme anahtarını açıkça yaz: bilgisayar adı ile logon ID birlikte, yalnız logon ID değil.
• Kerberos köprüsünü kullanan kurallarda oturumun Kerberos ile oluşup oluşmadığını ve hangi domain controller'a bakıldığını kayıt altına al.
• Dizin değişikliği analizlerinde operasyon korelasyon kimliğiyle gruplama yap; metrikleri kayıt değil işlem bazında raporla.
• Açık kimlik bilgisiyle başlatılan erişimleri ayrı bir kayıt ailesi olarak izle; bunlar zincirin bilinen kopma noktalarıdır.
• Zaman kaynaklarının senkronizasyonunu düzenli doğrula; korelasyon pencereleri saat sapmasına duyarlıdır.
• Her korelasyon kuralı için kapsam notu tut: hangi alan tanımlayıcı, hangi eşleşme sezgisel, hangi koşulda kural sessiz kalır.

Events and relevant fields

• İki farklı makinede görülen aynı logon ID değeri aynı oturum anlamına gelmez; değer yalnız üreten makinede benzersizdir.
• Oturum kaydında anlamlı bir logon GUID bulunmaması bir anormallik değildir; Kerberos dışı oturumlarda bu köprü kurulamaz.
• Domain controller tarafında bilet kaydının bulunamaması, oturumun gerçekleşmediğini göstermez; talep başka bir DC tarafından karşılanmış veya ilgili alt kategori kapalı olabilir.
• Çok sayıda dizin değişikliği kaydı, çok sayıda ayrı eylem anlamına gelmez; tek bir işlem birden çok öznitelik kaydı üretebilir.
• Zaman damgalarının yakın olması nedensellik kurmaz; alan tabanlı bir bağ yoksa ilişki hipotez olarak kalır.

Kuralı yazmadan önce anahtarı tanımla

Bir korelasyon kuralının kalitesi, kullandığı anahtarın kalitesidir. Anahtar bir tanımlayıcıysa kural dar ve güvenilir olur; anahtar yalnız hesap adı ve zaman ise kural geniş ve gürültülü olur. Bu yüzden kural yazımının ilk adımı sorgu değil, anahtar seçimidir.

Anahtar seçimi aynı zamanda kuralın sınırını belirler. Oturum kimliği makine içinde çalışır; makineler arası bir iddia için başka bir köprü gerekir. Bu sınır kural belgesine yazıldığında, kuralın üretmediği sonuçlar da anlaşılır hale gelir.

Anlatıyı halkalarıyla birlikte sun

Bir olay anlatısı sunulurken her halkanın hangi kanıta dayandığı ayrı gösterilir: hangi kayıt hangi alanla bir öncekine bağlandı, hangi bağ yalnız zaman yakınlığına dayanıyor. Bu gösterim, anlatının hangi noktada zayıfladığını okuyucuya doğrudan aktarır.

Böyle sunulan bir anlatı, sonradan gelen bilgiyle güncellenebilir kalır. Zayıf halka işaretlenmişse, yeni bir kayıt kaynağı eklendiğinde yalnız o halka yeniden değerlendirilir; bütün sonuç yeniden kurulmak zorunda kalmaz.

Detection logic · KQL

let window = 1h;
let logons = SecurityEvent
| where TimeGenerated > ago(window) and EventID == 4624
| project LogonTime = TimeGenerated, Computer, TargetUserName, TargetLogonId;
SecurityEvent
| where TimeGenerated > ago(window) and EventID == 4672
| project PrivTime = TimeGenerated, Computer, SubjectUserName, SubjectLogonId
| join kind=inner logons on $left.Computer == $right.Computer, $left.SubjectLogonId == $right.TargetLogonId
| project LogonTime, PrivTime, Computer, TargetUserName, TargetLogonId

Query assumptions

• Bu sorgu yalnız biçim örneğidir ve bu oturumda hiçbir platformda çalıştırılmamıştır; tablo ve alan adları kullanılan toplama çözümüne göre değişir.
• Birleştirme anahtarı bilerek bilgisayar adı ile oturum kimliğini birlikte kullanır; yalnız oturum kimliği üzerinden yapılan birleştirme farklı makineleri karıştırır.
• Sorgu yalnız aynı makine içindeki zinciri kurar; domain controller tarafındaki Kerberos kayıtları bu sonuçta yer almaz.
• İlgili alt kategoriler etkin değilse veya kayıtlar merkeze iletilmiyorsa sorgu sessizce boş döner.

False positives

• Hizmet hesaplarının rutin oturumları ayrıcalık atama kayıtlarıyla birlikte görünür; bu beklenen bir desendir.
• Yönetim araçlarının planlı çalışması kısa aralıklarla çok sayıda eşleşme üretebilir.
• Negatif örnek: makine yeniden başlatıldıktan sonra aynı sayısal oturum kimliği yeniden kullanılabilir; dar zaman penceresi olmadan eski ve yeni oturumlar karışabilir.
• Saat sapması olan bir kaynakta olay sırası yanlış görünebilir ve nedensel yorum bozulur.

Hardening

• Korelasyon kurallarını alan kapsamıyla birlikte belgele; her kuralın hangi koşulda geçerli olduğunu yaz.
• Oturum zinciri kuran sorgularda bilgisayar adını her zaman eşleşme anahtarına dahil et.
• Dizin değişikliği uyarılarını işlem bazında grupla; eşikleri kayıt sayısı yerine işlem sayısı üzerinden belirle.
• Zaman senkronizasyonunu kritik kaynaklar için izle; sapma tespit edildiğinde ilgili dönemin korelasyon sonuçlarını yeniden değerlendir.
• Rapor dilinde 'aynı tanımlayıcı' ile 'aynı zaman aralığı' ifadelerini ayrı tut; hipotez olan bağları hipotez olarak yaz.
• Zincirin bilinen kopma noktalarını analist rehberine yaz; boşluk görüldüğünde önce telemetri kapsamı sorgulanır.

Ö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>5136</EventID><Version>0</Version><Level>0</Level><TimeCreated SystemTime="2026-10-01T08:12:33.0000000Z"/><EventRecordID>1502001</EventRecordID><Channel>Security</Channel><Computer>dc03.outreason.example</Computer><Security/></System><EventData><Data Name="OpCorrelationID">{3f2b08c4-5d61-4a7e-9f03-2c8b14ad6e51}</Data><Data Name="SubjectUserName">ops-admin</Data><Data Name="SubjectDomainName">OUTREASON</Data><Data Name="SubjectLogonId">0x5f21c9</Data><Data Name="ObjectDN">CN=Reports Service,OU=Service Accounts,DC=outreason,DC=example</Data><Data Name="ObjectClass">user</Data><Data Name="AttributeLDAPDisplayName">servicePrincipalName</Data><Data Name="OperationType">%%14674</Data></EventData></Event>

İki yanlış kanı / Two reality checks

Sanılan: Logon ID benzersiz bir oturum kimliğidir; aynı değeri gördüğüm her kayıt aynı oturuma aittir.

Gerçekte: Hayır. Logon ID yalnız onu üreten bilgisayarda ve yeniden başlatmalar arasında benzersizdir. İki farklı sunucuda aynı sayısal değerin görülmesi aynı oturum anlamına gelmez ve bir makine yeniden başlatıldıktan sonra değerler yeniden kullanılabilir. Bu nedenle oturum zinciri kuran her sorgu, eşleşme anahtarına bilgisayar adını ve makul bir zaman penceresini dahil etmelidir. Makineler arası bir iddia için farklı bir köprü, örneğin Kerberos ile oluşan oturumlarda logon GUID alanı gerekir.

Sanılan: Dizin değişikliği kayıtlarının sayısı, yapılan değişikliklerin sayısını verir.

Gerçekte: Hayır. Tek bir dizin işlemi birden çok özniteliği değiştirdiğinde her öznitelik değişikliği ayrı bir kayıt üretir; bu kayıtlar ortak bir operasyon korelasyon kimliği taşır ve asıl işlem sayısı bu kimlikle gruplanarak bulunur. Üstelik kayıtların oluşabilmesi için ilgili denetim alt kategorisinin etkin olması ve nesnenin SACL kapsamında bulunması gerekir; kapsam dışındaki değişiklikler hiç kaydedilmez. Dolayısıyla ham kayıt sayısı ne eylem sayısının ne de toplam değişiklik hacminin doğru ölçüsüdür.

Kaynaklar / Sources

• Microsoft · 4624(S) An account was successfully logged on
  Logon ID alanının aynı bilgisayardaki olayları ilişkilendirmek için kullanılması; Logon GUID alanının domain controller'daki Kerberos olaylarıyla eşleştirilebilmesi; logon type açıklamaları.
• Microsoft · 4634(S) An account was logged off
  Logon ID alanının oturum açma olayıyla geriye doğru ilişkilendirme için kullanılması.
• Microsoft · 5136(S) A directory service object was modified
  EventData alanları: OpCorrelationID, SubjectUserName, SubjectLogonId, ObjectDN, ObjectClass, AttributeLDAPDisplayName, OperationType; %%14674 Value Added ve %%14675 Value Deleted sabitleri.
• Microsoft · Audit Directory Service Changes
  Alt kategorinin yalnız domain controller'larda geçerli olması ve SACL koşulu.
• Microsoft · 4769(S, F) A Kerberos service ticket was requested
  Olayın yalnız domain controller'larda üretilmesi ve servis bileti talebi alanları.
• Microsoft · Audit Special Logon
  Özel ayrıcalıkların atanmasını gösteren olay ailesi ve oturum kimliği alanı.