MODÜL 1 — Koddan Makineye: C → Assembly → Binary

Modül Teması

Kaynak kodun olmadığı bir dünyada, "ne amaçlandı?" sorusu ile "gerçekte ne çalıştı?" sorusu arasındaki mesafe büyür. Bu modül, o mesafeyi tahminlerle kapatmak yerine; derleyici ve bağlayıcının ikili dosyada bıraktığı izlerden, kontrol/veri akışı üzerinden doğrulanabilir çıkarımlar üretmeyi öğretir. Hedef; assembly satırlarını ezberlemek değil, bir davranış hipotezini kanıt zinciri ile sınayıp raporda yeniden üretilebilir şekilde anlatabilmektir.

1) Derleme ve linkleme: İkili dosyanın "anatomi"sini okumak

C kodu, çalıştırılabilir hale gelirken yalnızca talimatlara "çevirilmez"; aynı zamanda işletim sisteminin onu nasıl yükleyeceğine dair bir düzen de inşa edilir. Derleyici kaynak kodu nesne dosyalarına (.o/.obj) dönüştürür; bağlayıcı (linker) bu parçaları ve kütüphaneleri birleştirerek nihai yürütülebilir dosyayı üretir (platforma göre PE/ELF gibi biçimler).

Bu süreci analiz açısından bir üretim hattı gibi düşünmek işe yarar: her istasyonda bazı bilgiler kaybolur (değişken isimleri gibi), bazıları eklenir (bölüm düzeni, relocation kayıtları gibi). İleri analistin yaptığı iş, kaybolanı "hikâye uydurarak" geri getirmek değil; kalan izlerden doğrulanabilir sonuç çıkarmaktır.

1.1. Semboller ve debug bilgisi: Hızlandırır ama garanti vermez

Semboller (symbols), fonksiyon/nesne isimleri ile adres ilişkisini taşıyan isimlendirme dünyasıdır. Debug bilgisi (debug info) ise kaynak seviyesindeki bazı anlamların (satır eşlemesi, tipler, değişken adları gibi) ikiliye eklenmiş halidir. Yayın derlemelerinde çoğu zaman temizlenir (stripping), ama bazen kurumsal paketlemelerde, hatalı build zincirlerinde veya yanlışlıkla yayımlanan sürümlerde kalıntılar görülebilir.

Neden önemli? Çünkü sembol/debug bilgisi, decompiler'ın varsayım yükünü azaltır; hipotez kurmayı hızlandırır. Ancak bu bilgi var diye "doğru yorum" otomatik gelmez: isimler yanıltıcı olabilir, yeniden kullanılan bileşenler eski isimleri taşıyabilir, hatta bilerek aldatıcı etiketleme görülebilir.

Yöntem seçimi (sembol/debug varken — yokken):

• Bilgi varsa: hızlı yön bulma, çağrı grafiği üzerinde önceliklendirme, kritik işlevleri daha çabuk aday gösterme.
• Risk: "isim doğruysa işlev de doğrudur" refleksi.
• Bilgi yoksa: kontrol akışı + veri akışı + yan etkiler (dosya/ağ/bellek) üzerinden daha disiplinli ilerleme.
• Risk: daha fazla zaman; ama rapor kanıt standardı genellikle daha sağlam kurulur.

Örnek: Bir fonksiyonun adı "decode" gibi görünüyor diye rapora "şifre çözüyor" yazmak güvenli değildir. Giriş/çıkış verisinin biçimi, çağrı bağlamı ve sonraki kullanım (örneğin metne dönüşüm, tablo indeksleme, ağ isteğinde header üretimi gibi) aynı sonuca işaret ediyorsa ifade güçlenir; aksi durumda daha temkinli bir dille yazılır.

$ re-lab # Aday fonksiyonun giriş/çıkış biçimi
$ python inspect_fn_io.py --fn sub_140012A30
input_type=byte_buffer
output_type=byte_buffer
len_relation=preserved

$ re-lab # Çıkış nerede tüketiliyor?
$ python trace_xrefs.py --from sub_140012A30 --depth 2
sink_1=table_lookup
sink_2=header_builder
text_render_usage=0

$ re-lab # Rapor dili: temkinli yorum
$ echo "assessment=transform_function; decode_confidence=low-medium"
assessment=transform_function; decode_confidence=low-medium

İpucu: Sembol/debug yokken bile "en az varsayım" ilkesini kullan. Kontrol akışı ve veri akışı aynı yorumu destekliyorsa rapora taşınan cümle kırılgan olmaz.

2) C yapılarının assembly'deki yüzü: koşul, döngü, çağrı

Bu bölümde amaç "assembly'yi C'ye çevirme" değil; assembly'nin davranışa dair taşıdığı sinyalleri okumaktır. Decompiler'ın sunduğu C-benzeri görünüm, çoğu zaman iyi bir haritadır; ama haritanın doğru olup olmadığını araziyle (disassembly ve akış) sınamak gerekir.

2.1. Koşullar: karşılaştırma + dallanma

Koşullar, assembly'de bir karşılaştırma (CMP/TEST benzeri) ve ardından koşullu dallanma (JZ/JNE/JG... benzeri) olarak görünür. Decompiler bunu okunur bir if gibi sunar; fakat optimizasyonlar veya dönüşümler nedeniyle koşul ters çevrilmiş, birleştirilmiş ya da farklı bloklara dağılmış olabilir.

Neden önemli? Zararlı davranışın "ne zaman devreye girdiği" çoğu zaman koşullarla belirlenir: ortam uygunsa çalışma, hata olursa geri çekilme, belirli bir işaret varsa farklı yol izleme gibi.

Doğrulama refleksi (karşı kanıt arayarak):

• Karşılaştırılan değerin kaynağı neresi (parametre mi, global mi, bir çağrının dönüşü mü)?
• Dallanma sonrası iki yolun yan etkileri neler (dosya erişimi, bellek ayırma, ağ çağrısı, süreç oluşturma vb.)?
• Alternatif yol gerçekten alternatif mi, yoksa erişilemeyen/temizlenecek bir parça mı?

Örnek: Decompiler bir yerde "x == 0 ise başarısız ol" gibi bir yapı gösteriyorsa, x'in gerçekten "sıfır olması gereken bir durum" olup olmadığını x'in üretildiği çağrı sözleşmesiyle ve sonraki kullanım biçimiyle sınarsın. Eğer x bir hata kodu ise, işaretin anlamını ters okumak kolaydır; karşı kanıt aramak bu yüzden kritiktir.

2.2. Switch/jump table: "çok kollu" kararların izi

Bazı çok dallı karar yapıları, jump table (zıplama tablosu) gibi düzenlerle uygulanabilir. Decompiler bazen bu dalları eksik veya hatalı temsil eder.

Yöntem seçimi: Decompiler görünümü "çok temiz" ama davranışın kapsamı şüpheliyse, kararın gerçekten kaç kola ayrıldığını kontrol akışı üzerinde doğrulamak daha güvenlidir. Burada hız — doğruluk dengesi kurulur: önce harita, sonra kritik bölgede sınır kontrolü.

Dikkat: "Okunaklı decompile" bir doğruluk sertifikası değildir. Rapor cümlesi, decompiler'ın estetiğine değil; akışın tutarlılığına dayanır.

2.3. Döngüler: geri dönüş (back-edge) + veri dönüşümü

Döngüler çoğu zaman geriye doğru dallanma ile tanınır; ancak optimizasyonlar döngüyü "tanınmaz" hale getirebilir (örneğin loop unrolling gibi). O yüzden yalnızca "burada geri zıplama var" demek, döngünün ne yaptığını kanıtlamaz.

Neden önemli? Döngüler genellikle tarama, kopyalama, dönüştürme, tablo gezinme, veri çözümleme gibi davranışların taşıyıcısıdır. Döngüyü yanlış yorumlamak; "kaç öğe işlendi?", "hangi sınır var?", "hangi koşul döngüyü kırıyor?" gibi kritik soruları bozar.

İki yaklaşım ve seçim mantığı:

• Kontrol akışı odaklı: Hangi blok tekrar ediyor? Hangi koşul geri dönüyor?
• Artısı: hızlıdır. Eksisi: optimizasyonla yanıltılabilir.
• Veri akışı odaklı: Her turda hangi değer değişiyor? Hangi adres ilerliyor? Hangi uzunluk/sayaç etkili?
• Artısı: daha sağlam kanıt üretir. Eksisi: daha zahmetlidir.

İpucu: Döngüyü rapora taşırken "döngü var" demek yerine, sayaç/indeksin nerede tutulduğunu ve her turdaki veri dönüşümünün izini anlat. Bu, yeniden üretilebilirliği belirgin artırır.

2.4. Fonksiyon çağrıları: niyetin düğüm noktası

Bir CALL gördüğünde tek soru "ne çağrıldı?" değildir. "Hangi argümanlarla, hangi bağlamda, hangi dönüş değeriyle, hangi yan etkiyle?" soruları birlikte cevaplanır.

Neden önemli? Bir davranışı savunabilmek için yalnızca "şu API çağrılıyor" demek yetmez; argüman kaynakları ve çağrı sonrası etkiler, kanıt zincirini oluşturur.

Kanıt üretimi: gözlem — yorum ayrımı

• Gözlem: Argümanların hangi bellek bölgesinden geldiği, çağrı sırası, dönüş değerinin nasıl kullanıldığı, kritik adres/offset referansları
• Yorum: Bu gözlemlerin hangi davranışa işaret ettiği, belirsizlik payı, alternatif açıklamalar

Örnek: Bir çağrının ilk argümanı bir buffer adresi gibi görünüyorsa, o buffer'ın nerede doldurulduğunu ve daha sonra metin olarak mı işlendiğini yoksa ikili blob gibi mi taşındığını sınarsın. "Buffer var" gözlemdir; "konfigürasyon taşıyor" yorumdur ve gerekçeyle birlikte yazılır.

3) Calling convention ve stack frame: parametre takibinin omurgası

Calling convention, fonksiyon parametrelerinin nasıl taşındığını, dönüş değerinin nasıl iletildiğini ve çağrı sonrası temizliğin nasıl yapıldığını belirleyen sözleşmedir.

Neden önemli? Parametreyi yanlış yerde ararsan, fonksiyonun yaptığı işi de yanlış tarif edersin. Bu, hatalı tespit önerilerine ve yanlış IOC/IOA üretimine kadar gidebilir.

3.1. x64 (Windows ABI): ilk dört argüman yazmaçlarda

Windows x64'te varsayılan çağrı düzeninde ilk dört argüman yazmaçlarda taşınır: tamsayı/pointer türleri için sırasıyla RCX, RDX, R8, R9; kayan nokta argümanları için XMM yazmaçları kullanılır. Bu düzen, analizde "ikinci parametre nerede?" gibi soruları netleştirir.

Bu bilgi, "decompiler bana iki argüman gösterdi" gibi belirsizliği azaltır: doğru yerde bakarsın; yanlış yerde arama ihtimali düşer.

3.2. x86 dünyası: çağıran — çağrılan temizliği ve hatalı okuma riski

x86 tarafında cdecl/stdcall gibi düzenlerde parametrelerin yığın üzerinden geçmesi ve yığının kim tarafından temizlendiği değişebilir. Örneğin __cdecl'de temizliği çağıran, __stdcall'de çağrılan taraf yapar. Bu fark, özellikle "kaç argüman var?" ve "çağrıdan sonra yığın nasıl değişti?" sorularını yanıltmaya açık hale getirir.

3.3. Stack frame: fonksiyonun çalışma masası

Stack frame'i, bir teknisyenin masası gibi düşünebilirsin: hangi araç nereye konduysa, iş bitince iz bırakır. Fonksiyonun yerel değişkenleri, kaydedilmiş yazmaçlar ve dönüş adresi belirli bir düzende durur. Bu düzen, parametrelerin ve yerel verinin nerede olduğuna dair ölçülebilir kanıt sağlar.

Doğrulama: pointer mı, handle/değer mi? Decompiler bir argümanı pointer gibi gösterebilir; ama o değer hiç dereference edilmiyorsa, belki de bir handle/değer taşınıyordur. Karşı kanıt aramak burada çok nettir: değer daha sonra bellek erişiminde mi kullanılıyor, yoksa yalnızca çağrılar arasında mı aktarılıyor?

Dikkat: Fonksiyon prologue/epilogue desenleri genellikle stack frame yorumunu kolaylaştırır; fakat optimizasyonlar veya elle yazılmış assembly, bu düzeni "beklenmedik" hale getirebilir. Beklenmedik gördüğünde, varsayımı büyütmek yerine kanıtı sıkılaştır.

4) Optimizasyonlar: "ikna edici ama yanlış" decompile tuzağı

Modern derleyiciler performans için kodu yeniden şekillendirir: küçük fonksiyonları içeri alabilir (inlining), erişilemeyen yolları temizleyebilir (dead code elimination), döngüyü açabilir (loop unrolling) veya değişkenleri tamamen yok edebilir.

Neden önemli? Çünkü optimize edilmiş ikililerde decompiler'ın ürettiği C-benzeri yapı "çok temiz" görünebilir; ama bu temizlik, gerçek niyetin doğru yansıtıldığı anlamına gelmez.

Yöntem seçimi (strateji üçlüsü):

• Decompiler odaklı okuma: hızlı harita çıkarır; risk, yanlış güven duygusudur.
• Disassembly odaklı okuma: daha sağlam sınar; risk, zaman maliyetidir.
• Hibrit: decompiler ile harita, disassembly ile kritik bölgelerde sınır kontrolü. İleri seviyede en dengeli yaklaşımdır.

Örnek: Kaynakta tek bir döngü varken, loop unrolling sonrası decompile "arka arkaya çok sayıda benzer işlem" gibi görünebilir. Burada veri akışıyla sayaç/indeks davranışını aramak, yanlış çıkarımı engeller.

5) "Decompile güvenilirliği": doğrulama, karşı kanıt, kanıt paketi

Decompiler çıktısını bir sonuç değil, bir hipotez olarak ele almak ileri seviye okuryazarlığın çekirdeğidir. Hipotezi güçlendiren şey, birden fazla bağımsız sinyalin aynı yorumu desteklemesidir.

5.1. Güvenilirlik sorusunu üç yönden sormak

Bir parça decompile'a baktığında şunlar birlikte cevaplanır:

• Kontrol akışı bu yorumu destekliyor mu?
• Veri akışı (kaynak → dönüşüm → kullanım) tutarlı mı?
• Yan etkiler (dosya/ağ/bellek/süreç) bu yorumu güçlendiriyor mu?

Bu üçlüden biri boşsa, rapor dili "kesin" olmaktan çıkar; belirsizlik alanı net yazılır.

5.2. Karşı kanıt arama: analisti hatadan koruyan refleks

Doğrulama yalnızca kanıt toplamak değildir; yanlış olabilecek noktayı da aramaktır.

Karşı kanıt örnekleri:

• Decompiler pointer dereference gösteriyor ama disassembly'de o değer hiç dereference edilmiyor.
• "String compare" gibi görünen şey aslında uzunluğu değişken ikili bir blob.
• "x > 0" gibi görünen koşul, gerçek hata kodu sözleşmesiyle ters anlam taşıyor.

Örnek: Decompiler bir değişkene "len" havası veren bir kullanım çiziyor. Sen, bunun gerçekten uzunluk olup olmadığını buffer işlemlerinde ölçülebilir şekilde kullanılıp kullanılmadığıyla sınarsın. Eğer yalnızca API'ler arasında taşınan bir tanıtıcı gibi davranıyorsa, isimlendirme yanlıştır; rapora da "muhtemel uzunluk" gibi temkinli ifade girer.

5.3. Raporlanabilir kanıt paketi: yeniden üretilebilirlik standardı

Yayınlanabilir bir ileri analiz çıktısı, "ne buldum?" kadar "nasıl emin oldum?" sorusunu da taşır. Pratik bir kanıt paketi şu omurgayla kurulur:

• Gözlemler: adres/offset referansları, çağrı sırası, argüman kaynakları, kritik basic block açıklaması
• Yorum: davranış çıkarımı + belirsizlik notu
• Doğrulama: hangi alternatif açıklama elendi, hangi karşı kanıt arandı
• Artefakt: kısa akış şeması kırıntısı, çağrı grafiği özeti, veri akışı özeti
• Yeniden üretilebilirlik: hangi varsayımlar altında aynı sonuç çıkar, hangi koşullar değişirse yorum zayıflar

İpucu: Kesin ifade kullanacağın her cümlede, kendine "bunu çürütebilecek karşı kanıt ne olurdu?" diye sor. Cevap veremiyorsan, cümleyi ya yeniden formüle et ya da kanıtı güçlendirecek ek kontrol ekle.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Derleme/linkleme sürecinin ikili dosyada bıraktığı izleri “kanıt kaynağı” olarak okuyabilme
• Sembol/debug varlığını hızlandırıcı görüp, yokluğunda kontrol+veri akışına dayalı disiplinli yaklaşım kurabilme
• Koşul/döngü/çağrı örüntülerini assembly seviyesinde davranış hipotezi kuracak kadar okuyabilme
• Calling convention ve stack frame üzerinden doğru parametre takibi yapıp yanlış yorum riskini azaltma
• Optimizasyonların decompile’ı kaydırabileceğini bilip, hibrit okuma ve karşı kanıt aramayla güvenilir rapor cümlesi kurabilme

Modül 2 — Reverse Engineering Hazırlık

İleri seviye tersine mühendislikte en pahalı hata, "hemen koda dalıp" erken bir hikâyeye inanmak ve sonra o hikâyeyi kanıt gibi rapora taşımaktır. Bu modül, disassembly'nin çıplak gerçekliği ile decompiler'ın rahat ama yorumlayıcı dünyası arasında doğru dengeyi kurmayı; kontrol akışı (CFG) ve veri akışını birlikte okuyarak "kritik fonksiyonları" bilimsel ölçütlerle seçmeyi ve analizi en baştan raporlanabilir, yeniden üretilebilir bir kanıt hattına dönüştürmeyi hedefler.

1) Disassembly ve decompile okuma ilkeleri

Tersine mühendislikte iki ayrı mercek kullanırsın: disassembly (işlemcinin gerçekten yürüteceği talimatlar) ve decompile (bu talimatlardan türetilmiş C-benzeri temsil). İleri seviye fark, bu iki merceği birbirinin alternatifi değil, birbirini "denetleyen" bir çift olarak konumlandırmaktır.

Decompile çıktısı büyük ikililerde yön bulmayı hızlandırır: muhtemel fonksiyon sınırları, if/loop benzeri bloklar, değişkenler ve akışın kabaca "neye benzediği"... Disassembly ise tartışmasız gerçekliktir: hangi register'ın ne zaman değiştiği, hangi dalın gerçekten mümkün olduğu, hangi çağrı öncesi hangi argüman hazırlığının yapıldığı oradadır.

Neden önemli? Çünkü decompiler, kaybolan tip bilgisini ve değişken isimlerini "tahmin eder"; optimizasyonlar da bu tahmini daha kırılgan hale getirir. Dolayısıyla decompile çoğu zaman iyi bir hikâye anlatır — ama ileri analist, hikâyeyi rapora yazmadan önce "çürütülebilir mi?" sorusunu sorar ve karşı kanıt arar.

1.1. Harita çıkar, sınır kontrolü yap

Decompile'ı "harita" gibi düşün: hızlıca nerede olduğunu görürsün; ama kritik kavşakta pasaport kontrolü gerekir — yani disassembly ve veri akışıyla doğrulama.

Sınır kontrolünü özellikle tetikleyen durumlar:

• "Aşırı temiz" görünen akışlar (optimize edilmiş ikililerde bu temizlik yanıltıcı olabilir)
• Pointer gibi görünen ama hiç dereference edilmeyen değerler (handle / durum kodu olma ihtimali)
• Decompiler'ın ürettiği anlamlı değişken isimlerine gereğinden fazla güvenme
• "Fonksiyonun adı var" diye otomatik anlam yükleme (isimlendirme yanlış/eksik/yanıltıcı olabilir)

Doğrulama zihniyeti: Decompile'daki bir iddiayı rapora taşımadan önce en az iki bağımsız işaret ararsın. Örneğin kontrol akışı bu yorumu destekliyor mu + veri akışı aynı sonuca gidiyor mu + (varsa) yan etki (dosya/ağ/bellek) ile uyumlu mu?

Örnek: Decompile, bir fonksiyonu "ayarları ayrıştırıyor" gibi gösteriyor. Rapor cümlesine dönüşmeden önce, fonksiyon çıktısının nerede kullanıldığına bakarsın: bir karar koşulunu mu besliyor, ağ isteğine mi gidiyor, bir tablo indeksini mi belirliyor? Çıktı hiç kullanılmıyorsa "ayrıştırma" iddiası zayıflar; belki de yalnızca hazırlık yapan bir yardımcı bloktur.

Dikkat: "Decompiler böyle gösterdi" bir kanıt türü değildir. Kanıt; kontrol akışının tutarlılığı, veri zincirinin izlenebilirliği ve (varsa) gözlemlenebilir yan etkilerle desteklenmiş, yeniden üretilebilir bir çıkarımdır.

1.2. Disassembly'de okuma disiplini: talimat değil ilişki oku

Ham talimatların tek tek anlamına takılıp kalmak, büyük örneklerde seni "mikro ayrıntıda boğar". Daha verimli olan, ilişkileri okumaktır:

• Hangi basic block hangi bloğa bağlanıyor?
• Hangi çağrı, hangi çağrı zincirini tetikliyor?
• Hangi veri nereden geliyor, nerede dönüşüyor, nerede anlam kazanıyor?

Yöntem seçimi:

• Zaman baskısı varsa: önce decompile ile harita çıkar, riskli kavşaklarda disassembly ile doğrula.
• Kanıt standardı yüksek bir çıktı gerekiyorsa (olay müdahalesi, kurumsal rapor, hukuki/uyum etkisi olan senaryolar): kritik iddialarda disassembly doğrulaması "varsayılan" olur.
• Kütüphane kodu yoğun ikililerde: disassembly'ye erken gömülmek kaybolma riskini artırır; önce kritik fonksiyon seçimi ve akış planı gerekir (Modülün 4. bölümü).

İpucu: Decompile'da "okunaklı görünen" bir akış bulduğunda, hemen anlam yüklemek yerine o akışın hangi yan etkilere bağlandığını işaretle. Yan etkiyi ölçebildiğin (dosya/ağ/bellek/süreç) her yerde rapor cümlesi daha sağlam olur.

2) Kontrol akışı okuma: branch, loop, function çağrıları

Kontrol akışı, programın "hangi yoldan yürüdüğü"dür; tersine mühendislikte bu, yalnızca if/else görmek değil, karar noktalarının davranışla ilişkisini kurmaktır. CFG (Control Flow Graph), basic block'lar arası geçişleri bir grafik olarak göstererek bu ilişkiyi görünür kılar.

Neden önemli? Çünkü şüpheli davranışlar çoğu zaman koşullarla devreye girer, döngülerle tekrarlanır ve çağrı zincirleriyle dış dünyaya etki eder. Akışı yanlış yorumlamak, yanlış davranış cümlesi ve yanlış tespit önerisi demektir.

2.1. Karar noktaları: koşulun anlamı kaynağından anlaşılır

Bir koşulun ne anlattığı, karşılaştırılan değerin kaynağı ile şekillenir: parametre mi, global mi, bir çağrının dönüşü mü, yoksa ara bir değer mi?

Doğrulama ve karşı kanıt arama:

• Değer bir çağrı dönüşüyse, o çağrının hata/başarı sözleşmesi ile uyumlu mu?
• Koşulun iki kolunda yan etkiler gerçekten ayrışıyor mu, yoksa biri erişilemez / "gürültü" mü?
• Decompiler koşulu ters çevirmiş olabilir mi? En güçlü sinyal, dalların sonunda ortaya çıkan davranış farkıdır (hangi dal "iş" üretiyor, hangisi yalnızca temizlik/hata yönetimi?)

Örnek: Bir dal, yüzeyde "başarısız ol ve çık" gibi görünür; ama aslında normal kapanış yolu olup kaynakları kapatır ve standart dönüş değerini ayarlar. Diğer dal ise ağ/dosya/bellek tarafında asıl yan etkiyi üretir. Bu durumda "başarı/başarısızlık" etiketleri yerine, dalların ölçülebilir etkileri üzerinden rapor dili kurmak daha güvenlidir.

2.2. Döngüler: "Ne zaman biter?" sorusu kanıt üretir

Döngüyü görmek yetmez; döngünün çıkış koşulu ve her turda değişen değerler, davranışın sınırlarını verir.

Burada kritik bir nüans var: Disassembly'de "geriye doğru dallanma" (back edge) döngü adayını güçlü biçimde işaret eder; ancak tek başına her zaman "kesin döngü" demek değildir. CFG'de back edge kavramının nasıl tanımlandığı ve analiz bağlamına göre değişebileceği, kontrol akışı teorisinin temel parçalarındandır. Bu yüzden döngüyü rapor cümlesine taşımadan önce şu kanıtları ararsın:

• Çıkış koşulu nerede ve nasıl kontrol ediliyor?
• Her turda hangi sayaç/indeks değişiyor (register/stack/global)?
• Döngü kırılınca hangi yan etki başlıyor (ör. bir çağrı zincirinin başlaması, bir veri yapısının tamamlanması, bir durumun set edilmesi)?

Yöntem seçimi:

• Kontrol akışı ile iskeleti hızlı çıkarırsın; ama optimizasyonlar döngüyü parçalayabilir.
• Veri akışı ile sayaç/işlenen blok büyüklüğünü izlemek daha sağlamdır; raporda daha güvenli temel oluşturur.

Dikkat: Döngüye erken "şu kadar tekrar eder" gibi kesin sınırlar yazmak, kanıt standardını yükseltir. Çıkış koşulunu ve sayaç değişimini görmeden sayısal kesinlik eklemek, itiraz edildiğinde kırılganlık yaratır.

2.3. Çağrı grafiği: davranış zincirleri düğümlerden okunur

Fonksiyon çağrıları, davranışın düğüm noktalarıdır. Hazırlık aşamasında amaç "her fonksiyonu okumak" değil; çağrı grafiğinde merkez düğümleri bulmaktır:

• Dış dünya ile etkileşen (dosya/ağ/süreç/bellek yönetimi) düğümler
• Çok çağrılan / çok alt çağrı yapan düğümler (hub)
• Hata yollarını veya mod seçimini yöneten düğümler

Doğrulama: Çok çağrılan bir fonksiyon "kritik" olabilir; ama karşı kanıt şudur: Utility (loglama, string işlemleri, küçük dönüştürücüler) fonksiyonlar da sahte merkez gibi görünebilir. Bu ayrımı, fonksiyonun argüman rolü ve yan etkilerinde ararsın.

İpucu: Çağrı grafiğinde işaretlediğin her "kritik aday" için, kendine şu soruyu zorla: "Bu fonksiyon olmasaydı davranışın ölçülebilir bir parçası eksik kalır mı?" Cevap hayırsa, adayın önceliği düşebilir.

3) Veri akışı takibi: kaynak → dönüşüm → kullanım zinciri

Veri akışı, programın "neyle çalıştığı"dır: veri nereden gelir, nasıl dönüşür, nerede anlam kazanır. Orta seviyede bunun kontrol listesini ayrıntılı işlemiştik; burada ileri analiz açısından kritik nokta, veri akışını kanıt zinciri gibi kurmak ve karşı kanıt aramaktır.

Neden önemli? Çünkü decompiler tipleri ve isimleri "yakıştırabilir". Aynı kontrol akışı, farklı veriyle bambaşka davranış üretir; bu yüzden davranışı çoğu zaman veri belirler.

3.1. Üç temel soru: kaynak neresi, dönüşüm ne, kullanım nerede?

• Kaynak: Veri sabit mi, hesaplanmış mı, dışarıdan mı (dosya/ağ/pano benzeri), bir çağrı dönüşü mü?
• Dönüşüm: Birleştirme, ayrıştırma, kodlama/çözme, tablo indeksleme, doğrulama gibi işlemler var mı?
• Kullanım: Veri bir API argümanında mı, bir karar koşulunda mı, bir yapı alanında mı?

Bu üçlü, raporda gözlem — yorum ayrımının omurgasını kurar.

Örnek: Bir buffer hazırlanıyor, birkaç fonksiyondan geçiyor ve sonunda bir ağ çağrısının argümanına dönüşüyor. "Bu buffer konfigürasyondur" demek yorumdur; gözlem ise "şu blokta oluşturuldu, şu fonksiyonlarda dönüştü, şu çağrının şu argümanında kullanıldı" zinciridir.

3.2. Karşı kanıt arama: veri akışının güvenlik valfi

Veri akışında en sık hata, bir değere erken isim vermektir ("bu kesin anahtar", "bu kesin uzunluk" gibi). İleri seviye disiplin, isimleri ancak ölçülebilir kullanım biçimiyle destekleyince kullanır.

Karşı kanıt örnekleri:

• Pointer sandığın değer hiç dereference edilmiyor → handle/durum kodu olabilir
• Uzunluk sandığın değer buffer işlemlerinde görünmüyor → bayrak/durum olabilir
• String sandığın veri ikili blob → farklı bir kodlama/format olabilir

Bu yaklaşım, analizi "tek bir yoruma kilitlemekten" korur ve raporun denetlenebilirliğini artırır.

Dikkat: Veri akışında yanlış isim verme, domino etkisi yaratır: yanlış isim → yanlış hipotez → yanlış kanıt paketi → yanlış tespit önerisi.

3.3. Source & Sink düşüncesi ve aliasing gerçeği

Veri akışında "source" verinin sisteme girdiği nokta, "sink" ise verinin dışarı çıktığı veya kritik bir işleme sokulduğu noktadır. Bu model özellikle hassas verilerde (kimlik bilgisi, yapılandırma parametresi, kimlik doğrulama materyali) çok faydalıdır; çünkü zinciri baştan sona kurmaya zorlar.

Ancak pratikte bir sorun çıkar: data aliasing. Aynı bellek adresine farklı pointer'lar üzerinden farklı isimlerle erişilebilir; bu da decompiler ekranında "veri kayboldu" yanılsaması yaratır. Bu yüzden veri takibinde "aynı adres, farklı isim" olasılığını sürekli akılda tutmak gerekir.

Örnek: Bir metin parçası bir yerde "p" üzerinden taşınırken, başka bir fonksiyonda aynı bellek "buf" olarak görünür. İki farklı veri değil, aynı veri olabilir. Kanıt olarak, adres/offset sürekliliği ve kullanım desenleri aranır.

4) Kritik fonksiyonları seçme ve analiz planı çıkarma

İleri seviye örneklerde zorluk çoğu zaman "okumak" değil, nereden başlayacağını seçmektir. Kötü başlangıç saatlerce utility kodda oyalanmak demektir; iyi başlangıç davranış iskeletini hızla çıkarır.

Neden önemli? Analiz çıktısı genellikle karar vermeyi besler: etki değerlendirmesi, tespit önerisi, olay müdahalesi aksiyonu... Bu yüzden başlangıç noktası "sezgi" değil, ölçütlerle seçilmelidir.

4.1. "Kritik" kavramını ölçütlerle tanımla

Kritik fonksiyon tipik olarak şu özelliklerden en az birini taşır:

• Dış etkileşim: dosya/ağ/süreç/bellek yönetimi gibi yan etkilerle ilişki
• Merkezilik: çağrı grafiğinde birçok yolun üzerinden geçtiği düğüm (hub)
• Veri değeri: kritik veri üretimi/dönüşümü (parametre setleri, ana karar değerleri)
• Akış kontrolü: hata yönetimi, durum makinesi, mod seçimi

Bu ölçütleri yazılı hale getirmek planın yeniden üretilebilirliğini artırır: başka bir analist aynı ölçütlerle benzer başlangıcı seçebilmelidir.

4.2. Top-down / bottom-up / graf merkezli stratejiler ve riskleri

Top-down (dış etkileşimden içeri): Dış dünya ile etkileşen çağrılardan başlayıp geriye doğru iz sürmek.

• Güçlü yanı: Yan etkiler somut kanıt üretir.
• Risk: Çok sayıda "normal" yardımcı çağrı içinde kaybolma.

Bottom-up (veriden veya OS çağrılarından yukarı): Şüpheli veri dönüşümlerini veya OS etkileşim noktalarını bulup bunları üreten/karar veren üst mantığa tırmanmak.

• Güçlü yanı: Kritik veri ve karar mekanizmasını erken yakalar.
• Risk: Yanlış halka seçimi zinciri uzatır.

Graph-centric (çağrı grafiği merkezleri): Çok çağrılan / çok alt çağrı yapan düğümleri hedeflemek.

• Güçlü yanı: Davranış iskeletini hızlı çıkarabilir.
• Risk: Utility fonksiyonlar sahte merkez gibi görünebilir.

Doğrulama: Seçtiğin fonksiyonun kritik olduğuna dair karşı kanıt ararsın: yan etki yoksa, sadece veri taşıyorsa veya hep aynı küçük işi yapıyorsa önceliği düşebilir.

4.3. Boilerplate kodu ve bilinen fonksiyonları ayıklama

Derleyici çalışma zamanı (runtime), standart kütüphaneler ve tekrar eden kalıplar (boilerplate) analizde gürültü yaratır. Bu gürültüyü erken yönetmek, asıl davranışa odaklanmanı sağlar.

Burada yardımcı olan kavramlar:

• Xref (cross-reference): Bir fonksiyonun/verinin nerede kullanıldığını hızlıca görerek etki alanını saptarsın.
• İmza tabanlı tanıma (örn. FLIRT gibi yaklaşımlar): Bilinen kütüphane fonksiyonlarını etiketleyip "bilinmeyen kullanıcı kodu"na alan açmak, pre-analizi hızlandırır.

İpucu: Önceliklendirmeyi "insan gözüyle okunabilirlik" üzerinden değil, "kanıt değeri" üzerinden yap: dış etkileşim + kritik veri + akış kontrolü birleşiyorsa, o fonksiyon genellikle doğru başlangıçtır.

4.4. Analiz planını raporlanabilir hale getirme

İyi plan, sadece yapılacaklar listesi değildir; kanıt üretimine dönük bir çerçevedir:

• Test edilebilir hipotezler (hangi koşulda hangi davranış)
• Kanıt kaynakları (kontrol akışı, veri akışı, yan etkiler, graf ilişkileri)
• Karşı kanıt stratejisi (hangi alternatif açıklama elenecek)
• Üretilecek artefaktlar (kritik blok notları, çağrı zinciri özeti, veri zinciri şeması)
• Yeniden üretilebilirlik notu (hangi varsayımlar altında aynı sonuç beklenir)

"Zaman çizelgesi" mutlaka dinamik log anlamına gelmez; statikte bile "önce hazırlanır → sonra dönüştürülür → sonra kullanılır" sıralaması, kanıt anlatısını güçlendirir.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Decompile’ın yorumlayıcı doğasını, disassembly’nin tartışmasız gerçekliğiyle denetleyerek “harita + sınır kontrolü” disiplini kurmayı
• CFG ve çağrı grafiği üzerinden kontrol akışını davranış hipotezine bağlamayı; karar noktalarında kaynağı ve yan etkiyi kanıtlaştırmayı
• Veri akışını kaynak → dönüşüm → kullanım zinciriyle izleyip, karşı kanıt arama refleksiyle erken etiketleme riskini yönetmeyi
• Kritik fonksiyon seçimini ölçütlerle tanımlamayı; top-down / bottom-up / graf merkezli yöntemleri koşula göre seçmeyi
• Analizi, gözlem–yorum ayrımıyla paketlenmiş, yeniden üretilebilir rapor çıktısına dönüştürecek bir plan omurgası kurmayı

Modül 3 — CPU, ABI ve Assembly Okuryazarlığı

Bu modül, tersine mühendislikte "kodun ne dediği" ile "CPU'nun gerçekten ne yaptığı" arasındaki boşluğu kapatır. İleri seviyede fark yaratan şey, tek tek talimatları ezberlemekten çok; çağrı sözleşmesini (calling convention) ve ABI'yi doğru okuyarak argümanların/dönüş değerinin izini güvenilir biçimde sürmek, derleyicinin optimizasyonla bıraktığı izleri yanlış yorumlamamak ve her kritik iddiayı rapora taşınabilir kanıta dönüştürmektir. Büyük ikililerde hız kadar önemli olan, bulgunun çürütülemeyecek kadar iyi doğrulanmasıdır.

1) ABI ve calling convention okuryazarlığı: Argüman nerede aranır?

Calling convention, bir fonksiyonun argümanları nasıl aldığı, dönüş değerini nasıl verdiği ve stack temizliğinin kimde olduğu gibi kuralları belirler. ABI (Application Binary Interface) ise bunu daha geniş çerçeveye taşır: hangi yazmaçların "volatile" sayıldığı, stack hizalaması, çağrı sınırında hangi alanların ayrıldığı gibi kuralların tamamı, ikili seviyede uyumluluğun sözleşmesidir.

Neden önemli? Argümanı yanlış yerde ararsanız fonksiyonun "neyle çalıştığını" yanlış anlarsınız. Bu hata genelde tek bir cümleyi değil, tüm anlatıyı devirecek zincir etkisi yaratır: yanlış parametre yorumu → yanlış veri akışı → yanlış davranış tanımı → raporda zayıf/yanlış kanıt.

İleri analizde pratik gerçek: decompile çıktısındaki C-benzeri imza "ikna edici bir hipotez" olabilir; fakat belirleyici olan, çağrıdan hemen önce değerlerin nereden geldiği ve çağrıdan sonra dönüş değerinin nerede/niçin kullanıldığıdır. ABI okuryazarlığı, decompile'ı körlemesine reddetmek değil; kritik iddiaları CPU gerçekliğiyle sınırlandırmaktır.

1.1. x86 ↔ x64 parametre aktarımı: yazmaç önceliği, stack'in rolü ve "gölge alan"

x64 dünyasında (özellikle Windows x64) standart yaklaşım, ilk argümanların yazmaçlardan geçirilmesidir; ilk dört argüman için RCX/RDX/R8/R9 (tamsayı/pointer) ve XMM0 — XMM3 (kayan nokta) gibi düzenler kullanılır; kalan argümanlar stack'e taşar.

Aynı çağrı, farklı platform/derleyici seçeneklerinde farklı yerleşim üretebilir. Bu yüzden "hangi yazmaç hangi argüman" bilgisi tek başına yeterli değildir; doğrulama disiplini gerekir:

• Decompiler "2 argüman" diyorsa, çağrı noktasında gerçekten iki değer mi hazırlanıyor, yoksa üçüncü bir değer farklı bir kanaldan (yazmaç/stack) taşınıyor mu?
• "Pointer gibi" görünen argüman hiç dereference edilmiyorsa, handle/indeks/değer olma ihtimalini canlı tut.
• Dönüş değeri sadece bir koşulda mı kullanılıyor, yoksa aritmetik/ofset/indeks bağlamlarına da giriyor mu?

Örnek: Bir fonksiyon çağrısı sonrası dönen değer önce "sıfır mı?" diye kontrol ediliyor; bu, durum kodu yorumunu güçlendirebilir. Fakat aynı değer birkaç blok sonra bir tablo indeksinde veya bellek ofset hesabında görünüyorsa, "başarı/başarısızlık" yorumu zayıflar; uzunluk/indeks/kimlik gibi anlamlar daha olası hâle gelir. Rapor cümlesi de kesinlik tonunu buna göre ayarlamalıdır.

Windows x64'te ayrıca çağrı yapan tarafın, callee'nin gerekirse kaydedebilmesi için "dört yazmaç argümanı"na yetecek bir shadow store ayırma zorunluluğu vardır. Bu alan pratikte 4×8 bayt = 32 bayt olarak düşünülür; bazı durumlarda derleyici yazmaçtaki argümanı bu alana geri yazıp (spill) daha sonra buradan okuyabilir. Bu "yankı", özellikle akış içinde yazmaçlar yeniden kullanıldığında argümanın izini güçlendiren bir delil kaynağı olabilir.

Dikkat: "Tek sinyalle karar verme" (sadece decompile imzası, sadece bir yazmaç, sadece bir karşılaştırma) ileri seviyede en yaygın düşüştür. Sağlam doğrulama en az iki bağımsız işaret arar: çağrı hazırlığı + kullanım bağlamı; ya da kontrol akışı + gözlemlenebilir yan etki gibi.

İpucu: Dönüş değerini rapora "durum kodu" diye yazmadan önce, dönüş değerinin sonraki birkaç kullanımını (3 — 5 temas noktası) hızlıca tarayın. Sadece koşullarda kalıyorsa durum kodu ihtimali artar; ofset/aritmetik/indeks bağlamlarına giriyorsa uzunluk/indeks ihtimalini ciddi biçimde masada tutun.

1.2. x86'da "stack temizliği" sinyali: ret imm ve temkinli yorum

x86 ekosisteminde bazı çağrı sözleşmeleri "callee stack temizliği" izini bırakabilir; örneğin dönüşte ret imm benzeri bir desen, çağrılan tarafın belirli bir argüman alanını temizlediğine işaret edebilir. Ancak bu tür ipuçları tek başına "hangi calling convention" sorusunu kesin kapatmaya yetmez: derleyici optimizasyonları, thunk/stub yapıları ve farklı prototip türleri aynı yüzeyi üretebilir.

Bu yüzden yaklaşım şudur: "ret imm gördüm → şu kesin" demek yerine, çağrı sitesinde argümanların nasıl yerleştirildiğini ve çağrı sonrası stack dengesinin nasıl korunduğunu birlikte okuyup hipotezi sınamak; hipotezi çürütecek karşı kanıtları aktif aramak.

2) Stack frame analizi ve parametre takibi: Fonksiyonun çalışma masası

Stack frame, fonksiyonun yerel değişkenleri, kaydedilmiş yazmaçları ve çağrı bağlamını düzenleyen çerçevedir. Analist açısından stack yalnızca "değişkenlerin durduğu yer" değildir; veri yaşam döngüsünün iz bırakabildiği bir yüzeydir: bir değer çağrıdan gelir, yerel alana kopyalanır, dönüştürülür, başka çağrılara taşınır; tüm bu izler raporda delile dönüşebilir.

Neden önemli? Çünkü parametre takibi, sadece "hangi yazmaçta ne var" sorusu değildir. Bir argüman stack'e kopyalanabilir, bir struct/array parçası gibi dilimlenebilir, farklı ofsetlerde yeniden ortaya çıkabilir. Decompiler'ın "var_xx" tahminleriyle gerçek bellek düzeni arasında uyuşmazlık olduğunda, ileri seviye analistin güvenli zemini stack frame okuryazarlığıdır.

2.1. RSP/RBP dinamiği: "gözlem cümlesi" yazabilmek

Stack erişimleri çoğunlukla "taban + ofset" mantığıyla görünür. Bu, rapor dili açısından çok kıymetlidir çünkü denetlenebilir cümle kurdurur: "şu ofsete yazıldı, sonra şu çağrının şu argümanında göründü, sonra şu koşulda kontrol edildi."

Örnek: Bir yerel alana yazılan değer, kısa süre sonra bir veri dönüştürme fonksiyonuna giden yolda kullanılıyor. "Bu kesin anahtardır" demek yorumdur. Gözlem ise şudur: değerin hangi blokta üretildiği, hangi ofsete yazıldığı, hangi çağrıda argüman olarak kullanıldığı ve sonuçta hangi dış etkiye (dosyaya yazım, ağ paketine ekleme, bellek kopyası) bağlandığı. Bu zincir kurulmadan yapılan erken etiketleme, raporun kanıt gücünü düşürür.

Kanıt üretiminde en temiz ayrım:

• Gözlem: "Fonksiyon girişinden sonra X ofsetine kopyalanıyor; daha sonra Y çağrısının ikinci argümanına taşınıyor."
• Yorum: "Bu örüntü, değerin uzunluk/kimlik/anahtar olabileceğini düşündürüyor."
• Karşı kanıt arama: "Eğer uzunluk olsaydı, bellek kopyalama/karşılaştırma noktalarında tutarlı görünmesi beklenirdi; fakat sadece durum kontrolünde görünüyorsa uzunluk yorumu zayıflar."

2.2. Aynı ofset, farklı değişken: optimizasyonun paylaştırma oyunu

Optimizasyon seviyesi yükseldikçe derleyici, yaşam döngüsü çakışmayan değişkenleri aynı stack slot'ta yeniden kullanabilir. Decompiler bunu "karışmış değişken" gibi gösterebilir; analistin de "bu ofset hep aynı değişken" varsayımına kapılması kolaydır.

Neden önemli? Çünkü bu varsayım veri akışı zincirini kırar; aynı ofsetten okunan değerler aslında farklı zamanlarda farklı rol oynayabilir. Sağlam doğrulama için "ofsetin kimliği" değil, "değerin bağlamı ve kullanım örüntüsü" izlenir:

• Aynı ofsetten okunan değerler aynı dönüşüm zincirine mi gidiyor?
• Farklı akışlarda farklı çağrılara mı akıyor?
• Bazı yollarda indeksleme, bazı yollarda durum kontrolü gibi farklı roller mi üstleniyor?

Dikkat: Decompiler'ın ürettiği geçici değişkenlere (var_xx) çok erken "uzunluk/anahtar/IP" gibi isimler vermek, domino etkisiyle tüm analizi yanlış yöne sürükler. İsimlendirme, kanıtın yerine geçmez; kanıtı okunur kılmak için en sonda gelir.

İpucu: Raporu "itiraza dayanıklı" kılmak için her kritik iddiada üçlüyü birlikte verin: (1) gözlemin bağlamı (hangi fonksiyon/blok), (2) yazmaç/ofset referansı, (3) sonraki kullanım noktası (hangi çağrıda/koşulda anlam kazandığı). Bu üçlü, yorumu denetlenebilir hâle getirir.

3) Derleyici optimizasyonları: okunabilirlik illüzyonlarını fark et ve yöntemini değiştir

Derleyici optimizasyonları performansı artırırken, insanın kolay okuduğu yapıları bozabilir: inline, koşul terslemeleri/birleştirmeleri, döngü dönüşümleri (unroll vb.), frame pointer'ın kaldırılması, leaf fonksiyonların stack açmaması... x64 dünyasında ayrıca ABI'nin "volatile/non-volatile" yazmaç ayrımı ve unwind gereksinimleri, prolog/epilog yapısını da belirli kısıtlarla şekillendirir.

Neden önemli? Çünkü optimize edilmiş ikililerde decompile çıktısı "çok temiz" bir hikâye anlatabilir ve bu temelsiz bir güven üretir. İleri seviye analistin hedefi estetik anlatı değil; sınırları açık, çürütülemeyen ve kanıtla taşınan anlatıdır.

3.1. FPO ve leaf function: "stack'e bakma" refleksini yeniden ayarla

Frame pointer kullanılmadığında (FPO), sabit RBP-ofset okuma rahatlığı kaybolur; erişimler daha çok RSP-relative kayar. Leaf fonksiyonlarda ise başka fonksiyon çağrısı olmadığından ve stack alanı minimal olabildiğinden, veri çoğu zaman yazmaçlarda yaşar; stack'te "iz" aramak her zaman verimli değildir.

Yöntem seçimi burada kritikleşir:

• Hızlı triage: decompile ile genel haritayı çıkar; ama FPO/leaf sinyali görür görmez "decompile değişkenleri"ne aşırı güveni düşür.
• Kanıt standardı yüksek çalışma: kritik iddialarda veri akışını (yazmaç + bellek) birlikte izleyen, çürütücü karşı kanıtları hedefleyen daha sıkı bir okuma seç.

Bu temelin kontrol listesini Orta Seviye ilgili modülde ayrıntılı işlemiştik; burada ileri analiz açısından kritik olan, optimizasyonu fark eder etmez yöntemini değiştirebilme refleksidir.

3.2. LEA ve aritmetik optimizasyonlar: "karmaşık görünen" her şey karmaşık değildir

Bazı talimat dizileri, decompile'da "garip formül" gibi görünür; oysa derleyici daha hızlı aritmetik üretmek için LEA benzeri talimatları matematikte kullanıyor olabilir. Bu noktada güvenli yaklaşım, "bu kesin obfuscation/crypto" gibi ağır yorumlara atlamadan önce çıktının nereye gittiğini izlemektir.

Örnek: Bir döngü içinde adres hesaplar gibi görünen bir dizinin çıktısı sadece tablo indeksine gidiyorsa, veri dönüşümü/şifreleme yorumu zayıflar. Aynı çıktı, bir tamponu sistematik biçimde değiştirip dış etkileşimden önce son hâlini aldırıyorsa, "dönüşüm" yorumu güçlenir. Buradaki farkı yaratan, talimatın şekli değil, kullanım bağlamıdır.

4) Dolaylı dallanma ve exception/unwind akışları: kaçırılan yollar, saklanan davranışlar

Kod her zaman doğrusal ilerlemez. Switch-case yapıları jump table ile yürüyebilir; çağrılar dolaylı pointer'larla yapılabilir; exception/unwind yolları ise "normal" kontrol akışına paralel, ayrı bir yürütme düzlemi oluşturabilir.

Neden önemli? Çünkü şüpheli davranışlar bazen "nadiren seçilen bir dal"da ya da hata/istisna yolunda saklıdır. Bu yolları atlamak, davranışın kritik parçasını kaçırmak demektir.

4.1. Jump table ve indirect call: hedef belirsizse kanıt dili değişir

Jump table'da bir indeks hesaplanır, bir hedef tablosundan adres seçilir ve akış o adrese yönelir. Indirect call'da ise çağrılacak adres bellekten okunur; hedef, bağlama göre değişebilir.

Doğrulama disiplini:

• İndeksin kaynağı nedir: parametre mi, global durum mu, hesaplanmış bir değer mi?
• Hedeflerin hepsi gerçekten ulaşılabilir mi, yoksa bazıları "ölü/yanıltıcı" mı?
• Dolaylı çağrıda pointer'ın kaynağı farklı akışlarda farklı adreslere mi bağlanıyor?

Kanıt üretimi: "Switch var" demek yerine, seçici değerin üretim zincirini ve hangi koşullarla hangi hedef sınıfına yöneldiğini raporlamak daha güçlüdür. Bu, itiraz geldiğinde "hangi sinyalle bu sonuca vardın?" sorusuna net yanıt verir.

4.2. Exception/unwind akışı: temizlik mi, alternatif davranış mı?

Exception/unwind yolları bazen masum "temizlik"tir: kaynak kapatma, hata kodu standardizasyonu, geri dönüş hazırlığı... Bazen de akışı beklenmedik bir yola taşır ve davranışın kritik kısmı orada yaşar.

Doğrulama ve karşı kanıt:

• Handler yolunda sadece kaynak kapatma ve kontrollü geri dönüş sinyalleri varsa "temizlik" yorumu güçlenir.
• Handler yolunda dosya/ağ gibi dış etkileşim üreten çağrılar veya kritik veri dönüşümleri görünüyorsa "alternatif davranış" ihtimali ciddileşir.

Yöntem seçimi: Sadece "CALL/JMP zinciri" ile akış okumak, bazı istisna yollarını görünmez kılabilir. Bu riski azaltan zihinsel model, akışı iki katmanlı düşünmektir: normal yol + istisna yolu. Böylece "ana akış temiz" göründüğünde bile, nadir yollarda davranış saklanma ihtimali gözden kaçmaz.

Dikkat: İstisna akışını otomatik olarak "anti-analiz" diye etiketlemek de hatalıdır. Kanıt standardı, niyeti değil; gözlemlenebilir akışın etkisini ve tekrar üretilebilir izlerini temellendirir.

İpucu: İstisna akışını rapora koyarken iki ankrajı sabitleyin: istisnanın tetiklendiği yürütme noktası (instruction pointer bağlamı) ve kontrolün geçtiği handler yolunun bağlamı. Bu ikili, zaman çizelgesinde "nerede koptu, nerede devam etti" sorusunu kanıtla cevaplar.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• ABI/calling convention okuryazarlığının, parametre ve dönüş değerini doğru okumada “doğruluk omurgası” olduğunu.
• Decompile imzasının “hipotez” olduğunu; kritik iddiaların çağrı hazırlığı ve kullanım bağlamıyla doğrulanması gerektiğini.
• Stack frame okuryazarlığıyla yerel değişken/argüman yerleşimini kanıtlanabilir biçimde izlemeyi; erken isimlendirme tuzağından kaçınmayı.
• Shadow store gibi ABI detaylarının, yazmaç–stack ilişkisini doğrulama ve kanıt üretimi için nasıl fırsata çevrilebileceğini.
• FPO/leaf/inline/döngü dönüşümleri gibi optimizasyonların ürettiği yanılsamaları fark edip yöntemi koşula göre seçmeyi.
• Jump table, indirect call ve exception/unwind yollarında “nadiren seçilen” akışları sistematik biçimde haritalandırmayı.
• Bulguyu rapora taşırken gözlem–yorum ayrımını koruyup, adres/ofset bağlamı ve yeniden üretilebilirlikle delil standardı kurmayı.

Modül 4 — İşletim Sistemi İç Yapısı ve Yürütme Modeli

Bir zararlı örneği anlamak, yalnızca "hangi dosyaları oluşturdu, nereye bağlandı?" listesini çıkarmak değildir; bu davranışların işletim sisteminin hangi mekanizmaları üzerinden mümkün olduğunu görebilmektir. Bu modülde Windows yürütme modelini tek bir hikâye gibi okuruz: loader'ın (yükleyici) bir imajı adres alanına yerleştirmesinden, süreç ve thread'in "iç kimlik kartları" olan PEB/TEB yapılarına, sanal bellek ve sayfa korumalarına ve en altta ntdll — syscall sınırına kadar. Hedef, sezgiyle hüküm vermek değil; bulguyu doğrulamak, karşı kanıt aramak ve raporda yeniden denetlenebilir bir kanıt zinciri kurmaktır.

1) Loader davranışı ve modül çözümleme

Bir süreç başlatıldığında Windows, dosyayı "okuyup çalıştırmakla" kalmaz: imajı adres alanına map eder, bağımlılıkları çözer, import bağlamasını yapar, gerekiyorsa relocation uygular ve bazı erken yürütme noktalarını devreye sokar (örneğin TLS callback gibi mekanizmalar, ana giriş noktasından önce çalışabilir). Bu zinciri okumak iki şey kazandırır:

1. — Davranışın hangi aşamada ortaya çıktığını görürsün.
2. — Aynı davranışın "normal yükleme" ile mi yoksa "olağandışı bellek/modül örüntüsü" ile mi üretildiğini doğrulamaya başlarsın.

1.1. PE loader'ın pratikte bıraktığı izler

Loader'ın izi tek bir "log satırı" değildir; farklı katmanlarda bir araya gelince güçlenir:

• İmaj haritalama ve adresleme: ASLR nedeniyle aynı ikili farklı çalıştırmalarda farklı taban adreslere yerleşebilir. Bu yüzden "şu adreste vardı" ifadesi tek başına zayıf kanıttır; güçlü olan, imajın image-mapped karakterini ve zaman bağlamını gösterebilmektir.
• Import çözümleme (IAT bağlama): Import tablosu loader'ın "alışveriş listesi" gibidir; ama bazı yazılımlar bu listeyi minimumda tutar, bazıları delay-load kullanır, bazıları da runtime'da dinamik çözümleme yapar. Burada kritik refleks: "import yok" sonucunu hükme çevirmeden önce, aynı iddiayı çalışma zamanı sinyalleri ile sınamaktır.
• Section/koruma mantığı: Loader, bölüm (section) özelliklerine göre sayfa korumaları uygular (kod/data ayrımı). Bir bölge "kod gibi" davranıyorsa ama beklenen bölüm modeliyle uyuşmuyorsa şüphe doğabilir; yine de JIT üreten meşru bileşenler gibi karşı olasılıkları özellikle aramak gerekir.

Örnek: Bir "belge görüntüleyici" işleminde statik importlar sakin görünürken çalışma anında kriptografi ve ağ yığınıyla ilişkili modüller yükleniyor, hemen ardından dış bağlantılar başlıyorsa; "yükleme → bağlantı" sıralamasını aynı zaman penceresinde göstermek rapor için güçlü delil seti üretir.

Yöntem seçimi (bu aşamada neye yaslanırsın?)

• Sadece dosya varsa: import tablosu + section modeli iyi başlangıçtır; ama nihai hüküm için yeterli değildir.
• Telemetri (EDR/ETW/SIEM) varsa: modül yükleme olaylarını, thread başlangıçlarını ve ağ/dosya davranışını zaman çizelgesinde korele etmek kanıt gücünü yükseltir.
• Bellek dökümü varsa: modül listesi ile bellek haritasını birlikte okuyup "disk izi olan imaj mı, yoksa private/mapped bir bölge mi?" ayrımını güçlendirirsin.

Dikkat: "Import tablosu temiz → ağ yeteneği yok" gibi kesin cümleler ileri analizde sık hata üretir. "Görünür import yok" ile "yetenek yok" aynı şey değildir; aradaki boşluğu runtime sinyalleriyle doldurmadıkça kanıt standardı zayıf kalır.

1.2. "Yüklemek" ile "bulmak" aynı şey değildir: modül + sembol çözümleme

Modül çözümlemeyi iki parçalı düşünmek işini kolaylaştırır:

• Bir DLL'in sürece yüklenmesi
• Yüklenen modül içinden bir fonksiyonun/isimli sembolün çözülmesi (runtime resolving)

Bir süreçte modül yüklenmesi çoğu zaman meşrudur; şüphe, örün­tü + bağlam + zaman birleşince doğar:

• UI odaklı bir süreçte kısa sürede çok sayıda sistem DLL'inin yüklenmesi ve hemen ardından ağ/dosya davranışının başlaması gibi zincirler,
• "Kullanıcı etkileşimi yokken" belirli API ailelerine yönelim gösteren modül yükleme paternleri.

Doğrulama refleksi (karşı kanıt arama):

• "Beklenmedik" dediğin modül gerçekten beklenmedik mi? Uygulamanın eklenti sistemi, güncelleme bileşeni, yazıcı sürücüsü entegrasyonu veya güvenlik ajanı gibi meşru nedenleri özellikle kontrol et.
• Modül yükleme iddiasını mümkünse iki perspektiften doğrula: süreç içi modül görünümü + telemetri veya bellek haritası gibi.

Kanıtı rapora paketleme:

• Sadece "modül listesi" koymak yerine "hangi süreçte, hangi zaman aralığında, yükleme öncesi/sonrası davranış farkı ne?" sorularını tek parçaya bağla.
• Aynı olay tekrar gözlenebildiyse, tetik koşullarını yaz (dosya açılması, belirli bir süre sonra tetiklenme, kullanıcı etkileşimi olup olmaması). Bu, raporu denetlenebilir kılar.

2) PEB/TEB ve süreç içi veri yapıları

Telemetri "dışarıdan gözlem" sunar; PEB/TEB ise sürecin/thread'in işletim sistemi tarafından tutulan iç meta verisini verir. PEB (Process Environment Block) süreç düzeyinde; TEB (Thread Environment Block) thread düzeyinde kritik ipuçları taşır. Bu iç bakış, özellikle "süreç aslında nasıl başladı?", "hangi modüller gerçekten devrede?" gibi sorularda hızlı hipotez kurdurur.

2.1. PEB: süreç parametreleri ve loader verisi

PEB içinde analist için pratik değeri yüksek alanlar:

• Süreç parametreleri (komut satırı, çalışma dizini, imaj bağlamı): "Bu süreç burada ne arıyordu?" sorusunu güçlendirir.
• LoaderData ve modül listeleri: "Modül var mı/yok mu?" tartışmalarında ilk referans noktasıdır.

Örnek: Telemetride görünen başlatma argümanlarıyla süreç içi parametreler uyumlu değilse iki olasılık öne çıkar: telemetri eksiktir ya da süreç içi yapıların manipüle edildiği ihtimali vardır. İleri seviye dil, "kesin manipülasyon" değil, "uyumsuzluk sinyali" diye başlar ve doğrulama adımını açıkça yazar.

2.2. TEB: thread bağlamı, TLS ve istisna zinciri (SEH)

TEB, thread'in kimliği, TLS alanları ve istisna işleme gibi mekanizmalarla ilişkilidir. Bazı davranışlar süreçten çok thread seviyesinde ayrışır: aynı süreçte farklı thread'ler farklı roller üstlenir.

• Aynı zaman penceresinde başlayan thread'lerin davranışı, "şüpheli yürütme nereden çıktı?" sorusuna yaklaşırken değerlidir.
• TLS meşru yazılımlarda da çok yaygındır; ancak şüpheli bellek bölgeleriyle birlikte bazı thread'lerin belirli lokal veriyi sürekli taşıması, davranış izini güçlendirebilir.
• SEH/istisna zinciri ile ilgili anormallikler (beklenmedik istisnalarla kontrol akışı oluşturma gibi) bazen kontrol akışını anlamayı zorlaştırır; burada "API'de görünmüyor" demek yerine, ilgili thread bağlamını açıklayan kanıtlara yönelmek gerekir.

İpucu: PEB/TEB tabanlı bulguları rapora koyarken "gözlem" ile "yorum"u ayır. "Şu yapıdaki alan şu değeri taşıyor" gözlemdir; "bu, manipülasyon olabilir" yorumdur. Yorumun yanına hangi karşı kanıtı aradığını yazmak, raporu profesyonel seviyeye taşır.

2.3. PEB/TEB tek başına neden yetmez?

İleri seviyede kritik refleks şudur: PEB/TEB "içeriden bakış" verir; içeriden bakış her zaman güvenilir kabul edilemez. Bu yüzden yöntem seçimi ve doğrulama birlikte yürür:

• PEB/TEB hızlı hipotez kurdurur.
• Bellek haritası/region analizi "dışsal gerçeklik" sunar: "Listede yok ama bellekte var mı?" sorusunu güçlendirir.
• Telemetri olayın zaman boyutunu taşır: "Ne zaman oldu?" sorusunu delillendirir.

Bu başlıkta sık karşılaşılan bir örüntü de şudur: bazı örnekler analiz ortamını anlamak için süreç içi işaretleri (ör. BeingDebugged gibi bayraklar) okuyabilir. Bunun analiste anlamı "kaçınma tekniği nasıl yapılır?" değil; davranışın bağlamını doğru kurmaktır: "Bu örnek, çalışma ortamı sinyallerine duyarlı olabilir; bu yüzden gözlenen davranışların tekrar üretilebilirlik notu özellikle önem kazanır."

Ek teknik not: TEB, mimariye göre segment tabanlı erişimle ilişkilidir; 32-bit Windows'ta FS, 64-bit Windows'ta GS thread yapısına işaret eder ve PEB işaretçisi TEB içinden alınır.

Dikkat: PEB/TEB verisini "mutlak gerçek" gibi rapora yazmak, yanlış kesinlik üretir. Özellikle yüksek riskli çıkarımlarda en az bir çapraz doğrulama çizgisi ekle (bellek region görünümü, telemetri korelasyonu, bütünlük/anomali sinyalleri gibi).

3) Sanal bellek ve sayfa koruma analizi

Sanal bellek, süreç adres alanının "haritasıdır": image-mapped bölgeler, memory-mapped file bölgeleri, heap/stack ve private allocation aynı evrende yaşar. İleri analizde hata genellikle şuradan doğar: tek bir sinyali görüp (ör. "RWX var") hemen hükme gitmek. Doğru yaklaşım "sinyal + bağlam + karşı kanıt" üçlüsüdür.

3.1. Bölge türleri: image / mapped / private

• Image-mapped: Genellikle loader'ın bir PE imajını map etmesiyle ilişkilidir.
• Mapped file: Bir dosyanın belleğe haritalanmasıdır; tarayıcı cache'i, büyük dosya işleme, veritabanı motorları gibi meşru yazılımlarda sık görülür.
• Private memory: Dosyaya bağlı olmayan ayrılmış bellek. Bazı bellek içi davranışlar burada iz bırakabilir; ama tek başına "kötü" değildir.

Örnek: Bir süreçte executable özellikli private bölgeler görülüyor ve aynı zaman penceresinde beklenmedik thread başlangıçları oluşuyor; üstelik bu thread başlangıç adresleri bilinen bir modülün kod bölümüne değil de bu private bölgeye yakınsa şüphe artar. Buna karşı kanıt olarak, süreçte JIT/çalışma zamanı kod üretimi yapan meşru bileşenlerin olup olmadığı ve bellek örüntüsünün onlarla uyumu aranır.

3.2. Sayfa korumaları: R/W/X, RWX ve guard page

Sayfa korumaları bir bölgenin nasıl kullanılacağını belirler: okunabilir (R), yazılabilir (W), yürütülebilir (X). Önemli nokta, korumaların zaman içinde değişebilmesidir; bazı akışlar "hazırlık → yürütme" izleri bırakır.

• RWX çok konuşulur çünkü risklidir; ancak tek başına suç değildir. Tarayıcılar, oyun anti-cheat bileşenleri, bazı EDR/sürümleme mekanizmaları ve runtime ortamları sıra dışı ama meşru örüntüler üretebilir.
• RX kod bölgelerinde beklenen görünümdür.
• Guard page bazen stack büyümesi ve istisna üretimi gibi amaçlarla devrededir; "tuhaf" görünmesi normaldir.

Bu noktada DEP/ASLR gibi korumaların "ne yaptığı" değil, analist için "ne tür yanılgı ürettiği" önem kazanır: adreslerin değişmesi, anlık snapshot'ın bağlamdan kopması veya meşru runtime'ların "saldırı gibi görünen" bellek modelleri üretmesi.

İpucu: Bellek bulgularını zaman çizelgesine koyduğunda okunurluk dramatik biçimde artar: "Önce yeni executable private bölge → sonra yeni thread → sonra ilk dış bağlantı" sıralaması, tek tek bulguların toplamından daha ikna edicidir ve denetlenebilirlik sağlar.

3.3. "Şüpheli bellek" iddiasını delile dönüştürmek

"Şüpheli region gördüm" rapor cümlesi değildir; delil paketinin bileşenleri olmalıdır:

• Bölgenin türü (private/mapped/image)
• Bölgenin koruması (RX/RWX/guard vb.) ve mümkünse zaman içindeki değişim
• Bölgeyle ilişkili thread davranışı (başlangıç adresi bağlamı, zaman penceresi)
• Modül yükleme/çözümleme ile korelasyon (yükleme → davranış zinciri)
• Karşı kanıt araması (JIT/runtime, bilinen bileşen örüntüleri, meşru senaryo uyumu)
• Sınırlılıklar (eksik log, gözlem penceresi, ortam çeşitliliği)

Dikkat: "RWX gördüm, kesin zararlı" refleksi ileri analizde en sık yanlış alarm (false positive) üreten alışkanlıklardandır. Kanıt gücünü yükseltmeden kesin hüküm yazmak, raporun güvenilirliğini zedeler.

4) Syscall ve ntdll rolü: "gerçek temas noktası"nı görmek

Kullanıcı modunda gördüğün pek çok API çağrısı, daha altta ntdll üzerinden çekirdeğe uzanan bir zincirin üst katmanıdır. ntdll, kullanıcı modu ile çekirdek arasındaki sınırda merkezi bir rol taşır; bu yüzden bazı durumlarda üst katman API'ler eksik görünse bile alt katmanda daha tutarlı sinyaller bulunabilir.

4.1. ntdll neden merkezi?

Önemli olan tek tek fonksiyon isimlerini ezberlemek değil, şunu kavramaktır:

• Davranış "Win32 API" gibi görünse bile çekirdeğe giden yol çoğu zaman ntdll'den geçer.
• Bazı meşru yazılımlar performans veya mimari nedeniyle daha düşük seviyeyi kullanabilir; bu, otomatik olarak kötü niyet değildir.

Örnek: Bir süreçte dosya sistemiyle temas eden bir davranış üst katman telemetrilerinde eksik görünürken, alt seviyede tutarlı sinyaller varsa; raporda "görünmüyor" yerine "üst katmanda sınırlı görünürken alt katmanda korele sinyaller bulunuyor" dilini kurmak kanıt gücünü artırır.

4.2. Syscall sınırında doğrulama ve yorum riskleri

Syscall düzeyi güçlüdür çünkü çekirdeğe temas eden "asıl eylem" burada belirginleşir; risklidir çünkü:

• Windows sürüm farklılıkları,
• WoW64 gibi uyumluluk katmanları,
• Telemetri eksikleri

yanlış yorum riskini yükseltir.

Bu yüzden syscall/ntdll ile ilgili iddialarda yöntem seçimi belirleyicidir:

• Ortam çeşitliliği yüksekse, tek gözleme dayanma; dosya/ağ izleri, bellek korelasyonu ve olay zaman çizelgesini birlikte kullan.
• ntdll bütünlüğüyle ilgili bir şüphe varsa, dili "kesin manipülasyon" değil "uyumsuzluk sinyali" ekseninde kur; kanıt düzeyine uygun ifadeyi seç.

4.3. "Alt katman bulgusu"nu rapora koymak

Teknik bir ayrıntıyı operasyonel delile çevirmek için:

• Bulguyu hangi kaynaktan aldığını net yaz (bellek dökümü, telemetri, runtime gözlem).
• Aynı iddiayı destekleyen ikinci bir sinyal ekle (modül yükleme korelasyonu, dosya/ağ izi, thread bağlamı).
• Sınırlılıkları açık yaz (sürüm farkı, eksik log, gözlem penceresi).
• Mümkünse yeniden gözlenebilirlik notu ekle: "hangi koşulda tetiklendi, aynı pencerede tekrarlandı mı?"

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Loader zincirini “yürütmenin başlangıcı” olarak okuyup modül yükleme ile davranış başlangıcını kanıt zinciri içinde ilişkilendirdin.
• PEB/TEB üzerinden süreç ve thread bağlamını çıkarırken tek kaynağa kör güvenmek yerine çapraz doğrulama refleksi kazandın.
• Sanal bellek bölge türleri ve sayfa korumalarını bağlamla yorumlayıp “şüpheli bellek” iddiasını delillendirmeyi öğrendin.
• ntdll ve syscall sınırını “gerçek temas noktası” olarak konumlandırıp sürüm/katman farklarının yorum risklerini yönetmeyi gördün.
• Bulguları gözlem–yorum ayrımıyla, zaman çizelgesi ve sınırlılık notlarıyla rapora paketlemeyi pekiştirdin.

Modül 6 — Debugging ve Davranış-Kod Eşleme

Statik analiz, bir örneğin "iskeletini" çıkarır; ama bazı kritik cevaplar ancak çalışma zamanında (runtime) ortaya çıkan değerlerde saklıdır. Bu modülde debugging'i bir "durdur--bak" pratiği olmaktan çıkarıp, davranışı belirli bir kod yoluna ve koşula bağlayan, denetlenebilir kanıt üreten bir disipline dönüştürüyoruz. Hedef; statik hipotezleri dinamik gözlemle eşleştirirken doğru yerde ölçmek, ölçtüğünüz şeyi de raporda tekrar üretilebilir bir delil paketine dönüştürmek — üstelik bunu yaparken gözlemci etkisini (analiz ortamının davranışı bozması) yönetebilmektir.

1. Breakpoint türleri ve stratejik kullanımı

Debugging'de en pahalı hata, yanlış yerde durup doğru yerde duramadığınız için yanlış sonuç çıkarmaktır. Bu yüzden breakpoint seçimi, "hangi aracı kullandın?" sorusundan çok "hangi hipotezi hangi maliyetle test ettin?" sorusuna cevap vermelidir. İyi bir ölçüm noktası üç şeyi birlikte taşır: tetik (ne zaman duracağım), bağlam (durduğum anda neyi toplayacağım), etki (topladığım veri neyi ispatlar/çürütür).

1.1. Yazılımsal breakpoint: görünür ama müdahaleci

Yazılımsal breakpoint'ler genellikle hedef adresteki kod akışına geçici bir kesme talimatı (ör. INT3 / 0xCC) yerleştirilmesi mantığıyla çalışır. Bu yaklaşımın cazibesi hızlı kurulumdur; riski ise "ölçtüğünüz şeyi değiştirme" ihtimalidir. Zamanlama hassas örneklerde veya bütünlük kontrolü (integrity check) yapan yapılarda, bu küçük değişiklik bile davranışın farklı bir dala sapmasına neden olabilir.

• Ne zaman mantıklı? Hedeflediğiniz nokta nettir ve oraya gidişin "olayla aynı şey" olduğundan emin olabileceğiniz başka işaretler (çağrı zinciri, argüman örüntüsü, yan etki öncesi bağlam) vardır.
• Doğrulama refleksi: Bir defalık duruşu "tesadüf" olasılığından ayırın. Aynı noktanın farklı koşullarda tetiklenip tetiklenmediğini, çağrı yığını (call stack) ve argüman deseni üzerinden sınayın.
• Karşı kanıt: Aynı durak, hata toparlama yolu veya telemetri/log yolu gibi farklı amaçlarla da tetikleniyorsa, "tek bir kritik yol" iddiası kurmak zayıflar; raporda ayrım yapılmalıdır.

Örnek: Bir davranış iddiası "belirli bir dosya oluşturuluyor" olsun. Aynı dosya oluşturma çağrısı kimi zaman sadece hata log'u üretmek için de tetiklenebilir. Duruş anında çağrı zincirini (hangi koşul dalından geldiğini) ve dönüş değerinin sonraki adımlarda nasıl tüketildiğini gözlemlemek, davranışın "amaç" kısmını kanıta yaklaştırır.

Dikkat: Breakpoint yoğunluğu, özellikle ağ zaman aşımı/retry gibi zamanla ilgili mantıkları tetikleyerek davranışı bozabilir. Bu nedenle raporda "debug ortamında gözlendi" gibi bağlam notu, bulgunun güvenilirliğini artırır; yazılmazsa yanlış kesinlik riski büyür.

1.2. Donanımsal breakpoint: daha az iz bırakan, daha sınırlı

Donanımsal breakpoint'ler işlemcinin hata ayıklama kayıtlarını (ör. DR0 — DR7) kullanarak izleme yapar; kod üzerinde bayt düzeyinde bir değişiklik gerektirmez. Bu, bazı bütünlük kontrollerinin tetiklenmesini daha az olası kılar; ancak sayıca sınırlı olması ve kullanım senaryolarının kısıtları vardır (pratikte az sayıda izleme noktası).

• Ne zaman mantıklı? Kod bütünlüğünün kontrol edildiğinden şüpheleniyorsanız veya müdahale riskini düşürmek istiyorsanız.
• Doğrulama refleksi: Erişim "gürültü" üretiyorsa korelasyon arayın: erişimden hemen sonra hangi dallanma çalıştı, hangi API çağrıları başladı, hangi yan etki görüldü?
• Karşı kanıt: Aynı adrese runtime/kütüphane kodları da dokunuyor olabilir; "dokunuldu" bilgisini "kim dokundu ve neden?" sorusuna bağlamadan hüküm vermeyin.

1.3. Bellek tabanlı duraklar: erişim ve koruma değişimlerini ölçmek

Bazı örneklerde kritik sinyal "hangi fonksiyon çağrıldı?" değil, bellekte ne değişti? sorusudur. Örneğin bir bölgenin yazılırken hemen ardından yürütülebilir (execute) hale gelmesi veya beklenmedik bir koruma değişimi, in-memory davranış iddialarını güçlendiren sinyaller üretebilir. Bu yaklaşım, "kod yolu belirsiz ama bellek olayı belirgin" senaryolarda daha iyi bir başlangıç noktasıdır.

• Ne zaman mantıklı? In-memory yürütme iddiası var ama doğrudan "hangi fonksiyon yaptı?" net değil.
• Doğrulama refleksi: Tek başına bellek olayı, modern runtime'lar nedeniyle yanlış pozitif üretebilir. Olayla eş zamanlı thread başlangıcı, modül yüklenmesi, beklenmedik ağ aktivitesi gibi ikinci bir sinyal arayın.
• Kanıt üretimi: Önce — sonra bağlamı zaman çizelgesinde toplamak, tek bir ekran görüntüsünden daha güçlü bir delildir.

Not (müfredat içi bağlantı): Paketli/çok aşamalı örneklerde bellek olayları, "asıl kodun görünür hale geldiği eşiği" yakalamaya yardım edebilir. Bu konuyu unpacking metodolojisiyle birlikte daha geniş çerçevede ayrıca ele alacağız; burada hedef, bellek olayını davranış — kod eşlemesi için bir kanıt düğümüne dönüştürmektir.

1.4. Koşullu breakpoint: gürültüyü azaltarak "kanıt anına" odaklanmak

Aynı API/fonksiyon binlerce kez çağrılıyorsa, her seferinde durmak hem zamanlamayı bozar hem de analisti gürültüye gömer. Koşullu duraklar; belirli argüman örüntüsü, belirli çağrı sayısı veya belirli bir bağlam oluştuğunda durarak hipotez testini hızlandırır.

• Ne zaman mantıklı? Yalnızca küçük bir çağrı alt kümesi sizi ilgilendiriyorsa.
• Doğrulama refleksi: Koşulu "çok dar" kurup kritik olayı kaçırmamak için önce geniş örüntü çıkarıp sonra daraltmak daha güvenilirdir.
• Karşı kanıt: Kurduğunuz koşul sadece "beklediğiniz" yolu yakalayıp alternatif dalları kaçırıyorsa, rapor dilini kesinlikten uzak tutun.

İpucu: Debugging planını bir harita gibi düşünün. Önce geniş yakalama noktalarıyla (yüksek seviyeli davranış düğümleri) yön bulun; sonra koşullu/odaklı duraklarla kritik argüman ve koşulu yakalayarak delili sıkıştırın. Bu, yanlış yerde ayrıntıya boğulmayı engeller.

2. Exception tabanlı kontrol ve anti-debug sinyalleri

Exception'lar sadece "hata" değildir; kimi yazılımlar kontrol akışını exception mekanizmaları üzerinden de yönetebilir. Bu yüzden bir exception görmek, otomatik olarak "anti-debug var" demek değildir. İleri seviyede farkı yaratan, exception'ı örüntü olarak okumak ve bunu davranış değişimiyle ilişkilendirmektir.

2.1. Exception: sinyal mi, yan ürün mü?

Aynı exception aynı noktada düzenli tekrarlanıyorsa bu, akış tasarımının bir parçası olabilir. Öte yandan exception sadece debugger altında belirginleşiyor veya sıklığı dramatik artıyorsa, analiz ortamının etkisi olasılığı yükselir. Burada karar verirken şu ayrım işinize yarar:

• Exception sonrası akış "hata toparlama" mı, yoksa "bilinçli dallanma" mı? Bunu exception sonrası çağrı zinciri ve yan etkilerle bağlayın.
• Aynı exception tetiklendiğinde bazen davranış gerçekleşip bazen gerçekleşmiyorsa, exception tek başına "tetik" olmayabilir; başka koşullar devrededir.

Örnek: Periyodik exception'lar oluşuyor ve program devam ediyor. Dış bağlantı denemeleri yalnızca exception sonrasında başlıyorsa, exception akışı bir "kapı" gibi çalışıyor olabilir. Karşı kanıt olarak, exception oluştuğu halde bağlantının başlamadığı tekrarlar aranır; varsa "exception tek başına tetik değil" sonucu güçlenir.

2.2. Anti-debug sinyallerini kanıt düzeyine taşımak

Anti-debug sinyallerini rapora taşırken niyet okumaya kaçmak kolaydır. Daha sağlam yaklaşım, sinyali sınıflandırıp davranış farkını gösterebilmektir:

• Zamanlama sapmaları: yürütme hızına duyarlı karar mekanizmaları (ör. döngüler, ölçüm noktaları)
• Exception/flow oyunları: beklenen exception'ı akış kapısı gibi kullanmak veya beklenmeyen koşulda farklı davranmak
• Ortam göstergeleri: analiz ortamında bazı kontrollerin farklı sonuç üretmesi

Burada güçlü rapor dili, "anti-debug var" demek yerine şunu yapar: Hangi koşulda hangi sinyal gözlendi, bu sinyal hangi kontrol dalını etkiledi, sonuçta hangi yan etki değişti?

Dikkat: Exception temelli akışlar meşru yazılımlarda da görülebilir (hata toparlama, korumalı çalışma, bazı optimizasyon örüntüleri). Sinyali davranış değişimiyle bağlamadan kesin hüküm yazmak, ileri analizde en sık yanlış pozitif üreten genellemedir.

2.3. Exception yoğun örneklerde yöntem seçimi

Exception'ların yoğun olduğu bir örnekte, klasik "şu fonksiyona dur" yaklaşımı verimsizleşebilir.

• Kontrol akışının ana kapısını bulmak istiyorsanız: handler etrafındaki dallanmalar ve handler sonrası kritik çağrılar önceliklenir.
• Anti-debug sinyalinin etkisini kanıtlamak istiyorsanız: exception öncesi — sonrası davranış farkı zaman çizelgesiyle toplanır.
• Ortam etkisini azaltmak istiyorsanız: daha az müdahaleci ölçüm noktaları tercih edilir; sık duruş, zamanlama sinyallerini bozabilir.

İpucu: Exception'ları "kırmızı alarm" gibi değil, "yön levhası" gibi okuyun. Exception çoğu zaman kritik eşik adreslerini işaret eder; asıl delil, o eşiğin ardından hangi yan etkinin oluştuğunu gösterebildiğinizde güçlenir.

3. API call tracing ve argüman analizi

API call tracing davranışı görünür kılar; ileri seviyede farkı yaratan, çağrıları listelemek değil, argüman — dönüş değeri — yan etki zincirini kurmaktır. Aynı API farklı argümanlarla tamamen farklı semantik taşıyabilir; bu yüzden argüman analizi davranış — kod eşlemenin belkemiğidir.

3.1. Trace'i olay listesi değil nedensellik zinciri olarak okumak

Her çağrı için şu üç soru, "log"u "kanıt"a yaklaştırır:

• Girdi nereden geldi? (config, hesaplanan değer, runtime'da çözülen veri)
• Çıktı ne oldu? (başarılı/başarısız, handle/nesne üretildi mi?)
• Bu çıktı nerede tüketildi? (sonraki çağrının parametresi mi oldu, bir dalı mı tetikledi?)

Örnek: example.net benzeri bir alan adı trace'de bir bağlantı çağrısına argüman oluyor. Güçlü delil, alan adının dosyada geçmesi değil; aynı değerle çözümleme/bağlantı denemesinin yapılması, dönüş değerinin tüketilmesi ve devamında görülen yan etki zinciridir. Karşı kanıt olarak, aynı değerin yalnızca log/telemetri akışında taşınması ihtimali değerlendirilir; dönüş değeri hiç tüketilmiyorsa "operasyonel kullanım" iddiası zayıflar.

3.2. Argüman analizi: kimliklendirme ve sınıflandırma

Argümanları "değer listesi" gibi değil, "anlam taşıyan kanıt parçaları" gibi sınıflandırmak işinizi hızlandırır:

• Kaynak argümanlar: dosya yolları, alan adları, örnek IP'ler (198.51.100.0/24 gibi dokümantasyon blokları), registry yolları, mutex isimleri
• Kontrol argümanları: bayraklar, modlar, erişim hakları, seçenek bitleri
• Bağlayıcı argümanlar: handle'lar, pointer'lar, context nesneleri

Bir argümanı rapora koyarken tek başına "ne"yi değil, "nasıl oluştu ve neyi değiştirdi"yi de anlatmanız gerekir. Aynı yolun farklı örneklerde tekrar yakalanabilmesi için, argümanın oluşma zinciri (formatlama/çözme/taşıma) önemli bir yeniden üretilebilirlik işaretidir.

3.3. Runtime'da çözülmüş veriyi yakalamak: kanıtın en temiz anı

Birçok örnek, disk üzerinde anlamlı değerleri gizler; değerler API çağrısından hemen önce bellekte çözülür. Bu yüzden "çağrı anı" (calling convention bağlamıyla birlikte) yüksek değerli bir kanıt penceresidir: x64'te bazı argümanlar register'lar üzerinden, devamı stack üzerinden taşınabilir; önemli olan, argümanların o anda "mutlak gerçeklik" olarak görülmesidir.

Örnek: Statik analizde bir ağ fonksiyonuna giden yol var; fakat hedef değer belirsiz. Dinamik izde çağrı anında bellekte çözülmüş hedefin 203.0.113.88 gibi dokümantasyon amaçlı örnek bir IP veya example.net gibi örnek alan adı olarak geçtiğini görmek, tespit/avcılık ekipleri için yüksek güvenli IOC üretebilir. Kanıt paketinde, değerin görüldüğü bağlam (çağrı anı, çağrı yığını, dönüş değeri ve devam eden yan etki) birlikte yer alır.

3.4. Trace yöntem seçimi: görünürlük — müdahale dengesi

Aynı davranış farklı izleme kaynaklarında farklı görünür:

• Debugger tabanlı izleme: kod — çağrı bağını kurmada güçlü, fakat müdahale ve performans etkisi daha yüksek olabilir.
• Sistem/telemetri tabanlı izler: daha az müdahaleci olabilir, fakat argüman ayrıntısı sınırlı kalabilir.
• Hedef odaklı izleme: gürültüyü azaltır; yanlış seçilirse kritik sinyal kaçabilir.

Seçim, hedefinizin "kod bağlamı mı", "zaman çizelgesi mi", "argüman doğruluğu mu" olduğuna göre yapılır. Rapor, seçilen yöntemin sağladığı görünürlüğü ve kör noktalarını açık yazdığında güçlenir.

4. Kanıt üretme ve minimal müdahale yaklaşımı

Debugging hem en güçlü doğrulama aracı hem de en büyük bozulma kaynağıdır. Bu ikisini yönetmek, "hiç dokunma" değil, dokunuyorsan etkisini hesapla ve rapora taşı disiplinidir.

4.1. Gözlem — yorum ayrımı: rapor güvenilirliğinin omurgası

Aynı durum iki farklı cümleyle farklı güven düzeyi taşır:

• Gözlem: "Çağrı izinde, belirli bir fonksiyonun ardından dosya oluşturma denemesi görüldü; dönüş değeri başarısız."
• Yorum: "Örnek kalıcılık kurmaya çalışıyor."

Yorum yapmaktan kaçınmak zorunda değilsiniz; ama yorumun gücü, destekleyen sinyallerle doğru orantılı olmalıdır. En az iki bağımsız sinyal (ör. yol + devam eden kullanım + zaman korelasyonu) varsa yorum daha güçlü yazılır; tek sinyalse "olası" dili ve karşı kanıt araması notu daha doğrudur.

4.2. Zaman çizelgesi: delili "an"dan "akış"a taşımak

Debugging bulguları tek tek parçalar gibidir; zaman çizelgesi bu parçaları denetlenebilir bir hikâyeye dönüştürür:

• Tetik olayı (hangi koşul sağlandı)
• Geçiş olayı (hangi dal/handler sonrası akış değişti)
• Yan etki (dosya/ağ/registry)
• Tutarlılık (tekrarlandı mı, aynı pencerede benzer mi?)

Örnek: "10:12:40'ta exception tetiklendi → 10:12:41'de handler sonrası yeni çağrı zinciri başladı → 10:12:43'te 198.51.100.10 adresine bağlantı denemesi görüldü." Bu tür bir akış, tek tek ekran görüntülerinden daha ikna edicidir ve başka bir analistin aynı pencereyi hedefleyerek doğrulamasını kolaylaştırır.

4.3. Minimal müdahale: ölçerken bozmamak

Minimal müdahale, "az duruşla çok bilgi" hedefler:

• Hipotezi test etmeyen durakları azaltın; ölçüm noktalarını kanıt ihtiyacına göre seçin.
• Aynı örneği farklı koşullarda izlemek gerekiyorsa değişkenleri kontrol altında tutun (ağ, saat, sistem yükü, kullanıcı etkileşimi).
• Debug altında görülen davranış, daha az müdahaleli izde farklıysa bu farkı yok saymayın: farkın kendisi de bir sinyal olabilir ve raporda yer almalıdır.

Dikkat: "Ben böyle gördüm" tarzı raporlar, başka analist aynı sonuca ulaşamadığında hızla değer kaybeder. Tetik koşulu, gözlem penceresi ve sınırlılıklar yazılmadığında, bulgu teknik delil olmaktan çıkar "görüş"e dönüşür.

İpucu: Kanıt paketini üç parçaya bölmek raporu keskinleştirir: (1) ham gözlem (trace/exception/stack bağlamı), (2) bağlam açıklaması (tetik koşulu + argüman/dönüş değeri + çağrı zinciri), (3) yorum ve güven düzeyi (destekleyen sinyaller + aranan karşı kanıtlar + sınırlılıklar). Bu yapı, fazla iddialı cümleleri doğal olarak budar.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Breakpoint’leri tür etiketiyle değil, hipotez–maliyet–müdahale dengesiyle seçmeyi
• Exception’ları “hata” diye kapatmak yerine örüntü ve davranış korelasyonu ile sınıflandırmayı
• API tracing’de argüman–dönüş değeri–yan etki zinciri kurarak davranış–kod eşlemesini sağlamlaştırmayı
• Kanıt üretiminde gözlem–yorum ayrımını koruyup zaman çizelgesi ve yeniden üretilebilirlik notlarıyla raporu güçlendirmeyi
• Minimal müdahale yaklaşımıyla gözlemci etkisini yönetmeyi ve bulguya şeffaf biçimde taşımayı

Modül 7 — Dinamik Enstrümantasyon ve Frida

Dinamik enstrümantasyon, bir ikiliyi "durdurup incelemekten" ziyade, süreç çalışırken kritik temas noktalarından ölçüm alarak davranışı görünür kılar. Statikte belirsiz kalan karar noktalarını runtime'da aydınlatır, verinin kısa süreli "açık hâlini" yakalamayı mümkün kılar ve en önemlisi: "davranış — kod" bağını denetlenebilir kanıta dönüştürür. Bu modülde odak, daha çok veri toplamak değil; doğru görünürlük katmanını seçmek, bulguyu karşı kanıtlarla sınamak ve rapora yeniden üretilebilir bir delil paketi olarak yerleştirmektir.

Bu modülün sonunda yapabiliyor olmanız beklenenler

1) Enstrümantasyonun mantığı: "akıș bozulmadan" görünürlük üretmek

Dinamik enstrümantasyon, hedef sürecin adres alanında çalışırken ölçüm noktaları oluşturur. Çoğu pratikte bu, sürece bir betik çalıştırma ortamı enjekte edilerek (çoğunlukla JavaScript ekosistemi üzerinden) yürütmenin belirli fonksiyonlarında "araya girme" (interception/hooking) yapılması fikrine dayanır. Neden önemli? Çünkü klasik debugging, yürütmeyi durdurduğu için (Modül 6'da gördüğümüz gibi) zamanlama duyarlı örneklerde davranışı değiştirme riskini yükseltirken; enstrümantasyon, akış devam ederken yüksek hacimli gözlemi daha ölçeklenebilir hâle getirir.

Bu yaklaşımın pratik çerçevesi üç soruyla kurulur:

• Nereye bakacağım? (API katmanı, fonksiyon katmanı, veri dönüşümü katmanı)
• Neyi ispatlamaya çalışıyorum? (davranış iddiası, konfigürasyon iddiası, veri çözme iddiası)
• Yanılma payım nereden gelir? (kütüphane gürültüsü, test yolları, telemetri, analiz aracının yan etkisi)

1.1. Debugging ile enstrümantasyonun rol ayrımı

Debugging, derin bağlam çıkarmak için "doğru yerde durmayı" sever; enstrümantasyon ise geniş zaman penceresinde "örüntü yakalamayı" sever. İleri analizde genellikle iki yaklaşım birlikte kullanılır: enstrümantasyonla doğru alanı ve ritmi bulup, kritik anlarda debugging ile noktasal doğrulama yapmak çoğu durumda dengeli bir yöntem seçimi sağlar.

İpucu: Analize başlarken "tek bir katmanda ısrar" etmek yerine, hedefinizi yazın: "Raporumda kod — davranış eşlemesi mi gerekiyor, yoksa operasyonel zaman çizelgesi mi?" Bu cümle, hangi katmana bakacağınızı (debugger mı, enstrümantasyon mu, sistem telemetrisi mi) doğal olarak belirler.

1.2. "Kanca" kavramı: neyi yakalar, neyi kaçırır?

Kancalama (hooking), bir çağrının giriş/çıkışında gözlem almak demektir. Bu sayede:

• çağrının argümanlarını,
• çağrının dönüş değerini,
• çağrının zaman içindeki sıklık/ritmini

aynı çerçevede toplayabilirsiniz.

Ama unutulmaması gereken bir sınır var: kanca, seçtiğiniz noktayı aydınlatır; seçmediğiniz noktayı karanlıkta bırakır. "Mutlak gerçek" yanılsaması burada başlar.

Dikkat: Enstrümantasyon çıktısı ikna edici görünür; fakat yalnızca seçtiğiniz ölçüm noktalarının gerçeğidir. Yanlış noktayı izlemek, doğru davranışı yanlış bağlama oturtur. Bu yüzden her kritik bulguda mutlaka bir karşı kanıt sorusu taşıyın: "Aynı değer başka amaçla taşınıyor olabilir mi? Aynı çağrı zinciri alternatif bir dalda da oluşuyor mu?"

2) Görünürlük katmanları: API, fonksiyon ve veri dönüşümü

Dinamik enstrümantasyonda "aynı problemi" farklı katmanlardan izleyebilirsiniz. Seçim, hedeflediğiniz kanıt standardına göre yapılır.

2.1. API katmanı: işletim sistemiyle temas eden davranış

API seviyesinde görünürlük, davranışı "dış dünyaya çıktığı yerden" okur. İleri seviyede fark yaratan şey, API listesini uzatmak değil; her çağrıyı argüman — dönüş değeri — yan etki zincirine bağlamaktır.

Örneğin dosya etkileşiminde tek başına "dosya açma/oluşturma çağrısı" görmek zayıf kalabilir. Aynı çağrıyı:

• hangi erişim haklarıyla açtı (kontrol argümanları),
• işlem başarılı mı oldu (dönüş değeri),
• bu başarı/başarısızlık sonraki akışı nasıl değiştirdi (tüketim ve dal),

sorularıyla okuduğunuzda davranış ayrışır.

2.2. Fonksiyon katmanı: "kara kutu" blokların şeffaflaşması

Statikte anlaşılması zor, yardımcı mı iş mantığı mı olduğu belirsiz fonksiyonlar runtime'da daha net ayrışır. Ancak fonksiyon katmanı en çok gürültüyü de burada üretir: binlerce çağrı aynı anda akabilir.

Burada iyi yöntem seçimi, "her şeyi izleme" yerine şu iki kademeyi kullanmaktır:

• Geniş yakalama noktaları: ağ, dosya, süreç, bellek koruma değişimi gibi davranış düğümleri
• Dar doğrulama noktaları: belirli argüman örüntüsü veya belirli dönüş değerinin tüketildiği kritik noktalar

2.3. Veri dönüşümü katmanı: string "bulmak" değil, dönüşüm zincirini okumak

Şifreli/obfuscate verinin statikte görünmemesi çoğu zaman normaldir; veri, çalışırken çözülür ve kısa süre sonra yeniden silinir ya da anlamını yitirir. Burada hedef, "string avcılığı" değil; verinin bir dönüşüm zincirinden geçip kullanıma hazır hâle geldiği anı yakalamaktır.

Örnek: Bir iletişim hedefi (alan adı veya dokümantasyon amaçlı örnek IP blokları) çalışırken kısa süre belirebilir. Bu değerin gerçekten operasyonel kullanıma girdiğini söyleyebilmek için:

• değerin bir çağrının argümanına fiilen girdiği,
• çağrı sonucunun (return) sonraki akışta tüketildiği,
• bunun bir yan etkiyle korele olduğu

gösterilmelidir. Aksi hâlde aynı değer sadece telemetri/log amaçlı taşınıyor olabilir.

3) Runtime'da "çözülen" veriyi yakalama: tüketim noktası mı, çözme noktası mı?

Şifreli veri yakalama stratejisi, algoritmayı "tersine çevirmekten" çok, verinin savunma açısından anlamlı hâle geldiği noktayı bulmaya dayanır. İki ana yaklaşım vardır:

• Çözme noktasına yakın gözlem: daha erken yakalarsınız; ancak veri ham/parçalı olabilir.
• Tüketim noktasına yakın gözlem: nihai değer gelme ihtimali daha yüksektir; fakat tüketim noktası çok olabilir, gürültü artar.

Örnek: example.net benzeri bir alan adının bellek üzerinde belirdiğini gördünüz. Bu, tek başına operasyonel kullanım kanıtı değildir. Güçlü kanıt, değerin ağ iletişimiyle ilişkili çağrılara argüman olması ve ardından gelen akışın (ör. yanıt işleme, retry ritmi) bu iddiayı desteklemesidir.

3.1. Yanlış sahiplik ve yanlış rol: en yaygın iki tuzak

• Yanlış sahiplik: değer bellekten geçmiştir ama analiz ettiğiniz bileşene ait değildir (kütüphane/çerçeve kaynaklı).
• Yanlış rol: değer vardır ama operasyonel amaçla kullanılmıyordur (debug mesajı, test endpoint, telemetri).

Bu yüzden delil paketi, değeri en az iki bağımsız bağ ile güçlendirmelidir:

1. — tüketim bağlamı (hangi çağrıda, hangi zincirde),
2. — yan etki korelasyonu (hangi davranışa bağlandı, neyi tetikledi).

Dikkat: "Şifre çözme" başlığı kolayca kötüye kullanılabilir ayrıntıya kayabilir. Bu modülde amaç; algoritma uygulamak veya atlatma tarifleri vermek değil, savunma için gerekli kanıt standardıyla verinin runtime'da nerede görünür olabileceğini anlamaktır.

4) Davranış görünürlüğünde ritim ve sıklık: "potansiyel yetenek" → "gerçekleşmiş eylem"

Çağrı sıklığı ve ritim analizi, davranışın tesadüfi mi sistematik mi olduğuna dair güçlü bir sinyal üretir. Ancak burada da karşı kanıt gerekir: yüksek sıklık bazen döngü/kütüphane gürültüsüdür.

• Periyodik ritim: zamanlayıcı/heartbeat olasılığı
• Patlama (burst): tetik sonrası kısa yoğun aktivite olasılığı
• Sadece başlangıç: init/ortam hazırlığı olasılığı

Örnek: Bir süreç, klavye durumunu okumaya yönelik API'ları aşırı sık çağırıyorsa bu, davranışsal olarak "girdi gözetimi" şüphesini güçlendirebilir. Yine de kesinlik, çağrıların hangi bağlamda oluştuğu ve verinin nasıl kullanıldığıyla (tüketim ve yan etki) artar; sadece "çağrı var" demek yeterli değildir.

İpucu: Ritim analizi, tek başına hüküm vermek için değil; "hangi pencereyi" ve "hangi katmanı" derinleştireceğinizi seçmek için kullanıldığında en verimli çalışır. Önce örüntüyü bulun, sonra bağlamla doğrulayın.

5) Hızlı hipotez testleri: akış kesilmeden doğrulama, yanlış kesinlik üretilmeden raporlama

Enstrümantasyon, hipotezleri hızlı sınamak için güçlüdür; fakat "hız" yanlış kesinlik riskini büyütür. İleri seviyede hedef, iki şeyi aynı anda yapmaktır:

• hipotezi hızlı test etmek,
• yanılma ihtimalini yönetmek (karşı kanıt, sınırlılık, tekrar edilebilirlik).

5.1. Kontrollü deney düşüncesi: neyi değiştirirsen neyi bozarsın?

Enstrümantasyon, bazı durumlarda "çalışma zamanı koşullarını" deneysel amaçla farklılaştırmaya elverişlidir. Savunma açısından değerli olan, bunun bir "atlatma" değil, bir doğrulama aracı olarak konumlandırılmasıdır: belirli bir kontrol dalına geçildiğinde hangi davranışların görüldüğünü gözlemleyip, o dalın raporda nasıl kanıtlanacağını netleştirirsiniz. Bu tür deneylerde rapor dili özellikle şeffaf olmalıdır: hangi koşulda gözlendi, aynı koşul farklı bir gözlem katmanında tutarlı mı, değilse neden olabilir?

5.2. Gürültüyü azaltmak: merkez sinyal tuzağından kaçınmak

Yanlış pozitifleri azaltmanın ileri yolu, tek bir sinyale aşırı anlam yüklememektir:

• Bir değer yakaladıysanız, tüketimini ve etkisini arayın.
• Bir çağrı zinciri gördüyseniz, alternatif dallarda da oluşup oluşmadığını kontrol edin.
• Bir örüntü yakaladıysanız, mümkün oldukça benzer çevre değişkenlerinde tekrar gözlemleyin.

6) Frida/enstrümantasyon çıktılarını delile dönüştürmek: ham log → denetlenebilir bulgu

Enstrümantasyon çıktısı çoğu zaman ham ve dağınıktır. Profesyonel rapor, bu ham veriyi "kanıt paketi"ne dönüştürür. Burada amaç, raporu logla doldurmak değil; logu, denetlenebilir ve yeniden üretilebilir bir iddianın taşıyıcısı yapmak.

6.1. Kanıt paketi standardı

Bir bulgu rapora girerken şu bileşenler birlikte düşünülür:

• Ham gözlem: zaman damgası, olay türü (giriş/çıkış), ilgili argüman kategorisi (kaynak/kontrol/bağlayıcı), çağrı ritmi notu
• Bağlam: olayın hangi davranış zincirine bağlı olduğu, tekrar sayısı, belirgin tetik koşulu
• Yorum + güven düzeyi: hangi bağımsız sinyallerin desteklediği, aranan karşı kanıtlar, görülen sınırlılıklar
• Yeniden üretilebilirlik: gözlem penceresi, görünürlük seviyesi (API/fonksiyon), kullanılan araç sürümleri ve ortam notları

Örnek: "Ağa bağlandı" demek yerine; belirli bir zaman penceresinde example.net değerinin iletişimle ilgili çağrılara argüman olduğu, çağrı sonucunun nasıl tüketildiği ve devamındaki akışın bu iddiayı nasıl desteklediği yazılır.

6.2. Enstrümantasyonun yan etkisi ve tespit riski

Enstrümantasyon, hedef sürecin bellek yapısını değiştirir. Bazı örnekler kendi belleğini (self-checksum) veya yüklü modülleri kontrol ederek analiz aracına tepki verebilir. Bu durumda iki şey önem kazanır:

• Bulguları "enstrümantasyon altında gözlendi" şeklinde açıkça bağlama oturtmak
• Alternatif gözlem katmanlarına dönmek (ör. daha düşük müdahaleli telemetri veya Modül 6'daki daha noktasal doğrulama yaklaşımı)

Dikkat: Analiz aracının varlığı davranışı değiştiriyorsa, "tek sonucu mutlak gerçek" diye yazmak raporu kırılganlaştırır. Farkın kendisi de bir sinyal olabilir; raporda mutlaka yer almalıdır.

İpucu: Rapor eklerinde doğrudan çalıştırılabilir betik paylaşmak yerine, "betiğin mantığı"nı ve ölçüm noktalarını tarif eden kısa bir yöntem özeti vermek çoğu kurumda daha güvenli ve sürdürülebilir kabul edilir. Böylece yeniden üretilebilirlik korunur, kötüye kullanım riski azaltılır.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Dinamik enstrümantasyonu, akış bozulmadan görünürlük üreten bir hipotez test aracı olarak konumlandırmayı
• API/fonksiyon seviyesinde argüman–dönüş değeri–çağrı ritmi üçlüsüyle davranışı ayrıştırmayı
• Çözülen veriyi “string bulma” seviyesinde bırakmadan, tüketim ve yan etki zinciriyle kanıta bağlamayı
• Konfigürasyon çıkarımında “çekirdek alan + etki bağı” yaklaşımıyla gürültüyü azaltmayı
• Hızlı hipotez testlerinde karşı kanıt ve sınırlılık disiplinini korumayı
• Enstrümantasyon çıktılarını zaman çizelgesi, bağlam notu ve yeniden üretilebilirlik bilgileriyle delil paketine dönüştürmeyi

Modül 10 — In-Memory Teknikler ve Injection Analizi

Modern tehditler, disk üzerinde yakalanabilecek izleri azaltmak için yürütmeyi giderek daha fazla bellek içine taşır; bu da "dosya + imza" eksenli tespit ve tersine mühendislik akışlarını kırılgan hâle getirir. Bu modülde, bir sürecin "meşru görünmesine" rağmen belleğinde yabancı yürütme barındırdığı durumları nasıl anlayacağınızı; injection ve "module-less" yürütme örüntülerini doğrulama — karşı kanıt disipliniyle nasıl sınayacağınızı ve bulguları adli kanıt standardında raporlanabilir biçimde nasıl paketleyeceğinizi ele alacağız. Ayrıca debugging ile dinamik enstrümantasyonu birlikte kullanırken, hedef soruya göre yöntem seçimi yapmanın ve müdahale riskini yönetmenin pratiğini işleyeceğiz.

1) In-memory yürütme: görünürlük nereden geri kazanılır?

In-memory teknikler, yürütmeyi "dosya üzerinde" değil; bellek haritası, thread bağlamı, çağrı zincirleri ve çalışma zamanı API davranışları üzerinden şekillendirir. Bu yüzden başarı, tek bir IOC'ye yaslanmaktan çok, birbiriyle tutarlı kanıt parçaları üretmeye dayanır. Orta seviyede bellek — süreç telemetrisinin temel kontrol listesini ayrıntılı işlemiştik; burada kritik olan, aynı sinyalleri yanlış pozitifleri yönetebilecek biçimde ileri düzeyde okumaktır.

1.1. Module-less code ve bellek haritasında anormallikler

"Module-less code", yürütmenin işletim sisteminin "yüklü modüller" envanterinde görünmeyen, sürecin kendi private bellek bölgelerinde gerçekleşmesidir. Tipik uygulamalarda thread başlangıçları ve çağrı yığınları çoğu zaman bir modül içinde anlamlı bir yere oturur; buna karşılık module-less yürütme, iz sürmeyi zorlaştırır ve "bu akış nereden geldi?" sorusunu olay müdahalesinin merkezine taşır.

Sinyal kümeleriyle okunan başlıca göstergeler:

• Bellek izinleri ve zaman içindeki geçişler: Yazılabilirlik/yürütülebilirlik bayraklarının davranışla birlikte değişmesi (özellikle kısa aralıklarla izin dönüşümleri)
• Bölge türü korelasyonu: "Image" eşlemeleri ile "private" bölgelerin hangi davranış düğümüyle (ağ, yeni süreç, kalıcılık denemesi) eşleştiği
• Thread start address bağlamı: Başlangıç noktasının modül aralığında olup olmadığı ve hangi bellek bölgesine düştüğü
• Call stack tutarlılığı: Başlangıç adresi ilk bakışta meşru görünse bile, yığındaki çerçevelerin "normal başlatma akışı" ile uyumu

Örnek: Bir tarayıcı sürecinde beklenmedik bir thread başlıyor; start address, modül listesiyle ilişkisiz "private + yürütülebilir" bir bölgeye düşüyor. Aynı zaman penceresinde kısa süreli ağ temasları görülüyor. Bu tablo, in-memory yürütme hipotezini güçlendirir; karşı kanıt olarak da "tarayıcıların JIT derleyicileri yürütülebilir bellek üretebilir" olasılığı aynı anda masada tutulur.

Dikkat "Private executable" veya RWX benzeri göstergeler tek başına mahkûm edici değildir. JIT çalışma zamanları, codec/GPU bileşenleri, kurumsal güvenlik ajanları ve gözlem katmanları benzer izler bırakabilir. Bu yüzden bellek bulgusunu mutlaka thread başlangıcı + call stack + zaman çizelgesi + yan etki ile birlikte doğrulayın.

1.2. Doğrulama disiplini: karşı kanıtı baştan tasarlamak

İleri analizde doğrulama, yalnız "destekleyici" delil toplamak değildir; bulgunun yanlış olabileceği senaryoları kurup test etmektir. In-memory alanında yanlış pozitif maliyeti yüksek olduğundan, rapor dili de kanıt seviyesine uygun kurulmalıdır.

Karşı kanıtı güçlendiren sorular:

• Bu örüntü, ilgili yazılım ailesinde normal olabilir mi (JIT, sandbox, erişilebilirlik eklentileri, EDR sensörleri)?
• Aynı anormallik benzer sürüm ve kullanımda tutarlı mı, yoksa belirli tetikleyicilerde mi oluşuyor?
• Anormallik dış dünya temasına (ağ, yeni süreç, kalıcılık izi) bağlanıyor mu, yoksa lokal ve etkisiz mi kalıyor?

İpucu Hızlı doğrulama için "temiz referans" yaklaşımını kullanın: aynı uygulamanın benzer sürümünde, benzer yük altında bellek haritası ve thread başlangıç örüntüsü nasıl görünüyor? Bu karşılaştırma, tek bir ekran görüntüsünden çok daha güçlüdür.

2) Process hollowing ve yapısal örüntüler: "güvenilir gövde, şüpheli içerik"

Process hollowing, dışarıdan bakıldığında meşru görünen bir süreç gövdesi içinde, bellekte yürütülen içeriğin beklenmedik biçimde farklılaşmasıyla karakterize edilen bir örüntü ailesidir. Pratikte süreç, "askıya alınmış" başlatma gibi ara evrelerden geçebilir; asıl kritik nokta, süreç kimliğinin iddia ettiği içerikle bellek içeriğinin uyuşmamasıdır. Bu teknik, olay müdahalesinde sık kullanılan "süreç adı/konumu/ebeveyn" gibi yüzey sinyallerini hedef aldığı için önemlidir.

2.1. "Skin-walker" süreçleri anlamak: yüzey ile içeriğin ayrışması

Bir sürecin "meşru gibi" görünmesi, bellekte gerçekten o ikilinin çalıştığı anlamına gelmez. Hollowing şüphesinde odak, disk üzerindeki dosya bilgisiyle bellek görüntüsü arasındaki farka kayar.

Güvenilir sinyal kümeleri:

• Zamanlama ve süreç yaşam döngüsü sapmaları: Süreç doğar doğmaz bellek izinlerinin alışılmadık değişimi, beklenmeyen erken ağ teması gibi göstergeler
• Bellek haritası tutarlılığı: Ana yürütme alanlarının beklenen image eşlemesiyle uyumu
• Thread başlangıç bağlamı: Ana thread'in başlangıç noktası ve "normal başlatma rutini"yle uyum
• Süreç içi yapı tutarlılığı: Süreç çevresel yapı bilgileriyle (ör. süreç ortam blokları ve image temel adresiyle ilgili alanlar) bellek haritasının birbirini destekleyip desteklemediği

Örnek: Bir ofis uygulaması süreci açılıyor; doğuşundan hemen sonra kısa aralıklarla bellek koruma değişimleri ve modül listesiyle ilişkisiz yürütülebilir bölgeler görülüyor. Aynı pencerede ağ teması başlıyor. Bu tablo "meşru süreç içinde yabancı yürütme" hipotezini güçlendirir; karşı kanıt olarak da eklenti yöneticileri veya güvenlik denetleyicilerinin benzer izler üretip üretmediği kontrol edilir.

2.2. Doğrulama: "bellekteki gerçek içerik" ile "diskteki iddia" uyumlu mu?

İleri doğrulama, "hangi teknikle yapıldı?"yı ezberlemekten çok, şu soruyu kanıtlamaya odaklanır: Bu süreç gerçekten iddia ettiği içeriği mi çalıştırıyor?

Bunu savunma bakışıyla kanıtlamak için pratik tariflere kaçmadan şu prensipler kullanılır:

• Bellekteki yürütme bölgelerinin image/private niteliğini ve bölge sınırlarını belgelendirme
• Thread başlangıçlarının düştüğü bölgeleri modül envanteriyle çapraz kontrol etme
• Süreç içi bazı yapı alanlarının (ör. image temel adresiyle ilişkili göstergeler) bellek haritasıyla tutarlı olup olmadığını sınama
• Aynı senaryoyu tekrar koşup anormalliklerin tekrarlanabilirliğini not etme

Dikkat "Şu değer uyuşmuyor, o hâlde tartışmasız hollowing" gibi kesinlik, pratikte risklidir. ASLR, meşru enstrümantasyon veya güncelleme/hotpatch mekanizmaları benzer sapmalar oluşturabilir. Bu yüzden tek bir yapısal sapmayı değil, birden çok bağımsız sinyali ve bunların zaman çizelgesindeki korelasyonunu kullanın.

2.3. Kanıt üretimi: rapora taşınacak minimum paket

Hollowing şüphesini raporda denetlenebilir kılan minimum paket:

• Zaman çizelgesi: süreç oluşturma → anormal bellek değişimi → dış dünya teması (varsa)
• Haritalama kanıtı: thread start address ↔ bellek bölgesi türü ↔ modül envanteri uyumu
• Gözlem — yorum ayrımı: "ne görüldü" ve "ne anlama geldi" ayrı yazılır
• Yeniden üretilebilirlik: kaç tekrar, hangi koşullar, tutarlılık düzeyi
• Sınırlılıklar: tetiklenemeyen yürütme yolları, ortam bağımlılığı ihtimali

3) Thread injection ve reflective loading: yürütme bağlamını "başka yerde başlatmak"

Thread injection, hedef sürecin içine yeni bir yürütme birimi eklenmesiyle kodun o süreçte çalışmasına yol açan örüntüler ailesidir. Reflective loading (özellikle reflective DLL injection), standart yükleyici akışları yerine, bir bileşenin bellek içinde "yüklenmiş gibi" hazırlanmasını ifade eder. Bu iki yaklaşım, "modül listesinde görürüm / diskte yakalarım" varsayımını zayıflatır.

3.1. Remote thread injection örüntüleri: çalışma zamanı telemetrisi mi, bellek artefaktı mı?

Bazı vakalarda injection, süreçler arası bellek ayırma — yazma — uzaktan yürütmeyi başlatma gibi bir çağrı deseniyle görünür hâle gelir. Bu deseni saldırı tarifi gibi kullanmak değil, savunma açısından "neye bakmalıyım?" sorusuna cevap vermek önemlidir: belli fonksiyon ailelerinin ardışıklığı (örn. bellek ayırma, bellek yazma, uzaktan thread başlatma) hem canlı telemetride hem de sonradan adli incelemede iz bırakır.

Yöntem seçimi burada belirgindir:

• Canlı analiz / triage: çalışma zamanı çağrı telemetrisi ile "hangi süreç kime dokunuyor?" sorusu hızlı yanıtlanır.
• Geriye dönük analiz: hedef sürecin bellek görüntüsü ve thread start address'leri üzerinden "yürütme nerede başladı?" sorusu derinleştirilir.

Bu seçim, hedefinizin "olayı durdurmak" mı yoksa "kanıt üretmek" mi olduğuna göre yapılır; çoğu olayda ikisi birlikte gerekir.

İpucu Canlı telemetri geniş alanı hızlı süzer; bellek artefaktı ise "nerede başladı?" sorusunu netleştirir. Triageda geniş, kanıt üretiminde dar ve derin ilerleyen hibrit yaklaşım, zaman ve doğruluk dengesini en iyi kurar.

3.2. Reflective loading ve module-less PE izleri

Reflective loading'de, bileşen standart yükleyici mekanizmalarıyla görünür bir "yüklü modül" olarak kaydedilmeyebilir. Savunma açısından güçlü bir kanıt, modül envanterine bağlı olmayan bir bellek bölgesinde PE başlık izleri (ör. "MZ" imzası ve PE header yapısı) görülmesiyle başlar; fakat bu bulgu da tek başına hüküm değildir: bazı meşru paketleyiciler, sanal dosya sistemleri veya güvenlik ürünleri benzer yapıların bellek içi kopyalarını oluşturabilir.

Kanıtı güçlendiren doğrulama yaklaşımı:

• PE başlık izlerinin bulunduğu bölgenin private/image niteliği
• Bu bölgeye düşen thread start address veya bu bölgeyi çalıştıran akışın call stack bağlamı
• Bölgenin davranışla korelasyonu (ağ, yeni süreç, kalıcılık)

Örnek: Bir metin düzenleyici süreci normal görünürken, kısa bir zaman penceresinde modül listesiyle ilişkisiz bir bellek bölgesinde PE başlık izleri görülüyor ve yeni bir thread'in başlangıcı bu bölgeye düşüyor. Aynı dakikada 192.0.2.44 adresine bağlantı denemesi kaydediliyor. Bulgular, "injection → yürütme başlangıcı → dış temas" sıralamasıyla rapor zaman çizelgesine işlenir; karşı kanıt olarak kurumsal ajan/eklenti davranışları elenir veya sınırlılık olarak not edilir.

3.3. Yanlış pozitifleri yönetmek: meşru injection ekosistemi

Kurumsal ortamlarda meşru injection kaynakları yaygındır: EDR sensörleri, overlay yazılımları, erişilebilirlik araçları, uygulama izleme ajanları. Bu yüzden karar, "injection var" demekten çok, sahiplik ve amaç kanıtlamaya kayar.

Sorulması gerekenler:

• Davranış, kurumun yazılım envanteriyle uyumlu mu?
• Farklı makinelerde aynı ajanla tutarlı mı?
• Şüpheli bileşen, dış dünya teması veya kalıcılık gibi ek düğümlerle birlikte mi geliyor?

4) Şüpheli bellek bölgeleri ve RWX analizi: "riskli izin"i delile çevirmek

RWX (Read — Write — Execute), bir bellek bölgesinin hem yazılabilir hem yürütülebilir olmasını ifade eder. Güvenli tasarım ilkelerinde "W^X" (yazılabilir ve yürütülebilir izinlerin aynı anda verilmemesi) hedeflenir; fakat pratikte bazı çalışma zamanları ve performans odaklı bileşenler RWX benzeri durumlar üretebilir. Bu nedenle RWX, bir "alarm"dır; hüküm değildir.

4.1. RWX'i anlamlı kılmak: "var" değil, "ne zaman ve neyle birlikte?"

RWX'i değerlendiren ileri seviye yaklaşım, şu korelasyonları arar:

• RWX ne zaman oluştu (süreç doğuşu mu, çalışma ortası mı)?
• RWX ile aynı pencerede yeni thread başladı mı? Start address nereye düşüyor?
• Bölge private mı, modül envanteriyle ilişkisiz mi?
• RWX oluşumu, ağ teması veya yeni süreç gibi dış düğümlere bağlanıyor mu?

Örnek: Bir çalışma zamanında RWX benzeri bölgeler her çalıştırmada benzer anda oluşuyor ve call stack, bilinen çalışma zamanı modüllerine işaret ediyor. Buna karşılık ikinci senaryoda, RWX bölgesi oluşur oluşmaz hedef süreçte yeni thread başlıyor ve başlangıç bu bölgeye düşüyor; ardından ağ teması görülüyor. İkinci tablo, doğrulama önceliğini yükseltir.

Dikkat RWX'i tek bir "kare" üzerinden değerlendirmek, in-memory analizde en sık düşülen tuzaktır. En güçlü kanıt, RWX'in zaman içindeki evrimi ve davranış düğümleriyle korelasyonudur; raporda bunu zaman çizelgesiyle göstermek, denetlenebilirliği belirgin artırır.

4.2. RWX'in meşru kaynaklarını elemek: çağrı zinciri ve bağlam

Bir RWX bölgesinin JIT gibi meşru bir kaynaktan mı yoksa şüpheli bir enjeksiyondan mı geldiğini anlamada en güvenilir yaklaşım, bölgenin "kimin tarafından" ve "hangi akışla" tetiklendiğini göstermektir. Burada call stack ve çapraz referans mantığı (Xref) değerlidir: kodun nereye çağrıldığını değil, hangi zincirle oraya gelindiğini anlatır.

5) Hooking ve instrumentation: müdahale mi, gözlem mi?

Hooking, bir çağrıyı başka bir noktaya yönlendirme veya araya katman ekleme yaklaşımıdır; instrumentation ise çalışma zamanında davranışı görünür kılmak için çağrı izleme ve bağlam toplama gibi gözlemsel teknikler bütünüdür. Tehditler hooking ile API sonuçlarını manipüle ederek gizleme veya kontrol elde etme peşinde olabilir; aynı zamanda güvenlik ürünleri de gözlem/koruma için hooking veya benzeri teknikler kullanabilir. Bu ikili gerçeklik, bulgunun yorumunda karşı kanıt aramayı zorunlu kılar.

5.1. Inline hooking tespiti: bellek ile disk arasındaki "sapma"yı okumak

Inline hooking'de, bir fonksiyonun girişindeki ilk baytların yönlendirme kalıbına dönüşmesi sık görülen bir işarettir. Savunma açısından "ispat" dili, genellikle bellek içi fonksiyon giriş baytlarıyla diskteki referans kopya arasında byte seviyesinde karşılaştırma yapabilmeyi ve sapmanın davranış etkisini gösterebilmeyi gerektirir.

Doğrulama burada iki eksende yürür:

• Sapma gerçek mi? Diskteki referansla bellek farkı var mı?
• Sapma neye hizmet ediyor? Bu yönlendirme hangi davranış düğümüne bağlanıyor?

Bu noktada yanlış pozitif yönetimi kritiktir: hotpatch mekanizmaları, güvenlik ajanları veya uyumluluk katmanları da benzer sapmalar üretebilir. Bu yüzden "sapma gördüm" cümlesi değil, "sapma + etki + sahiplik" paketi raporu güçlü kılar.

Örnek: Bir sistem çağrısının sonucu değişmiş gibi görünüyor ve belirli dosyalar listelenmiyor. Bellekte ilgili fonksiyon girişinde sapma saptanıyor. Karşı kanıt olarak güvenlik ajanlarının aynı sistemde benzer yönlendirmeler yapıp yapmadığı kontrol ediliyor; sapma yalnız belirli süreçlerde ve belirli zaman pencerelerinde ortaya çıkıyorsa şüphe artıyor.

5.2. Instrumentation'ın rolü: "etkiyi" yakalamak, kanıtı genişletmek

Dinamik enstrümantasyon (önceki modüllerdeki yaklaşım) burada iki şeye yarar:

• Şüpheli yürütmenin hangi çağrıları tetiklediğini ve bunun davranışla ilişkisini görünür kılmak
• Hook şüphesini yalnız statik farkla değil, çalışma zamanındaki etki ile desteklemek

İpucu: Enstrümantasyon bulgusunu tek koşuda kesinleştirmeyin. Bazı örnekler gözlem altında farklı yollara sapabilir; bazı meşru yazılımlar da performans/uyumluluk nedeniyle davranışı değiştirir. Karşılaştırmalı tekrar ve sınırlılık notu, raporu "denetlenebilir" kılar.

6) Debugging + enstrümantasyon hibrit stratejisi: hedef soruya göre yöntem seçimi

Bu modülde yöntem seçimi, "hangi araç daha güçlü?" sorusundan çok "hangi soruya cevap arıyorum?" üzerinden yapılır:

• Kırılma anını (handoff, thread start, bellek izin değişimi) kanıtlamak için debugging güçlüdür.
• Davranışın kapsamını (hangi çağrılar, hangi bağlamlar) hızlı haritalamak için enstrümantasyon güçlüdür.
• En sağlam yaklaşım çoğu vakada hibrittir: biri olayı yakalar, diğeri olayın etkisini genişletir.

6.1. Hibrit akışın rapora taşınması: kanıt standardı

Hibrit analiz çıktısını delile dönüştürmek için raporda şu yapı "hissedilir" olmalıdır:

• Zaman çizelgesi: süreç/thread telemetrisi + bellek değişimleri + çağrı izleri aynı hikâyeyi destekler
• Gözlem — yorum ayrımı: "şu görüldü" ile "bu şu anlama gelir" ayrı yazılır
• Yeniden üretilebilirlik: koşullar ve tutarlılık (kaç tekrar, hangi sonuç)
• Sınırlılıklar: tetiklenemeyen yollar, gözlemin davranışı etkileme ihtimali, ortam bağımlılığı

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Bellek içi yürütmeyi, tek bir işarete yaslanmadan sinyal kümeleri ve korelasyon ile okumayı
• Process hollowing, thread injection ve reflective loading şüphesini doğrulama–karşı kanıt disipliniyle sınamayı
• RWX ve module-less bulgularını “var/yok” yerine zaman çizelgesi ve bağlam ile anlamlandırmayı
• Hooking bulgularında “sapma + etki + sahiplik” paketini kurarak kanıt standardını yükseltmeyi
• Debugging ve enstrümantasyonu hibrit stratejiyle kullanıp bulguları raporlanabilir adli delile dönüştürmeyi öğrenmiş olacaksınız.

Modül 14 — IoT ve Cloud-Native İleri Analiz

IoT cihazları ve cloud-native iş yükleri, klasik uç nokta (endpoint) analizinden farklı bir "sahne düzeni" ile çalışır: birinde kaynaklar kısıtlı, dosya sistemi alışılmadık ve mimari çeşitlidir; diğerinde ise bileşenler kısa ömürlü, katmanlı imajlar üzerinden dağıtılır ve davranış izleri çoğu zaman kontrol düzlemi loglarına yayılır. Bu modül, IoT tarafında ELF örneklerinde mimari farkındalıkla analiz, gömülü konfigürasyon/C2 çıkarımı, firmware artefaktlarıyla kalıcılık okuma ve botnet komut — telemetri örüntülerini; cloud-native tarafında container imaj/katman analizi, Kubernetes çalışma zamanı artefaktları ve audit temelli korelasyonla kalıcılık örüntülerini savunma odaklı kanıt standardında ele alır.

1) IoT İleri Analiz: ELF, mimari farkındalık ve firmware bağlamı

IoT dünyasında "aynı davranışın" farklı cihazlarda farklı izler bırakması normaldir; çünkü işlemci mimarisi, libc varyantları, dosya sistemi düzeni ve servis yöneticileri değişkendir. Bu nedenle IoT analizinde en büyük hata, bir bulguyu tek bir gözlemle genelleyip "evrensel" sandığından emin olmaktır. Burada amaç saldırı tarif etmek değil; bulgunun gerçekten ne olduğunu doğrulamak, hangi karşı kanıtın bulguyu zayıflatacağını bilmek ve raporu denetlenebilir hale getirmektir.

1.1. ELF malware analizi ve mimari farkındalık

ELF (Executable and Linkable Format), Linux tabanlı sistemlerde ikili dosyaların standart biçimidir; neden önemli dersen, IoT tehditlerinin büyük kısmı Linux türevlerinde ve farklı CPU mimarilerinde (ARM/MIPS gibi) ELF olarak karşımıza çıkar. Mimari farkındalık, yalnızca "hangi platformda çalışır?" sorusu değildir; aynı zamanda disassembly/decompile yorumunun doğruluğunu belirler.

• Mimari uyumu doğrulama: Bir örneğin hedeflediği CPU mimarisi, ikilinin başlık bilgileri ve iç sembol/derleme izleriyle tutarlı olmalıdır. Tutarsızlık, ya çoklu hedefleme stratejisi ya da analiz ortamında yanlış varsayım olasılığını doğurur.
• Kütüphane ve derleyici izleri: Statik analizde görülen kütüphane çağrıları ve string ipuçları, cihazın kullanıcı alanı (userland) profiliyle uyumlu mu sorusu mutlaka sorulmalıdır. Uyumsuzluk, "örnek burada çalışmaz" demek de olabilir; "başka bir cihaz sınıfı hedefleniyor" demek de.
• Davranış — kod eşlemesinde seçicilik: IoT örnekleri sıkça minimal ve görev odaklı olduğundan, kritik fonksiyonları seçmek (Modül 5'teki planlama yaklaşımını hatırla; burada ileri analiz açısından kritik olan, mimari uyumsuzlukların doğurduğu yanlış fonksiyon çıkarımı riskidir) analizi hızlandırır.

Örnek: Bir ağ cihazından alınan şüpheli ELF ikilisinde "uzaktan komut" çağrışımı yapan stringler var. İlk hipotez "komut alıyor" olabilir; karşı kanıt olarak stringlerin log mesajı mı, test modu mu, yoksa gerçekten ağdan gelen girdiyi işleyen bir akışın parçası mı olduğu, çağrı grafiği ve veri akışı üzerinden sınanır. Aynı stringlerin kullanılmasına rağmen girdi doğrulama ve ağ okuma fonksiyonlarıyla bağ kurulamıyorsa, hipotez zayıflar ve rapor dili buna göre ayarlanır.

Dikkat: IoT analizinde "mimariyi yanlış varsaymak", en pahalı hatalardandır. Yanlış mimaride yapılan decompile yorumları çoğu zaman ikna edici görünür ama hatalıdır; bu yüzden bulguyu yazmadan önce mimari uyumu destekleyen en az iki bağımsız işaret aramak, raporun güvenilirliğini ciddi biçimde artırır.

1.2. Embedded konfigürasyon ve C2 çıkarımı metodolojisi

Embedded konfigürasyon, ikili içine gömülmüş çalışma parametrelerini (sunucu adresleri, portlar, kampanya kimlikleri, modlar) ifade eder; neden önemli dersen, IoT tehditlerinde dışarıdan "konfigürasyon indirme" yerine gömülü parametreler sık görülür ve tespitte doğrudan kullanılabilecek ipuçları üretir. C2 (Command and Control) ise komutların alındığı ve telemetrinin gönderildiği yönetim altyapısını temsil eder; tespit açısından değerli olan, "tek bir alan adı gördüm" değil, o altyapının nasıl kullanıldığını doğrulayabilmektir.

Bu modülde komut/skript düzeyinde tariflere girmeden, analist yaklaşımı şu üç ayak üzerinde kurulur:

• Bulgu sınıflandırma: Gördüğün şey gerçekten konfigürasyon mu? Örneğin sabit bir URL, yalnızca bir güncelleme kontrolü olabilir; C2 iddiası, veri akışı ve ağ çağrılarıyla desteklenmeden ağır kalır.
• Doğrulama soruları:
• Bu parametre hangi fonksiyon akışında okunuyor?
• Okunan değer, ağ iletişimi başlatan çağrılarla aynı yürütüm yolunda mı?
• Alternatif açıklama var mı (diagnostic ping, zaman senkronizasyonu, cihaz yönetim paneli)?
• Karşı kanıt arayışı: Temiz firmware sürümünde aynı parametreler bulunuyor mu? Aynı cihaz ailesinde meşru servisler benzer endpoint'lere gidiyor mu?

Örnek: Bir ikilide example.net benzeri bir alan adı gömülü görünüyor. İlk refleks bunu C2 sanmak olabilir. Daha dayanıklı yaklaşım, bu stringin kullanım yerlerini (xref zinciri) takip edip, ağ istek akışında "komut alma/telemetri gönderme" ayrımını gösterecek işaretler aramaktır. Eğer kullanım yalnızca "sürüm kontrolü" gibi tek yönlü bir sorgu ile sınırlıysa, rapor bunu C2 yerine "dış servis bağımlılığı" olarak yazar; C2 iddiası için ek kanıt gerektiğini açık bırakır.

İpucu: Konfigürasyon çıkarımı raporunda, "bulgu listesi" ile "yorum"u birbirine karıştırma. Önce ham değerleri (stringler, sabitler, yapı alanları) kaynak konumlarıyla ver; ardından hangi yürütüm yolunda kullanıldığına dair kanıtı ekle. Bu ayrım, itiraz geldiğinde bulgunun ayakta kalmasını sağlar.

1.3. Firmware artefaktları üzerinden kalıcılık ve davranış analizi

Firmware incelemesi, cihazın "disk imajı" gibi düşünülebilir; ama dosya sistemi düzeni, init sistemi ve servis bileşenleri klasik dağıtımlardan farklıdır. Neden önemli? IoT'ta kalıcılık çoğu zaman kullanıcı hesabı veya klasik servis kayıtlarından ziyade firmware içindeki başlangıç betikleri, servis tanımları ve güncelleme mekanizmalarına tutunur.

Savunma odaklı analizde amaç "nasıl kalıcı olur?"u öğretmek değil; kalıcılık iddiasını doğrulayıp, meşru güncelleme/özelleştirme ile kötü niyetli değişikliği ayıracak kanıt standardını kurmaktır.

• Firmware'de beklenen yapı ile sapma analizi: Aynı model/seri cihazın bilinen sürümleriyle karşılaştırıldığında hangi dosyalar/servisler "uyumsuz"?
• Kalıcılık hipotezini güçlendiren sinyaller: Başlangıçta devreye giren servislerde anormal çağrı zincirleri, beklenmeyen ikililer, gereksiz ağ bağımlılıkları.
• Karşı kanıt: Üretici güncellemeleri veya operatör özelleştirmeleri aynı tür dosyaları ekliyor mu? Değişiklikler "konfigürasyon" düzeyinde mi, "yürütülebilir ekleme" düzeyinde mi?

Örnek: Bir firmware dosya sisteminde, cihazın rolüyle ilgisiz görünen bir ikili tespit ediliyor. İlk hipotez "kötü niyetli ek" olabilir. Karşı kanıt için, aynı cihaz ailesinde resmi uzaktan yönetim ajanlarının da benzer ikililer ekleyip eklemediği ve ilgili ikilinin gerçekten başlangıçta çağrılıp çağrılmadığı incelenir. Başlangıç bağlamıyla ilişki kurulamazsa, bulgu "şüpheli ama doğrulanmamış artefakt" olarak yazılır; doğrulama için gereken ek veri (runtime logları gibi) raporda belirtilir.

Dikkat: Firmware artefaktlarından kalıcılık iddiası çıkarmak, yanlış pozitif üretmeye çok açıktır. Üretici/operatör özelleştirmeleri, özellikle ağ yönetimi ve telemetri için beklenmedik bileşenler içerebilir. Bu yüzden "sapma" bulgusunu mutlaka zaman çizelgesi ve cihaz rolü bağlamıyla birlikte yaz; tek başına "dosya var" demek denetimde zayıftır.

1.4. IoT botnet davranış modeli: komut ve telemetri örüntüleri

IoT botnet davranış modeli, "tek bir kötü ikili"den çok bir yaşam döngüsü anlatır: keşif/katılım, komut dinleme, görev icrası, durum bildirme (telemetri) ve dayanıklılık. Neden önemli? Bu model, tespit tarafında doğru yerde doğru sinyali aramanı sağlar; ayrıca bulguyu rapora taşırken "hangi aşamayı hangi kanıtla destekliyorum?" sorusunu netleştirir.

• Komut örüntüleri: Komutlar çoğu zaman sınırlı bir sözlükten gelir ve cihaz rolüne göre değişir. Analist açısından kritik olan, komutun "metin olarak varlığı" değil, komutun cihaz davranışına bağlanabilmesidir.
• Telemetri örüntüleri: Botnet telemetrisi genelde kimlik bilgisi (cihaz türü), çalışma durumu ve görev sonuçlarını içerir. Savunma açısından telemetri, ağ tespit kuralları ve korelasyon için değerlidir.
• Doğrulama: Komut — telemetri akışı gerçekten iki yönlü mü? Tek yönlü "ping" trafiği veya log gönderimi, botnet telemetrisi sanılmamalıdır.
• Karşı kanıt: Meşru cihaz yönetim platformları da "komut" ve "telemetri" kavramlarını kullanır; farkı yaratan, protokol/akış bağlamı ve yürütüm yoludur.

Örnek: Bir IoT cihazında periyodik olarak dışarıya küçük paketler gittiği görülüyor. İlk yorum "telemetri" olabilir. Botnet telemetrisi iddiası için, bu trafiğin bir komut yanıtı ile ilişkili olup olmadığı (zaman korelasyonu), cihaz üzerinde hangi sürecin bu trafiği ürettiği ve aynı firmware sürümünde temiz cihazlarda bunun görülüp görülmediği sınanır. Temiz profilde aynı akış varsa botnet iddiası zayıflar; yoksa hipotez güçlenir.

İpucu: Botnet şüphesini raporlarken "aşama haritası" kullan: katılım/komut/telemetri aşamalarının her biri için en az bir gözlem, bir doğrulama adımı ve bir karşı kanıt sonucu yaz. Bu yapı, "hikâye anlatımı" değil "kanıt zinciri" üretir.

2) Cloud-Native İleri Analiz: container katmanları, Kubernetes artefaktları ve audit korelasyonu

Cloud-native dünyada dosyalar ve süreçler kadar "tanım" (manifestler, imaj katmanları, deployment şablonları) da delildir. Neden önemli? Saldırgan davranışı çoğu zaman container içine bir dosya bırakmaktan ziyade, imaj/manifest değişikliği, kısa ömürlü job'lar veya init container gibi yürütüm mekanizmaları üzerinden akar. Buradaki amaç saldırı kurmak değil; şüpheli artefaktları izole etmek, davranışı doğrulamak ve denetlenebilir rapor üretmektir.

2.1. Container imaj ve katman analizi: şüpheli artefakt ayrıştırma

Container imajı, katmanlı bir dosya sistemi gibi çalışır; her katman öncekinin üzerine eklenen değişiklikleri taşır. Neden önemli? Şüpheli bir ikili, bir katmanda eklenmiş olabilir; ya da meşru bir bileşen beklenmedik bir katmanda değiştirilmiş olabilir. Analist için değer, "dosya var" demekten çok, o dosyanın hangi katmanda ve hangi bağlamda geldiğini söyleyebilmektir.

• Artefakt ayrıştırma yaklaşımı:
• Beklenen bileşen seti (base imaj, uygulama bağımlılıkları) ile görülen bileşen seti arasındaki farklar
• Katmanlar arasında değişen dosyalar ve "neden bu katmanda?" sorusu
• Meşru paket yöneticisi kaynaklı mı yoksa doğrudan kopyalanmış mı izlenimi?
• Doğrulama: Şüpheli dosya, container çalıştığında gerçekten yürütülüyor mu? Yalnızca build artığı olabilir.
• Karşı kanıt: CI/CD pipeline çıktılarında veya resmi imaj etiketlerinde aynı değişiklik var mı? Aynı servis için önceki sürümlerde benzer dosya bulunuyor mu?

Örnek: Bir uygulama imajında beklenmeyen bir ELF ikilisi katmanlardan birinde görülüyor. İlk hipotez "eklenmiş zararlı" olabilir. Karşı kanıt olarak, ilgili katmanın hangi pipeline adımına karşılık geldiği, imajın resmi registry kaydındaki açıklamalar ve önceki imaj sürümlerindeki farklar incelenir. Eğer aynı ikili daha önce de var ve meşru bir bağımlılığa aitse, hipotez zayıflar; yoksa "şüpheli ekleme" bulgusu kanıt gücünü artırır.

2.2. Kubernetes çalışma zamanı artefaktları: pod davranışı, init container, job/cron job örüntüleri

Kubernetes'te iş yükleri pod'lar içinde koşar; init container, ana container başlamadan önce çalışan hazırlık adımlarını temsil eder; job/cron job ise tek seferlik veya zamanlanmış işlerdir. Neden önemli? Kalıcılık veya gizli yürütüm, bazen ana uygulamaya dokunmadan init container veya cron job gibi mekanizmalarla "görünürde meşru" bir akışa saklanabilir.

Savunma odaklı analizde dikkat edilen noktalar:

• Pod davranış profili: Normalde kısa yaşayan bir pod'un aniden sürekli yaşaması; normalde ağ erişimi olmayan bir iş yükünün ağ konuşmaya başlaması gibi sapmalar.
• Init container örüntüleri: "Hazırlık" amacıyla eklenmiş init container gerçekten hazırlık mı yapıyor, yoksa uygulama dışı bir yürütüm mü taşıyor? Bu iddia, init container'ın yaptığı değişikliklerin ana container davranışıyla ilişkisi üzerinden doğrulanır.
• Job/CronJob örüntüleri: Zamanlanmış işler, özellikle veri işleme ve bakım görevlerinde meşrudur; şüpheyi doğuran şey, işin rolüyle uyumsuz erişimler ve beklenmeyen sıklık/davranış sapmalarıdır.

Örnek: Bir ortamda her gece çalışan bir cron job görülüyor. İlk yorum "bakım işi" olabilir. Karşı kanıt olarak, job'ın çıktısının gerçekten bakım metriklerine mi hizmet ettiği, yürütüm sırasında beklenmeyen ağ temasları olup olmadığı ve aynı işin önceki haftalarda aynı şekilde tanımlı olup olmadığı incelenir. Sonuç, "meşru bakım" veya "rol uyumsuz, doğrulanmış sapma" şeklinde kanıt gücüne göre yazılır.

Dikkat: Cloud-native analizde en sık tuzak, "manifestte var → meşru" düşüncesidir. Yanlış yapılandırmalar veya zincirleme değişiklikler, meşru tanımlar içine şüpheli yürütümü taşıyabilir. Bu yüzden tanım (deployment/yaml) delildir ama tek başına hüküm değildir; runtime sinyallerle doğrulanmalıdır.

2.3. Cloud ortamlarında log ve olay korelasyonu: audit yaklaşımı ve runtime sinyaller

Cloud log korelasyonu, olayların farklı katmanlara bölünmesi nedeniyle "tek bir log kaynağı yeter" yaklaşımını bozar. Audit yaklaşımı, özellikle kontrol düzlemi eylemlerini (kim, neyi, ne zaman değiştirdi) izlemeyi hedefler; neden önemli dersen, cloud-native persistence çoğu zaman "dosya bırakmak" yerine "yetki ve tanım değişikliği" ile kurulur.

• Audit odaklı doğrulama: Bir pod davranışı şüpheliyse, bunu doğuran değişiklik hangi audit olayına bağlanabiliyor? Değişiklik zinciri yoksa, hipotez zayıflar ya da veri eksikliği açıkça raporlanır.
• Runtime sinyaller: Container'ın beklenmedik süreç üretmesi, beklenmedik network temasları, kısa süreli ama tekrarlı iş yükü oluşumu gibi sinyaller, audit ile birleştirildiğinde kanıt gücü artar.
• Karşı kanıt: Otomasyon sistemleri (CI/CD, autoscaler, operatörler) benzer değişiklikleri meşru biçimde üretebilir. Bu yüzden "değişikliği kim yaptı?" sorusunun cevabı, servis hesapları ve otomasyon paternleriyle tutarlı mı diye sınanır.

Örnek: Bir servis hesabının çok sayıda deployment güncellemesi yaptığı görülüyor. İlk yorum "otomasyon" olabilir. Ancak aynı zaman penceresinde runtime sinyallerinde, beklenmeyen init container eklenmesi ve ağ temasları sapması varsa, otomasyon hipotezi zayıflar; audit zinciri, değişikliğin kaynağını daha sıkı doğrulamak için kullanılır.

İpucu: Korelasyonun raporlanabilir olması için olayları "değişiklik → etkisi → doğrulama → karşı kanıt" şeklinde yaz. Örneğin: "X tanımı değişti (audit) → Y davranışı oluştu (runtime) → Z ile doğrulandı (korelasyon) → alternatif açıklama (otomasyon) şu nedenle zayıf kaldı."

2.4. Cloud-native persistence örüntüleri ve tespit odaklı analiz yaklaşımı

Cloud-native persistence, çoğu zaman platform mekanizmalarının "beklenen" özelliklerini kötüye kullanım olarak değil, "beklenmeyen bağlamda" kullanma şeklinde belirir: beklenmedik ayrıcalıklar, rol uyumsuz zamanlanmış işler, init container üzerinden değişiklik izleri, imaj katmanında sessiz eklemeler... Neden önemli? Tespit odaklı yaklaşım, bu örüntüleri "kural yazılabilir sinyaller" haline getirir.

• Örüntüleri kanıta dönüştürme:
• Hangi tanım değişikliği hangi davranışı doğurdu?
• Bu bağ, başka bir açıklamayla (meşru bakım, autoscaling, sürüm geçişi) kırılabiliyor mu?
• Sınırlar ve riskler:
• Her ortamda full audit kapsamı olmayabilir; eksik kapsam, raporda "kanıt gücü"nü düşürür.
• Kısa ömürlü pod'lar delili hızla yok eder; yöntem seçimi burada "ne kadar hızlı yakalamalıyım?" sorusuna bağlanır.

Dikkat: Cloud-native vakalarda "kanıtın uçuculuğu" (ephemerality) yüksektir. Bir bulgu, yalnızca birkaç dakika görünen bir pod davranışına dayanıyorsa; aynı bulguyu tekrar üretilebilir kılacak audit kaydı, imaj katmanı farkı veya tanım sürümü gibi kalıcı delillerle desteklemeden kesin hüküm kurmak raporu kırılgan yapar.

3) Doğrulama, kanıt üretimi ve yöntem seçimi: IoT ve cloud için ortak disiplin

Bu bölüm, modülün iki dünyasını ortak bir standarda bağlar: aynı bulgu farklı yöntemlerle doğrulanabilir; önemli olan koşula göre doğru yöntemi seçmek ve sonucu delil olacak biçimde paketlemektir.

3.1. Doğrulama: hipotezi test etmek ve karşı kanıtı tasarlamak

Bir bulgu, çoğu zaman bir "işaret" olarak başlar: şüpheli ELF, beklenmedik katman farkı, anormal init container... Doğrulama, bu işaretin gerçekten iddia ettiğin şeye bağlanıp bağlanmadığını sınamaktır.

• IoT tarafında karşı kanıt çoğu zaman meşru firmware özelleştirmesi veya meşru yönetim telemetrisi olur.
• Cloud-native tarafta karşı kanıt çoğu zaman otomasyon paternleri (CI/CD, operatörler, autoscaling) ve planlı bakım işleri olur.

Örnek: Bir container imajında beklenmeyen ikili var. "Zararlı" hipotezini test etmek için runtime'da yürütüm bağı aranır; karşı kanıt olarak, aynı ikilinin önceki meşru sürümlerde bulunması veya pipeline artefaktı olması ihtimali değerlendirilir. Sonuç, kanıt gücüne göre katmanlanır: "şüpheli artefakt" → "yüksek şüpheli ekleme" → "davranışla doğrulanmış ekleme".

3.2. Kanıt üretimi: rapora dayanıklı paket nasıl oluşturulur?

Bu modülde kanıt paketi üç parçaya ayrılır:

1. Gözlem: Ne gördün? (artefakt, fark, olay kaydı, zaman damgası)
2. Yorum: Bu gözlem hangi hipotezi destekliyor?
3. Yeniden üretilebilirlik + zaman çizelgesi: Başka bir analist aynı veriden aynı sonuca nasıl gider?

IoT için örnek paket öğeleri:

• ELF ikilinin kimliği ve mimari uyumu (gözlem)
• Konfigürasyon/C2 iddiasını destekleyen xref/veri akışı bağı (yorum)
• Firmware sürümü ve karşılaştırma referansı (yeniden üretilebilirlik)

Cloud-native için örnek paket öğeleri:

• İmaj katman farkı ve hangi katmanda eklendiği (gözlem)
• Audit olay zinciri ile runtime sinyali arasındaki bağ (yorum)
• Tanım sürümü, değişiklik zamanı ve otomasyon bağlamı (yeniden üretilebilirlik)

İpucu: Rapor eklerinde "delil haritası" kullan: her iddia için hangi veri kaynaklarıyla (imaj katmanları, audit log, runtime sinyal, firmware artefaktı) desteklediğini tek sayfada göster. Bu harita, denetimde en hızlı savunma aracıdır.

3.3. Yöntem seçimi: aynı problemi farklı yollardan çözmek

Yöntem seçimi, "en kapsamlı"yı değil, "en uygun ve en az riskli"yi seçmektir.

• IoT cihaz erişimi kısıtlıysa: Firmware artefaktları ve ikili statik analizi daha gerçekçi olabilir; runtime kanıtı sınırlı kalabilir. Bu sınırlılık rapora yazılır.
• Cloud ortamda uçuculuk yüksekse: Öncelik audit zinciri ve imaj katmanı gibi kalıcı deliller olabilir; runtime sinyaller kaçabilir. Buna göre kesinlik dili ayarlanır.
• Kurumsal risk: Üretim sisteminde agresif gözlem yöntemleri davranışı etkileyebilir; "minimal müdahale" yaklaşımını Modül 6'daki prensiplerle uyumlu şekilde burada da sürdürürsün.

Örnek: Bir Kubernetes ortamında şüpheli cron job görüldü. Yöntem seçimi, önce audit üzerinden "kim ekledi, ne zaman, hangi kaynakla" sorusunu cevaplar; sonra runtime sinyallerle davranış sapmasını doğrular; en sonunda imaj/katman farkı ile şüpheli bileşeni izole eder. Bu sırada otomasyon kaynaklı alternatif açıklamalar sürekli karşı kanıt olarak masada tutulur.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• IoT ELF örneklerini mimari farkındalıkla yorumlamayı ve yanlış yorum riskini karşı kanıtla azaltmayı
• Gömülü konfigürasyon ve C2 çıkarımında “bulgu → doğrulama → delil” zinciri kurmayı
• Firmware artefaktları üzerinden kalıcılık iddiasını, meşru özelleştirme olasılığını dışlamadan kanıt standardında yazmayı
• IoT botnet komut–telemetri örüntülerini davranış modeli üzerinden okuyup tespit önerisine dönüştürmeyi
• Container imaj/katman analizinde şüpheli artefaktları bağlamıyla ayrıştırmayı ve doğrulamayı
• Kubernetes runtime artefaktlarında (pod, init container, job/cron job) rol uyumu, audit korelasyonu ve runtime sinyallerle cloud-native persistence örüntülerini kanıtlamayı
• Yöntem seçimini ortam kısıtı, uçuculuk ve operasyonel riskle birlikte ele alıp raporu yeniden üretilebilir kılmayı

Modül 16 — Supply Chain Saldırı Analizi

Tedarik zinciri vakalarında problem çoğu zaman "tek bir dosya" değildir; bağımlılıklar, derleme hattı ve dağıtım kanalları boyunca biriken küçük güven varsayımları, tek bir kırılma anında büyük ölçekli etkiye dönüşür. Bu modül, şüpheli paket/sürüm geçişlerini yalnız "kötü mü?" diye etiketlemek yerine; hangi aşamada neyi doğruladığınız, hangi delille hangi kesinlik dilini kullandığınız üzerinden ele alır. Meşru bileşenlerin içine gömülen zararlı davranışları ayrıştırmayı, build/artefakt anomalilerini kanıt standardıyla analiz etmeyi ve altyapı — TTP korelasyonu ile olayı daha geniş kampanya resmine güvenli biçimde oturtmayı hedefler.

1) Bağımlılık, build pipeline ve artefakt repo riskleri

Modern yazılım geliştirme, yüzlerce üçüncü taraf bileşen ve otomatikleştirilmiş üretim bandı üzerinde yükselir. Neden önemli? Çünkü saldırgan, yazılıma doğrudan saldırmak yerine "güvenilir kabul edilen" bir halkayı hedefleyerek tek hamlede çok sayıda hedefe erişim etkisi yaratabilir. İleri seviye analistin görevi, samanlıkta iğne aramak gibi her şeye tek tek bakmak değil; meşru akış içindeki semantik sapmaları (yazılımın "ne yaptığı"nın beklenmedik biçimde değişmesi) bulma disiplinini işletmektir.

1.1. Bağımlılık riski: "kimin kodunu çalıştırıyorum?"

Bağımlılık analizinde güven kaynağını üç katmanda düşünmek pratik olur:

• Sahiplik ve yayın yetkisi: Projenin bakım modeli, hesap devri riski, imzalama anahtarlarının yönetimi, yayın sürecindeki erişim sınırları
• Sürümleme ve değişim mantığı: "Küçük güncelleme" iddiasıyla uyumsuz büyük davranış değişimleri, olağandışı hızlı sürüm artışları, ani bakım devri/ani geri dönüşler
• Dağıtım kanalı güveni: Registry metadata'sı, paket imzası, yayın geçmişi, kaldırılan sürümler, yeniden yayın ve tag/digest tutarlılığı

Doğrulama bakışı burada "saldırıdır" diye kestirmek yerine, aynı anormalliğin masum açıklamalarını da aktif biçimde arar. Tek başına "yeni sürüm çıktı" bir kanıt değildir; ama yeni sürümle birlikte beklenmedik dış erişim, konfigürasyon okuma akışında değişim ve release notu ile uyumsuz modül eklenmesi aynı anda görülüyorsa hipotez güçlenir.

Örnek: Küçük bir patch güncellemesinde paket boyutu belirgin artar. Bu artış, yeni yerelleştirme dosyaları veya test varlıklarıyla açıklanabilir. Karşı kanıt olarak artışın kaynak kontrolündeki değişimle uyumlu olup olmadığı ve güncelleme sonrası çalışma zamanı davranışında yeni bir dış temas/dosya etkileşimi ortaya çıkıp çıkmadığı birlikte değerlendirilir. "Boyut arttı → saldırı" gibi kısa devre çıkarımlardan kaçınmak, yanlış yönlendirmeyi azaltır.

1.2. CI/CD ve build pipeline riski: "kaynak kod temizse ürün de temiz mi?"

Build pipeline; CI/CD ajanları, secret'lar, cache mekanizmaları, bağımlılık çözümleme ve imzalama adımlarıyla "görünmez" ama yüksek etkili bir yüzeydir. Neden önemli? Çünkü kaynak kod denetimleri (code review) düzgün olsa bile, üretim hattı kompromize ise dağıtılan artefakt beklenmedik şekilde farklılaşabilir.

Burada analistin bakacağı kanıt sınıfları:

• Provenance (köken) kanıtı: Artefakt hangi commit/tag'den, hangi ortam profiliyle, hangi kimlikle üretildi?
• Sürüm — artefakt tutarlılığı: Aynı kaynaktan üretildiği iddia edilen çıktılar semantik olarak aynı mı?
• İmzalama ve anahtar hijyeni: İmzalama nerede ve hangi erişim modeliyle gerçekleşiyor?
• SBOM sürekliliği: Bağımlılık bileşimi sürümden sürüme beklenen biçimde mi değişiyor?

Bu noktada yöntem seçimi, vakaya göre değişir: canlı olay müdahalesinde hızlı karar gerekiyorsa provenance + SBOM sapmalarıyla risk önceliklendirmesi yapılabilir; adli rapora gidecek vakada ise üretim kanıtının derin doğrulaması daha yüksek standartla ele alınır.

İpucu: Üretim hattı şüphesinde "tek bir delil" aramak yerine, provenance tutarsızlığı + SBOM sapması + davranış farklılığı gibi en az iki bağımsız kanıt hattı kurun. Bu yaklaşım, hem itirazlara dayanıklılığı artırır hem de yanlış alarmı azaltır.

1.3. Reproducible builds: üretim hattı şüphesini "kanıt" düzeyine taşımak

Yeniden üretilebilir derleme, aynı kaynak ve deterministik üretim koşulları sağlandığında aynı çıktıya ulaşabilme ilkesidir. Neden önemli? Çünkü kaynak kod temiz görünüp dağıtılan ürün farklıysa, "nerede fark oluştu?" sorusunu spekülasyondan çıkarıp kanıta yaklaştırır.

Savunma odaklı kullanımda amaç; adım adım saldırı tarif etmek değil, iddianın doğrulanabilirlik eşiğini yükseltmektir. Şüpheli artefakt ile kontrollü ortamda üretilen artefakt arasında anlamlı fark bulunuyorsa, rapor dili "muhtemel"den "güçlü şüphe"ye daha sağlam zeminle geçebilir. Tersi durumda da hipotez daralır ve yanlış yönlendirme riski düşer.

Dikkat: Reproducible builds, her ekosistemde "hemen uygulanabilir" olmayabilir (derleme zaman damgaları, farklı toolchain, non-deterministic adımlar). Bu sınırlamalar rapora açıkça yazılmadığında, güçlü gibi görünen sonuçlar denetimde zayıflayabilir.

1.4. Artifact repository riski: "dağıtılan şey gerçekten beklediğimiz şey mi?"

Artefakt depoları (paket registry, container registry, binary depoları) hem dağıtım kanalı hem de tarihçe kaydıdır. Neden önemli? Çünkü saldırgan çoğu zaman doğrulama/denetim boşluklarının olduğu halkayı seçer.

Analizde şu sorular disiplin kazandırır:

• Artefaktın kimliği ve yayın geçmişi tutarlı mı (tag/digest ilişkisi, beklenen sürüm politikası)?
• Olağandışı sil — yeniden yayın veya "tag kaydırma" sinyalleri var mı?
• Aynı isimle farklı kaynaktan yayın ihtimali mevcut mu (typosquatting / dependency confusion sınıfları)?
• Repository logları "ne zaman, hangi kimlikle, hangi bağlamda" sorularına cevap verecek kadar sağlam mı?

Dikkat: "İmzalı paket" veya "güvenilir repo" etiketi, supply chain vakalarında analizi bitirmek için gerekçe değildir. İmza anahtarları ele geçirilmiş olabilir ya da üretim hattında imzalanan şey, beklenmeyen biçimde farklılaşmış olabilir. Kesinlik, etiketten değil kanıt zincirinden doğar.

2) Şüpheli paket/sürüm triage ve davranış analizi

Triage'ın amacı tam analiz yapmak değil, doğru sıraya koymaktır. Neden önemli? Çünkü supply chain olaylarında aynı anda birçok sürüm, bağımlılık ve tüketici ürün etkilenebilir; yanlış sıraya koymak, hem zaman kaybettirir hem de kaçırma riskini artırır.

2.1. Triage sinyalleri: neyi "önce" ele alırsın?

Sinyalleri üç grupta toplamak pratik olur:

• Sürüm/metadata anormallikleri: "Küçük güncelleme" ile uyumsuz değişim, tutarsız release açıklaması, olağandışı yayın temposu
• Kod/işlev anormallikleri: İlgisiz modüllerde yoğun değişim, başlangıç akışında beklenmedik yeni adımlar
• Çalışma zamanı anormallikleri: Yeni dış temaslar, beklenmedik dosya/ayar etkileşimleri, zamanlama paternlerindeki değişim

Doğrulama — kanıt ayrımı burada belirgin olmalı: sinyal "gözlem"dir; "yorum" ise bağımsız kanıt eklenene kadar temkinli kurulur. Karşı kanıt olarak, aynı anormalliğin masum sebepleri (telemetri eklenmesi, lisans taraması, hata raporlama, refactor) değerlendirilir.

Örnek: Güncellemeden sonra uygulama her başlatılışta kısa bir ağ teması kurar. Bu telemetri olabilir. Karşı kanıt arayışı; hedef sınıfının ürünün bilinen servisleriyle uyumu, davranışın belirli ortamlara bağlı olup olmadığı ve zaman penceresinin normal operasyonla çakışıp çakışmadığı üzerinden yürür. Böylece "ağ teması var → kötü" gibi zayıf çıkarım yerine, bağlama oturan bir risk anlatısı oluşur.

2.2. Versiyon fark analizi ve diffing: nerede "az okuma, çok görme" işe yarar?

Supply chain vakalarında en verimli yöntemlerden biri, değişimin olduğu yeri daraltmaktır. "Tüm kodu baştan sona okumak" yerine, iki sürüm arasındaki farkın hangi fonksiyon/akışlarda yoğunlaştığını görmek; özellikle küçük ama kritik "zehirli delta"ların yakalanmasında etkilidir.

Yöntem seçimi bağlama göre yapılır:

• Kaynak diff (varsa): Değişen satırları hızlıca görmek, semantik sapmayı yakalamayı kolaylaştırır.
• Binary diffing (özellikle kaynak yoksa veya dağıtılan ikili kritikse): Değişen fonksiyonlara odaklanmayı sağlar; analiz alanını dramatik biçimde daraltır.

Örnek: Bir kripto kütüphanesinin yeni sürümünde, rastgelelik üretimiyle ilişkili fonksiyon davranışının beklenmedik biçimde değiştiği tespit edilir. Bu tür sapmalar "performans iyileştirmesi" olarak açıklanmış olsa bile, güvenlik etkisi yüksek olabilir. Raporda burada önemli olan, "arka kapı" gibi ağır etiketleri aceleyle kullanmak değil; değişimin güvenlik varsayımını nasıl zayıflattığını kanıt zinciriyle gösterebilmektir.

İpucu: Diffing bulgularını rapora taşırken "değişti" demek yetmez. Değişimin etkisini (hangi akışı etkiliyor, hangi koşulda tetikleniyor, hangi güven varsayımı bozuluyor) kısa bir akış anlatısıyla eklemek, delil değerini artırır.

2.3. Typosquatting ve dependency confusion: isim benzerliği ve kaynak önceliği tuzakları

Saldırganlar, popüler paket isimlerini taklit ederek (typosquatting) veya kurum içi özel paket isimlerini suistimal ederek (dependency confusion) geliştirme ortamlarına sızmayı hedefleyebilir. Neden önemli? Çünkü bu sınıfta "kurban" çoğu zaman üretim ortamı değil; build zinciridir. Bir kez build hattına giren kötü niyetli bileşen, çok daha geniş ölçekte yayılım etkisi yaratabilir.

Savunma açısından burada kanıt üretimi; "yanlış paket çekildi" iddiasını destekleyecek kaynak çözümleme izi, sürüm/namespace tutarlılığı ve dependency graph kanıtlarıyla güçlenir. Karşı kanıt olarak da benzer isimli paketlerin meşru bir migration/sürümleme kararı olup olmadığı değerlendirilir.

3) Meşru bileşen içine gömülü payload ayrıştırma yaklaşımı

En zor senaryo, zararlı davranışın meşru ve hatta imzalı bir bileşenin içine "fonksiyonelliği bozmadan" gizlenmesidir. Neden önemli? Çünkü analist yalnız "ek dosya" ararsa, asıl tetikleyici mantığı kaçırabilir; doğru soru çoğu zaman "hangi davranış akışı semantik olarak sapmış?" sorusudur.

3.1. Semantik sapma: meşru akış içindeki beklenmedik yönelimler

Semantik sapma, kodun varlığından ziyade kodun anlamının değişmesidir: beklenmedik dış temas, beklenmedik koşul bağımlılığı, beklenmedik veri dönüşümü gibi. Bu modülde amaç, "nasıl enjekte edilir?" değil; nasıl ayrıştırılır ve ispatlanır? sorusunu yönetmektir.

Ayrıştırma için üç soru güçlü bir iskelet sunar:

• Gözlenen çıktılar neler? (dış erişim, konfigürasyon okuma, beklenmedik modül yüklenmesi)
• Bu çıktıyı tetikleyen giriş noktası neresi? (başlatma, modül yüklenmesi, belirli kullanıcı akışı)
• Tetikleyici hangi veriye/koşula bağlı? (feature flag, ortam değişkeni, zaman penceresi, sürüm kontrolü)

Örnek: Bir güncelleme sonrası yalnız belirli saat aralığında kısa bir dış istek görülür. Bu bir ölçüm mekanizması da olabilir. Karşı kanıt arayışı; isteğin hedeflerinin ürünün bilinen telemetri sağlayıcılarıyla uyumu ve tetikleyicinin belgelenmiş bir konfigürasyon anahtarına bağlı olup olmadığı üzerinden yürür. Belgelenmemiş, sürümle birlikte gelen ve açıklanamayan bir koşul bağımlılığı görülürse, "gömülü mantık" hipotezi güçlenir.

3.2. "Gömülü" parçanın kanıtlanması: akışın çalındığını gösteren delil dili

Gömülü manipülasyonda sık görülen problem, raporda "zararlı var" cümlesinin kanıt düzeyine taşınamamasıdır. Burada kanıt üretimi için iki ilke kritiktir:

• Gözlem — yorum ayrımı: "Fonksiyon akışı beklenmedik bir hedefe yönleniyor" gözlemdir; "bu arka kapıdır" yorumu ise ek kanıt ister.
• Teknik ispatın biçimi: Akışın beklenmedik şekilde yönlendiği, meşru akışla tutarsız bellek/akış izleriyle desteklenmeli; mümkünse sürümler arası farkla bağlanmalıdır.

Bu bağlamda, "inline hooking" veya "code caves" gibi kavramlar, saldırıyı öğretmek için değil; analistin 'akış neden beklediğim gibi değil?' sorusunu yanıtlayabilmesi için önemlidir. İspat dili, belirli adres/opcode gibi saldırıyı kolaylaştıracak ayrıntılara sapmadan; fonksiyon girişinin yama ile yönlendirildiği, kontrol akışının orijinal olmayan bir bölgeye saptığı ve bu sapmanın çalışma zamanı davranışıyla örtüştüğü gibi doğrulanabilir ifadeler üzerine kurulmalıdır.

Dikkat: "Dosya imzalı" bilgisi, özellikle tedarik zinciri vakalarında güven hissi üreterek analizi erken bitirtir. İmza; dosyanın bir noktada bir anahtarla imzalandığını söyler, fakat üretim hattı ve çalışma zamanı manipülasyonlarını tek başına dışlamaz. Raporda imza, kanıt zincirinin yalnız bir parçası olarak konumlandırılmalıdır.

3.3. SBOM dışı bileşenler ve çalışma zamanı anomalileri

SBOM, yazılımın "resmi bileşen listesi"dir. Çalışma zamanında SBOM'da olmayan bir bileşenin yüklenmesi veya paketlenmesi, her zaman güçlü bir anomali sinyalidir. Neden önemli? Çünkü bu durum; yanlış paket çekilmesi, build hattında enjekte edilmiş artefakt, side-loading benzeri davranışlar veya yanlış yapılandırma gibi farklı kök nedenlere işaret edebilir.

Burada doğrulama, tek bir açıklamaya kilitlenmeden ilerler: anomaly'nin kaynağı sürüm farkı ile mi geldi, build provenancesi ile mi açıklanıyor, yoksa yalnız belirli ortamlarda mı tetikleniyor? Bu sorular hem hipotezi daraltır hem de raporun denetlenebilirliğini artırır.

4) Altyapı ve TTP korelasyonu ile kampanya analizi

Tedarik zinciri saldırıları çoğu zaman tekil olay değildir; daha geniş bir saldırı altyapısının parçası olabilir. Neden önemli? Çünkü korelasyon, savunma ekiplerinin yayılımı sınırlama ve tespit kapsamını genişletme kararlarını doğrudan etkiler.

4.1. Korelasyon iskeleti: bileşen → tüketim noktası → dış sinyaller

Korelasyonun güvenilir olması için tek bir göstergeden kaçınmak gerekir. Güçlü korelasyon, genellikle şu bağımsız bağların birlikte konuştuğu yerde oluşur:

• Bileşen bağı: aynı dependency graph bölgesi, aynı sürüm aralığı, aynı dağıtım kanalı davranışı
• Davranış bağı: benzer olay sırası, benzer veri dönüşümleri, benzer tetikleyici koşullar
• Altyapı bağı: benzer hedef sınıfları (ör. benzer alan adı desenleri/sertifika sınıfları), benzer zamanlama paternleri
• TTP bağı: davranışın teknik sınıflaması ve tekrarlayan örüntüler

Örnek: Zehirli güncellemenin çekildiği alan adı deseni "update.example.com" yerine "update.example.net" gibi beklenmedik bir varyanta kaymış görünüyor. Bu tek başına kampanya kanıtı değildir; karşı kanıt olarak meşru bir CDN/altyapı değişimi olup olmadığı araştırılır. Eğer aynı zaman penceresinde benzer davranış akışları ve provenance tutarsızlıkları da görülürse, "kampanya" hipotezi daha güvenli zemine oturur.

4.2. Sonuç dilini yönetmek: kesinlik eşiği ve raporun dayanıklılığı

Kampanya dilinde en kritik beceri, kesinlik eşiğini doğru seçmektir:

• Tek bir ortak işaret: raporda not edilir, sonuç hükmüne taşınmaz.
• En az iki bağımsız sinyal: "benzer davranış kümesi" gibi temkinli bir dille ifade edilebilir.
• Bağımsız sinyaller + meşru açıklamayı zayıflatan karşı kanıt: kampanya düzeyi risk anlatısı daha savunulabilir hale gelir.

Kanıt üretimi açısından teknik ekte şunlar net olmalıdır: analiz ortam profili, gözlem penceresi, kullanılan karşılaştırma yaklaşımı (sürüm farkı/graph analizi/davranış profili), yeniden üretilebilirlik notları ve sınırlamalar. Bu disiplin, bir sonraki aşamalarda tehdit istihbaratı eşlemesi ve ölçeklenebilir analiz hattına güçlü bir zemin hazırlar.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Tedarik zinciri analizinde “güven” varsayımlarını halkalar halinde sökerek, kök neden hipotezini doğru yere konumlandırmayı
• Triage ve yöntem seçiminde hız–kanıt dengesini yönetmeyi; diffing, provenance, SBOM ve davranış analizini birlikte konuşturmayı
• Meşru bileşen içine gömülü sapmaları “semantik” bakışla yakalayıp, gözlem–yorum ayrımıyla rapora delil olarak taşımayı
• Kampanya korelasyonunda tek göstergeden kaçınmayı; bağımsız kanıt hatları ve karşı kanıt disiplinini işletmeyi
• İmzaya, repoya veya “güvenilir” etiketlere değil; yeniden üretilebilir, denetlenebilir kanıt zincirine dayanan profesyonel çıktı üretmeyi

Modül 17 — Threat Intelligence Entegrasyonu

İleri seviye malware analizi, bir örneğin "ne yaptığını" ortaya çıkarmakla bitmez; elde edilen teknik bulguların tehdit ekosistemindeki yerini belirlemek, benzer vakalarla ilişkilendirmek ve savunma hattına aktarılabilir bir istihbarat paketine dönüştürmek profesyonel bir zorunluluktur. Bu modülde, tersine mühendislik ve dinamik analiz çıktılarının MITRE ATT&CK diliyle ifade edilmesini, aile/küme (family clustering) mantığıyla bağlanmasını ve kanıt standardı + attribution disiplini ile raporun itiraza dayanıklı hale getirilmesini ele alacağız. İleri seviye fark, "etiket koymak" değil; etiketi kanıta ve doğru kesinlik diline bağlayabilmektir.

1) ATT&CK eşleme ve TTP matrisi üretimi

ATT&CK eşleme, bir örneğin "neye benzediğini" söylemekten çok, ne yaptığını ve bunu hangi kanıtla söylediğini netleştirmektir. Savunma ekipleri tespiti bir etikete değil, davranışın gözlenebilir sinyallerine bağlar. Bu yüzden yanlış eşleme, doğrudan yanlış tespit yatırımı ve yanlış önceliklendirmeye dönüşür.

1.1. Davranışı tek bir cümleye indir: TTP'nin omurgası

TTP, taktik — teknik — prosedür üçlüsünün birleşmiş davranış örüntüsüdür. İleri seviyede ilk hamle, ATT&CK ID'sini aramak değil; davranışı "kanıtlanabilir" bir cümleye dönüştürmektir:

• Ne oldu? (gözlenen çıktı: beklenmedik süreç etkileşimi, beklenmedik ağ teması, yetki/kimlik erişimi sinyali vb.)
• Nerede oldu? (telemetri kaynağı: EDR olayı, sandbox gözlemi, bellek artefaktı, ağ kaydı)
• Hangi koşulda oldu? (tetikleyici: başlatma, belirli modül yüklenmesi, belirli yapılandırma anahtarı, zaman penceresi)

Örnek: Bir örnekte, süreç içinde beklenmedik bir modülün "dosyadan iz bırakmadan" devreye girdiği izlenimi ve ardından kısa süreli dış temas görülüyor. Bu görüntü tek başına kötü niyet kanıtı değildir; bazı meşru güvenlik/telemetri bileşenleri de benzer izler bırakabilir. Davranış cümlesi; hangi telemetride, hangi zaman penceresinde, hangi olay sırasıyla görüldüğünde daha güvenilir hale gelir. Bu omurga, ATT&CK eşlemesini rastgelelikten çıkarır.

İpucu: Her bulgu için iki satırlık mini kayıt standardı kullan:
* "Gözlem" (çıplak olay)
* "Yorum/hipotez" (ATT&CK eşlemesi ve hangi ek kanıt gelmeden kesinleşmeyeceği)>

Bu alışkanlık, rapor dilini otomatik olarak denetlenebilir kılar.

1.2. Teknik seçimi: geniş mi dar mı?

Aynı davranış birden fazla tekniğe yakın durabilir. Burada yöntem seçimi, kanıt seviyesine göre yapılır:

• Geniş teknik seçimi: Kanıt sınırlıyken daha güvenlidir; yanlış eşleme riskini azaltır. Tespit önerileri "genel davranış" düzeyinde kalır.
• Dar teknik seçimi: Kanıt güçlü ve çoklu kaynaktan geliyorsa daha değerlidir; avcılık (hunting) ve mühendislik aksiyonları daha hedefli olur. Ancak yanlış seçilirse ekipleri yanlış yöne çeker.

Dar tekniğe geçmeden önce karşı kanıtı sistematik aramak gerekir: "Bu davranış meşru bir güncelleme/telemetri/hata raporlama akışıyla açıklanabilir mi?" "İkinci bir bağımsız kanıt hattı var mı?" "Zaman çizelgesi olay sırasına oturuyor mu?"

Dikkat: ATT&CK kodu bir kanıt değil, sınıflamadır. Tek bir log satırını 'teknik kanıt' gibi sunmak, özellikle yüksek etkili tekniklerde raporun güvenilirliğini zedeler. Kanıt, sınıflamanın altında durmalıdır; sınıflama kanıtın yerine geçmemelidir.

1.3. TTP matrisi: savunma ekibinin çalışacağı çıktı

TTP matrisi, farklı ekiplerin aynı olayı ortak dilde görmesini sağlar. Pratikte güçlü bir matris, yalnız "taktik/teknik" değil; kanıtın nereden geldiğini ve güven seviyesini de taşır.

Önerilen alanlar:

• Taktik / Teknik
• Kanıt özeti (telemetri referansı + kısa davranış cümlesi)
• Güven seviyesi (düşük/orta/yüksek)
• Karşı kanıt notu (masum açıklama ihtimali ve neden zayıfladığı)
• Zaman penceresi (ilk görüldü — son görüldü)
• "Tespit sinyali" notu (SOC/EDR açısından hangi davranış izlenebilir?)

Örnek: "Kısa süreli dış temas" bulgusunda yalnız hedefi yazmak yetmez; hedef sınıfının meşru bir servis altyapısı olma ihtimali matriste görünür olmalıdır. Böylece rapor, tek bir altyapı benzerliğine kilitlenmez.

İpucu: Matrise "hangi tespit sinyali üretir?" satırını eklemek, Blue Team entegrasyonunu hızlandırır. Orta seviye modüllerdeki kontrol listeleri burada yeniden anlatılmayacak; kritik olan, sinyali TTP'ye bağlayan delilin kalitesidir.

1.4. Doğrulama: eşleme itiraza dayanıklı mı?

İleri seviyede doğrulama, "gördüm" ile "kanıtladım" arasını disiplinle doldurur:

• Çapraz kaynak doğrulaması: Aynı davranış iki farklı telemetri sınıfında da var mı?
• Zaman tutarlılığı: Teknik iddia, olay sırasına oturuyor mu?
• Çevresel değişkenler: Davranış yalnız belirli ortamlarda mı tetikleniyor? Bu, meşru bir konfigürasyonla açıklanabilir mi?

Bu sorular, "etiket" yerine "kanıt" merkezli düşünmeyi zorunlu kılar.

2) Family clustering: kod, config ve altyapı benzerlikleri

Yeni bir örnek geldiğinde analistin zihnindeki ilk soru genellikle şudur: "Bu daha önce gördüğümüz bir şeye mi benziyor?" Clustering, benzer örnekleri aile/küme altında toplayarak kampanya görünürlüğü sağlar; fakat yanlış kümelenme, yanlış attribution ve yanlış tespit stratejisine dönüşebilir.

2.1. Üç benzerlik hattı: ne zaman hangisi?

Kod benzerliği; fonksiyon akışı, tekrar eden motifler ve semantik yapı üzerinden çalışır. Güçlü yanı davranışın "nasıl yapıldığını" yakalamasıdır; sınırı ise yoğun obfuscation/packing altında yanıltıcı olabilmesi ve ortak kütüphanelerin sahte benzerlik üretmesidir.

Config benzerliği; yapılandırma anahtarları, şemalar, "mod" seçenekleri ve veri düzeniyle ortaya çıkar. Kod değişse bile saldırganın operasyonel alışkanlıkları değişmeyebilir. Sınırı, otomatik üretim araçlarının benzer şemalar çıkarabilmesi ve tek başına aile kanıtı sayılmamasıdır.

Altyapı (infra) benzerliği; alan adı desenleri, sertifika sınıfları, zamanlama paternleri ve (gerektiğinde) dokümantasyon amaçlı örnek IP bloklarıyla değerlendirilir. Hızlı triage sinyali sağlar; ancak paylaşımlı barındırma, yeniden kullanılan altyapı veya ele geçirilmiş meşru altyapı yanıltıcı ortaklıklar üretebilir.

Yöntem seçimi bağlama göre gerekçelendirilmelidir: çok sayıda örnek hızlı sınıflanacaksa config/infra öne çıkar; kalıcı tespit ve adli rapor üretilecekse code + config hattında daha yüksek standart aranır.

Dikkat: "Aynı IP'ye bağlandı → aynı aile" kısa devre çıkarımı kırılgandır. Infra benzerliği çoğu zaman başlangıç sinyalidir; sonuç cümlesi değildir.

2.2. Kod benzerliğinde yöntem seçimi: ham iz mi, semantik iz mi?

Kod benzerliği için farklı yöntem aileleri vardır:

• Esnek özetleme (fuzzy hashing): Benzer dosyalarda yakın sonuçlar verebilir; hızlı triage için değerlidir.
• Fonksiyonel imzalama / fonksiyon kimliği: Fonksiyon seviyesinde karşılaştırma yaparak daha rafine sinyal üretebilir.
• Semantik karşılaştırma: Obfuscation/packing altında ham dosya benzerliği zayıfladığında, decompile/akış düzeyindeki mantıksal yapıya odaklanır.

Burada doğrulama, "çıkan benzerlik puanı" ile bitmez. Karşı kanıt olarak, benzerliğin ortak bir açık kaynak bileşenden veya yaygın bir kütüphaneden kaynaklanıp kaynaklanmadığı sorgulanır.

2.3. Config ve infra örüntüleri: saldırganın "alışkanlıkları"

Kod tamamen değişse bile, saldırganın operasyonel tercihleri çoğu zaman tekrar eder.

Örnek: Bir kümede, yapılandırma bloklarının her sürümde farklı anahtarla ama aynı dönüşüm mantığıyla korunması ve C2 bilgilerinin tutarlı bir şema içinde saklanması gözlenir. Bu, aile atfı için değerli bir davranışsal örüntüdür; ancak tek başına "kesin aile" ilanı yerine, diğer kanıt hatlarıyla birlikte değerlendirilmelidir.

Bu noktada "false flag" riski de gündeme gelir. Bazı saldırganlar analisti yanlış yöne çekmek için bilinen başka grupların yüzeysel izlerini taklit edebilir: kolay değiştirilebilir metaveriler, kasıtlı bırakılmış belirgin ipuçları, yaygın açık kaynak profil/şablonlarının kullanımı gibi.

İpucu: "False flag" şüphesini test etmek için tutarlılık avı yap: yüzeyde çok "bağıran" ipuçları varken, kodun derinindeki karmaşıklık ve operasyonel disiplin o ipuçlarıyla çelişiyor mu? Tutarsızlık, karşı kanıt arayışını tetikleyen değerli bir sinyaldir.

2.4. Benzerlik iddiasını kanıtlamak: ölçüt — eşik — karşı kanıt

"Benziyor" demek yetmez; "hangi ölçütle benziyor?" sorusu raporu profesyonelleştirir.

• Ölçüt (feature): Hangi sinyaller benzerlik kanıtı sayılıyor?
• Eşik (threshold): Ne olursa "aynı küme" diyeceksin?
• Karşı kanıt: Ortak bağımlılık/ortak altyapı gibi masum açıklamalar nasıl eleniyor?

Örnek: İki örnekte aynı config alan adları ve "updates.example.net" benzeri desen taşıyan dış temaslar görülür. Bu, hızlı triage için küme adayıdır. Karşı kanıt arayışı; bu config şemasının yaygın bir bileşenden geliyor olma ihtimalini ve alan adı deseninin meşru bir güncelleme altyapısına ait olma ihtimalini değerlendirir. Eğer kod hattında da tutarlı semantik akış ortaklıkları bulunuyorsa küme iddiası güçlenir; aksi halde rapor dili "benzer davranış kümeciği" gibi daha temkinli kalır.

2.5. Küme çıktısı: isimlendirme ve süreklilik

Kümeler zamanla genişler, bölünür veya revize edilir. Bu yüzden çıktıda:

• Kesin aile dilinden kaçınan, evrimleşebilir bir isimlendirme
• "Bu tarihe kadar şu örnekler dahil" şeklinde kapsam notu
• Yeni örnek geldiğinde hangi ölçütlerle dahil edileceğinin kısa kural seti
• Yeni kanıt geldiğinde geriye dönük düzeltmeye açık olunduğunun belirtilmesi

Bu yaklaşım, Modül 18'deki ölçeklenebilir analiz hattında otomasyonun en çok ihtiyaç duyduğu şeyi sağlar: tutarlı karar kuralları.

3) Kanıt standardı ve attribution disiplini

Attribution, "kim yaptı?" sorusuna cevap verme iddiasıdır ve en çok hata üreten alandır. Teknik analistin görevi politik yorum yapmak değil; teknik parmak izlerini tarafsız ve denetlenebilir biçimde sunmaktır. Bu modülde attribution, "cesur etiket" değil; kanıt seviyesine uygun kesinlik dili olarak ele alınır.

3.1. Güven seviyeleri: dili kanıtına uydur

• Düşük güven: Tekil sinyal, sınırlı telemetri; alternatif açıklamalar güçlü
• Orta güven: En az iki bağımsız kanıt hattı; alternatif açıklamalar kısmen zayıflatılmış
• Yüksek güven: Çoklu bağımsız kanıt + zaman çizelgesi tutarlılığı + alternatif açıklamalar için güçlü karşı kanıt

Bazı göstergeler manipülasyona daha açıktır: derleme zamanı, dil/saat dilimi, yüzeysel metaveriler gibi. Bunlar not edilir; fakat tek başına fail tayinine taşınmaz.

3.2. Gözlem-yorum ayrımı, zaman çizelgesi ve yeniden üretilebilirlik

İstihbarat çıktısı, başka analistlerin de aynı sonuca ulaşabileceği biçimde paketlenmelidir:

• Ham gözlemler ve telemetri referansları
• Eşleme/yorum ve bunun gerekçesi
• Zaman çizelgesi (önce — sonra ilişkisi)
• Analiz ortam profili ve gözlem penceresi
• "Bu sonucun sınırları" (hangi veri eksikleri var, hangi alternatif açıklamalar kaldı)

Bu disiplin, raporun teknik ekini güçlendirir ve itirazlara dayanıklılığı artırır.

3.3. Veri paylaşımı ve operasyonel gizlilik: yöntem seçimi

Tehdit istihbaratı, çoğu zaman paylaşım ve standardizasyona dayanır. Makinelerce okunabilir formatlar (ör. istihbarat paylaşım standartları) kurumsal iş birliğini kolaylaştırır; ancak paylaşımın riskleri de vardır.

• Hedefli saldırı şüphesinde, dosya/artefaktı çevrimiçi analiz platformlarına yüklemek saldırgana "izlendiğini" hissettirebilir.
• Bu tür durumlarda yöntem seçimi; mümkünse önce "düşük ifşa" yaklaşımıyla (ör. yalnız özet sorguları, yerel laboratuvar analizi) ilerlemek, sonra kurumsal gizlilik protokolleriyle uyumlu şekilde paylaşımı planlamaktır.

Dikkat: Hedefli saldırı şüphesi olan vakalarda kontrolsüz paylaşım, savunmayı güçlendirmek yerine operasyonel riski büyütebilir. "Daha hızlı sonuç" motivasyonu, gizlilik maliyetini gölgelememelidir.

3.4. "False flag" ve yanıltıcı izler: attribution'da karşı kanıt

Attribution iddiaları, saldırganın bilinçli yanıltma çabalarına açık bir alandır. Burada karşı kanıt aramak, "olabilir" denen şeyin ne kadar dayanıklı olduğunu test etmektir:

• Yüzeysel izler (metaveri, kolay değişen göstergeler) ile derin teknik izler (tutarlı davranış zinciri, özgün protokol/algoritmik tercih, operasyonel disiplin) birbiriyle uyumlu mu?
• Bir kanıt sınıfı "fazla iyi oturuyorsa", bunun kasıtlı bir sahneleme olup olamayacağı da düşünülür.

3.5. Zaman içinde evrim: varyant takibi neden önemli?

Aileler zamanla evrilir: yeni kaçınma örüntüleri, yeni hedefler, yeni altyapı tercihleri görülebilir. Varyantların evrimsel takibi; savunmaya proaktif değer katar: "Bir sonraki sürümde ne tür davranış değişimi beklenebilir?" sorusuna daha hazırlıklı cevap verilir.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Teknik bulguları ATT&CK üzerinde kanıta dayalı biçimde konumlandırmayı ve çalışılabilir bir TTP matrisi üretmeyi
• Eşleme ve kümeleme kararlarında doğrulama ve karşı kanıt arama disiplinini işletmeyi
• Kod/config/infra benzerliklerini bağlama göre seçip, ölçüt–eşik mantığıyla denetlenebilir clustering çıktısı üretmeyi
• Attribution iddialarını güven seviyesiyle uyumlu bir dille yönetmeyi ve “false flag” riskini tutarlılık analiziyle ele almayı
• İstihbarat paketini zaman çizelgesi, yeniden üretilebilirlik notları ve gizlilik farkındalığıyla savunma hattına entegre etmeyi

Modül 18 — Ölçeklenebilir Analiz ve Otomasyon

Bu modül, tek tek örnekleri "usta işi" analiz etmekten daha zor bir problemi hedefler: aynı kalite standardını koruyarak çok sayıda örneği ve çok sayıda telemetri kaynağını sürdürülebilir biçimde işleyebilmek. Triage'dan başlayıp detonasyon, çıkarım, zenginleştirme ve raporlamaya uzanan hattın tasarımını; tekrar eden RE işlerinin otomasyonla yönetilmesini ve sandbox stratejisinin kurumsal ekosisteme doğru şekilde bağlanmasını ele alır.

1) Analiz hattı tasarımı: triage → detonation → extraction → enrichment → reporting

Bir analiz hattı, üretim bandına benzer: kalite, tek bir istasyonda değil, istasyonlar arası standart ve aktarım disiplininde kazanılır. Burada amaç "en hızlı" hat değil, yanlış negatif/yanlış pozitif maliyetini kontrol eden ve her adımda bulguyu doğrulayabilen bir hat kurmaktır.

1.1. Triage: hız — derinlik dengesini kurmak

Triage, örneği "önemli/önemsiz" diye etiketlemekten çok, hangi analize ne kadar kaynak ayrılacağını belirleyen bir karar kapısıdır. Neden önemli? Çünkü hat, sınırlı CPU/VM/sandbox süresiyle çalışır; yanlış sınıflama ya pahalı derin analizleri boşa harcar ya da kritik örnekleri kaçırır.

Triage çıktısının iyi bir standardı şunları taşır:

• Öncelik gerekçesi: hangi sinyaller bu örneği öne çekti?
• Risk notu: hedefli saldırı şüphesi, veri sızdırma riski, yüksek etki ihtimali
• Bir sonraki adım kararı: detonasyon profili mi, doğrudan statik/RE kuyruğu mu, bekletme mi?

Örnek: Bir dosya, görünürde "güncelleme aracı" gibi paketlenmiş; ancak içindeki yapılandırma parçaları sıra dışı ölçüde dallanmış ve çalıştırma koşulları çevresel değişkenlere bağlı görünüyor. Bu, triage aşamasında "normal yazılım olabilir" karşı açıklamasını akılda tutarak, detonasyonun birden fazla ortam profiliyle planlanmasını gerektirir.

İpucu: Triage kararlarını "tek sinyal" ile vermek yerine, sinyalleri kanıt sınıflarına ayır: statik bulgular, dinamik sinyaller, çevresel bağlam (kampanya, benzerlik, olay akışı). Aynı sınıftan iki sinyal, iki farklı sınıftan birer sinyal kadar güçlü olmayabilir.

1.2. Detonation: gözlem üretmek mi, kanıt üretmek mi?

Detonasyon (kontrollü çalıştırma), "çalıştı/çalışmadı" demek için değil, savunma açısından anlamlı gözlem seti üretmek içindir. Neden önemli? Çünkü birçok örnek yalnız belirli koşullarda davranış gösterir; yanlış profil seçimi, "temiz" izlenimi vererek hatalı güven duygusu yaratır.

Detonasyon tasarımında yöntem seçimi üç eksende yapılır:

• Gözlem kapsamı: hangi telemetri türleri şart (süreç, bellek sinyali, ağ davranışı, dosya/registry değişimi vb.)
• Profil çeşitliliği: tek profil mi, farklı dil/yerel ayar/izin seti gibi profiller mi?
• Maliyet: geniş gözlem daha pahalıdır; triage puanı düşük örneğe "tam kapsam" vermek hattı kilitleyebilir.

Örnek: Bir örnek, kısa süreli ağ temaslarını yalnız "ilk çalıştırmadan birkaç dakika sonra" yapıyor gibi görünüyor. Bu durumda detonasyon süresi uzatılmadan "temiz" sonucu çıkarmak risklidir; öte yandan her örneği uzun süre koşturmak da ölçeği bozar. Çözüm, triage puanı yüksek örneklerde daha uzun pencereler, düşüklerde daha kısa ama kanıt odaklı pencereler tanımlamaktır.

Dikkat: "Sandbox'ta bir şey yapmadı" sonucu, çoğu zaman bir sonuca değil bir soruya işaret eder: "Hangi koşul eksik olabilir?" Bu karşı kanıtı aramadan "temiz" hükmü kurmak, hattın en sık yaptığı pahalı hatalardandır.

1.3. Extraction: artefakt çıkarımı ve delile dönüştürülebilir ham veri

Extraction, detonasyon ve statik/RE süreçlerinden üretilen ham verinin, sonraki adımlarda tutarlı biçimde işlenebilmesi için normalize edilmesidir. Neden önemli? Çünkü zenginleştirme ve raporlama, ham veriye değil; ham verinin kaynağı belli, zamanı belli, tekrar üretilebilir haline dayanır.

İyi bir extraction standardı şunları içerir:

• Kaynak bilgisi: hangi sensörden/telemetri sınıfından geldi?
• Zaman damgası: olayın sırası ve penceresi
• Bağlam: hangi profil/ortam altında üretildi?
• Ham — işlenmiş ayrımı: orijinal kayıt + normalize edilmiş özet birlikte saklanır

Bu temelin kontrol listesini Orta Seviye dinamik analiz ve SOC bağlamında ayrıntılı işlemiştik; burada kritik nokta, extraction çıktısının kanıt zinciri taşımasıdır.

1.4. Enrichment: bağlam eklerken "yanlış hikâye" üretmemek

Enrichment, IOC/artefaktları dış ve iç bilgi kaynaklarıyla bağlama oturtma işidir. Neden önemli? Çünkü avcılık ve önceliklendirme kararları, çoğu zaman bu bağlama göre alınır; ama enrichment aynı zamanda yanıltıcı korelasyon riski taşır.

Yöntem seçimi, enrichment kaynağının güvenilirliğine ve güncelliğine göre yapılır:

• İç kaynaklar: kurumsal olay geçmişi, EDR/SIEM kayıtları, daha önceki analiz arşivi
• Dış kaynaklar: tehdit istihbaratı notları, bilinen altyapı/sertifika kümeleri, genel reputasyon sinyalleri

Doğrulama disiplinini burada özellikle hissetmek gerekir: bir alan adının "kötü şöhretli" görünmesi, örneğin o alan adıyla gerçekten nasıl etkileştiğini ispatlamaz. Karşı kanıt olarak, altyapının paylaşımlı servis/CDN olma ihtimali veya ele geçirilmiş meşru altyapı olasılığı düşünülür.

Örnek: Bir örnek, updates.example.net benzeri bir ada temas ediyor. Dış kaynaklar bu desene dair olumsuz notlar içeriyor olabilir; ancak bu tek başına yeterli değildir. Trafik paternleri, zamanlama, DNS çözümleme tutarlılığı ve diğer telemetriyle uyum aranır. Uyum yoksa, "enrichment sinyali" raporda temkinli konumlandırılır.

İpucu: Enrichment sonuçlarını "kanıt" ve "bağlam" diye ikiye ayır. Bağlam, kanıtın üzerine inşa edilir; kanıt, bağlamın gölgesinde bırakılmaz. Bu ayrım raporda yanlış kesinliği otomatik olarak azaltır.

1.5. Reporting: sonuç yazmak değil, kanıt paketi üretmek

Reporting, hattın en görünür çıktısıdır; fakat en çok da burada hata yapılır: yorum, gözlem gibi; bağlam, kanıt gibi yazılır. Neden önemli? Çünkü rapor, başka ekiplerin (SOC/DFIR/mühendislik/yönetim) aksiyon aldığı belgedir; dayanıklılık, "iyi yazı"dan değil delil paketinden gelir.

Raporun hat üzerinde üretilen en kritik ekleri:

• Gözlem — yorum ayrımı: her iddianın dayandığı telemetri referansı açık
• Zaman çizelgesi: olay sırası, pencereler, profil bilgisi
• Yeniden üretilebilirlik notu: hangi ortam profili, hangi gözlem kapsamı, hangi sürüm/konfigürasyon
• Bulgudan aksiyona köprü: tespit önerileri, avcılık hipotezleri, önceliklendirme gerekçesi

Dikkat: "Otomasyon üretti" diye bir bulguyu rapora kesin hüküm gibi koymak, ölçek büyüdükçe güven kaybına yol açar. Otomasyon çıktısı rapora girecekse, yanında mutlaka "hangi veriyle üretildiği" ve "hangi koşulda yanlışlanabileceği" yazmalıdır.

1.6. Hat sağlığı: kuyruklar, tekrar deneme, hata sınıfları

Ölçeklenebilirlik yalnızca işlem gücüyle değil, hatanın yönetimiyle sağlanır. Aynı örnek tekrar geldiğinde aynı sonucu üretmeye yatkın olmak (tutarlılık), adli değeri yükseltir. Hata sınıflarını en baştan tanımlamak, "hattın tıkanmasını" engeller:

• Geçici hata: kaynak yok, zaman aşımı, ortam hazır değil
• Veri hatası: bozuk artefakt, eksik telemetri, uyumsuz format
• Yöntem hatası: yanlış profil seçimi, yanlış önceliklendirme varsayımı
• Şüpheli sonuç: otomasyon kararsız, karşı kanıt güçlü

Bu sınıflar, yeniden deneme stratejisini ve "analiste escalate" kararını belirler.

2) RE otomasyonu ve tekrarlı işlerin scripting ile yönetimi

Otomasyon, analistin yerine karar vermek için değil; analistin karar vermesini hızlandıracak tekrar eden işleri güvenilir biçimde yapması için vardır. İleri seviye fark, otomasyonu "ne kadar çok yazdığın" değil; nerede duracağını bildiğin noktada ortaya çıkar.

2.1. Otomasyona uygun işler: deterministik olanı makineye ver

RE tarafında otomasyona en uygun işler genelde deterministik veya ölçülebilir çıktı üreten işlerdir:

• Artefakt indeksleme: fonksiyon/akış düğümleri, referans zincirleri, yapılandırma adayları
• Tekrarlı çıkarımlar: belirli yapıların normalize edilmesi, benzer örnekler arası karşılaştırma için "özellik" üretimi
• Rapor ekleri: zaman çizelgesi iskeleti, kanıt referanslarının listelenmesi, çıktı paketleme

Buna karşılık, otomasyonun tek başına iyi yapamadığı alanlar:

• Belirsiz hipotezler: "bu davranışın amacı ne olabilir?"
• Çelişkili sinyaller: aynı anda hem meşru hem şüpheli açıklama mümkünse
• Yüksek riskli atıflar: attribution dili ve güven seviyesi

Bu temelin kritiğini Modül 17'de istihbarat entegrasyonu bağlamında hissetmiştin; burada aynı mantık hattın her adımına yayılır.

2.2. Yöntem seçimi: hızlı heuristik mi, yavaş ama sağlam mı?

Aynı probleme giden iki yol vardır:

• Hızlı heuristik yaklaşım: ölçeği büyütür, erken sinyal verir; fakat yanlış pozitif maliyeti artabilir.
• Yüksek doğruluk yaklaşımı: daha pahalıdır, daha az örneğe uygulanır; ama rapor kalitesini yükseltir.

Doğru seçim, triage puanı ve hedeflenen çıktı türüne bağlıdır:

• Avcılık hipotezi üretmek için hızlı yaklaşım değerlidir.
• Adli rapor ve kalıcı tespit önerisi üretmek için sağlam yaklaşım gerekir.

Örnek: Bir örnek kümesinde benzerlik sinyalleri hızlıca görülebiliyor, ancak bazı örnekler yoğun karartma altında. Bu durumda hızlı benzerlik sinyalleri "küme adayı" üretir; sağlam yaklaşım, yalnız bu adayların küçük bir alt kümesinde çalıştırılarak yanlış kümelenme riski azaltılır.

2.3. Doğrulama: otomasyon çıktısı nasıl yanlışlanır?

Otomasyonda en kritik soru şudur: "Bu çıktı hangi koşulda yanlıştır?" Yanlışlama kuralı yazılmayan otomasyon, ölçek büyüdükçe güvenilmezleşir.

Doğrulama yaklaşımı:

• Çapraz kontrol: aynı bulgu farklı veri sınıfında destekleniyor mu?
• Eşik ve belirsizlik: çıktının güven aralığı veya belirsizlik notu var mı?
• Karşı kanıt: meşru açıklama ihtimali otomasyon tarafından bayraklanabiliyor mu, yoksa analiste mi bırakılıyor?

İpucu: Otomasyon çıktısına "kırmızı bayraklar" ekle: belirsiz sonuç, eksik telemetri, çelişkili sinyal, profil uyumsuzluğu. Bu bayraklar, analistin zamanını doğru yere harcatır.

2.4. Sürümleme ve test: hatayı büyütmemek

Otomasyonun en tehlikeli tarafı, bir hatayı binlerce örneğe yayabilmesidir. Bu nedenle:

• Değişiklikler sürümlenir ve geriye dönük kıyas yapılabilir olmalıdır.
• Test örnek havuzu, farklı aile/format/profil çeşitliliği içermelidir.
• Çıktılar "aynı girdiye aynı sonuç" tutarlılığı açısından izlenmelidir.

Burada amaç yazılım mühendisliği dersi vermek değil; RE otomasyonunun adli/operasyonel etkisini koruyacak disiplinin kurulmasıdır.

2.5. Kanıt üretimi: loglar ve artefakt izleri

Otomasyonun rapora delil olacak çıktılar üretebilmesi için:

• Hangi veriyi okuduğu, hangi dönüşümü yaptığı, hangi kaynakta hangi referansı kullandığı kaydedilir.
• Ham veri saklanır; işlenmiş özet yanında tutulur.
• Sonucun üretildiği zaman ve ortam profili not edilir.

Bu yaklaşım, raporda "çıktı" ile "çıktıyı doğuran süreç" arasındaki bağı şeffaf hale getirir.

3) Sandbox stratejisi ve kurumsal entegrasyon yaklaşımı

Sandbox stratejisi, tek bir araç seçimi değildir; "hangi riskte hangi gözlem kapsamı" kararları bütünüdür. Kurumsal entegrasyon ise sandbox'ı bir ada olmaktan çıkarıp SOC/DFIR/mühendislik akışına bağlar.

3.1. Sandbox profili: gözlem kalitesi ve güvenlik izolasyonu

Sandbox'ın amacı, örneği güvenle izlemek ve izlenebilir davranış sinyali üretmektir. Neden önemli? Çünkü izolasyon zayıfsa risk büyür; gözlem zayıfsa yanlış negatif artar.

Yöntem seçimi:

• İzolasyonu artıran yaklaşımlar, gözlemi kısıtlayabilir.
• Gözlemi artıran yaklaşımlar, maliyeti ve operasyonel karmaşıklığı yükseltebilir.

Bu denge triage puanı ve hedeflenen çıktı türüne göre kurulmalıdır.

3.2. Profil çeşitliliği: tek ortamla genelleme yapmak risklidir

Bazı örnekler yalnız belirli yerel ayar, izin düzeyi veya çevresel koşullarda davranış gösterir. Ölçeklenebilir hat, "her örneğe her profil" yerine:

• Önce temel profil
• Sinyal varsa genişletilmiş profil seti
• Şüphe varsa hedefe uygun özel profil

mantığıyla ilerler.

Doğrulama açısından kritik nokta: bir davranış yalnız tek profilde görülüyorsa, karşı kanıt olarak "profil kaynaklı artefakt" olasılığı düşünülür.

3.3. Telemetri stratejisi: sinyali tespit diline çevirmek

Sandbox telemetrisi, doğrudan rapor değil; raporun hammaddesidir. Kurumsal kullanım için telemetri şu özelliklere sahip olmalıdır:

• Zaman çizelgesine oturabilirlik
• Olayların ilişkilendirilebilir olması (aynı örnek, aynı profil, aynı çalışma penceresi)
• Tespit önerilerine dönüşebilirlik (hangi sinyal hangi kontrol/algılama hattına bağlanır?)

Bu, Modül 19'daki raporlama standardına doğal bir zemin hazırlar: telemetri "güzel bir çıktı" değil, "delil" haline gelir.

3.4. Kurumsal entegrasyon: SIEM/SOAR/EDR ile ortak dil

Sandbox tek başına değer üretmez; değer, çıktının tüketilmesiyle oluşur. Kurumsal entegrasyonda üç hedef öne çıkar:

• SOC için: avcılık hipotezleri, tespit sinyalleri, önceliklendirme notları
• DFIR için: olay akışı, kanıt referansları, yeniden üretilebilirlik notları
• Mühendislik için: kalıcı kontrol önerileri, zayıf nokta analizi, izleme kapsamı

Burada yöntem seçimi, "en çok entegrasyon" değil; "en az sürtünmeyle doğru aksiyon" prensibine dayanmalıdır.

Dikkat: Entegrasyonda "her şeyi aktaralım" yaklaşımı veri gürültüsü üretir. Gürültü arttıkça gerçek sinyal kaybolur. Hattın sağlığı için, hangi verinin kim tarafından nasıl tüketileceği baştan tanımlanmalıdır.

3.5. Gizlilik ve paylaşım disiplini: hedefli vakalarda görünürlük maliyeti

Hedefli saldırı şüphesinde, sandbox çıktılarının dış platformlarla paylaşımı veya kontrolsüz yayılması operasyonel risk doğurabilir. Bu nedenle:

• Paylaşım seviyeleri belirlenir (iç ekip, sınırlı paydaş, dış paylaşım)
• Redaksiyon/anonimleştirme kuralları uygulanır
• "Gizlilik maliyeti" raporun bir parçası olarak değerlendirilir

Bu yaklaşım, hem kurumsal riski azaltır hem de raporun güvenilirliğini artırır.

3.6. Geri besleme döngüsü: hat, kendini iyileştirmelidir

Ölçeklenebilir hatlar statik kalmaz:

• Yanlış pozitifler ve kaçan örnekler incelenir
• Triage kuralları ve profil seçimleri revize edilir
• Otomasyonun yanlışlama kriterleri güçlendirilir
• Rapor formatı, tüketici ekibin ihtiyaçlarına göre iyileştirilir

Bu döngü kurulmadığında hat, zamanla "çok çalışıyor ama az değer üretiyor" noktasına sürüklenir.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Ölçeklenebilir analiz hattının, istasyonlar arası standart ve kanıt zinciriyle güçlendiğini
• Triage’ın, hız–derinlik dengesini ve profil/işleme kararlarını belirleyen kritik kapı olduğunu
• Detonasyonun “negatif sonuç”larını karşı kanıt arayışıyla yönetmeden kesin hükme dönüşmemesi gerektiğini
• Extraction ve enrichment aşamalarında kaynak–zaman–bağlam disiplininin rapor dayanıklılığını belirlediğini
• Otomasyonda yöntem seçiminin triage ve hedef çıktıya bağlı olduğunu; otomasyon çıktısının yanlışlama koşullarıyla rapora girmesi gerektiğini
• Sandbox stratejisinin profil çeşitliliği, telemetri kalitesi ve kurumsal tüketim (SIEM/SOAR/EDR) ihtiyaçlarıyla birlikte tasarlanması gerektiğini
• Hattın kalitesinin, geri besleme döngüsüyle sürdürülebilir biçimde iyileştirildiğini

Modül 19 — İleri Raporlama ve Profesyonel Çıktılar

İleri malware analizi ve tersine mühendislikte gerçek değer, laboratuvarda elde edilen bulguların kurumsal savunmada uygulanabilir kararlara dönüşmesiyle ortaya çıkar. Bu modül; raporun yalnızca "bulgu listesi" değil, kanıt standardı yüksek, denetlenebilir, yeniden üretilebilir bir çıktı olmasını; IOC paketinin ve tespit önerilerinin ise savunma mimarisine oturan operasyonel yol haritaları haline gelmesini hedefler. İleri seviye fark burada görünür: aynı veriyi herkes toplayabilir; ama herkes onu doğru kesinlik diliyle paketleyip, farklı ekiplerin (SOC/DFIR/mühendislik/yönetim) kullanabileceği biçimde teslim edemez.

1) Profesyonel rapor iskeleti ve "iki okur" problemi

Aynı raporu iki farklı okur tipi tüketir: teknik derinlik arayan uzmanlar ve hızlı karar almak isteyen yöneticiler. Bu nedenle raporlama, tek bir tonla "herkese hitap etme" çabasından ziyade katmanlı bir tasarım ister.

• Yönetici katmanı, iş etkisini ve öncelikleri taşır; teknik ayrıntıyı boğmaz.
• Teknik katman, iddiaları kanıtla bağlar; "gözlem — yorum" ayrımını kaybetmez.

Yöntem seçimi burada belirgindir: bazı vakalarda tek bir rapor içinde katmanlandırma yeterlidir; yüksek gizlilikli veya çok paydaşlı süreçlerde ise yönetici özeti ayrı, teknik ek ayrı dağıtılır.

Örnek: Bir kurumda "veri sızıntısı riski" kararının 30 saniyede anlaşılması gerekirken, DFIR ekibi aynı olayın hangi telemetri penceresinde doğrulandığını görmek ister. Katmanlı rapor, iki ihtiyacı aynı anda karşılar.

İpucu: Yönetici özeti yazarken "ne oldu / etkisi ne / şu an risk seviyesi ne / ilk yapılacak 3 şey ne" akışı, raporun kurumsal değerini ciddi biçimde artırır.

2) Teknik ek standardı: kritik fonksiyonlar, akış şemaları, decode notları

Teknik ek, raporun "süs" kısmı değil; iddiaların ispat zeminidir. Neden önemli? Çünkü ileri seviye rapor, "ne oldu" kadar "nasıl biliyoruz" sorusunu da taşır.

2.1. Kritik fonksiyon seçimi: her fonksiyon değil, "kararı taşıyan" fonksiyon

Tersine mühendislikte yüzlerce fonksiyon görülebilir; teknik ek ise seçici olmak zorundadır. Fonksiyon seçimi, raporun hedef çıktısına göre yapılır:

• Tespit odaklı rapor: davranış sinyali üreten fonksiyonlar (konfigürasyon okuma, iletişim başlatma, kalıcılık tetikleme gibi)
• Adli rapor: olay akışındaki düğümler (kritik karar noktaları, çözülen verinin kullanıldığı yerler)
• Korelasyon/istihbarat odaklı rapor: özgünlük taşıyan, varyantlar arası benzerlik kurulabilen parmak izi nitelikleri

Doğrulama disiplininin sorusu nettir: "Bu fonksiyon kritik" iddiası hangi kanıta dayanıyor? Karşı kanıt ararken iki risk sık görülür:

• Meşru kütüphane davranışını "kötü niyet" sanmak
• Decompiler çıktısını gerçeğin kendisi gibi kabul etmek

Örnek: "Decoder gibi görünen" bir fonksiyon bazı sıkıştırma/serileştirme kütüphanelerinde de benzer izler bırakabilir. Bu yüzden teknik ekte, fonksiyonun yalnız biçimini değil; çıktısının nerede kullanıldığını ve davranışı nasıl tetiklediğini göstermek, raporu itiraza dayanıklı kılar.

İpucu: Teknik ek için fonksiyon seçerken üç filtre sorusu kullan:

1. — Bu parça çıkarılırsa ana iddia zayıflar mı?
2. — Tespit önerisine sinyal üretiyor mu?
3. — Yeniden üretilebilirlik için referans noktası mı?

2.2. Akış şemaları: okunabilirlikten öte, iddia — kanıt köprüsü

Akış şeması kodun tamamını çizmek değildir; karar düğümlerini, koşula bağlı davranışları ve veri akışını görünür kılmaktır. Neden önemli? Çünkü Blue Team tarafında "hangi koşulda ne oldu?" sorusu çoğu zaman "hangi sinyali nerede arayacağım?" sorusuna dönüşür.

Yöntem seçimi iki uç arasında yapılır:

• Minimal akış: yalnız ana patika + kritik dallar; hızlı tüketim, düşük gürültü
• Zengin akış: alternatif tetikleyiciler, hata kolları, çevresel koşullar; daha güçlü doğrulama

Doğrulama açısından iyi bir pratik: şemadaki her düğümün, decompile edilmiş koddaki ilgili karar yapısıyla tutarlı olması beklenir. Eğer bir yol statik olarak ulaşılamaz görünüyorsa, bu durum "karşı kanıt" olarak not edilir ve yöntem seçimi dinamik gözleme kaydırılır.

2.3. Decode notları ve veri yapıları: "sonuç" değil, ispat zinciri

Obfuscation/packing/in-memory karmaşasında çözülen veriler rapora taşınırken en çok hata, "çıktı doğruymuş gibi" davranıldığında oluşur. Decode notu, çözümlemenin tahmin değil ispat olduğunu göstermek için vardır.

Beklenen kanıt standardı:

• Çözülmüş verinin davranışla tutarlılığı (ör. çalışma modları, konfigürasyon alanları ve gözlenen eylemler uyumlu mu?)
• Çapraz kanıt (aynı değer farklı telemetri sınıflarıyla destekleniyor mu?)
• Karşı kanıt arayışı (çıktı rastgele veri, masum string havuzu veya yanlış ayrıştırma olabilir mi?)

Örnek: Bir yapılandırma bloğunda "mod=telemetry" benzeri bir alan görülür. Tek başına kötü niyet kanıtı saymak yerine, bu alanın varlığında süreç davranışında ölçülebilir bir değişim olup olmadığına bakılır; varsa "gözlem — yorum" ayrımıyla raporlanır.

Dikkat: Teknik ekte "mikroskobik ayrıntı" artarken, raporun hedefi unutulursa okur bunu "gösteriş" gibi algılar. Her teknik ayrıntı, mutlaka bir iddiayı kanıtlamalı veya bir tespit önerisini gerekçelendirmelidir.

3) IOC paketi, zaman çizelgesi ve tespit önerileri: listedən mimariye

İleri seviye IOC yönetimi, statik göstergelerin ötesinde saldırganın davranış kalıbını taşır. Bu temelin temel kontrol listesini Orta Seviye SOC modüllerinde ayrıntılı işlemiştik; burada odak, IOC'yi "ek" olmaktan çıkarıp tespit mühendisliğine bağlamaktır.

3.1. Davranış odaklı IOC paketlemesi

Bir saldırganın küçük değişikliklerle (ör. yeniden paketleme) statik göstergeleri geçersiz kılabildiği senaryolarda, kalıcı değer davranışsal imzalardadır. Yöntem seçimi burada nettir:

• Statik IOC'ler: hızlı triage ve kısa vadeli bloklama için işe yarayabilir, ama kırılgandır
• Davranışsal göstergeler: daha kalıcıdır; korelasyon ve zaman bağlamıyla güçlenir

Örnek: 192.0.2.45 gibi bir hedefe temas tek başına zayıf bir gösterge olabilir; fakat bu temasın belirli bir iç olay dizisini takip etmesi ve belirli bir zaman penceresinde tekrar etmesi, "zamanlama tabanlı davranış göstergesi" olarak daha anlamlı hale gelir.

3.2. Olay zaman çizelgesi: doğrulama ve operasyonel korelasyon

Zaman çizelgesi, olayları "dizmekten" çok davranışın mantığını görünür kılar. Kanıt üretimi açısından kritik değer şudur: "oldu" demek yerine "ne zaman, hangi kaynakta, hangi sırayla" demek.

İyi bir çizelge:

• Olayların kaynak bilgisini (EDR/SIEM/host log vb.) taşır
• Tetikleyici — sonuç ilişkilerini kurar
• Belirsizlikleri saklamaz (log gecikmesi, zaman senkronu riski)

İpucu: Çizelgede "eşik anları"nı belirginleştir: ilk tetik, ilk dış temas, ilk kalıcılık denemesi, ilk veri hazırlama/çözme. Bu anlar, tespit önerilerinin nerede yoğunlaşacağını doğrudan belirler.

3.3. Tespit önerileri: Sigma/YARA gibi çıktılar için gerekçelendirme

Tespit önerisi, yalnız "şunu yakalayın" demek değildir; sinyalin hangi kontrol katmanında nasıl değerlendirileceğini ve risklerin nasıl yönetileceğini açıklayan bir karar çerçevesidir. Burada Sigma ve YARA gibi çıktılar devreye girdiğinde, raporun kalitesi "kural var" demekle değil; kuralın hangi kanıtla savunulduğuyla ölçülür.

• Kuralın dayandığı benzersiz nitelik açık olmalıdır (rastgele string değil, davranışa bağlanan ayırt edici parça).
• Yanlış pozitif riski için karşı kanıt düşünülmelidir (meşru senaryolar neler, hangi bağlam kısıtları uygulanmalı?).
• Kuralın hangi senaryoda zayıflayacağı belirtilmelidir (ör. varyantlaşma, ortam farkları).

Dikkat: Aşırı spesifik kurallar, kanıt zayıfsa ekibi yanlış yöne sürükler; aşırı genel kurallar ise alarm gürültüsüne yol açar. Kanıt gücü düşükse daha genel davranış sinyalleriyle başlayıp, operasyonel geri besleme ile daraltmak daha güvenli bir stratejidir.

4) Blue Team entegrasyonu: kullanım senaryosu (use case) tasarımı ve paylaşım disiplini

Analiz çıktısı, savunma sistemlerinde çalışacak "kullanım senaryolarına" dönüşmediğinde raporun etkisi düşer. Kullanım senaryosu, ekiplerin "yarın sabah ne yapacağım?" sorusuna cevap verir:

• Hedef: neyi yakalamaya çalışıyoruz?
• Gözlem: hangi sinyaller bu hedefi destekliyor?
• Aksiyon: nerede, hangi sorgu/korelasyon mantığıyla araştırma yapılacak?
• Başarı ölçütü: hangi bulgu hipotezi doğrular/yanlışlar?

Örnek: Süreç davranışlarında beklenmedik bir yetki kullanımına dair sinyal, tek başına yeterli olmayabilir. Kullanım senaryosu, bu sinyalin hangi zaman penceresinde hangi ek olaylarla birlikte anlam kazandığını tarif ettiğinde, SIEM/EDR tarafında operasyonel karşılığı olan bir alarm tasarımına dönüşür.

Paylaşım disiplini de raporlamanın bir parçasıdır. Tehdit verisinin "kimle, hangi kapsamda" paylaşılacağı netleşmezse, savunma kazanımı gizlilik ve operasyon riskiyle gölgelenebilir. TLP (Traffic Light Protocol) gibi çerçeveler bu nedenle rapor diline entegre edilir.

5) Yeniden üretilebilirlik standardı ve sürümleme notları

Profesyonel bir tersine mühendislik raporu, başka bir analist tarafından okunduğunda aynı bulgulara ulaşılabilecek kadar şeffaf olmalıdır. Neden önemli? Çünkü kalite denetimi, ekip içi devir, uzun vadeli tespit mühendisliği ve hukuki/kurumsal inceleme süreçleri yeniden üretilebilir çıktılara dayanır.

5.1. Yeniden üretilebilirlik: hangi bilgiler raporda "olmazsa olmaz"?

• Ortam profili: gözlem kapsamı, izolasyon düzeyi, temel yapılandırma
• Gözlem penceresi: hangi süre içinde hangi telemetri izlendi
• Veri kaynakları: hangi log/telemetri sınıfları kullanıldı
• Çıktıların kökeni: ham verinin nerede referanslandığı ve nasıl izlenebilir kılındığı

Hassas vakalarda ayrıntı düzeyi, gizlilik riskini artırabilir. Bu durumda yöntem seçimi, ayrıntıyı "iç ek"e taşımak; ana raporda ise denetlenebilirliği bozmadan kontrollü açıklama yapmak yönünde olur.

5.2. Sürümleme: raporun yaşayan doğası

Analiz ilerledikçe bazı bulgular güçlenir, bazıları zayıflar; kimi hipotezler elenir. Profesyonel sürümleme:

• Revizyon geçmişini tutar
• Hangi bulgunun hangi kanıtla değiştiğini açıklar
• Değişikliğin tespit önerilerine/IOC paketine etkisini belirtir
• Başarısız denemeleri "negatif sonuç" olarak kısaca not eder (aynı hataların tekrarlanmaması için)

İpucu: Sürüm notlarında yalnız "güncellendi" demek yerine, "hangi iddia değişti / hangi kanıt eklendi / hangi karşı kanıt bulundu" çizgisini izlemek, raporu denetime hazır hale getirir.

Terimler Sözlüğü

Kendini Değerlendir

Bu modülde neler öğrendiniz?

• Teknik ekin, ileri seviye raporda iddiaları taşıyan ispat katmanı olduğunu
• Kritik fonksiyon ve akış şeması seçiminin, rapor hedefiyle uyumlu yöntem seçimi gerektirdiğini
• Decode notlarında tutarlılık, çapraz kanıt ve karşı kanıt arayışının yanlış kesinliği azalttığını
• IOC paketinin bağlam, güven seviyesi ve zaman çizelgesiyle “liste” olmaktan çıkıp operasyonel değere dönüştüğünü
• Tespit önerilerinin Sigma/YARA gibi çıktılara dönüşürken kanıtla gerekçelendirilmesi gerektiğini
• Kullanım senaryosunun bulguyu SOC/DFIR/mühendislik iş akışına bağlayan pratik köprü olduğunu
• Yeniden üretilebilirlik ve sürümlemenin raporu denetime hazır, sürdürülebilir bir çıktıya çevirdiğini