MODÜL 1 — Olay Müdahalesine Giriş ve Temel Kavramlar

Modül Teması

Bu modül, "alarm gördüm → teknik inceleme yaptım" çizgisini kurumsal ölçekte yönetilebilir bir olay müdahalesi disiplinine dönüştürür. Hedef, bir sinyali hızla "etiketlemek" değil; belirsizliği sistematik biçimde azaltarak doğrulanabilir bulgular üretmek, bulguları doğru paydaşlara doğru zamanda taşımak ve her kararın kanıt standardını korumaktır. Bir önceki modülde kurulan doğrulama--kanıt--karar omurgası burada temel kavramlar, yaşam döngüsü ve organizasyonel çerçeveyle sağlamlaştırılır.

1. Kavramların doğru kullanımı: Aynı şey değiller, sonuçları da aynı değil

Kurumsal ortamlarda en pahalı hatalardan biri, kavramları karıştırıp "yanlış şiddette" reaksiyon vermektir. Yanlış kelime, yanlış yükümlülük; yanlış yükümlülük, yanlış aksiyon demektir. Bu bölümün odağı sözlük ezberi değil; doğru kelimenin sizi doğru kanıt standardına ve doğru koordinasyona nasıl zorladığını hissettirmektir.

1.1. Security event / event: gürültü mü sinyal mi?

Gün içinde milyonlarca kayıt oluşur; bunların tamamı müdahale gerektirmez. Bir ağ akışı, bir başarısız giriş, bir politika ihlali uyarısı... Bunların her biri "gözlemlenebilir bir gerçekleşim" olarak event sınıfına girebilir. Ancak "müdahale disiplini" devreye sokulacak eşiği belirlemek için iki soru kritikleşir:

• Bu gözlem, gizlilik-bütünlük-erişilebilirlik etkisine (veya politika ihlali riskine) bağlanabiliyor mu?

• Bu gözlem, doğrulama planına bağlanmadan "kesin hüküm" kurulmasına sebep oluyor mu?

Dikkat: >Her incident bir event akışından doğar; ama her event incident değildir. "Gürültüden sinyal ayıklama" becerisi, ekip kapasitesini korur ve gerçek olaylarda gecikmeyi azaltır.

1.2. Incident: koordinasyon, kanıt standardı ve karar kaydı gerektiren eşik

Incident, artık "teknik inceleme"nin ötesinde bir yönetim sürecidir. Bu eşik aşıldığında:

• Koordinasyon (roller, komuta zinciri, eskalasyon) zorunlu hâle gelir,

• Kanıt standardı (bütünlük, erişim kaydı, yeniden üretilebilirlik) beklenir,

• Kararların gerekçesi yazılı hâle gelmelidir (neden bu containment? neden bu kapsam?).

Bu noktada ileri seviye ayrım şudur: "Ne var?" kadar "ne yok?" da ciddiye alınır. Bir iddiayı güçlendiren veriler kadar, iddiayı çürütebilecek karşı kanıtlar da tasarlanır.

1.3. Breach: teknik bir sonuç değil, aynı zamanda hukuki/uyum tetikleyicisidir

Breach pratikte çoğunlukla "yetkisiz ifşa / veri sızıntısı" gibi bir sonuç içerir. Her incident breach değildir; fakat breach olarak adlandırılan durumlar genellikle teknik aksiyonlara ek olarak hukuk, uyum ve dış iletişim yükümlülüklerini tetikler.

Bu yüzden breach eşik cümlesi şu disiplinle kurulmalıdır: Veri sızıntısını veya yetkisiz ifşayı gösteren somut delil olmadan "ihlâl oldu" demek yerine, "veri ihlali şüphesi" dilini korumak çoğu zaman daha savunulabilir bir yaklaşımdır.

Örnek: Bir sistemde mesai dışında yoğun DNS sorguları görülüyor. Bu; yanlış yapılandırılmış bir health-check nedeniyle event olabilir, şüpheli davranış nedeniyle incident olabilir, veri dışarı çıktıysa breach olabilir. Sınıflandırmayı ilk bakış değil, doğrulama tasarımı belirler: aynı örüntü geçmişte var mı, hedef alan adı kurumun normal iletişim listesinde mi, davranışı destekleyen bağımsız izler var mı?

İpucu: İletişimde "breach" kelimesi, çoğu kurumda geri dönüşü zor bir kriz yönetimini tetikler. Bu kelimeyi ancak kanıtla taşınabilir eşik aşıldığında kullanmak, hem gereksiz panik riskini hem de gerçek ihlalde gecikme riskini azaltır.

1.4. "Saldırı var" dilinin tuzağı: iddia ile kanıt arasına mesafe koymak

"Saldırı var" çoğu zaman bir hipotezdir. İleri DFIR'de hipotez tek başına değerli değildir; değer, hipotezin hangi verilerle sınandığı ve hangi olasılıkların elendiği ile oluşur. Bu yüzden raporda ve ekip içi iletişimde şu ayrım korunur:

• Gözlem: "Şu zaman aralığında, şu varlıkta, şu sinyal görüldü."

• Yorum: "Bu sinyal, şu hipotezle tutarlı olabilir."

• Doğrulama planı: "Hipotezi çürütebilecek karşı kanıtlar şunlardır; bunlar aranmıştır / aranacaktır."

İpucu: Bir ifadeyi "kesin" yazmadan önce kendinize şu soruyu sorun: "Bunu çürütecek hangi karşı kanıtı özellikle aradım; arayamadıysam neden?" Bu refleks, doğrulama yanlılığını (confirmation bias) belirgin biçimde azaltır.

2. NIST odaklı IR yaşam döngüsü: faz isimleri değil, faz çıktıları yönetilir

Olay müdahalesi doğrusal görünse de sahada döngüsel ve geri beslemeli bir süreçtir. Kurumların önemli bir kısmı hâlâ klasik faz yaklaşımını (hazırlık → tespit/analiz → containment/eradication/recovery → olay sonrası) operasyonel dil olarak kullanır; bu yaklaşım pratik çıktıları netleştirdiği için değerlidir. Bununla birlikte NIST'in daha yeni yaklaşımı, incident response'u daha geniş siber risk yönetimi faaliyetleriyle hizalayarak "Detect-Respond-Recover" eksenine taşır ve hazırlığı, daha geniş yönetişim ve koruma faaliyetleriyle birlikte ele alır.

Bu modülde kritik olan, modelin adı değil; her aşamada hangi kanıtın üretildiği, hangi belirsizliğin yönetildiği ve hangi kararın gerekçelendirildiğidir.

2.1. Hazırlık: olay çıkmadan üretilen "hareket edebilirlik"

Hazırlık, "doküman yazdık" demek değildir; olay anında kanıtla uyumlu hız üretmektir. İleri seviye bakışla hazırlığın çıktıları şunlara dayanır:

• Yetki ve sınırlar: İzolasyon, hesap askıya alma, log saklama gibi geri etkili kararları kim hangi eşikte alır?

• Kanıt standardı: Delil bütünlüğü nasıl korunur, erişim ve aktarım nasıl kayıt altına alınır?

• İletişim kanalları: Krizde kim, kiminle, hangi kanaldan konuşur? Belirsizlik, bilgi sızıntısı ve yanlış yönlendirme riskini büyütür.

• Baseline ve görünürlük: "Normal" bilinmeden anomali, ya gürültüye dönüşür ya da aşırı alarmcılık üretir.

Dikkat: Hazırlık eksikse, containment hamleleri delili bozabilir veya kritik hizmeti gereksiz yere kesebilir. IR'de "hız" tek başına erdem değildir; kanıtla uyumlu hız erdemdir.

2.2. Tespit ve analiz: triage, doğrulama ve kapsam yönetimi

Bu aşama, alarmı "olaya" dönüştüren filtredir. İleri seviyede beklenen çıktılar:

• Kapsam tanımı: Etkilenen varlıklar, zaman penceresi, olası yayılım ve temas noktaları

• Hipotez seti: Tek bir açıklamaya kilitlenmeden birden fazla olasılığı masada tutmak

• Doğrulama planı: Hangi veri hipotezi güçlendirir, hangi veri hipotezi çürütür?

• Triage raporu: Etki ve olasılık üzerinden önceliklendirme; "şimdi neyi durdurmalı, neyi izlemeli?" gerilimini görünür kılma

Örnek: Bir uç noktada kısa süreli yüksek ayrıcalık oturumları görülüyor. "Hesap ele geçirildi" hipotezini kurduğunuz anda karşı kanıtı da ararsınız: aynı kullanıcı için geçmişte benzer yükseltmeler var mı, değişiklik yönetimiyle uyumlu mu, cihaz/konum tutarlı mı? Bu doğrulama yapılmadan yapılan hesap kilidi, kritik hizmet hesabını devre dışı bırakıp kesinti yaratabilir.

İpucu: Triage notlarına küçük bir alan ekleyin: "Bu sinyal neyi kanıtlamaz?" Bu satır, abartılı çıkarımları frenler ve raporun savunulabilirliğini artırır.

2.3. Containment: kanamayı durdurmak ama kanıtı öldürmemek

Containment kararında "en doğru" diye tek bir seçenek yoktur; kanıtla savunulabilir seçenek vardır. Yöntem seçimini belirleyen üç gerilim sürekli birlikte düşünülür:

• Delil volatilitesi: Canlı sistemde bazı izler hızla kaybolur; agresif müdahale bu izleri silebilir.

• İş etkisi: İzolasyon güvenlik kazanımı sağlar; ama hizmet kesintisi risk toplamını artırabilir.

• Belirsizlik seviyesi: "Tam emin değilim" hâlâ bir karardır; gerekçesi belirsizliği taşımalıdır.

Containment seçenekleri, dar kapsamlı izolasyondan (yalnızca ilgili hesabın/varlığın sınırlandırılması) segment bazlı sınırlamaya veya kontrollü izlemeye kadar genişler. İleri seviye pratikte her seçenek için şu iki not yazılı hâle getirilir: kanıta etkisi ve iş etkisi.

2.4. Eradication: "temizlik refleksi" ile kök nedenin görünmezleşmesi arasındaki risk

Eradication, kök nedeni ve kalıcılık unsurlarını kaldırmayı hedefler. Ancak erken eradication refleksi, saldırganın giriş yolunu ve yayılım modelini görünmez kılabilir; bu da kısa vadede rahatlatıp orta vadede tekrar olaya davetiye çıkarır. Bu nedenle eradication, doğrulanmış bulguların olgunlaşması ve gerektiği kadar kanıt paketinin tamamlanmasıyla dengelenir.

2.5. Recovery: geri dönüş kadar "geri dönmediğini doğrulamak"

Recovery, sistemleri normale döndürmekten ibaret değildir. Geri dönüş sonrasında, tehdidin geri gelmediğini ve aynı zafiyetin hâlâ açık olmadığını gösterecek bir doğrulama periyodu tasarlanır. Bu periyot "gelişmiş izleme" mantığıyla, ölçülebilir kontrol noktaları üretmelidir.

2.6. Olay sonrası faaliyetler: toplantı değil, ölçülebilir iyileştirme

Olay sonrası fazın ileri seviye çıktısı "toplantı yaptık" değildir; ölçülebilir öğrenmedir:

• Hangi sinyal geç geldi, hangi log eksikti, hangi zaman senkronizasyonu timeline'ı bozdu?

• Hangi yetki/iletişim belirsizliği zaman kaybettirdi?

• Hangi korelasyon yaklaşımı yanlış pozitif üretti; hangi yaklaşım kör nokta bıraktı?

İyileştirmeler kanıta bağlanmazsa, bir sonraki olayda aynı tartışmalar tekrar eder.

3. Önceliklendirme: etki-olasılık düşünmeden triage "kuyruk yönetimi"ne döner

Her olay aynı aciliyette değildir. Kurum ölçeğinde kaynak yönetimi için triage; etki (impact) ve olasılık (likelihood) dengesine oturtulur. İleri seviyede etki tek boyutlu okunmaz:

• Fonksiyonel etki: Hizmet verilebilirlik sürüyor mu, kritik süreçler aksıyor mu?

• Bilgi etkisi: Gizlilik veya bütünlük teyit edilmiş biçimde bozuldu mu, yoksa şüphe düzeyinde mi?

• Kurtarılabilirlik: Güvenli geri dönüş ne kadar sürer; bağımlılıklar neler?

Örnek: Bir uç noktada ağa yayılmayan bir fidye yazılımı olayı, kritik veritabanı sunucusunda görülen şüpheli ayrıcalıklı oturumdan daha düşük öncelikli olabilir; "aktif saldırı" etiketi tek başına öncelik belirlemez. Öncelik, etkilenebilecek varlığın kritikliği ve belirsizlik altında alınacak kararların maliyetiyle belirlenir.

4. Politika, plan, playbook ve eskalasyon: teknik doğruluk tek başına yetmez

Teknik beceri sahada vakayı çözer; kurumsal ölçekte ise çoğu kriz, kötü iletişim ve belirsiz roller yüzünden büyür.

4.1. Politika vs plan vs playbook: aynı iş için üç farklı seviye

• Politika: Kurumun "neyi kabul eder, neyi etmez" çizgisidir; eşikler ve yükümlülükleri belirler.

• IR planı: Roller, süreç, komuta zinciri, eskalasyon ve raporlama çerçevesidir.

• Playbook/runbook: Belirli senaryolarda (oltalama, DDoS, fidye yazılımı gibi) hangi ekibin hangi çıktıları üreteceğini somutlaştırır; yaşayan dokümandır.

Bu ayrım net değilse, olay anında ekip ya aşırı temkinli kalıp gecikir ya da aşırı agresif davranıp kanıtı riske eder.

4.2. Eskalasyon matrisi: "kimin, ne zaman, hangi sırayla" sorusunun cevabı

Eskalasyon matrisi, küçük bir olayda gereksiz kriz yönetimini tetiklememek ve büyük bir olayda kritik paydaşları geç çağırmamak için vardır. İleri seviyede eskalasyon, yalnızca "kişiye haber verme" değil; kanıt ve belirsizlik seviyesine göre doğru dili seçme disiplinidir.

4.3. Roller ve komuta zinciri: kriz anında koordinasyon bir yetenektir

Bazı rollerin ayrı tanımlanması, uzmanlığı bölmek için değil; karar kalitesini artırmak içindir:

• Incident Commander (Olay Yöneticisi): Büyük resmi görür, ekipleri koordine eder, üst yönetime raporlar; teknik ayrıntıya gömülmez.

• Forensics Lead (Adli lider): Delil toplama ve analiz disiplininin bütünlüğünden sorumludur; kanıt standardını korur.

• Communications (İletişim): Hukuk ve dış iletişimle koordinasyonu yürütür; teknik ekibi dış baskıdan korur.

İpucu: Teknik analistlerin en sık düştüğü tuzak, bulguları doğrudan teknik olmayan paydaşlara ham hâliyle anlatmaktır. Doğru yaklaşım, bulguların kanıt-belirsizlik çerçevesinde süzülüp "iş etkisi" diline çevrilmesidir.

4.4. İletişimde zamanlama da kanıt kadar önemlidir

İletişimde iki pahalı hata sınıfı vardır:

• Erken kesinlik: Doğrulanmamış iddiayı kesin dille duyurmak

• Geç bilgilendirme: Paydaşların farklı kanallardan bilgi arayıp kontrol kaybı yaratması

İleri seviye pratikte mesajlar "durum + kanıt + belirsizlik + bir sonraki doğrulama eşiği" kurgusuyla verilir.

Örnek: "198.51.100.0/24 kaynaklı başarısız giriş denemeleri ve bazı uç noktalarda servis oluşumu sinyalleri birlikte görülüyor; ihlâl henüz doğrulanmadı. Şu iki kanıt gelince containment seçenekleri netleşecek; gelmezse şu ihtimal dışlanacak."

5. SIEM/EDR telemetrisi ve DFIR: sinyal ile kanıt arasındaki köprü

SIEM çoğu zaman "nerede ve ne zaman başladı?" sorusunu başlatır; DFIR ise "gerçekten oldu mu, nasıl oldu, neyi dışladık?" sorularını cevaplar. Bu iki dünya karıştırıldığında iki risk doğar:

• SIEM sinyalini "kanıt" zannedip aşırı kesin raporlamak

• DFIR'i "her şeyi bilir" zannedip veri kalitesi ve görünürlük sorumluluğunu ihmal etmek

5.1. SIEM'in güçlü yanı ve kör noktaları

SIEM'in gücü, farklı kaynaklardan gelen sinyalleri korelasyonla bir araya getirmesidir. Kör noktaları ise genellikle şunlardan beslenir:

• Log kalitesi ve kapsamı zayıfsa korelasyon yanıltıcı olabilir

• Zaman senkronizasyonu bozuksa timeline "doğru ama yanlış sırada" görünebilir

• Baseline bilinmiyorsa anomali "gürültü"ye dönüşebilir

Bu yüzden ileri DFIR'de SIEM sinyali şu sorularla ele alınır: "Bu sinyal hangi ham veriye dayanıyor? Ham veri bütünlükle erişilebilir mi? Aynı iddiayı destekleyen bağımsız iz var mı?"

5.2. DFIR'in rolü: delil disiplini ve karar gerekçesi

DFIR, sinyali delil standardına taşır:

• Gözlem-yorum ayrımını netleştirir

• Zaman çizelgesini tutarlı hâle getirir

• Bulguların hangi kararı etkilediğini açıkça yazar (containment/eradication/recovery)

Örnek: SIEM'de "şüpheli bir komut çalıştırma" sinyali görüldüğünde, bunu tek başına "kanıt" diye raporlamak yerine; aynı davranışı doğrulayabilecek bağımsız izler (uç nokta telemetrisi, ilgili kayıtların tutarlılığı, gerekirse uçucu delillerin uygun standardla korunması) birlikte değerlendirilir. Buradaki hedef, "çok şey toplamak" değil; iddiayı taşıyan en az müdahaleyle en güçlü kanıt paketini kurmaktır.

Dikkat: "SIEM'de gördüm" tek başına kanıt değildir. Kanıt, aynı gerçeği taşıyan bağımsız izlerin bütünlük ve bağlamıyla birlikte paketlenmesiyle güç kazanır.

6. Kısa vaka analizi: kavramlar sahada nasıl birbirine bağlanır?

Bu bölümün amacı "sonuca koşmak" değil; doğru soruları doğru sırada sormayı ve kararları kanıtla savunmayı ölçmektir.

6.1. Senaryo

Hafta sonu boyunca şu sinyaller raporlanıyor:

• Birden fazla kullanıcı hesabında art arda başarısız oturum açma girişimleri

• İki uç noktada olağandışı saatlerde yeni servis oluşumu sinyali

• Dış ağdan example.net alan adına düzenli aralıklarla kısa süreli bağlantı denemeleri

• Ayrıca bir istemci cihazın (CLIENT-04), mesai saatleri dışında (02:14) bir yedekleme sunucusuna (backup-srv.example.net) uzaktan erişim oturumu açtığı ve yüksek hacimli veri aktarımı yaptığına dair telemetri

Olay henüz "ihlâl" olarak doğrulanmış değil.

6.2. Triage: sınıflandırma ve kapsamın ilk çizimi

Burada "event mi incident mı?" sınırı, yalnızca alarm şiddetine göre değil; potansiyel etki + doğrulama planı + koordinasyon ihtiyacı üzerinden çizilir:

• Bu sinyaller aynı olaya mı ait, yoksa bağımsız gürültü mü?

• Zaman penceresi ve etkilenen varlıklar nasıl tanımlanmalı?

• Hangi hipotezler masada kalmalı (ör. yanlış yapılandırma, otomasyon görevi, yetkisiz erişim, veri sızıntısı şüphesi)?

Çıktı beklentisi: kısa bir triage raporu, ilk kapsam listesi ve hipotez seti.

6.3. Doğrulama tasarımı: karşı kanıtı özellikle aramak

• Başarısız girişler: Parola püskürtme gürültüsü mü, hedefli deneme mi? Karşı kanıt: hedeflenen kullanıcıların rol kritikliği, saat örüntüsü, kaynak çeşitliliği, eşlik eden başka izler.

• Servis oluşumu: Planlı dağıtım olabilir mi? Karşı kanıt: değişiklik yönetimiyle zaman uyumu, dağıtım kanalının tutarlılığı, benzer değişimin başka varlıklarda görünmesi.

• Düzenli bağlantı denemeleri: Health-check olabilir mi? Karşı kanıt: alan adının tarihsel görünümü, baseline sapması, davranışın yalnızca belirli varlıklarda yoğunlaşması.

• 02:14 erişim ve büyük aktarım: Meşru yönetici aktivitesi mi, yetkisiz hareket mi? Karşı kanıt: ilgili hesabın rolü/iş akışı, olağan çalışma saatleri, aynı cihazın geçmiş davranışı, erişim zincirinin başka izlerle desteklenip desteklenmediği.

Çıktı beklentisi: "hangi iddia hangi veriyle sınandı / çürütülmeye çalışıldı" netliği.

6.4. Yöntem seçimi: containment kararını savunulabilir kılmak

Belirsizlik varken iki uç risk birlikte yönetilir:

• Gereksiz izolasyon → iş sürekliliği kaybı

• Geç izolasyon → etki büyümesi

Karar, "tek doğru" olduğu için değil; kanıt ve belirsizlikleri açıkça taşıdığı için savunulabilir olmalıdır. Örneğin bir istemciyi tamamen kapatmak, uçucu delil kaybı riskini artırabilir; buna karşılık kontrollü ağ izolasyonu, hem yayılım riskini azaltıp hem de kanıt disiplinini koruyacak bir seçenek olabilir. Hangi seçeneğin seçildiği kadar, neden seçildiği ve kanıta/işe etkisinin nasıl tartıldığı karar günlüğünde yer almalıdır.

6.5. Delil paketi: rapora taşınabilir biçimde yazmak

Bu vakada beklenen paket, ekran görüntüsü koleksiyonu değil; denetlenebilir bir yapı olmalıdır:

• IoC aday listesi (doğrulanmış / şüpheli / bağlama bağlı gibi güven düzeyiyle)

• Ön timeline (zaman dilimi tutarlılığı gözetilmiş; olaylar kronolojik ve kaynak referanslı)

• Kısa durum özeti (kanıtlar + belirsizlikler + önerilen ilk aksiyon + bir sonraki doğrulama eşiği)

• Karar gerekçesi notu (alternatifler, riskler, seçimin nedeni)

• Delil bütünlüğü ve erişim kayıtları (kim erişti, ne zaman, hangi koşullarda)

İpucu: IoC listesine bir sütun ekleyin: "Bu gösterge neyi kanıtlamaz?" Bu satır, özellikle ihlâl dili ve dış iletişimde aşırı yorum riskini dramatik biçimde azaltır.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Event–incident–breach ayrımının “kelime seçimi” değil, kanıt standardı ve yükümlülük seçimi olduğunu
• IR yaşam döngüsünü, her fazın somut çıktıları ve riskleri üzerinden yönetmeyi
• Doğrulamada karşı kanıt aramanın, yanlış pozitif maliyeti ile gecikme riskini dengelediğini
• Containment/eradication/recovery kararlarında yöntemi; delil volatilitesi–iş etkisi–belirsizlik üçlüsünün seçtirdiğini
• SIEM/EDR’nin sinyal ürettiğini; DFIR’in bunu doğrulama + delil paketi + timeline + gerekçeli karar çıktısına dönüştürdüğünü
• Politika/plan/iletişim net değilse, teknik doğruluğun bile kurumsal ölçekte değer üretemeyebileceğini

MODÜL 2 — Delil Toplama ve Koruma: Volatilite, Bütünlük ve Delil Zinciri

Artefaktı kanıta dönüştüren disiplin: volatilite sırasıyla toplama, hash ile bütünlük, müdahale izini minimize etme ve denetlenebilir delil zinciri kurma.

Modül Teması

Olay müdahalesinde "bir şey gördüm" demek, çoğu zaman yalnızca iyi bir başlangıçtır; "kanıtladım" diyebilmek ise delilin kökenini, bütünlüğünü ve bağlamını uçtan uca yönetmeyi gerektirir. Bu modül, laboratuvarın steril rahatlığı ile olay anının kaotik gerçekliği arasındaki farkı kapatır: Hangi verinin uçucu olduğunu, hangi dokunuşun delili geri dönüşsüz değiştirebileceğini ve üretilen çıktının üçüncü bir kişi tarafından aynı delil setiyle yeniden doğrulanabilir olup olmadığını sistematik biçimde ele alır.

1. Dijital delil düşüncesi: "artefakt"tan "kanıt"a geçiş

Bir log satırı, bir dosya parçası veya bir telemetri kaydı tek başına çoğu zaman yalnızca artefakttır. Delil (evidence) olabilmesi için üç sütun aynı anda ayakta kalmalıdır:

• Köken (provenance): Nereden geldi, hangi yöntemle alındı, hangi zaman penceresini kapsıyor?

• Bütünlük (integrity): Alındığı hâliyle değişmediğini nasıl gösterebiliyorum?

• Bağlam: Hangi iddiayı destekliyor, hangi iddiayı desteklemiyor?

İleri DFIR'de fark yaratan nokta, "bulguyu büyütmek" değil; bulguyu doğrulama planına bağlayıp (hangi karşı kanıtı aradın?), ardından denetlenebilir bir paket olarak taşınabilir hâle getirmektir. NIST, olay müdahalesiyle adli tekniklerin birleştiği yerde; delil toplama sırasında mümkün olan en az değişikliğin yapılması ve yapılan her değişikliğin kayda bağlanması gerektiğini açıkça vurgular.

Örnek: Bir uç noktada "olağandışı oturum" sinyali var. Bu sinyal, "hesap ele geçirildi" hipoteziyle tutarlı olabilir; fakat aynı zaman aralığında kimlik doğrulama kayıtları, uç nokta telemetrisi ve ağ akışları birbiriyle tutarlı değilse, elindeki şey güçlü bir delil değil, zayıf bir iddiadır. Üstelik aceleyle yapılan bir kapatma/yeniden başlatma, o hipotezi çürütecek veya güçlendirecek uçucu izleri (oturum bağlamı, anlık bağlantılar) ortadan kaldırabilir.

İpucu: Delil paketinde her bulgu için iki satır ayırın:
1)"Bu bulgu hangi iddiayı destekler?"
2) "Bu bulgu neyi kanıtlamaz?"\ İkinci satır, doğrulama yanlılığını (confirmation bias) pratikte frenleyen en ucuz ama en güçlü emniyet kemeridir.

2. Volatilite: Bazı deliller "beklemez"

Olay anında en pahalı varsayım "sonra toplarız"dır. Bazı veriler zamanla kendiliğinden değişir; bazıları ise sizin yaptığınız müdahaleyle geri dönüşsüz biçimde dönüşür. Bu nedenle uçuculuk, yöntem seçiminin merkezinde durur.

2.1. Uçuculuk sırası (Order of Volatility): standart, ama kör ezber değil

RFC 3227, dijital delillerin en uçucudan en kalıcıya doğru önceliklendirilmesini önerir; çünkü güç kesildiğinde veya zaman geçtikçe kaybolma eğilimi farklıdır.\ Bu disiplinin pratikte sık görülen katmanları:

• CPU cache / register gibi anlık bağlamlar

• RAM (çalışan süreçler, açık bağlantılar, oturum bağlamı)

• Swap/pagefile gibi belleğin diske taşan bölümleri

• Disk üzerindeki veriler (ama sistem çalıştıkça değişebilir)

• Loglar ve arşivler (özellikle merkezi/uzak log altyapısı varsa daha dirençli olabilir)

Yöntem seçimi burada başlar: Uçucu delil, belirli bir hipotezi test etmek için zorunluysa; "en temiz" görünen seçenek (ör. hızlı kapatma) gerçekte delil standardını zayıflatabilir. Buna karşın "her şeyi toplayalım" refleksi de kanıtı bozma ve iş etkisini büyütme riski taşır. İleri seviye yaklaşım, her toplama kararında hangi hipotezi test etmek için hangi delile ihtiyaç olduğunu yazılı hâle getirir.

Dikkat: Uçuculuk sırası bir "kontrol listesi" değil, bir kayıp risk haritasıdır. Her olayda her katmanı toplamak zorunda değilsiniz; ama hangi katmanı toplamadığınız için hangi hipotezi artık test edemeyeceğinizi bilmek zorundasınız.

2.2. Ağ ve bulut delilleri: "elinizin altındaki disk" yanılgısı

Her delil bir diskte durmaz. Ağ delilleri (akış kayıtları, paket yakalama) çoğu zaman yakalanmadıysa geri getirilemez; bu da hazırlık ve görünürlük kararlarını doğrudan adli kapasiteye bağlar. Benzer biçimde bulutta çoğu zaman fiziksel diske el koyamazsınız; delil, sağlayıcının sunduğu mantıksal çıktılar (loglar, zaman damgalı kayıtlar, anlık görüntüler) üzerinden yürür.

Buradaki ileri seviye ayrım şudur: "Yönetim panelinde gördüm" ile "ham ve doğrulanabilir kayıt aldım" aynı şey değildir. Doğrudan ham kayda, tutarlı zaman damgalarına ve bütünlük göstergelerine dayanmayan ekran görüntüleri, çoğu vakada tek başına zayıf kalır.

2.3. Olayın bağlamı standart sıralamayı nasıl yeniden tarttırır?

Uçuculuk sırası bir pusuladır; ancak olay bağlamı bazen pusulayı "önce şu riski yönet" diye zorlar.

Örnek: Yaygın bir fidye yazılımı senaryosunda diskteki veriler hızla dönüşürken, bazı kritik bağlamlar kısa süreliğine bellekte bulunabilir. Bu tür durumlarda yöntem seçimini belirleyen faktör yalnızca "standart sıra" değil; kurtarılabilirlik riski + delil volatilitesi + iş etkisi birlikte olur. (Burada amaç saldırı "nasıl yapılır"ını anlatmak değil; olay anındaki delil kaybı riskini doğru tartabilmektir.)

3. Delil toplama prensipleri: Minimum müdahale, maksimum açıklanabilirlik

Dijital adli bilişimde "hiç iz bırakmamak" çoğu zaman gerçekçi değildir; hedef, bıraktığınız izi minimumda tutmak ve daha önemlisi açıklanabilir ve belgelenebilir kılmaktır. NIST'in yaklaşımı, olay müdahalesi sırasında delile dokunan her işlemde değişiklik riskinin ve kayıt zorunluluğunun yönetilmesi gerektiğini vurgular.

3.1. Canlı toplama (Live Response) ne zaman savunulabilir?

Canlı toplama, uçucu delil ihtiyacı nedeniyle değerli olabilir; fakat aynı anda sistemi değiştirir. Savunulabilirlik şu üç soruya verilen net cevapla artar:

• Uçucu delil hangi hipotezleri test etmek için zorunluydu?

• Kaçınılmaz değişiklikler nelerdi (ör. bellek/işlem aktiviteleri, erişim izleri)?

• Bu değişiklikleri nasıl kayıt altına aldınız ve raporda nasıl sınırladınız?

İpucu: Canlı toplama yaptığınız her vakada, "toplama işlemi ortamı nasıl etkilemiş olabilir?" sorusuna tek cümlelik bir yanıtı karar günlüğüne ekleyin. Bu cümle, ileride çıkabilecek "delil kirlendi" itirazlarını yönetilebilir hâle getirir.

3.2. Kapalı sistem (dead-box) yaklaşımı ne zaman daha güvenlidir?

Kapalı sistem yaklaşımı, müdahale izini azaltır; özellikle iş sürekliliği hassassa veya adli hassasiyet yüksekse daha temkinli bir seçenektir. Bedeli ise nettir: bazı hipotezler uçucu delil olmadan zayıflar veya doğrulanamaz. İleri DFIR, bu bedeli "görmezden gelmek" yerine raporun belirsizlik alanı olarak taşır: "Şu iddia, şu uçucu delil alınamadığı için şu seviyede kalmıştır."

3.3. Yazma engelleme (Write-blocking): güçlü ama her yerde uygulanabilir değil

Disk temelli adli kopyalama sırasında hedef medyaya yazmayı engellemek; "orijinal delili değiştirmeme" iddiasını güçlendirir. NIST'in rehberlerinde, delilin toplanması sırasında değişiklik riskinin yönetimi ve delil bütünlüğünün korunması; yöntemin savunulabilirliğinin parçası olarak ele alınır.

Canlı sistemde ise tam anlamıyla yazma koruması çoğu zaman mümkün değildir; bu da minimum müdahale prensibini daha kritik hâle getirir. Buradaki ileri seviye yaklaşım, "mükemmel sterilite" vaat etmek değil; ne kadar steril olabildiğinizi ve nerede olamadığınızı dürüstçe yazmaktır.

4. Delil bütünlüğü ve delil zinciri: Güven, teknikten çok süreçle kazanılır

Delil bütünlüğünü "hash aldık" cümlesine indirgerseniz, en savunmasız yerden yakalanırsınız: zamanlama, erişim izleri ve açıklanamayan boşluklar.

4.1. Bütünlük doğrulamasında kritik ayrım: "alma anı" ve "doğrulama anı"

İleri pratikte bütünlük; en az iki anı görünür kılar:

• Delil alınırken üretilen bütünlük göstergesi (toplama raporu / kayıt)

• Delil daha sonra tekrar okunduğunda yapılan doğrulama ve eşleşme kaydı

Bu yaklaşım "matematiksel doğrulama"yı, "prosedürel izlenebilirlik"le birleştirir. Teknik raporun gücü, yalnızca değerin kendisinde değil; o değerin hangi koşulda üretildiğini taşımasındadır.

4.2. Chain of Custody (Delil zinciri): delilin biyografisi

RFC 3227, delil toplanırken zincirin korunmasını ve alınan her verinin bağlamıyla kayda bağlanmasını vurgular; ayrıca olay kayıtlarında zaman bilgisinin farklı sistemler arasında tutarsız olabileceğini hatırlatır.\ Bu yüzden delil zinciri, "kimin elinde ne kadar kaldı" sorusunu muğlak bırakmamalıdır. Bir zincir kaydı en azından şunları netleştirir:

• Delili kim aldı, ne zaman aldı (zaman dilimi belirtilerek)

• Nereden alındı (varlığın kimliği, konumu veya mantıksal karşılığı)

• Nerede saklandı / kime teslim edildi

• Kim erişti, hangi amaçla erişti

Dikkat: Zincirde açıklanamayan boşluklar, bulgunun teknik kalitesinden bağımsız olarak itiraza açık bir zemin doğurur. "Delil değişmedi" iddianızın zayıfladığı yer çoğu zaman analiz kısmı değil, süreç kayıtlarıdır.

4.3. Saklama ve "kurcalama anlaşılır" koruma

Delil yalnızca toplanmaz; tutulur. Saklama (retention) ve gerektiğinde hukuki saklama (legal hold) kararları, olayın teknik kısmı kadar kurumsal risk yönetimidir. Delile erişim kontrolü, erişim günlükleri ve kurcalanma anlaşılır (tamper-evident) paketleme yaklaşımı; delilin "ben buyum" iddiasını güçlendirir.

5. Delil paketleme: Bulguyu rapora taşınabilir hâle getirmek

Delil paketi, rapordaki iddiaların "kaynak + bütünlük + bağlam" teminatıdır. İyi bir paket, okuyucuya şu resmi net gösterir:

• Hangi kaynaklardan, hangi zaman aralığında ne gözlendi?

• Bu gözlemler hangi hipotezlerle ilişkilendirildi?

• Hangi karşı kanıtlar arandı, hangi ihtimaller elendi?

• Bu bulgular hangi kararları (izolasyon, geri dönüş, izleme) nasıl etkiledi?

5.1. Zaman çizelgesinde (timeline) kırılan yer: zamanın güvenilirliği

RFC 3227, farklı sistemlerin zaman bilgisinin birbirine uymayabileceğini ve bu tür tutarsızlıkların kayıt altına alınması gerektiğini özellikle hatırlatır.\ Bu nedenle timeline sadece sıralama değildir; aynı zamanda "bu zaman damgasına ne kadar güveniyorum?" sorusunun da taşıyıcısıdır. Zaman kayması, saat dilimi farkı, gecikmeli log akışı gibi unsurlar görünmez kalırsa, doğru verilerle yanlış hikâye yazmak mümkündür.

5.2. "Ham veri mi, aracı katman çıktısı mı?" sorusunun delil standardındaki yeri

Uzaktan toplama ve merkezi sistemler hız kazandırır; ama aracı katmanlar filtreleme/normalize etme ile bağlamı değiştirebilir. Bu yüzden delil paketi, verinin "hamlığa yakınlığını" ve aracı etkilerini şeffaf biçimde taşır.

5.3. Araç ekosistemi: araç değil yöntem savunulur

Adli bilişimde "sihirli değnek" yoktur. Ticari veya açık kaynak araçlar, raporlama ve indeksleme gibi alanlarda farklı avantajlar sunar; fakat profesyonel savunulabilirlik şuradan gelir:

• aynı bulguyu mümkünse ikinci bir yöntem/araçla doğrulamak,

• "araç öyle dedi" yerine "hangi veri yapısında hangi gözlemi yaptım ve nasıl doğruladım" diyebilmek.

Bu yaklaşım, hem hata (tool bug) riskini hem de tartışmalı bulguların itiraz edilebilirliğini düşürür.

6. Kısa vaka: Delil volatilitesi-iş etkisi-belirsizlik üçlüsüyle strateji tasarlamak

6.1. Senaryo

Mesai saatleri dışında bir çalışan cihazından, normalde erişmediği bir dosya sunucusuna oturum açıldığı ve beklenmedik büyüklükte veri aktarımı olabileceği yönünde sinyaller geliyor. Aynı zaman aralığında bir sunucuda olağandışı servis/oturum davranışı ve dış ağa kısa süreli bağlantı denemeleri görülüyor. Veri sızıntısı (ihlâl) henüz doğrulanmış değil.

6.2. Doğrulama çerçevesi: "Bunu çürütecek ne ararım?"

• Erişim örüntüsü meşru olabilir mi? Karşı kanıt: geçmiş davranış (baseline), yetki kapsamı, değişiklik/bakım kayıtları

• Sunucu sinyali planlı faaliyet olabilir mi? Karşı kanıt: bakım penceresi, dağıtım kanalı tutarlılığı, benzer sunucularda eşleşme

• Dış bağlantı denemeleri normal uygulama çağrısı mı? Karşı kanıt: tarihsel DNS/flow örüntüsü, hedeflerin kurumsal envanterle ilişkisi

6.3. Yöntem seçimi: "savunulabilir karar" nasıl görünür?

• Uçucu delil ihtiyacı varsa, ani kapatma bazı hipotezleri test etmeyi zorlaştırabilir.

• İş etkisi yüksekse, agresif izolasyon kesinti üretebilir.

• Belirsizlik sürüyorsa, geri dönüşsüz etkisi düşük seçeneklerle ilerlenir; belirsizlik karar günlüğünde açıkça taşınır.

Mobil veya kablosuz bağlı bir varlık söz konusu olduğunda, uzaktan müdahale/uzaktan silme gibi riskleri azaltmak için iletişimi kesmeye dönük izolasyon seçenekleri gündeme gelir. NIST'in mobil adli bilişim rehberi, cihazların dış dünyayla iletişimini sınırlamaya dönük önlemler (ör. ağ bağlantısının kesilmesi, radyo iletişiminin engellenmesi) çerçevesinde izolasyonun önemini tartışır.

6.4. Beklenen delil paketi çıktıları

• Kaynak haritası: Hangi veri nereden alındı, hangi zaman aralığı kapsandı

• IoC adayları: Kesinlik seviyeleriyle (doğrulanmış/şüpheli/bağlama bağlı)

• Ön timeline: Zaman güvenilirliği notlarıyla

• Karar günlüğü: Seçilen yöntemin gerekçesi, alınan riskler, bir sonraki doğrulama eşiği

Dikkat: Bu vaka "en hızlı sonuca ulaşma" yarışı değildir. Ölçülen şey, belirsizlikte bile delil standardını bozmadan karar üretebilme yeteneğidir.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Delilin “artefakt” olmaktan çıkıp “kanıt”a dönüşmesi için köken + bütünlük + bağlam üçlüsünü birlikte yönetmeyi
• Uçuculuk sırasını bağlamla tartıp, hipotez testini mümkün kılacak savunulabilir toplama stratejisi kurmayı
• Canlı toplama, kapalı sistem yaklaşımı ve uzaktan toplama arasında; delil volatilitesi–iş etkisi–belirsizlik dengesine göre seçim yapmayı
• Delil zincirini raporun denetlenebilirliğini taşıyan bir “biyografi” olarak tutmayı; zaman ve erişim boşluklarının nasıl risk ürettiğini
• Timeline ve delil paketlemede, gözlem–yorum ayrımı ve “neyi kanıtlamaz” sınırlarıyla raporu savunulabilir hâle getirmeyi

MODÜL 3 — İleri Olay Müdahalesi Yöntemleri ve Tehdit Avcılığı

Modül Teması

Olay müdahalesi sahada çoğu zaman "alarm geldi—bakıldı—kapandı" diye akar; fakat gelişmiş vakalarda asıl mesele, belirsizlik altında hızla karar alırken kanıt standardını düşürmemek ve yanlış kesinlik üretmemektir. Bu modül, tehdit avcılığını reaktif müdahalenin alternatifi gibi değil; kör noktaları aydınlatan, korelasyon kalitesini artıran ve bulguyu operasyonel karara bağlayan tamamlayıcı bir analiz disiplini olarak ele alır. "Bulgu var" demek yerine, bulgunun gerçekliğini sınama, karşı kanıt arama, aynı soruna farklı yöntemlerle yaklaşım seçimi ve çıktıyı denetlenebilir biçimde paketleme becerileri merkezdedir.

1. Proaktif ve reaktif yaklaşım: aynı hedef, farklı başlangıç noktası

Reaktif müdahale genellikle bir alarm veya bildirimle başlar ve hızla containment/eradication/recovery kararlarına bağlanır. Proaktif yaklaşım (tehdit avcılığı) ise "alarm yokken de" görünmeyeni arar: tespit boşluklarını görünür kılar, yeni korelasyon fikirleri üretir ve "bilinmeyen kötüyü" yakalayacak sinyalleri olgunlaştırır. Bu ayrımın pratik karşılığı şudur: Reaktif akış, zaman baskısı altında yürür; proaktif akış, belirsizliği azaltma hedefiyle yürür.

Gelişmiş saldırılar için kritik metriklerden biri "dwell time"dır: saldırganın ortamda tespit edilmeden kaldığı süre. Bazı raporlar bu sürenin sektör ve olaya göre değiştiğini, kimi kampanyaların haftalar/aylar ölçeğinde uzayabildiğini vurgular; bu yüzden avcılık, yalnız "ekstra iş" değil, tespit gecikmesini düşürmenin doğrudan bir yoludur.

"Assume breach" (sızıldığını varsay) yaklaşımı bu noktada bir slogan olarak değil, yöntem olarak anlam kazanır: "Kesin sızıldı" iddiası üretmek yerine, sızıntı varsayımını test edilebilir hipotezlere bölüp, her hipotez için doğrulanabilir/yanlışlanabilir kanıt hattı kurarsınız.

Dikkat: Avcılığın hedefi "her yere bakmak" değildir. Kör noktaları bulmak için geniş başlarsınız; ama ilerledikçe soruyu daraltıp kanıt standardını güçlendirmezseniz, belirsizlik büyür, operasyonel kararlar gecikir.

1.1. Avcılık reaktif müdahalenin neresinde durur?

Reaktif olaylarda avcılık çoğu zaman "kanıtı güçlendiren keşif" işlevi görür: alarmın taşıdığı iddiayı (gerçek ihlal mi, gürültü mü?) bağımsız veri hatlarından sınar. Tek bir araç sinyali "kanıt" değildir; kanıt, aynı iddiayı farklı bir gözle yeniden sınayabilmektir.

Örnek: Uç noktada şüpheli bir süreç sinyali görülüyor. Bu tek başına "zararlı çalışıyor" demek değildir. Aynı zaman penceresinde kimlik doğrulama kayıtları, ağ akışları ve uç nokta telemetrisi tutarlı bir hikâye kurmuyorsa, en doğru refleks "alarmı büyütmek" değil; iddiayı çürütebilecek veriyi aramaktır.

1.2. Ne zaman proaktif avcılık öncelik kazanır?

• Alarm kalitesi düşüktür; sinyaller zayıf ama tekrar eden örüntüler üretir.

• Bazı segmentler veya varlık sınıfları kör noktadır (görünürlük dengesizdir).

• Tehdit modeli değişmiştir; yeni TTP'ler için mevcut use-case'ler yetersiz kalır.

• Olay sayısı az görünse de risk yüksektir (kritik sistemler, hassas veri erişimleri).

Burada "kirli veride av yapılmaz" ilkesi pratik bir fren görevi görür: envanter yoksa, zaman senkronizasyonu zayıfsa, temel log hijyeni sağlanmamışsa avcılık verim yerine yanılsama üretebilir. Önce veri disiplinini toparlamak, sonra hipotezleri büyütmek daha sağlıklıdır.

1.3. Yöntem seçimi: reaktif mi proaktif mi, hibrit mi?

Aynı probleme birden fazla yolla yaklaşılabilir. Seçimi belirleyen üç değişken çoğu zaman şunlardır:

• Belirsizlik: İddianın kanıt düzeyi düşükse "hızlı karar" değil "hızlı doğrulama" seçilir.

• İş etkisi: Kesinti maliyeti yüksekse geri dönüşsüz müdahale seçenekleri sona bırakılır.

• Volatilite: Uçucu izler kaybolacaksa doğrulama için gerekli

minimum veri önce güvence altına alınır.

İpucu: Karar günlüğüne tek satır eklemek çoğu tartışmayı çözer: "Bu seçim hangi hipotezi test etmeyi mümkün kılıyor; hangi hipotezi artık test edemeyeceğiz?" Bu cümle hem yöntemi gerekçelendirir hem de raporu denetlenebilir kılar.

2. Threat hunting süreci: "bulduğunu büyütme" değil, "bulduğunu sınama"

Tehdit avcılığı rastgele log incelemesi değil; hipotez → veri kaynakları → av/pivot → doğrulama → çıktı döngüsünde ilerleyen bir analiz metodolojisidir. Olgun avcılığın ayırt edici tarafı şudur: hipotez yalnız "neyi arayacağım" demez, hangi koşulda zayıflayacağını da söyler.

2.1. Hipotez kurma: iddiayla birlikte çürütecek koşulları yazmak

Örnek: "Mesai dışı saatlerde belirli kullanıcı grubunda standart dışı dış bağlantılar artıyor; bu artış meşru bir bakım penceresiyle açıklanamıyor olabilir."
Bu hipotezi zayıflatabilecek karşı kanıtlar: planlı bakım kaydı, onaylı yazılım dağıtımı, benzer örüntünün çok sayıda cihazda 'beklenen davranış' olarak görünmesi.

Bu yaklaşım, avcılığı "şüpheli listeleme" işinden çıkarıp yanlış kesinliği azaltan bir doğrulama disiplinine taşır.

2.2. Veri kaynaklarını seçmek: "en çok veri" değil, "en bağımsız kanıt"

Hipotezi test ederken en güçlü yapı, aynı iddiayı destekleyen bağımsız kanıt hatları kurmaktır:

• Kimlik/oturum verileri (kim, ne zaman, nereden, hangi yetkiyle?)

• Uç nokta telemetrisi (süreç ilişkileri, kalıcılık izleri, dosya/registry davranışları)

• Ağ verisi (flow/PCAP, DNS/TLS ipuçları, periyodiklik)

• Sunucu/uygulama logları (erişim örüntüsü, sıra dışı hata/uyarı kümeleri)

• Bulut denetim logları (yönetim düzlemi çağrıları, IAM anomalileri)

Bu seçimin arkasında "observability" (gözlemlenebilirlik) mantığı vardır: Elinizdeki veri hangi davranışı gerçekten görünür kılıyor, hangisini yalnız tahmin ettiriyor? MITRE ATT&CK'in değerli kullanım biçimlerinden biri de budur: teknikleri saymak değil, eldeki veriyle hangi teknik sınıflarını denetlenebilir biçimde arayabileceğinizi görmek.

İpucu: Her veri kaynağı için bir cümle yazın: "Bu kaynak hipotezin hangi parçasını doğrular; hangi alternatif açıklamayı elemeye yarar?" Kaynağı "güzel veri" diye değil, "çürütebilir mi?" diye seçmek avcılığı olgunlaştırır.

2.3. Av ve pivot mantığı: yeni soru açmak, gürültüyü büyütmemek

Pivot, bir bulgudan hareketle aynı zaman penceresinde veya aynı varlık kümesinde yeni bir doğrulama sorusu sormaktır. Pivotun amacı, bulguyu "daha büyük" göstermek değil, yanlış yorumlamamak için alternatif açıklamaları elemek ve bağlamı netleştirmektir.

Örnek: Periyodik dış bağlantı örüntüsü gördünüz. Pivot soruları:
Aynı örüntü başka sistemlerde de var mı (meşru güncelleme/telemetri olabilir mi)?
Aynı anda kimlik tarafında olağandışı oturum var mı?
Uç noktada süreç bağlamı bu bağlantıyı beklenen bir uygulamaya mı bağlıyor?

Burada "long tail analysis" (uzun kuyruk) yaklaşımı işlevsel olabilir: sık görülen normal davranışları eleyip, nadir görülen örüntülere odaklanmak; fakat bu yöntemin güvenilirliği baseline kalitesine bağlıdır.

2.4. Doğrulama: "Bunu yanlışlayacak ne ararım?"

Doğrulama, bulguyu "kesin" yapmak değil; bulgunun taşıdığı iddiayı yanlışlanabilir kılmaktır. İki refleks birlikte çalışır:

• Karşı kanıt arama: Meşru açıklamalar için kanıt üretmek (değişiklik kaydı, onaylı yazılım, bakım penceresi, baseline uyumu).

• Bağımsız iz arama: Aynı iddiayı başka veri hattından teyit etmek.

Dikkat: "Araç bunu gösterdi" doğrulama değildir. Doğrulama, başka bir analistin aynı veri setiyle benzer akıl yürütmeyi yeniden kurabilmesidir.

2.5. Çıktı ve otomasyon: av bulgusu ya olaya, ya tespit mühendisliğine akar

Avcılık sonucunda:

• Gerçek bir tehdit doğrulanırsa, reaktif müdahale akışına kontrollü biçimde devredilir.

• Tehdit doğrulanmazsa ama hipotez değerliyse, üretilen analitik mantık tespit kuralına/use-case'e dönüşerek kurumsal hafızaya eklenir.

Negatif sonuç da bir çıktıdır: "Bu hipotez bu veri ve bu zaman penceresinde doğrulanmadı" demek, belirsizliği azaltır ve sonraki avların hedefini netleştirir.

3. MITRE ATT&CK ile haritalama: kanıt değil, kanıtın dili

ATT&CK, saldırgan davranışlarını ortak bir dilde ifade etmeyi sağlar; farklı ekiplerin aynı olayı farklı kelimelerle anlatıp yanlış anlaşılmasını azaltır. Ancak kritik ayrım şudur: haritalama kanıtın kendisi değil, kanıtın sınıflandırılmasıdır.

Haritalama yaptığınızda raporda iki şeyi açık tutmak güven verir:

• Eşlemenin dayandığı gözlenebilir veri nedir?

• Hangi alternatif açıklamalar altında bu eşleme zayıflar?

Örnek: "Kalıcılık" sınıfına giren bir iz gördünüz. Bu tek başına "kalıcılık vardır" hükmü değildir; izlerin kökeni, zaman penceresi ve meşru yönetim aracı olasılığı değerlendirilmeden etiket, kanıtın önüne geçer.

İpucu: Haritalamayı ana metinde tek cümlelik bir "ortak dil" olarak kullanıp, ayrıntılı teknik eşleştirmeyi eklerde tutmak çoğu zaman en iyi dengedir: karar verici hikâyeyi kaybetmez, teknik okur denetim malzemesine erişir.

4. Gelişmiş ihlal belirtileri: düşük sinyallerin doğru korelasyonu

Gelişmiş ihlal belirtileri çoğu zaman tek bir "kırmızı alarm" olarak gelmez; gürültülü ortamlarda düşük sinyallerin korelasyonuyla güçlenir. Burada amaç "daha çok anomali bulmak" değil; anomaliyi bağımsız hatlarla doğrulayıp yanlış-pozitif riskini yönetmektir.

4.1. Kimlik ve oturum anomalileri

"Olağandışı saat/lokasyon", "beklenmedik cihaz izi", "yetki kapsamı dışı erişim", "hesap geçişleri" gibi örüntüler güçlü sinyaller olabilir. Ancak VPN çıkışları, vardiya değişimleri, otomasyon hesapları, SSO yönlendirmeleri gibi meşru açıklamalar da sık görülür. Bu yüzden doğrulama refleksi "meşru mu?" sorusunu kanıtla cevaplamaktır: baseline, MFA olayları, cihaz envanteri, ağ mimarisi ve değişiklik kayıtları birlikte okunur.

4.2. Ağ beacon ve "jitter" ile gizlenen periyodiklik

Periyodik, düşük hacimli, az varyanslı dış iletişim C2 şüphesi doğurabilir; fakat lisans kontrolü, telemetri ve güncelleme bileşenleri de benzer ritimler üretebilir. "Jitter" kavramı burada devreye girer: periyodikliği gizlemek için aralıklara rastgele sapma eklenebilir; bu yüzden analist, "tam düzen" aramak yerine varyans ve tutarlılık üzerinden düşünür.

4.3. Kalıcılık işaretleri ve "normalden sapma"

Kalıcılık mekanizmaları hem saldırganlar hem de yönetim araçları tarafından kullanılabildiği için "var" demek yetmez. "Ne zamandır var, kim dağıttı, envanterde yeri var mı, baseline ile uyumlu mu?" soruları kanıt üretir. Scheduled task veya servis gibi nesnelerde isim benzerliği aldatıcı olabilir; asıl ayırt edici olan, zaman penceresi, sahiplik, dağıtım kaydı ve güvenilirlik göstergeleridir.

Bazı süreç anomalilerinde de aynı yaklaşım geçerlidir: Örneğin belirli sistem süreçlerinin olağandışı bir ebeveyn bağlamıyla başlaması şüphe doğurabilir; ama bu tür sinyaller "kesin" diye sunulmak yerine, ek kanıt hatlarıyla desteklenmelidir. Bazı üretici dokümanları, beklenmeyen ebeveyn-çocuk süreç ilişkilerini korelasyon kuralı olarak ele alır; bu da yaklaşımın "tek sinyal değil, korelasyon" olması gerektiğini hatırlatır.

Dikkat: Gürültülü ortamda en tehlikeli hata, tekil bir sinyali "kesin ihlal" diye yorumlamaktır. Doğru refleks, sinyali çoğaltmak değil; sinyali bağımsız hatlardan doğrulamaktır.

5. Uygulamalı av senaryosu: hipotez → doğrulama → delil standardı → operasyonel karar

Aşağıdaki vaka, hipotez temelli avcılığın nasıl yürütüldüğünü ve çıktının nasıl "karar verilebilir" hâle getirildiğini birleştirir.

5.1. Senaryo

Kurumsal ortamda mesai sonrası saatlerde bazı uç noktalarda kısa süreli dış bağlantı artışı gözleniyor. Bağlantıların bir kısmı 198.51.100.0/24 bloğunda belirli uç noktalarda kümeleniyor. Aynı zaman penceresinde bazı cihazlarda beklenmedik süreç davranışları raporlanmış; fakat olay henüz "ihlâl" olarak doğrulanmış değil. Ayrıca sektör genelinde ofis dokümanları üzerinden uzaktan erişim ajanı benzeri davranışların görüldüğüne dair güncel istihbarat notları bulunuyor.

5.2. Hipotez ve karşı kanıt tasarımı

Hipotez: "Bazı uç noktalarda uzaktan erişim/ajan benzeri yetkisiz bir aktivite olabilir."

Hipotezi zayıflatabilecek karşı kanıtlar:

• Dış uç noktanın onaylı bir hizmet/tedarikçi altyapısına ait olduğunun doğrulanması

• Bağlantıların yalnızca envanterde yer alan meşru bir bileşen tarafından üretilmesi

• Zaman penceresinin planlı dağıtım/bakım aktivitesiyle çakışması ve değişiklik kaydıyla desteklenmesi

5.3. Veri kaynakları ve yöntem seçimi

Bu hipoteze farklı yollardan gidilebilir; ileri seviyede amaç "en hızlı sonuç" değil, en az varsayım ve en bağımsız kanıt üretmektir:

• Ağ tarafında örüntünün periyodiklik, hedef çeşitliliği ve benzer davranışların yaygınlığı incelenir.

• Uç nokta telemetrisiyle süreç-ağ ilişkisinin tutarlılığı değerlendirilir (bağlantıyı hangi bağlam üretmiş görünüyor?).

• Kimlik kayıtlarıyla "bu saatlerde bu kullanıcılar normalde ne yapar?" sorusu baseline'a karşı sınanır.

Burada kritik eşik şudur: Ağ örüntüsü güçlü, uç nokta bağlamı zayıfsa iddia kırılgan kalır; tersi durumda ağ örüntüsü gürültü olabilir. Yöntem seçimi bu yüzden "tek kaynağa yaslanma" değil, kaynakların birbirini sınayacak şekilde kurgulanmasıdır.

5.4. Doğrulama: güçlendiren ve zayıflatan koşulları birlikte yönetmek

Güçlendiren: aynı zaman penceresinde kimlik anomalisi + süreç bağlamında sapma + dış bağlantı örüntüsü birlikte görülür.\ Zayıflatan: bağlantının onaylı uygulamayla açıklanması + değişiklik kaydı + benzer örüntünün yaygın ve beklenen davranış olarak görünmesi.

Örnek: İncelenen cihazların bir kısmında dış bağlantı "meşru güncelleme/telemetri bileşeni" ile tutarlı; diğer bir kısmında bağlantının süreç bağlamı belirsiz ve kimlik tarafında da sıra dışılık var. Bu durumda tek bir hikâye uydurmak yerine iki hipotezi paralel yönetmek gerekir: (i) beklenen güncelleme davranışı, (ii) olası yetkisiz ajan aktivitesi.

5.5. Çıktı: raporlanabilir delil paketi ve karar dili

Beklenen çıktılar:

• Bulgu özeti: ne gözlendi, hangi kaynaklardan, hangi zaman aralığında

• Kesinlik notları: doğrulanmış / şüpheli / bağlama bağlı

• Ön zaman çizelgesi: kaynaklar arası zaman güvenilirliği, saat dilimi ve olası kaymalar not edilerek

• Haritalama eki: davranışların ATT&CK diliyle sınıflandırılması; bunun kanıt değil sınıflandırma olduğunun açık tutulması

• Operasyonel öneri: containment seçeneklerinin risk-etki-belirsizlik dengesiyle gerekçelendirilmesi (kesinti riski, kanıt volatilitesi, kapsam genişletmenin maliyeti vb.)

İpucu: Av raporunun en üstüne iki cümle yazmak raporu "sonsuz arama" olmaktan çıkarır: "Bu çalışma hangi soruya cevap aradı?" ve "Hangi yeni soruları doğurdu?" Böylece hem kapsam yönetilir hem de çıktılar ölçülebilir hâle gelir.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Avcılığın reaktif müdahaleyi yavaşlatan bir “lüks” değil, doğru kurgulandığında kanıtı güçlendiren hedefli bir yöntem olduğunu
• Hipotezleri yanlışlanabilir kurmanın ve karşı kanıt aramanın yanlış kesinliği ve yanlış-pozitifleri azalttığını
• Veri kaynaklarını “çok veri” diye değil, bağımsız kanıt hatları olarak seçmenin karar kalitesini yükselttiğini
• ATT&CK haritalamasının kanıt değil, kanıtı standardize eden bir dil olduğunu ve raporda bu ayrımın güven ürettiğini
• Dwell time gerçekliğinin, proaktif avcılığı kurum olgunluğu için stratejik hâle getirdiğini
• Avcılık çıktısını delil standardına uygun paketlemenin (gözlem–yorum ayrımı, timeline tutarlılığı, yeniden üretilebilirlik) operasyonel kararları daha savunulabilir kıldığını

MODÜL 4 — Olay Esnasında Delil Toplama ve Canlı Müdahale

Modül Teması

Olay müdahalesinin en kritik ve en riskli safhası, sistem hâlâ çalışırken yapılan müdahaledir. "Sıcak sistem" üzerinde bir yandan tehdidi büyütmeden kontrol altına almak, diğer yandan uçucu delili kaybetmeden, adli bütünlüğü koruyarak ilerlemek gerekir. Bu modül; kapatma/izolasyon kararının nasıl gerekçelendirileceğini, canlı sistemden toplanan verinin nasıl doğrulanacağını ve tüm çıktıların denetlenebilir bir delil paketine nasıl dönüştürüleceğini ele alır.

1. İlk Müdahale Checklist: Karar Anı

Olay yerine vardığınız an (uzaktan ya da fiziksel), bir "triayj doktoru" soğukkanlılığı gerektirir: her hareketin bir bedeli vardır ve panik, delil kaybının en büyük sebebidir. Bu nedenle ilk kontrol listesi "yapılacaklar"dan çok, belirsizlik altında karar vermeyi standardize eden bir düşünme iskeletidir.

1.1. Öncelik üçgeni: risk - uçuculuk - iş etkisi

• Risk: Tehdit sürüyor mu? Yayılım, veri sızdırma, yetki suistimali gibi zararlar hâlâ aktif mi?

• Uçuculuk: Kaçırırsanız geri gelmeyecek izler var mı? Oturumlar, ağ durumları, bellek içi bulgular ve geçici artefaktlar hızla değişebilir.

• İş etkisi: Kesinti bedeli nedir? Kritik servis mi, üretim mi, müşteri etkisi var mı? Bazı ortamlarda "yanlış bir kapatma" doğrudan büyük zarardır.

1.2. Kesmek mi, izlemek mi?

Klasik refleks "hemen kabloyu çek" olabilir; fakat modern tehditler bazen bellekte yaşar (dosya izi bırakmadan) veya bağlantı kesildiğinde davranış değiştirip delili zayıflatabilir. Buna karşılık bazı saldırı tiplerinde (ör. anlık zarar üreten durumlarda) öncelik "kanıt" değil "zararı durdurmak" olabilir. İleri seviye analistin işi, bu ikisini aynı anda tartıp gerekçelendirmektir.

1.3. Akıllı izolasyon fikri

Tam koparma yerine, saldırganın dışarıyla etkileşimini keserken olay müdahale ekibinin sistem üzerinde kontrol ve gözlem yapabilmesini sağlayan "akıllı izolasyon" yaklaşımı bazı senaryolarda işlevseldir. Buradaki kritik nokta, bunun teknik bir numara değil; iş sürekliliği + kanıt bütünlüğü + güvenlik riski dengesini gözeten bir yöntem seçimi olduğudur.

Dikkat: Canlı sisteme dokunduğunuz an, sistem değişir. Bu, fiziksel dünyadaki Locard değişim prensibinin dijital karşılığıdır: "temas iz bırakır." Amaç iz bırakmamak değil; minimum müdahale ile maksimum açıklanabilirlik üretmek ve bıraktığınız izi belgeleyebilmektir.

1.4. Uçucu delil önceliği

Canlı müdahalede tipik sıralama; ortamın koşullarına göre değişse de, uçucu delilin önce güvenceye alınması mantığıyla kurulur. Ekrandaki durumun kaydı, bellek ve kısa ömürlü canlı triyaj verileri, daha sonra disk edinimi gibi daha ağır ve uzun işlemlere zemin hazırlar.

İpucu: İlk dakikalarda "karar günlüğü" tutmak, teknik bir alışkanlık değil, delil standardının parçasıdır. Zaman, alınan karar, gerekçe, onaylayan kişi/rol gibi kısa notlar; ekip içi uyumu artırır ve sonradan denetimde "neden böyle yaptınız?" sorusuna savunulabilir cevap üretir.

Örnek: Mesai saatleri dışında bir sunucuda dış bağlantı artışı görülüyor. Bir yandan yayılım riski var, diğer yandan kapatma kararı uçucu delili yok edebilir. Bu durumda karar; aynı zaman penceresinde kimlik kayıtlarında olağandışı oturum olup olmadığı, uç nokta telemetrisinin süreç-ağ ilişkisinde sapma gösterip göstermediği ve kesinti maliyetinin kabul edilebilirliği birlikte değerlendirilerek verilir. Kayıt altına alınmayan "sezgisel" hamleler, doğru olsa bile sonradan savunması zor bir zemin bırakır.

2. Canlı Sistem Analizi: "Canlı Cerrahi" Disiplini

Canlı analiz, otopsi değil; canlı cerrahidir. Amaç "şüpheli bir şey bulmak" değil, her gözlemi bir iddiaya dönüştürmeden önce sınayabilmektir. İleri seviyede iyi bulgu, kendisiyle birlikte karşı kanıt arayışını da taşır.

2.1. Gözlem-yorum ayrımı

• Gözlem: Ham veri (ör. beklenmedik süreç zinciri, anormal ağ durumu, olağandışı oturum bağlamı).

• Yorum: Bu ham verinin anlamı (ör. yetkisiz uzaktan erişim, bellek içi yük, kalıcılık şüphesi). Rapor güvenilirliği, bu ikisinin birbirine karışmamasına bağlıdır.

2.2. Süreç bağlamı: ebeveyn-çocuk ilişkisi ve meşru açıklamalar

Süreçleri "adı" üzerinden yargılamak yanıltıcıdır. Aynı isim, farklı konum, farklı imza durumu veya farklı ebeveyn bağlamında bambaşka anlam taşır. Bu nedenle doğrulama; konum, imza, başlatan bağlam ve zaman çizelgesi tutarlılığı üzerinden yürür.

2.3. Ağ durumu: aktif bağlantılar kadar "artıklar" da konuşur

Canlı ağ durumu yalnız "şu an aktif" olanı değil, "az önce olmuş" olanı da gösterebilir. Yeni kapanmış bağlantıların izleri, saldırganın kısa süreli temaslarının geride bıraktığı son ipuçları olabilir. Burada da tek başına "bir IP gördüm" demek yetmez; aynı zaman penceresinde süreç bağlamı ve kimlik olaylarıyla korelasyon aranır.

2.4. Dosyalar, ikililer ve tutamaçlar (handles)

Saldırgan diskten bir dosyayı silmiş olabilir; fakat süreç hâlâ çalışıyorsa, o dosyaya ilişkin izler bellek ve süreç-kaynak ilişkileri üzerinden hâlâ yakalanabilir. Canlı müdahale; diskte "görünmez" olanın, sistem durumunda "görünür" kalabildiği bu noktada değer kazanır.

Dikkat: Uzak masaüstü gibi etkileşimli erişim yöntemleri, olay yerini "kirletme" riskini artırabilir: yeni oturumlar, ek günlük kayıtları ve beklenmedik yan etkiler üretir. Canlı müdahale yaklaşımı, mümkün olduğunda daha kontrollü ve izlenebilir kanallar üzerinden yürütülmelidir; hangi yöntemin seçildiği ise raporda gerekçeli biçimde yazılmalıdır.

İpucu: Canlı analiz notlarını "kanıt paketi" mantığıyla tutun. Her bulgu için aynı anda üç parçayı yazmak, hem doğrulamayı hem raporlamayı kolaylaştırır:

1. 1)Gözlem (ne görüldü?),
2. 2) Yorum (hangi hipotezle tutarlı?),
3. 3) Karşı kanıt (hangi masum açıklama test edilecek/edildi?).

Örnek: Bir iş istasyonunda kısa aralıklarla 203.0.113.0/24 bloğunda tek bir uç noktaya tekrarlayan bağlantı örüntüsü görülüyor. Bu, otomatik olarak "komuta-kontrol" anlamına gelmez. Doğrulama için; aynı zaman aralığında oturum hareketliliği, bu bağlantıyı üreten süreç bağlamı ve benzer örüntünün başka sistemlerde "normal" olup olmadığı birlikte sınanır. Bulguyu rapora taşırken bağlantı örüntüsü gözlem olarak yazılır; "C2 olabilir" ifadesi yorum olarak ve gerekçesiyle birlikte belirtilir.

3. Bellek Alma (RAM Acquisition): En Zengin, En Kırılgan Bölge

RAM, dijital olay yerinin en zengin ama en kırılgan parçasıdır: geçici kimlik izleri, çalışma anındaki süreç bağlamı, bazı anahtar materyalleri, oturum durumları ve uygulama içi geçici veriler burada görülebilir. Bu yüzden bellek edinimi, doğru zamanda yapılırsa olayın "o anki fotoğrafını" yakalamaya en yakın araçtır; yanlış yönetilirse iş sürekliliği ve delil bütünlüğü açısından risk doğurur.

3.1. Bütünlük gerçeği: bellek değişir

Bellek sürekli değiştiği için, edinimin "an"ı kritik önemdedir. Bütünlük doğrulaması yapılırken, edinim aracının ürettiği kayıtlar (edinim günlüğü gibi) ve süreç boyunca hata/uyarı üretip üretmediği özellikle değerlidir. Burada amaç, "mükemmel donmuş bellek" iddiası değil; edinimin koşullarını şeffaf biçimde belgeleyerek denetlenebilirlik sağlamaktır.

3.2. Kernel etkisi ve çökme riski

Bellek edinimi, düşük seviyeli bileşenlerle etkileşime girebilir; nadiren de olsa sistemin kararsızlaşmasına yol açma ihtimali vardır. Kritik sistemlerde bu risk, toleransla birlikte değerlendirilir.

3.3. Yöntem seçimi: kritik sistemlerde alternatif düşünme

Bazı ortamlarda "çökme toleransı" yoktur. Böyle durumlarda bellek edinimi için seçilecek yaklaşım, operasyonel gerçeklik ve risk iştahına göre farklılaşır; canlı edinim yerine, sistemin kendi mekanizmalarının ürettiği bellek temsilleri veya sanallaştırma katmanındaki imkânlar alternatif olabilir.

3.4. Sanal ortam avantajı

Sanal makinelerde, hipervizör seviyesinde alınan askıya alma/anlık görüntü çıktıları, konuk işletim sisteminin içine müdahale etmeden bellek temsili sağlayabilir. Bu yaklaşımın değeri, hem olay yerini daha az kirletmesi hem de saldırganın analiz edildiğini "fark etme" ihtimalini azaltmasıdır.

Dikkat: Bellek edinimi "iş bitti" demek değildir. RAM bir kesittir; yorum, tek başına kesin hüküm üretmek yerine bağımsız veri hatlarıyla doğrulanmalıdır.

Örnek: Kritik bir sunucuda olağandışı oturum hareketliliği ve dış bağlantı örüntüsü aynı anda görülüyor. Kesinti maliyeti yüksekse, ani kapatma yerine önce bellek edinimiyle uçucu izleri güvenceye alıp, ardından izolasyon/containment seçeneklerini kanıt temelli tartışmak çoğu zaman daha savunulabilir bir çizgidir.

4. Disk İmajı (Live Acquisition) ve Kapsam: "Zamanla Yarış"

Canlı sistemden disk edinimi, dosya sisteminin değişmeye devam ettiği bir ortamda yapılır. Bazı dosyalar kullanımda olabilir, kilitli olabilir; ayrıca işlem, performans etkisi doğurabilir. Bu nedenle disk edinimi; teknik doğruluktan çok kapsam ve yöntem seçimi becerisini sınar.

4.1. Format ve temsil: ham kopya mı, adli kapsayıcı mı?

Disk edinimi formatları, yalnızca "dosya uzantısı" değildir; bütünlük, parçalara bölme, metadata taşıma ve saklama/taşıma süreçlerini etkiler. Seçim, olayın denetim/hukuki beklentisi ve operasyonel zaman kısıtıyla birlikte gerekçelendirilir.

4.2. Kapsam: tam imaj mı, hedefli toplama mı?

• Tam imaj daha geniş analiz imkânı sunar; fakat zaman, depolama ve iş etkisi maliyeti yüksektir.

• Hedefli toplama kriz anında hız sağlar; saldırıyı aydınlatan kritik artefaktlara odaklanır. Ancak bağlam kaçırma riski vardır; bu yüzden seçimin sınırları raporda açıkça yazılmalıdır.

4.3. Kilitli dosyalar ve anlık görüntü yaklaşımı

Çalışan sistemlerde bazı veriler doğrudan okunamayabilir. Bu noktada işletim sisteminin anlık görüntü mekanizmaları, kilitli veriyle çalışmayı mümkün kılan bir köprü işlevi görebilir. Burada amaç, "her şeyi alırım" iddiası değil; adil, tekrar edilebilir ve denetlenebilir bir edinim stratejisi kurmaktır.

İpucu:Kapsam tartışmasını "sonradan analiz" değil, "sonradan iddia" açısından yapın: "Bu kapsam, hangi iddiaları kanıtlayabilir; hangi iddiaları artık kanıtlayamayız?" Bu cümle, hedefli toplamanın sınırını dürüstçe rapora taşır ve yanlış kesinliği azaltır.

Örnek: Büyük bir dosya sunucusunda yalnız belirli bir uygulama dizininde şüpheli izler görülüyor. Hedefli toplama hızlıdır; ancak olayın kimlik ve ağ boyutu olabileceği düşünülüyorsa, yalnız dizini almak "dosya var"ı gösterebilir ama "nasıl geldi, ne zaman çalıştı, başka nerelere dokundu" sorularını zayıflatır. Bu nedenle kapsam, hipotezin genişliğiyle uyumlu seçilir.

5. Ölçekli Toplama (Enterprise Forensics): Merkezi Triyaj ve Delil Havuzu

Kurumsal olaylarda saldırgan çoğu zaman tek makinede kalmaz. Yüzlerce uç noktadan veri toplayabilmek, modern DFIR'in temel kabiliyetidir. Burada başarı; "çok veri" değil, tutarlı, karşılaştırılabilir ve denetlenebilir veri seti üretmektir.

5.1. Merkezi triyaj mimarisi

EDR benzeri platformlar veya kurumsal toplama çerçeveleri; merkezi bir noktadan çok sayıda uç noktada aynı standardı uygulamayı mümkün kılar. Bu, bir "delil havuzu" oluşturur: veriler zaman damgalı, kaynağı belli, formatı tutarlı şekilde toplanır ve daha sonra korelasyon için güvenilir zemin sağlar.

5.2. Standart toplama profili (triage profile)

Kurumsal ölçekte en büyük risk, veri setinin kirlenmesidir. Farklı makinelerden farklı artefakt setleri toplanırsa, yatay hareketlilik gibi kritik sorular takip edilemez. Bu nedenle şüpheli sistemlere aynı "toplama profili" uygulanır: hangi artefaktlar, hangi zaman penceresi, hangi etiketleme standardı...

5.3. Yöntem seçimi: geniş tarama mı, derin toplama mı?

• Geniş tarama: Çok sistemden sınırlı veriyle yayılım resmini çıkarır, hipotezleri daraltır.

• Derin toplama: Az sayıda kritik düğümde güçlü kanıt üretir, kök nedenin peşine düşer.\ İleri pratikte en iyi sonuç çoğu zaman hibrittir: önce geniş tarama ile "nerede derinleşeceğini" seçmek, sonra derinleşerek kanıtı güçlendirmek.

Dikkat: Ölçek büyüdükçe yanlış-pozitif maliyeti artar. Tek bir makinede anormal görünen örüntü, bin makinede normal olabilir. Bu yüzden kurumsal triyaj her zaman baseline ve varlık bağlamıyla birlikte yürür.

Örnek: Beş departman cihazında benzer dış bağlantı örüntüsü var. Önce merkezi triyaj ile örüntünün yaygınlığı, ortak bağlamı ve zaman penceresi çıkarılır. Ardından seçilen iki kritik cihazda canlı analiz + uçucu delil odaklı edinimle iddia güçlendirilir. Böylece "hepsine aynı anda derin dalma" refleksi yerine yönetilebilir ve savunulabilir bir plan oluşur.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• İlk dakikalarda panik yerine triayj disipliniyle hareket edip, kararları risk–uçuculuk–iş etkisi dengesiyle gerekçelendirebilme
• Canlı analizde gözlem–yorum ayrımını koruyarak, bulguları karşı kanıt ve bağımsız izlerle doğrulayabilme
• RAM ve canlı disk ediniminde yöntem/kapsam seçimini “en çok veri” refleksi yerine savunulabilirlik ve operasyonel gerçeklikle yönetebilme
• Kilitli/veri değişen ortamlarda edinimi teknik imkânlar kadar delil standardı açısından da tasarlayabilme
• Kurumsal ölçekte merkezi triyaj, standart toplama profili ve delil havuzu yaklaşımıyla tutarlı veri seti üretebilme

MODÜL 5 — Disk ve Dosya Sistemi Adli Analizi (Timeline Odaklı)

Modül Teması

Bu modül, disk adli analizini "tek tek artefakt bulma" refleksinden çıkarıp olayın zaman çizelgesini kuran, denetlenebilir bir kanıt üretim disiplinine taşır. Modern olaylarda izler çoğu zaman tek bir logda "parlamaz"; dosya sistemi meta verileri, journaling kayıtları, uygulama artıkları, silme davranışının kalıntıları ve snapshot'ların birlikte okunduğu yerde netleşir. Buradaki hedef, "ne buldum?" kadar "bulduğum şey gerçekten neyi kanıtlıyor?" sorusuna sağlam cevap verebilmektir.

1. Dosya sistemini "iz üreten makine" gibi okumak

1.1. NTFS: MFT ve öznitelik katmanı

NTFS'te Master File Table (MFT), her dosya/dizin için bir kayıt tutan merkezî yapı olduğundan, bir nesnenin içeriği silinse bile "orada bir şey vardı"ya dair meta veri izleri bir süre daha yaşamaya devam edebilir. Adli açıdan kritik nokta, MFT'yi "dosya listesi" olarak görmek değil; hangi eylemin hangi iz düzenini ürettiğini okumaktır.

NTFS'in öznitelik (attribute) yaklaşımı, aynı dosya için birden fazla zaman ve bağlam bilgisinin farklı alanlarda tutulmasına yol açar. Bu da tek bir zaman damgasına bakıp hüküm vermeyi riskli hâle getirir. Özellikle küçük içeriklerin "resident" olarak MFT kaydının içinde tutulabildiği durumlar, veri alanı taramalarında gözden kaçabilecek bulgular doğurur; bu pratikte, "dosyayı bulamadım" ile "dosya yoktu" arasına temkinli bir mesafe koymayı gerektirir.

Dikkat: Bir dizinde yüzlerce dosyanın aynı kısa pencerede "değişmiş" görünmesi, otomatik olarak kötü niyetli bir senaryo demek değildir. Yedekleme/indeksleme/dağıtım işleri benzer örüntüler üretebilir. İddia kurarken, aynı zaman aralığında meşru bakım faaliyeti olasılığını eleyecek karşı kanıtı arayın.

Örnek: Bir kullanıcının "hiç dokunmadım" dediği bir klasörde çok sayıda dosyada kısa süreli güncellenme görülüyor. Bu tabloyu "toplu manipülasyon" diye yazmadan önce; güncelleme penceresinin yazılım güncellemesi, arama indekslemesi veya kurumsal senkronizasyonla çakışıp çakışmadığına bakılır. Rapor dili "gözlem: şu zaman aralığında yoğun meta veri güncellenmesi" ile başlar; "yorum: olası nedenler" kısmı ayrı tutulur.

1.2. NTFS journaling: $LogFile ve $UsnJrnl ile "eylem kanıtı"

NTFS Change Journal (USN Journal), dosya sistemi üzerinde gerçekleşen değişimleri kayıtlayan bir mekanizmadır; "dosya artık yok" durumlarında bile silme/yeniden adlandırma/taşıma gibi eylemlere dair kalıntılar, olay örgüsünü güçlendirebilir. Bu yüzden USN Journal, "bulamadığım dosyanın başına ne geldi?" sorusunda değerli bir çapraz doğrulama kaynağıdır.

İpucu: "Dosyayı bulamadım" çıktısını tek başına sonuç diye yazmak yerine, aynı zaman penceresinde eylemi destekleyen iz (ör. değişim kaydı) var mı diye bakın. Böylece "içerik yok" durumunu bile timeline'a kanıtlı bir madde olarak taşıyabilirsiniz.

2. Ana artefaktlar: iddia-kanıt eşlemesiyle seçmek

Orta seviyede artefaktların temel listesini ve nerede olduklarını ayrıntılı işlemiştik; burada kritik olan, her artefaktın hangi iddiayı güçlendirebildiğini ve hangi koşulda zayıfladığını bilmektir.

2.1. Windows: çalıştırma, etkileşim ve "silme davranışı"

• Prefetch / çalıştırma izleri: "Dosya vardı" ile "dosya çalıştı" arasında delil değeri açısından büyük fark vardır. Prefetch sınıfı izler çalıştırma hipotezini güçlendirebilir; ancak sistem politikaları ve bazı senaryolar (özellik kapalı, farklı yürütme bağlamları) nedeniyle "yokluğu", "çalışmadı" anlamına otomatik gelmez.

• LNK / Jump List benzeri etkileşim artıkları: Kullanıcının bir dosyaya dokunması, kopyayı başka yerde görseniz bile, etkileşim izleri bırakabilir. LNK analizleri; orijinal yol, bazı MAC zamanları ve bağlantının işaret ettiği konum hakkında meta veriler taşıyabildiği için "erişildi mi?" sorusunda değerlidir; ayrıca bazı durumlarda volume adı/seri numarası gibi çevresel bilgileri de içerebilir.

• ShimCache / Amcache (evidence of execution ailesi): "Bu ikili sistemde görüldü mü?" sorusunu destekleyebilir; fakat tek başına suçlayıcı bir kesinlik üretmek yerine, diğer yürütme/etkileşim izleriyle birlikte ele alındığında sağlamlaşır.

• $Recycle.Bin ve silme zinciri: Silmenin kendisi bir "eylem"dir; kullanıcının "yanlışlıkla sildim" iddiası ile "izleri ortadan kaldırma" hipotezi aynı cümleye sığdırılamaz. Silme davranışının hangi oturum bağlamında, hangi zaman aralığında ve hangi diğer izlerle beraber gerçekleştiği timeline'da ayrı ayrı test edilmelidir.

Dikkat: "Artefakt var → ihlal var" gibi doğrusal cümleler raporu kırılganlaştırır. Denetimde en hızlı çöken yer, masum açıklama olasılığını hiç test etmeden kurulan kesin yargılardır.

Örnek: Bir yürütülebilir dosyaya ait çalıştırma izleri görülüyor. Bu durum, "çalıştırılmış olabilir" hipotezini güçlendirir. Aynı pencere için kullanıcı oturumu var mı, dosya yolu tutarlı mı, eşzamanlı kurumsal dağıtım var mı, benzer izler başka makinelerde de aynı anda mı çıkıyor gibi sorularla masum açıklama elenir; rapora da "gözlem" ve "yorum" ayrı düşülür.

2.2 Linux: kimlik, komut etkileşimi ve zamanlanmış eylemler

• auth kayıtları: Oturum açma, yetki yükseltme ve kimlik doğrulama davranışı, dosya sistemi değişikliklerini kime bağlayabileceğiniz konusunda güçlü bir çerçeve sağlar.

• shell history: Etkileşimli komut geçmişi değerli olabilir; ama eksik kalabilir ya da manipüle edilebilir varsayımıyla okunmalıdır. "History'de var" ifadesi tek başına kanıt değil; aynı iddiayı destekleyen servis izleri, dosya sistemi değişim örüntüsü ve kimlik loglarıyla güçlenir.

• cron/systemd izleri: "Kendiliğinden oldu" iddialarını test ederken zamanlanmış iş/süreç davranışını timeline'a bağlamak kritik rol oynar.

İpucu: Linux tarafında tek bir kaynağın "hakem" olmasına izin vermeyin. Aynı iddiayı en az bir kimlik izi (auth), bir zamanlanmış/servis izi (cron/systemd) ve bir dosya sistemi değişim izi ile çaprazlayınca yanlış pozitif ciddi düşer.

3. Timeline üretimi: zamanın semantiğini yönetmek

Timeline, DFIR'de anlatının iskeletidir: bulguları tek tek sıralamak yerine, neden-sonuç ilişkisini ve karar noktalarını görünür kılar. İleri seviyede asıl değer, timeline üretmekten çok tutarsızlığı yönetebilmekte ortaya çıkar.

3.1. MACB ve "hangi zaman neyi anlatır?" sorusu

Dosya sistemleri farklı zaman kavramlarını (içerik değişimi, meta veri değişimi, erişim, oluşturma) ayrı ayrı tutar. Bu fark, "dosya değişti" iddiasını kurarken kritik bir ayrımdır: içerik mi değişti, yoksa isim/izin/konum gibi meta veri mi?

3.2. Zaman tutarsızlığı: önce masum açıklama, sonra anti-adli ihtimal

Timezone, yaz saati uygulaması, NTP sapması veya farklı kaynakların farklı zaman semantiği, aynı olayı "çelişkili" gösterebilir. Bu yüzden ilk refleks "timestomping var" demek değil; saat doğruluğu ve normalizasyon kararları üzerinden tutarlılık testi yapmaktır.

NTFS'te iki farklı zaman setinin ($STANDARD_INFORMATION ve $FILE_NAME) bulunabilmesi ve bazı anti-adli manipülasyonların bu alanlar arasında tutarsızlık bırakabilmesi, doğrulamada çok işe yarar; fakat bu gözlem bile tek başına "kesin" yazılmamalıdır. Çünkü yeniden adlandırma/taşıma gibi meşru işlemler de bazı zaman alanlarını farklı şekillerde etkileyebilir; bu yüzden tutarsızlık görüldüğünde, aynı olayın USN gibi değişim kayıtlarıyla veya başka artefaktlarla desteklenip desteklenmediği aranır.

Dikkat: "Timestomping" şüphesi, ancak normalizasyon + meşru açıklamalar elendikten sonra anlam kazanır. Anti-adli bölümde (Modül 11) bu sinyallerin nasıl bir araya getirileceğini daha geniş ele alacağız.

Örnek: Bir dosyada "çok eski" bir oluşturma zamanı görülüyor, ama aynı zaman aralığında ilişkili değişim kayıtları ve kullanıcı etkileşim izleri daha yeni bir pencereyi işaret ediyor. Burada rapora "zaman alanları arasında tutarsızlık" gözlemi yazılır; yorum kısmında meşru olasılıklar (taşıma/yeniden adlandırma, saat sapması) ve anti-adli olasılık, hangi karşı kanıtlarla test edildiğiyle birlikte değerlendirilir.

3.3. Süper-timeline: çok kaynağı tek anlatıda birleştirmek

Dosya sistemi artefaktları, kimlik ve uygulama izleriyle bir araya geldiğinde "tek bir logun söyleyemediğini" anlatır. Plaso/log2timeline gibi yaklaşımlar, farklı kaynaklardan zaman olaylarını çıkarıp ortak bir zaman çizelgesine taşıyan çerçevelere örnektir; ölçek büyüdükçe bu tür birleştirme pratikte vazgeçilmez hâle gelir.

Araç/yöntem seçiminde şu dengeyi kurarsınız:

• Ölçek büyükse ve hızlı resim gerekiyorsa: otomasyon + görselleştirme, geniş resmi çıkarır.

• Kanıt standardı yüksekse: ham kaynakların saklanması, normalizasyon kararlarının yazılması, filtreleme mantığının belgelenmesi şarttır.

• Tutarsızlık kritikse: otomasyonun ürettiği çizelge, manuel derinleşme ile "neden böyle görünüyor?" sorusuna bağlanır.

İpucu: Timeline çıktısını rapora "ekran görüntüsü" diye gömmek yerine, delil paketini tarif edin: hangi kaynaklardan üretildi, zaman dönüşümü nasıl yapıldı, hangi filtreleme mantığı kullanıldı, hangi maddeler yorum içeriyor. Bu şeffaflık, aynı sonucun başka bir analist tarafından tekrar üretilebilir olmasını sağlar.

4. Veri kurtarma ve file carving: bağlam-içerik dengesini kurmak

File carving, dosya sistemi meta verisi olmasa bile ham veri kalıntılarından içerik çıkarma yaklaşımıdır. En büyük tuzağı şudur: carving çoğu zaman içeriği kurtarır ama bağlamı zayıflatır. Bu nedenle yöntem seçimi, "hangi soruya cevap arıyorum?" üzerinden yapılır.

4.1. Yöntem seçimi: meta veri tabanlı kurtarma mı, carving mi?

• Meta veri tabanlı yaklaşım (kayıt/harita üzerinden): yol, isim, zaman ve ilişki bağlamını daha iyi korur; timeline'a taşımak daha güvenlidir.

• Carving: dosya parçalanması (fragmentation) ve bağlam kaybı nedeniyle "ne zaman/nereden/kim yaptı?" sorularını zayıflatabilir; çoğu zaman destekleyici bulgu düzeyinde kalır.

Dikkat: "Kurtarılamadı" cümlesi raporda zayıf kalır. Bunun yerine, kurtarmayı sınırlayan koşulları netleştirin: olası üzerine yazma, şifreleme, disk kullanım örüntüsü, zaman aralığı, depolama teknolojisi.

4.2. SSD/TRIM gerçeği: kurtarma beklentisini doğru yönetmek

Modern SSD'lerde TRIM gibi mekanizmalar, silinen blokların daha sonra temizlenmesine/yeniden düzenlenmesine yol açabildiğinden, bazı senaryolarda içerik kurtarma olasılığı ciddi düşer. Böyle durumlarda odak, "içeriği kurtaramadım" noktasında kilitlenmek yerine, silme eylemini ve olayın diğer izlerini (değişim kayıtları, etkileşim izleri, snapshot'lar, zaman çizelgesi tutarlılığı) kanıt standardında birleştirmeye kaydırılır.

Örnek: Bir çalışan "yanlışlıkla sildim" derken aynı gün kısa aralıkta çok sayıda dosyada benzer silme örüntüsü görülüyor. SSD/TRIM koşulları nedeniyle içerik geri gelmeyebilir; fakat eylem örüntüsü, değişim izleri ve kullanıcı/oturum bağlamı birleştirildiğinde, olayın "tekil hata" mı "senkronize bir faaliyet" mi olduğu daha sağlam tartışılır.

5. Snapshot / Shadow Copy: geçmişle karşılaştırarak doğrulamak

Snapshot/shadow copy yaklaşımı, belirli anların "fotoğrafını" sunduğu için hem kurtarma hem de tutarlılık testi açısından değerlidir. "Canlıda yok" olan bir şeyin geçmiş kopyada görünmesi, olayın zaman çizelgesini netleştirir; ancak snapshot'ın varlığı da tek başına her şeyi çözmez (sıklık, saklama süresi, kapsam gibi sınırlar vardır).

5.1. Ne zaman güçlüdür?

• Bir log/dosya "yok" denildiğinde, geçmiş kopyalar önceki durumu gösterebilir.

• Değişiklik iddiasında "önce/sonra" karşılaştırmasıyle timeline'ı güçlendirir.

• Merkezi log eksikse, kısa bir pencere için yerel geçmiş kopyalar hayat kurtarabilir.

5.2. Sınırlar ve kanıt standardı

Snapshot'tan gelen her bulgu, raporda kaynağı, zamanı ve bütünlük doğrulaması ile birlikte sunulmalıdır. Modül 2'deki delil yönetimi yaklaşımı burada doğrudan devrededir: "hangi kopya", "hangi tarih", "hangi bütünlük adımı" gibi ayrıntılar, bulgunun tartışılabilirliğini azaltır.

İpucu: Snapshot'ı yalnız "kurtarma" için değil, "tutarlılık testi" için de kullanın. Canlıdaki sürümle geçmiş sürüm arasındaki fark, yalnız içerik değil, olay örgüsünün zaman ilişkisi açısından da kanıt üretir.

Örnek: Bir günün belirli saat aralığına ait kayıtların canlı sistemde eksik olduğu fark ediliyor; geçmiş kopyada aynı kayıtların bulunması "sonradan değişiklik" hipotezini güçlendirir. Ancak rapora "kesin silinmiş" yazmadan önce, log rotasyonu/bakım, disk doluluğu, saat ayarı değişimi gibi masum açıklamalar da aynı pencere için test edilir; sonra olasılık değerlendirmesi gerekçeli biçimde yapılır.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• NTFS ve ext4’te eylemlerin hangi iz düzenleriyle ortaya çıkabileceğini, “kayıt sistemi” bakışıyla okuyabildiniz
• Windows/Linux artefaktlarını, iddia–kanıt ilişkisiyle seçip masum açıklamaları dışlayacak şekilde doğrulama yaklaşımı kurdunuz
• Zaman semantiği, normalizasyon ve tutarsızlık yönetimi üzerinden timeline’ın denetlenebilirliğini artırdınız
• Süper-timeline ve otomasyon yaklaşımlarında yöntem seçimini ölçek/kanıt standardı/zaman baskısı ile gerekçelendirdiniz
• Süper-timeline ve otomasyon yaklaşımlarında yöntem seçimini ölçek/kanıt standardı/zaman baskısı ile gerekçelendirdiniz

MODÜL 6 — Bellek (Memory) Adli Analizi

Modül Teması

Disk adli analizi, çoğu olayda "ne kadarını geride bırakabildiğinizi" gösterirken bellek adli analizi "o anda neler yaşandığını" yakalar. Bunu, bir şehrin haritasına bakmakla aynı şehrin anlık trafik kameralarını izlemek arasındaki farka benzetebilirsiniz: harita durağan bir gerçeklik sunar; kamera ise akışın içindeki anormallikleri ortaya çıkarır. Fileless (dosyaya yazmadan çalışan) tehditler, kısa ömürlü süreçler, geçici ağ bağlantıları, şifreli iletişimin uç noktadaki izleri, kod enjeksiyonu belirtileri ve bazı gizlenme girişimleri çoğu zaman önce RAM'de görünür. Bu modülde hedef, bellek bulgularını "şüpheli" diye işaretlemekten öteye taşımak; bulguyu karşı kanıt arayarak doğrulamak, raporda denetlenebilir delil paketine dönüştürmek ve aynı sonuca giden birden fazla yaklaşım arasından doğru yöntem seçimini yapabilmektir.

1. Bellek temelleri: Neyi görüyoruz, neyi görmüyoruz?

Bellek analizi, işletim sisteminin o anki çalışma durumuna ait uçucu delil katmanıdır. Neden önemli? Çünkü süreçler, thread'ler, yüklü modüller, açık handle'lar ve ağ bağlantıları gibi öğeler olay sırasında görünürken; olay bittikten sonra disk üzerinde aynı açıklıkta kalmayabilir. Disk tarafında "kalıcı iz", bellek tarafında "anlık davranış" baskındır.

Orta seviye temel kavramları uzun uzun tekrar etmeyeceğiz; ilgili kontrol listelerini Orta Seviye modüllerde ayrıntılı işlemiştik. Burada ileri analiz için kritik olan, bu kavramları kanıt üretimi ve doğrulama perspektifiyle okumaktır:

• Process (süreç): Güvenlik bağlamı (kullanıcı/ayrıcalık), ebeveyn-çocuk ilişkisi ve kaynak tüketimi olan yürütme birimi. Neden önemli? Çünkü saldırı hikâyesinin omurgası çoğu zaman süreç soyağacında kurulur.

• Thread: Süreç içindeki yürütme akışı. Neden önemli? Çünkü süreç "normal" görünürken thread davranışı sapması bazı gizlenme/enkapsülasyon senaryolarında daha iyi sinyal verir.

• Handle: Bir nesneye erişim "bileti" (dosya, registry, başka süreç vb.). Neden önemli? Çünkü "hangi süreç neye erişmiş?" sorusu, özellikle credential access türü şüphelerde güçlü bir doğrulama hattı kurar.

• Module / DLL: Sürece yüklenen bileşenler. Neden önemli? Çünkü beklenmeyen yüklemeler, modül-bellek bölgesi tutarsızlıkları ve imza/konum uyumsuzluğu anomali üretir.

• Virtual memory (sanal bellek): Süreçlerin izole adres alanı illüzyonunu sağlayan mekanizma. Neden önemli? Çünkü dosyaya bağlı olmayan ("diskte karşılığı görünmeyen") bellek bölgeleri ve izin anomalileri genellikle burada yakalanır.

Bu modülün ayırt edici katmanı, bellek yönetiminin çekirdek yapılarına yakından bakmaktır:

1.1. Sanal bellek ve VAD (Virtual Address Descriptor)

Her süreç kendine ait bir sanal bellek alanında "yaşadığını" varsayar; işletim sistemi bu illüzyonu yönetir. VAD, sürecin kullandığı bellek aralıklarını ve bu aralıkların niteliğini tutan bir tür "tapu kaydı" gibidir. Neden önemli? Çünkü diskte dosya eşlemesi olmayan, private commit türü bölgeler veya beklenmeyen izin kombinasyonları, enjeksiyon/yerleştirme şüphesine giden en doğrudan sinyaller arasındadır.

Örnek: Bir süreçte çalıştırılabilir bir bellek bölgesi görünüyor; fakat bu bölge diskteki bir .exe/.dll eşlemesiyle ilişkilendirilemiyor ve "private" karakter taşıyor. Bu gözlem, "dosyaya bağlı olmayan kod yürütümü" hipotezini güçlendirir; yine de rapora geçmeden önce aynı süreçte meşru eklenti/yükleyici davranışı, güvenlik ajanı enstrümantasyonu veya uygulamanın JIT/VM benzeri çalışma modeli gibi masum açıklamalar test edilir.

1.2. Kernel nesneleri: EPROCESS / KPROCESS

Windows çekirdeği süreçleri EPROCESS/KPROCESS benzeri veri yapılarıyla takip eder. Analiz çerçeveleri süreç listelerini üretirken çoğu zaman bu çekirdek yapıların izini sürer. Neden önemli? Çünkü bazı gizlenme girişimleri "resmî listeleri" manipüle etmeyi hedefler; bu durumda aynı sürecin izleri farklı çekirdek kaynaklarında tutarsız biçimde ortaya çıkar.

Dikkat: Bellek, "tam gerçek" gibi görünse de tek bir anın fotoğrafıdır. Fotoğraf çekildiğinde sistem yoğun yük altında olabilir, güvenlik ajanları geçici artefaktlar üretebilir veya edinim sırasında bazı bölgeler eksik kalabilir. Bu nedenle bir bulgu, en az bir bağımsız kaynakla (disk artefaktı, EDR telemetrisi, olay logları, ağ akış kayıtları) çaprazlanmadan "kesin hüküm"e çevrilmemelidir.

2. Volatility ile çekirdek iş akışları: Çıktı üretmek değil, güvenilir çıktı üretmek

Volatility gibi bellek adli çerçeveleri, ham bellek dökümünü anlamlı tablolara dönüştürür: süreç listeleri, ağ bağlantıları, yüklü modüller, handle ilişkileri ve daha fazlası. Neden önemli? Çünkü olayın "aktif bileşenlerini" tek bir yerde görmeyi sağlar. Ancak ileri seviyede ilk soru her zaman şudur: Bu çıktı ne kadar güvenilir?

2.1. Edinim bağlamı ve analiz uyumu

• Bellek görüntüsünün bütünlüğü (hash + zincir kayıtları) raporun omurgasıdır; bulgunun "nereden geldiği" kadar "değişmediği" de önemlidir.

• Edinimin koşulları (sistem açık mıydı, yoğun yük var mıydı, güvenlik ürünleri aktif miydi) yorumun ağırlık merkezini değiştirir.

• Disk ile bellek arasında zaman ilişkisi beklenir: bellek anlıktır, disk kalıcıdır; tutarsızlık varsa önce masum açıklamalar elenmelidir.

İpucu: Minimum sağlam okuma seti, süreç-ağ-modül üçlüsünü birlikte değerlendirmek ve kritik bir iddiayı (örn. "bu süreç bu uçla konuşmuş olabilir") en az bir ikinci veri kaynağıyla doğrulamaktır. Hız kazandırır ama kanıt standardını korur.

2.2. Süreç listeleme: pslist vs psscan ve yöntem seçimi

Aynı "süreç listesi" farklı yöntemlerle üretilebilir. Buradaki yöntem farkı, çoğu zaman olayın kilidini açar:

• pslist (active list yaklaşımı): İşletim sisteminin resmî süreç listesini takip eder. Hızlıdır; ancak resmî liste manipüle edilmişse görünürlük kaybı yaşanabilir.

• psscan (pool scanning yaklaşımı): Belleği tarayıp süreç veri yapısı imzalarını/pattern'lerini arar (pool tag/pool scanning mantığı). Daha kapsayıcı olabilir; ancak bellek bozukluğu, eksik edinim veya eski kalıntılar gibi durumlarda daha fazla yorum disiplini ister.

Bu ikisinin çıktısındaki tutarsızlık, gizlenme şüphesini doğurabilir.

Dikkat: "psscan'de var, pslist'te yok" gözlemi güçlü bir sinyaldir; fakat tek başına otomatik hüküm değildir. Eksik/bozuk edinim, race condition benzeri anlık durumlar veya artık veri (residual) gibi ihtimaller de kontrol edilmelidir. Rapor dili, "gizlenmiştir" kesinliğinden önce "resmî listelerde görünmüyor, alternatif taramada süreç yapısı izleri bulundu" gibi denetlenebilir cümlelerle kurulmalıdır.

2.3. Ağ görünümü: netscan, soket artıkları ve bağlam paketleme

Bellek, kapatılmış bağlantıların artıklarını (residual data) bir süre barındırabilir. Bu, olay zaman penceresinde "kısa süreli" iletişimleri yakalamada değerlidir. Ancak ileri seviye kanıt üretiminde ağ bulgusu tek başına rapora taşınmaz; bağlamı ile paketlenir:

• Bağlantının sahibi PID/süreç

• Sürecin başlama zamanı / olay penceresi ile ilişkisi

• Bağlantı durumu (ör. ESTABLISHED/CLOSED gibi) ve tekrar örüntüsü

• İkinci kaynak doğrulaması (flow/EDR/cihaz logları)

Örnek: Bellekte 192.0.2.5'e doğru bir uç görülüyor. Bu, "kötü niyetli iletişim" diye yazılmaz. Aynı uçla konuşan sürecin soyağacı, süreç konumu/imzası, modül profili ve disk üzerindeki karşılığıyla tutarlılığı test edilir. Beklenmedik bir kullanıcı uygulamasının şifreli porta bağlantı kurması, şifreli içerik görülmese bile uç noktada davranışsal uyumsuzluk sinyali üretir; karar, bu sinyalin diğer artefaktlarla örtüşmesine göre güç kazanır.

İpucu: Ağ bulgularını rapora taşırken en dayanıklı format şudur: "Bağlantı → Sahip süreç → Süreç bağlamı → Çapraz doğrulama". Bu sıralama, hem yanlış pozitifleri azaltır hem de denetimde "neden bu yoruma gittin?" sorusunu karşılar.

3. Zararlı izleri ve anomali tespiti: "Normalden sapma"yı ölçülebilir kılmak

Bellek analizinde çoğu zaman "imza" yerine "davranışsal uyumsuzluk" aranır. Neden önemli? Çünkü gelişmiş tehditler izlerini diskten silmeye veya hiç yazmamaya çalışır; buna karşı en dayanıklı yaklaşım, bir sürecin "olması gereken" ile "olduğu" arasındaki farkı sistematik biçimde ölçmektir.

3.1. Kod enjeksiyonu / DLL injection / process hollowing belirtileri

Bu modülde amaç, bu tekniklerin uygulanışını anlatmak değil; belirtilerini nasıl doğrularsınız sorusunu yanıtlamaktır. İleri doğrulama hattında şu sorular birlikte yürür:

• Süreç bellek haritasında beklenmeyen izin kombinasyonları var mı?

• VAD ağacında diskte bir dosyayla eşleşmeyen (file mapping yokluğu) private bölgeler "çalıştırılabilir" özellik taşıyor mu?

• Modül listesi ile bellek bölgeleri arasında tutarsızlık var mı?

• Sürecin disk üzerindeki görüntüsüyle (image on disk) bellek içeriği arasında açıklanabilir mi, yoksa anormal mi?

RWX (Read-Write-Execute) anomali mantığı: Güvenli yazılım prensiplerinde kod (execute) ve veri (write) ayrımı tercih edilir (DEP/NX gibi korumalar bu ayrımı destekler). Bir bellek bölgesinin aynı anda hem yazılabilir hem çalıştırılabilir olması, meşru senaryolarda nadirleşen bir durumdur; bu yüzden yüksek öncelikli inceleme gerektirir. Yine de rapora "kesin enjeksiyon" diye geçmeden önce, uygulamanın çalışma modeli (örn. bazı JIT senaryoları) veya güvenlik/izleme bileşenlerinin müdahalesi gibi masum açıklamalar elenmelidir.

Bölgede görülen ilk baytların belirli kalıpları (örn. MZ başlığı gibi yürütülebilir format izleri veya sıra dışı dolgu desenleri) bulguyu güçlendirebilir; fakat burada kritik olan "kalıp gördüm" değil, kalıbın süreç bağlamıyla uyumsuzluğu ve başka kaynaklarla desteklenmesidir.

Örnek: Bir süreç, kullanıcı arayüzü uygulaması gibi görünürken beklenmedik şekilde ağ bağlantısı kuruyor. Aynı süreçte diskte karşılığı olmayan çalıştırılabilir bir bellek bölgesi sinyali var. Bu noktada yorum, "enjekte edilmiş olabilir" hipotezinde kalır; doğrulama için süreç ebeveyni, yüklenen modüller, kullanıcı oturumu, aynı zaman penceresindeki olay logları ve disk üzerindeki dosya/imza tutarlılığı birlikte aranır. Raporda gözlem ile yorum net ayrılır.

3.2. Süreç soyağacı ve bağlamsal doğrulama

Masquerading (adı benzeyen meşru süreç gibi görünme) senaryolarında en güçlü savunma, ad yerine bağlam okumaktır:

• Ebeveyn süreç beklenen mi?

• Süreç nereden çalışıyor (konum) ve imza durumu ne?

• Aynı isimli süreçlerin davranışı tutarlı mı?

• Olay penceresinde kullanıcı etkileşimi var mı?

Dikkat: "Şu süreç yalnızca şundan başlar" gibi mutlak cümleler raporu kırılganlaştırır. Doğru yaklaşım, "kurumsal baseline'da tipik ebeveyn-çocuk ilişkisi şu; bu olayda farklılık var ve şu kanıtlarla destekleniyor" şeklinde denetlenebilir dil kurmaktır.

4. Credential access odağı: LSASS sinyallerini 'araç adı'na indirgemeden doğrulamak

LSASS, kimlik doğrulama bileşenleriyle ilişkili olduğu için olay müdahalesinde sık incelenir. Neden önemli? Çünkü kimlik bilgisi erişimi, yatay hareketi besleyebilecek kritik bir aşamadır. Bu modülde odak "şu araç var mı?" değil; erişim davranışı anormalliğidir.

Güçlü sinyallerden biri handle analizi mantığıdır: Normal şartlarda sıradan bir kullanıcı uygulamasının LSASS üzerinde anlamlı erişim handle'ı olması beklenmez. Böyle bir gözlemde ileri doğrulama şu şekilde olgunlaşır:

• Handle sahibi sürecin soyağacı ve bağlamı (kullanıcı oturumu, ayrıcalık seviyesi)

• Aynı zaman penceresinde oturum açma anormallikleri (başarısız girişler, olağan dışı oturumlar)

• Diskteki geçici artefaktlar ve EDR telemetrisi ile örtüşme

• Kurumsal envanterde meşru yönetim/güvenlik araçlarının bu davranışı açıklayıp açıklamadığı

İpucu: LSASS şüphesinde en savunulabilir raporlama kalıbı şudur: "Hangi süreç → hangi zaman penceresinde → LSASS ile hangi tür etkileşim sinyali → hangi bağımsız kayıtlarla destek → hangi masum açıklamalar elendi." Bu dil, hem abartılı kesinlikten kaçınır hem de karar verdirir.

5. İleri gizlenme olasılıkları: DKOM ve cross-view yaklaşımıyla denetlenebilir sonuçlar

DKOM (Direct Kernel Object Manipulation) gibi teknikler, çekirdek seviyesinde veri yapılarını manipüle ederek bazı görünürlük katmanlarını bozabilir. Neden önemli? Çünkü "liste boş ama davranış var" gibi çelişkiler doğabilir. Ancak ileri yaklaşım, DKOM'u ilk refleks açıklama olarak kullanmaz.

Burada belirleyici olan cross-view analysis mantığıdır: aynı nesnenin (süreç vb.) varlığını birden fazla veri kaynağından sorgulayıp tutarsızlık aramak. Örneğin psxview gibi yaklaşımlar, süreci farklı listelerden/izlerden görmeye çalışır; bir yerde görünüp başka yerde görünmüyorsa, "standart görünürlük hatları"ndan saklanma ihtimali güçlenir.

Dikkat: "Kernel manipülasyonu var" demek yerine, daha savunulabilir olan şudur: "Süreç, standart listeleme kaynaklarında görünmüyor; ancak alternatif görünürlük kaynaklarında (örn. thread/handle gibi izlerde) aktifliğe işaret eden tutarsızlıklar saptandı." Bu ifade hem teknik olarak daha doğru, hem de denetimde daha dayanıklıdır.

Örnek: Süreç listeleri "temiz" görünürken ağ cihazı akış kayıtları belirli bir zaman penceresinde yoğun iletişim gösteriyor. Bellekte bağlantı sahibi süreç "beklenen" bir bileşen gibi duruyor. Bu çelişkide önce profil/sembol uyumu, edinim kalitesi ve güvenlik ajanı etkisi elenir; ardından süreç-modül-disk karşılığı tutarlılığı test edilir. Hâlâ açıklanamıyorsa cross-view tutarsızlıkları "gizlenme hipotezi"ni destekleyen delil olarak raporlanır.

6. Delil paketleme: Bellekten çıkarılan veriyi rapora taşımanın standartları

Bellek analizinin değeri, "şüpheli çıktı" üretmekle sınırlı değildir; o çıktıyı yeniden üretilebilir ve denetlenebilir delil paketine çevirmekle ölçülür.

Bu modülde beklenen kanıt paketleme disiplini:

• İncelenen bellek imajının bütünlük kayıtları (hash, zincir notları)

• Kritik bulguların bağlamı: süreç soyağacı, zaman penceresi, ağ uçları, modül listesi

• Şüpheli bellek bölgeleri için "ham veri çıkarımı (dump)" kararının gerekçesi ve sınırları

• Çıkarılan ham verinin bütünlük kaydı ve analiz notu (örn. format izleri/strings bulguları gibi, saldırıyı kolaylaştırmayacak seviyede)

• Bulguların sınırlılıkları: edinim koşulları, eksik alanlar, alternatif masum açıklamalar ve nasıl elendiği

Örnek: Bir süreçte anormal bellek bölgesi sinyali tespit edildi. Bu bölge ham veri olarak dışarı alındı, bütünlük kaydı oluşturuldu ve içerik, sadece "ne tür veri/kod ailesi izleri taşıyor olabilir?" seviyesinde sınıflandırıldı. Aynı süreçte eşleşen ağ uçları ve modül tutarsızlıkları ile birlikte "gözlem seti" rapora taşındı; "nihai yorum" kısmında kesinlik yerine olasılık ve doğrulama adımları açıkça yazıldı.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Belleği “anlık trafik kamerası” gibi okuyup, diskten görünmeyebilecek davranış izlerini yakalama perspektifi
• VAD ve EPROCESS/KPROCESS gibi çekirdek yapıların, bellek bulgularını yorumlamada neden kritik olduğu
• Süreç listeleme, ağ görünümü ve modül analizini tek tek değil birlikte okuyarak “normal vs. anormal” ayrımını güçlendirme
• pslist/psscan ve cross-view mantığıyla görünürlük tutarsızlıklarını hipotez–doğrulama disiplini içinde ele alma
• RWX, private/mapped tutarsızlıkları ve süreç soyağacı üzerinden enjeksiyon/hollowing türü şüpheleri saldırı anlatısına kaçmadan raporlama
• LSASS odağında handle ve bağlam korelasyonu ile credential access sinyallerini denetlenebilir biçimde ifade etme
• Bellekten çıkarılan ham veriyi bütünlük, bağlam ve sınırlılıklarıyla birlikte yeniden üretilebilir delil paketine dönüştürme

MODÜL 7 — Windows Sistemlerinde Gelişmiş Adli Analiz

Modül Teması

Kurumsal olayların büyük kısmında Windows, "olayın dili"ni üç ana kanaldan konuşur: Registry (yapılandırma ve kalıcılık izleri), Event Log'lar (kim-ne zaman-ne yaptı zinciri) ve yürütme/etkileşim artefaktları (bir şey gerçekten çalıştı mı, kullanıcı neye dokundu mu?). Bu modül, tek bir artefakta bakıp hüküm vermek yerine; bulguyu karşı kanıt arayarak sınamayı, denetlenebilir delile dönüştürmeyi ve aynı soruyu birden fazla yöntemle yanıtlayabilmeyi hedefler.

1. Registry analizi: Kalıcılık ve davranış izleri

Registry, Windows'un sinir sistemi gibidir: sistem yöneticisi de, kötüye kullanım şüphesi doğuran aktiviteler de çoğu zaman buraya temas eder. Bu yüzden "Registry'de bir şey var" demek yerine, hangi kapsamda, hangi nesneye işaret ederek, hangi zaman penceresinde iz bıraktığını doğrulamak gerekir. Orta seviyede hive mantığını ve temel anahtar türlerini ayrıntılı işlemiştik; burada ileri analiz açısından kritik nokta kanıt zinciri kurmaktır.

1.1. Run/RunOnce, Services, Scheduled Tasks: "Var" demek yetmez

Bu kalıcılık yüzeyleri, sistem açılışında/oturum açılışında tetiklenen davranışları taşıyabildiği için olay müdahalesinde hızlıca gündeme gelir. Ancak ileri seviyede "giriş var" bulgusu tek başına kırılgandır; sağlam yaklaşım üç soruyu birlikte yürütür:

• Bağlam testi: Kayıt hangi kullanıcı/kapsam altında? Kurumsal imajın (baseline) beklenenleri neler?

• Nesne doğrulaması: İşaret edilen dosya/servis/görev gerçekten var mı; konum, sürüm, imza, sahiplik ve yüklenme biçimi beklenenle uyumlu mu?

• Zaman tutarlılığı: Değişiklik zamanı, olay penceresindeki diğer sinyallerle (kurulum izleri, süreç oluşturma kayıtları, oturum açma hareketleri) örtüşüyor mu?

Örnek: "Güncelleme yardımcısı" gibi masum görünen bir Run girdisiyle karşılaşılıyor. İlk refleks etiketlemek değil; envanterde bu bileşenin meşru karşılığını aramak, hedef dosyanın konumunu (beklenen program dizini mi, kullanıcı profili gibi beklenmedik bir yer mi?), imza/metadata tutarlılığını ve aynı zaman aralığında Event Log'larda süreç/kurulum izlerini çaprazlamak olur. Raporda "gözlem" (tam anahtar yolu + değer), "doğrulama" (nesne varlığı + güven ilişkileri + zaman korelasyonu) ve "yorum" (kalan olasılıklar) net ayrılır.

Dikkat: Registry'de "şüpheli isim" tuzağı çok yaygındır. Meşru yazılımlar da benzer adlar kullanabilir; güvenlik/izleme ajanları enstrümantasyon için otomatik kayıtlar oluşturabilir. İsim yerine konum + imza/metadata + olay penceresi + çapraz log dörtlemesi, yanlış pozitifleri dramatik biçimde düşürür.

1.2. Winlogon alanları ve "ince ayar" kalıcılık izleri

Bazı kalıcılık izleri, klasik Run/Service taramalarında hemen parlamaz; oturum açma akışına gömülü yapılandırma alanları bunun tipik örneğidir. Burada ileri seviye farkı, "bir değer farklı" demekten çok, değerin sistem davranışını gerçekten nasıl etkilediğini doğrulama disiplinidir: değişiklik aynı zaman penceresinde hangi süreçleri tetiklemiş, kullanıcı/servis bağlamı ne, bu değişiklik baseline ile açıklanabiliyor mu?

1.3. MRU, USB geçmişi, RDP izleri: Kullanıcı davranışı mı, olay izi mi?

MRU türü kayıtlar, USB geçmişi ve RDP ile ilişkili izler olay hikâyesinin "insan kısmını" besler; bu nedenle önemlidir. Fakat ileri seviyede bu sinyallerin kanıt gücü dikkatli tartılır:

• MRU kayıtları çoğu zaman "etkileşim/niyet" sinyali üretir; "kesin yürütme" cümlesi kurmak için tek başına yetmeyebilir.

• USB geçmişi "aygıt takıldı"yı gösterebilir; veri taşındı iddiası için dosya erişim/transfer izleriyle destek gerekir.

• RDP izleri uzak erişimi işaret edebilir; bunun meşru yönetim mi yoksa anomali mi olduğu, oturum açma kayıtları ve zaman/alışkanlık tutarlılığıyla netleşir.

İpucu: Bu sınıf artefaktları rapora taşırken dili "kesin hüküm" yerine "denetlenebilir ifade"ye yaklaştırmak raporu güçlendirir: "kayıtlar, şu kaynağın son kullanımına uyumlu bir iz seti sunuyor" gibi cümleler, sonradan çürütülmeye daha dayanıklıdır.

1.4. Shellbags ve UserAssist: "Dosya açmadı ama iz bıraktı" alanı

Windows Gezgini ve GUI etkileşimleri bazı durumlarda "kullanıcı o klasörden haberdardı / oraya göz attı" gibi kritik ayrımları taşıyabilir. Bu izleri ileri seviyede değerli yapan şey, olayın teknik kısmı kadar olayın insan-akışını da zaman çizelgesine bağlayabilmesidir.

Örnek: Klasör daha sonra silinmiş olsa bile, kullanıcı arayüzü etkileşimine ait izler "o yolun görüntülendiği" yönünde destekleyici sinyaller üretebilir. Bu sinyali tek başına "veri erişildi"ye çevirmek yerine, aynı zaman penceresinde dosya sistemi zaman çizelgesi ve süreç oluşturma kayıtlarıyla birlikte değerlendirmek daha sağlamdır.

2. Event Log analizi: Zaman çizelgesi ve kanıt disiplini

Event Log'lar "ne zaman, hangi sırayla, hangi kapsamda?" sorusunu yanıtlar; bu yüzden önemlidir. Yanlış okunduğunda ise gerçeğe benzeyen ama hatalı bir hikâye üretir. İleri seviyede odak iki noktaya kayar: (1) doğru soruya doğru log kaynağı, (2) tutarlılık testleri ve karşı kanıt arayışı.

2.1. Kritik kategoriler ve soru-kaynak eşleşmesi

• Oturum açma hareketleri: Hesap kullanımı ve erişim şüphesinde ilk duraktır; oturum açmanın türü, erişimin şekline dair bağlam sağlar. Logon Type değerleri Windows güvenlik denetimlerinde açıkça tanımlanır.

• Süreç oluşturma: "Ne çalıştı?" sorusunu doğrudan besler; fakat komut satırı ayrıntısı ortam politikasına göre kayıt altına alınmayabilir.

• Denetim günlüğü temizliği: "Log yok" durumunda, bunun doğal mı yoksa müdahale kaynaklı mı olabileceğini tartmak gerekir; denetim günlüğünün temizlenmesi ayrı bir olay olarak kayda geçebilir.

Dikkat: Log yokluğu her zaman "olmadı" anlamına gelmez. Log saklama politikaları, rotasyon, cihazın olay anındaki durumu veya merkezi toplama eksikliği görünürlüğü düşürebilir. Bu yüzden raporda "log bulunamadı" ifadesi, "bu davranış yoktur" gibi kesin bir yargıya çevrilmez.

2.2. Sysmon varsa: zengin telemetri, daha iyi ham madde

Sysmon, süreç ve ağ gibi alanlarda daha ayrıntılı olaylar üretebilir; bu yüzden önemlidir. Ancak "zengin telemetri" otomatik olarak "kanıt" demek değildir: konfigürasyon kapsamı, loglama sürekliliği ve ortamın meşru otomasyonları yanlış pozitif üretebilir. Bu nedenle Sysmon bulguları, mümkün olduğunda standart loglar ve disk/bellek artefaktlarıyla çaprazlanarak rapora taşınır.

İpucu: Triage odaklı hızlı analiz ile hukuki/kurumsal denetim düzeyinde delil üretimi aynı şey değildir. Triage'da "yüksek sinyal" olaylar önceliklenir; delil standardında ise aynı iddia en az iki bağımsız kaynaktan desteklenmeden "kesin" yazılmaz.

2.3. Doğrulama: Zaman tutarlılığı ve karşı kanıt arayışı

İleri seviyede bir log girdisini gördüğünüzde refleks "etiketlemek" değil, çürütmeye çalışmaktır:

• Zaman çizelgesinde görünen kritik olayın komşu olaylarla akışı uyumlu mu?

• Aynı iddia, farklı log kategorilerinde de iz bırakıyor mu?

• Disk/bellek artefaktlarıyla çelişki var mı; varsa hangisi daha güvenilir ve neden?

Örnek: Gece saatlerinde bir hesapla başarılı oturum açma görünüyor. Bu, meşru otomasyon da olabilir. Karşı kanıt olarak aynı zaman aralığında süreç oluşturma izleri, uzak erişimle uyumlu kayıtlar ve kullanıcının normal çalışma örüntüsü birlikte değerlendirilir. Raporda tek bir kayda dayalı iddia yerine, yapılan tutarlılık testleri yazılır.

3. Evidence of Execution: "Çalıştı mı?" sorusuna kanıt üretimi

Bir ikilinin disk üzerinde bulunması "çalıştı" demek değildir; bu ayrım olay müdahalesinde kararları belirlediği için önemlidir. Evidence of Execution artefaktları tam burada devreye girer; ama her birinin kanıt gücü ve sınırı farklıdır.

3.1. Prefetch: Güçlü sinyal, dikkatli yorum

Prefetch bazı ortamlarda yürütmeye dair güçlü bir iz seti sunar; bu yüzden önemlidir. Ancak Prefetch'in üretimi politika ve sistem koşullarına bağlı olabilir; yokluğu "çalışmadı"ya çevirmek risklidir. En sağlam yaklaşım, Prefetch'i tek başına "zaman doğrulayıcısı" gibi kullanmak yerine, olay penceresini başka kaynaklarla sağlamlaştırmaktır.

3.2. ShimCache (AppCompatCache) ve Amcache: "Görüldü" ile "yürütüldü" arasındaki çizgi

Bu artefaktlar çoğu zaman "sistemde görüldü / Windows tarafından tanındı" sinyalini taşır; bu yüzden önemlidir. Fakat yürütme kanıtı olarak mutlak yazmak kırılgan olabilir: kayıtların güncellenme davranışı, sürümler ve toplama koşulları nedeniyle yorumlanması hassastır. Akademik çalışmalar, AppCompatCache kayıtlarının bazı sürümlerde yerinde güncellenebildiğini ve zaman alanlarının "kesin yürütme zamanı" gibi okunmasının riskli olabileceğini vurgular; ayrıca bazı senaryolarda en güncel bilginin canlı sistemde bellek tarafında daha taze olabileceğine işaret eder.

Amcache tarafı, uygulama envanteri ve bazı kimlikleyici alanlar üzerinden "isim değişikliği" gibi yanıltıcı durumları daha iyi yakalamanıza yardım edebilir; bu yüzden önemlidir. Bu tür kimlikleyiciler, tehdit istihbaratıyla (örn. bir hash'in itibar sorguları) ilişkilendirildiğinde raporun doğrulanabilirliği artar.

Dikkat: ShimCache/Amcache için "kesin çalıştı" cümlesi kurmak yerine, bu artefaktları kanıt zincirinin bir halkası yapmak daha sağlamdır: süreç oluşturma kayıtları, Prefetch (varsa) ve zaman çizelgesi uyumu gibi bağımsız desteklerle güçlendirilir.

3.3. LNK (kısayol) izleri: Kullanıcı etkileşimi ve medya bağlamı

LNK türü izler, bir hedefe kullanıcı düzeyinde etkileşim sinyali taşıyabilir; bu yüzden önemlidir. İleri analizde değerli olan, LNK'nin yol/konum bağlamını zaman çizelgesine bağlayabilmesidir: dosya nereden erişildi, hangi kullanıcı penceresinde, olay penceresiyle uyumlu mu? Bu iz de tek başına "kötü niyet" değildir; ancak diğer kaynaklarla birleştiğinde yürütme/etkileşim iddiasını sağlamlaştırır.

İpucu: "Çalıştı mı?" sorusunda en dayanıklı yaklaşım genellikle üçlü bir bileşimi sever: (i) süreç oluşturma izleri, (ii) yürütmeye dair bir artefakt (Prefetch gibi) ve (iii) destekleyici etkileşim/zaman çizelgesi izi (LNK veya dosya sistemi timeline). Tek kaynağa dayanan raporlar, itiraza daha açıktır.

4. Lateral Movement ve kimlik suistimali: İzleri bağlamak, yanlış pozitifi azaltmak

Yanal hareket, olayın etkisini büyüten aşamadır; bu yüzden önemlidir. Burada hedef "hangi teknik kullanıldı"yı tarif etmek değil; kimlik kullanım örüntülerini ve uçtan uca korelasyonu kurmaktır.

4.1. Kerberos/NTLM sinyalleri ve DC loglarının rolü

Etki alanı ortamlarında kimlik doğrulama, merkezi bileşenlerde iz bırakır; bu yüzden önemlidir. Uç noktada "tek bir oturum açma" gibi görünen şey, DC tarafında bir örüntünün parçası olabilir. İleri doğrulama şu sorulara dayanır:

• Aynı hesabın kısa sürede çok sayıda hedefe erişmesi normal mi?

• Başarısız denemeler ile başarılar arasında "deneme-başarı" örüntüsü var mı?

• Erişimin zamanlaması, uç noktadaki süreç/ağ sinyalleriyle örtüşüyor mu?

4.2. Servis kurulum/değişiklik izleri: Yönetim mi, anomali mi?

Servisler hem meşru yönetimde hem kötüye kullanım şüphesinde ortak yüzeydir; bu yüzden önemlidir. "Yeni servis" türü sinyaller görüldüğünde yöntem seçimi kritikleşir: önce bakım pencereleri ve envanterdeki yönetim araçlarıyla uyuşuyor mu diye bakılır; uyuşmuyorsa olay penceresinde süreç oluşturma ve kimlik doğrulama örüntüleriyle korelasyon aranır.

4.3. LSASS erişimi gibi sinyaller: İşaret, hüküm değil

Bazı olaylar "kimlik bilgisine temas" şüphesi doğurur; bu yüzden önemlidir. Ancak ileri raporlama dili burada özellikle temkinlidir: güvenlik/izleme araçları da benzer erişim izleri üretebilir. Bu nedenle rapora "kesin" değil, "işareti güçlendiren sinyaller + elenen masum açıklamalar + kalan belirsizlikler" şeklinde girer.

Örnek: Olağan dışı saatlerde yoğun kimlik doğrulama trafiği ve aynı olay penceresinde servis değişikliği sinyali görülüyor. Bu, yayılım hipotezini güçlendirir. Karşı kanıt olarak planlı bakım/otomasyon kayıtları, ilgili yönetim sistemlerinin logları ve DC tarafındaki örüntüler kontrol edilir; sonuç, yalnızca desteklenen iddialar üzerinden yazılır.

5. WMI ve PowerShell izleri: "Sessiz otomasyon"u adli dile çevirmek

WMI Windows'ta yönetim/otomasyon altyapısıdır; PowerShell de modern yönetim ekosisteminin merkezidir. Bu yüzden önemlidir: meşru kullanım çok yaygındır ve ayırt etmek zordur. İleri yaklaşım, "WMI/PowerShell gördüm = kötü" hatasına düşmeden varlık kontrolü + anomali + olay penceresi üçlüsünü yürütür.

5.1. PowerShell günlükleri: Görünürlük politikaya bağlıdır

PowerShell tarafında bazı günlükler, yürütülen içerik ve etkinliğe dair daha zengin bağlam sunabilir; bu yüzden önemlidir. Ancak loglama her ortamda aynı düzeyde açık olmayabilir; kısmi kayıt ve filtreleme görünürlüğü bozabilir. Ayrıca bir içerik görünse bile bunun meşru otomasyon mu anomali mi olduğu, kimlik bağlamı ve zaman çizelgesiyle belirlenir.

Dikkat: PowerShell/WMI içeriğini rapora taşırken "gereksiz ayrıntı" iki risk doğurur: okunabilirliği düşürür ve istemeden kötüye kullanımı kolaylaştırabilecek bir derinliğe yaklaşabilir. Bu nedenle raporda delil değeri yüksek parçalar seçilir; bağlam ve doğrulama adımları öne çıkarılır.

5.2. WMI kalıcılık nesneleri: Filter-Consumer-Binding üçlüsü

WMI tarafında kalıcılık, yönetim nesneleri üzerinden tariflenebilen bir tetikleme-eylem ilişkisine dayanır; bu yüzden önemlidir. İnceleme sırasında yöntem seçimi şunu gözetir:

• Bu tür nesneler kurumsal baseline'da bekleniyor mu?

• Nesnenin işaret ettiği davranış, olay penceresinde süreç oluşturma ve yürütme izleriyle destekleniyor mu?

• Meşru yönetim araçlarıyla açıklanabiliyor mu; açıklanıyorsa hangi kayıtlar bunu doğruluyor?

5.3. Kanıt üretimi: "otomasyon izi"ni delile dönüştürmek

Bu modülde rapor standardının omurgası şudur:

• Gözlem: ilgili log kaydı / nesne varlığı / anahtar yolu / olay kimliği

• Doğrulama: kimlik bağlamı, zaman çizelgesi, süreç oluşturma ve disk/bellek artefaktlarıyla uyum

• Yorum: elenen masum açıklamalar, kalan olasılıklar, sınırlılıklar

Böylece başka bir analist aynı veri setiyle aynı sonuca ulaşabilir; rapor "kanıt-yorum" ayrımını korur.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Registry’de kalıcılık şüphesini isimlere takılmadan bağlam–nesne doğrulaması–zaman tutarlılığı ile değerlendirebilme.
• Event Log’lardan zaman çizelgesi kurarken log yokluğunu doğru raporlama, tutarlılık testleri ve karşı kanıt arama refleksi.
• “Çalıştı mı?” sorusunu Prefetch/ShimCache/Amcache/LNK gibi izlerin güç ve sınırlarını tartarak, çoklu kaynakla destekleyebilme.
• Yanal hareket ve kimlik suistimali şüphesini uç nokta sinyallerini DC tarafı örüntülerle tamamlayarak daha sağlamlaştırma.
• PowerShell/WMI gibi meşru yönetim yüzeylerinde anomaliyi baseline + olay penceresi + korelasyon üçlüsüyle ayırt etme.
• Bulguları gözlem–doğrulama–yorum ayrımında, yeniden üretilebilir ve denetlenebilir rapora dönüştürme.

MODÜL 8 — Ağ Adli Analizi ve Log Korelasyonu

Modül Teması

Bir olayın "hareketi" ağda taşınır: kim kiminle konuştu, hangi servisler devreye girdi, erişim nasıl genişledi, veri akışı hangi örüntüyle sürdü? Bu modülde ağ kanıtlarını (PCAP/flow/proxy/DNS) uç nokta ve kimlik loglarıyla aynı zaman çizelgesinde birleştirerek, denetlenebilir delil gücü yüksek bir olay hikâyesi kurmayı hedefleyeceksiniz. Vurgu tek bir alarma yaslanmakta değil; bulguyu doğrulamak, karşı kanıt aramak, yöntem seçimini görünürlük-maliyet-kanıt standardı üçgeninde gerekçelendirmek ve çıktıyı raporda yeniden üretilebilir hale getirmektedir.

1. PCAP ve Flow Analizi

Ağ adli analizinde iki ana "mercek" vardır: PCAP mikroskop gibidir; tekil bir oturumun içine kadar iner. Flow ise güvenlik kamerası gibidir; payload görmeden, geniş alanda kim-kiminle-ne kadar konuştuğunu ölçekli şekilde izletir. İleri seviye analistin ilk kritik kararı, olayın sorusunu doğru seçmek ve veriyi buna göre kullanmaktır.

1.1. PCAP vs Flow: aynı gerçeğin iki farklı temsili

PCAP, paket içeriğine (payload) kadar inebilen ham kanıt katmanıdır. Bazı olaylarda "tam olarak ne taşındı?" sorusuna yaklaşmanın tek yolu uygulama katmanına kadar görebilmektir. Bu nedenle, örneğin bir isteğin/yanıtın gerçekten gerçekleşip gerçekleşmediğini tartışırken PCAP güçlü bir dayanak olabilir.

Flow (NetFlow/IPFIX) ise özet telemetri sağlar: kaynak/hedef, portlar, protokol, zaman, bayt/paket miktarı gibi metriklerle "kim kiminle, ne yoğunlukta konuştu?" sorusunu büyük ölçekte yanıtlar. IPFIX, IETF tarafından standartlaştırılmış akış raporlama yaklaşımıdır; pratikte "uzun süre saklanabilir geniş hafıza" rolünü üstlenir.

Yöntem seçimi burada delil standardını doğrudan etkiler:

• Derinlik gerekiyorsa (tek bir oturumun yeniden inşası, belirli bir isteğin yapısı, bir veri nesnesinin gerçekten taşındığı iddiası) PCAP öne çıkar.

• Kapsam gerekiyorsa (günlerce konuşan yüzlerce cihaz, yayılım haritası, 6 ay geriye dönük "kim konuştu?" soruları) flow daha rasyoneldir; çünkü depolama maliyeti çok daha yönetilebilirdir.

Örnek: Bir uç noktada şüpheli bir süreç sinyali var. Önce flow ile bu uç noktanın hangi dış hedeflerle, hangi sıklıkta ve ne hacimde konuştuğu çıkarılır (kapsam haritası). Ardından kritik görünen birkaç akış için PCAP varsa, aynı zaman penceresinde 5-tuple (kaynak/hedef IP, portlar, protokol) ve oturum davranışıyla "gerçekten aynı oturum mu?" sorusu doğrulanır.

Dikkat: "Ağ trafiği değiştirilemez kayıttır" cümlesi pratikte fazla iddialıdır. Ham trafik, birçok disk/log kaynağına göre manipülasyona daha dirençli olabilir; ancak yakalama noktasının kapsama sınırları, paket kaybı, örnekleme, zaman senkronizasyonu ve zincir-of-custody zayıfsa kanıt gücü kırılganlaşır. Bu modülde "ham veri" kadar "verinin nasıl toplandığı" da delilin parçasıdır.

1.2. Yakalama kalitesi ve kanıt bütünlüğü: paket kaybı, örnekleme, zaman

Ağ verisinin kanıt değeri sadece "ne gördüğünüz" ile değil, "ne kadar sağlıklı gördüğünüz" ile ölçülür.

Doğrulama refleksi şu sorularla başlar:

• Sensör/SPAN/TAP konumu olayla ilgili segmenti gerçekten görüyor mu?

• Flow tarafında örnekleme var mı? Varsa hangi sinyaller zayıflar (özellikle küçük hacimli, kısa süreli akışlar)?

• Zaman damgaları NTP/clock drift nedeniyle kaymış olabilir mi? Aynı olay farklı kaynaklarda farklı dakikalarda görünüyor olabilir mi?

İpucu: Rapora küçük ama kritik bir "veri kaynağı kalitesi" bölümü eklemek çoğu itirazı baştan söndürür: sensör konumu, kapsama, örnekleme, bilinen boşluklar, zaman senkronizasyon durumu ve bu sınırlılıkların analize etkisi açıkça yazıldığında rapor denetlenebilir hale gelir.

1.3. Kanıt üretimi: ağ verisini raporda delile dönüştürmek

Ağ bulgusu rapora "yorum" olarak değil, ölçülebilir ve referanslanabilir bir delil seti olarak girmelidir.

• Gözlem: hangi veri kaynağı (PCAP/flow/proxy/DNS), hangi zaman aralığı, hangi akış/oturum kimliği (5-tuple), metrikler (bayt, paket sayısı, süre), gerekiyorsa oturum/akış ID veya PCAP içi referans.

• Doğrulama: aynı oturumun uç nokta proses/ağ telemetrisiyle eşleşmesi; proxy/DNS/kimlik loglarıyla tutarlılık testi; NAT/proxy/VPN gerçeğinin açıklığa kavuşturulması.

• Yorum: meşru açıklamaların (güncelleme, telemetri, sağlık kontrolü, CDN davranışı) nasıl elendiği; hangi belirsizliklerin kaldığı; kararın bu belirsizliklerle nasıl verildiği.

2. Protokol Bazlı Analiz

Protokol bazlı bakış, trafiği "paket yığını" olmaktan çıkarır; alanları ve örüntüleri üzerinden davranış diline çevirir. Amaç "nasıl yapılır" tarifine kaymadan; hangi alanların sinyal ürettiğini, hangi alanların yanıltıcı olabileceğini ve hangi koşulda hangi yöntemin seçileceğini netleştirmektir.

2.1. HTTP: istek örüntüsü, başlık bağlamı, proxy gerçeği

HTTP'de sinyal üreten alanlar çoğu zaman içerikten ziyade örüntüdür: istek yolu, yöntem çeşitliliği, yönlendirme akışı, erişim sıklığı ve başlık tutarlılığı.

• User-Agent anomalileri: Ağda çok sık görülen tarayıcı

başlıklarının dışında kalan "nadir" (least frequent) başlıklar bazen gerçek dışı taklitler veya otomasyon göstergesi olabilir. Ancak bu yaklaşım tek başına hüküm kurdurmaz; çünkü meşru ajanlar da nadir görünebilir.

• Proxy etkisi: Kurumsal proxy varsa uç nokta IP'si yerine proxy'nin

konuştuğu görünür. Bu durumda "hangi istemci konuştu?" sorusunu endpoint/proxy eşleştirme kayıtlarıyla doğrulamadan, ağ akışını yanlış cihaza bağlamak kolaydır.

Örnek: Bir istemcinin belirli aralıklarla çok kısa HTTP istekleri yaptığı görülüyor. Bu "beacon" olabilir; fakat aynı örüntü bir uygulamanın sağlık kontrolü de olabilir. Karşı kanıt olarak aynı davranışın diğer cihazlarda olup olmadığı, yazılım envanterinde bu uygulamanın varlığı ve uç noktada süreç+ağ eşleşmesi kontrol edilir.

2.2. DNS: tünelleme belirtisi mi, masum gürültü mü?

DNS'de sinyal çoğunlukla "içerik"ten değil, istatistiksel örüntülerden gelir: sorgu sıklığı, alt alan adı uzunluğu/entropisi, NXDOMAIN oranı, TTL tutarlılığı ve query tipi dağılımı.

• Yöntem seçimi: Kapsam arıyorsanız DNS logları güçlü bir harita sunar. Derin doğrulama için aynı zaman penceresinde flow/PCAP ve uç nokta telemetrisiyle eşleştirme gerekir.

• Gürültü gerçeği: Modern uygulamalar (telemetri, CDN, güncelleme mekanizmaları) DNS'i doğal olarak gürültülü hale getirir. Bu yüzden "yüksek NXDOMAIN" gibi sinyaller tek başına kesin kanıt değil, hipotez üreticisidir.

Örnek: Bir istemci kısa aralıklarla çok sayıda alt alan adına sorgu atıyor ve çoğu başarısız. Bu veri taşıma karakteristiğine benzeyebilir; fakat yanlış yapılandırılmış bir uygulama da aynı izi bırakabilir. Karşı kanıt: hedef alan adı başka istemcilerde de görünüyor mu, aynı zaman penceresinde proxy/HTTP trafiği eşlik ediyor mu, uç nokta süreç bağlamı hangi uygulamayı işaret ediyor?

2.3. SMB: dosya paylaşımı trafiğinde davranış sinyali

SMB'de sinyal çoğu zaman "nereden nereye erişildi" ve "hangi paylaşım örüntüsü" üzerinden gelir. Yayılım ve kimlik suistimali şüphesinde SMB erişimleri kritik olabilir; fakat ağ trafiğini tek başına hüküm yerine kimlik logları ve uç nokta olayları ile korele etmek gerekir.

Örnek: Flow verisinde bir istemciden kısa sürede birçok iç hedefe SMB bağlantısı görülüyor. Bu tarama/yayılım hipotezini güçlendirir; karşı kanıt için planlı yönetim araçlarının (envanter/backup vb.) aynı zaman penceresindeki olağan davranışları ve kimlik doğrulama örüntüleri kontrol edilir.

2.4. TLS: şifre var, sinyal bitmedi

TLS içerik görünürlüğünü azaltır; ancak zamanlama, oturum özellikleri ve el sıkışma metadatası hâlâ sinyal üretebilir. Encrypted Traffic Analytics (ETA) yaklaşımı da bu fikir üzerine kurulur: içerik çözmeden, akış karakteristikleri ve TLS özellikleri gibi metaverilerle risk değerlendirmesi yapılabilir.

Sinyal üreten unsurlar:

• SNI (görünürse): istemcinin bağlanmak istediği alan adını sağlar.

• Sertifika özellikleri: sertifika zinciri ve alan adı tutarlılığı bağlam üretir (tek başına "iyi/kötü" değildir).

• Oturum süresi + paket boyutu dağılımı + periyodiklik: özellikle düşük hacimli ama düzenli bağlantılar "beacon" hipotezini besleyebilir.

JA3 parmak izi de TLS el sıkışmasındaki (ClientHello) cipher suite/extension gibi parametrelerden bir imza türeterek, içeriğe bakmadan istemci türü hakkında sinyal sağlayan bir yaklaşımdır.\ Burada ileri yaklaşım, JA3/SNI gibi tekil göstergeleri "kanıt" yerine korelasyon girdisi olarak konumlandırmaktır: aynı zaman penceresinde süreç bağlamı, DNS/proxy kaydı ve akış örüntüsüyle destekleniyorsa delil gücü artar.

Dikkat: TLS üzerinde "şüpheli" diye etiketlenen birçok örüntü, meşru CDN/telemetri davranışlarıyla çakışır. Tek göstergeden sonuç yerine bağımsız ikinci kaynakla doğrulama (uç nokta telemetrisi, kimlik logu, proxy kaydı) şarttır.

2.5. PCAP içinden "ağ nesnesi" çıkarımı: somut delil üretimi

PCAP bazen yalnızca "akış" değil, taşınan nesnelerin adli izlerini de barındırır: bir dosya, bir sertifika zinciri, bir indirilen içerik parçası veya bir uygulama katmanı yanıtı. Bu tür nesneleri adli süreçte somut delil olarak ele almak mümkündür; fakat kanıt bütünlüğü perspektifi korunmalıdır: nesnenin PCAP içindeki bağlamı (hangi oturum, hangi zaman penceresi, hangi uçlar) ve sınırlılıkları raporda açıkça yer almalıdır.

3. C2 / Beacon Tespiti

Beacon tespiti, "düzenli nefes alan" trafiği gürültüden ayıklama disiplinidir. IDS/IPS alarmları veya tek bir anomali bulgusu çoğu zaman yalnızca ipucudur; kanıt standardı için ritim analizi bağlam ve karşı kanıt ile birleşmelidir.

3.1. Periyodiklik, varyans ve jitter: ritmi sayısallaştırmak

Beacon şüphesini güçlendiren işaretler:

• Bağlantı aralıklarının düzenli olması (düşük varyans),

• Trafik boyutlarının benzer kalması,

• Hedeflerin az sayıda ve tutarlı olması,

• Oturumların kısa ama ısrarlı olması.

Ancak modern tehditlerde periyodik düzen kasıtlı olarak "mükemmel" olmayabilir; aralıklara küçük sapmalar (jitter) eklenebilir. Bu nedenle ileri analiz, eşik değer yaklaşımını tek başına yeterli görmez; bağlantı aralıkları (delta time) üzerinden varyans/standart sapma gibi ölçülerle ritmi nicelleştirir.

"Low-and-slow" örüntülerde hacim çok düşük olduğundan "top talkers" gibi hacimsel yaklaşımlar yetersiz kalabilir; bu durumda uzun zaman pencerelerinde (ör. 24-48 saat) ısrarlı, tekrar eden hedef ilişkileri daha anlamlı hale gelir.

İpucu: Dış hedefleri filtrelerken "genel popülerlik listeleri" geçmişte sık kullanılırdı; bazı listeler zamanla erişilemez hale geldi. Bu rolü daha güncel ve manipülasyona dayanıklı alternatifler (ör. Tranco gibi) veya kurumun kendi allowlist/baseline setleri üstlenebilir.

3.2. "Beacon olabilir" hipotezini doğrulamak: karşı kanıt disiplini

Ritmin varlığı tek başına yeterli değildir. Karşı kanıt ararken tipik sorular şunlardır:

• Bu ritim bir meşru ajan/güncelleme/sağlık kontrolü ile açıklanabilir mi?

• Aynı örüntü birçok cihazda mı var (meşru ajan olasılığı artar), yoksa tekil mi?

• Aynı zaman penceresinde uç noktada yeni süreç/servis değişimi, yeni yürütme izleri veya kimlik anormallikleri eşlik ediyor mu?

Örnek: Flow verisinde 203.0.113.10 adresine her 10 dakikada bir kısa TLS oturumu görünüyor. Bu durum tek başına "C2" yazdırmaz. DNS çözümlemesiyle bağlam aranır, proxy kayıtlarında çıkışın kimden yapıldığı doğrulanır ve uç nokta telemetrisinde hangi süreçle eşleştiği kontrol edilir. Bu zincirin herhangi bir halkası zayıfsa raporda iddia temkinli kurulur.

3.3. Kanıt üretimi: beacon iddiasını raporlanabilir hale getirmek

"İstatistiksel his" yerine ölçülebilir bir paket gerekir:

• Zaman penceresi ve örneklem büyüklüğü,

• Ortalama/medyan aralık, varyans/standart sapma,

• Bayt/paket dağılımı,

• Eşlik eden DNS/HTTP/TLS metaverileri,

• Uç nokta süreç bağlamı + kimlik bağlamı ile korelasyon,

• Sınırlılıklar (örnekleme, kapsama boşluğu, zaman sapması, proxy/NAT belirsizliği).

4. Log Korelasyonu (SIEM Mantığı)

Tek bir log satırı ipucudur; birden fazla kaynağın aynı iddiayı bağımsız desteklemesi ise hikâyeyi delile dönüştürür. Korelasyon, "yakın zamanlı iki olayı" aynı şey sanmak değil; zaman + bağlam eşleşmesiyle yeniden üretilebilir bir anlatı kurmaktır.

4.1. Zaman senkronizasyonu ve "süper zaman çizelgesi"

Korelasyonun görünmeyen altyapısı zaman hizalamasıdır:

• Zaman dilimleri (timezone) ve NTP durumu,

• Saat sapmaları (clock drift) ve log kaynakları arasındaki offset,

• Merkezi toplayıcıların gecikmeleri.

Saatler senkron değilse olayların sırası bozulur; "X'ten sonra 1 dakika içinde Y" gibi korelasyon mantıkları çalışmayabilir. Bu yüzden ileri seviye rapor, zaman kayması şüphesi varsa bunu sınırlılık olarak yazmakla kalmaz; mümkünse veriyi ortak bir referansa hizaladığını da belirtir.

4.2. Normalizasyon: aynı şeyi ortak bir dilde konuşmak

Farklı kaynaklar aynı gerçeği farklı alanlarla anlatır: kullanıcı adı biçimleri, cihaz kimlikleri, IP/NAT gerçeği, olay türleri... Normalizasyon; bu alanları ortak şemaya eşleyip sorgulanabilir hale getirir. Korelasyonun kalitesi, çoğu zaman "en iyi kural"dan çok "en iyi alan eşleştirme" ile yükselir.

4.3. Use-case örüntüleri: bağlamla güçlenen korelasyon

Bu modülün omurgasını taşıyan üç örüntü:

• İmkânsız seyahat: Kısa sürede farklı coğrafya iddiası yalnız IP ile değil; cihaz parmak izi, MFA davranışı, oturum süresi ve kullanıcı rutinleriyle doğrulanmalıdır. "GeoIP = kesin konum" gibi bir kesinlik dili raporu kırılganlaştırır.

• Brute-force → başarı → anormal akış: Çok sayıda başarısız girişten sonra başarı ve hemen ardından yüksek bayt çıkışı görülmesi, hipotezi güçlendirir. Yine de bakım penceresi, parola senkronizasyon hataları veya otomasyon gibi masum açıklamalar karşı kanıt olarak test edilmelidir.

• Süreç + ağ eşleşmesi: Uç noktada bir süreç başlar, aynı saniyelerde belirli hedefe ağ trafiği oluşur. İki bağımsız kaynağı birleştirdiği için güçlüdür; proxy/NAT varsa istemci kimliği ek kayıtlarla doğrulanmalıdır.

Dikkat: Korelasyonda en tehlikeli hata, iki kaydı "yakın zamanlı" diye aynı olaya yapıştırmaktır. Zaman yakınlığı kanıt değildir; kimlik, süreç, hedef ve oturum bağlamı birlikte eşleşmelidir.

4.4. Korelasyon çıktısını delil paketine dönüştürmek

Rapor çıktısı "grafik"ten ibaret kalmamalıdır. Denetlenebilir paket şunları içerir:

• Olay zinciri (aşamalar) ve her aşama için delil referansı (kaynak + olay türü + zaman),

• Zaman çizelgesi (dakika düzeyi tutarlılık),

• IoC seti (domain/IP/URL yol örüntüsü/sertifika özelliği gibi) ve bağlam notları,

• Sınırlılıklar ve görünürlük boşlukları,

• Karar notları: hangi delilin hangi operasyonel kararı (izolasyon, kapsam genişletme, ek toplama) desteklediği.

5. Korelasyonlu Vaka Çalışması

Bu bölümün amacı "çok şey gördüm" demek değil; tek bir anlatıya dönüşen ve karar aldıran bir delil paketi üretmektir.

5.1. Veri parçaları ve olay penceresi

Kurgusal bir ortamda aşağıdaki kaynaklar mevcut olsun:

• Proxy logları (HTTP/TLS oturum metadatası),

• DNS logları,

• Flow kayıtları (NetFlow/IPFIX),

• Uç nokta telemetrisi (süreç başlatma + ağ bağlantısı eşleştirmesi),

• Kimlik doğrulama logları (başarısız/başarılı oturum örüntüleri).

Olay penceresinde tek bir uç noktadan dışarıya düzenli aralıklarla kısa TLS oturumları görülüyor; aynı günün ilerleyen saatlerinde aynı uç noktadan birden fazla iç hedefe ağ oturumları oluşuyor.

5.2. Analiz akışı: yöntem seçimi ve doğrulama

• Önce kapsam: Flow ile hangi hedeflere ne yoğunlukta konuşulmuş, ısrarlı hedefler hangileri? Bu adım, "nerelere bakacağınızı" belirleyen haritadır.

• İsim bağlamı: DNS loglarıyla dış hedefin hangi alan adlarıyla ilişkilendiği aranır; yanlış eşleştirme riskine karşı aynı zaman penceresiyle pivot yapılır.

• Çıkış gerçeği: Proxy/NAT var mı? Konuşan gerçekten uç nokta mı, yoksa proxy mi? İstemci kimliği netleşmeden hüküm kurulmaz.

• Süreç bağlamı: Uç nokta telemetrisi, bu trafiği hangi süreç/servisin ürettiğini gösterir; aynı hedefe konuşan meşru süreçler var mı diye karşı kanıt aranır.

• Kimlik ve yayılım: Kimlik loglarıyla kısa sürede çok sayıda iç hedefe oturum var mı, başarısız girişler kümeleniyor mu, normal kullanıcı davranışıyla çelişiyor mu test edilir.

Örnek: DNS loglarında update-check.example.net gibi bir alt alan adına sık sorgular var; flow'da 203.0.113.10 adresine düzenli bağlantılar görülüyor. Bu ikisi tek başına kanıt değildir. Uç noktada aynı dakikalarda beklenmedik bir süreç başlatma kaydı ve süreç+ağ eşleşmesi bulunursa hipotez güçlenir; ancak karşı kanıt olarak yazılım envanterinde benzer "update-check" davranışı olan meşru ajanlar aranır ve aynı sorguların diğer cihazlarda da olup olmadığı kontrol edilir.

$ ir-correlation # DNS + Flow ilişki adayı
$ python correlate_dns_flow.py --domain update-check.example.net --ip 203.0.113.10 --window 2h
dns_hits=56
flow_sessions=48
candidate_hosts=4

$ ir-correlation # Uç nokta süreç + ağ eşleşmesi
$ python match_process_network.py --host ws-2241 --ip 203.0.113.10
process_name=updater-helper.exe
start_time=2026-04-28T11:42:18Z
network_match=True

$ ir-correlation # Karşı kanıt: meşru ajan kontrolü
$ python check_allowlisted_agents.py --process updater-helper.exe
allowlisted=false
peer_hosts_with_same_pattern=1
assessment="suspicious, continue containment-ready monitoring"

5.3. Çıktı: saldırı zinciri + timeline + IoC + aksiyon önerisi

Raporlanabilir çıktı şu şekilde toparlanır:

• Zaman çizelgesi: Her adımın hangi kanıtla desteklendiği (kaynak + zaman + bağlam) açıkça yazılır.

• IoC seti: example.net altında alan adları, 203.0.113.10 gibi IP'ler, "10 dakikada bir kısa TLS oturumu" gibi örüntüler.

• Karar notları: İzolasyon/kapsam genişletme/ek toplama gibi kararların gerekçesi delille bağlanır.

• Sınırlılıklar: PCAP yoksa içerik doğrulama sınırı; flow örneklemesi varsa kaçırma riski; zaman sapmaları ve proxy/NAT belirsizlikleri açıkça belirtilir.

Dikkat: "Kesin saldırı" gibi iddialı cümleler ancak bağımsız kaynaklar aynı iddiayı tutarlı biçimde desteklediğinde kullanılmalıdır. Aksi halde rapor dili olasılık ve doğrulama testleriyle temkinli kurulmalıdır.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• PCAP ile flow arasında, olayın sorusuna göre yöntem seçmeyi ve seçimin maliyet/görünürlük etkisini raporda gerekçelendirmeyi.
• Yakalama kalitesi (kapsam, örnekleme, paket kaybı, zaman sapması) nedeniyle “yokluk” yorumunun neden temkinli yapılması gerektiğini.
• HTTP/DNS/SMB/TLS protokollerinde sinyal üreten alanları, proxy/NAT/şifreleme gerçekleriyle birlikte değerlendirmeyi.
• Şifreli trafikte içerik çözmeden metaveri temelli analizle hipotez üretmeyi; hipotezi süreç/kimlik/timeline ile doğrulayıp güçlendirmeyi.
• Beacon/C2 şüphesini periyodiklik, varyans/jitter ve bağlam testleriyle sayısallaştırarak raporlanabilir hale getirmeyi.
• SIEM mantığında normalizasyon + korelasyon ile saldırı zinciri, timeline, IoC ve karar notlarını tek bir delil paketine dönüştürmeyi.

MODÜL 9 — Zararlı Yazılım Analizi ve Tersine Mühendislik (IR Odaklı)

Modül Teması

Olay müdahalesi sırasında "zararlı yazılım analizi", tek başına teknik bir merak alanı değil; zaman baskısı altında operasyonel kararı besleyen bir kanıt üretim disiplinidir. Soru hep aynıdır: Bu dosya gerçekten zararlı mı; sistemde neyi değiştirdi; nereye/kimle konuştu; yayılım ihtimali ne; hangi göstergelerle güvenle tespit edilir; ve tüm bunlar raporda denetlenebilir delil standardında nasıl sunulur?

Bu modül, hızlı triage ile doğru derinliği seçmeyi; statik ve dinamik bulguları bağımsız kaynaklarla doğrulamayı; gerektiğinde hedefli tersine mühendislikle belirsiz noktaları netleştirmeyi; çıktıyı da (IoC + davranış profili + öneriler) containment/eradication/recovery kararlarına bağlamayı öğretir.

1. Güvenli analiz ortamı ve çalışma disiplini

Zararlı analizi, laboratuvarda yürütülen bir deney gibidir: güvenlik sadece "izolasyon" değildir; aynı zamanda başka bir analistin aynı koşulları kurup aynı sonuca varabilmesi demektir. Bu yüzden sandbox yaklaşımı; kontrollü ortam, tutarlı kayıt, tekrar edilebilirlik ve kanıt paketleme ile birlikte ele alınır.

1.1. İzolasyon ve risk yönetimi: "tetiklemek" mi, "gözlemek" mi?

Aynı örneği incelemenin birden fazla yolu vardır; doğru seçim, olayın hedefi ve risk toleransına göre yapılır:

• IR odağı: Amaç "her şeyi çözmek" değil, hızlı ve güvenilir karar destek çıktısı üretmektir. Bu yüzden gözlem planı, containment ve tespit ihtiyacına göre sınırlandırılır.

• Davranışı tetiklemeye yönelik çalışma: Örneği çalıştırıp davranışı görünür kılmak caziptir; ancak örnek her koşulda aynı davranışı göstermeyebilir. "Çalışmadı" sonucu, "zararlı değil" anlamına gelmez; raporda bu sınır net yazılır.

• Sınırlı gözlem: Bazı durumlarda örneği tam yürütmek yerine, riskin düşük tutulduğu, yalnızca hangi kaynaklara yöneldiğini ve ne tür izler bırakma eğiliminde olduğunu anlamaya odaklanan gözlemler daha doğru olabilir.

Dikkat: Analiz ortamının kurumsal ağa istemeden temas etmesi, tek olayı ikinci bir olaya dönüştürebilir. IR bağlamında bu risk kabul edilmez; izolasyon teknik bir ayar kadar, süreç disiplini (yetki, erişim sınırı, kayıt) işidir.

1.2. Ağ görünürlüğü: dış dünya kapalıyken davranış nasıl okunur?

Birçok zararlı, internet yoksa tam davranışını göstermeyebilir. Bu noktada iki uç yaklaşım arasında yöntem seçimi yapılır:

• Dış ağa çıkışı kesmek: Örneğin dışarıya veri sızdırma veya "analiz ediliyorum" sinyali verme riskini azaltır.

• Ağ servislerini izole biçimde simüle etmek: İnternete çıkmadan, DNS/HTTP gibi servislerin taklit edildiği bir düzenekle zararlının ağ davranışı görünür hale getirilebilir (ör. FakeNet-NG yaklaşımı "internet hizmetlerini simüle ederek" trafiği kontrollü biçimde yakalamaya odaklanır).

Bu karar, "davranışı açığa çıkarma" ile "operasyonel risk" arasında denge kurar. Kritik olan; hangi seçimin neden yapıldığını ve neyin kapsam dışı kaldığını raporda açık tutmaktır.

1.3. Snapshot ve kayıt standardı: "ne gördüm" değil, "neye dayanıyorum"

Raporun omurgası, gözlemi delile dönüştürmektir. Pratikte üç katman raporu dayanıklı kılar:

• Ortam tanımı: işletim sistemi sürümü, temel uygulama seti, ağ görünürlüğü, saat senkronizasyonu, snapshot durumu

• Gözlem kanıtı: zaman damgalı olay kayıtları, ham log/telemetri çıktıları, alınan örneklerin bütünlük bilgisi

• Yorum + alternatif açıklamalar: masum yazılım olasılığı hangi karşı kanıtlarla elendi; hangi belirsizlikler kaldı?

Örnek: Bir ikilinin dışarıya bağlanma girişimi gözlenir. Bu "zararlı iletişim" de olabilir, meşru bir güncelleme kontrolü de. Karar vermeden önce hedefin kurum envanterindeki meşru servislerle ilişkisi, benzer davranışın benzer makinelerde yaygınlığı ve eşlik eden kalıcılık izleri birlikte değerlendirilir.

İpucu: Not tutmayı standartlaştırın: zaman aralığı + gözlem + kaynak + doğrulama notu. Bu düzen, raporda "kanıt-yorum" çizgisini kendiliğinden korur.

1.4. Operasyonel güvenlik: örneği nereye "taşıdığın" da bulgudur

Hedefli vakalarda, şüpheli dosyayı kamuya açık analiz ekosistemlerine yüklemek; örneğin kurum dışına çıkması, farklı taraflarca erişilebilir hale gelmesi ve saldırganın tepki geliştirmesi gibi riskler doğurabilir. Bu yüzden kurum politikası, hukuki çerçeve ve risk değerlendirmesiyle hareket edilir.

İpucu: Çoğu durumda "dosyayı yüklemek" ile "yalnızca hash/metadata üzerinden sorgulamak" aynı şey değildir. IR'de amaç hız kazanmaksa, gereksiz ifşa riskini büyütmeden ilerleyen bir yol tercih edilir.

2. Hızlı statik triage: doğru soruyu dakikalar içinde seçmek

Statik triage, paketin dışına bakarak içeriği hakkında fikir yürütmeye benzer: paketi açmadan da risk işaretlerini görürsünüz. Burada kritik olan; sinyallerin güvenilirlik sınırını bilmek ve hangi sinyalin hangi soruyu hızlı yanıtladığını anlamaktır.

2.1. Kimlik ve köken sinyalleri: dosya "iddia ettiği şey" mi?

• Tür tutarlılığı: "belge" gibi görünen bir dosyanın çalıştırılabilir özellikler taşıması, IR'de hemen ayrı bir hipotez doğurur.

• İmza/yayımlayıcı bilgisi: İmza varlığı tek başına masumiyet kanıtı değildir; ama zincir tutarlılığı, "meşru yazılım olabilir" hipotezini test ederken güçlü bir karşı kanıt kaynağıdır.

• Paketleme/obfuscation şüphesi: İç yapının "normal" yazılım desenlerinden sapması, statikte ısrar etmek yerine dinamik gözleme geçmeyi gerektirebilir.

Dikkat: Derleme zamanı gibi bazı metadata alanları kolayca yanıltıcı olabilir. Tek başına karar verdirici kanıt olarak kullanılmaz; ancak başka kanıtlarla tutarlıysa bağlam sağlar.

2.2. Imports/IAT ve "dinamik çözümleme" işareti: neyi düşündürür?

Bir örneğin import tablosunun çok sınırlı olması ve "çalışma anında API çözümleme" yaklaşımına işaret etmesi, statik görünürlüğü düşürebilir. Bu, zararlının niyetini tek başına kanıtlamaz; fakat dinamik analiz planınızı "hangi davranışları özellikle aramalıyım?" diye keskinleştirir.

Ayrıca, yüksek entropi gibi ölçümler (özellikle belirli bölümlerde) paketleme/şifreleme olasılığını destekleyen bir işaret olarak kullanılır; karar verdirici değil, hipotez güçlendirici bir sinyaldir.

Örnek: Statik bulgular, ağ erişimi ve kalıcılık davranışı ihtimalini düşündürür. Dinamikte sadece "ağ var mı?" değil, "ağa eşlik eden kalıcılık izi var mı?" sorusu da gözlem planına alınır.

2.3. Strings ve "kör noktalar": okunabilir iz yoksa ne olur?

Strings analizi; URL parçaları, hata mesajları, dosya yolu ipuçları gibi bulgularla IoC üretimini hızlandırabilir. Ancak dize şifreleme, çalışma anında üretim (örn. "stack üzerinde oluşan dizeler") veya yoğun gürültü; statik sinyalleri zayıflatabilir.

Bu durumda yöntem seçimi şöyle evrilir:

• Statik, yalnızca hipotez üretir → dinamik analiz, hipotezi test edecek şekilde hedefli tasarlanır

• Statik ve dinamik çelişirse → rapor dili "kesin" değil, **doğrulama adımları ve sınırlılıklar** üzerinden kurulur

3. Dinamik davranış analizi: gürültüden kanıt çıkarmak

Dinamik analiz, "çalıştır ve izle" değil; kontrollü gözlemdir. IR'de karar verdiren şey çoğu zaman "kodun içi" değil; sistemde neyi değiştirdiği ve neyle konuştuğudur.

3.1. IR için anlamlı davranış sınıfları

Bulguları raporlamayı kolaylaştırmak için davranışı şu başlıklarda toplamak işe yarar:

• süreç zinciri ve yürütme izi

• dosya sistemi değişimleri ve bırakılan artefaktlar

• kalıcılık sinyalleri (yeniden başlatma sonrası iz)

• ağ davranışı (hedefler, ısrar, periyodiklik, "low-and-slow" ritimler)

• kimlik/yetki sinyalleri (beklenmedik yetki ilişkileri, anormal kimlik erişimleri)

Dikkat: Dinamik analiz "gözlenen davranış" üretir; "gözlenmeyen davranış yoktur" üretmez. Çevre bağımlılığı (kullanıcı, ağ, sistem) nedeniyle görünmeyen davranışların olasılığı raporda açık tutulur.

3.2. Doğrulama: çevre gürültüsü mü, davranış izi mi?

İki güçlü yaklaşım, yanlış pozitif riskini dramatik biçimde azaltır:

• Karşılaştırmalı okuma: aynı ortamda "beklenen normal" ile kıyas

• Çapraz kanıt: host artefaktları + log/telemetri + ağ verisi arasında tutarlılık arama

Örnek: Kısa süreli DNS sorgu artışı görülür. Bu tünelleme şüphesi doğurabilir; ama meşru bileşenler de benzer örüntü üretebilir. Karşı kanıt olarak, hedef alan adlarının benzer makinelerde yaygınlığı ve eşlik eden kalıcılık/dosya izi olup olmadığı birlikte değerlendirilir.

3.3. Şifreli trafik: içerik görünmüyorsa neye güvenilir?

İçerik yokken "tek sinyal"e yaslanmak risklidir. IR'de daha güvenilir olan, metaveri örüntülerinin birlikte tutarlılığıdır:

• bağlantı ritmi ve periyodiklik

• hedef çeşitliliği (tek hedefe ısrar mı, dağılım mı)

• oturum süreleri ve hacim profili

• zaman çizelgesinde diğer davranışlarla eşleşme (süreç başlatma → hemen dış iletişim gibi)

3.4. "Hiçbir şey olmuyor" durumu: bulgu değil, sınırdır

Örnek çalışır gibi görünüp davranış üretmiyorsa bu, "zararlı değil" demek değildir. Anti-analiz/çevre kontrolü, koşula bağlı tetikleyiciler veya yalnızca gözlemin kapsamadığı bir davranış penceresi söz konusu olabilir. IR açısından doğru refleks; bunu raporda sınırlılık olarak yazmak ve ek kanıt kaynaklarına (disk artefaktları, log korelasyonu, bellek incelemesi, ağ akış verisi) pivot etmektir.

4. IoC çıkarma, zenginleştirme ve paylaşım: liste değil, paket

IoC üretimi, savunmayı güncellemenin en hızlı yollarından biridir; aynı zamanda yanlış pozitif üretmenin de en hızlı yoludur. Bu yüzden IoC'nin değeri, bağlam ve doğrulamadan gelir.

4.1. Dayanıklılık perspektifi: kırılgan gösterge vs davranış kalıbı

• Kırılgan göstergeler: kolay değişebilen tekil değerler (tek bir domain/IP gibi). Hızlı triage için iyidir, tek başına uzun vadede zayıf kalabilir.

• Daha dayanıklı göstergeler: süreç+ağ korelasyonu, tutarlı kalıcılık izi, özel davranış örüntüsü gibi "kalıp" göstergeler. Değişime daha dirençli olabilir; doğrulaması daha fazla emek ister.

Örnek: Sadece example.net alan adını engellemek hızlıdır; ancak altyapı değişirse etkisi azalır. Buna karşılık "belirli süreç zinciri + belirli bağlantı ritmi + belirli kalıcılık izi" gibi desen, değişime daha dayanıklı olabilir; ama kurum envanterinde masum çakışma ihtimali mutlaka test edilir.

4.2. "IoC kartı" yaklaşımı: operasyonel kullanımı netleştirme

Bir IoC'yi raporlanabilir ve işletilebilir kılan, şu bilgilerin birlikte verilmesidir:

• kaynak (hangi analiz/telemetri)

• zaman bağlamı (hangi pencere)

• güven seviyesi (tek kaynak mı, çapraz doğrulamalı mı)

• yanlış pozitif riski (hangi meşru yazılımlar benzer davranabilir)

• kullanım notu (nerede aranır, ne kadar süre aktif tutulur, neyle teyit edilir)

İpucu: IoC'nin yanına "tetiklenirse ikinci hangi kanıtla doğrulanır?" notu ekleyin. Bu küçük alışkanlık, SOC tarafında alarm kalitesini belirgin biçimde artırır.

4.3. Standardizasyon ve geri bildirim döngüsü

IoC'lerin ekipler arasında anlam kaybı yaşamaması için:

• bağlamla birlikte paylaşım

• sürümleme (ne zaman değişti)

• false positive geri bildirimiyle iyileştirme yaklaşımı benimsenir. Burada amaç "kural yazmak" değil; kuralın neden doğru olduğunun kanıtla açıklanmasıdır.

5. IR için "sınırlı" tersine mühendislik: yeterli derinliği seçmek

Bu modülde tersine mühendislik, "dipsiz kuyu" değil; IR'nin ihtiyacına hizmet eden hedefli bir araçtır. Öncelik; şu sorulara kanıtlı cevap üretmektir:

• ne yapıyor, hangi eylemleri tetikliyor?

• nasıl kalıcı olmaya çalışıyor?

• nereye bağlanıyor, yapılandırmasını nerede tutuyor?

• hangi izlerle tespit edilir?

5.1. Ne zaman kod seviyesine inilir?

Kod incelemesine geçmek çoğu zaman şu durumlarda rasyoneldir:

• dinamik analiz "ne yaptığını" gösteriyor ama "neden/nereden" kısmı belirsiz kalıyorsa (örn. yapılandırma kaynağı)

• üretilen IoC'ler çok kırılgansa ve daha dayanıklı bir desen gerekiyorsa

• örnek çevre bağımlı davranıyor ve dinamik gözlem sınırlı kalıyorsa

Buna karşılık zaman baskısı yüksekse ve containment kararı bekliyorsa, davranış + korelasyon çoğu zaman daha doğru yatırım olur.

Dikkat: IR odaklı tersine mühendislikte amaç "engelleri aşmak" değildir. Anti-analiz/paketleme gibi unsurlar, raporda bir risk ve sınırlılık olarak yer alır; kesin iddialar bu sınıra göre kurulmalıdır.

5.2. Kod bulgusunu delile dönüştürmek: davranışla birleşmeyen yorum kalır

Kodda görülen bir hedef/kalıcılık mantığı, dinamikte gözlenen izlerle tutarlıysa delil gücü artar. Çelişki varsa rapor dili "kesin" olmaz; olasılıklar ve doğrulama ihtiyacı açık yazılır.

Örnek: Kod, yapılandırmanın yerel bir kaynaktan okunabileceğini düşündürür; dinamik gözlemde ise ağ bağlantısı vardır ama yerel iz zayıftır. Bu çelişki, koşula bağlı farklı bir kaynak olasılığını doğurur; raporda bu olasılık belirtilir ve hangi ek kanıtla netleştirileceği yazılır.

5.3. Teknik bulgudan operasyonel karara bağlama

Bu modülün çıktıları, IR yaşam döngüsünde doğrudan şuraya oturur:

• Containment: hangi göstergelerle hangi varlıklar izole edilir (cihaz/hesap/segment)

• Eradication: hangi kalıcılık izleri temizlenmeden geri dönme riski sürer

• Recovery: izleme ne kadar sürer; "geri döndü" sinyalleri neler olur

• Lessons learned: hangi tespit boşluğu vardı (telemetri, log eksikliği, görünürlük) ve nasıl kapanır

İpucu: Operasyonel karar cümlelerini her zaman bir delil referansına (zaman çizelgesi + kaynak + doğrulama notu) bağlayın. Bu, teknik ekip ile karar verici katman arasındaki güveni gözle görülür biçimde artırır.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Zararlı analizini, IR’de karar destek üreten bir kanıt disiplinine dönüştürmeyi
• Sandbox yaklaşımını yalnız izolasyon değil, kayıt ve yeniden üretilebilirlik standardı olarak kurmayı
• Statik triage ile doğru derinliği seçmeyi; sinyallerin güvenilirlik sınırını yönetmeyi
• Dinamik analizde davranışı gürültüden ayırıp çapraz kanıtla doğrulamayı
• IoC’leri bağlam, güven seviyesi ve kullanım notlarıyla operasyonel pakete dönüştürmeyi
• Sınırlı tersine mühendisliği, IR’de gerekli sorulara cevap veren hedefli bir araç olarak konumlandırmayı

MODÜL 10 — Diğer Platformlar ve Ortamlarda Adli Analiz

Modül Teması

Modern bir olay müdahalesi neredeyse hiçbir zaman tek bir uç noktaya sığmaz. Aynı olayın izleri; Linux sunucularda kimlik doğrulama ve kalıcılık kayıtlarında, macOS uç noktalarda Apple'ın kendine özgü artefaktlarında, bulutta API çağrılarının denetim izlerinde ve mobil cihazlarda şifreleme-edinim dengesinin belirlediği veri katmanlarında dağınık halde durabilir. Bu modülün odağı, her ortamda hangi verinin neye kanıt olabileceğini seçebilmek; bulguları bağımsız karşı kanıtla doğrulamak; ardından çıktıyı kanıt standardında (zaman çizelgesi, kaynak belirtimi, yeniden üretilebilirlik, belirsizliklerin açık yazımı) paketleyerek containment/eradication/recovery kararlarına bağlamaktır.

1. Linux Adli Analizi

Linux sunucular çoğu kurumda "omurga" rolündedir; bu yüzden saldırganlar açısından da uzun süreli kalıcılığın ve sessiz hareketin uygun zemini olabilir. Windows'taki gibi merkezi bir "registry" mantığı yerine, Linux'ta davranışın izi çoğunlukla metin tabanlı loglar, yapılandırma dosyaları, zamanlayıcı/servis tanımları ve dosya sistemi meta verileri üzerinden okunur. Bu çeşitlilik, tek bir kaynağa yaslanan yorumları kırılgan hale getirir; sağlamlık, tutarlı bir artefakt seti kurmaktan gelir.

1.1. Kimlik doğrulama ve yetkilendirme izleri: "kim, ne zaman, hangi bağlamda?"

Linux olaylarında ilk sorulardan biri "giriş yapıldı mı?" değil, "girişin bağlamı olağan mı?" olmalıdır. Kimlik doğrulama kayıtları (SSH oturumları, başarısız giriş dalgaları), yetki kullanımı (sudo benzeri yükseltmelerin anomali üretmesi) ve hesap değişiklikleri (yeni kullanıcı/anahtar eklenmesi, yetki kapsamının genişlemesi) birlikte okunur.

Doğrulama, burada şu refleksle başlar: tek bir "başarılı giriş" kaydı, ele geçirmeyi kanıtlamaz. Aynı zaman penceresinde;

• oturumun başlattığı süreç zinciri,

• kritik yapılandırma/dosya değişiklikleri,

• anormal ağ davranışı (beklenmedik dış bağlantılar, beacon benzeri periyodiklik)\ gibi bağımsız izlerle tutarlılık aranır.

Örnek: Bir gece kısa aralıklarla artan başarısız SSH denemeleri görülür, ardından tek bir başarılı giriş kaydı gelir. Bu tablo "parola denemesi" hipotezini güçlendirir; ancak kesin hüküm için aynı pencerede hesap/anahtar değişikliği, yetki kullanım anomalisı ve süreç+ağ eşleşmesi aranır. Bu üçlü tutarlılık yoksa, meşru bakım erişimi gibi masum açıklamalar hâlâ masada kalır.

Dikkat: Linux'ta loglar rotasyona uğrayabilir; kimi ortamlarda merkezi loglama da olmayabilir. "Gördüğün kadarıyla" sınırlılık, raporda saklanacak bir kusur değil, bulgunun kanıt ağırlığını doğru tartmak için yazılması gereken bir bilgidir.

1.2. Komut satırı, geçici alanlar ve yürütme izleri: "ne yapıldı, nerede iz bıraktı?"

Komut satırı geçmişi (ör. kullanıcı kabuğunun history davranışı) olay hikâyesini destekleyebilir; fakat ileri seviye olaylarda bunun eksik/boş olması olağandışılık değildir. Bu nedenle yöntem seçimi iki eksende şekillenir:

• Düşük müdahaleyle hızlı kanıt üretimi: Mevcut loglar, süreç bilgisi, dosya meta verileriyle kısa sürede zaman çizelgesi ve ön bulgular üretmek.

• Derinlemesine doğrulama: Silme/temizleme şüphesi, şifreleme veya anti-forensic sinyaller varsa, daha kapsamlı artefakt analizi (imaj/backup gibi) gerekebilir.

Linux'ta özellikle dünya-yazılabilir alanlar (ör. geçici dizinler ve paylaşımlı bellek bölgeleri gibi) olaylarda sık karşımıza çıkar: saldırganın "araç indirip çalıştırdığı" iddialarının doğrulanması çoğu zaman bu bölgelerdeki dosya yaşam döngüsü izleri, süreçlerin dosya tutma davranışı ve zaman damgası korelasyonuna dayanır.

İpucu: History dosyasının boş olması "hiç komut çalıştırılmadı" anlamına gelmez. İleri doğrulama, aynı eylemi farklı bir iz üzerinden yakalamayı hedefler: süreç zinciri, dosya erişim kalıpları, ağ bağlantıları ve zaman çizelgesi tutarlılığı çoğu zaman daha güçlü kanıt üretir.

1.3. Kalıcılık: cron ve servis yöneticileri üzerinden "geri geliyor mu?"

Linux'ta kalıcılık genellikle zamanlayıcılar ve servis mekanizmaları üzerinden kurulur. Burada kritik ayrım "var mı?" değil, "meşru mu?" sorusudur:

• Beklenmedik zamanlayıcı/servis tanımları ve olağandışı çalıştırma zamanları bir sinyal üretir.

• Meşruiyet testi, envanterle uyum ve değişiklik zamanının yetkili bakım pencereleriyle ilişkisi üzerinden yapılır.

• Karşı kanıt arayışı, aynı nesnenin benzer sunucularda yaygın olup olmadığı ve değişikliğin iş gerekçesiyle açıklanıp açıklanmadığıyla güçlenir.

Örnek: Gece saatlerinde düzenli aralıklarla çalışan bir iş tanımı bulunur. Bu, bir arka plan görevi de olabilir, kalıcılık sinyali de. Kanıt standardı açısından belirleyici olan, bu tanımın hangi paket/uygulama ile ilişkili olduğu, değişikliğin kim tarafından yapıldığı ve aynı zaman penceresinde ağ/kimlik izleriyle tutarlılık gösterip göstermediğidir.

2. macOS Adli Analizi

macOS, UNIX temelli olsa da Apple'ın kendi dosya sistemi (APFS) ve olay kayıt mimarisi nedeniyle "Linux gibi düşünür ama farklı kanıt yolları ister." Metin tabanlı klasik log beklentisi, macOS'ta sıkça yanıltıcıdır; ileri seviye analiz, Unified Logging, dosya sistemi olay izleri ve indeks/yedek mekanizmalarını birlikte kullanmayı gerektirir.

2.1. Unified Logging: "parçalı sinyali bütünlemek"

macOS'ta birçok sistem olayı düz metin loglardan ziyade, yüksek performanslı ve sıkıştırılmış bir loglama altyapısı içinde tutulur (uygulamada bunun izleri, platformun kullandığı ikili log formatlarıyla da görülür). Neden önemli? Çünkü yanlış araç/yanlış beklentiyle bakıldığında "log yok" sanılan yerde aslında zengin bir telemetri vardır.

Kanıt üretimi için iki nokta öne çıkar:

• Aynı zaman penceresinde birden fazla log katmanından tutarlılık aramak,

• Log bulgusunu dosya/uygulama artefaktlarıyla eşleştirmek (ör.kalıcılık nesnesi ile log sinyali aynı hikâyeyi anlatıyor mu?).

Dikkat: macOS'ta bazı veriler erişim denetimleri ve mahremiyet kontrolleri nedeniyle sınırlı görülebilir. "Görmüyorum" ile "yok" arasındaki fark, raporda açık yazılmadığında yanlış kesinlik üretir.

2.2. APFS snapshot, Time Machine ve "zaman makinesi" etkisi

APFS snapshot'lar ve Time Machine, belirli senaryolarda kaybolduğu düşünülen parçaları geri getirmeye yarar: silinmiş/taşınmış bir dosyanın olay penceresindeki varlığı, geçmiş durumlarla karşılaştırıldığında daha net anlaşılabilir. Burada yöntem seçimi, olayın operasyonel baskısına göre yapılır:

• Hızlı containment gereken anlarda önce kritik log/telemetri ve yürütme izleriyle karar destek üretmek,

• Kapsam büyüdüğünde veya anti-forensic şüphesi arttığında snapshot/backup kaynaklarıyla hikâyeyi sağlamlaştırmak.

Şifreleme (ör. FileVault) ve cihazın durumu, hangi veri sınıflarının erişilebilir olacağını etkileyebilir. Bu yüzden snapshot/backup üzerinden çıkarım yapılırken "erişilebilen veri sınıfı" ve "yeniden üretilebilirlik koşulları" raporda net olmalıdır.

2.3. FSEvents ve Spotlight: kullanıcı davranışını çözümlemek

macOS'ta dosya sistemi olay izleri (FSEvents gibi mekanizmalar) ve indeksleme/arama altyapıları (Spotlight) ileri analizde güçlü bağlam sunabilir. Dosya üzerinde "oluşturma-değiştirme-silme" hareketlerinin zaman çizelgesine katkısı, özellikle "ben o dosyayı görmedim / kullanmadım" gibi iddiaları doğrulama veya çürütme açısından değerlidir.

Örnek: Bir kullanıcı, belirli bir belgeyi hiç açmadığını söyler. Aynı belge için dosya sistemi olay izleri, indeksleme meta verisi ve uygulama log sinyalleri tutarlı şekilde "erişim" gösteriyorsa, bulgu yalnız bir iddia değil, çok kaynaklı bir kanıt haline gelir.

İpucu: macOS incelemesinde "tek büyük delil" yerine "küçük ama tutarlı sinyaller" yaklaşımı genellikle daha güvenilirdir. Bir sinyalin masum açıklaması olabilir; üç ayrı kaynaktan aynı hikâye akıyorsa, yanlış pozitif riski hızla düşer.

3. Bulut Adli Analizi (Genel)

Bulutta adli analiz, çoğu zaman fiziksel disk/belleğe doğrudan erişim varsayımıyla değil, API düzeyi denetim izleri ve snapshot/backup mantığıyla yürür. Bulutun "paylaşımlı sorumluluk" doğası, analistin veri toplama yeteneğini belirli bir katmanla sınırlar: sağlayıcının fiziksel altyapısı size ait değildir; sizin kontrolünüz, size sunulan servis arayüzleri ve kendi iş yüklerinizin (instance/VM, konteyner, uygulama) katmanıyla sınırlıdır.

3.1. Log-first yaklaşımı: yönetim düzlemi olayın omurgasıdır

Bulutta "konsola giriş", "sunucu oluşturma", "depolama nesnesini silme", "erişim politikasını değiştirme" gibi eylemler, temelde API çağrılarıdır ve denetim loglarına yansır (AWS CloudTrail, Azure Activity Logs, GCP benzeri audit logları gibi). Bu nedenle ilk amaç, saldırı hikâyesini yönetim düzleminden kurmaktır:

• Kim hangi kaynağı oluşturdu/değiştirdi/sildi?

• IAM tarafında beklenmedik yetki genişletme, rol/anahtar değişimi, MFA davranış anomalisı var mı?

• Depolama erişimlerinde olağandışı indirme/okuma desenleri veya "public" hale gelme sinyali görülüyor mu?

Doğrulamada "tek bir çağrı" yeterli sayılmaz: aynı zaman penceresinde kimlik değişiklikleri, politika güncellemeleri ve veri erişim kalıbı birlikte değerlendirilir.

Örnek: Bir iş yükünün silinmesine karşılık gelen bir API çağrısı görülür. Çağrının kullanıcı ajanı (UserAgent) veya otomasyon izi, kurumda normalde kullanılan istemci profilinden belirgin biçimde farklıysa (ör. beklenen arayüz yerine bir SDK/otomasyon imzası), çalıntı anahtar veya yetkisiz otomasyon hipotezi güçlenir. Bu hipotez, aynı kullanıcının önceki davranışları ve eş zamanlı IAM değişiklikleriyle sınanır.

Dikkat: Bulutta kanıt toplama eylemleri de iz bırakabilir. Gereksiz değişiklik, zaman çizelgesini bulanıklaştırır; ayrıca olayın etkisini artırabilir. "Topladım çünkü gerekliydi" gerekçesi ve minimum müdahale prensibi, bulutta daha sert bir standarttır.

3.2. Snapshot/forensic image yaklaşımı: ne zaman, neden?

Bazı olaylarda denetim logları tek başına yetmez: iş yükünün içeride ne yaptığı belirsizse, dosya sistemi düzeyinde değişiklik şüphesi varsa veya loglara müdahale olasılığı konuşuluyorsa snapshot/forensic image yaklaşımı gündeme gelir. Buradaki yöntem seçimi, bir denge işidir:

• Üretim ortamına etkiyi düşük tutmak,

• Delil bütünlüğünü korumak,

• Analizi izole ve denetlenebilir bir ortamda yapabilmek.

Pratikte "canlı sistemde derin analiz" yerine, kontrollü bir kopya üzerinde çalışmak çoğu zaman daha güvenli ve daha savunulabilir bir kanıt zinciri üretir. Yine de her olayda bu yol şart değildir; log-first ile hızlı karar desteği üretmek, containment baskısı altında daha gerçekçi olabilir.

3.3. Çoklu veri kaynağı korelasyonu: bulutta "tek doğru" nadir

Güvenilir sonuçlar, katmanlar arası tutarlılıktan çıkar:

• Yönetim düzlemi denetim logları,

• İş yükü telemetrisi (EDR/agent varsa),

• Ağ akış verileri,

• Uygulama logları ve erişim kayıtları.

Bu korelasyon, teknik bulguyu operasyonel karara dönüştürür: hangi hesabın izole edileceği, hangi anahtarın iptal edileceği, hangi kaynağın güvenli yeniden oluşturulacağı gibi.

4. Mobil Adli Bilişim (iOS/Android) — Detaylandırılmış

Mobil cihazlar, kullanıcıların iletişim, konum, kimlik ve iş süreçlerini taşıdığı için DFIR'de kritik bir yer tutar. Aynı zamanda modern şifreleme ve volatilite, mobil incelemeyi "hızlı ama temkinli" bir disipline dönüştürür: geç kalındığında veri değişebilir; acele edildiğinde kanıt bozulabilir.

4.1. Zorluklar ve riskler: şifreleme, volatilite, uzaktan müdahale

Mobilde üç risk alanı sürekli akılda tutulur:

• Şifreleme ve kilit durumu: erişilebilir veri sınıflarını belirler (FDE/FBE gibi yaklaşımlar, cihaz ve sürüme göre farklı etki yaratır).

• Verinin hızla değişmesi: uygulama cache'leri, mesaj indeksleri, geçici loglar kısa ömürlü olabilir.

• Uzaktan silme/erişim kesme riski: özellikle kullanıcı ya da saldırgan tarafında uzaktan yönetim kanalları varsa delil kaybı riski artar.

Dikkat: Mobil olaylarda yapılan her eylem (toplama, izolasyon, analiz) "kanıtı koruyor mu, değiştiriyor mu?" sorusuyla birlikte düşünülmelidir. Kurum prosedürü, hukuki yetki ve minimum veri ilkesi netleşmeden geniş kapsamlı edinim, raporu da delili de zayıflatır.

4.2. Edinim (Acquisition) türleri: kapsam-risk-yetki dengesi

Mobilde edinim, "en çok veriyi al" yarışı değildir; doğru edinim, olay hedefi ve erişim koşullarıyla uyumludur:

• Mantıksal edinim (logical): yedekler ve uygulama seviyesinde erişilebilen veriler üzerinden ilerler; hızlıdır, ancak kapsam sınırlı olabilir.

• Dosya sistemi edinimi (file system): daha geniş artefakt seti sağlayabilir; erişim koşulları cihaza, sürüme ve yetkilere bağlıdır.

• Fiziksel edinim (physical): teorik olarak en kapsamlıdır; modern cihazlarda güçlü şifreleme nedeniyle ham kopya çoğu zaman tek başına anlamlı değildir ve uygulanabilirlik her vakada mümkün olmayabilir.

BFU/AFU çerçevesi burada belirleyicidir: cihaz yeniden başlatıldıktan sonra henüz ilk kilit açma yapılmadıysa (BFU), kullanıcı verilerinin önemli bir bölümü erişilemez kalabilir; ilk kilit açmadan sonra (AFU) veri erişilebilirliği artabilir. Bu farklılık, bulgunun kapsamına doğrudan etki eder ve raporda açıkça yazılmalıdır.

4.3. iOS artefaktları: yedekler, SQLite ekosistemi ve davranış izleri

iOS "kapalı kutu" doğası gereği, artefaktların çoğunu yedekler ve uygulama veri yapıları üzerinden okursunuz. İleri analizde sık karşılaşılan kaynaklar:

• iTunes/Finder yedekleri ve kurum politikası uygunsa iCloud senkron verileri,

• Mesaj ve iletişim artefaktları (ör. mesaj veritabanları),

• Tarayıcı izleri ve web artefaktları (çerez ve geçmiş gibi),

• Kullanıcı davranışını zaman çizelgesine bağlayan sistemsel veritabanları (ör. knowledgeC.db gibi kaynaklar; uygulama kullanım süreleri, kilitlenme/açılma zamanları ve çeşitli cihaz olaylarını ilişkilendirmede değerli olabilir),

• Konumla ilgili izler (senaryoya göre; kapsam sınırı gözetilerek).

Örnek: Bir kullanıcı "o gün o uygulamayı hiç kullanmadım" der. Uygulama kullanım izleri, cihaz kilit-aç döngüsü ve ilgili zaman penceresindeki mesajlaşma/metaveri bulguları tutarlıysa, ifade artık yorum değil, kaynakları belli bir gözlem zincirine dönüşür.

4.4. Android artefaktları: parçalı ekosistemde tutarlılık aramak

Android'in üretici ve sürüm çeşitliliği, analizin standartlaşmasını zorlaştırır. Bu yüzden "aynı yöntemi her cihaza uygularım" yaklaşımı yerine, erişim koşullarına göre kanıt üretmek gerekir:

• Cihaz ve kurumsal yapılandırmaya göre değişen sistem kayıtları,

• Uygulama veri dizinleri ve uygulama içi veritabanları,

• Uygulama kullanım geçmişi (UsageStats benzeri kaynaklar),

• Bulut hesabı kaynakları (ör. Google Takeout üzerinden alınabilen konum/aktivite verileri; her zaman kapsam/izin kontrolüyle).

Bu çeşitlilikte doğrulamanın ana stratejisi, tek bir kaynağı "hakikat" ilan etmek yerine, farklı kaynakların aynı zaman çizelgesini destekleyip desteklemediğini sınamaktır.

4.5. Uygulama odaklı inceleme: SQLite ve "silinmiş" verinin gölgesi

Mobil uygulamaların büyük bir kısmı veriyi SQLite tabanlı yapılarda tutar. İleri adli yorumda yalnız ana veritabanı dosyası değil, veritabanının yazma/işlem günlükleri ve ek dosyaları da önem kazanır. Neden önemli? Çünkü kullanıcı arayüzünde "silindi" görünen bir kayıt, depolama katmanında hemen yok olmayabilir; bu da "silme eylemi"nin kendisini kanıtlamak veya zaman çizelgesini güçlendirmek açısından değerli bir sinyal üretir.

Medya tarafında da EXIF gibi meta veriler; zaman/konum/cihaz bağlamı kurmada yardımcı olabilir. Yine de her meta veri, manipülasyona açık olabileceği için tek başına kesinlik taşımaz; başka izlerle tutarlılık aranır.

İpucu: Mobilde "bir kayıt buldum" çoğu zaman başlangıçtır. Kanıt ağırlığı, o kaydın zaman çizelgesindeki yeri, başka kaynaklarla tutarlılığı ve alternatif masum açıklamaların karşı kanıtla elenmesiyle oluşur.

4.6. Kurumsal mobil senaryolar: MDM ve BYOD'de adli sınır

Kurumsal mobil olaylarda teknik analiz, yönetişimle iç içedir:

• MDM (Mobile Device Management): cihaz envanteri, uyumluluk politikaları, uygulama listeleri ve yönetimsel aksiyon kayıtları; olayın kapsamını ve zaman çizelgesini destekleyebilir.

• BYOD (Bring Your Own Device): kişisel cihaz-kurumsal veri sınırı en baştan belirlenmelidir. Orantısız veri toplama hukuki/etik risk yaratır; bu risk raporun güvenilirliğini de etkiler.

Bu noktada yöntem seçimi "teknik olarak yapabiliyorum" üzerinden değil, "olay hedefi için gerekli ve yetkili kapsam nedir?" üzerinden yapılır. Kurumsal konteyner/iş profili yaklaşımı gibi sınırlandırılmış veri alanları, çoğu vakada daha savunulabilir bir çizgi sunar.

4.7. Mobil olay çıktıları: normalizasyon, belirsizlik ve adli dil

Mobil raporlar ham veri yığını değil; delil standardında özet üretmelidir:

• Farklı uygulamalardaki iletişim ve olayları tek bir kronolojik zaman çizelgesine oturtmak (normalizasyon),

• "Kesin" ile "yüksek olasılık" dilini ayırmak,

• Erişim sınırlarını, kilit durumunun etkisini ve hata paylarını açık yazmak.

Örnek: "Cihaz X konumundaydı" demek yerine, konum verisinin kaynağını ve belirsizliğini (GPS/baz istasyonu/uygulama kaydı gibi) belirterek, hangi korelasyonla bu sonuca varıldığını yazmak adli dili güçlendirir.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Linux’ta kimlik–kalıcılık–ağ davranışı üçlüsünü aynı zaman çizelgesinde birleştirerek daha sağlam doğrulama yapabilme
• macOS’ta Unified Logging, APFS snapshot/Time Machine, FSEvents ve Spotlight gibi kaynaklarla parçalı sinyali bütünleyebilme
• Bulutta yönetim düzlemi logları (CloudTrail/Activity Logs), IAM anomalileri ve UserAgent sinyallerini korele ederek log-first hikâye kurabilme; snapshot yaklaşımını doğru koşulda seçebilme
• Mobilde BFU/AFU ve edinim türlerini kapsam–risk–yetki dengesiyle gerekçelendirebilme; SQLite ekosisteminde “silme” izlerini adli dilde yorumlayabilme
• MDM/BYOD senaryolarında teknik analiz kadar kapsam, izin, mahremiyet ve rapor savunulabilirliğini birlikte yönetebilme

MODÜL 11 — Anti-Adli Teknikler ve Karşı Önlemler

Modül Teması

Bir olayda izlerin "az" olması, olayın "yok" olduğu anlamına gelmez. Gerçek hayatta saldırganlar çoğu zaman yalnızca erişim elde etmekle kalmaz; aynı zamanda incelemeyi zorlaştırmak için kayıtları azaltır, bozar veya yanlış yöne çeken izler üretir. Bu modülün odağı, anti-adli davranışları "nasıl yapılır?" düzeyinde tarif etmek değil; hangi sinyallerle şüphelenileceğini, bulguyu hangi karşı kanıtlarla doğrulayacağını ve sonucu denetlenebilir bir delil standardında rapora nasıl taşıyacağını öğretmektir. Bir yandan da kurum tarafında "kanıt zemini"ni güçlendiren mimari önlemlerle, olay anında tartışmayı uzatan belirsizlikleri azaltmayı hedefler.

1. Anti-adli davranış sınıfları ve tipik sinyaller

Anti-forensics (anti-adli davranış), en geniş anlamıyla olayın izini azaltma, bozma veya yanıltıcı iz üretme çabasıdır. Neden önemli? Çünkü IR kararlarını belirleyen "ne zaman başladı, hangi kapsamda etkiledi, hangi kimlikle gerçekleşti?" gibi sorular çoğu zaman kayıtların doğruluğuna dayanır. Bu zemin oynadığında analistin hedefi "kesin fail anlatısı" kurmak değil, kanıt ağırlığını doğru tartmaktır.

1.1. Log silme/temizleme ve log bütünlüğünü bozma

Bir logun "olmaması", tek başına anti-adli eylem kanıtı değildir. Log rotasyonu, kapasite baskısı, yanlış yapılandırma, merkezi toplanmama veya planlı bakım gibi masum açıklamalar da mümkündür. Bu yüzden doğrulama, tek kaynağa değil katmanlar arası tutarlılığa dayanır.

• Aynı zaman penceresinde farklı katmanlarda iz var mı?\Kimlik doğrulama servisleri, ağ akış kayıtları, EDR telemetrisi, uygulama logları gibi bağımsız kaynaklar aynı olayı başka bir yerden "hatırlıyor" olabilir.

• Boşluk tek bir kaynakta mı, yoksa birden fazla kaynağı eş zamanlı mı etkiliyor?\ Tek kaynağın susması "o kaynağın hedef alındığı" ihtimalini artırır; çoklu kaynağın susması ise "ortak bir operasyonel neden" ihtimalini güçlendirir.

Windows ekosisteminde bazı temizleme eylemleri, kendi başına bir denetim izi üretebilir. Örneğin Security log'un temizlenmesi, güvenlik kayıtlarında Event ID 1102 ("audit log cleared") gibi bir işaret bırakabilir.

Dikkat: "Log temizlendi" işareti değerli bir sinyaldir ama tek başına her şeyi açıklamaz. Temizleme eyleminin kendisi de sonradan başka eylemlerle gölgelenebilir; bu yüzden merkezi loglar ve harici telemetri ile çapraz doğrulama yapmak kritik hale gelir.

Örnek: Bir uç noktada belirli saat aralığında yerel olay kayıtları yoktur; aynı aralıkta kimlik servisinde oturum açma denemeleri ve ağ akışlarında kısa süreli dış bağlantı artışı devam ediyordur. Bu tablo "log hiç üretilmedi" açıklamasını zayıflatır, "yerel kayıt katmanının etkilenmiş olabileceği" hipotezini güçlendirir.

1.2. Zaman damgası manipülasyonu ve timeline bozulması (timestomping sinyalleri)

Zaman damgaları DFIR'in ortak dili gibidir: olay hikâyesini tek çizgide birleştirir. Bu nedenle zaman tutarsızlıkları hem saldırgan davranışının hem de operasyonel süreçlerin sonucu olabilir. İleri analizde aranan şey "tek bir doğru saat" değil, hangi saat kaynağına hangi koşulda güvenilebildiği ve hangi kaynağın "gözlem zamanı" taşıdığıdır.

Şüpheyi büyüten sinyaller:

• Aynı nesnenin farklı zaman alanlarında uyumsuzluk: dosya meta verisi, log zamanı, EDR gözlem zamanı, yedek/snapshot zamanı

• Sistem saatinin ileri/geri oynamış olabileceğine dair göstergeler:zaman senkronizasyon kayıtları, ani saat sıçramaları

• "İmkânsız sıralama": bir bileşenin, onu doğurduğu varsayılan olaydan önce görünmesi

NTFS gibi dosya sistemlerinde tek bir dosya için birden fazla zaman alanı (örneğin MFT özniteliklerinde $STANDARD_INFORMATION ve $FILE_NAME tarafında MAC zamanları) bulunabilir; bu alanların beklenmedik şekilde ayrışması manipülasyon şüphesini artırabilir. Ancak kopyalama, geri yükleme, senkron istemcileri ve bazı sistem davranışları da benzer izler üretebildiğinden, karşı kanıt (yedek kayıtları, dağıtım araçları, NTP olayları, EDR gözlemleri) aranır.

İpucu: Timeline tutarsızlığı yakaladığında refleks olarak "şu kesin manipülasyon" demek yerine, raporda güvenilir saat referansını ve belirsizlik aralığını açık yaz. Denetlenebilirlik, dakikadan çok gerekçeye dayanır.

Örnek: Bir dosyanın oluşturulma zamanı ile onu referanslayan uygulama kaydının zamanı çelişir. Bu, manipülasyon olabilir; ama aynı zamanda bir geri yükleme, dosya senkronizasyonu veya imajdan dönme etkisi de olabilir. Karşı kanıt arayışı, ilgili yedekleme/geri dönüş kayıtlarını ve zaman senkronizasyon verilerini kapsar.

1.3. Şifreleme ve erişimi engelleme (ransomware bağlamı dahil)

Şifreleme kimi zaman doğrudan saldırı etkisidir (erişimi keser), kimi zaman da delili kullanılmaz hale getirmenin aracıdır. Neden önemli? Çünkü şifreli alanlar analizi "veriye" değil, "davranışa" iter: kim şifreledi, ne zaman, hangi kimlikle, hangi kapsamda?

İleri seviyede ayrım için kritik sorular:

• Şifreleme hangi süreç/kimlik bağlamında gerçekleşti?

• Aynı zaman penceresinde yetki değişimi, log boşluğu, olağandışı ağ trafiği gibi eşlik eden sinyaller var mı?

• Bu davranış meşru bir kurumsal politika ile açıklanabilir mi? (ör. disk şifreleme zorunluluğu)\ Bu durumda kapsam, zamanlama ve değişiklik yönetimi kayıtlarıyla test edilir.

1.4. "Güvenli silme" iddiaları: shredding/wiping ve pratik izler

Güvenli silme iddiası, pratikte her zaman "hiç iz kalmaz" demek değildir. Depolama teknolojisi, dosya sistemi davranışı ve önbellek katmanları nedeniyle kalıntı kaynaklar oluşabilir. Yöntem seçimi burada belirleyicidir: bazı vakalarda dosyanın içeriğini aramak yerine, dosyaya ilişkin etkileşim izlerini (oluşturma/silme hareketi, yürütme artefaktı, indeks/önbellek, yedek/snapshot) aramak daha yüksek getirili olur.

Şüpheyi artıran sinyaller:

• Kısa zaman aralığında "oluştur-büyüt-sil" gibi dosya yaşam döngüsünün anormal görünmesi

• Bazı dosya kalıntılarında içerik yerine "boş/tekdüze" desenler (her zaman kesin değildir; bağlamla yorumlanır)

• Kullanıcının "hiç yoktu" dediği bir öğenin başka bir kopyada (yedek/snapshot) görülmesi

Dikkat: "İçerik kurtarılamıyor" tek başına "kesin güvenli silme yapıldı" anlamına gelmez. SSD/TRIM, depolama sanallaştırması ve dosya sistemi optimizasyonları da kurtarmayı zorlaştırabilir. Bu nedenle raporda neden-sonuç ilişkisini kesinleştirmeden, kanıt ağırlığıyla ilerlemek gerekir.

1.5. "Görünmezlik" iddiaları: rootkit ve telemetri kör noktaları

Rootkit gibi sınıflar çoğu zaman "görünmezlik" vaadi taşır. İleri DFIR'de pratik yaklaşım, "rootkit var mı?" sorusunu bir etiket gibi sormak yerine sistemin davranış sapmalarını ve katmanlar arası çelişkileri okumaktır:

• Beklenmeyen ağ bağlantıları, tutarsız envanter, telemetri kör noktaları

• Bir katmanda görülen öğenin başka katmanda kaybolması

• EDR/SIEM tarafında beklenmedik "sessizlik" pencereleri

Bu modülde amaç, görünmezlik tekniklerini "aşma" rehberi vermek değil; görünmezlik iddialarını kanıt standardında test edip raporda "ne biliyoruz / ne bilmiyoruz" ayrımını net tutmaktır.

2. Doğrulama ve tespit stratejileri: "yoklukla" çalışmak

Anti-adli şüpheyi "kanıt"a dönüştüren şey tek bir işaret değil; tutarlı bir sinyal kümesi ve bu sinyallerin masum açıklamalarını eleyen karşı kanıttır. Burada analistin zihniyeti "tek kanıt arama" değil, bağımsızlık ve tekrar üretilebilirlik üzerine kuruludur.

2.1. Boşluğu tanımlamak: Gap Analysis

İlk iş, boşluğun sınırını ve doğasını netleştirmektir:

• Boşluk hangi kaynaklarda var, hangilerinde yok?

• Boşluk aynı host'ta birden fazla log türünü etkiliyor mu?

• Aynı dönemde planlı bakım/yeniden başlatma/değişiklik var mı?

• Boşluk tekil mi, tekrarlı mı, periyodik mi?

Örnek: Üç yıldır düzenli toplanan kayıtlar içinde yalnızca olay gecesi iki saatlik boşluk varsa, bu durum "operasyonel hata" ihtimalini azaltır; ancak yine de değişiklik yönetimi ve kapasite/rotasyon verisiyle test edilmeden kesin hükme varılmaz.

2.2. "Harici hafıza": merkezi loglar ve çok katmanlı korelasyon

Anti-forensics çoğu zaman yerel düzeyi hedefler. Bu yüzden merkezi kaynaklar kritik hale gelir:

• Kimlik kayıtları (oturum açma, rol değişimi, başarısız denemeler)

• Ağ akışları ve güvenlik cihazı kayıtları

• SIEM'e akan loglar (alarm kanıt değildir; kanıta giden ipucudur)

• EDR telemetrisi (işlem/ağ/dosya olayları)

Windows tarafında log temizleme eylemlerini gösteren 1102 gibi işaretler, ancak merkezi kayıtlarla birlikte değerlendirildiğinde daha "savunulabilir" hale gelir.

İpucu: Yerel kayıt yoksa "olay yoktur" demek yerine şu soruyu sor: "Yerel kaydın susması, başka bir katmanda hangi izi büyütür?" Bu yaklaşım, yokluğu bir iddiaya değil bir hipoteze dönüştürür.

2.3. Timeline tutarsızlıklarını sistematik ele almak: saat kaynağı ve çözünürlük

Zaman çizelgesi bozuksa önce "hangi saatle konuştuğunu" netleştir:

• Referans saat: NTP senkronizasyon durumu, saat sıçraması pencereleri

• Kaynakların gecikme etkisi: telemetri toplama gecikmeleri, farklı zaman çözünürlükleri

• Rapor dili: "şu dakikada" yerine gerekirse "şu aralıkta" ve dayanak kaynak

ISO 27001 gibi çerçevelerde de saat senkronizasyonu doğrudan kontrol alanı olarak ele alınır; pratikte bu, olay korelasyonunu ve kanıt kalitesini güçlendiren bir temeldir.

2.4. Snapshot / shadow copy / yedeklerle çapraz doğrulama

Yerel izler silinmiş olsa bile snapshot ve yedek mekanizmaları olay penceresinin "başka bir kopyasını" tutuyor olabilir. Yöntem seçimi burada iki eksende yapılır:

• Hızın kritik olduğu olaylarda: önce merkezi telemetri, kimlik kayıtları ve ağ izleriyle karar desteği

• Kapsamın belirsiz veya anti-adli şüphenin güçlü olduğu olaylarda: snapshot/yedek üzerinden geçmiş durum doğrulaması

Örnek: Bir kullanıcı "bu dosya hiç yoktu" der, cihazda görünmez. Yedek/snapshot tarafında daha eski bir sürüm ve erişim izleri bulunursa, "hiç yoktu" iddiası zayıflar; olayın kapsamı daha net tariflenebilir.

2.5. Yürütme ve etkileşim izleri: "dosya yok"ken "davranış"ı yakalamak

Saldırganlar çoğu zaman ana dosyayı siler; ancak işletim sisteminin ve uygulamaların arka planda ürettiği yan artefaktların tümünü tutarlı biçimde "temizlemek" zordur. Bu nedenle Prefetch, Amcache, ShimCache benzeri yürütme/kurulum/çalıştırma izleri; dosya artık yokken bile "o dosya bir noktada vardı ve kullanıldı" hipotezini destekleyen parçalar sağlayabilir.

Dikkat: Bu artefaktlar tek başına fail göstermez. En değerli kullanım biçimi, başka bağımsız sinyallerle (kimlik kaydı, ağ akışı, EDR gözlemi, yedek/snapshot) bir araya gelerek "tutarlılık" üretmesidir.

3. Kalıntı veri kaynakları: izler silinse de kalan "kırıntılar"

Anti-forensics izleri tamamen yok etmeyi hedeflese bile sistemler çoğu zaman kırıntı bırakır. Buradaki amaç "tek sihirli kaynak" aramak değil; farklı kalıntı kaynaklarını kanıt ağırlığına göre kullanmaktır.

3.1. Pagefile/hiber: uçucu olmayan bellek kalıntıları

Belleğe yakın çalışan bazı alanlar (sayfalama ve hazırda bekletme gibi) olayın belirli parçalarına dair izler taşıyabilir. Neden önemli? Çünkü bir dosya silinse bile, o dosyayla etkileşim sırasında bellekten disk tabanlı alanlara taşınmış parçalar kalabilir. Bu tür kaynaklar genellikle "doğrudan dosya" değil, "davranışın kırıntısı" üzerinden değer üretir.

3.2. Önbellekler, indeksler ve uygulama kalıntıları

Tarayıcı önbelleği, arama indeksleri, uygulama geçici dosyaları veya senkron istemcilerinin yerel kayıtları; doğrudan "zararlı dosya" değil ama "dosya ile etkileşim" kanıtı üretebilir.

Örnek: Bir kullanıcı belirli bir eklentiyi hiç çalıştırmadığını söyler. Doğrudan çalıştırma kaydı bulunmaz; ancak uygulama önbelleğinde o eklentinin yüklenme izleri ve aynı zaman aralığında ağ akışlarında ilgili hizmete bağlantı görülür. İki bağımsız iz, iddianın yeniden değerlendirilmesini sağlar.

3.3. Registry yedekleri ve transaction log'lar

Registry kovanları veritabanı mantığıyla çalışır. Ana kovan temizlenmiş olsa bile işlem günlükleri (transaction logs) bazen geri dönülebilir izler barındırır. Bu, özellikle kalıcılık veya yapılandırma değişikliğinin "tam silindiği" iddialarında değerli olabilir.

3.4. NTFS Journal, $MFT kırıntıları, slack ve unallocated alanlar

Dosya sistemi günlükleri (ör. USN Journal) dosya oluşturma/silme/yeniden adlandırma gibi hareketleri içerik yokken bile "hareket izi" olarak bırakabilir. Benzer şekilde MFT kaydının kendisinde, dosyanın sonundaki slack alanlarda veya unallocated bölgelerde metadata kırıntıları kalabilir.

Dikkat: Kalıntı kaynaklar sıkça "yarım iz" taşır. Yarım iz, yanlış yorumlanırsa yanlış pozitif üretir. Bu yüzden kalıntıyı mutlaka başka bir bağımsız sinyalle eşleştir.

4. Kurumsal karşı önlemler: kanıt zemini inşa etmek

Anti-forensics'i analizle yakalamak kadar, olay anında kanıt üretimini kolaylaştıracak bir kurumsal zemin kurmak da önemlidir. Bu bölüm, teknik bulguyu operasyonel karara bağlayan savunma uygulamalarına odaklanır.

4.1. Immutable logging ve bütünlük güvencesi (WORM dahil)

Değiştirilemeyen veya bütünlüğü doğrulanabilir log arşivleri, "log silindi mi?" tartışmasını dramatik biçimde azaltır. Neden önemli? Çünkü IR'de tartışma uzadıkça containment gecikebilir. WORM benzeri yaklaşımlar, logların yetkili hesaplar tarafından bile geriye dönük oynanmasını zorlaştırarak denetlenebilirliği artırır.

4.2. Log forwarder ve saklama politikaları

Yerel kayıtlar kaybolduğunda merkezi telemetri "ikinci kopya" rolü görür. Ancak bu yalnızca toplamakla olmaz:

• Saklama süresi (retention) ihtiyaca göre belirlenmeli

• Erişim kontrolü ve değişiklik yetkileri sıkı yönetilmeli

• Olay anında kanıtı bozacak "üzerinde oynama" refleksi engellenmeli

4.3. EDR telemetri saklama ve kör nokta analizi

EDR tek başına kanıt değildir; fakat olay zincirinin kritik halkalarını bağlayabilir. İleri seviye yaklaşım, EDR'nin kör noktalarını bilerek raporda sınırları açık yazmaktır:

• Kapsanmayan sistemler

• Yoğunluk nedeniyle düşen olaylar

• Toplama gecikmeleri

4.4. NTP standardizasyonu ve güvenilir saat

Zaman senkronizasyonu yalnız "düzen" değil, doğrudan kanıt kalitesi meselesidir. Çok kaynaklı korelasyonun anlamlı olabilmesi için saat kaynakları tutarlı olmalıdır. Kurum çapında standardizasyon, timeline üretiminde belirsizliği azaltır.

İpucu: Karşı önlemleri "uyguladık bitti" diye değil, "hangi olay tipinde hangi kanıtı güçlendiriyor?" diye düşün. Immutable logging log silme tartışmasını; zaman standardı timeline tartışmasını; telemetri saklama ise "geç fark ettik" krizini azaltır.

5. Uygulamalı senaryo: "silinmiş izlerden" olay hikâyesi kurmak

Bu bölümün amacı, "kanıt yok" gibi görünen bir olayda bile kırıntılardan tutarlı bir hikâye kurmanın mantığını oturtmaktır. Burada yöntem seçimi kritiktir: her kırıntının kanıt değeri aynı değildir; bazıları yalnız ipucu üretir.

Örnek: Bir sunucuda 02:00-04:00 aralığında yerel olay kayıtlarının eksik olduğu görülür. Aynı gece sistemde kısa süreli bir dış bağlantı artışı yaşanmıştır. Şüpheli olduğu düşünülen "backup_helper.exe" adlı bir ikili daha sonra diskte bulunamaz.

Analiz, "kesin hüküm" yerine hipotezleri sınayan bir çizgide ilerler:

1. 1.Boşluğu tanımlama: Eksik aralık hangi log türlerinde var, başka benzer sistemlerde de var mı? Aynı saatlerde planlı bakım veya otomasyon işi var mı?

1. 2.Bağımsız katmanlarla doğrulama: Kimlik kayıtlarında olağandışı oturum açma denemesi, ağ akışlarında dış bağlantı yoğunluğu ve EDR telemetrisinde kısa süreli "görünürlük düşüşü" aynı pencereye denk geliyor mu?

1. 3.Dosya "yokken" davranışı arama: Dosya sistemi günlükleri dosyanın varlığına/silinmesine dair hareket izi bırakmış mı? Yürütme/etkileşim artefaktları "bu öğe bir noktada çalıştı" hipotezini destekliyor mu?

1. 4.Geçmiş durum doğrulaması: Snapshot/yedek tarafı aynı zaman penceresinin alternatif kopyasını sunuyor mu?

1. 5.Rapor paketleme: Gözlemler ve yorumlar ayrılır; zaman çizelgesi ortak saat referansına oturtulur; belirsizlik aralıkları açık yazılır; kullanılan kaynaklar ve sınırlılıklar yeniden üretilebilir şekilde listelenir.

Rapor dili, özellikle anti-adli şüphe olan olaylarda "kesin fail anlatısı" yerine, kanıt ağırlığı yüksek halkaları öne çıkaran ve belirsizliği yöneten bir yaklaşımı korur.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• “İz yoksa olay yoktur” yanılgısını kırarak, yokluğu hipotez olarak ele alma ve karşı kanıt arama refleksi kazandınız.
• Log boşlukları, timeline tutarsızlıkları ve “dosya yok” senaryolarında tek kaynağa değil çoklu katmana dayalı doğrulama yaklaşımını oturttunuz.
• Kalıntı veri kaynaklarını tek başına kesin hüküm üretmeden, kanıt ağırlığı ve yanlış pozitif yönetimiyle kullanmayı öğrendiniz.
• Raporlamada gözlem–yorum ayrımı, belirsizlik aralığı, zaman çizelgesi tutarlılığı ve yeniden üretilebilirlik standardını nasıl koruyacağınızı pekiştirdiniz.
• Kurumsal düzeyde immutable logging/WORM, log forwarder, telemetri saklama ve saat senkronizasyonu gibi önlemleri “kanıt kalitesi” perspektifiyle IR kararlarına bağladınız.

MODÜL 12 — Olay Sonrası İyileştirme, Raporlama ve Hukuki Süreçler

Modül Teması

Bir olay "kontrol altına alındığında" iş bitmez; gerçek kazanım, aynı olayın bir daha yaşanmamasını sağlayacak iyileştirmelerin yapılması ve elde edilen bulguların denetlenebilir bir kanıt setine dönüştürülmesidir. Bu modül; recovery/hardening kararlarını teknik bulgularla gerekçelendirmeyi, lessons learned çıktılarının ölçülebilir hale getirilmesini, raporlamanın "savunulabilir dosya" standardında kurgulanmasını ve hukuki/regülasyon farkındalığının iletişim yönetimiyle birlikte yürütülmesini ele alır. NIST'in olay müdahalesi yaklaşımı da, müdahalenin yalnız containment/eradication ile bitmediğini; olay sonrası faaliyetlerin (post-incident) kurumsal olgunluğu belirlediğini vurgular.

1. Recovery ve Hardening

Toparlanma, sistemi yeniden ayağa kaldırmak değil; yeniden güvenilir hale getirmektir. Neden önemli? Çünkü acele toparlanma "geri dönüş" riskini büyütür; aşırı sert müdahale ise iş sürekliliğini gereksiz zedeler.

1.1. Yöntemi seçmek: restore mu, rebuild mi, hedefli temizlik mi?

Aynı olayda farklı varlıklar için farklı yöntemler savunulabilir olabilir. Karar, şu üç eksende netleşir:

• Kanıt gücü / güven düzeyi: İhlalin kapsamını "tahmin" mi ediyorsunuz, yoksa bağımsız kaynaklarla (kimlik + uç nokta + ağ + uygulama) tutarlı biçimde doğruladınız mı?

• Etki alanı: Tek bir sunucuda mı sınırlı, yoksa kimlik altyapısı/ayrıcalıklı hesaplar gibi "yataya yayılma" ihtimali yüksek bir zemine mi dokunuyor?

• Zaman penceresi: Olayın başlangıcı (patient zero) ve olay penceresi güvenle kurulabiliyor mu? Kurulamıyorsa "hangi yedeğe dönülecek" sorusu teknik değil, kanıt sorusuna dönüşür.

Hedefli temizlik (targeted remediation) kesintiyi azaltabilir; ancak kapsam yanlış çizilirse kalıcılık olasılığı artar. Rebuild (temiz imajdan yeniden kurulum) "temiz sayfa" avantajı sağlar; fakat iyi bir baseline/golden image yoksa eski yanlış yapılandırmalar geri gelir. Restore (yedekten dönüş) hızlıdır; fakat dönülen noktanın "temiz olduğuna dair" bağımsız kanıt yoksa risk taşır.

Dikkat: "Admin/root düzeyi yetkisiz erişim şüphesi" olan bir sistemde yalnızca temizlik yaklaşımına güvenmek, görünmeyen kalıcılık riskini artırır. Bu noktada karar, rahatlığa değil; kanıtın gücüne dayanmalıdır.

Örnek: Bir dosya sunucusunda olağandışı erişim artışı görülür. Uygulama logları belirli bir aralıkta tutarsızdır; ağ akışları erişim artışını doğrular. Bu durumda "son yedeğe dönelim" refleksi yerine önce iki karşı kanıt aranır: (i) yedek tarihinden sonra benzer erişim izleri başka sistemlerde var mı, (ii) aynı zaman penceresinde kimlik olaylarında anomali var mı. Yalnız tek sunucu etkilenmiş görünüyorsa restore savunulabilir; kimlik altyapısına uzanan sinyal varsa rebuild + daha geniş erişim sıfırlama kapsamı gündeme gelir.

1.2. Kök neden kapatılmadan üretime dönmeme: "re-infection" gerçeği

Toparlanma adımının en kritik doğrulaması, kök nedenin gerçekten kapatılıp kapatılmadığıdır. Neden önemli? Çünkü saldırganın "girdiği kapı" kapanmadıysa, içeriyi toparlamak sadece tekrar aynı döngüyü başlatır.

• Kök neden bir zafiyet/yama eksikliği ise: düzeltme planının "tek sistem" değil "aynı sınıfta tüm sistemler" için uygulandığına dair kanıt aranır.

• Kök neden yanlış yapılandırma ise: konfigürasyon standardının güncellenip yaygınlaştırıldığı doğrulanır.

• Kök neden kimlik/ayrıcalık zafiyeti ise: sadece parola değişimi değil, oturum/token yaşam döngüsü ve ayrıcalık sınırlarının da ele alındığı gösterilir.

İpucu: Kök neden kapatma maddelerini "yapıldı" diye değil, hangi kanıtla doğruladığınızı yazarak rapora bağlayın: değişiklik kaydı, denetim izi, kapsam listesi, kontrol sonucu.

1.3. Kimlik ve erişim iyileştirmeleri: geniş reset mi, hedefli reset mi?

"Hesapları değiştirdik" ifadesi tek başına güven üretmez. İleri seviye yaklaşım, hesabı değil erişim bağlamını merkez alır: hangi roller, hangi servis/entegrasyon hesapları, hangi token/oturum türleri, hangi yetkilendirme yolları etkilenmiş olabilir?

Yöntem seçimi çoğu zaman iki uç arasında dengedir:

• Geniş reset: Güveni artırır, operasyonel maliyeti yükseltir.

• Hedefli reset: Maliyeti düşürür, kaçak bırakma riski taşır.

Doğrulama için aranan karşı kanıtlar:

• Kimlik olaylarında olağandışı oturum açma örüntüsü, rol/izin

değişimleri, "imkânsız seyahat" benzeri sinyallerin zaman çizelgesiyle uyumu,

• Uç nokta ve ağ telemetrisinde kimlik olaylarıyla eş zamanlı anomalilerin korelasyonu,

• Kritik hesapların "beklenen kullanım modeli" ile olay penceresindeki kullanımın kıyaslanması.

Active Directory ortamlarında, belirli senaryolarda Kerberos biletlerinin geçersizleşmesi ve anahtar geçmişi nedeniyle krbtgt gibi kritik hesaplarda iki aşamalı parola rotasyonu gerekebilir; bu tür adımlar üretici rehberleriyle ve kurumsal değişiklik yönetimiyle yürütülür.

Dikkat: "Geniş reset" kararı teknik olarak doğru olsa bile, kapsam belirsiz bırakılırsa denetimde zayıf düşer. Hangi hesapların neden dahil edildiği ve hangilerinin neden hariç bırakıldığı yazılmadığında risk artar.

1.4. Hardening: yamadan izlemeye, segmentasyondan standarda

Hardening'i "kilidi değiştirmek" gibi düşünmek kolaydır; oysa bir olay yaşandıysa, mahallenin zayıf noktaları da masaya gelmiştir. Tipik dönüşüm çizgileri:

• Zafiyet/yanlış konfigürasyon bulgusu → yama/konfig düzeltme + yaygınlaştırma planı

• Yatay hareket sinyali → segmentasyon + erişim politikalarının daraltılması

• Geç tespit bulgusu → telemetri kapsamı/retention + yeni SIEM use-case'leri

Örnek: Olay penceresinde birden fazla sunucuda kısa süreli oturum denemeleri görülür. Kalıcılık kanıtı yoktur; ancak segmentasyon zayıftır. Burada hedef "tüm sunucuları kapatmak" değil; kritik segmentlerde erişim yollarını daraltmak, ayrıcalıkları azaltmak ve sonraki benzer denemeleri daha erken görecek izleme iyileştirmelerini devreye almaktır.

1.5. Recovery doğrulaması: "servis açıldı" değil, "güvenilir çalışıyor"

Toparlanma sonrası doğrulama, servislerin ayağa kalkmasından ibaret değildir. Neden önemli? Çünkü saldırganın geri dönüşü çoğu zaman "her şey normale döndü" sanılan dönemde olur.

İleri seviye doğrulama seti:

• Baseline kıyası: Envanter, kritik servis seti, beklenen konfigürasyon, beklenen yetkilendirme yolları.

• Telemetri sürekliliği: Log akışı, EDR kapsaması, zaman senkronizasyonu (NTP) ve veri kaybı pencereleri.

• Anomali izlemi: Olayla ilişkili IoC/TTP sinyallerinin tekrar görülüp görülmediği.

Bu aşamada "sanity check" yaklaşımı faydalıdır: güvenlik sertleştirmeleri meşru iş süreçlerini bozmuş olabilir; doğrulama hem güvenliği hem iş sürekliliğini birlikte sınar.

İpucu: Recovery doğrulamasını rapora kontrol listesi gibi gömmek yerine, her kontrolün kapattığı riski bir cümleyle yazın. Bu, "neden buna zaman harcadık?" sorusunu peşinen cevaplar.

2. Lessons Learned ve Süreç Güncelleme

Lessons learned bir toplantı değil; kurumsal hafızayı güncelleyen bir üretim hattıdır. Olay sonrası faaliyetler ve ders çıkarma pratikleri, NIST'in incident handling yaklaşımında da "olgunluk artırıcı" bir kapatıcı adım olarak ele alınır.

2.1. Suçlu aramak yerine kör noktayı bulmak

"Kim hata yaptı?" sorusu, kısa vadede rahatlatıcı görünür; uzun vadede ise kanıt paylaşımını ve şeffaflığı azaltır. İleri seviye hedef, iddiaları veriyle sınamaktır:

• "Alarm yoktu" iddiası → SIEM ingest durumu + kural kapsamı + ham olayların o pencerede gelip gelmediği

• "EDR görmedi" iddiası → kapsama + telemetri kaybı penceresi + ajan sağlığı

• "Yedek temizdi" iddiası → restore noktası seçiminin dayanakları + timeline ile tutarlılık

Örnek: Bir vardiya devrinde olay "false positive" sanılarak eskale edilmez. Sonradan aynı zaman penceresinde başka bir sistemde benzer sinyaller görülür. Burada hedef "vardiya personeli hatalı" demek değil; devrin hangi bilgiyle yapıldığı, eskalasyon eşiğinin nasıl tanımlandığı ve "benzer sinyal aileleri" için korelasyonun neden kurulamadığını ortaya çıkarmaktır.

2.2. Gap analysis: insan-süreç-teknoloji ayrımı

Aynı semptomun kökü farklı olabilir. "Geç tespit" örneğinde:

• Teknoloji: eksik telemetry retention, eksik log kaynağı, zayıf korelasyon

• Süreç: eskalasyon gecikmesi, playbook belirsizliği, yetki/rol çatışması

• İnsan: vardiya devri zayıflığı, eğitim eksikliği, karar sorumluluğu belirsizliği

Yöntem seçimi burada "her şeyi aynı anda düzeltelim" yerine, en yüksek risk azaltımını en düşük maliyetle sağlayacak sıralamayı kurmaktır.

2.3. Playbook ve use-case güncelleme: ölçülebilir çıktı üretmek

Olay sırasında doğaçlama yapılan her başarılı hamle, yazılı prosedüre dönüşmediği sürece kişiye bağımlı kalır. Somut çıktılar:

• Güncellenmiş playbook (özellikle karar noktaları ve eskalasyon)

• Yeni/iyileştirilmiş SIEM use-case'leri

• Telemetri kapsamı ve saklama (retention) iyileştirmeleri

• Tabletop exercise planı ve hedef metrikler

İpucu: İyileştirme maddelerini "yapılacak iş" olarak değil, başarı ölçütü ile yazın: "X anomalisinde Y dakika içinde uyarı üretilecek; Z gün geriye dönük arama yapılabilecek." Böylece doğrulama mümkün olur.

3. Raporlama Standardı

İyi rapor, bir dosya gibidir: okuyan kişi olayı yeniden kurabilmeli, hangi sonucun hangi kanıta dayandığını görebilmeli ve belirsizliği yönetebilmelidir.

3.1. Katmanlı rapor yapısı: yönetici özeti + teknik ek + delil paketi

• Yönetici özeti: Etki, kapsam, alınan kararlar, risk durumu, öncelikli öneriler (teknik ayrıntı minimum).

• Teknik rapor: Timeline, korelasyon, doğrulama adımları, sınırlılıklar, alternatif yöntemler ve neden seçilmedikleri.

• Delil paketi: Artefaktlar, bütünlük kontrolleri, erişim kayıtları, kaynak envanteri.

Bu katmanlama, teknik bulgunun nasıl operasyonel karara dönüştüğünü görünür kılar: containment/eradication/recovery gerekçeleri, risk-maliyet dengesi ve karar günlüğü.

3.2. Olgu-yorum ayrımı ve güven düzeyi

Rapor kalitesi "kesin konuşmakla" değil, kanıt ağırlığını doğru tartmakla yükselir.

• Olgu: Kaynak + zaman + gözlem (denetlenebilir).

• Doğrulama: Bağımsız kaynaklarla tutarlılık/çelişki arama.

• Yorum: Hangi hipotezi güçlendirdiği; hangi masum açıklamaların elenmediği.

Örnek: "Veri sızdı" demek yerine; "Uygulama hesabında yetkisiz işlem şüphesi doğrulandı; kapsam analizi sürüyor. Ağ telemetrisinde 203.0.113.0/24 aralığına doğru olağandışı çıkış artışı gözlendi; ancak bunun veri aktarımı olup olmadığı için ek doğrulama planlandı." demek, belirsizliği yönetirken güveni korur.

Dikkat: "Alarm üretildi" ifadesi kanıt değildir. Alarmın dayandığı ham olaylar, korelasyon mantığı ve bağımsız doğrulama gösterilmezse rapor denetimde ilk sarsılan parça olur.

3.3. Timeline ve IoC seti: tekrar kullanılabilir paket

Timeline ve IoC listesi, yalnız tablo değildir; sonraki avcılık ve izleme için "yeniden kullanılabilir yakıt"tır.

Yöntem seçimi iki kritik kararda görünür:

• IoC kapsamı: Çok geniş → yanlış pozitif; çok dar → kaçak risk.

• Bağlam: IoC hangi sistemde, hangi zaman penceresinde, hangi davranışla ilişkili?

Delil paketinde tipik olarak beklenenler:

• Kaynak envanteri (hangi log/telemetri/imaj)

• Bütünlük kayıtları (hash/dijital imza) ve bunların nasıl saklandığı

• Erişim kayıtları (kim, ne zaman, hangi amaçla erişti)

• Zaman standardı notu (timezone/NTP etkisi)

• Sınırlılıklar ve kör noktalar

NIST, dijital delillerin kolay değiştirilebilir olması nedeniyle bütünlük ve zincir yönetiminin kritik olduğunu; hashlerin güvenli algoritmalarla üretilip delilden ayrı güvenli yerde saklanmasının iyi uygulama olduğunu vurgular.

3.4. Redaksiyon ve paylaşım sınırları

Rapor teknik doğruluğu korurken gereksiz ifşayı engellemelidir: kişisel veriler, erişim anahtarları, iç mimari ayrıntılar "need-to-know" ilkesiyle ele alınır. Bu yaklaşım hem hukuki riski hem de ikinci saldırı riskini azaltır.

4. Hukuki/Regülasyon Çerçevesi

Bu bölüm hukuki danışmanlık değildir; teknik ekibin delilin değerini düşürecek adımlardan kaçınmasını sağlayan bir farkındalık çerçevesidir.

4.1. Chain of custody ve bütünlük: teknik disiplinin hukuki ağırlığı

Delilin kimde olduğu, nasıl taşındığı, ne zaman erişildiği; mahkemede bulgunun tartışılmasında belirleyici olabilir. Zincir yönetimi, delili toplamak kadar belgeleme disiplinini de standardize etmeyi gerektirir. Dijital delilde bütünlüğün korunması ve hashlerin güvenli biçimde saklanması, NIST'in delil koruma önerileri arasında temel başlıklardandır.

4.2. Veri minimizasyonu: "her şeyi topla" refleksini kontrol etmek

Olay sırasında "her şeyi topla" yaklaşımı kişisel veri riskini büyütebilir. Buradaki yöntem seçimi, inceleme için yeterli veriyi toplarken gereksiz kişisel veri toplamaktan kaçınma dengesidir. Erişim, paylaşım ve saklama kararları hukuk/uyum ekipleriyle birlikte yürütülmelidir.

4.3. Bildirim mantığı: doğrulanmış bilgi ile olasılığı ayırmak

Regülasyonlarda bildirim süreleri ve eşikler yargı alanına göre değişebilir; GDPR bağlamında kişisel veri ihlallerinin belirli koşullarda "gereksiz gecikme olmaksızın" ve mümkünse 72 saat içinde bildirilmesi gerektiği hükmü vardır.\ Teknik ekibin kritik katkısı, "kesinleşmiş ihlal" ile "şüpheli olay" ayrımını net tutmak; kanıt-olasılık çizgisini raporda ve iletişimde doğru kurmaktır.

4.4. Saklama (retention) ve "litigation hold" refleksi

Hukuki süreç ihtimali doğduğunda bazı veri setleri normalde silinecek olsa bile saklama dondurulabilir. Teknik karşılığı; log retention, e-posta/mesajlaşma arşivleri, erişim kayıtları gibi kaynakların korunmasıdır.

Dikkat: Kanıtı koruma motivasyonuyla "daha fazla müdahale"ye kaymak sistemi daha çok değiştirebilir. Müdahale-koruma dengesi, IR liderliği ve hukuk/uyum ekipleriyle birlikte kurulmalıdır.

5. İletişim Yönetimi

İletişim, olay müdahalesinin gölgesinde kalan bir iş değil; doğrudan risk azaltım aracıdır. Yanlış iletişim, yanlış teknik karar kadar maliyetli olabilir.

5.1. Paydaş haritası ve tek doğruluk kaynağı

İç paydaşlar (SOC, IT, ürün, hukuk/uyum, üst yönetim) ile dış paydaşlar (müşteri, iş ortağı, regülatör, medya) aynı derinlikte bilgi almaz; fakat tüm iletişim tek bir doğruluk kaynağına dayanmalıdır: güncel durum raporu + karar günlüğü + doğrulama planı.

Ayrıca "tek seslilik" prensibi önemlidir: teknik ekip bulgularını doğrudan dışarı taşımak yerine, olay yöneticisi (incident commander) üzerinden koordine eder; böylece bilgi kirliliği ve çelişki riski azalır.

5.2. Belirsizliği doğru çerçevelemek

İyi iletişim belirsizliği saklamaz; doğru sınıflandırır:

• Kesin olanlar: doğrulanmış gözlemler

• Muhtemel olanlar: güçlü korelasyonla desteklenen çıkarımlar

• Açık sorular: doğrulanmamış hipotezler ve planlanan doğrulama adımları

Örnek: Bir uygulama hesabında yetkisiz işlem şüphesi doğrulanır. Dış paydaşa "veri sızdı" demek yerine, "yetkisiz işlem tespit edildi, kapsam analizi sürüyor; etkilenen kullanıcı aralığını netleştirmek için şu doğrulama adımları yürütülüyor" demek, hem dürüst hem yönetilebilir risk sunar.

5.3. Hız-doğruluk dengesi: mesajı katmanlandırmak

Çok hızlı açıklama yanlış bilgi riski taşır; çok geç açıklama güven kaybı yaratır. Denge, mesajı katmanlandırarak kurulur:

• Kısa ve doğrulanmış durum güncellemeleri

• Söz verilen periyotta düzenli iletişim

• Teknik ayrıntıyı eklerde tutmak, ana mesajı sade tutmak

İpucu: İletişim metinleri için dört soru checklist'i hazırlayın: "Ne biliyoruz? Ne bilmiyoruz? Ne zaman bileceğiz? Kullanıcı ne yapmalı?" Bu yapı panik iletişimini azaltır ve teknik ekibin doğrulama disiplinini güçlendirir.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Recovery yaklaşımını kanıt gücü–risk–iş etkisi dengesiyle seçmeyi; tek reçeteden kaçınmayı.
• “Kök neden kapanmadan üretime dönüş” riskini yönetmeyi ve re-infection döngüsünü kırmayı.
• Kimlik ve erişim iyileştirmelerinde kapsamı kanıtla gerekçelendirmeyi; geniş reset–hedefli reset dengesini kurmayı.
• Lessons learned’i kör nokta kapatmaya ve ölçülebilir çıktılara dönüştürmeyi; playbook/use-case güncellemelerini doğrulanabilir hedeflerle yazmayı.
• Raporu katmanlandırarak denetlenebilir, yeniden üretilebilir ve belirsizliği doğru yöneten bir yapıda sunmayı.
• Chain of custody, bütünlük, veri minimizasyonu ve saklama/bildirim farkındalığıyla hukuki riskleri teknik doğruluk üzerinden yönetmeyi.
• İç/dış paydaş iletişiminde tek doğruluk kaynağı ve hız–doğruluk dengesini kurarak yanlış bilgi riskini azaltmayı.

MODÜL 13 — Bütünleşik Olay Senaryosu ve Uygulamalı Değerlendirme

Modül Teması

Bu final modülü, DFIR'de "tek tek doğru işler" ile "uçtan uca savunulabilir bir hikâye" arasındaki farkı sahaya indirir. Tek bir alarmdan yola çıkıp; kanıtı bozmadan ilerleyerek hipotez kurma-doğrulama döngüsüyle olayın ne olduğunu ortaya koymanız, containment/eradication/recovery kararlarını iş etkisi ve kanıt standardıyla gerekçelendirmeniz ve sonunda denetlenebilir bir rapor + delil paketi üretmeniz beklenir. Buradaki hedef, sadece teknik doğruyu bulmak değil; doğruyu, ekipçe savunulabilir bir karar dosyasına dönüştürmektir.

1. Senaryo kurulumu: Kaosu tanımlamadan düzene geçilmez

Olay müdahalesinde ilk saatlerin kalitesi, "neye bakacağınızı" değil, "neye bakmayacağınızı" doğru seçmenizle artar. Bu bölümde sahneyi kurarsınız: Neyi koruyoruz? Hangi sinyalle uyandık? Elimizde hangi veri var, hangi veri yok? Nerede durup nerede ilerleyeceğiz?

1.1. Kurgusal altyapı, envanter ve kör noktalar

Senaryo, günlük hayatla temas eden bir kurum tipinde (ör. kurgusal bir lojistik/dağıtım firması) geçer. Tipik bileşenler:

• DMZ'de dışa açık bir web sunucusu

• İç ağda bir kimlik sunucusu (ör. AD/DC), dosya sunucusu ve çok sayıda istemci

• Log tutma gerçekliği: bazı kaynaklar kısa süre saklanır (örn. yerel event log'larda düşük retention), bazıları daha uzun (örn. ağ cihazlarında 30 gün). Merkezi SIEM/EDR bulunmayabilir; bu, analistin "yöntem" becerisini sınar.

Envanter burada "liste" değil, karar mekanizmasıdır: aynı bulgu kritik kimlik altyapısında görülünce bir anlam taşır; test ortamında başka bir anlam.

Örnek: Aynı kullanıcı hesabı için olağandışı oturum açma sinyali, kimlik sunucusuna yakın sistemlerde görülüyorsa yayılım riski artar; tek bir izole istemcide görülüyorsa önce kapsamı daraltıp doğrulamaya ağırlık verirsiniz.

Dikkat: Envanter ve kör noktalar netleşmeden "kesin hüküm" kurmak, hem yanlış containment'e hem de kanıt kaybına davetiye çıkarır. "Hangi veri yok ve bu yokluk hangi belirsizliği doğuruyor?" sorusu, raporun kalite çıpasıdır.

1.2. Başlangıç göstergeleri: İpucu mu, kanıt mı?

Başlangıç sinyali çoğu zaman ipucudur; kanıt değildir. İleri seviye yaklaşım, ipucunu "doğrulama planı"na çevirmektir.

Örnek: Pazar 04:15'te nöbetçi yönetici "bir sunucunun diski doldu, CPU %100, servisi yeniden başlatmak istedim ama erişim engellendi" der. Bu, performans sorunu da olabilir; güvenlik olayı da. Buradaki kritik karar: hemen yeniden başlatmak mı, yoksa önce uçucu delili koruyup triage yapmak mı?

1.3. Veri kaynakları ve erişim sınırları

Değerlendirilebilir bir senaryo, veri kaynaklarını ve sınırlarını baştan görünür kılar:

• Kimlik kayıtları (SSO/MFA/oturum açma olayları)

• Uç nokta telemetrisi (varsa EDR; yoksa yerel artefaktlar)

• Ağ verisi (flow; varsa PCAP, yoksa sınırlılık notlarıyla)

• Uygulama/sistem logları

• Yedek/snapshot kayıtları (varsa)

• Karar günlüğü ve olay yönetimi notları (eskalasyon, rol atamaları, zaman damgaları)

Örnek: Merkezi log yoksa, "kanıt yok" demek kolaydır. İleri seviye refleks: "Bu eksik, şu hipotezi zayıflatıyor; belirsizliği azaltmak için şu bağımsız kaynağa başvurdum" diye yazmaktır.

1.4. Çıktılar ve rol paylaşımı: Analiz daha başlamadan kaliteyi kilitlemek

Bu modülde üretilecek çıktılar senaryonun başında bellidir:

• IoC seti (bağlam + güven düzeyiyle)

• Super-timeline (çoklu kaynaktan birleşik zaman çizelgesi)

• Kök neden hipotezi (alternatifleri ve karşı kanıtlarıyla)

• Karar günlüğü (containment/eradication/recovery)

• Rapor (yönetici + teknik katman) ve delil paketi

İpucu: Rol tanımını "aracı kullanan kişi" diye değil, "kanıt standardının bir parçasını koruyan kişi" diye yapın. Bir kişi zaman çizelgesi tutarlılığı (timezone/NTP uyumu), bir kişi delil envanteri ve bütünlük, bir kişi korelasyon/pivot kalitesi gibi sorumluluklar alır.

2. Uçtan uca analiz ve müdahale: Hipotez kur, karşı kanıt ara, sonra konuş

Bu bölümde amaç, tek bir "doğru anlatı" yazmak değil; hipotezleri kanıt ağırlığına göre sıralayıp doğrulamaktır. Aynı veriden farklı yorumlar çıkabilir; ileri seviye kalite, seçtiğiniz yorumu neden seçtiğinizi ve diğer olasılıkları hangi karşı kanıtla zayıflattığınızı gösterebilmenizde yatar.

2.1. Hipotez → doğrulama döngüsü ve "assertion" disiplini

Raporda geçen her güçlü cümle bir assertion (kanıt gerektiren iddia) sayılmalıdır. "Olmuş olabilir" ile "oldu" arasında, kanıt standardı kadar fark vardır.

Örnek: SIEM (ya da kimlik sistemi) "imkânsız seyahat" sinyali üretir ve aynı kullanıcı adına kısa aralıklarla başarısız girişler görünür. İlk refleks "hesap ele geçirildi" demek değil; masum açıklamaları sınayacak karşı kanıt aramaktır: planlı bakım, VPN çıkış değişikliği, MFA onay kayıtları, aynı zaman penceresinde uç noktada süreç/ağ sinyali olup olmaması. (Logon türleri ve uzaktan oturum davranışlarını okurken "RemoteInteractive / logon type 10" gibi ayrımlar kritik olabilir.)

Örnek: 198.51.100.0/24 aralığına periyodik küçük veri çıkışı (beacon benzeri örüntü) görülür. Bu tek başına "C2 var" demek değildir. Aynı zaman penceresinde süreç ağacı değişimi, yeni servis/kalıcılık izi, şüpheli oturum gibi ikinci bir sinyal aranır.

Dikkat: Saldırgan altyapısıyla doğrudan etkileşime girerek "bakmak", operasyonel güvenlik açısından ters tepebilir; saldırganın izlenildiğini anlamasına ve davranış değiştirmesine yol açabilir. Bu modülde tercih edilen yaklaşım, öncelikle pasif ve denetlenebilir kaynaklarla doğrulamadır.

2.2. Super-timeline: Zaman çizelgesi uydurulmaz, yönetilir

Super-timeline, disk artefaktlarını, event log'ları, ağ kayıtlarını ve (varsa) bellek bulgularını tek bir zaman omurgasında birleştirir. Neden önemli? Çünkü containment ve recovery kararları, olay penceresi üzerine oturur.

• "İlk görülen" ile "ilk gerçekleşen" ayrımını koruyun: log eksikse, boşluk "varsayımla" doldurulmaz.

• Zaman damgası tutarlılığı: timezone/NTP farklarını raporda açıkça not edin.

• Dil disiplini: "03:00'te saldırgan girdi" yerine "03:00'te şu kaynaktan şu olay kaydedildi" demek denetlenebilirliği artırır.

Örnek: Dosya sistemi zaman damgaları ile yürütme kanıtı üreten artefaktların zamanları çelişiyorsa (mantıksız sıçramalar), bu bir anti-forensic sinyal olabilir; en güvenli yaklaşım, çelişkiyi "kanıt ağırlığı" mantığıyla tartmak ve belirsizliği görünür kılmaktır.

İpucu: Timeline'a her satır için "kaynak referansı" eklemek (hangi log/artefakt), akran incelemesinde en hızlı güven kazandıran pratiktir. "Nereden biliyoruz?" sorusunu satır seviyesinde yanıtlar.

2.3. Zincir: vektör → yayılım → kalıcılık → etki (Kill Chain / ATT&CK ile okuma)

Bu başlık, "saldırı nasıl yapılır" anlatımı değildir. Ama zincirin her halkası için hangi izlerin beklenebileceğini ve nasıl doğrulanacağını konuşur.

• Vektör sinyalleri: kimlik anomalileri, uygulama hataları, e-posta/indirme izleri, VPN/SSO değişimleri

• Yayılım sinyalleri: aynı hesabın çoklu host'larda görünmesi, segmentler arası beklenmeyen bağlantılar

• Kalıcılık sinyalleri: zamanlanmış görev/servis kayıtları, WMI/otomasyon izleri, script telemetrisi (varsa)

• Etki sinyalleri: dosya uzantı değişimleri, veri erişim sıçraması, hizmet kesintisi, güvenlik kontrollerinde anomali

Örnek: Bir sunucuda dosya uzantılarının topluca değiştiği görülür. Bu "etki"ye işaret eder; fakat "veri sızıntısı da oldu" iddiası için ayrıca ağ ve süreç artefaktlarıyla doğrulama gerekir. "Fidye notu" çoğu zaman psikolojik baskıdır; tek başına teknik kanıt sayılmaz.

MITRE ATT&CK haritalaması bu modülde bir "etiketleme" egzersizi değil; gözlediğiniz veriyle ilişkilendirme aracıdır: gördüğünüz sinyal hangi taktik/teknik sınıfına oturuyor ve bunu destekleyen veri hangi kaynaktan geliyor?

2.4. Pivot yönetimi: Bir bulgudan yeni doğrulama yoluna geçmek

Pivot, tek bir "gösterge"yi olay hikâyesinin omurgasına bağlayan geçiştir. Kötü pivot, sizi gürültüye taşır; iyi pivot, bağımsız doğrulamaya.

Örnek: Etkilenen sunucunun log'larında olaydan kısa süre önce bir servis hesabıyla uzaktan etkileşim görülür. Bu noktada, uzaktan oturum türünü ve kaynağı netleştirmek için kimlik kayıtlarıyla korelasyon kurarsınız (ör. uzaktan etkileşim türleri).

Örnek: Sunucuya uzaktan yönetim aracıyla erişim şüphesi varsa, bazı araçlar hedef sistemde kısa ömürlü servis oluşturabilir; bu, sistem olay günlüğünde "yeni servis kuruldu" tipinde izler bırakabilir. Bu sınıf olaylar (örn. Event ID 7045: A service was installed in the system) lateral movement doğrulamasında değerli sinyal üretir.

Örnek: Pivot bir istemciye kayar: tarayıcı geçmişinde "fatura_sorgulama.zip" gibi bir indirme izi, yürütme kanıtlarında ilişkili bir çalıştırma sinyali ve bellek/ağ telemetrisinde 203.0.113.0/24 bloğundaki bir uçla periyodik bağlantı şüphesi görülebilir. Bu parçalar tek tek ipucu iken, birlikte "daha güçlü iddia" üretir; yine de masum açıklamalar ve karşı kanıtlar aktif biçimde aranır (meşru güncelleme/ajan davranışı, planlı iş akışları vb.).

2.5. Containment: "En sert" değil, "en savunulabilir" karar

Containment bir refleks değil, risk-kanıt-iş etkisi dengesidir.

• Uçucu delil riski (sistem kapanırsa neyi kaybedersiniz?)

• Yayılım ihtimali (kimlik altyapısı etkilenmiş olabilir mi?)

• İş kritikliği (kesinti maliyeti)

• Telemetri kapsaması (izlemenin anlamı var mı?)

İpucu: Karar günlüğünü bir "denetim omurgası" gibi düşünün: zaman, kararı veren rol, dayanak bulgular, değerlendirilen alternatifler, beklenen risk azaltımı. Sunumda en çok güven üreten parçalar genellikle burasıdır.

2.6. Eradication ve recovery: Temizlik mi, yeniden kurulum mu?

Bu noktada "alışkanlıkla yapılan" kararlar en pahalı hatalara dönüşür. Seçim; kanıt gücü, kapsam belirsizliği ve kalıcılık ihtimaliyle yapılır.

• Güven düzeyi: yönetici yetkisi/kalıcılık şüphesi var mı?

• Temiz geri dönüş noktası: yedeğin olay öncesi olduğu bağımsız kanıtlarla gösterilebiliyor mu?

• Kök neden kapatma: yapılandırma/yama/kimlik kontrolleri gerçekten kapandı mı, doğrulandı mı?

Örnek: Dosya sunucusunda şüpheli erişim doğrulanmıştır; fakat kimlik altyapısına uzanan kanıt yoktur ve yedeklerin olay penceresi dışında olduğu güçlü biçimde gösterilebiliyordur. Restore, savunulabilir olabilir. Aynı senaryoda kimlik altyapısında rol değişimleri ve beklenmeyen servis hesap hareketleri görülseydi, daha geniş rebuild ve erişim sıfırlama gündeme gelirdi.

3. Ekip çıktıları: "Bulduk" yetmez; kanıt standardında paketle

İleri seviye değerlendirmede, kanıt kalitesi düşük bir "doğru tahmin" yerine; kanıt kalitesi yüksek, temkinli ve denetlenebilir bir sonuç daha değerlidir.

3.1. IoC seti: Liste değil, bağlamlı ve derecelendirilmiş paket

IoC'ler operasyonel yakıttır; bağlam yoksa gürültü üretir.

• Bağlam: hangi sistem(ler), hangi zaman penceresi, hangi davranışla ilişkili?

• Güven düzeyi: doğrulanmış mı, kuvvetli şüphe mi, araştırma gerektiriyor mu?

• Paylaşım sınırı: yanlış pozitif ve gereksiz ifşa riski

Örnek: "203.0.113.88" tek başına "engelle" listesi değil; hangi host'ta, hangi süreç bağlamında, hangi zaman penceresinde görüldüğünü ve doğrulama durumunu taşıyan bir kayıttır.

Dikkat: "Ne kadar çok IoC, o kadar iyi" yaklaşımı yanlış pozitifleri şişirir. Aynı zamanda gerçek sinyali boğar ve SOC'un güvenini düşürür.

3.2. Timeline paketi: Yeniden üretilebilirlik standardı

İyi timeline, başka bir analistin aynı sonuca ulaşmasını kolaylaştırır:

• kaynak referansı (log/artefakt)

• zaman standardı notu (timezone/NTP)

• olay-yorum ayrımı

• belirsizlikler ve kör noktalar

3.3. Kök neden hipotezi: Kesinlik değil, kanıt ağırlığı

Kök neden, her zaman tek bir "kapı" değildir; zincirin kırıldığı yeri göstermektir.

• birincil hipotez + dayanak kanıtlar

• alternatif hipotezler + onları zayıflatan karşı kanıtlar

• kalan belirsizlik + kapatma için önerilen doğrulamalar

Örnek: "Yetkisiz erişim, kimlik doğrulama akışındaki bir yapılandırma zafiyetiyle kolaylaşmış olabilir." Bu iddia; ilgili konfig değişikliği kaydı, oturum anomalilerinin zaman penceresi ve MFA olaylarıyla tutarlıysa güçlenir. Aynı pencerede planlı değişiklik kaydı bulunursa hipotez revize edilir.

3.4. Öneriler: Teknik bulgudan operasyonel karara

Öneriler "dilek listesi" değil; uygulanabilir, ölçülebilir risk azaltımıdır.

• hızlı kazanımlar (hemen azaltılan risk)

• orta vadeli iyileştirmeler (telemetri, segmentasyon, playbook)

• ölçülebilir başarı ölçütleri (MTTD/MTTR, log kapsaması, av penceresi)

Örnek: "MFA zorunlu olsun" tek başına slogan değildir; hangi hesap sınıflarında öncelikli, hangi istisnalarla, doğrulaması nasıl yapılacak, raporda netleştirilir.

3.5. Delil paketi ve redaksiyon: Raporu taşıyan iskelet

Delil paketi, rapordaki iddiaların dayanağıdır:

• delil envanteri

• bütünlük kayıtları (hash, saklama)

• erişim/transfer kayıtları

• sınırlılıklar ve kör noktalar

• gerektiğinde redaksiyon (hassas veriyi maskeleme)

4. Sunum ve değerlendirme: Aynı gerçeği farklı katmanlarda anlatmak

Bu bölümde "doğru içeriği" doğru formatta sunarsınız. İyi yapılandırma, belirsizliği bile yönetilebilir kılar.

4.1. Katmanlı sunum: Tek doğruluk kaynağı, iki okuma yolu

• Yönetici katmanı: etki, risk durumu, alınan kararlar, kalan belirsizlik ve plan

• Teknik katman: timeline, doğrulama adımları, IoC seti, delil paketi referansları

• Karar günlüğü: containment/eradication/recovery kararlarının gerekçesi

Örnek: Yönetici özeti "hash, registry key" ile dolarsa mesaj dağılır; karar vericinin ihtiyacı risk/etki/aksiyon çerçevesidir. Teknik detaylar eklerde yaşar.

4.2. Rubrik ve akran değerlendirmesi

Değerlendirme, tipik olarak şu eksenlerde yapılır:

• Doğruluk (sonuçların veriye dayanması; varsayımların açık yazılması)

• Kanıt kalitesi (olgu-yorum ayrımı; kaynak gösterimi; bütünlük disiplini)

• Kararların gerekçesi (alternatif yöntemler; risk-kanıt-iş etkisi dengesi)

• Rapor netliği (katmanlı yapı; yeniden üretilebilirlik; anlaşılır öneriler)

• İyileştirme önerileri (stratejik ve ölçülebilir olup olmaması)

Akran değerlendirmesi (peer review) burada "kusur bulma" değil, denetlenebilirliği artırma aracıdır: iddiaların kanıtla bağını, timeline'ın tutarlılığını ve kör noktaların raporlanma kalitesini birlikte kontrol edersiniz.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Olayı envanter ve başlangıç göstergeleriyle doğru çerçeveleyip önceliklendirme
• Hipotez–doğrulama döngüsünde karşı kanıt arama refleksiyle “kesinlik” yönetimi
• Super-timeline kurarak zaman tutarlılığı, boşluk ve kör nokta yönetimi
• Containment/eradication/recovery kararlarını alternatiflerle kıyaslayıp gerekçelendirme
• IoC seti, timeline, kök neden hipotezi ve önerileri delil paketiyle birlikte savunulabilir hale getirme
• Yönetici + teknik katmanlı raporlama ve akran değerlendirmesiyle kaliteyi yükseltme