MODÜL 0 — Güvenli Çalışma Disiplini ve Analiz Metodolojisi

Zararlı yazılım analizi, doğası gereği riskli bir iştir: yanlış ortamda yapılan tek bir “meraktan tıklama”, hem sizin sisteminizi hem de bağlı olduğunuz ağı etkileyebilir. Bu modül; kontrollü bir analiz laboratuvarı kurmayı, şüpheli örnekleri güvenli şekilde saklamayı ve analizi baştan sona kanıt temelli bir akışla (triage → statik → dinamik → IOC → rapor) yürütmeyi öğretir. İyi bir analiz, doğru araçlardan önce doğru disiplinle başlar.

Lab üçlüsü

Örnek dosyaya dokunmadan önce bu kartları açıp kontrol listesine işaret atın.

İzolasyon

Ağ segmenti, snapshot, host-only. Kişisel sürücüde “hızlı bakayım” yoktur.

Geri dönüş

VM ve imaj tekrar üretilebilir olmalı; kirlenmiş ortamı yakıp yeniden kurmak rutin olmalı.

Kanıt

Hash, alınma zamanı, zincir. Zaman çizelgesi olmadan davranış yorumu zayıftır.

Bu Modülde Hedeflenen Kazanımlar

Şüpheli dosyalarla çalışırken izolasyon ve kontrol prensiplerini yerleştirmek.
Sanal makinelerle geri döndürülebilir bir analiz düzeni kurmak ve snapshot mantığını doğru kullanmak.
Örnekleri kazara çalıştırmayı ve dağınık delil toplamayı önleyecek saklama/taşıma alışkanlığı kazanmak.
Analiz akışını tutarlı bir “iş yapma biçimi” haline getirerek zamanı ve riski yönetmek.
Kanıt, zaman çizelgesi ve hipotez üretimiyle bulguları savunma aksiyonlarına çevirebilmek.

Modül Teması

Güvenli malware analizi üç temel ilkeye yaslanır: İzolasyon, Tekrar üretilebilirlik ve Kanıt bütünlüğü. Bu üçü olmadan teknik adımlar “işlem” üretir ama “analiz” üretmez.

İzolasyon

Şüpheli örneğin davranışı kişisel veya üretim sistemlerinden ayrıştırılır. Amaç, kaçabileceği yolları kapatıp riski sınırlandırmaktır.

Tekrar Üretilebilirlik

VM ve snapshot disipliniyle aynı koşulları yeniden kurabilmek; gözlemlerin başkası tarafından da doğrulanabilmesini sağlar.

Kanıt Bütünlüğü

Hash, log ve zaman çizelgesiyle “ne, ne zaman, hangi koşulda” kayıt altına alınır. Yorum ve kanıt birbirine karıştırılmaz.

Örnek — Şüpheli örneği güvenli klasöre alma ve hash çıkarma

ÖRNEK ÇIKTI — ANALİZ VM

# Örneği yetkisiz çalıştırmaya karşı koruyarak vaka klasörüne taşı
analyst@lab:~/cases/CASE-2026-014$ mkdir -p sample && mv ~/incoming/suspicious.bin sample/
analyst@lab:~/cases/CASE-2026-014$ chmod 600 sample/suspicious.bin

# Bütünlük için kriptografik hash hesapla, vaka notuna ekle
analyst@lab:~/cases/CASE-2026-014$ sha256sum sample/suspicious.bin | tee evidence/hash.txt
3f7a9b1e8c2d4a6f5b9e0c8d7a2f1b4e6d8c9a0b1e2f3a4b5c6d7e8f9a0b1c2d  sample/suspicious.bin

# Dosya türü uzantıdan değil içerikten doğrulanır
analyst@lab:~/cases/CASE-2026-014$ file sample/suspicious.bin
sample/suspicious.bin: PE32+ executable (GUI) x86-64, for MS Windows

1. İzolasyon: Riskin sınırlarını çizmek

İzolasyon, şüpheli dosyanın davranışını günlük kullandığınız sistemlerden ve kurumsal ağdan ayrıştırarak “kaçabileceği yolları” kapatma yaklaşımıdır. Neden önemli? Çünkü malware analizi “bilinmeyenle” çalışır; bilinmeyenle çalışırken en güvenli varsayım, örneğin zararlı olabileceğidir.

İzolasyonu düşünürken üç temel refleks geliştirilir:

Çalışma alanını ayırma: Analiz, kişisel/üretim ortamında değil, analiz için ayrılmış bir laboratuvar ortamında yapılır.
Temas yüzeyini azaltma: Ağ erişimi, paylaşımlı klasörler, kopyala–yapıştır alışkanlıkları, sürükle–bırak dosya transferi gibi kanallar risk yüzeyini büyütür.
Kontrollü gözlem: Amaç “zararlıyı serbest bırakmak” değil; davranışı kontrollü koşullarda gözlemleyip kanıt üretmektir.

Örnek: Bir analist, şüpheli dosyayı masaüstünde çift tıklayıp “ne oluyor” diye bakmak yerine, izole bir VM’de sınırlı gözlem planıyla çalıştırır. Dosya beklenmedik şekilde ağ bağlantısı denese bile davranış kontrol altında tutulur.

Dikkat: Şüpheli dosyayı kısa süreliğine bile kişisel ana bilgisayara, üretim sistemine veya senkronize/paylaşımlı bir klasöre koymak yayılma riskini artırır. “Bir kere bakıp sileceğim” yaklaşımı en sık kazaya yol açan düşünce biçimidir.

2. Analiz laboratuvarı: Sanallaştırma (VM) yaklaşımı

Sanal makine (VM), işletim sistemini izole bir sanal donanım üzerinde çalıştırarak güvenli ve yönetilebilir bir analiz alanı sağlar. Neden önemli? Çünkü dinamik analiz sırasında sistemde bozulmalar, ayar değişiklikleri ve çok sayıda artefakt birikebilir; VM bu etkileri “sınırlandırıp yönetilebilir” hale getirir.

Laboratuvarı kurarken pratikte şu disiplin işe yarar:

Rollere göre VM: Windows analiz VM’si ve Linux analiz VM’si (ör. REMnux yaklaşımı) farklı amaçlara hizmet eder. Her ortamı kendi görevi kadar sade tutmak, gözlemi netleştirir.
Temiz taban (clean state) mantığı: Araçları kurulmuş, temel ayarları yapılmış, “bilinen iyi durum” bir başlangıç noktası bulunur.
Değişkenleri azaltma: Otomatik güncellemeler, gereksiz uygulamalar ve “her şey yüklü” imajlar analiz trafiğini kirletebilir; ayrıca hangi etkinin örnekten geldiğini ayırt etmeyi zorlaştırır.

Örnek: Dinamik analiz sırasında dosya sistemi ve registry’de değişiklikler oluştu. Analist bu değişiklikleri not eder; sonra temiz tabana dönüp ikinci bir gözlemi aynı koşullarda tekrar ederek bulguların tutarlılığını kontrol eder.

İpucu: Analiz ortamında “sadelik”, görünürlük sağlar. Ne kadar az gereksiz süreç ve yazılım varsa, örneğin yarattığı anomali o kadar kolay seçilir.

3. Snapshot: Analizde geri sarma ve tekrar üretilebilirlik

Snapshot, VM’in belirli bir andaki durumunu kaydederek daha sonra aynı noktaya geri dönmeyi sağlayan mekanizmadır. Neden önemli? Çünkü bir örnek çalıştırıldıktan sonra bıraktığı izler, sonraki gözlemleri etkileyebilir. Snapshot, hem güvenliği artırır hem de analizi tekrar üretilebilir kılar.

Snapshot’ı “fotoğraf çekmek” gibi düşünmek işe yarar:

Analizden önce “temiz durum” snapshot’ı,
Araçlar kurulu ve doğrulanmış bir “hazır ortam” snapshot’ı,
Hipotez testinden hemen önce bir “dönüş noktası” snapshot’ı.

Örnek: Analist ilk çalıştırmada sadece proses ağacı ve dosya değişimlerine odaklanır. Snapshot’a dönüp ikinci çalıştırmada ağ davranışına ağırlık verir. Böylece ilk çalıştırmanın bıraktığı kalıntılar ikinci gözlemi kirletmez.

Dikkat: Snapshot, yedekleme stratejisi değildir; analiz akışını yönetmek için kontrol noktasıdır. Snapshot varken bile örnek arşivleme, hash kaydı ve kanıt paketleme disiplini ayrıca yürütülmelidir.

4. Ağ izolasyonu: “Konuşmasına izin ver, ama güvenli şekilde”

Birçok zararlı yazılımın davranışı ağ etkileşimiyle görünür olur: DNS sorguları, HTTP(S) istekleri, komuta-kontrol (C2) temasları gibi. Buradaki hedef, ağ davranışını gözlemlemek; fakat bunu gerçek ağınıza risk taşımadan yapmaktır.

C2 (Command & Control), saldırganın zararlı yazılımı yönettiği altyapıyı ifade eder. Neden önemli? Çünkü C2 temasları, tespit ve engelleme için güçlü IOC’ler üretir.
Ağ izolasyonu sayesinde şüpheli örneğin denediği bağlantılar gözlenebilir; ancak bu trafiğin kurumsal ağa “yan etki” üretmesi engellenir.

Örnek: Bir dosya çalıştıktan sonra 30 saniye içinde 192.0.2.15 adresine HTTP GET isteği atıyorsa, bu “dışarıdan bir yapılandırma/ek bileşen alma” ihtimalini gündeme getirir. Bu, doğrulanması gereken bir hipotezdir; kanıtlarla desteklenerek rapora taşınır. Bazı senaryolarda ağ davranışını daha ileri doğrulama yöntemleriyle test etmek gerekebilir; bu yaklaşımın ileri tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ele alınır.

5. Örnek saklama ve taşıma disiplini: “Canlı bomba” refleksi

Şüpheli dosyalar, her zaman kazara çalıştırılma riski taşıyan nesnelerdir. Örnek saklamada amaç; yetkisiz erişimi engellemek, yanlışlıkla çalıştırmayı zorlaştırmak ve delil bütünlüğünü korumaktır. Sağlıklı bir saklama/taşıma pratiği şunları hedefler:

Bütünlük ve izlenebilirlik: Örneğin hash değerini kaydetmek; aynı örneğin değişmediğini göstermek.
Vaka bağlamı: Örnek nereden geldi, hangi koşulda ele alındı, ilk gözlemler neler?
Kazara çalıştırmayı azaltma: Örneği doğrudan çalıştırılabilir halde dolaştırmak yerine, erişimi kontrollü tutmak.

Örnek: Bir e-posta eki olduğu iddia edilen dosya, ayrı bir vaka klasöründe saklanır; hash değeri not edilir. Analiz sırasında alınan loglar, ekran görüntüleri ve zaman çizelgesi kayıtları aynı vaka kimliği altında toplanır.

İpucu: Notlarınız raporun omurgasıdır. “Çalıştırdım, bir şey oldu” yerine; hangi koşulda, ne zaman, hangi kanıtla gözlemlediğinizi yazmak hem raporu hızlandırır hem de başka bir analistin aynı süreci tekrar etmesini sağlar.

6. Uçtan uca akış: triage → statik → dinamik → IOC → rapor

Profesyonel analiz, rastgele deneme-yanılma değildir; doğru sırayı takip ederek en az riskle en çok bilgi toplamayı hedefler.

6.1. Triage: hızlı sınıflandırma ve öncelik

Triage, örneğin aciliyetini ve analiz derinliğini belirleyen ilk süzgeçtir. Neden önemli? Çünkü zaman sınırlıdır; aynı gün birçok örnek gelebilir ve “en yüksek risk” önce ele alınmalıdır.

Örnek: Üç şüpheli dosyadan biri kullanıcılar tarafından çalıştırılmış, diğeri sadece indirilmiş, üçüncüsü e-posta geçidinde engellenmiş olsun. Triage, hangi dosyanın önce ele alınacağını ve hangi ekiplere hızla bilgi geçileceğini belirler.

TRIAGE ÖNCELİK — ÖRNEK ÇIKTI

# Vaka sinyallerini risk ağırlığına göre puanla
analyst@lab:~/cases/CASE-2026-021$ python triage_score.py suspicious_list.csv
sample_a.exe  executed_by_user=true   score=92  priority=P1
sample_b.doc  downloaded_only=true    score=46  priority=P3
sample_c.zip  blocked_at_gateway=true score=21  priority=P4

# İlk bildirim listesi (SOC/IR) hazırlanır
analyst@lab:~/cases/CASE-2026-021$ python notify_plan.py --top 1
notify_soc=true
notify_ir=true
initial_scope="endpoint group: finance-laptops"

6.2. Statik analiz: çalıştırmadan görülen sinyaller

Statik analiz, örneği çalıştırmadan yapısal göstergeler, metadata ve okunabilir içerikler üzerinden sinyal toplamaktır. Neden önemli? Çünkü dinamik analiz planını besler: “Neye bakacağım? Hangi davranışları özellikle izlemeliyim?”

Örnek: Dosyada belirli registry anahtarlarına referanslar veya şüpheli URL kalıpları görülüyorsa, dinamik analizde persistence izleri ve ağ davranışı daha öncelikli hale gelir.

STATİK SİNYAL ÖZETİ — ÖRNEK ÇIKTI

# String/metadata taramasıyla aday sinyalleri çıkar
analyst@lab:~/cases/CASE-2026-021$ python static_scan.py sample/sample_a.exe
registry_refs=HKCU\Software\Microsoft\Windows\CurrentVersion\Run
url_hits=hxxp://update-check.example.net/gate
packed_hint=true

# Dinamik plan önceliği belirlenir
analyst@lab:~/cases/CASE-2026-021$ python dynamic_plan.py --from static_scan.json
watch_registry=true
watch_dns_http=true
watch_process_tree=true

6.3. Dinamik analiz: davranışı kanıtlamak

Dinamik analiz, örneği kontrollü koşullarda çalıştırıp süreç ağacı, dosya sistemi, registry ve ağ etkileşimini gözlemleme yaklaşımıdır. Neden önemli? Çünkü “neye benziyor” sorusunu “ne yaptı” sorusuna dönüştürür.

Örnek: Statikte görülen bir alan adına dinamikte gerçekten bağlantı denemesi var mı? DNS sorgusu atıyor mu? Denemeler belirli aralıklarla tekrarlanıyor mu? Bu ayrıntılar tespit ve müdahaleyi yönlendirir.

DİNAMİK DOĞRULAMA — ÖRNEK ÇIKTI

# Çalıştırma penceresinde DNS ve HTTP denemeleri toplanır
analyst@lab:~/cases/CASE-2026-021$ python net_observe.py --window 120s
dns_query=update-check.example.net
http_attempt=203.0.113.25:80
attempt_count=4
interval_sec~=30

# Süreç bağlamına bağlayarak kanıt notu üret
analyst@lab:~/cases/CASE-2026-021$ python correlate_proc_net.py
parent_process=winword.exe
child_process=sample_a.exe
network_source_process=sample_a.exe
confidence=medium-high

6.4. IOC üretimi: savunma için aranabilir göstergeler

IOC (Indicator of Compromise), olayın izini sürmeye yarayan somut göstergelerdir: domain, IP, URL yolu, dosya hash’i, registry anahtarı, dosya yolu gibi. Neden önemli? Çünkü SOC ve olay müdahale ekipleri, “aranabilir” ve “sorgulanabilir” sinyaller üzerinden tarama yapar.

IOC’leri tek bir işaret yerine paket olarak düşünmek gerekir:

Bir ortamda hash bulunmayabilir, ama URL yolu loglarda görülebilir.
Bir ortamda domain görünmez, ama persistence anahtarı tespit edilebilir.

6.5. Raporlama: kanıtı aksiyona çevirmek

Rapor, bulguları teknik doğrulukla bir araya getirirken, savunma tarafında ne yapılacağını da netleştirir: risk değerlendirmesi, önerilen aksiyonlar, izleme/tarama önerileri gibi. “Kötü amaçlı” demek tek başına değer üretmez; kanıtla desteklenen davranış modeli ve öneriler değer üretir.

7. Kanıt ve zaman çizelgesi: dedektif gibi düşünmek

Analist, elindeki parçaları bir araya getirerek doğrulanabilir bir hikâye kurar.

Kanıt, bulguların dayanağıdır: log kayıtları, ekran görüntüleri, hash’ler, zaman damgaları ve gözlem notları. Neden önemli? Çünkü karar vericiler çoğu zaman sizin ortamınızda değildir; kanıt, ortak dili sağlar.
Zaman çizelgesi (timeline), olayların sırasını ve ilişkisini gösterir. Neden önemli? Çünkü davranış çoğu zaman aşamalıdır; “önce kopyaladı, sonra kalıcılık bıraktı, sonra ağa çıktı” gibi.

Örnek: Çalıştırmadan 15 saniye sonra geçici dizine bir dosya bırakılıyor; 20. saniyede görev zamanlayıcı benzeri bir kalıcılık izi oluşuyor; 60. saniyede DNS sorguları başlıyorsa, kalıcılığın ağ temasından önce geldiği anlaşılır. Bu sıralama, müdahale önceliklerini etkiler.

8. Hipotez üretimi: “Hangi kanıt eksik?” sorusunu merkez almak

Hipotez, eldeki sinyallerden yola çıkarak test edilebilir bir açıklama kurmaktır. Neden önemli? Çünkü hipotez, analizi rastgele denemelerden kurtarıp planlı kanıt toplamaya yöneltir. İyi bir hipotez; somut, doğrulanabilir ve yanlışlanabilir olmalıdır. Eksik kanıt listesi, bir sonraki gözlem turunun yol haritasını oluşturur.

Hipotez kurarken şu düşünme biçimi işe yarar:

Hangi sinyal bunu düşündürüyor?
Bunu doğrulamak için hangi kanıt eksik?
Eksik kanıtı güvenli koşullarda nasıl toplarım?

Örnek: Bir dosya çalıştıktan sonra ağ üzerinden başka bir içerik almaya çalışıyorsa, “indirici (dropper/downloader) rolü olabilir” hipotezi kurulabilir. Bu hipotez, zaman çizelgesi ve ağ kanıtlarıyla güçlendirilerek raporda “olasılık + kanıt” şeklinde sunulur.

Terimler Sözlüğü

Terim	Açıklama
Isolation	İzolasyon; Şüpheli örneğin davranışını üretim sistemlerinden ve ağdan ayrıştıran kontrol disiplini.
VM (Virtual Machine)	Sanal Makine; İşletim sistemini izole sanal donanım üzerinde çalıştırarak güvenli analiz alanı sağlayan ortam.
Snapshot	VM’in belirli bir andaki durumunu kaydeden ve geri dönmeye olanak tanıyan kontrol noktası.
Sandbox	Kum havuzu; kontrollü/izole ortamda gözlem yaklaşımı
Triage	Örneklerin aciliyet ve derinlik açısından önceliklendirildiği ilk değerlendirmeadımı.
Static analysis	Statik analiz; örneği çalıştırmadan yapısal göstergeler ve içerik üzerinden sinyal toplama yaklaşımı.
Dynamic analysis	Dinamik analiz; örneği kontrollü koşullarda çalıştırıp davranışı (proses, dosya, registry, ağ) gözlemleme.
IOC (Indicator of Compromise)	İhlal göstergesi: hash, domain, IP, URL, registry anahtarı gibi aranabilir izler.
Evidence	Kanıt; olayı anlamaya/ispatlamaya yarayan log, ekran görüntüsü, hash, zaman damgası vb. kayıtlar.
Timeline	Gözlenen olayların sırasını ve ilişkisini gösteren zaman çizelgesi.
Hipothesis	Hipotez; eldeki sinyallerden hareketle test edilebilir, yanlışlanabilir açıklama önerisi.
C2 (Command & Control)	Saldırganın zararlı yazılımı yönettiği altyapı; güçlü IOC kaynağıdır.
Detonation	Kontrollü çalıştırma; örneği izole ortamda çalıştırıp gözleme alma eylemi.

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Şüpheli dosya eline geçtiğinde en doğru ilk yaklaşım hangisidir?

A) Üretim sisteminde hızlıca çalıştırıp gözlemlemek

B) İzole analiz ortamında triage yapıp rotayı belirlemek

C) Dosya adından aile tahmini yapıp rapora yazmak

D) Dosyayı paylaşımlı klasöre koyup ekipten görüş istemek

E) İnternette benzer isimli dosyaları bulup aynı kabul etmek

Doğru: B
Gerekçe: İzolasyon + triage riski sınırlar ve analizi planlar. A ve D yayılma riskini artırır; C ve E kanıtsız varsayımdır.

2) Snapshot’ın analiz kalitesine en kritik katkısı hangisidir?

A) Zararlı yazılımı otomatik engellemesi

B) İnternet trafiğini otomatik maskelemesi

C) Aynı koşullara dönerek gözlemi tekrar üretilebilir kılması

D) Hash hesaplamayı otomatik yapması

E) Sandbox raporu üretmesi

Doğru: C
Gerekçe: Snapshot, “bilinen iyi duruma” dönüş sağlayarak karşılaştırmalı gözlem yapmayı mümkün kılar. Diğerleri snapshot’ın doğrudan işlevi değildir.

3) Analiz ortamında temas yüzeyini artıran davranış hangisidir?

A) Vaka klasörlerini düzenli tutmak

B) Şüpheli örneği senkronize/paylaşımlı klasörde taşımak

C) İzole VM’de çalışmak

D) Kanıtları zaman damgasıyla kaydetmek

E) Statik bulgularla dinamik gözlemi planlamak

Doğru: B
Gerekçe: Senkronize/paylaşımlı klasörler yanlışlıkla yayılma ve yanlış yere kopyalama riskini büyütür. Diğerleri riski azaltır.

4) Triage aşamasının temel çıktısı hangisi olmalıdır?

A) Örneğin tüm fonksiyonlarının listesi

B) Kesin malware aile adı

C) Öncelik, etki tahmini ve hangi analiz derinliğine gidileceği

D) Anti-analiz yöntemlerinin nasıl aşılacağı

E) Kernel seviyesinde kanıt

Doğru: C
Gerekçe:Triage, hızla “ne kadar acil/derin” kararını verir. A ve B genelde daha ileri ve zaman alıcıdır; D ve E kapsam dışıdır.

5) Statik analiz bulguları dinamik analize en doğru nasıl hizmet eder?

A) Dinamik analizi tamamen gereksiz kılar

B) Hangi davranışların özellikle izleneceğini işaret eder

C) Tüm IOC’leri tek başına kesin çıkarır

D) Örneği sistemden temizler

E) VM’i otomatik günceller

Doğru: B
Gerekçe: Statik sinyaller, dinamik gözlemde odak ve hipotez oluşturur. A ve C aşırı iddia; D ve E alakasızdır.

6) IOC’lerin paket olarak düşünülmesi hangi pratik problemle ilgilidir?

A) Tek bir IOC’nin her ortamda mutlaka görünmesi

B) Farklı ortamlarda farklı izlerin daha görünür olabilmesi

C) IOC’nin sadece hash olması

D) Raporda teknik detayların hiç olmaması

E) IOC’nin yalnızca e-posta ile paylaşılması

Doğru: B
Gerekçe: Kimi yerde hash yoktur ama URL yolu/log izi vardır; kimi yerde domain yoktur ama persistence izi bulunur. Diğer seçenekler hatalı genellemedir.

7) Zaman çizelgesi oluşturmanın analizdeki ana değeri nedir?

A) Analistin çalışma süresini ispatlamak

B) Olayların sırasını ve ilişkiyi göstererek davranış modelini netleştirmek

C) Hash hesaplamayı hızlandırmak

D) Ağ kablosunu kapatmak

E) Decompile çıktısı üretmek

Doğru: B
Gerekçe: Timeline, aşamalı davranışı anlamlandırır ve müdahale önceliklerini etkiler. Diğerleri timeline’ın amacı değildir.

8) “Bu dosya indirici rolünde olabilir” hipotezi en güçlü hangi kanıt türüyle desteklenir?

A) Dosya ikonunun belge gibi görünmesi

B) Çalıştırma sonrası belirli bir adrese tekrar eden ağ istekleri ve zaman çizelgesinde bunun konumlanması

C) Dosya adının “fatura” olması

D) Analiz makinesinin bir kez donması

E) Dosya boyutunun büyük olması

Doğru: B
Gerekçe: Ağ istekleri + timeline ilişkisi, hipotezi test edilebilir kılar. A/C sosyal mühendislik sinyali olabilir ama tek başına yeterli değildir; D/E zayıf çıkarımdır.

9) Kanıtın “savunma tarafı” için vazgeçilmez olmasının nedeni hangisidir?

A) Raporu daha uzun gösterir

B) Karar vericilerin sizin ortamınıza ihtiyaç duymadan doğrulama yapabilmesini sağlar

C) Teknik terimleri azaltır

D) Örneği otomatik temizler

E) Aile adını kesinleştirir

Doğru: B
Gerekçe: Kanıt, bulguyu doğrulanabilir kılar ve tespit/engelleme aksiyonlarını meşrulaştırır. A/C/D/E kanıtın temel amacı değildir.

10) Analiz bittikten sonra laboratuvar disiplini açısından en doğru yaklaşım hangisidir?

A) VM’i kapatıp olduğu gibi bırakmak

B) Şüpheli dosyaları masaüstünde bırakıp ana makineye kopyalamak

C) Kanıtları paketleyip notları tamamladıktan sonra ortamı bilinen temiz duruma geri döndürmek

D) VM’i internete bağlayıp güncelleme başlatmak

E) Örneği sistem klasörlerine taşımak

Doğru: C
Gerekçe: Önce kanıt/raporlanabilirlik tamamlanır, sonra ortam temizlenir. A ve B kirli ortam ve yayılma riski doğurur; D trafiği kirletebilir; E hatalı ve risklidir.

Bu Modülde Kazanılan Yetkinlikler

Şüpheli örneklerle çalışırken izolasyonun “kırmızı çizgi” olduğunu bilmek ve buna göre davranmak.
VM ve snapshot ile geri döndürülebilir, karşılaştırmalı gözlem yapabilen bir analiz düzeni kurmak.
Örnek saklama/taşıma disiplinini delil bütünlüğü ve kazara çalıştırmayı azaltma ekseninde uygulamak.
Triage → statik → dinamik → IOC → rapor akışını, savunma odaklı çıktı üreten bir alışkanlığa dönüştürmek.
Kanıt, zaman çizelgesi ve hipotezle “gördüm” yerine “gösteriyorum” düzeyinde analiz anlatısı kurmak.

MODÜL 1 — Malware Ekosistemi ve Temel Taksonomi

Zararlı yazılımı tek bir “etiket” gibi görmek, analistin en kritik karar noktalarını bulanıklaştırır. Bu modül, şüpheli bir örneği yalnızca teknik izlerinden değil; hangi amaçla, saldırı zincirinin hangi aşamasında ve operasyonel olarak hangi rolü oynayacak şekilde tasarlanmış olabileceğinden hareketle okumayı öğretir. Doğru taksonomi dili kurulduğunda, triage ve analiz sırasında “neye bakacağım, hangi kanıt eksik, savunmada ilk neyi kapatmalıyım?” sorularının yanıtı çok daha hızlı netleşir.

Modül Teması

Türler ve Aileler

Downloader, ransomware, infostealer, RAT, worm, botnet bileşeni — her birinin kendi amacı ve karakteristik izleri vardır.

Enfeksiyon Zinciri

İlk erişimden kalıcılık, hareket, veri çıkışı ve etkiye uzanan saldırı yaşam döngüsü.

Savunma Dili

IOC, IOA, TTP, aile ve kampanya kavramları analist–SOC–IR ekipleri arasında ortak dili kurar.

Bu Modülde Hedeflenen Kazanımlar

Yaygın malware türlerini motivasyon/amaç perspektifiyle ayırt etmek ve “davranış profili” çıkarmak
Bir saldırının girişten hedef etkiye kadar ilerleyişini yaşam döngüsü üzerinden okuyup analiz kararlarına çevirmek
IOC, IOA, TTP kavramlarını doğru bağlamda kullanmak ve rapor dilini savunma aksiyonlarına bağlamak
Tehditleri aile ve kampanya düzeyinde gruplandırmanın ne işe yaradığını kavramak
“Ne zaman sandbox yeter, ne zaman eskalasyon gerekir?” sorusuna eksik kanıt odaklı yanıt verebilmek

1. Malware türleri ve kullanım amaçları

Bir zararlı yazılımı “ne yaptığı” kadar “ne amaçla tasarlandığı” üzerinden okumak daha işlevseldir. Çünkü saldırganın hedefi, yazılımın davranışını ve bıraktığı izleri belirler. “Tür” burada kesin bir kutu değil; savunmada önceliklendirme yapan bir zihinsel harita gibidir.

1.1. Downloader / Dropper (İndirici / Taşıyıcı rol)

Downloader, asıl zararlı yükü (payload) dışarıdan indirmeye çalışan; dropper ise sistemi hazırlayıp ek bileşenleri bırakma rolünü üstlenen örneklerdir. Neden önemli? Çünkü ilk görülen dosya “esas tehdit” olmayabilir; analist zincirin devamını aramazsa olayı eksik okur.

Örnek: Bir dosya çalıştığında ekranda bir belirti oluşmaz; ancak kısa süre sonra 198.51.100.20 adresine tekrarlı istekler başlar ve ardından disk üzerinde yeni bir çalıştırılabilir dosya belirir. Bu tablo ilk dosyanın taşıyıcı rolü olabileceğini düşündürür; savunmada hem ilk örneğin izleri hem de indirilen/bırakılan bileşenlerin izleri birlikte ele alınır.

1.2. Ransomware (Fidye yazılımı)

Ransomware, erişimi engellemek veya dosyaları şifrelemek gibi yöntemlerle iş sürekliliğini hedef alır. Güncel vakalarda “yalnızca şifreleme” değil, veriyi sızdırıp yayınlamakla tehdit etme (double extortion) modeli de görülebilir. Neden önemli? Çünkü müdahalede zaman kritik bir değişkendir: hızla izolasyon, yayılım ihtimalinin değerlendirilmesi ve etkilenmiş sistemlerin kapsamının çıkarılması gerekir.

Örnek: Kısa sürede çok sayıda dosyanın yeniden adlandırıldığı, yeni uzantılar oluştuğu ve klasörlerde not dosyalarının belirdiği bir uç düşünün. Bu, acil containment ihtimalini yükseltir; IOC’ler hızla paketlenip diğer uçlarda tarama başlatılır.

1.3. Infostealer / Stealer (Bilgi hırsızı)

Infostealer’lar kimlik bilgileri, tarayıcı verileri, oturum belirteçleri (session token/çerez) gibi değerli bilgileri toplayıp dışarı sızdırmayı hedefler. Neden önemli? Çünkü tek bir uçtaki olay, hızla hesap ele geçirmeye ve zincirleme kurumsal riske dönüşebilir; yalnızca “dosyayı temizlemek” yetmez, kimlik/oturum riskinin de ele alınması gerekir.

Örnek: Kullanıcı “tarayıcı sürekli çıkış yapıyor” diye şikâyet ederken aynı zaman aralığında şüpheli dış bağlantılar artmış olabilir. Rapor, yalnızca dosya bulgusunu değil, olası hesap kompromisini ve oturum güvenliğini de kapsar.

1.4. Backdoor / RAT / Trojan (Arka kapı / uzaktan erişim / Truva atı)

Backdoor veya RAT, sisteme uzaktan komut çalıştırma, dosya yönetimi, ekran izleme gibi yetkiler kazandırmayı hedefler. Trojan ise kendini yararlı bir yazılım gibi gösterip sisteme sızan ve çoğu zaman arka kapı gibi bir yeteneğe zemin hazırlayan sınıftır. Neden önemli? Çünkü bu tür örnekler “kalıcılık + komuta-kontrol (C2)” ikilisini merkeze alır; savunmada hem erişimi kesmek hem de kalıcılık izlerini temizlemek gerekir.

Örnek: Bir uçta kullanıcı davranışıyla açıklanamayan arka plan süreçleri, düzenli aralıklarla aynı alan adına DNS sorguları ve kalıcılığa işaret eden sistem kayıtları birlikte görülüyorsa uzaktan kontrol olasılığı güçlenir. IOC’ler (domain, URL yolu, süreç adı, kalıcılık izi) tek tek değil, birlikte değerlendirilir.

1.5. Worm (Solucan)

Worm’lar kullanıcı müdahalesine gerek duymadan ağ üzerinden kendini kopyalayarak yayılabilen türlerdir. Neden önemli? Çünkü etkisi tek bir uçla sınırlı kalmayabilir; ağ seviyesinde korelasyon ve hızlı engelleme aksiyonları öne çıkar.

Örnek: Aynı saat diliminde birden fazla uçta benzer ağ denemeleri ve anormal bağlantı artışları görülürse, olay “tekil dosya” olmaktan çıkıp yayılım şüphesine dönüşebilir.

1.6. Botnet bileşeni

Botnet, çok sayıda enfekte sistemin merkezi veya yarı merkezi bir kontrolle koordineli yönetilmesidir. Neden önemli? Çünkü tekil bir uçtaki tespit daha geniş bir yayılımın parçası olabilir; ağ seviyesinde bloklama ve avcılık için örüntü aramak gerekir.

Örnek: Birden fazla uçta benzer zamanlarda 203.0.113.77 adresine kısa ve tekrarlı bağlantılar görülmesi, “aynı kontrol düzeneği” ihtimalini gündeme getirir; tespit mantığı paket halinde güncellenir.

1.7. Spyware / Adware (Casus yazılım / reklam yazılımı)

Spyware kullanıcı davranışını izlemeye; adware ise agresif reklam/yönlendirme ile gelir üretmeye odaklanır. Neden önemli? Çünkü her örnek yüksek teknik sofistikasyon taşımasa da veri gizliliği ve kullanıcı güveni üzerinde gerçek etki doğurur; “teknik olarak basit” olan “önemsiz” değildir.

Örnek: Tarayıcı ayarlarının habersiz değişmesi, istenmeyen eklentiler ve anormal yönlendirmeler görüldüğünde adware/spyware şüphesi güçlenir; rapor kullanıcı etkisini ve iyileştirme adımlarını netleştirir.

1.8. Rootkit (kısa çerçeve)

Rootkit’ler, varlığını gizlemeye ve sistemin daha derin katmanlarına yerleşmeye odaklanan tehditlerdir. Neden önemli? Çünkü standart gözlem araçları her zaman güvenilir görünürlük sunmayabilir; bazı vakalarda “daha derin doğrulama” ihtiyacı doğar. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

Dikkat: Türler kesin kutular değildir. Aynı örnek hem indirici rol oynayıp hem de arka kapı bırakabilir. Bu yüzden “etiket koymaya” değil, kanıtla desteklenen davranış profili çıkarmaya odaklanın.

2. Enfeksiyon zinciri ve saldırı yaşam döngüsü

Enfeksiyon zinciri, zararlı yazılımın sisteme nasıl girdiğinden başlayıp hedef etkisini yaratana kadar geçtiği aşamalar bütünüdür. Neden önemli? Çünkü analist yalnızca “şüpheli dosya”yı değil; o dosyaya giden yolu ve o dosyadan sonra oluşan etkileri anlamak zorundadır.

Orta seviyede pratik bir yaşam döngüsü okuması şu şekilde düşünülebilir:

Giriş vektörü: e-posta eki, indirilen dosya, sahte güncelleme, USB vb.

Çalıştırma/etkinleşme: kullanıcı eylemi veya otomatik tetik

Yerleşme/hazırlık: ek bileşen indirme/bırakma, sistem değişiklikleri

Kalıcılık (persistence): yeniden başlatmalardan sonra da çalışmayı sürdürme

Dış iletişim/C2: DNS–HTTP(S) örüntüleri, düzenli aralıklı temaslar

Hedef etki: veri sızdırma, şifreleme, uzaktan yönetim vb.

Bu bakış, literatürde sık geçen Cyber Kill Chain yaklaşımıyla da uyumludur; modelin yaygın anlatımlarında keşiften hedef etkiye uzanan ardışık aşamalar bulunur. Bazı kaynaklar aşama sayısını farklı genişletmelerle ele alabilir; ancak savunma açısından kritik fikir değişmez: zincirin bir halkasını kırmak, saldırının tamamını durdurabilir.

Örnek: Kullanıcı bir dosyayı açtıktan sonra kısa süreli bir süreç oluşur, ardından sistemde yeni bir görev kaydı görünür ve birkaç dakika sonra dışarıya düzenli aralıklarla bağlantı denemeleri başlar. Bu sıra “çalıştırma → kalıcılık → dış iletişim” zincirini düşündürür; zaman çizelgesine oturtulduğunda rapor çok daha ikna edici hale gelir.

İpucu: Yaşam döngüsünü “hikâye” gibi okuyun: önce ne oldu, sonra ne değişti, en sonunda hangi etki hedeflendi? Dağınık log parçaları, bu sırayla bir araya gelince savunma aksiyonlarını doğru sıraya koymak kolaylaşır.

3. Savunma dilinin omurgası: IOC, IOA, TTP, aile ve kampanya

Bu kavramlar çoğu zaman birbirine karışır; oysa her biri savunmada farklı ihtiyaca hizmet eder.

3.1. IOC (Indicator of Compromise) — İhlal göstergesi

IOC, ihlalin izini sürmeye yarayan somut teknik göstergedir: dosya hash’i, domain, IP, URL yolu, dosya yolu, registry anahtarı gibi. Neden önemli? Çünkü hızlı tarama, engelleme ve avcılık için “aranabilir” hedef sağlar.

Örnek: Bir uçta belirli bir URL yolu ve belirli bir kalıcılık kaydı görülüyorsa, aynı göstergeler diğer uçlarda aranarak kısa sürede kapsam çıkarılabilir.

3.2. IOA (Indicator of Attack) — Saldırı göstergesi

IOA, sabit bir değer yerine davranış örüntüsünü işaret eder: anormal süreç ilişkileri, beklenmeyen komut yürütme paterni, düzenli aralıklı “beaconing” gibi. Neden önemli? Çünkü IOC’ler hızlı değişebilir; davranış odaklı yaklaşım varyantlara karşı daha dirençli olabilir.

Örnek: Dosya adı ve hash her seferinde değişse bile, süreç ağacındaki ilişki ve zamanlama örüntüsü benzer kalıyorsa IOA tabanlı tespit daha güçlü hale gelir.

3.3. TTP (Tactics, Techniques, Procedures)

TTP, saldırganın hedefe ulaşmak için izlediği yöntem setini ifade eder: taktik (niyet), teknik (yöntem) ve prosedür (uygulama alışkanlığı). Neden önemli? Çünkü olayları tekil bir dosyadan çıkarıp daha geniş tehdit modeline bağlar; savunma ekipleri için “öğrenilebilir desen” üretir.

Dikkat: IOC’ler (hash/IP/domain) saldırgan tarafından hızlı değiştirilebilir. Bu yüzden sadece IOC tabanlı savunma kırılgandır; daha üst seviyedeki göstergeler (ör. TTP) saldırgan için daha “maliyetli” değişir. Bu yaklaşımı sistematikleştiren “Pyramid of Pain” modeli; hash’ten TTP’ye doğru çıktıkça göstergelerin değiştirilmesinin zorlaştığını anlatır.

İpucu: Raporunuzda IOC listesini verirken bir cümle daha ekleyin: “Bu IOC’ler değişebilir; tespiti daha dayanıklı kılmak için şu davranış örüntüleri (IOA/TTP) özellikle izlenmeli.” Bu, raporu “engelleme”den “kalıcı savunma”ya taşır.

3.4. Aile (family) ve kampanya (campaign)

Aile, benzer kod tabanı veya davranış seti paylaşan örneklerin kümelenmesidir.

Kampanya, belirli bir zaman aralığında belirli hedeflere yönelik yürütülen operasyonel saldırı dizisidir.

Neden önemli

Aile perspektifi teknik benzerliklerle tespiti güçlendirir; kampanya perspektifi hedefleme ve altyapı korelasyonuyla kapsam/risk değerlendirmesini netleştirir.

Örnek: Aynı dönemde farklı kullanıcıların benzer içerikli e-postalar aldığı ve benzer alan adı kalıplarına giden bağlantılar bulunduğu düşünülürse olay “tekil dosya” olmaktan çıkar; kampanya perspektifi kazanır ve raporda risk daha doğru konumlanır.

Dikkat: Kanıt yetersizken “kesin aile adı” vermek raporu zayıflatır. Orta seviyede çoğu zaman daha sağlam yaklaşım; davranış profili + IOC paketi + TTP/ATT&CK diline yakın eşleme ile ilerlemektir.

4. Eskalasyon kararları: ne zaman sandbox, ne zaman RE, ne zaman bellek analizi?

Eskalasyon, analiz derinliğini artırma kararıdır: “Elimdeki kanıt savunma aksiyonunu desteklemeye yetiyor mu, yoksa farklı bir yönteme mi geçmeliyim?” sorusuna verilen yanıttır.

4.1. Ne zaman sandbox yaklaşımı?

Sandbox, örneği kontrollü ortamda çalıştırıp hızlı bir davranış görünümü sağlamaya yarar. Neden önemli? Çünkü çok sayıda şüpheli dosya arasında önceliklendirme yaparken “ilk izlenim” ve davranış sinyalleri rota belirlemeyi hızlandırır.

Örnek: Gün içinde çok sayıda şüpheli ek geldiğinde, hangisinin kalıcılık ve dış iletişim izleri ürettiğini hızlı görmek “hangi dosyaya önce yoğunlaşacağım?” kararını destekler.

4.2. Ne zaman tersine mühendislik (RE) ihtiyacı gündeme gelir?

Statik/dinamik gözlemin netleştirmediği, raporlanabilir kanıt üretmek için daha güçlü doğrulama gerektiren durumlarda RE ihtiyacı doğabilir. Orta seviyede hedef, RE’nin hangi durumda gerekli olduğunu tanımaktır. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

4.3. Ne zaman bellek analizi (memory) ihtiyacı gündeme gelir?

Disk üzerinde iz bırakmayan veya sınırlı iz bırakan; çalışma anında görünen artefaktların kritik olduğu vakalarda bellek analizi gündeme gelebilir. Orta seviyede amaç “ne zaman gerekebilir?” sorusunu doğru sormaktır. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

Dikkat: Bellekteki bazı kanıtlar uçucudur; sistemin kapatılması/yeniden başlatılması, belirli sınıf vakalarda gözlemlediğiniz izlerin kaybolmasına yol açabilir. Orta seviyede burada hatırlanması gereken şey, “kanıt türü” ile “işlem sırası” arasındaki ilişkidir.

İpucu: Eskalasyon kararını “merak” değil, “eksik kanıt” belirlesin. Eğer raporda şu cümleyi net kurabiliyorsanız doğru yöndesiniz: “Şu iddiayı güçlendirmek için şu kanıt eksik; bu kanıt savunma aksiyonunu doğrudan etkiliyor.”

Terimler Sözlüğü

Terim	Açıklama
Malware	Zararlı yazılım; sisteme zarar vermek, erişim sağlamak veya veri çalmak amacıyla kullanılan yazılım
Downloader	İndirici; asıl zararlı bileşeni ağ üzerinden indirmeye çalışan rol
Dropper	Taşıyıcı/bırakıcı; ek bileşenleri sistemde konuşlandıran rol
Payload	Yük; saldırının asıl etkisini üreten bileşen
Ransomware	Fidye yazılımı; veriyi şifreleme/erişimi engelleme ile etki yaratır
Double extortion	“Çift baskı”; şifreleme + sızdırma tehdidini birlikte kullanma modeli
Infostealer/Stealer	Bilgi hırsızı; kimlik bilgileri/oturum belirteçleri gibi verileri toplama odaklıdır
Backdoor	Arka kapı; uzaktan erişim ve komut yürütme imkânı sağlar
RAT	Uzaktan erişim aracı; sistem üzerinde uzaktan kontrol kabiliyeti
Trojan	Truva atı; yararlı gibi görünerek sisteme sızan, çoğu zaman arka kapı/yan yük getiren tür
Worm	Truva atı; yararlı gibi görünerek sisteme sızan, çoğu zaman arkakapı/yan yük getiren tür
Botnet	Bot ağı; çok sayıda enfekte sistemin koordineli yönetimi
C2 (Command& Control)	Komuta-kontrol; saldırganın zararlıyı yönettiği altyapı
IOC	İhlal göstergesi; ihlalin izine dair teknik işaret (hash, domain, IP vb.)
IOA	Saldırı göstergesi; davranış örüntüsüne dayalı tespit sinyali
TTP	Taktik/teknik/prosedür; saldırganın yöntem seti
Family	Aile; benzer kod/davranış setine sahip örnek kümeleri
Campaign	Kampanya; belirli hedeflere yönelik operasyonel saldırı süreci
Escalation	Eskalasyon; analiz derinliğini artırma kararı
Sandbox	Kum havuzu; kontrollü ortamda davranış gözlem yaklaşımı
Reverse Engineering(RE)	Tersine mühendislik; kodu/ikiliyi daha derin doğrulama yaklaşımı
Memory analysis	Bellek analizi; çalışma anı artefaktlarını inceleme yaklaşımı
Exfiltration	Veri sızdırma; çalınan verilerin dışarı aktarılması
Attribution	Aidiyet belirleme; tehdidi aktör/aile/kampanya bağlamında ilişkilendirme çabası
Pyramid of Pain	Göstergelerin saldırgan için değiştirme maliyetine göre katmanlandığı model
Cyber Kill Chain	Saldırıyı aşamalara bölerek erken durdurma noktalarını görünür kılan model

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Bir örneği “malware türü” olarak sınıflandırırken en doğru yaklaşım hangisidir?

A) Yalnızca dosya adına bakıp karar vermek

B) Tek bir kategori seçip diğer ihtimalleri dışlamak

C) Davranış setini amaçla ilişkilendirerek profil çıkarmak

D) Sadece hash’e bakarak tür belirlemek

E) Örneği açmadan aile ismi yazmak

Doğru: C
Gerekçe: Tür sınıflandırması, amaç–davranış ilişkisiyle anlam kazanır. A/D/E kanıtsızdır; B, karma rolleri kaçırır.

2) Downloader/Dropper rolü için en ayırt edici risk nedir?

A) Her zaman fidye notu gösterir

B) İlk görülen dosyanın esas tehdit olmayabilmesi ve zincirin devamının kaçırılması

C) Mutlaka çok büyük boyutlu olması

D) Sadece tarayıcı ayarlarını değiştirmesi

E) Sadece çevrimdışı çalışması

Doğru: B
Gerekçe: Taşıyıcı rol, sonraki bileşenlere kapı açar. A/D/E genelleme; C ilgisiz.

3) IOC ile IOA arasındaki en doğru ayrım hangisidir?

A) IOC davranış örüntüsü, IOA sabit değerdir.

B) IOC sabit teknik gösterge, IOA davranış örüntüsüdür.

C) IOC sadece e-posta adresidir, IOA sadece IP’dir.

D) IOC yalnızca bellekten çıkar, IOA yalnızca diskten çıkar.

E) İkisi aynı şeydir.

Doğru: B
Gerekçe: IOC aranabilir somut değerdir; IOA davranış paternidir. A ters; C/D yanlış; E kavramsal hatadır.

4) “Pyramid of Pain” yaklaşımı, savunma açısından en çok hangi mesajı verir?

A) Her zaman sadece hash engellemek yeterlidir.

B) Göstergeler yukarı çıktıkça saldırgan için değiştirme maliyeti artar

C) IP adresleri TTP’den daha değiştirilemezdir.

D) IOC kullanmak gereksizdir.

E) Sadece adli bilişim raporlarında kullanılır.

Doğru: B
Gerekçe: Model, hash/IP/domain gibi göstergelerin kolay, TTP’lerin daha zor değiştiğini vurgular. A/C/D/E modelin mantığıyla çelişir.

5) Double extortion en çok hangi türle ilişkilidir?

A) Spyware

B) Worm

C) Ransomware

D) Adware

E) Botnet

Doğru: C
Gerekçe: Çift baskı modeli, şifreleme + sızdırma tehdidini birlikte kullanır; bu fidye yazılımı örüntüsüdür.

6) “Kampanya” ile “aile” kavramını karıştırmak hangi riski doğurur?

A) Logları hızlandırır.

B) Teknik kanıtı artırır.

C) Operasyonel bağlamı yanlış okuyup kapsam ve risk değerlendirmesini zayıflatır.

D) IOC üretimini otomatikleştirir.

E) Dinamik analizi gereksiz kılar

Doğru: C
Gerekçe: Kampanya hedefleme/zaman/altyapı bağlamıdır; aile teknik benzerlik kümelenmesidir. Diğerleri ilişkisiz.

7) Aşağıdakilerden hangisi “backdoor/RAT” şüphesini daha tutarlı biçimde destekler?

A) Dosyanın çok büyük olması

B) Tek seferlik bir dosya kopyalama

C) Düzenli aralıklarla dış iletişim denemesi + kalıcılık izleri + kullanıcı davranışıyla açıklanamayan arka plan süreçleri

D) Dosya adının “update” olması

E) Masaüstünde kısayol oluşması

Doğru: C
Gerekçe: RAT/backdoor profili C2 + kalıcılık + süreç anomalileriyle birlikte okunur. A/D/E yüzeysel; B tek başına zayıftır.

8) “Bir Office belgesi, kullanıcı etkileşimi sonrası işletim sisteminde bir komut yorumlayıcıyı tetikleyerek ek kod çalıştırıyor” senaryosu saldırı zincirinde hangi aşamaya daha yakındır?

A) Keşif (reconnaissance)

B) Teslimat (delivery)

C) İstismar/çalıştırma (exploitation)

D) Kurulum (installation)

E) Hedef etki (actions on objectives)

Doğru: C
Gerekçe: Teslimat belgenin ulaşmasıdır; belge içeriğinin kod çalıştıracak şekilde tetiklenmesi istismar/çalıştırma evresine yakındır.

9) Eskalasyon kararını en doğru hangi soru yönlendirir?

A) “Bu dosya ilginç mi?”

B) “Daha çok araç denersem daha çok şey çıkar mı?”

C) “Hangi kanıt eksik ve bu eksik kanıt savunma aksiyonunu etkiliyor mu?”

D) “Dosya adını değiştirsem daha net olur mu?”

E) “Sadece tür etiketi koysam yeter mi?”

Doğru: C
Gerekçe: Eskalasyon, meraktan değil eksik kanıt ve karar ihtiyacından doğar; A/B sezgiseldir, D/E analitik değildir.

10) Aşağıdakilerden hangisi bir IOC örneği olamaz?

A) 203.0.113.45 IP adresi

B) Zararlı dosyanın SHA-256 özeti

C) example.net alan adı

D) Analiz ortamındaki sanal makinenin RAM miktarı

E) Yazılımın oluşturduğu özgün bir registry anahtarı

Doğru: D
Gerekçe: RAM miktarı analist ortamına aittir; IOC, tehdidin bıraktığı izdir.

Bu Modülde Kazanılan Yetkinlikler

Malware türlerinin, “etiket”ten çok amaç ve rol üzerinden daha doğru sınıflandırıldığını
Yaşam döngüsü/kıll chain bakışının dağınık bulguları olay anlatısına ve zaman çizelgesine dönüştürdüğünü
IOC’nin somut teknik izler, IOA’nın ise davranış örüntüleri üzerinden tespit mantığı kurduğunu
TTP, aile ve kampanya kavramlarının savunmada farklı ihtiyaçlara hizmet ettiğini; Pyramid of Pain’in göstergeleri “maliyet” açısından konumlandırdığını
Eskalasyonun “daha derine inmek” değil, eksik kanıtı tamamlayarak savunma kararını güçlendirmek olduğunu

MODÜL 2 — Dosya Triage ve Kimliklendirme

Şüpheli bir dosya elinize geldiğinde en pahalı hata, “ne olduğundan emin olmadan” derine dalmaktır. Bu modül, tıptaki acil servis triage mantığına benzer biçimde; dosyayı hızlı ama kanıta dayalı şekilde tanımanızı, risk sinyallerini okumanızı ve “hangi analiz rotası buna değer?” sorusuna tutarlı bir yanıt üretmenizi sağlar. Buradaki kazanımlar, bir sonraki modülde yapılacak statik incelemenin hedefini keskinleştirir: ne aradığınızı bilirseniz kanıt daha hızlı bulunur.

Modül Teması

Hash Omurgası

SHA-256 öncelikli kriptografik hash + ek olarak fuzzy hash (SSDEEP/TLSH) ile benzerlik avı.

Magic Bytes

Uzantı değil içerik konuşur: dosya türü, gerçek sınıfı belirler ve triage beklentisini şekillendirir.

Erken Risk Sinyalleri

Entropy, kesit anomalileri, overlay ve makro işaretleri; hüküm değil yön gösterir.

Bu Modülde Hedeflenen Kazanımlar

Şüpheli bir dosyayı hash + bağlam ile benzersiz biçimde kimliklendirip olay boyunca tutarlı şekilde takip etmek.
Uzantıya güvenmeden dosya türünü (PE/ELF/Mach-O/script/doküman/arşiv) doğru sınıflandırmak ve kılık değiştirme sinyallerini yakalamak.
Entropy, section/kesit anormallikleri, overlay ve makro göstergeleri gibi erken risk sinyallerini yorumlayıp “ne eksik kanıt var?” sorusunu netleştirmek.
Metadata ve bağlamı birlikte okuyarak analiz önceliğini ve rotasını (statik/dinamik/escalation ihtiyacı) gerekçelendirmek.
İlk bulguları savunma çıktısına çevirmek: IOC paketi, hızlı ön uyarı, kapsam taraması talebi ve rapor notları üretmek.

1. Kimliklendirme omurgası: hash ve bağlam birlikte düşünülür

Bir dosyanın hash’i, içerik temelli “dijital parmak izi” gibidir: dosyada tek bir bit değişse bile kriptografik hash bambaşka bir değere döner. Neden önemli? Çünkü triage aşamasında asıl ihtiyaç “bu dosya hangisi?” sorusuna tartışmasız cevap vermektir: aynı örnekle tekrar uğraşmamak, başka uçlarda aynı dosya var mı taramak ve bulguları doğru örnekle ilişkilendirmek hash ile mümkün olur.

1.1. Kriptografik hash’ler: SHA-256, SHA-1, MD5 (ne işe yarar, nerede sınırları var?)

SHA-256 modern ekosistemde en yaygın “varsayılan kimlik”tir; raporlama ve paylaşımda temel dayanak gibi düşünülür.

MD5 ve SHA-1 bazı ortamlarda hâlâ “uyumluluk” ve eski raporlarla eşleştirme için karşınıza çıkar; ancak çakışma (collision) riskleri nedeniyle “tek başına kesin kimlik” gibi sunulmaz.

Pratikte triage çıktısında birden fazla hash birlikte yazılır (ör. SHA-256 + MD5): biri güçlü kimlik standardını, diğeri ise eski sistemlerle eşleşmeyi kolaylaştırır.

Örnek: Bir kullanıcı “fatura.pdf” diye bir dosya iletir. Dosyayı alır almaz SHA-256 değerini vaka notuna yazarsınız. İki gün sonra aynı isimle bir dosya daha gelir; isim benzer olsa bile hash farklıysa “aynı dosya” yanılgısıyla yanlış sonuca gitmezsiniz.

1.2. “Benzeme” odaklı yaklaşım: fuzzy hashing (SSDEEP/TLSH gibi)

Fuzzy hashing, dosyaların birebir aynı olup olmadığını değil, ne kadar benzer olduğunu ölçmeye çalışır. Neden önemli? Çünkü saldırganlar aynı aile/kampanya içinde küçük değişikliklerle dosyayı varyantlaştırabilir; kriptografik hash’ler bu durumda “tamamen farklı” görünürken, fuzzy hashing benzerlik sinyali üretebilir.

Bu modülde hedef, fuzzy hash çıktısını “benzerlik sinyali” olarak doğru yorumlamaktır: kesin akrabalık iddiası değil, “yakınlık ihtimali” raporlamak. Büyük ölçekli kümelendirme, otomasyon ve doğrulama tarafı daha ileri analizlerde anlam kazanır.

1.3. Hash bir karar etiketi değildir: “kimlik” ayrı, “risk” ayrı

Hash, dosyanın kimliğini verir; ama tek başına “zararlı/zararsız” hükmü kurmaz. Neden önemli? Çünkü aynı dosya farklı bağlamda farklı risk taşıyabilir (test ortamında meşru bir araç, üretimde şüpheli bir örüntünün parçası olabilir) ve bazı dosyalar “temiz görünüp” zincirin taşıyıcısı rolünü oynayabilir.

Örnek: Aynı SHA-256’e sahip bir dosya iki uçta görülür. Birinde kullanıcı dosyayı çalıştırmıştır, diğerinde e-posta geçidi dosyayı karantinaya almıştır. Dosya aynı olsa da aciliyet aynı değildir; rapor, “çalıştırılmış olma” bilgisini risk ve öncelik gerekçesi olarak yazmalıdır.

Dikkat: Hash’i raporda “kanıt/kimlik” olarak yazmak başka, hash’e bakıp “kesin zararlı” demek başkadır. Triage çıktısında doğru dil şudur: “Dosya şu hash ile kimliklendirildi; şu sinyaller görüldü; şu kanıt eksik; şu rota önerildi.”

İpucu: Aynı olayda paydaşlar dosyayı farklı isimlerle anabilir. Karmaşayı bitiren şey genellikle dosya adı değil, vaka kimliği + SHA-256 kombinasyonudur. Bu ikisini her triage notunun en üstüne koymak, iletişim maliyetini ciddi düşürür.

2. Dosya türü tespiti: uzantı değil, içerik konuşur

Dosya türü, “bu örnek nasıl çalışır ve hangi artefaktları bırakması beklenir?” sorusunun temelidir. Neden önemli? Çünkü yanlış dosya türü varsayımı; yanlış araç, yanlış beklenti ve kaçırılan kanıt demektir.

2.1. “Magic bytes / magic number”: dosyanın kendi imzası

Uzantı kolayca değiştirilebilir; daha güvenilir sinyal, dosyanın başlık (header) imzası ve iç yapısıdır.

PE (Windows) dünyasında yürütülebilir dosyalar çoğunlukla DOS header ile başlar ve “MZ” imzası bu katmanda görülür.

ELF (Linux) dosyaları, header’da 0x7F ve ardından “ELF” dizisini taşıyan bir imza ile tanınır.

Mach-O (macOS) formatı da kendi header imzalarıyla ayırt edilir; triage’da kritik olan, uzantıdan bağımsız olarak format ailesini doğru yakalamaktır.

Örnek: “rapor.pdf” adıyla gelen bir dosyanın içerik imzası yürütülebilir bir formata işaret ediyorsa bu, kılık değiştirme ihtimalini yükselten bir risk sinyalidir. Böyle bir durumda doküman güvenliği çizgisinden çıkıp yürütülebilir analizi rotasını öne alırsınız.

2.2. Temel sınıflar: triage beklentisi neye göre şekillenir?

PE (Windows EXE/DLL): Import/section yapısı, sürüm bilgileri, imza/sertifika izleri gibi statik sinyaller zengindir; dinamikte süreç ağacı ve kalıcılık izleri beklenebilir.

ELF (Linux): Çalışma izinleri, bağımlılıklar ve kalıcılık için sistem servisleri/planlayıcı izleri triage’da daha görünür hale gelir.

Mach-O (macOS): İmzalama/notarization bağlamı ve başlatma öğeleri triage kararını etkileyebilir.

Script (bat/ps1/js/vbs vb.): Genellikle okunabilir içerik izleri taşır; hızlı içerik incelemesi triage’da yüksek değer üretir.

Doküman (Office/PDF vb.): Makro, gömülü nesne, şüpheli bağlantı ve anormal metadata erken sinyaldir.

Arşiv (zip/7z/rar vb.): Arşiv çoğu zaman “taşıyıcıdır”; asıl inceleme nesnesi içerideki dosyalardır.

2.3. Uzantı aldatmacaları: çift uzantı ve kullanıcı yanılsaması

Bazı dosyalar “dosya.pdf.exe” gibi çift uzantıyla adlandırılır; bazı sistemlerde son uzantının görünürlüğü kullanıcıyı yanıltabilir. Triage açısından bu, yalnızca teknik bir detay değil; giriş vektörü ve kullanıcı etkileşimi riskini büyüten bir sinyaldir.

Dikkat: “Arşiv temiz görünüyor” cümlesi tek başına zayıftır. Arşiv dosyanın kendisi değil, içindekiler asıl inceleme konusudur. Triage notu, arşivden çıkan dosya türlerini ve hangisinin neden öncelikli olduğunu söylemelidir.

İpucu: Şüpheli bir pakette tek bir format aramayın: arşiv içinde doküman + script + yürütülebilir bir arada olabilir. Triage’ın değeri, bu karmayı hızlıca “önce şuna bak” sırasına koyabilmesidir.

3. Erken risk sinyalleri: entropy, kesit anormallikleri, overlay ve makrolar

Bu bölüm “dosyanın yapısında normal dışı ne var?” sorusuna erken yanıt üretir. Neden önemli? Çünkü erken sinyaller; zamanınızı nereye harcayacağınızı ve hangi analiz yönteminin daha anlamlı olacağını belirler.

3.1. Entropy: sıkıştırma/şifreleme/paketleme şüphesi (ama hüküm değil)

Entropy, verideki rastgeleliğin ölçüsüdür; bayt temelli Shannon entropisi pratikte 0–8 aralığında yorumlanır ve 8’e yaklaşan değerler “daha rastgele” bir dağılıma işaret eder. Triage bağlamında yüksek entropy, içerikte sıkıştırma/şifreleme/obfuscation veya paketleme ihtimalini düşündürür. Neden önemli? Çünkü bu, statik sinyallerin sınırlı kalabileceğini ve dinamik gözlemin daha kritik hale gelebileceğini önceden haber verir.

Örnek: Bir yürütülebilirde, normalde okunabilir izler beklenen bir bölüm yüksek entropy gösteriyorsa anlamlı string bulamamak şaşırtıcı değildir. Triage notu bunu “statik bulgular sınırlı kalabilir; dinamik artefakt toplama önceliklendirilmeli” şeklinde savunma gerekçesine dönüştürür.

Paketleyicilerin açılması ve iç yapının ayrıştırılması, pratikte daha ileri doğrulama gerektirir. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

3.2. Section/kesit anomalileri: isim, boyut, izinler, tutarsızlıklar

Özellikle PE dünyasında section isimleri (.text, .data, .rsrc gibi), boyut/yerleşim ilişkileri ve izinler “normal aralık” hissi verir. Anomali; bu normalin dışında kalan örüntülerdir: beklenmedik section isimleri, olağandışı boyutlar, diskteki boyut ile bellekteki boyut arasında anlamlı farklar veya beklenmedik çalıştırma izinleri gibi.

Örnek: “Section yapısı olağandışı” demek tek başına zayıftır. Daha raporlanabilir bir yaklaşım: “Section dağılımı tipik profile uymuyor; bu nedenle statik sinyaller sınırlı olabilir ve davranış/artefakt gözlemiyle kanıt tamamlanmalı” demektir.

3.3. Overlay: dosyanın “görünen sınırından” sonra gelen ek veri

Overlay, dosya formatının beklenen yapısı bittiği halde dosya sonunda ek veri bulunmasıdır. Bu bazen meşrudur (kurulum paketleri veya kendi içinde kaynak taşıyan uygulamalar), bazen de gizlenmiş konfigürasyon/ikincil bileşen şüphesi doğurur. Neden önemli? Çünkü overlay varlığı, “dosya tek parça gibi görünse de başka bir şey taşıyor olabilir” uyarısıdır.

Örnek: Dışarıdan tek bir yürütülebilir gibi görünen dosya, triage’da belirgin overlay sinyali veriyorsa rapor notu “tekil dosya gibi ele alınsa da içinde ek veri/ikincil içerik taşıma ihtimali var” der ve sonraki analiz planını etkiler.

Overlay içeriğinin çıkarılması ve doğrulanması, uygulamada daha ileri yöntemler gerektirebilir. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

3.4. Makro işaretleri: doküman içinde tetiklenebilir yürütme niyeti

Makro, doküman içinde otomasyon sağlayan kod parçalarıdır; kötüye kullanımda “kullanıcı etkileşimiyle kod çalıştırma” zincirinin halkasına dönüşebilir. Neden önemli? Çünkü “çalıştırılabilir dosya yok” sanılan bir olayda asıl risk, dokümanın tetiklediği davranış olabilir.

Triage açısından sinyal üreten noktalar:

Makro varlığı/aktif içerik izleri

Gömülü nesneler veya dış bağlantı çağrışımları

Kullanıcıyı “içeriği etkinleştir” gibi aksiyona iten sosyal ipuçları

Bazı belgelerde, belge açılır açılmaz çalışan otomatik tetikleyici makro giriş noktalarının (ör. AutoOpen/Document_Open gibi) izleri

Örnek: Bir ofis belgesi içinde “içeriği etkinleştirmeniz gerekiyor” yönlendirmeleri ve şüpheli bir bağlantı izi bulunur. Bu yalnızca dosyayı kimliklendirmekle kalmaz; olayın giriş vektörü ve kullanıcı etkileşimi boyutunu da rapora taşır.

Dikkat: Entropy/overlay/makro gibi sinyaller “kesin zararlı” demek değildir; risk bayrağıdır. Triage çıktısı, bayrağı gördükten sonra “hangi kanıt eksik ve bu kanıtı hangi gözlem tamamlar?” sorusunu öne alır.

İpucu: Sinyaller tek tek değil, kümeler halinde ikna edicidir: yüksek entropy + statikte az okunabilir iz + beklenmedik format uyumsuzluğu gibi birleşimler, savunma ekibine “neden ciddiye alıyoruz?” sorusunun cevabını hazır verir.

4. Metadata ve temel inceleme yaklaşımı: “kimlik kartı” ama sahtecilik ihtimaliyle

Metadata, dosyanın zamanlar, üretim aracı izleri, sürüm bilgileri, belge özellikleri gibi yan bilgilerini taşır. Neden önemli? Çünkü bazen içerikten önce metadata, sahtecilik izlerini, kullanıcı etkisini veya olay bağlamını aydınlatır; fakat aynı zamanda manipüle edilebilir.

4.1. Bağlam: “nereden geldi?” sorusu kaybolursa triage eksik kalır

Triage yalnızca teknik değildir. Dosya hangi kanaldan geldi, hangi uçta görüldü, kullanıcı çalıştırdı mı, bir güvenlik ürünü karantinaya aldı mı, şikâyet neydi… Bunlar öncelik kararını değiştirir.

Örnek: Aynı dosya iki uçta görünür. Birinde kullanıcı çalıştırmış, diğerinde yalnızca indirilenler klasöründe duruyordur. İkincisi potansiyel risk taşır ama birincisi “etki ihtimali” nedeniyle daha acildir; raporda bu ayrım açık yazılır.

4.2. Zaman tutarlılığı ve “timestomping” şüphesi

Dosya zaman damgaları ve bazı derleme/zaman alanları kopyalama/indirme süreçleriyle değişebilir ya da saldırgan tarafından manipüle edilebilir. Bu tür manipülasyonlar literatürde “timestomp” olarak anılır ve iz silme/yanıltma amaçlarıyla ilişkilendirilir.

Aşırı uç tarihler (örneğin 1970’e çok yakın veya gerçekçi olmayan geleceğe işaret eden değerler) triage’da “metadata güvenilirliği sınırlı” notunu hak eder. Bu, tek başına hüküm değil; tutarlılık arama gereğidir.

4.3. Dijital imza: güven sinyali olabilir, garanti değildir

Dijital imza (code signing), dosyanın bütünlüğü ve yayıncı bilgisi hakkında sinyal verebilir; savunma tarafında önceliklendirmeyi etkileyebilir. Neden önemli? Çünkü imzalı dosyalar her zaman temiz değildir: çalıntı/istismar edilmiş sertifikalar veya güven zincirinin suistimaliyle kötü amaçlı yazılımlar da “meşru görünümlü” hale getirilebilir.

Triage dilinde güvenli yaklaşım: “imza var/yok” bilgisini yazmak, ama bunun tek başına aklanma olmadığını belirtmektir.

4.4. Triage çıktısı nasıl savunma aksiyonuna dönüşür?

Triage’ın güçlü çıktısı, “bulgular listesi” değil; eyleme dönük bir pakettir:

Dosya kimliği: SHA-256 (+ gerekirse MD5/SHA-1) ve görülen isimler

Dosya türü: içerik temelli sınıflandırma, uzantı–içerik uyumu

Erken risk sinyalleri: entropy/section/overlay/makro gibi bayraklar

Eksik kanıt: neyi henüz bilmiyoruz? (çalıştırıldı mı, ağ denemesi var mı, ikincil bileşen bırakıyor mu gibi)

Önerilen rota: statik mi dinamik mi öncelikli; hangi artefaktların özellikle izlenmesi gerekir

Savunma çıktısı: IOC paketi + kapsam taraması talebi + hızlı ön uyarı metni + rapor notları

Bu yapı, bir sonraki modülde yapılacak statik analizde “ne arıyorum?” sorusunu hazır hale getirir.

Terimler Sözlüğü

Terim	Açıklama
Triage	Ön değerlendirme; örneği hızlı sınıflandırma ve öncelik/rota belirleme
Hash	Dosya içeriğinden üretilen özet/parmak izi değeri
SHA-256	Güncel, güçlü kriptografik özet; yaygın kimlik standardı
SHA-1	Kriptografik özet; çakışma riskleri nedeniyle sınırlı güven
MD5	Kriptografik özet; uyumluluk/arama için görülür, tek başına kesin kimlik sayılmaz
Fuzzy hashing	Birebir aynı yerine “benzer” dosyaları yakalamaya yarayan yaklaşım (ör. SSDEEP/TLSH)
Magic bytes / Magic number	Dosya türünü içerikten belirleyen header imza baytları
PE	Windows çalıştırılabilir format ailesi (EXE/DLL)
ELF	Linux çalıştırılabilir format
Mach-O	macOS çalıştırılabilir format
Entropy	Verideki rastgelelik ölçüsü; sıkıştırma/şifreleme/paketleme şüphesine sinyal olabilir
Packed	Paketlenmiş; içerik analizden kaçınmak ya da dağıtımı optimize etmek için sıkıştırılmış/ambalajlanmış olabilir
Section (Kesit)	Yürütülebilir dosyaların bölümleri; isim/izin/boyut tutarsızlıkları anomali sinyali verebilir
Overlay	Dosya formatının beklenen sınırından sonra gelen ek veri
Macro	Doküman içinde otomasyon kodu; kötüye kullanımda tetikleyici rol oynayabilir
Metadata	Dosyanın yan bilgileri; zaman/üretim/özellik gibi bağlam sinyalleri taşır
Compile time	Bazı ikililerde derleme zamanı alanı; yanıltılabilir olduğu için tutarlılık kontrolü gerekir
Code signing / Dijital imza	Dosyanın bütünlüğü ve yayıncı sinyali; tek başına güven garantisi değildir
Timestomping	Zaman/metadata alanlarını manipüle ederek yanıltma veya iz silme yaklaşımı

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)Bir dosyayı olay boyunca en güvenilir biçimde tekilleştirmek için triage raporunda hangi bilgi “kimlik” omurgasıdır?

A) Dosya adı ve uzantısı

B) Dosya ikonunun türü

C) SHA-256 gibi güçlü bir kriptografik hash

D) Dosyanın kaydedildiği klasör adı

E) Kullanıcının dosyayı nasıl bulduğuna dair anlatımı

Doğru: C
Gerekçe: Hash içerik temelli benzersiz kimlik verir. A/B/D değiştirilebilir ve yanıltıcıdır; E bağlam açısından değerlidir ama kimlik değildir.

2)MD5 veya SHA-1 değerleri triage’da hâlâ raporlansa bile neden “tek başına kesin kimlik” gibi sunulmaz?

A) Çok yavaş hesaplandıkları için

B) Sadece belirli işletim sistemlerinde çalıştıkları için

C) Çakışma (collision) riskleri nedeniyle güvenilirliklerinin sınırlı olması

D) Yalnızca metin dosyalarında çalıştıkları için

E) Entropy ile karıştırıldıkları için

Doğru: C
Gerekçe: Çakışma riski, tek başına kesin kimlik iddiasını zayıflatır. A/B/D yanlış; E konu dışıdır.

3)SSDEEP/TLSH gibi fuzzy hashing hangi durumda daha anlamlı sinyal üretir?

A) Dosyanın birebir kopyasını bulmak istediğinizde

B) Uzantının doğru olup olmadığını doğrulamak istediğinizde

C) Küçük değişikliklerle varyantlaşmış örnekler arasında benzerlik aradığınızda

D) Dosyanın ağ trafiği üretip üretmediğini anlamak istediğinizde

E) Makro varlığını tespit etmek istediğinizde

Doğru: C
Gerekçe: Fuzzy hashing benzerliği yakalamaya odaklıdır. A’da kriptografik hash daha uygundur; B/D/E farklı analiz alanlarıdır.

4)Uzantısı “.pdf” olan bir dosyanın içerik imzasının yürütülebilir formatla uyumlu görünmesi triage’da en doğru nasıl yorumlanır?

A) Normaldir; uzantı her zaman güvenilirdir

B) Kılık değiştirme ihtimali nedeniyle risk bayrağıdır; analiz rotası yeniden düşünülür

C) Dosya otomatik olarak zararsız kabul edilir

D) Sadece kullanıcı deneyimi sorunudur, güvenlik etkisi yoktur

E) Dosya türü yalnızca antivirüs sonucuyla belirlenebilir

Doğru: B
Gerekçe: Uzantı–içerik uyumsuzluğu güçlü bir sinyaldir. A ters ve hatalıdır; C/D yanlış; E gereksiz sınırlayıcıdır.

5)Entropy’nin bazı bölümlerde 8’e yakın olması triage’da en çok neye işaret eder?

A) Kesin zararlı olduğuna

B) İçerikte sıkıştırma/şifreleme/paketleme olabileceğine ve statik sinyallerin sınırlı kalabileceğine

C) Mutlaka arşiv dosyası olduğuna

D) Mutlaka makro içerdiğine

E) Mutlaka ağ üzerinden yayılabildiğine

Doğru: B
Gerekçe: Yüksek entropy “risk bayrağıdır”, kesin hüküm değildir. C/D/E doğrudan çıkarım yapılamaz; A aşırı kesinliktir.

6)Overlay varlığı triage notuna neden girmelidir?

A) Overlay her zaman meşrudur, rapora gerek yoktur

B) Overlay dosyayı otomatik olarak temiz yapar

C) Dosyanın tek parça görünse de ek veri/ikincil içerik taşıyabileceğine dair yapısal sinyal üretir

D) Overlay yalnızca metin dosyalarında olur

E) Overlay ağ trafiğini otomatik şifreler

Doğru: C
Gerekçe: Overlay, ek içerik taşıma ihtimalini artıran yapısal sinyaldir. A/B/D/E yanlıştır.

7)Arşiv dosyaları (zip/7z/rar) için triage kararını en çok güçlendiren yaklaşım hangisidir?

A) Arşivin hash’ini yazmak tek başına yeterlidir

B) İçeriğe bakmadan “temiz” demek mümkündür

C) Arşiv içindeki dosya türlerini çıkarıp öncelik sırası belirlemek gerekir

D) Arşivler yürütülemez, risk taşımaz

E) Sadece arşiv uzantısına göre karar verilir

Doğru: C
Gerekçe: Arşiv çoğu zaman taşıyıcıdır; risk içeriğe bağlıdır. A tekilleştirme için iyidir ama yeterli değildir; B/D/E hatalıdır.

8)Bir dokümanda makro işaretlerinin bulunması triage açısından en tutarlı risk çerçevesiyle nasıl ele alınmalıdır?

A) Makro varsa mutlaka fidye yazılımıdır

B) Makro, kullanıcı etkileşimiyle yürütme zinciri doğurabileceğinden giriş vektörü/tetiklenme riski olarak değerlendirilir

C) Makro sadece görsel/biçimsel bir özelliktir

D) Makro varsa hash raporlanamaz

E) Makro tespiti yalnızca bellek analiziyle mümkündür

Doğru: B
Gerekçe: Makro tetikleyici rol oynayabilir; triage’da bağlam ve risk değerlendirmesi güçlenir. A genelleme; C yanlış; D alakasız; E doğru değildir.

9)Metadata incelemesinde en sık yapılan hata hangisine en yakındır?

A) Dosya türünü içerik imzasıyla doğrulamak

B) Tek bir metadata alanına dayanıp kesin hüküm vermek

C) SHA-256 değerini vaka notuna yazmak

D) Arşiv içeriğini listeleyip öncelik belirlemek

E) Uzantı–içerik uyumsuzluğunu not etmek

Doğru: B
Gerekçe: Metadata manipüle edilebilir veya taşınma etkisiyle değişebilir; tutarlılık aranmalıdır. Diğer seçenekler iyi triage pratikleridir.

10)Triage çıktısının savunma aksiyonuna dönüşmesini en çok hangi bileşen seti sağlar?

A) Dosya ikonunun ekran görüntüsü

B) Yalnızca dosya adının rapora yazılması

C) Hash + dosya türü + erken risk sinyalleri + eksik kanıt + önerilen sonraki adımların birlikte verilmesi

D) Sadece “zararlı/zararsız” etiketi

E) Sadece kullanıcı şikâyetinin kopyalanması

Doğru: C
Gerekçe: Savunma için eyleme dönük paket gerekir: kimlik, sınıf, sinyal, boşluk ve rota. A/B/D/E tek başına yetersizdir.

Bu Modülde Kazanılan Yetkinlikler

Triage’ın “önce tanı, sonra derinleş” disiplinini; hash’in olay boyunca tartışmasız kimlik omurgası olduğunu.
SHA-256’ın modern standarda karşılık geldiğini; MD5/SHA-1’in uyumluluk için görülebileceğini ama tek başına kesin kimlik iddiasına taşınmaması gerektiğini.
Fuzzy hashing’in “benzerlik” sinyali ürettiğini; varyant şüphesinde işe yaradığını.
Dosya türünü uzantıdan bağımsız, içerik imzası ve yapı üzerinden okumanın; uzantı–içerik uyumsuzluğunun güçlü bir risk bayrağı olduğunu.
Entropy, section/kesit anomalileri, overlay ve makro işaretlerinin “kesin hüküm” değil, kanıt boşluklarını görünür kılan erken sinyaller olduğunu.
Metadata’nın değerli bir bağlam kaynağı olduğunu ama manipüle edilebileceği için tutarlılık kontrolü gerektirdiğini; dijital imzanın güven sinyali olabileceğini fakat garanti olmadığını.
Triage çıktısını savunma aksiyonuna çevirecek rapor omurgasını: kimlik + sınıf + sinyal + eksik kanıt + rota + IOC paketi.

MODÜL 3 — Statik Analizle Hızlı Bulgular: Dosyanın İçinden Kanıt Okuma

Modül 2’de kimliklendirdiğiniz şüpheli dosyayı bu kez çalıştırmadan, yalnızca dosyanın yapısına ve içeriğine bakarak okumayı öğreniyorsunuz. Statik analiz, dosya “uykudayken” yapılan incelemedir: size yazılımın olası yetenekleri, iletişim kurmak isteyebileceği hedefler ve sistemde bırakabileceği izler hakkında hızlı ama kanıta dayalı sinyaller verir. Buradaki amaç “kesin hüküm” değil; doğru soruları üretmek, ilk IOC adaylarını güvenli bir dille paketlemek ve dinamik analizde nereye bakacağınızı netleştirmektir.

Modül Teması

Strings & IOC

URL, IP, domain, registry yolu, mutex, hata mesajı — niyetin ilk yüzünü gösteren satır aralarındaki ipuçları.

Import Haritası

Çağrılan API’ler ‘yetenek’ haritasıdır: ağ, dosya, registry, kalıcılık, kripto kabiliyetleri.

Manifest & PDB

Talep edilen yetkiler, derleme izleri ve PDB yolları; ipucu ama tek başına ‘kanıt’ değil.

Bu Modülde Hedeflenen Kazanımlar

Statik analizin hangi kanıtları üretebildiğini ve nerede sınırlandığını doğru çerçevelemek
PE dünyasında import/section/resource/sürüm bilgisi gibi sinyallerle “yetenek haritası” çıkarabilmek
Dosya içindeki strings (metin dizileri) üzerinden ağ, dosya yolu ve kayıt defteri (registry) göstergeleri yakalamak
Manifest, derleyici izleri ve PDB yolları gibi metadata ipuçlarını istihbarat üretirken temkinli kullanmak
Elde edilen bulgularla “yazılım ne yapmaya çalışıyor?” sorusuna ilk teknik hipotezi kurmak; eksik kanıt listesini yazıp analiz rotasını gerekçelendirmek

1. Statik analiz nedir, ne değildir?

Statik analiz; dosya yapısı, başlık bilgileri, içeride kalan okunabilir metinler, kaynaklar ve metadata üzerinden çıkarım yapma yaklaşımıdır. Neden önemli? Çünkü birçok olayda ilk kararlar (öncelik, izolasyon ihtiyacı, kapsam taraması) hızlı kanıt ister; statik analiz bu kanıtı düşük riskle sunar.

Statik bulgular genelde iki kümeye ayrılır:

Doğrudan görülen izler: Dosyanın içinde açıkça duran URL, alan adı, IP, dosya yolu, sürüm bilgisi, imza bilgisi gibi.

Hazırlık sinyalleri: Yazılımın “muhtemel” yeteneklerini düşündüren izler; örneğin belirli sistem işlevlerine çağrı hazırlığı veya belirli kaynakların gömülü olması.

Dikkat: Statik bulguyu “olmuş bitmiş davranış” gibi yazmak raporu zayıflatır. Güçlü rapor dili şudur: “Şu iz görüldü → bu iz şu davranış ihtimalini güçlendiriyor → şu kanıtlar eksik, doğrulama için şunlar izlenmeli.”

2. Strings analizi: satır aralarından IOC ve niyet okumak

Derleme ve paketleme süreçlerinde komutların çoğu makine diline dönüşür; ama hata mesajları, URL’ler, dosya yolları, yapılandırma parçaları sıkça dosya içinde okunabilir biçimde kalır. Bu okunabilir parçalar “strings” olarak anılır (ASCII ya da Unicode olabilir). Neden önemli? Çünkü doğru seçilmiş bir strings incelemesi, dakikalar içinde hem IOC adayı çıkarır hem de saldırı senaryosunu daraltır.

2.1. Ağ göstergeleri (URL / IP / domain)

Dosyanın dış dünya ile konuşma niyetini en net ele veren izlerdir.

Örnek: Dosya içinde <https://example.org/updates/cfg.php> benzeri bir yol görmeniz, yazılımın dışarıdan yapılandırma çekmeye çalışabileceğine dair güçlü bir sinyaldir. Bu, “bağlandı” kanıtı değildir; ama avcılık/tarama için değerli bir IOC adayına dönüşebilir.

2.2. Dosya yolları ve kayıt defteri (registry) anahtarları

Yazılımın nereye yazmak isteyebileceğini, hangi ayarları hedefleyebileceğini veya kalıcılık davranışına hazırlanıp hazırlanmadığını düşündürebilir.

Örnek: Bir strings listesinde Windows başlangıç davranışlarıyla ilişkilendirilen bir registry yolunun geçmesi, “kalıcılık ihtimali” hipotezini güçlendirir. Bu durumda dinamik doğrulamada süreç başlangıçları ve ilgili sistem kayıtları özellikle izlenecekler listesine girer.

2.3. Mutex isimleri: ağ çapında avcılık için güçlü bir iz

Mutex (mutual exclusion), aynı programın bir sistemde aynı anda tek kopya çalışmasını kontrol etmek için kullanılan bir nesnedir. Zararlı yazılımlar çoğu zaman kendilerine özgü mutex adları kullanır. Neden önemli? Çünkü benzersiz bir mutex adı, uç nokta telemetrisi veya avcılık sorgularında “aynı kampanyayı” yakalamayı kolaylaştıran pratik bir göstergedir.

Örnek: Global\Global_Unique_ID_123 gibi bir string görülürse, bu değer savunma tarafında “IOC adayı” olarak not edilir; ağ genelinde aynı iz aranabilir.

2.4. Hata mesajları ve fonksiyon adları: amaç ve teknoloji ipuçları

Hata mesajları bazen yazılımın niyetini ele verir; fonksiyon adları ise kullanılan yaklaşımı kabaca işaret edebilir.

Örnek: Dosyada “dosya işleme hatası”, “bağlantı kurulamadı” gibi anlamlı hata metinleri, yazılımın hangi adımlarda zorlanabileceğini gösterir; raporda “tahmini davranış akışı” için destekleyici kanıt olur.

Dikkat: Bazı örneklerde okunabilir string’ler çok az olabilir veya neredeyse hiç görünmeyebilir. Bu durum içerikte saklama/karartma (obfuscation) ya da paketleme/şifreleme benzeri yöntemlerin kullanıldığına işaret edebilir; statik verimin düşeceği ve dinamik gözlemin daha kritik hale gelebileceği rapora yazılmalıdır. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

İpucu: Strings bulgularını rapora “ham liste” gibi dökmek yerine, 3 başlık altında paketleyin: Ağ (domain/IP/URL), Sistem (dosya yolu/registry), Operasyonel izler (mutex/hata mesajı). Bu, SOC ekibinin tarama ve önleme adımını hızlandırır.

3. Import analizi: yeteneklerin haritası

Import table, bir programın çalışırken çağırmayı planladığı işletim sistemi işlevlerinin ve kütüphanelerin izlerini taşır. Neden önemli? Çünkü “hangi kasları kullanacak?” sorusuna hızlı yanıt verir; ağ, kripto, süreç yönetimi gibi kabiliyetleri daha çalıştırmadan işaret edebilir.

Aşağıdaki ilişkilendirme, tek başına hüküm değil; hipotez kurmak içindir:

Ağ kabiliyeti sinyalleri: Ağla ilgili kütüphane/işlev izleri, dış iletişim ihtimalini güçlendirir.

Kripto kabiliyeti sinyalleri: Kriptografi işlevleri, veri şifreleme/özetleme ya da iletişimi koruma gibi amaçları düşündürebilir.

Süreç/sistem etkileşimi sinyalleri: Süreç oluşturma, bellek ayırma, süreçler arası etkileşim gibi izler; daha agresif sistem davranışlarına işaret edebilir.

Örnek: Import listesinde hem ağ hem de kripto ile ilişkili izler birlikte görülürse, rapor bunu “dış iletişim + veri işleme/koruma” ekseninde bir hipotez olarak yazar; doğrulama için ağ telemetrisi ve dosya/registry değişiklikleri izleme planına eklenir.

“Ordinal” olarak görülen import’lar (isim yerine numara) da bazen dikkat çeker; bazı dosyalar çağrıları daha az görünür kılmak için bu yolu tercih edebilir.

İpucu: Import listesi çok kısa ve “genel amaçlı yükleme/çözümleme” işlevleri ağırlıktaysa, bu durum dosyanın gerçek kabiliyetlerini statikte saklıyor olabileceğini düşündürür. Sonraki adım planına “statik bulgu sınırlı olabilir” notu ekleyip dinamik doğrulama kapsamını genişletmek daha sağlıklıdır.

Dikkat: Import’ların varlığı, o davranışın kesin gerçekleştiği anlamına gelmez. Yazılım o fonksiyonları hiç çağırmayabilir veya belirli koşullarda çağırabilir. Bu yüzden raporda “kanıt türü”nü (doğrudan iz / hazırlık sinyali) açık belirtin.

4. Resource ve Manifest incelemesi: dosyanın taşıdığı ek yükler ve yetki isteği

4.1. Resource (kaynak) bölümü: gizli bileşen veya yapılandırma izi

Resource bölümü normalde ikon, metin, arayüz parçaları gibi meşru içerikler taşır; fakat bazı vakalarda ek veri veya ikincil bileşen izleri de buraya “sıkıştırılabilir”. Neden önemli? Çünkü dosya dışarıdan tek parça görünse bile içeride başka bir içerik taşıyor olabilir; bu da olayın çok aşamalı olma ihtimalini artırır.

Örnek: Dosyanın toplam boyutu beklenmedik derecede büyük ve kaynak bölümünde “anlamsız görünen” büyük bir veri yığını varsa, rapor “ikincil bileşen taşıma ihtimali” notunu düşer; doğrulamada dosya sistemi yazma aktiviteleri ve yeni oluşturulan dosyalar özellikle izlenir.

4.2. Manifest: programın talep ettiği yetki ve uyumluluk izleri

Manifest, programın hangi yetki seviyesinde çalışmak istediği gibi bilgileri taşıyabilir. Neden önemli? Çünkü sıradan bir kullanım senaryosunda gereksiz görünen yetki talepleri, arka planda sistem değişikliği hedeflendiğine dair sinyal üretir.

Örnek: Dışarıdan “belge gibi” görünen bir dosya davranışında, yüksek yetki talebi işaretleri görülürse bu bir anomali olarak rapora girer; doğrulama adımlarında sistem dosyaları/ayarları üzerinde değişiklik araması genişletilir.

5. Derleme ipuçları, sürüm bilgileri ve PDB yolları: istihbarat üretirken temkinli olmak

Sürüm bilgileri (version info) dosyanın kendini nasıl “tanıttığını” gösterir; saldırganlar kimi zaman dosyayı meşru göstermek için bu alanları sahte doldurabilir. Neden önemli? Çünkü bu alanlar sosyal mühendislik boyutunu aydınlatabilir; ama tek başına güven kanıtı değildir.

PDB path (Program Database yolu), bazı derlemelerde geliştiricinin proje dizin yolunu açık edebilir. Neden önemli? Çünkü proje adı, klasör yapısı, bazen de yazılımın amacı hakkında ipucu verebilir; ancak bu ipuçları da sahte veya yanıltıcı olabilir.

Örnek: PDB yolunda proje adı çağrıştıran bir ifade görürseniz, bunu “muhtemel amaç/etiket” olarak rapora not edersiniz; kesin sınıflandırmayı başka kanıtlarla desteklersiniz.

Rich Header gibi derleyici izleri de (özellikle PE ekosisteminde) “hangi derleyici ailesi/araç zinciri” kullanılmış olabileceğine dair sinyal üretebilir; bu sinyal, büyük resimde kampanya benzerliği araştırırken faydalıdır.

İpucu: Profil çıkarırken “tek bir iz → kesin sonuç” tuzağına düşmeyin. En iyi yaklaşım, birden çok zayıf sinyali (strings + import + resource + metadata) aynı hipotez altında birleştirip güven düzeyini açık yazmaktır.

6. Statik bulguyu savunma aksiyonuna çevirme: IOC paketi + güven düzeyi + eksik kanıt listesi

Statik analiz sonunda iki ürün hedeflenir:

Kısa ve anlaşılır olay anlatısı: “Ne gördük, neden önemli, ne öneriyoruz?”
Savunma paketi: IOC adayları + kapsam taraması notu + doğrulama planı

IOC (Indicator of Compromise), hash, domain, IP, URL yolu, dosya yolu, registry izi gibi aranabilir göstergelerdir. Statikten IOC çıkarırken iki ilke raporu güçlendirir:

Değerin nerede görüldüğü: “strings içinde geçti”, “manifestte işaret edildi”, “sürüm bilgisinde göründü” gibi.

Güven düzeyi: “doğrudan görülen iz” mi, “hazırlık sinyali” mi?

Örnek: Strings içinde 203.0.113.88 ve C:\Windows\System32\drivers\etc\hosts benzeri ifadeler yan yana görünürse, rapor bunu “ağ yönlendirme/dns davranışına hazırlık ihtimali” olarak yazar; doğrulamada hosts dosyası değişikliği ve ağ çözümleme davranışları özellikle kontrol edilir.

Eksik kanıt listesi ise rotayı netleştirir:

Dosya gerçekten çalıştırıldı mı? (bağlam kanıtı)

Dış iletişim gerçekleşti mi? (ağ kanıtı)

Kalıcılık izi bırakıldı mı? (host kanıtı)

İkincil bileşen üretildi mi? (dosya sistemi kanıtı)

Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

Terimler Sözlüğü

Terim	Açıklama
Static analysis	Statik analiz; dosyayı çalıştırmadan yapı/içerik/metadata üzerinden inceleme
Dynamic analysis	Dinamik analiz; dosyayı çalıştırarak davranışlarını gözlemleme
Strings	Metin dizileri; ikili dosya içindeki okunabilir karakter dizileri
Import table	İçe aktarma tablosu; programın çağırmayı planladığı sistem işlevleri/kütüphane izleri
API	Uygulama programlama arayüzü; işletim sistemi işlevlerine erişim “dili”
DLL	Dinamik bağlantı kitaplığı; işlevleri barındıran kütüphane dosyası
Section	Kesit/bölüm; yürütülebilir dosyanın yapısal parçaları
Resource	Kaynak bölümü; ikon/metin vb. içerikler ve bazen ek veri barındırabilir
Manifest	Bildirim dosyası; yetki/uyumluluk gibi çalışma koşullarını ifade eden metadata
Mutex	Karşılıklı dışlama nesnesi; aynı programın tek kopya çalışmasını kontrol etmek için kullanılabilir
IOC	İhlal göstergesi; aranabilir teknik gösterge (hash, domain, IP, URL yolu vb.)
Ordinal import	İsim yerine numara ile yapılan import; görünürlüğü azaltma amacı taşıyabilir
PDB path	Sembol dosyası yolu; derleme ortamına dair iz taşıyabilen metadata
Obfuscation	Karartma; okunabilirliği azaltmaya dönük gizleme yaklaşımı
Escalation	Eskalasyon; eksik kanıt nedeniyle analizi bir üst seviyeye taşıma kararı

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)Strings listesinde 203.0.113.88 ile C:\Windows\System32\drivers\etc\hosts ifadesi birlikte görülüyorsa en tutarlı yorum hangisidir?

A) Yazılım ekran görüntüsü alacaktır.

B) Ağ çözümleme/yönlendirme davranışlarına müdahale ihtimalini güçlendiren bir sinyal vardır; doğrulama gerekir.

C) Bilgisayarın işlemcisi aşırı ısınacaktır.

D) Dosya kesin olarak antivirüstür.

E) Dosya yalnızca bir resim dosyasıdır.

Doğru: B
Gerekçe: IP + hosts yolu birlikte, ağ yönlendirme/dns davranışı hipotezini güçlendirir; “kesin oldu” demek için dinamik/host kanıtı gerekir. Diğer şıklar bu izlerle temelsizdir.

2)Import tablosunda yalnızca “genel amaçlı yükleme/çözümleme” işlevleri görülmesi (çok kısa import listesi) neyi düşündürmelidir?

A) Programın hiçbir yeteneği yoktur, güvenlidir.

B) Statik sinyaller sınırlı olabilir; gerçek kabiliyetler çalışma anında ortaya çıkabilir, doğrulama planı genişletilmelidir.

C) Dosya bozuktur ve çalışmayacaktır.

D) Dosya sadece Windows 7’de çalışır.

E) Dosya mutlaka bir arşivdir.

Doğru: B
Gerekçe: Kısa import listesi, statikte görünürlüğün sınırlı olabileceği senaryolarda görülür; rapor dili “sinyal sınırlı” + “doğrulama gerekli” olmalıdır.

3)Aşağıdaki bulgulardan hangisi statik analizde “doğrudan görülen iz” sınıfına en yakındır?

A) Import’ların “ağ kabiliyeti” çağrıştırması

B) Strings içinde açıkça görülen bir URL yolunun bulunması

C) Section yapısının “garip” durması

D) Dosya boyutunun beklenmedik büyük olması

E) Sürüm bilgisinin “meşru görünmesi”

Doğru: B
Gerekçe: URL’nin dosya içinde açıkça geçmesi doğrudan izdir. A/C/D/E daha çok yorum/hipotez üretir, tek başına kesinlik taşımaz.

4)Global\... biçiminde benzersiz bir isimle karşılaşmak savunma tarafında en çok neye yarar?

A) Hash üretmeye

B) Ağda aynı örneği avlamak için pratik bir IOC adayı üretmeye

C) Dosyanın dijital imzasını doğrulamaya

D) Diski şifrelemeyi tespit etmeye

E) Dosya türünü uzantıdan anlamaya

Doğru: B
Gerekçe: Bu tür ifadeler mutex izlerine benzer ve avcılık/tarama için değerlidir.

5)Bir dosyanın manifestinde yüksek yetki talebi işaretleri görülmesi hangi rapor cümlesini güçlendirir?

A) “Bu dosya kesin temizdir.”

B) “Sıradan kullanım senaryosunda gereksiz yetki talebi anomali sinyalidir; sistem değişikliği doğrulanmalıdır.”

C) “Bu dosya kesin PDF’dir.”

D) “Bu dosya sadece görsel içerir.”

E) “Bu dosya ağ trafiği üretmez.”

Doğru: B
Gerekçe: Yetki talebi, olası sistem müdahalesi hipotezini güçlendirir; doğrulama adımı gerektirir.

6)Resource bölümünde “ikincil bileşen taşıma ihtimali” denildiğinde en doğru savunma refleksi hangisidir?

A) Dosyayı görmezden gelmek

B) Dosya sistemi yazma aktiviteleri ve yeni oluşturulan bileşenleri doğrulama planına almak

C) Yalnızca dosya ikonuna bakmak

D) Sadece kullanıcı anlatımıyla yetinmek

E) Hiç rapor yazmamak

Doğru: B
Gerekçe: Resource anomalisinin değeri, doğrulamada “dosya üretimi/çıkarma” benzeri kanıtları izlemeyi gerektirir.

7)Kripto ile ilişkili import izleri görüldüğünde en temkinli ve doğru yaklaşım hangisidir?

A) “Kesin fidye yazılımı.”

B) “Veri şifreleme/özetleme ya da iletişimi koruma gibi amaçlar ihtimal dahilinde; davranış kanıtıyla doğrulanmalı.”

C) “İnternet bağlantısı yok demektir.”

D) “Dosya türü otomatik olarak dokümandır.”

E) “Bu izler rapora yazılmaz.”

Doğru: B
Gerekçe: Kripto import’ları niyeti düşündürür, kesin hüküm değildir; doğrulama gerekir.

8)PDB yolu veya derleme ortamı izi görüldüğünde rapora nasıl alınmalıdır?

A) Kesin saldırgan kimliği gibi yazılmalıdır.

B) “Geliştirme ortamına/amaç etiketine dair ipucu” olarak, güven düzeyi belirtilerek ve başka kanıtlarla desteklenerek yazılmalıdır.

C) Hiç yazılmamalıdır.

D) Dosyanın zararsızlığını ispatlar.

E) Dosyanın hash’ini değiştirir.

Doğru: B
Gerekçe: Bu izler değerli ama yanıltıcı olabilir; güven düzeyi ve korelasyon şarttır.

9)Registry ile ilişkili yol/anahtar izlerinin statikte görülmesi analisti en çok hangi doğrulama sorusuna taşır?

A) “Ekran parlaklığı değişti mi?”

B) “Kalıcılık veya sistem ayarı değişikliği gerçekleşti mi; hangi telemetri bunu gösterir?”

C) “Dosya bir ses dosyası mı?”

D) “İnternet hızını ölçtü mü?”

E) “Monitör çözünürlüğü değişti mi?”

Doğru: B
Gerekçe: Registry izleri, kalıcılık/ayar değişikliği hipotezini güçlendirir; doğrulama bu eksende yapılır.

10)Statik analizin dinamik analize göre en büyük avantajı hangisidir?

A) Gerçek zamanlı davranışı kesin kanıtlaması

B) Dosyayı çalıştırmadan analiz yapıldığı için analiz ortamına zarar verme riskini azaltması

C) Şifreli içerikleri otomatik çözmesi

D) Her zaman tüm IOC’leri eksiksiz çıkarması

E) Analistsiz kendi kendine doğru rapor yazması

Doğru: B
Gerekçe: Statik analizde kod yürütülmez; bu da ortam güvenliğini artırır. Diğer seçenekler statik analizin kapasitesini abartır.

Bu Modülde Kazanılan Yetkinlikler

Statik analizin, dosyayı çalıştırmadan kanıt üreten ama kesin hüküm yerine “hipotez + doğrulama” dili isteyen bir yaklaşım olduğunu
Strings analizinin ağ göstergeleri, dosya yolu/registry izleri, mutex adları ve hata mesajları üzerinden hızlı IOC adayları üretebildiğini
Import tablosunun yazılımın muhtemel kabiliyetlerine dair “yetenek haritası” sunduğunu; kısa/alışılmadık import profillerinin statik verimi sınırlayabileceğini
Resource ve manifest sinyallerinin ikincil bileşen taşıma ve yetki isteği gibi kritik risk işaretlerini görünür kıldığını
Derleme ipuçları, sürüm bilgileri ve PDB yollarının istihbarat değeri taşıdığını; fakat güven düzeyiyle raporlanması gerektiğini
Statik bulguyu IOC paketi + güven düzeyi + eksik kanıt listesi halinde sunmanın savunma aksiyonuna dönüşümü hızlandırdığını

MODÜL 4 — Dinamik Analizle Davranış Gözlemi ve Artefakt Toplama

Bu modül, Modül 3’te statik analizle kurduğunuz hipotezleri kontrollü bir ortamda dosyayı çalıştırarak doğrulamanızı sağlar. Hedef; “gerçekte ne yaptı, neyi denedi, nerede iz bıraktı?” sorularına ölçülebilir kanıtlarla yanıt üretmek ve bulguları savunma ekiplerinin hemen kullanabileceği hale getirmektir. Dinamik analiz, bir filmin fragmanını değil sahnelerini izlemek gibidir: yanlış sahneye bakarsanız önemli detayları kaçırırsınız; doğru izleme planı kurarsanız birkaç dakikada kritik kanıt toplarsınız.

Modül Teması

Proses Ağacı

Parent/child ilişkileri, başlatılan süreçler, command-line argümanları — niyetin canlı izi.

Dosya Sistemi

Düşürülen dosyalar, geçici dizinler, kopya/silme örüntüleri ve isimlendirme şablonları.

Registry & Kalıcılık

Run anahtarları, scheduled task, service kurulumu — sistemin yeniden açılışından sonra hayatta kalma stratejisi.

Bu Modülde Hedeflenen Kazanımlar

Dinamik analizin üretebildiği kanıt türlerini, risklerini ve sınırlarını doğru yönetebilmek.
Güvenli analiz ortamı mantığıyla (izolasyon, geri dönüş, kayıt) çalışmayı sürdürülebilir hale getirebilmek.
Süreç ağacı (process tree), dosya sistemi ve kayıt defteri (registry) değişikliklerinden davranış çıkarımı yapabilmek.
Ağ davranışını (DNS/HTTP/TLS gibi) “bağlandı mı, denedi mi?” ayrımıyla yorumlayıp IOC adaylarını güven düzeyiyle paketleyebilmek.
Dinamik bulguları zaman çizelgesi, kanıt–çıkarım ayrımı ve eksik kanıt listesiyle rapora dönüştürebilmek.

1. Dinamik analiz nedir, neyi çözer?

Dinamik analiz, şüpheli dosyanın çalışma anındaki davranışını gözlemleme yaklaşımıdır: hangi süreçleri başlattı, hangi dosyalara dokundu, hangi sistem ayarlarını değiştirdi, dışarıyla iletişim kurdu mu? Neden önemli? Çünkü statikte gördüğünüz bir URL “niyet” gösterebilir; dinamikte ise bunun gerçekten kullanılıp kullanılmadığını, hangi sırayla ne yapıldığını ve sistemde ne bıraktığını görürsünüz.

Dinamik analizden çıkan kanıtları üç katmanda düşünmek pratik olur:

Yürütme kanıtı: Dosya çalıştı mı, hangi süreçler oluştu, süreçler arası ilişki nasıl?

Host artefaktları: Dosya sistemi, registry, planlanmış görev/başlangıç davranışı gibi yerel izler var mı?

Ağ kanıtı: DNS sorgusu, bağlantı denemesi, veri alışverişi gibi dış iletişim izleri var mı?

Dikkat: Dinamik analiz “tek koşumda her şeyi görürüm” yaklaşımı değildir. Bazı davranışlar koşula bağlıdır (zaman, kullanıcı etkileşimi, yetki seviyesi, ağ erişimi). Bu yüzden rapor dili “gözlendi/gözlenmedi”yi net ayırmalı; gözlenmeyeni “yoktur” diye kesinlememelidir.

1.1. Güvenli çalışma mantığı: izolasyon, geri dönüş ve kayıt

Dinamik analizde hedef, örneği “yakmak” değil; kanıt toplamak ve bunu tekrarlanabilir kılmaktır. Bu yüzden üç temel disiplin önem kazanır:

İzolasyon: Analiz ortamı üretim ağından ayrıdır; amaç, olası yayılım ve veri sızıntısı riskini azaltmaktır.

Geri dönüş: Ortamı “temiz fotoğrafa” döndürebilmek; bir koşumda bozulan şeyi bir sonraki koşumda temizleyebilmek.

Kayıt: Gözlem, ekran görüntüsüyle değil; olay kayıtlarıyla (telemetri) desteklenmelidir.

İpucu: Analize başlamadan önce “baseline” yani başlangıç durumunu aklınızda netleştirin: süreç listesi, önemli klasörlerdeki dosya sayısı, ağ davranışının normal profili. Baseline’ı bilmeden değişikliği anlamak, karanlıkta anahtar aramak gibidir.

1.2. Dinamik analizde kanıt türleri ve “güven düzeyi” dili

Dinamik bulgu raporlanırken en güçlü yaklaşım şudur: “Ne oldu?” sorusunu kanıtla destekleyip yanına “ne anlama gelir?” yorumunu sınırlarıyla koymak.

“Bağlantı denedi” ile “başarılı bağlantı kurdu” aynı şey değildir.

“Dosya oluşturdu” ile “kalıcılık sağladı” aynı şey değildir.

“Registry’ye erişti” ile “kalıcılık anahtarını yazdı” aynı şey değildir.

Örnek: Bir koşumda örnek, 198.51.100.23 adresine bağlantı kurmayı deniyor; ancak iletişim tamamlanmıyor. Bu, “bağlandı” kanıtı değildir ama “hedef IOC adayı + ağ davranışı hipotezi” üretir. Savunma tarafında bu adres, avcılık/tarama listesine temkinli bir etiketle girer.

1.3. Anti-analysis, paketleme ve “neden göremiyorum?” anı

Bazı örnekler dinamik analizde beklediğiniz sinyalleri vermeyebilir: az log, kısa süreç, hızlı kapanma, sınırlı ağ davranışı. Bu durum bazen “davranış yok” değil, “davranış görünürlüğü sınırlı” anlamına gelir. Bu gibi vakalarda daha ileri doğrulama adımları gerekebilir; ancak bu modül kapsamında yalnızca çerçeveyi bilmek yeterlidir. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

2. Süreç davranışı: süreç ağacıyla hikâyeyi okumak

Süreç (process), çalışan program örnekleridir; süreç ağacı ise “kim kimi başlattı?” sorusunun görsel/hiyerarşik cevabıdır. Neden önemli? Çünkü birçok saldırı zinciri tek bir süreçten ibaret değildir: bir süreç başka bir aracı çağırır, o başka bir dosyayı üretir, sonra yeni süreçler oluşur. Süreç ağacı, olayın omurgasıdır.

Dinamikte süreç davranışına bakarken şu sorular ritim tutar:

İlk süreçten sonra yeni süreçler doğuyor mu?

Süreçler beklenen ebeveyn–çocuk ilişkisine uyuyor mu?

Süreç yaşam süresi kısa mı, tekrar eden bir döngü var mı?

Aynı anda birden fazla kopya çalışmayı engelleyen bir “tekillik” davranışı var mı?

2.1. Mutex ve tekillik davranışı (gözlem perspektifi)

Mutex’in varlığı statikte ipucu olabilir; dinamikte ise “aynı anda tek kopya” davranışıyla ilişkilendirilebilir. Bu tekillik, olay sırasında “niye ikinci kez çalışmadı?” sorusuna açıklama getirebilir.

Örnek: Bir koşumda süreç başlıyor; ikinci koşumda aynı sistemde beklenenden hızlı kapanıyor. Bu, “tekillik mekanizması devreye girmiş olabilir” şeklinde temkinli bir not üretir; aynı zamanda avcılık için mutex adı IOC adayına dönüşebilir.

Dikkat: Süreç ağacındaki anomaliyi “kötücül kesinliği” gibi yazmak cazip gelebilir. Oysa aynı anomali bazı meşru yazılımlarda da görülebilir (güncelleyici bileşenler, yardımcı servisler). Raporu güçlü yapan şey, anomaliyi bağlamla desteklemektir: ağ denemeleri + dosya yazma + beklenmedik başlangıç davranışı birlikteyse anlamı artar.

2.2. “İşlem yaptı mı, sadece denedi mi?” ayrımı

Dinamik analizde en çok hata yapılan yerlerden biri “erişti” ile “değiştirdi”yi karıştırmaktır. Süreç bir dosyayı açmaya çalışabilir ama yetkisi yetmez; registry’ye yazmayı dener ama başarısız olur. Bu fark, savunma aksiyonunu etkiler.

Örnek: Bir süreç, sistem dizininde bir dosya oluşturmayı deniyor ama izin hatası alıyor. Bu durumda rapor “hedeflenen davranış” ile “gerçekleşen davranış”ı ayırır; savunma ekibi için bu, “yetki seviyesi/çalıştırılma bağlamı” sorusunu gündeme getirir.

3. Host artefaktları: dosya sistemi ve registry izlerinden davranış çıkarmak

Host artefaktı, örneğin sistemde bıraktığı yerel izlerdir: yeni dosya/klasör, değişen ayar, eklenen başlangıç girdisi gibi. Neden önemli? Çünkü ağ davranışı olmasa bile host artefaktı çoğu zaman “etki”yi gösterir; olay kapsamını ölçmeye yarar.

3.1. Dosya sistemi: “nerede iz bırakmayı sever?”

Dinamikte dosya sistemi izleri üç amaçla yorumlanır:

Kalıcılık hazırlığı: Açılışta yeniden çalışmayı hedefleyen yazma davranışı

Yük taşıma: İkincil bileşen üretme/taşıma davranışı

Veri işleme: Geçici dosyalar, log benzeri çıktı üretimi, önbellek kullanımı

Örnek: Şüpheli süreç, kullanıcı profilinde beklenmedik bir klasör oluşturuyor ve içine çalıştırılabilir görünümlü bir dosya yazıyor. Bu, “ikincil bileşen üretimi ihtimali” olarak raporlanır; savunma tarafı aynı klasör adını ve dosya adını “IOC adayları” arasına alır ve benzer izler için tarama planlar.

3.2. Registry: ayar mı, kalıcılık mı?

Registry, Windows’ta yapılandırma verisinin tutulduğu kritik bir alandır. Neden önemli? Çünkü kalıcılık ve sistem davranışı değişiklikleri sıkça registry üzerinden yürür; ancak her registry erişimi “kötü” değildir.

Bu yüzden dinamik analizde registry için pratik yaklaşım:

Okuma mı yaptı, yazma mı yaptı?

Yazdıysa hangi anahtar sınıfına yakın (uygulama ayarı, başlangıç davranışı, sistem politikası gibi)?

Değişiklik, olay anlatısıyla tutarlı mı?

Örnek: Süreç, ...CurrentVersion\Run benzeri başlangıç davranışıyla ilişkilendirilen bir bölgeye yazma girişiminde bulunuyor. Bu, “kalıcılık ihtimali” olarak güçlü bir savunma sinyalidir; doğrulamada aynı sistemde yeniden başlatma sonrası süreç davranışı gözlenir.

İpucu: Host artefaktlarını rapora “liste” gibi dizmek yerine küçük bir zaman akışıyla verin: “T0 çalıştırıldı → T1 şu dosyayı oluşturdu → T2 şu ayara yazmayı denedi → T3 ağ denedi.” Olayı okuyan kişi, neden–sonuç ilişkisini daha hızlı kurar.

3.3. Yetki seviyesi ve davranışın şekli

Aynı örnek, farklı yetki seviyelerinde farklı iz bırakabilir: kimi şeyler sadece kullanıcı dizininde kalır; kimi hedefler için yükseltilmiş yetki gerekir. Bu modülde amaç “yetki yükseltme nasıl yapılır?” değildir; ama davranışın yetkiye bağlı olabileceğini bilmek, eksik kanıt yönetimini güçlendirir.

Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

4. Ağ davranışı: DNS’ten bağlantı denemesine, kanıtı doğru okumak

Ağ telemetrisi, örneğin dış dünya ile ilişkisinin kanıtını verir. Neden önemli? Çünkü birçok vakada ilk savunma aksiyonu “engelleme + avcılık + kapsam taraması”dır; bunlar ağ göstergeleriyle hızlanır.

Ağ davranışını okurken üç soruyu ayırmak gerekir:

Çözümleme: DNS sorgusu yaptı mı?

Bağlantı: Bir adrese/porta bağlantı denedi mi? Başarılı mı?

İçerik: HTTP istekleri, TLS oturumu, indirilen/yüklenen veri sinyali var mı?

Örnek: Örnek, example.net için DNS sorgusu yapıyor ama ardından bağlantı kurmuyor. Bu, “ağ niyeti” göstergesidir; domain IOC adayına girer, ancak “aktif iletişim” iddiası kurulmaz.

Dikkat: Dinamik analizde gördüğünüz her ağ adresi “komuta kontrol” demek değildir. Bazı yazılımlar güncelleme kontrolü, sertifika doğrulama veya kütüphane çağrıları nedeniyle normal ağ trafiği üretebilir. Burada değerli olan, ağ davranışını süreç bağlamına bağlamaktır: hangi süreç yaptı, hangi anda yaptı, host artefaktıyla birlikte mi geldi?

İpucu: Ağ IOC’lerini raporlarken tek satırda boğmayın. “Görülen DNS” ve “başarılı bağlantı”yı ayrı yazın; her birinin güven düzeyini açık tutun. Bu, yanlış bloklama riskini azaltır, avcılık sorgularını netleştirir.

5. Dinamik bulguyu rapora dönüştürme: savunma için paket üretmek

Dinamik analiz “gözlem” ile başlar, “savunma çıktısı” ile biter. Bu modülde hedeflenen paket şunları içerir:

— Olay özeti: Ne çalıştırıldı, ne gözlendi, neden önemli?
— Kanıt tablosu/akışı: Zaman çizelgesi veya kısa maddelerle en kritik adımlar
— IOC adayları listesi:

1. Yüksek güven: koşumda gerçekten görülen/gerçekleşen göstergeler (ör. oluşturulan dosya adı, başarılı bağlantı hedefi)

2. Orta güven: niyet/deneme seviyesindeki göstergeler (ör. bağlantı denemesi, DNS sorgusu, statikte görülen ama dinamıkte doğrulanmayan iz)

— Eksik kanıt listesi:

“Şu iddiayı güçlendirmek için şu kanıt yok” diliyle

— Savunma aksiyonları:

Kapsam taraması önerisi, bloklama önerisi (güven düzeyiyle), izleme önerisi

Örnek: Dinamik koşumda kullanıcı dizininde yeni bir çalıştırılabilir dosya oluşuyor, aynı anda 198.51.100.77 adresine bağlantı denemeleri gözleniyor. Rapor bunu “host artefaktı + ağ davranışı korelasyonu” olarak anlatır; IOC paketi hem dosya adını/konumunu hem de ağ hedefini içerir, ayrıca “yeniden başlatma sonrası kalıcılık izleri doğrulanmadı” gibi eksik kanıtı açıkça yazar.

Terimler Sözlüğü

Terim	Açıklama
Dynamic analysis	Dinamik analiz; dosyayı çalıştırarak çalışma anı davranışlarını gözlemleme
Sandbox	İzole analiz ortamı; davranışı güvenli biçimde gözlemlemeye yarayan düzenek
Isolation	İzolasyon; analiz ortamını üretim sistemlerinden ve ağlardan ayırma yaklaşımı
Snapshot	Anlık görüntü; ortamı belirli bir ana geri döndürebilmek için alınan kayıt
Telemetry	Telemetri; süreç, dosya, registry ve ağ olaylarına dair ölçümlü kayıtlar
Process tree	Süreç ağacı; ebeveyn–çocuk süreç ilişkilerinin görünümü
Artifact	Artefakt; sistemde bırakılan iz (dosya, ayar, ağ kaydı vb.)
Persistence	Kalıcılık; yeniden başlatma/oturum sonrası tekrar çalışmayı hedefleyen davranış
Registry	Kayıt defteri; Windows yapılandırma verisinin saklandığı sistem bileşeni
Baseline	Başlangıç profili; “normal” durum referansı
Correlation	Korelasyon; farklı kanıtları (host+ağ gibi) aynı olay akışında ilişkilendirme
DNS	Alan adı çözümleme; domain → IP çevirimiyle ilgili ağ davranışı
Confidence	Güven düzeyi; bulgunun kanıt gücü ve kesinlik seviyesi

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)Dinamik analiz raporunda aşağıdaki ifadelerden hangisi kanıt–çıkarım dengesini en iyi kurar?

A) Dosya içinde IP vardı, kesin bağlandı.

B) Dinamik analiz güvenilmez, rapora gerek yok.

C) Koşumda DNS sorgusu görüldü; bağlantının tamamlandığına dair kanıt yok. IOC adayı olarak kaydedildi ve ağ telemetrisiyle korelasyon önerildi.

D) Sadece dosya adını yazmak yeterli.

E) Kodu çözmeden hiçbir şey söylenemez.

Doğru: C
Gerekçe: C, gözlemi (DNS) ve sınırı (bağlantı kanıtı yok) ayırır, savunma aksiyonuna dönüştürür. A aşırı kesin; B/D/E pratik değildir.

2)Süreç ağacı (process tree) dinamik analizde en çok hangi soruyu yanıtlar?

A) Dosyanın hash’i nedir?

B) Hangi süreç kimi başlattı, olay akışının omurgası nasıl?

C) Dosyanın uzantısı doğru mu?

D) Dosyanın entropisi kaç?

E) Dosya statikte hangi string’leri içeriyor?

Doğru: B
Gerekçe: Süreç ağacı ebeveyn–çocuk ilişkisini gösterir. Diğerleri dinamik süreç ağacı sorusu değildir.

3)Bir koşumda dosya, bir adrese bağlantı deniyor ancak başarısız oluyor. En doğru savunma yorumu hangisidir?

A) Kesin veri sızdırdı.

B) Ağ niyeti var; hedef IOC adayıdır, ama ‘başarılı iletişim’ iddiası kurulmaz.

C) Ağ davranışı yok sayılır.

D) Bu kesin meşru yazılımdır.

E) Bu tek başına kalıcılığı kanıtlar.

Doğru: B
Gerekçe: Deneme ile başarı farklıdır; B temkinli ve eyleme dönüktür. A/E aşırı; C bilgi kaybı; D temelsiz.

4)Host artefaktları içinde “kalıcılık” hipotezini en çok güçlendiren kanıt türü hangisine daha yakındır?

A) Dosyanın ikonunun değişmesi

B) Başlangıç davranışıyla ilişkili bir ayara yazma/ekleme kanıtı

C) Sadece bir DNS sorgusu görülmesi

D) Dosya boyutunun büyük olması

E) Sadece kullanıcı şikâyeti

Doğru: B
Gerekçe: Kalıcılık genellikle yeniden başlatma/oturum sonrası çalışma düzenine bağlanır; başlangıç davranışıyla ilişkili yazma kanıtı anlamlıdır. Diğerleri dolaylı veya yetersizdir.

5)Dinamik analizde “baseline” kavramı neden kritik kabul edilir?

A) Çünkü hash üretir

B) Çünkü normal profili bilmeden değişikliği güvenle yorumlamak zordur

C) Çünkü dosyanın uzantısını doğrular

D) Çünkü ağ paketlerini şifreler

E) Çünkü raporu otomatik yazar

Doğru: B
Gerekçe: Baseline, “normal”i referans alarak anomaliyi anlamayı sağlar. A/C/D/E yanlış veya alakasız.

6)Aşağıdaki durumlardan hangisi “davranış yok” diye kesin hüküm vermeyi en riskli hale getirir?

A) Tek koşum yapılması ve beklenen logların görülmemesi

B) Hash’in hesaplanması

C) Dosya adının not alınması

D) Baseline çıkarılması

E) IOC’lerin güven düzeyiyle raporlanması

Doğru: A
Gerekçe: Tek koşumda görünmeyen davranış koşula bağlı olabilir; “yoktur” demek hatalı olur. Diğerleri riskli kesinlik üretmez.

7)Dinamik analizde “erişti” ile “değiştirdi” ayrımını yapmak savunma için neden değerlidir?

A) Çünkü raporu süsler

B) Çünkü yetki/başarı durumu farklı savunma aksiyonları doğurur

C) Çünkü dosya türünü belirler

D) Çünkü statik analizi gereksiz yapar

E) Çünkü entropy’yi hesaplar

Doğru: B
Gerekçe: Başarısız yazma denemesi ile gerçek değişiklik aynı değildir; aksiyon ve risk farklıdır. Diğerleri alakasız.

8)Bir örnek koşumda example.net için DNS sorgusu yapıyor, fakat bağlantı kurmuyor. En doğru IOC raporlama biçimi hangisidir?

A) Komuta kontrol kesin.

B) DNS gözlendi; bağlantı kanıtı yok. Domain, orta güven IOC adayıdır; korelasyon önerilir.

C) IOC yazılmaz.

D) Bu, dosyanın temiz olduğunu kanıtlar.

E) Bu, kalıcılık kanıtıdır.

Doğru: B
Gerekçe: DNS gözlemi niyet göstergesidir; güven düzeyiyle raporlanır. A/D/E aşırı; C bilgi kaybı.

9)Dinamik analiz bulgularını savunma çıktısına çevirmede en güçlü yapı hangisidir?

A) Sadece ekran görüntüleri

B) Tek cümle “zararlı” etiketi

C) Olay özeti + zaman akışı + IOC adayları (güven düzeyiyle) + eksik kanıt listesi + aksiyon önerisi

D) Sadece dosya adı ve uzantısı

E) Sadece kullanıcı anlatımı

Doğru: C
Gerekçe: Savunma ekipleri için eyleme dönük paket C’dir. Diğerleri eksik ve zayıftır.

10)Bir örnek dinamik analizde beklenenden az sinyal veriyorsa, en doğru yaklaşım hangisine yakındır?

A) “Kesin zararsız” demek

B) “Kesin zararlı” demek

C) “Görünürlük sınırlı olabilir; rapora ‘sinyal sınırlı’ notu düşüp eksik kanıt listesiyle doğrulama rotası önermek”

D) Rapor yazmamak

E) Kullanıcıyı suçlamak

Doğru: C
Gerekçe: Temkinli raporlama + eksik kanıt yönetimi doğru reflextir. A/B aşırı kesin; D/E profesyonel değildir.

Bu Modülde Kazanılan Yetkinlikler

Dinamik analizin, dosyayı çalıştırarak süreç–host–ağ kanıtı ürettiğini ve bu kanıtların güven düzeyiyle raporlanması gerektiğini
Süreç ağacının olay akışının omurgası olduğunu; “kim kimi başlattı?” sorusunu netleştirdiğini
Host artefaktlarının (dosya sistemi ve registry) etkiyi ve kalıcılık ihtimalini anlamada kritik rol oynadığını
Ağ davranışında DNS/bağlantı denemesi/başarılı iletişim ayrımının savunma kararlarını doğrudan etkilediğini
Dinamik bulguların savunmaya dönüşmesi için zaman çizelgesi, IOC paketi, eksik kanıt listesi ve aksiyon önerisinin birlikte gerektiğini

MODÜL 5 — Modül 5: Bulguları Savunma Çıktısına Dönüştürme (Sistem Davranışı, Zaman Çizelgesi, IOC Paketi ve Kapsam Taraması)

Statik analizde dosyanın “neye benziyor olabileceğini” gördükten, dinamikte de laboratuvar ortamında “gerçekte ne yaptığını” izledikten sonra sıradaki kritik iş, bu bulguları sahada işe yarar hale getirmektir. Bu modül; süreç ağacı, dosya sistemi, kayıt defteri ve ağ telemetrisi gibi kanıtları bir araya getirip, SOC/IR ekiplerinin hemen kullanabileceği IOC paketi, kapsam taraması planı ve yayınlanabilir rapor üretmeyi hedefler. Kısacası “ne gördük?” sorusunu “ne yapacağız?” sorusuna bağlayan köprüyü kurar.

Modül Teması

Timeline

Olayların saniye/dakika hassasiyetinde sıralanması; sebep–sonuç akışını okunur kılar.

IOC Paketi

Hash + ağ + host göstergeleri birlikte — tek bir işaret değil, aranabilir bütün.

Kapsam Taraması

SOC için sorgulanabilir: aynı izler ortamın başka noktalarında var mı?

Bu Modülde Hedeflenen Kazanımlar

Statik/dinamik bulguları kanıt–çıkarım ayrımı ve güven düzeyi ile doğru yazabilmek.
Süreç, dosya sistemi, registry, servis/görev planlayıcı ve ağ sinyallerini davranış hikâyesine dönüştürebilmek.
IOC adaylarını normalleştirip (format + bağlam) taranabilir bir paket haline getirebilmek.
Host ve ağ tarafında kapsam taraması planlayıp yanlış pozitif riskini yönetebilmek.
Gözlenen davranışlardan TTP çıkarımı yapıp savunma mekanizmalarına (EDR/SIEM) aktarılabilecek kanıt setini seçebilmek.

1. “Bulgudan karara” köprüsü: Kanıt, yorum ve çıktı türleri

Analizde ürettiğiniz her şey aynı ağırlıkta değildir. Bir kısmı doğrudan kanıttır, bir kısmı ise kanıttan türetilmiş yorumdur. Savunma tarafında yanlış bloklama, yanlış önceliklendirme ve “boş yere panik” çoğu zaman bu ikisinin karışmasından çıkar.

Dinamik ve statik analiz çıktıları pratikte şu başlıklarda toplanır:

Göstergeler (IOC): Hash, alan adı, IP, URL yolu, dosya yolu, registry anahtarı gibi aranabilir değerler.

Artefaktlar: Sistem üzerinde oluşan izler; yeni dosya, değişen ayar, süreç ağacı ilişkileri, log kayıtları.

Davranış örüntüleri (TTP): “Ne yapmaya çalıştı?” sorusuna davranış düzeyinde cevap veren kalıplar (kalıcılık denemesi, şüpheli çocuk süreç üretimi, ağ denemeleri gibi).

Etki: İş kesintisi, şifreleme belirtisi, veri erişimi sinyali gibi sonuçlar (bu modülde amaç, etkiyi abartmadan kanıta bağlayarak yazmaktır).

Dikkat: Bir IOC’nin dosya içinde “geçmesi” ile koşumda “kullanılması” aynı şey değildir. Rapor dilinde “görüldü” (statik ipucu) ve “gözlendi” (dinamik kanıt) ayrımı net olmazsa ekip yanlış karar alabilir.

1.1. Kanıt–çıkarım ayrımı ve güven düzeyi dili

Güven düzeyi, “kesinlik iddiası” üretmek için değil, hangi aksiyonun makul olduğunu tarif etmek için kullanılır. Kullanışlı bir çerçeve:

Yüksek güven: Koşumda doğrudan gözlenen eylem/iz (ör. belirli klasörde belirli adla dosya oluştu; DNS sorgusu belirli süreçten çıktı).

Orta güven: Niyet/deneme/başarısız girişim gibi tamamlanmamış sinyal (ör.bağlantı denendi ama kurulmadı).

Düşük güven: Tek başına yorum riski yüksek bağlam sinyali (ör. dosya içinde tek bir kelime/etiket).

Örnek: Koşumda example.net için DNS sorgusu görülüyor, fakat bağlantı kurulmadığına dair net telemetri var. Bu durumda “aktif iletişim” iddiası kurulmaz; domain orta güven IOC adayı olarak paketlenir ve DNS/proxy loglarıyla korelasyon önerilir.

1.2. IOC normalizasyonu: Taranabilir paket nasıl görünür?

Kapsam taramasında en çok zaman kaybettiren şey, aynı değerin farklı biçimlerde rapora yazılmasıdır. Normalizasyon, IOC’yi tekilleştirip bağlamıyla birlikte standartlaştırmaktır.

Bir IOC satırının savunma ekibine “hazır” gelmesi için genellikle şu alanlar yeterlidir:

Değer (ör. domain/IP/dosya yolu)

Kaynak (statik mi, dinamik mi; hangi süreç/artefakt üzerinden)

Zaman (varsa zaman damgası/koşum zamanı)

Güven düzeyi

Kısa not (neden önemli, hangi davranışla ilişkili olabilir)

İpucu: IOC’leri tek bir uzun liste halinde vermek yerine “Doğrulanmış/Gözlenmiş” ve “Aday/Niyet” diye iki blok halinde ayırmak, avcılık sorgularını ve bloklama kararlarını netleştirir.

2. Süreç ağaçları: Olayın omurgasını okumak

Zararlı yazılım çoğu zaman tek süreç olarak kalmaz; meşru araçları kullanarak yeni süreçler başlatır. Bu yüzden süreç ağacı, olayın “kim kimi tetikledi?” sorusuna verdiği cevapla savunmanın omurgasını oluşturur.

2.1. Ebeveyn–çocuk ilişkisi ve anomali mantığı

Normal sistemlerde hangi sürecin hangisini başlatacağı büyük ölçüde öngörülebilirdir. Bir metin düzenleyicinin arka planda komut satırını tetiklemesi veya bir ofis uygulamasının beklenmedik şekilde betik çalıştırması, dikkat edilmesi gereken bir anomalidir. Saldırganlar bazen sistemin güvenilir süreçlerinin arkasına saklanarak görünürlüğü azaltmaya çalışır; bu yaklaşım pratikte “meşru araçları kötüye kullanma” olarak da karşınıza çıkar.

Örnek: Analiz sırasında invoice.exe isimli çalıştırılabilir dosyanın kısa süre sonra powershell.exe başlattığı gözleniyor. Bu, tek başına “kesin zararlı” hükmü değildir; fakat süreç ilişkisi, aynı anda dosya yazma veya ağ denemeleriyle birleşiyorsa güçlü bir savunma sinyaline dönüşür.

2.2. Maskeleme ve “yer/kimlik tutarsızlığı”

Süreç adı meşru görünebilir; ancak çalıştığı dizin veya ebeveyn ilişkisi tutarsızsa risk artar. Meşru sistem süreçlerini taklit eden benzer isimler (harf/karakter oyunları) veya beklenmedik konumdan çalışan kopyalar, analistin odaklanması gereken işaretlerdir.

Dikka: Süreç ağacındaki anomaliyi tek başına “kötücül kesinliği” gibi yazmak cazip gelebilir. Güncelleyiciler, yardımcı servisler ve kurumsal yönetim araçları da sıra dışı süreç ilişkileri üretebilir. Raporu güçlü yapan şey, anomalinin bağlamla desteklenmesidir (aynı anda host artefaktı + ağ denemesi + zamanlama uyumu gibi).

2.3. Enjeksiyon/gizlenme sinyalleri

Bazen bir süreç çok kısa süre yaşar veya meşru bir süreçte olağandışı hareketlilik şüphesi doğar. Bu tür sinyaller “görünürlük sınırlı olabilir” notuyla raporlanır ve doğrulama ihtiyacını doğurur. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

3. Host artefaktları: Dosya sistemi, registry, servis ve görev planlayıcı

Zararlı yazılım işletim sistemiyle kurduğu her etkileşimde iz bırakır. Bu izler, kapsam taraması ve temizleme önceliği için altın değerindedir.

3.1. Dosya sistemi hareketleri: “Nereye yazıyor, ne bırakıyor?”

Dinamik analizde yazılımın nerelere dosya yazdığı, ne sildiği veya neyi dönüştürdüğü izlenir. Geçici klasörler, kullanıcı profili altındaki uygulama verileri veya sistem dizinleri gibi bölgeler sıkça gözlemlenir.

Örnek: >Koşumda bir .exe dosyasının kullanıcı profilinde güncelleme benzeri bir klasör yapısı altına rastgele isimli bir .dll bıraktığı görülüyor. Bu, “ikincil bileşen” ihtimalini güçlendirir ve IOC paketine yeni dosya yolu/deseni olarak girer.

3.2. Registry manipülasyonu: Ayar mı, kalıcılık mı, savunmayı kör etme mi?

Registry, Windows’ta ayarların merkezi gibidir. Zararlılar burayı bazen ayar saklamak, bazen kalıcılık sağlamak, bazen de savunma mekanizmalarını zayıflatmayı denemek için yoklar. Burada kritik ayrım şudur: okuma mı var, yazma mı var; yazma varsa hangi sınıfa yakın?

Örnek: Kullanıcı oturumu açıldığında otomatik çalışmayı tetikleyen “Run” anahtarlarına yazma girişimi görülmesi, kalıcılık hipotezini güçlendirir ve kapsam taraması için net bir iz üretir.

3.3. Servis ve zamanlanmış görevler: Sessiz kalıcılık alanı

Sürekli arka planda çalışmak isteyen yazılımlar kendini servis olarak kaydedebilir veya zamanlanmış görev oluşturabilir. Servis adlarının meşru isimlere benzetilmesi, analistin gözünü yanıltmaya yönelik bir taktik olabilir.

İpucu: Kalıcılık izlerini hızlı taramak için kullanılan görünürlük araçları, “imzasız”, “dosyası bulunamayan” ya da beklenmedik konumdan çalışan girişleri daha hızlı fark etmenize yardımcı olur. Önemli olan araç değil; şüpheli girişin bağlamını (hangi süreç oluşturdu, ne zaman oluşturdu, ağ denemesiyle eşleşiyor mu) kurmaktır.

3.4. WMI olay aboneliği gibi daha ileri kalıcılık yöntemleri

Bazı yöntemler belirli olaylar gerçekleştiğinde kodu tetikleyebilir ve ilk bakışta daha “gizli” görünür. Bu modülde amaç bu yöntemleri uygulamalı çözmek değil; böyle bir iz görüldüğünde “görünürlük ve doğrulama ihtiyacı artar” refleksini kazanmaktır. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

4. Davranış zaman çizelgesi: Dağınık bulguyu hikâyeye dönüştürmek

Tek tek bulgular değerli olsa da, saldırının seyrini en iyi anlatan yapı kronolojik akıştır. Zaman çizelgesi; “önce ne oldu, sonra ne tetiklendi, hangi iz neyin sonucuydu?” sorularını cevaplar.

Örnek:
— 09:00:01 — malware.exe çalıştırıldı
— 09:00:05 — Otomatik çalışmaya yönelik bir kayıt eklendi
— 09:00:10 — 192.0.2.50 adresi için DNS isteği gözlendi
— 09:00:20 — Kullanıcı belgelerinde uzantı değişimleri başladı (.crypt benzeri bir desen)

Dikkat: Zaman çizelgesinde “gözlenen” ile “varsayılan”ı birbirine karıştırmayın. “Şifreleme başladı” gibi yüksek iddialar, mutlaka kanıtla bağlanmalı; yoksa “şüpheli dosya işlemleri” gibi daha temkinli, doğrulanabilir bir dile dönülmelidir.

5. Kapsam taraması: “Sadece bu makine mi, yoksa yayıldı mı?”

Kapsam taraması, olayın yayılımını hızlıca anlamanın ana yoludur. Burada amaç, her şeyi engellemek değil; doğru yerde doğru izi aramaktır.

5.1. Host tarafı tarama mantığı

Üç eksen iş görür:

Süreç izi: Beklenmedik ebeveyn–çocuk ilişkileri, sıra dışı süreç doğumları

Dosya izi: Beklenmedik klasör/desen, yeni oluşan ikincil bileşenler

Registry/kalıcılık izi: Run anahtarları, servis/görev girişleri, şüpheli ayar yazımları

Örnek: Dinamikte kullanıcı profilinde beklenmedik bir klasör ve içine yazılmış çalıştırılabilir görünümlü dosya görülüyorsa, kapsam taramasında aynı desenin başka uçlarda tekrarlanıp tekrarlanmadığı aranır.

5.2. Ağ tarafı tarama mantığı: DNS–bağlantı–içerik

Ağ bulgularını üç soruya ayırmak kafa karışıklığını azaltır:

Domain çözümleme var mı (DNS)?

Bağlantı girişimi var mı; kuruldu mu?

Veri alışverişi sinyali var mı?

Örnek: 203.0.113.10 hedefine bağlantı girişimi görülüyor ama oturum kurulamıyorsa, bu gösterge orta güven kategorisinde tutulur; aynı anda host artefaktlarıyla korelasyon aranır.

İpucu: Laboratuvar ortamında ağ bağlantısının kontrollü/izole tutulması, dış dünyaya zarar vermeden “hangi hedeflere gitmeye çalıştı?” sinyalini görmeyi sağlar. Buradaki amaç gerçek saldırıyı yürütmek değil; niyeti ve denemeyi güvenle gözlemlemektir.

5.3. Yanlış pozitif yönetimi: Ölçülü aksiyon

Tek sinyalle kesin hüküm vermek yerine, korelasyon aramak ve güven düzeyine göre aksiyon önermek daha sağlıklıdır.

İpucu: Özellikle orta/düşük güven IOC’lerde “önce avcılık, sonra bloklama” sıralaması, operasyonel sürtünmeyi ve yanlış bloklamayı azaltır.

6. Raporlama: Aynı bulguyu üç farklı kitleye anlatmak

İyi bir rapor, aynı kanıtı farklı derinlikte sunabilir:

SOC/Analist: Telemetri, zaman akışı, IOC listeleri, korelasyon

IR/Operasyon: Kapsam taraması önerisi, izolasyon/temizleme önceliği, eksik kanıtlar

Yönetim: Abartısız risk/etki özeti + alınan/önerilen aksiyonlar

6.1. Delil bütünlüğü ve tutarlılık

Ekip içinde “aynı örnek mi konuşuyoruz?” sorusunu bitiren basit ama kritik alışkanlık, örnek ve kritik artefaktların kimliğini tutarlı tanımlamaktır (hash bilgisi ve nereden alındığı gibi).

6.2. EDR/SIEM’e aktarılabilir kanıt seçimi

Amaç, “her şeyi kural yapalım” değil; gürültü üretmeyen, bağlamı güçlü sinyalleri seçmektir: şüpheli ebeveyn–çocuk ilişkisi + dosya yazma deseni + ağ denemesi gibi birleşimler, tekil sinyallerden daha değerlidir.

7. Eksik kanıt listesi: Raporu güçlendiren dürüst bölüm

Her analiz bir noktada “bunu kesinleştirmek için şunu görmem gerek” noktasına gelir. Bu bir zayıflık değil, doğru yazıldığında profesyonel bir güçtür.

Eksik kanıt listesi için işe yarayan sorular:

Davranış gerçekten gerçekleşti mi, yoksa sadece denendi mi?

Yetki seviyesi davranışı değiştirmiş olabilir mi?

Tek koşum yeterli mi, yoksa tetikleyici koşullar var mı?

DNS var ama oturum yoksa arada engelleme/filtre olabilir mi?

Bazı durumlarda daha ileri doğrulama gerekebilir (ör. görünürlüğü artıran yöntemler veya daha derin tersine mühendislik). Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

Terimler Sözlüğü

Terim	Açıklama
IOC (Indicator of Compromise)	İhlal göstergesi; aranabilir teknik gösterge (hash, domain, IP, dosya yolu vb.)
Artifact	Artefakt/iz; bir işlemin sistemde bıraktığı dijital kalıntı
TTP	Taktik/Teknik/Prosedür; davranış örüntülerini anlatan çerçeve
Confidence	Güven düzeyi; bulgunun kanıt gücü ve kesinlik seviyesi
Scope	Kapsam; olayın kaç sistem/kullanıcı/ağ segmentine yayıldığı
Correlation	Korelasyon; farklı kanıtları aynı olay akışında ilişkilendirme
False Positive	Yanlış pozitif; meşru olayı yanlışlıkla tehdit gibi işaretleme
Containment	Çevreleme/izolasyon; yayılımı durdurmaya dönük aksiyon
Triage	Ön değerlendirme; hızlı sınıflandırma ve önceliklendirme
Normalization	Normalizasyon; IOC format ve bağlamını standartlaştırma
Sandbox	Kum havuzu; zararlı kodun güvenle çalıştırıldığı izole ortam
Snapshot	Anlık görüntü; laboratuvar ortamını geri döndürmeye yarayan kayıt
Persistence	Kalıcılık; yeniden başlatma/oturum sonrası otomatik çalışabilme
Child Process	Çocuk süreç; bir program tarafından başlatılan alt süreç
Registry Run Key	Otomatik çalışma kayıtlarının tutulduğu registry alanı
Dropper	Bırakıcı; sisteme başka bir zararlı bileşeni bırakan aracı yazılım
Timeline	Zaman çizelgesi; olayların kronolojik akışı

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)Aşağıdaki cümlelerden hangisi kanıt–çıkarım ayrımını en iyi kurar?

A) Dosyada example.net vardı, kesin veri aktardı.

B)DNS sorgusu görüldü; bağlantının kurulduğuna dair kanıt yok. Domain orta güven IOC adayıdır; korelasyon önerilir.

C)Bir şey görmedik, dosya temiz.

D)Dinamik analiz tek koşumda her şeyi kanıtlar.

E)Sadece dosya adını yazmak yeterlidir.

Doğru: B
Gerekçe:Gözlemi ve sınırı ayırır, savunma aksiyonuna bağlar. A aşırı kesin; C/D/E kanıt yönetimini zayıflatır.

2)IOC normalizasyonunun en kritik faydası nedir?

A) IOC’leri daha ürkütücü göstermek

B) Aynı göstergenin farklı yazımlarla taramada kaçmasını önlemek ve bağlamı korumak

C) Hash üretmeden rapor yazmak

D) Dinamik analizi gereksiz kılmak

E) Savunmayı otomatik devre dışı bırakmak

Doğru: B
Gerekçe: Taranabilirliği ve ekip içi tutarlılığı artırır. Diğerleri amaç dışıdır.

3)Dinamik analizde bir ofis uygulamasının beklenmedik şekilde komut satırı/betik süreci üretmesi en doğru nasıl raporlanır?

A) Güncelleme yapmıştır

B) Meşru ebeveyn sürecin şüpheli çocuk süreç başlatması anomalisidir; bağlam telemetrisiyle desteklenmelidir

C) PowerShell güvenlidir, rapora gerek yok

D) Bilgisayar hızlı çalışıyor

E) Rapor yazmadan dosyayı silmek yeterli

Doğru: B
Gerekçe: Parent–child anomalisi savunma sinyali olabilir; bağlamla güçlendirilir. A/C/E temelsiz; D alakasız.

4)Kalıcılık hipotezini en çok güçlendiren host bulgusu hangisine yakındır?

A) Dosyanın ikonunun değişmesi

B) Otomatik çalışmayı tetikleyen alanlara yazma girişimi veya kaydı

C) Tek bir DNS sorgusu

D) Dosya boyutunun büyük olması

E) Kullanıcının “yavaşladı” demesi

Doğru: B
Gerekçe: Kalıcılık, yeniden başlatma/oturum sonrası çalışmayı hedefler; otomatik tetikleyiciler kritik kanıttır.

5)“DNS var, bağlantı yok” bulgusu en doğru nasıl yorumlanır?

A) Kesin C2 iletişimi oldu

B) Ağ niyeti sinyali var; iletişim kanıtı yok. Orta güven IOC adayıdır, korelasyon aranır.

C) Hiçbir şey ifade etmez

D) Bu kalıcılığı kanıtlar

E) Bu dosyanın temiz olduğunu kanıtlar

Doğru: B
Gerekçe: DNS niyet gösterebilir; oturum kanıtı olmadan kesin iletişim iddiası kurulmaz

6)Aşağıdakilerden hangisi “dinamik analiz” çıktısına örnektir?

A) Dosya 32-bit mimariye sahiptir.

B) Dosya içinde ‘password’ kelimesi geçiyor.

C) Çalışma sırasında belirli bir klasörde yeni bir log dosyası oluştu.

D) Import tablosunda 5 fonksiyon var.

E) Dosyanın hash değeri hesaplandı.

Doğru: C
Gerekçe: Çalışma anında oluşan dosya/iz dinamik kanıttır. A/B/D/E statik veya tanımlayıcıdır.

7)Servis veya zamanlanmış görev üzerinden kalıcılık şüphesi varsa en etkili savunma refleksi hangisidir?

A) Bilgisayarı kapatmak

B) Tetikleyici mekanizmayı ve ilişkilendiği dosyayı birlikte doğrulayıp temizleme planına almak

C) Masaüstü arka planını değiştirmek

D) Tarayıcıyı sıfırlamak

E) Yeni kullanıcı hesabı açmak

Doğru: B
Gerekçe: Sadece dosyayı silmek tetikleyiciyi bırakabilir; mekanizma + dosya birlikte ele alınmalıdır.

8)Başka bir sürecin belleğinde alan açma gibi API çağrıları görülmesi en makul şekilde nasıl ele alınır?

A) Kesin oyun performans optimizasyonu

B) Muhtemel kod enjeksiyonu ön belirtisi olabilir; doğrulama ihtiyacı artar

C) Dosya kesin temiz

D) Hash değişmiştir, o yüzden önemsiz

E) Bu, internet hızını gösterir

Doğru: B
Gerekçe: Tek başına kesin hüküm değildir ama güçlü bir şüphe sinyalidir; doğrulama gerektirir.

9)Yanlış pozitif riskini en çok düşüren yaklaşım hangisidir?

A) Tüm domain’leri koşulsuz engellemek

B) Tek sinyalle “kesin zararlı” demek

C) Güven düzeyiyle raporlamak ve korelasyon aramak

D) Rapor yazmamak

E) Sadece ekran görüntüsü almak

Doğru: C
Gerekçe: Ölçülü aksiyon, güven düzeyi ve korelasyonla mümkün olur

10)Zaman çizelgesi oluşturmanın temel faydası nedir?

A) Hash üretmek

B) Olayı kronolojik akışla okunur yapıp hangi telemetrinin kritik olduğunu göstermek

C) Dosyayı otomatik temizlemek

D) Ağ trafiğini şifrelemek

E) Kullanıcıyı suçlamak

Doğru: B
Gerekçe: Timeline, saldırının “hikâyesini” kanıtlarla anlatır ve savunma aramalarını yönlendirir.

Bu Modülde Kazanılan Yetkinlikler

Kanıt ile yorumu ayırarak, bulguları güven düzeyiyle doğru dilde yazmayı
Süreç ağacı, dosya sistemi, registry ve servis/görev izlerini bir araya getirip davranış hikâyesi kurmayı
IOC’leri bağlamıyla normalleştirip taranabilir bir pakete dönüştürmeyi
Host ve ağ tarafında kapsam taramasını planlayıp yanlış pozitif riskini korelasyonla yönetmeyi
Zaman çizelgesi, delil bütünlüğü ve eksik kanıt listesiyle raporu eyleme dönük hale getirmeyi

MODÜL 6 — Dinamik Analiz: Ağ Davranışı

Bir zararlı yazılım, sistemde ne kadar iz bırakmadan çalışsa da çoğu senaryoda “dış dünya” ile bir şekilde temas eder: komut almak, durum bildirmek, ek bileşen indirmek ya da veri sızdırmak için. Bu modül, izole analiz ortamında gözlenen DNS ve HTTP(S) örüntülerini doğru yorumlamayı; beaconing ve staging gibi davranışların ne anlama geldiğini ayırt etmeyi; şifreli trafik gerçeğiyle proxy temelli gözlem yaklaşımını savunma bakışıyla konumlandırmayı ve en önemlisi ağ telemetrisinden taranabilir, bağlamlı IOC üretmeyi hedefler. Modül boyunca soru hep aynı kalır: “Bu trafik ne anlatıyor ve savunma ekibi bunu nasıl kullanır?”

Modül Teması

DNS & Domain

Çözümlenen alan adları, DGA örüntüleri, fast-flux davranışı — C2 keşfinin başlangıcı.

HTTP(S) Trafiği

User-Agent, URI yolu, beacon aralığı ve TLS parmak izleri (JA3) ile aile/kampanya işaretleri.

C2 Tespiti

Beacon’ın periyot ve jitter’ı, exfil paternleri, fallback adresler — savunma için aksiyona çevrilir.

Bu Modülde Hedeflenen Kazanımlar

DNS ve HTTP(S) trafiğinde “normal” ile “şüpheli” arasındaki farkı örüntüler üzerinden yorumlayabilmek

Şifreli trafikte içerik görünmese bile, meta-veri ve bağlam sinyalleriyle kanıt üretebilmek

Beaconing ve staging davranışlarını zamanlama, tekrar ve akış mantığıyla ayırt edebilmek

Proxy temelli gözlem yaklaşımını ne zaman ve neden kullanacağınızı; sınırlarını ve risklerini doğru konumlandırabilmek

Domain, IP, URL ve path tabanlı IOC’leri normalleştirerek (format + bağlam + güven düzeyi) savunma ekiplerinin kullanabileceği hale getirebilmek

1. Ağ davranışı analizi: “Nereye, ne sıklıkta, hangi bağlamla?”

Ağ davranışı analizi, zararlı örneğin oluşturduğu trafiği yalnızca “paketler” olarak değil, bir davranışın dışa yansıması olarak okumaktır. Bu okuma için üç katman birlikte düşünülür:

Hedef katmanı: Hangi domain/IP’lere yöneldi? Hedefler tekil mi, çok mu? Rastgele mi, tematik mi?

Zamanlama katmanı: Trafik patlama şeklinde mi geldi, yoksa düzenli aralıklarla mı?

Bağlam katmanı: Trafiği hangi süreç üretti, trafik öncesi/sonrası host üzerinde hangi izler oluştu?

Modül 5’te sistem davranışını incelerken süreç ağacı, dosya ve registry artefaktlarıyla “yerel hikâyeyi” kurmuştunuz. Burada o hikâyenin dışarı uzanan kolunu okursunuz. Aynı domain’e giden trafik, farklı bir süreçten çıktığında bambaşka anlam taşıyabilir.

Örnek: Bir doküman görüntüleyici süreç, kısa süre içinde bir komut yorumlayıcı süreci tetikliyor; hemen ardından example.net alan adına DNS sorgusu görülüyor. Bu zincir, tek başına “domain şüpheli” demekten daha güçlü bir anlatı üretir; çünkü ağ sinyali, süreç bağlamıyla desteklenir.

Dikkat: Ağ trafiğini bağlamdan koparıp “C2 budur” diye etiketlemek, savunmada en pahalı hatalardan biridir. DNS sorgusu görmek ile başarılı bağlantı/oturum görmek aynı şey değildir; bu ayrımı kurmadan yapılacak bloklama önerileri yanlış pozitif riskini büyütür.

1.1. Kanıt–çıkarım ayrımı ve güven düzeyi: ağ için doğru dil

Ağ tarafında “kanıt” genellikle gözlenen bir olaydır: DNS sorgusu, bağlantı girişimi, TLS el sıkışması, HTTP isteği gibi. “Çıkarım” ise bunun muhtemel anlamıdır: C2 niyeti, staging, veri sızıntısı gibi.

Güven düzeyini belirlerken şu düşünce disiplini işe yarar:

Yüksek güven: Trafik olayı kuruldu/gerçekleşti ve süreç bağlamı nettir (ör. belirli süreçten çıkan başarılı HTTP istekleri ve tutarlı hedef).

Orta güven: Niyet/deneme sinyali vardır ama “tam gerçekleşti” diyemediğiniz bir boşluk bulunur (ör. DNS var, oturum kanıtı yok).

Düşük güven: Tekil ve bağlamsız ipucudur; farklı senaryolarla açıklanabilir (ör. tek bir şüpheli görünümlü alt alan adı).

Örnek: example.org için DNS sorgusu görülüyor, ancak ağ katmanında oturum kurulduğunu gösteren bir işaret yok. Bu durumda “aktif iletişim kurdu” iddiası kurulmaz; domain orta güven IOC adayı olarak yazılır ve ilgili zaman penceresinde DNS/proxy kayıtlarıyla korelasyon istenir.

2. DNS ve HTTP(S) örüntüleri: “İlk uyarı levhaları”

Zararlı yazılımlar çoğu zaman doğrudan IP’ye gitmek yerine domain kullanır. Bunun nedeni basittir: IP değişse bile domain aynı kalabilir ya da saldırgan DNS kaydını güncelleyerek altyapıyı taşır. Bu da DNS katmanını, daha bağlantı kurulmadan önce bile “nereye gitmek istediğini” anlatan değerli bir sinyal haline getirir.

2.1. DNS sorgularında anomali aramak

DNS tarafında şüphe uyandıran örüntüler genellikle “tek sorgu”dan çok, şekil ve tekrar ile ortaya çıkar:

Anlamsız görünen, uzun ve rastgele karakterli alt alan adları

Kısa süre içinde çok sayıda başarısız çözümleme denemesi (ısrarcı tekrar)

Normalde kurum/uygulama profilinde görülmeyen TLD’lere yönelim

Aynı süreçten, kısa zaman aralığında çok sayıda farklı domain’e yönelim

Örnek: Bir süreç art arda qwe123asdzxc.example.com benzeri alt alan adlarını çözümlemeye çalışıyor ve önemli kısmı başarısız görünüyor. Bu görünüm, otomatik üretilen domain denemelerine (DGA benzeri davranışa) işaret edebilir ve “botnet/otomasyon altyapısı” ihtimalini gündeme taşır.

DNS analizi, savunmada “erken uyarı” gibi çalışır. Ancak tek başına hüküm vermez; DNS’in ardından bağlantı/oturum sinyalleri ve süreç bağlamı aranır.

2.2. HTTP(S) tarafında istek ve başlık sinyalleri

HTTP trafiği saldırgan için caziptir; çünkü web trafiği gürültünün içinde kolay saklanır. Analist için de değerlidir; çünkü başlıklar ve URL yapısı davranış hakkında çok şey anlatır.

HTTP(S) trafiğini yorumlarken özellikle şu sinyaller öne çıkar:

User-Agent tutarlılığı: Gerçek tarayıcı profiline uymayan, boş, aşırı sıra dışı ya da sabit kalan User-Agent’lar

İstek ritmi: Düzenli aralıklarla tekrarlanan küçük istekler (beaconing sinyali olabilir)

URL / path yapısı: Rastgele görünümlü yollar, olağandışı uzantılar, “upload/ gate / api” gibi işlev çağrıştıran uçlar

Yöntem ve içerik ipuçları: Sürekli POST denemeleri, çok küçük gövde boyutları, tekrar eden parametre şablonları

Örnek: Aynı süreçten gelen isteklerde User-Agent alanı sürekli boş kalıyor ve istekler hep benzer boyutta tekrarlanıyorsa, bu trafik “insan tarayıcı davranışı” olmaktan uzak görünür; otomatik bir istemciyi düşündürür.

HTTPS devreye girdiğinde içerik şifreli olabilir; bu durumda bile hedef domain, zamanlama, bağlantı kurulup kurulmadığı, oturumların sayısı ve süreleri gibi meta sinyaller savunma için anlam taşır.

3. Beaconing ve staging: “Ritmi yakala, akışı anla”

Ağ trafiğinde iki davranış sınıfı, orta seviye analist için özellikle öğreticidir: beaconing ve staging. Bu kavramlar tek başına “kötülük” kanıtı değildir; ancak doğru bağlamda güçlü sinyal üretir.

3.1. Beaconing: periyodik “buradayım” sinyali

Beaconing, bir zararlı yazılımın belirli aralıklarla bir hedefe kısa bir sinyal göndermesi ve yanıt beklemesi davranışıdır. Bu, “komut bekleme” ya da “durum bildirme” amacı taşıyabilir.

Beaconing’i düşündüren işaretler:

Düzenli aralıklarla tekrar eden trafik

İstek boyutlarının ve hedefin görece sabit kalması

Trafiğin çoğu zaman “kısa, rutin, tekrarlı” olması

Örnek: Bir süreç, gün boyunca benzer boyutlu istekleri belirli aralıklarla 198.51.100.25 hedefine gönderiyor; her seferinde kısa bir yanıt alıyor. Bu ritim, “periyodik sinyalleşme” ihtimalini gündeme getirir ve tespit mantığı açısından değerlidir.

Bazı örneklerde aralıklar sabit olmaz; jitter denilen zaman sapmalarıyla ritim “insan gibi” gösterilmeye çalışılabilir. Jitter’ın ayrıntılı doğrulama ve trafik manipülasyonu boyutu, ileri düzey analiz araç ve yöntemleri gerektirir. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

3.2. Staging: yükü aşamalara bölmek

Staging, zararlı yükün tek seferde gelmemesi; önce küçük bir bileşenin inmesi, ardından ek parçaların aşama aşama çekilmesi davranışıdır. Savunma için kritik noktası şudur: ilk aşama tespit edilirse sonraki parçalar gelmeden zincir kırılabilir.

Staging’i düşündüren işaretler:

Önce küçük bir istek/yanıt, ardından kısa süre içinde yeni istek dalgaları

Bir domain’e “yoklama” benzeri trafik, ardından başka bir adrese yönelim

İndirme davranışının parçalara ayrılmış görünmesi

Örnek: Trafik önce updates-cdn.example.net alan adına kısa bir istekle başlıyor, ardından birkaç dakika içinde farklı path’lere art arda istekler geliyor. Bu örüntü, “aşamalandırılmış indirme/kurulum” olasılığını yükseltir ve IOC üretiminde sadece domain değil URL path seviyesinde işaret bırakmayı değerli kılar.

İpucu: Beaconing ve staging’i ayırt etmenin pratik yolu “niyet” sorusudur. Beaconing çoğu zaman “komut var mı?” ritmidir; staging daha çok “parça parça içerik çekme” akışıdır. Aynı örnekte ikisi birlikte de görülebilir; bu durumda zaman çizelgesi, karışıklığı hızla çözer.

4. Proxy ile trafik gözlemi yaklaşımı: şifreli trafik gerçeğiyle baş etmek

Modern trafiğin büyük kısmı TLS ile şifreli olduğundan, içerik her zaman görünmez. Bu noktada proxy yaklaşımı, analiz ortamında görünürlük artırma amacıyla gündeme gelir. Orta seviyede önemli olan, “nasıl kurulacağı” değil; ne zaman anlamlı, ne zaman sınırlı olduğudur.

Proxy yaklaşımıyla iki şey hedeflenir:

Şifreli trafiğin “sadece nereye gittiğini” değil, mümkün olduğunda “ne konuştuğunu” da gözlemlemek

IOC çıkarımını domain seviyesinden URL/path seviyesine kadar zenginleştirebilmek

Bununla birlikte bazı yazılımlar, sertifika doğrulamasını sıkılaştırarak (certificate pinning gibi) proxy gözlemini zorlaştırabilir. Bu durumda orta seviyede yapılması gereken, “şifreli trafik içerik doğrulaması sınırlı kaldı” notunu rapora koymak ve elde kalan meta sinyalleriyle (zamanlama, hedef, oturum) kanıtı güçlendirmektir. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

Dikkat: Proxy ile görünürlük kazanmak savunma analizini güçlendirir; fakat raporda “ne gördüm?” ile “ne varsayıyorum?” çizgisi daha da kritik hale gelir. İçerik göremediğiniz durumda “veri sızdırdı” gibi ifadeler yerine, gözlenen sinyali doğru yazmak (ör. “tekrarlı POST denemesi”, “oturum kuruldu/kurulmadı”) hem daha güvenilir hem daha eyleme dönüktür.

İpucu: Şifreli trafik varken bile “her şey karanlık” değildir. Domain, oturum sayısı/süresi, trafik hacminde ani artışlar, tekrar ritmi ve en önemlisi bunu üreten süreç bağlamı, çoğu vakada savunma aksiyonunu tasarlamak için yeterli iskeleti verir.

5. IOC çıkarımı: domain, IP, URL ve path’i “taranabilir” hale getirmek

Bu modülün çıktısı “trafik gördüm” değil; savunma ekiplerinin ortamda arayabileceği, korele edebileceği ve ölçülü aksiyon alabileceği IOC seti olmalıdır. Bunun anahtarı, IOC’yi tek satırlık değer olmaktan çıkarıp bağlam + güven düzeyi ile paketlemektir.

Ağ tarafında tipik IOC türleri:

Domain IOC: updates-cdn.example.net gibi hedef alan adları

IP IOC: 203.0.113.110 gibi hedef sunucu adresleri

URL IOC: <https://example.org/v1/api/upload.php> gibi tam adresler

Path örüntüsü: /v1/api/upload.php gibi alan adından bağımsız yol şablonu

Sadece domain’i yazmak çoğu zaman yetmez. Bazı saldırılar, meşru bir alan adının altına belirli bir path yerleştirerek çalışabilir; tüm domain’i engellemek iş sürekliliğini bozabilir. Bu nedenle IOC üretirken “ne kadar dar, o kadar iyi” prensibi sıkça işe yarar; fakat daraltmanın doğru yapılabilmesi için bağlam gerekir.

Örnek: Trafikte example.net alan adı görünüyor; ancak yalnızca /content/check path’ine tekrarlı istekler var. Bu durumda IOC paketinde domain’i yazmakla yetinmeyip path bilgisini de eklemek, hem avcılığı hem de hedefli engellemeyi daha güvenli hale getirabilir.

5.1. Normalizasyon ve rapor dili: ekiplerin aynı şeyi aramasını sağlamak

IOC’lerin taramada işe yaraması için “format tutarlılığı” kadar “anlam tutarlılığı” da gerekir. Bu yüzden her IOC için şu bilgileri raporda doğal biçimde taşımak, savunma değerini artırır:

Değer (domain/IP/URL/path)

Kaynak (DNS mi HTTP mi; hangi gözlem kanalı)

Bağlam (hangi süreçle ilişkili)

Zaman (hangi pencere içinde)

Güven düzeyi (yüksek/orta/düşük)

Kısa not (neden önemli, hangi davranışla ilişkili)

İpucu: IOC’leri tek bir liste halinde vermek yerine, raporda “gözlenen/doğrulanmış” ile “aday/niyet” ayrımını net tutmak avcılık ve bloklama kararlarını berraklaştırır. Aynı göstergenin iki farklı güven düzeyinde karışması, ekipte gereksiz tartışma ve yanlış bloklama doğurur.

5.2. Yanlış pozitif riski: ağ göstergelerinde ölçülü savunma

Ağ göstergeleri, özellikle domain ve IP seviyesinde, yanlış pozitife yatkın olabilir. Güncelleme altyapıları, içerik dağıtım ağları ve telemetri servisleri benzer örüntüler üretebilir. Bu yüzden “otomatik ve sert” aksiyonlar yerine, güven düzeyine göre kademeli yaklaşım daha sağlıklıdır:

Yüksek güven sinyal varsa hedefli engelleme ve kapsam taraması önerisi güçlenir.

Orta/düşük güven sinyallerde önce avcılık ve korelasyonla “meşru mu, değil mi?” ayrımı yapılır.

Bu modülün odağında, karar matrisini uzun uzun kurmak yerine, ağ sinyalini doğru paketleyip Modül 11–12’deki raporlama ve bütünleme sürecine “temiz girdi” hazırlamak vardır.

Terimler Sözlüğü

Terim	Açıklama
DNS	Alan Adı Sistemi; domain adını IP’ye çözümleyen altyapı
HTTP	Web iletişim protokolü; istek/yanıt mantığıyla çalışır
HTTPS	HTTP’nin TLS ile şifrelenmiş hali
TLS	İletişimi şifreleyen güvenlik katmanı; oturum kurma ve şifreleme sağlar
C2 (Command and Control)	Komuta-kontrol; saldırganın zararlıyı yönettiği altyapı
User-Agent	HTTP başlığında istemci uygulamayı tanımlayan bilgi
Beaconing	Sinyalleşme; belirli aralıklarla “aktifim” benzeri trafik üretme davranışı
Staging	Aşamalara ayırma; yükün/işlevin parça parça indirilmesi/başlatılması yaklaşımı
Jitter	Zaman sapması; periyodik trafiğin aralıklarını rastgeleleştirme eğilimi
Proxy	Trafiği ara katmanda yöneten/gözlemleyen bileşen; analizde görünürlük artırmak içinkullanılır
IOC (Indicator of Compromise)	İhlal göstergesi; taranabilir teknik gösterge (domain, IP, URL, path vb.)
Confidence	Güven düzeyi; bulgunun kanıt gücüne göre aksiyon uygunluğu

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)DNS sorgusu görülüyor ancak bağlantı/oturum kurulduğunu gösteren hiçbir işaret yok. En doğru raporlama yaklaşımı hangisidir?

A)Kesin C2 iletişimi gerçekleşti.

B)DNS sorgusu gözlendi; oturum kanıtı olmadığı için aktif iletişim iddiası kurulamaz. Domain orta güven IOC adayıdır.

C)DNS varsa mutlaka veri sızmıştır.

D)DNS önemsizdir, rapora yazılmaz

E)Tüm domain’ler koşulsuz engellenmelidir.

Doğru: B
Gerekçe: B, kanıtı (DNS) ve eksik kanıtı (oturum yok) ayırır; ölçülü güven dili kullanır. A/C aşırı kesin; D bilgi kaybı; E yanlış pozitif riskini artırır.

2)Aşağıdakilerden hangisi DNS tarafında “örüntü” olarak şüphe uyandırmaya en yakındır?

A) Tek seferlik bir domain çözümlemesi

B) Kısa sürede çok sayıda rastgele görünümlü alt alan adı denemesi

C) Bilinen bir kurumsal alan adına düzenli erişim

D) Aynı ağda birden fazla kullanıcının aynı siteyi açması

E) Tarayıcı önbelleğinin artması

Doğru: B
Gerekçe: Rastgele alt alan adları ve çoklu deneme örüntüsü, DGA benzeri davranışları düşündürür. Diğerleri tek başına şüphe üretmez veya konuyla ilgisizdir.

3)HTTP trafiğinde User-Agent alanının sürekli boş kalması ve istek boyutlarının tekrarlı biçimde benzemesi neyi düşündürür?

A) İnsan tarayıcı davranışını

B) Otomatik bir istemci veya zararlı bileşen olasılığını

C) Ağın tamamen güvenli olduğunu

D) Dosya sisteminde kalıcılığın kesin kanıtını

E) DNS sunucusunun bozuk olduğunu

Doğru: B
Gerekçe: Tutarsız/boş User-Agent ve tekrarlı şablonlar otomasyon sinyalidir. A genellikle daha değişken profil gösterir; C/D/E çıkarım hatasıdır.

4)Beaconing davranışını en iyi tarif eden seçenek hangisidir?

A) Tek seferlik büyük bir dosya indirme

B) Düzenli/tekrarlı aralıklarla kısa, benzer trafik üretme

C) Sadece DNS önbelleğinin temizlenmesi

D) Registry’ye yazma girişimi

E) Dosya uzantısının değişmesi

Doğru: B
Gerekçe: Beaconing “ritim” ile anlaşılır. Diğer şıklar ağ davranışı tanımıyla örtüşmez.

5)Staging davranışı için en uygun çıkarım hangisidir?

A) Tüm zararlı işlev tek pakette gelir, tekrar yoktur

B) Önce küçük bir bileşen/istek, ardından aşama aşama yeni istekler ve indirmeler görülür

C) Ağ trafiği yoksa staging vardır

D) Staging sadece fiziksel cihazlarda olur

E) Staging, User-Agent alanının boş olmasıdır

Doğru: B
Gerekçe: Staging aşamalı akıştır. A tersidir; C/D/E yanlış/genelleyici tanımlardır.

6)Şifreli trafikte içerik görünmüyorken “kanıt üretmek” için en sağlam yaklaşım hangisine yakındır?

A) İçeriği göremedim, o zaman hiçbir şey söylenemez

B) Domain/oturum sayısı, zamanlama ritmi ve bunu üreten süreç bağlamını birlikte raporlamak

C) Otomatik olarak “veri sızdırdı” yazmak

D) Sadece IP adresini yazıp geçmek

E) Her zaman tüm domain’leri engellemeyi önermek

Doğru: B
Gerekçe: Şifreli trafikte meta sinyaller + süreç bağlamı, doğrulanabilir rapor üretir. A aşırı pesimist; C spekülatif; D bağlamı zayıf; E operasyonel riskli.

7)Aşağıdakilerden hangisi IOC’nin “taranabilir” olmasını en iyi güçlendirir?

A) Sadece domain’i yazmak

B) IOC’yi değer + kaynak + süreç bağlamı + zaman penceresi + güven düzeyi ile vermek

C) IOC’yi rapordan tamamen çıkarmak

D) Her IOC’ye “kesin zararlı” etiketi eklemek

E) Yalnızca ekran görüntüsü paylaşmak

Doğru: B
Gerekçe: Normalizasyon ve bağlam, IOC’yi operasyonel hale getirir. A/D eksik veya riskli; C/E yetersiz.

8)Domain yerine URL/path seviyesinde IOC yazmanın savunma açısından avantajı nedir?

A) Daha fazla yanlış pozitif üretmek

B) Hedefli engelleme ve avcılık yaparak iş sürekliliğini korumaya yardımcı olmak

C) TLS şifrelemesini otomatik kırmak

D) Dosyayı otomatik temizlemek

E) Her vakada gereksiz ayrıntı eklemek

Doğru: B
Gerekçe: Domain engelleme bazen aşırı geniştir; path/URL daha hedeflidir. C/D teknik olarak yanlış; A/E amaç dışıdır.

9)Proxy yaklaşımıyla ilgili orta seviye için en doğru ifade hangisidir?

A) Proxy kurulum adımları modülün ana hedefidir.

B) Proxy, şifreli trafikte görünürlük artırabilir; ancak bazı örnekler içerik gözlemini kısıtlayabilir. Bu durumda rapor meta sinyallere dayanmalı ve sınırlar açık yazılmalıdır.

C) Proxy varsa her şey kesin kanıtlanır.

D) Proxy kullanımı her ortamda zorunludur.

E) Proxy sadece saldırı yapmak için kullanılır.

Doğru: B
Gerekçe: B, doğru çerçeveyi ve sınırlamaları anlatır. C/D aşırı genelleme; E yanlış ve yönlendirici.

10)Bir süreçten çıkan tekrarlı POST istekleri görülüyor; ancak içerik şifreli ve gönderilen veri görülemiyor. En doğru yaklaşım hangisidir?

A) “Kesin parola sızdırdı” yazmak

B) “Tehlike yok” demek

C) Trafiğin zamanlamasını, hedefini, oturum kurulup kurulmadığını ve süreç bağlamını raporlayıp, veri içeriği için kanıt boşluğu olduğunu belirtmek

D) Sadece dosya adını yazmak

E) Sadece kullanıcı şikâyetine dayanarak karar vermek

Doğru: C
Gerekçe: C, kanıt–boşluk ayrımını kurar ve savunma ekibinin arayacağı alanları netleştirir. A spekülasyon; B acele hüküm; D/E eksik delildir.

Bu Modülde Kazanılan Yetkinlikler

DNS ve HTTP(S) trafiğini tekil olaylar yerine örüntüler üzerinden okumayı
DNS sinyalinin “niyet”, oturum/istek sinyallerinin “gerçekleşme” tarafında daha güçlü kanıt ürettiğini
Beaconing ve staging davranışlarını ritim ve akış mantığıyla ayırt etmeyi
Şifreli trafikte içerik görünmese bile meta sinyaller ve süreç bağlamıyla savunma değerinde çıktı üretmeyi
Domain/IP/URL/path tabanlı IOC’leri bağlam + zaman + güven düzeyi ile normalleştirerek taramaya hazır hale getirmeyi

MODÜL 7 — Sandbox Raporu Okuma ve Doğrulama

Kurumsal ortamlarda her gün yüzlerce, bazen binlerce şüpheli dosya triage edilmek zorunda kalır. Sandbox (detonation/kum havuzu) sistemleri bu yükü hafifleterek örneği kontrollü bir ortamda çalıştırır ve süreç, dosya/registry ve ağ davranışlarını raporlar. Bu modülde amaç; sandbox çıktısını bir “otomatik karar” gibi değil, hızlı hipotez üreten bir kanıt havuzu gibi okuyabilmek, yanlış pozitif/yanlış negatif risklerini sezebilmek ve kritik bulguları manuel gözlemle doğrulayarak savunma ekiplerinin güvenle kullanacağı operasyonel çıktılara dönüştürmektir.

Modül Teması

Otomatik Çıktı

Skor, etiket ve davranış listesi: hızlı yön ama tek başına hüküm değildir.

Doğrulama

Sandbox bulgularını yerel gözlemle çapraz doğrula; ortam farkı, anti-VM ve trigger eksikliklerine dikkat.

Kanıt Köprüsü

Rapordaki sinyalleri kendi timeline ve IOC paketine eşleştirerek savunma çıktısına dönüştür.

Bu Modülde Hedeflenen Kazanımlar

Sandbox raporundaki temel bölümleri (özet/skor, süreç ağacı, ağ, dosya/registry, imza/etiket eşleşmeleri) doğru sırayla okuyup her bölümün ürettiği kanıt türünü ayırt edebilmek.
Skor/verdict ve etiketlerin neyi söylediğini, neyi söylemediğini; “kanıt” ile “yorum” arasındaki çizgiyi koruyabilmek.
Yanlış pozitif (FP) ve yanlış negatif (FN) nedenlerini ortam koşulları, telemetri sınırları ve davranış örüntüleri üzerinden açıklayabilmek.
Ağ ve sistem bulgularını bağlam + zaman penceresi + güven düzeyi ile paketleyerek avcılık/engelleme/tarama gibi savunma aksiyonlarına çevirebilmek.
Sandbox raporundaki kritik iddiaları manuel doğrulama planına dönüştürmek (süreç, artefakt, ağ, kalıcılık ekseninde).

1. Sandbox raporu neyi temsil eder, neyi temsil etmez?

Sandbox raporu, “dosya kesin zararlı mı?” sorusunu tek başına nihai biçimde yanıtlamaktan çok, hızlı triage için kanıt parçalarını bir araya getirir. Birçok sandbox; süreç ağacı, dosya/registry değişimleri, ağ istekleri, düşürülen dosyalar, davranış imzaları/etiketleri, ekran görüntüleri ve IOC adaylarını aynı raporda toplar. Bunu, acil serviste çekilen bir “hızlı röntgen” gibi düşünebilirsiniz: yön verir, fakat teşhisi sağlamlaştırmak için doğru soruları sormanızı ve kanıtı tamamlamanızı ister.

Bu noktada iki zihinsel çerçeve her zaman korunur:

Gözlenen olay: Sandbox’ın telemetrisiyle gerçekten gördüğü şey (DNS sorgusu, bağlantı girişimi, yeni dosya oluşumu, child process açılması gibi).

Yorum/etiket: Sisteminin bu olayı bir kategoriye koyması (ör. “C2”, “persistence”, “credential access” gibi).

Dikkat: Sandbox’ın etiketi kanıtın kendisi değildir. Bir raporda “C2” yazması, sizin raporunuzda otomatik olarak “C2 kesin” yazmanız anlamına gelmez. Etiketin arkasındaki olayları (DNS mi, oturum mu, hangi süreçten çıktı?) görmeden yapılan kesin aktarım, yanlış bloklama ve yanlış önceliklendirme doğurabilir.

1.1. Ne zaman güçlü, ne zaman zayıf?

Sandbox güçlüdür çünkü:

Yüksek görünürlükle ilk izleri hızlı çıkarır (özellikle süreç + ağ + dosya/registry katmanlarını birlikte).

Çok sayıda örneği aynı gözlem şablonuyla kıyaslamayı kolaylaştırır.

Analistin “nereye bakacağını” hızla daraltır.

Sandbox zayıflayabilir çünkü:

Örnek, ortam koşulları uygun değilse davranış göstermeyebilir (zaman gecikmesi, kullanıcı etkileşimi bekleme, internet bağımlılığı, ortam uyumsuzluğu gibi).

Telemetri her şeyi kapsamaz; bazı olaylar görünmeyebilir ya da eksik bağlamla raporlanabilir.

Normal işletim sistemi gürültüsü, davranış listelerini şişirebilir.

İpucu: Sandbox raporuna bakarken zihninizde tek bir cümle sabit kalsın: “Bu rapor bir hipotez üretiyor; ben bu hipotezi hangi ek kanıtla güçlendireceğim?”

2. Rapor bölümlerini profesyonelce okuma: “hangi bölüm ne söyler?”

Sandbox raporları farklı ürünlerde farklı görünebilir; ancak içerik mantığı çoğunlukla benzer katmanlarda toplanır. Buradaki hedef, verinin içinde kaybolmadan kritik noktaları süzmektir.

2.1. Genel özet, verdict ve skorlama

Özet kısmında genellikle dosyanın kimliği (hash’ler, tür, boyut), genel karar (malicious/suspicious/clean gibi) ve skor bulunur. Skor çoğu zaman, tespit edilen davranış göstergelerinin ve kural/heuristik eşleşmelerinin ağırlıklandırılmış bir toplamı olarak düşünülmelidir; bu yüzden “yüksek skor = kesin zararlı” refleksi doğru değildir.

Örnek: Bir dosyanın skoru yüksek görünüyor; ayrıntıda ise skorun büyük kısmı “tanınmayan yayıncı”, “geçici dizine dosya yazma” gibi tek başına düşük riskli olayların birikiminden geliyor olabilir. Bu durumda asıl değer, hangi olayların gerçekten tehdit niyetine işaret ettiğini ayırabilmektir.

2.2. Davranış özeti, süreç ağacı ve zaman çizelgesi

Süreç ağacı (process tree), hangi sürecin hangisini başlattığını; zaman çizelgesi ise olayların sırasını anlatır. İkisi birlikte okunduğunda “liste” yerine bir olay akışı elde edersiniz.

Şu sorular, süreç ağacı okurken otomatikleşmelidir:

Başlatan süreç beklenen bir bağlamda mı?

Child process zinciri “normal uygulama hikâyesi” mi anlatıyor, yoksa anomali mi var?

Ağ trafiği hangi süreçten çıkıyor ve süreç zincirinde nereye oturuyor?

Örnek: Bir belge görüntüleyiciden kısa süre sonra komut yorumlayıcı benzeri bir süreç doğuyor; hemen ardından example.net alan adına DNS sorgusu ve sonrasında HTTPS oturum girişimi görülüyor. Bu senaryoda ağ sinyali, süreç bağlamıyla birleştiği için çok daha güçlü bir anlatı üretir.

2.3. Ağ aktiviteleri: DNS, bağlantılar, HTTP(S) ve ham trafik

Ağ bölümünde DNS sorguları, TCP/UDP bağlantıları, HTTP istekleri ve bazen TLS oturum meta verileri yer alır. Bazı sandbox’lar ham trafik çıktısı (PCAP) da sunar; bu, otomatik özetin atladığı ayrıntıları doğrulamak için değerlidir.

Örnek: Rapor “yoğun HTTP istekleri” diyor. Ham trafik varsa, talep/yanıt örüntüsünü ve veri transferinin gerçekten gerçekleşip gerçekleşmediğini daha net yorumlayabilirsiniz.

Dikkat: “DNS sorgusu var” ile “başarılı oturum kuruldu” aynı şey değildir. DNS, çoğu zaman niyeti; oturum/yanıt sinyalleri ise gerçekleşmeyi daha güçlü gösterir. Bu ayrımı kurmadan yazılan “C2 kurdu” gibi ifadeler yanlış kesinlik üretir.

2.4. Dosya değişiklikleri ve düşürülen dosyalar

Bu bölüm, oluşturulan/değiştirilen/silinen dosyaları ve “dropped files” olarak raporlanan yeni bileşenleri listeler. Burada önemli olan; dosya adının “şüpheli görünmesi” değil, zaman çizelgesindeki yeri ve hangi süreç tarafından üretildiğidir.

Örnek: “Dropped file” listesinde yeni bir dosya var; ancak süreç ağacında bu dosyanın yürütüldüğüne dair bir kanıt yok. Bu durumda rapor dili “düşürüldü” iddiasını kurabilir, “çalıştırıldı” iddiasını ise ancak ek kanıt varsa kurar.

2.5. Registry değişiklikleri ve kalıcılık sinyalleri

Registry listeleri uzun olabilir; analistin görevi “her satırı” okumak değil, kalıcılık veya sistem davranışıyla ilişkili örüntülere odaklanmaktır. “Persistence attempt” benzeri etiketler varsa, bu etiketin hangi yazma/okuma olaylarına dayandığı ve olayın başarıyla tamamlanıp tamamlanmadığı ayırt edilmelidir.

2.6. İmza eşleşmeleri ve MITRE ATT&CK eşlemeleri

Bazı sandbox’lar, davranışları imza/kural setleriyle eşleştirir ve ATT&CK tekniği gibi bir çerçevede sınıflandırır. Bu, ekipler arası ortak dil kurmak için çok faydalıdır; ancak tek başına kanıt değildir.

Örnek: “Signature Hits” bölümünde belirli bir zararlı ailesiyle eşleşme yazıyor. Bu, sandbox kurallarının benzer örüntü yakaladığını söyler; siz yine de süreç, ağ ve artefakt kanıtlarıyla eşleştirmeyi desteklemelisiniz.

3. FP/FN farkındalığı: raporu doğru ölçekle yorumlamak

Otomatik sistemlerin hatası olabilir; analisti analist yapan şey, bu hatayı fark edip rapor dilini doğru kurabilmesidir.

3.1. Yanlış pozitif (FP): “zararsız ama şüpheli görünen”

FP’yi sık üreten durumlar:

Meşru kurulum/güncelleme yazılımlarının çok sayıda dosya yazması ve bazı başlangıç ayarlarına dokunması

Yönetim/otomasyon araçlarının tarayıcı dışı trafik üretmesi ve bunun “C2 benzeri” görünmesi

Heuristik skorlamanın düşük riskli olayları birikimli biçimde büyütmesi

Normal sistem aktivitelerinin (servis rutinleri gibi) davranış listesinde tehdit gibi görünmesi

Örnek: Bir installer, çalışırken çok dosya yazıyor ve bazı ayarları güncelliyor; sandbox bunu “dropper” gibi yorumlayıp yüksek skor verebilir. Bu noktada süreç bağlamı ve olay akışı, FP’yi ayırmak için belirleyicidir.

3.2. Yanlış negatif (FN): “zararlı ama sessiz görünen”

FN riskini artıran durumlar:

Örnek, kullanıcı etkileşimi bekliyordur (CAPTCHA, şifre girişi, “Devam” butonu gibi)

Örnek, belirli koşul oluşmadan davranış üretmez (zaman gecikmesi, internet bağımlılığı)

Ortam uyumsuzluğu vardır (örneğin uygulama yalnızca 64-bit sistem ister; sandbox koşulu karşılamazsa gerçek davranış başlamayabilir)

Örnek, analiz ortamında davranışını kısar (evasion)

Örnek: Ekran görüntülerinde yalnızca “Bu uygulama sadece 64-bit sistemlerde çalışır” mesajı var. Bu durumda rapor “davranış” üretmemiş olabilir; skor/etiketlerin bir kısmı yanıltıcı çıkabilir ve analizi uygun koşullarda yeniden değerlendirmek gerekir.

Evasion (analizden kaçınma) yaklaşımına yalnızca kavramsal düzeyde dokunmak yeterlidir: Bazı örnekler analiz ortamında şüpheli hareket yapmadan “uyku” modunda kalabilir. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

İpucu: Rapor “No suspicious activity found” benzeri bir ifade içeriyorsa, bunu “temiz” diye çevirmek yerine şu güvenli dili tercih edin: “Bu gözlem koşullarında belirgin şüpheli davranış gözlenmedi; FN olasılığı ve ortam varsayımlarıyla birlikte değerlendirilmelidir.”

4. Otomatik bulguyu manuel doğrulama planına çevirmek

Bu modülün pratik çıktısı, sandbox raporunu “kopyalanacak ekran” olmaktan çıkarıp “doğrulanabilir rapor girdisi” haline getirmektir. Burada hedef; araç komutlarına boğulmak değil, hangi kanıtın nerede aranacağını bilerek doğrulama yürütmektir.

4.1. Dört eksenli doğrulama: süreç, artefakt, ağ, kalıcılık

Çoğu vaka şu eksenlerde toparlanır:

Süreç zinciri: Kim kimi başlatıyor? Parametre/ilişki anomali mi?

Dosya/registry artefaktları: Ne oluştu/değişti? Zaman çizelgesindeki yeri ne?

Ağ davranışı: DNS var mı, oturum var mı, yanıt var mı, trafik hacmi/ritim nasıl?

Kalıcılık sinyali: Kalıcılık girişimi mi, kalıcılık gerçekten oluşmuş mu?

Örnek: Sandbox “persistence attempt” diyorsa, doğrulama planınız; ilgili registry yazmasını zaman çizelgesinde konumlandırmak, hangi süreçten geldiğini görmek ve kalıcılığın sistemde gerçekten etkinleşip etkinleşmediğini ayırt etmek olmalıdır.

4.2. “İddia → aranacak kanıt → eksikse rapor dili” eşleştirmesi

Sandbox raporunu okurken her iddiayı şu şekilde düşünün:

“Ağ iletişimi kurdu” → DNS + bağlantı/oturum kanıtı + süreç bağlamı - Eksikse: “DNS görüldü; oturum/yanıt kanıtı yok” veya “bağlantı girişimi var; başarılı oturum doğrulanamadı”

“Dosya düşürdü” → dosya yolu + oluşturulma zamanı + ilgili süreç + varsa hash - Eksikse: “Düşürülen dosya listelendi; yürütme kanıtı yok”

“Kalıcılık kurdu” → kalıcılık noktası + yazan süreç + etkinleşme kanıtı - Eksikse: “Kalıcılık girişimi sinyali var; kalıcılığın oluştuğu doğrulanmadı”

“Belirli zararlı ailesiyle eşleşti” → imza eşleşmesi + davranış kanıtlarıyla tutarlılık - Eksikse: “İmza eşleşmesi var; aile atfı için ek kanıt gerekir”

4.3. Manuel doğrulamada sık kullanılan iki pratik “yakalama noktası”

Ekran görüntüleri: Uygulama hata veriyor mu, etkileşim bekliyor mu, hiç çalışmış mı? Sadece boş masaüstü veya bir hata penceresi, analiz akışının gerçekte başlamadığını gösterebilir.

Ağ ham verisi / altyapı gürültüsü: Bazı sandbox’lar kendi altyapı trafiğini de rapora dahil edebilir. Özellikle IP listelerinde gördüğünüz değerlerin gerçekten örneğe mi ait olduğundan emin olmadan “C2 budur” diye işaretlemek risklidir.

Örnek: Raporda 192.0.2.15 gibi bir IP görünüyor. Bu IP’nin örneğin ürettiği trafikte mi, yoksa sandbox altyapı etkileşiminde mi yer aldığını doğrulamadan aksiyon önerisi üretmek doğru değildir.

İpucu: Ağ bölümündeki IOC’leri tek listede vermek yerine iki kümeye ayırın: (1) süreç bağlamı ve zaman penceresi net olan “gözlenen/doğrulanmış” göstergeler, (2) “aday/doğrulama bekleyen” göstergeler. Bu ayrım, avcılık ile bloklama kararını temizleştirir.

4.4. Operasyonel çıktı üretimi: IOC’leri “taranabilir” hale getirmek

Savunma ekipleri için değer; “trafik gördüm” cümlesi değil, taranabilir ve bağlamlı IOC paketidir. Her IOC için mümkünse şu bağlamı taşıyın:

Değer (domain/IP/URL gibi)

Kaynak (DNS/HTTP/TLS meta verisi vb.)

İlişkili süreç

Zaman penceresi

Güven düzeyi (yüksek/orta/düşük)

Kısa not (neden önemli, hangi örüntüyle ilişkili)

Örnek: Ağ aktivitelerinde example.com adresine doğru bir girişim var; ancak veri transferi 0 byte görünüyor. Bu, DNS çözümlemesi ve bağlantı girişimi olduğunu; fakat karşıdan yanıt gelmediğini veya iletişimin tamamlanmadığını düşündürebilir. Bu durumda IOC “aday” kümesinde tutulur ve oturum/yanıt kanıtı aranır.

Terimler Sözlüğü

Terim	Açıklama
Sandbox	Şüpheli dosyanın kontrollü ortamda çalıştırılıp davranış izlerinin toplandığı analiz sistemi
Detonation	Şüpheli örneğin sandbox içinde çalıştırılması/izlenmesi yaklaşımı
Verdict	Sandbox’ın genel değerlendirmesi (malicious/suspicious/clean vb.)
Score	Risk/seviye puanı; çoğu zaman heuristik/kural tabanlı özet göstergesi
Telemetry	Süreç, dosya, ağ, registry gibi katmanlardan toplanan gözlem verisi
Process Tree	Süreç ağacı; hangi sürecin hangi süreci başlattığını gösteren yapı
Timeline	Zaman çizelgesi; olayların sırasını ve zamanını gösteren akış
Dropped Files	Analiz sırasında oluşturulan/düşürülen yeni dosyalar
Artifact	Davranışın geride bıraktığı iz (dosya/registry/ağ izi vb.)
PCAP	Paket yakalama dosyası; ağ trafiğinin ham hâli
Signature Hits	Davranış/kural eşleşmeleri; bilinen örüntülerle yapılan eşleştirme
MITRE ATT&CK	Saldırgan taktik ve tekniklerini sınıflandıran ortak çerçeve
False Positive (FP)	Zararsız bir dosya/davranışın zararlı sanılması
False Negative (FN)	Zararlı bir dosya/davranışın temiz sanılması veya görünmemesi
Evasion	Örneğin analiz ortamında davranışını gizleme/kısıtlama eğilimi
Confidence	Güven düzeyi; bulgunun kanıt gücüne göre aksiyon uygunluğu

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)Bir sandbox raporunda skor çok yüksek; ancak ekran görüntülerinde yalnızca “Bu uygulama sadece 64-bit sistemlerde çalışır” mesajı var. En doğru yaklaşım hangisidir?

A) Skor yüksekse raporu olduğu gibi kabul etmek

B) Dosyayı hemen tüm ağda engellemek

C) Uygulamanın tam çalışmadığını ve skorun yanıltıcı olabileceğini değerlendirip uygun koşullarda yeniden gözlem planlamak

D) Skor yüksekse IOC’leri otomatik yüksek güven yazmak

E) Sandbox bozuk deyip raporu tamamen çöpe atmak

Doğru: C
Gerekçe: Ortam uyumsuzluğu gerçek davranışı bastırabilir; bu durumda rapor/skar tek başına belirleyici değildir. A/B/D yanlış kesinlik üretir; E ise değerli kanıt parçalarını kaybettirebilir.

2)“C2 Communication” etiketi var; ağ bölümünde yalnızca DNS sorgusu görülüyor, oturum/yanıt kanıtı yok. En doğru raporlama dili hangisidir?

A) Kesin C2 kurdu

B) DNS önemsiz, rapora yazılmaz

C) DNS sorgusu gözlendi; oturum kanıtı olmadığı için aktif iletişim iddiası kurulamaz. IOC adayına alınır ve doğrulama istenir.

D) Tüm domain’ler koşulsuz engellenmelidir

E) Etiketi tamamen silip hiç bahsetmemek gerekir

Doğru: C
Gerekçe: Kanıt–yorum ayrımını korur ve güven düzeyiyle ilerler. A/D aşırı sert; B/E bilgi kaybı doğurur.

3)Yanlış negatif (FN) olasılığını en çok artıran durum hangisine yakındır?

A) Dosyanın küçük olması

B) Örneğin kullanıcı etkileşimi beklemesi (CAPTCHA/şifre girişi gibi) ve otomatik analizde akışın ilerlememesi

C) Hash’in raporda görünmesi

D) Süreç ağacının görselleştirilmesi

E) Özet bölümünde “network activity” yazması

Doğru: B
Gerekçe: Etkileşim bekleyen örnekler otomatik analizde sessiz kalabilir. Diğer seçenekler FN’yi doğrudan artıran faktörler değildir.

4)Ağ bölümünde 198.51.100.1 hedefine “yoğun HTTP istekleri” özeti var. Bu bulguyu en sağlam biçimde doğrulamak için hangisi en uygunudur?

A) Dosya adını değiştirmek

B) Raporla sunulan ham trafik (PCAP) varsa onu inceleyerek özetin atladığı detayları doğrulamak

C) RAM artırmak

D) Ekran çözünürlüğünü değiştirmek

E) Dosyayı doğrudan engellemek

Doğru: B
Gerekçe: Ham trafik, otomatik özetlerin kaçırabileceği ayrıntıları doğrulamaya yarar. Diğerleri doğrulama üretmez.

5)“Dropped files” listesi bulunan bir raporda aşağıdaki iddialardan hangisi tek başına kesinleştirilemez?

A) Yeni bir dosya oluştuğu

B) Dosyanın yolunun raporlandığı

C) Dosyanın mutlaka yürütüldüğü

D) Dosyanın bir artefakt olduğu

E) Olayın zaman çizelgesine bağlanabileceği

Doğru: C
Gerekçe: Düşürülen dosyanın yürütülmesi ayrıca süreç ağacı ve zaman çizelgesiyle desteklenmelidir.

6)“Signature Hits” bölümünde belirli bir zararlı ailesiyle eşleşme yazıyor. Bu ifade en doğru şekilde nasıl yorumlanmalıdır?

A) Saldırganın adı o ailedir

B) Dosyanın adı o aile olduğu için eşleşmiştir

C) Sandbox kurallarının yakaladığı örüntüler, o aileyle benzerlik gösteriyor; aile atfı için süreç/ağ/artefakt kanıtlarıyla tutarlılık aranmalıdır

D) Bilgisayarı formatlamak zorunludur

E) Eşleşme varsa tüm IOC’ler otomatik yüksek güven olur

Doğru: C
Gerekçe: İmza eşleşmesi önemli bir sinyaldir ama tek başına nihai atıf değildir. A/B/D/E yanlış veya aşırı yorumdur.

7)Bir analist neden süreç ağacı (process tree) ile ağ bölümünü birlikte okumalıdır?

A) Dosyanın telif hakkını anlamak için

B) Ağ trafiğini hangi sürecin ürettiğini ve olay akışındaki yerini görmek için

C) RAM kapasitesini artırmak için

D) Dosya uzantısını doğrulamak için

E) Sadece raporu güzelleştirmek için

Doğru: B
Gerekçe: Süreç bağlamı, ağ davranışının anlamını belirginleştirir. Diğer seçenekler konuyla ilgisizdir.

8)Bir sandbox raporunda görülen IP’leri doğrudan “C2” diye işaretlemenin temel riski nedir?

A) IP’ler her zaman yanlış yazılır

B) Sandbox’ın kendi altyapı trafiği rapora dahil olmuş olabilir; bağlam doğrulanmadan yapılan işaretleme yanlış yönlendirir

C) IP’ler DNS yerine geçer

D) IP’ler hiçbir zaman engellenemez

E) IP’ler sadece IPv6 olur

Doğru: B
Gerekçe: Altyapı/gürültü karışımı mümkündür; süreç bağlamı ve ham trafik doğrulaması olmadan kesin atıf risklidir.

9)Sandbox raporunda example.com hedefine giden trafiğin “0 byte” olduğu görülüyor. Bu durum en makul olarak neyi düşündürür?

A) İnternet çok hızlıdır

B) DNS çözümlemesi/bağlantı girişimi olmuş olabilir; ancak veri transferi/yanıt gerçekleşmemiş veya iletişim tamamlanmamıştır

C) Dosya hiçbir zaman ağ kullanmaz

D) Bu mutlaka veri sızıntısıdır

E) Bu, dosyanın resim dosyası olduğunu gösterir

Doğru: B
Gerekçe: 0 byte, çoğu senaryoda iletişimin kurulamadığı/yanıt alınmadığı ihtimalini güçlendirir. C/D/E aşırı veya alakasız çıkarımlardır.

10) IOC’leri operasyonel olarak en sağlıklı biçimde sunan yaklaşım hangisidir?

A) Tüm IOC’leri tek listede, güven düzeyi olmadan paylaşmak

B) Yalnızca domain’leri paylaşmak; diğerlerini çıkarmak

C) IOC’leri “gözlenen/doğrulanmış” ve “aday/doğrulama bekleyen” diye ayırıp süreç + zaman penceresi + güven düzeyi ile vermek

D) IOC’leri “kesin zararlı” etiketiyle işaretlemek

E) IOC paylaşmamak, sadece skor yazmak

Doğru: C
Gerekçe: Bağlam ve güven düzeyi, savunma aksiyonunu doğru kalibre eder. A/D riskli; B/E eksiktir.

Bu Modülde Kazanılan Yetkinlikler

Sandbox raporunun nihai hüküm değil, hızlı hipotez ve kanıt üretimi aracı olduğunu
Skor/verdict/etiketlerin kanıt yerine geçmediğini; “gözlenen olay” ile “yorum” ayrımının rapor kalitesini belirlediğini
Süreç ağacı + zaman çizelgesi + ağ + artefakt katmanlarını bir olay akışına dönüştürerek okumayı
FP/FN risklerini (gürültü, ortam uyumsuzluğu, etkileşim bekleme, telemetri sınırları) rapora doğru dille yansıtmayı
Ham ağ verisi (PCAP), ekran görüntüleri ve bağlam kontrolüyle otomatik bulguları doğrulama disiplinini
IOC’leri bağlam, zaman penceresi ve güven düzeyiyle paketleyerek avcılık/engelleme/tarama gibi savunma aksiyonlarına çevirmeyi

MODÜL 8 — Cross-Platform Triage

Zararlı yazılım denince çoğu kişinin aklına önce Windows gelir; ama sunucu dünyasının omurgasını oluşturan Linux ve son kullanıcı tarafında etkisi giderek artan macOS, saldırganların da radarındadır. Bu modülde hedef, Windows dışı örneklerde ilk temas anında “neyi, hangi sırayla aramalıyım?” sorusuna net bir triage pusulası edinmek: ELF (Linux) ve Mach-O (macOS) örneklerini doğru sınıflandırmak, hızlı risk sinyalleriyle önceliklendirmek ve özellikle kalıcılık (persistence) izlerini kanıt–yorum ayrımını bozmadan raporlamaktır.

Modül Teması

Windows: PE

PE32/PE32+, import/export tablosu, resource bölümü ve servis/registry kalıcılığı.

Linux: ELF

ELF segmentleri, dynamic section, init/systemd ve cron temelli kalıcılık örüntüleri.

macOS: Mach-O

Mach-O LC komutları, LaunchAgents/LaunchDaemons, code signing ve notarization sinyalleri.

Bu Modülde Hedeflenen Kazanımlar

ELF ve Mach-O örneklerinde dosya kimliğini doğru çıkarıp analiz yönünü (statik/dinamik/sandbox) gerçekçi biçimde seçebilmek.
Linux’ta kalıcılık örüntülerini “artefakt + bağlam + zaman çizelgesi” bakışıyla okuyup yanlış kesinlikten kaçınabilmek.
macOS’te başlangıç öğeleri ve servis mantığını yüksek seviyede anlayarak şüpheli başlangıç zincirini kurabilmek.
Cross-platform vakalarda IOC’leri (domain/IP/URL/path gibi) bağlamlandırıp savunma ekiplerinin kullanacağı çıktıya dönüştürebilmek.
“İddia” kurmadan önce eksik kanıtı açık yazmak ve doğrulama planı üretmek.

1. ELF için temel sinyaller ve triage yaklaşımı

ELF (Executable and Linkable Format), Linux dünyasında çalıştırılabilir dosyalar ve paylaşımlı kütüphaneler için temel formattır. Triage aşamasında amaç “dosyayı sonuna kadar sökmek” değil; dosyanın kimliğini, hedef ortamını ve risk sinyallerini hızla anlayıp doğru soruları sormaktır.

1.1. Dosya kimliği: çalıştırılabilir mi, kütüphane mi, başka bir şey mi?

İlk adım, örneğin gerçekten ELF olup olmadığını ve rolünü anlamaktır: ana program mı, başka süreçler tarafından yüklenmek üzere hazırlanmış bir bileşen mi?

Çalıştırılabilir (executable) bir ELF, genellikle doğrudan süreç davranışı ve ağ aktivitesi üretme potansiyeli taşır.

Paylaşımlı kütüphane (shared object) ise çoğu zaman başka bir süreç tarafından yüklenir; tek başına “sessiz” kalabilir ve zincirin parçası olabilir.

ELF sanılıp yanlış yola sapmamak için “dosya görünümü” ile “gerçek format” ayrımı önemlidir. ELF’ler tipik olarak 7F 45 4C 46 sihirli baytlarıyla başlar; bu, kimliklendirmede hızlı bir işarettir.

Örnek: “Güncelleme yardımcı aracı” diye taşınan bir dosyanın aslında paylaşımlı kütüphane olduğu anlaşılır. Bu bulgu, “çalıştırdım davranış göremedim” sonucunu temize çekmek yerine, “hangi süreç bunu yüklemiş olabilir, hangi olay zincirinde yer alıyor?” sorularını öne çıkarır.

1.2. Mimari farkındalık: 32/64-bit, uççulluk ve ABI neden seni ilgilendirir?

ELF örnekleri çoğu zaman mimariye bağımlıdır. 32-bit/64-bit ayrımı, uççulluk (endianness) ve ABI bilgisi; örneğin hangi ortamda yürüyebileceğini ve hangi telemetriyi beklemen gerektiğini etkiler. x86_64 (sunucu/masaüstü profili) ile ARM/MIPS (IoT/embedded profili) ayrımı, “davranış neden görünmedi?” sorusunun en sık cevabıdır.

Dikkat: “Çalışmadı” sonucu, çoğu zaman “zararlı değil” anlamına gelmez; yalnızca “bu koşullarda yürütülemedi / davranış gözlenemedi” anlamına gelir. Mimari uyuşmazlığı, yanlış negatif (FN) üretmenin klasik yoludur.

1.3. Başlık, kesitler ve “triage sinyali” olarak anomaliler

Linux triage süreci genellikle başlık bilgilerinden başlar: dosyanın sınıfı (32/64-bit), uççulluğu, hedef ABI’si gibi veriler ilk çerçeveyi kurar. Ardından “normalde böyle olur mu?” diye sorduran anomaliler aranır:

Stripped binaries: Sembol tablosu/isimlendirme bilgilerinin silinmiş olması analizi zorlaştırır. Bu tek başına kötü niyet kanıtı değildir; birçok üretim derlemesinde de görülebilir. Ancak şüpheli bağlamda “neden zorlaşmış?” sorusunu hak eder.

Alışılmadık kesitler (sections): Standart dışı kesit isimleri ya da beklenmedik boyut/dağılım, örneğin paketlenmiş/korunmuş olabileceğine dair işaret verebilir. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

Yüksek entropi şüphesi: Bazı kesitlerin “aşırı rastgele” görünmesi, sıkıştırma/şifreleme gibi koruma katmanlarını düşündürür; triage’da bu, “derinleştirme gerekebilir” notudur.

1.4. Strings ve bağımlılık izleri: hüküm değil, hipotez üretmek

Orta seviye triage’da strings çıktısı, bir dosyanın “hangi dünyaya dokunduğunu” hızlıca gösterebilir:

ağ hedefleri (domain/IP/URL), yapılandırma izleri, hata mesajları, dosya yolları

indir-çalıştır benzeri davranışlarla ilişkilendirilebilecek yardımcı araç/ifade referansları

dosyanın iddia edilen kimliğiyle çelişen “anomali hissi” veren parçalar

Örnek: Bir ELF içinde <http://example.org/>... benzeri bir URL referansı ve “çalıştırılabilir izin/çalıştırma akışını çağrıştıran” ifadeler birlikte görülür. Bu, “indirip çalıştırıyor” diye kesin hüküm kurdurmaz; ama “ağ telemetrisiyle doğrulanmalı” hipotezini güçlendirir.

İpucu: ELF triage’ı çoğu zaman “kanıt üretmek”ten çok “kanıt planı kurmak”tır. Bir domain referansı gördüğünde kendine Modül 6 disiplinini hatırlat: DNS var mı, oturum var mı, bu trafik hangi süreç bağlamında?

2. Linux persistence (kalıcılık) örüntüleri

Linux’ta kalıcılık, “bir kez çalıştı ve bitti” yerine “yeniden başlatınca/oturum açınca yine gel” mantığıyla düşünülür. Savunma açısından kritik nokta, kalıcılığı tek bir bulguya bağlamak yerine başlangıç noktası + yazan süreç + zaman çizelgesi üçlüsüyle okumaktır.

2.1. Nerelerde görünür? Sınıflar üzerinden düşünmek

Linux ekosisteminde sık görülen kalıcılık sınıfları:

Zamanlanmış işler (cron jobs): Belirli aralıklarla ya da belirli saatlerde tetiklenen görevler

Servis mantığı (systemd vb.): Sistem açılışında arka planda başlayan servisler

Oturum başlangıcı dosyaları: Kullanıcı girişinde devreye giren profil/başlangıç yapılandırmaları

Eski tip başlangıç mekanizmaları (rc dosyaları): Bazı sistemlerde hâlâ etkili olabilen başlangıç tetikleyicileri

Örnek: Bir sistemde gece 03:00 civarı aynı zaman penceresinde tekrarlayan anomali gözlenir ve yapılandırma dosyalarında o saati işaret eden bir tetikleyici izi bulunur. Bu, “tek satır buldum” değil; “zaman çizelgesiyle uyumlu bir kalıcılık hipotezi” olarak raporlanmalıdır.

2.2. Gürültü–sinyal ayrımı: meşru otomasyonla karışan yerler

Linux sistemlerinde güncelleyiciler, bakım işleri ve izleme ajanları da dosya yazar, ağ trafiği üretir ve servis mantığını kullanır. Bu nedenle:

tek bir iz yerine örüntü aramak,

“bu iz hangi süreç bağlamında oluştu?” sorusunu sormak,

diğer hostlarla baseline kıyası istemek yanlış pozitifi ciddi biçimde azaltır.

Dikkat: “Kalıcılık var” cümlesini, “kalıcılık sinyali/girişimi var” ile “kalıcılık oluştu ve tetikleniyor”dan ayırmadığında savunma tarafı gereksiz sert aksiyona kayabilir. Orta seviyede değerli olan, belirsizliği doğru yönetmektir.

2.3. Kırmızı bayraklar: bağlamla güçlenen ipuçları

Bazı dizinler ve adlandırma biçimleri, özellikle şüpheli bağlamda “neden burada?” sorusunu doğurur:

geçici dizinlerde beklenmedik çalıştırılabilirler

nokta ile başlayan “gizli” dosyalar (Linux’ta nokta ile başlayan adlandırma, dosyayı gizler)

RAM tabanlı paylaşımlı bellek alanları (ör. disk üzerinde kalıcı iz bırakmadan çalıştırma eğilimi)

İpucu: “Gizli ad” tek başına suç değildir; fakat aynı zaman penceresinde servis/cron iziyle veya ağ ritmiyle birleştiğinde sinyal değeri yükselir. Triage raporunda bu birleşimi özellikle belirtmek, savunma ekibine hız kazandırır.

2.4. Rapor dili: iddia–kanıt–eksik kanıt

Linux persistence bulgularını rapora taşırken en güvenilir çerçeve:

İddia: Kalıcılık şüphesi / kalıcılık girişimi sinyali

Kanıt: Hangi mekanizmada hangi artefakt görüldü, ne zaman?

Eksik kanıt: Bunu yazan süreç net mi, yeniden başlatma/oturum sonrası tetikleniyor mu?

Bu yaklaşım, “doğrulanmadı” cümlesini bir zayıflık değil, ekipler arası netlik olarak kullanmanı sağlar.

3. Mach-O için temel kavramlar ve triage yaklaşımı

Mach-O (Mach Object), macOS’in temel yürütülebilir formatıdır. macOS tarafında triage, çoğu zaman dosyanın “normal uygulama profili” ile “anomali” arasındaki çizgide yapılır; bağlam sinyalleri burada belirleyicidir.

3.1. Universal (fat) binaries: tek dosyada iki mimari

macOS’in ayırt edici özelliklerinden biri, bir dosyanın içinde hem Intel (x86_64) hem Apple Silicon (ARM64) mimarileri için ayrı kodlar barındırabilmesidir. Bu, analiz açısından iki kritik sonuç doğurur:

“Dosyayı inceledim” derken aslında hangi mimari parçasına baktığını bilmek gerekir.

Tek bir paket içinde iki farklı davranış ihtimali (veya tek bir davranışın iki uyarlaması) düşünülmelidir.

Örnek: Aynı dosya, bir mimaride beklenmedik ağ çağrılarına işaret eden ipuçları taşırken diğer mimaride daha “sessiz” görünebilir. Triage raporu bunu “fat binary; mimari parçalar ayrı değerlendirilmelidir” şeklinde not ederek yanlış negatif riskini düşürür.

3.2. Kod imzalama ve entitlements: “beklenmeyen yetki” sinyali

macOS güvenliği kod imzalama ve yetkilendirme mantığına sıkı bağlıdır. Bir uygulamanın talep ettiği yetkiler (entitlements), her zaman tek başına hüküm vermez ama güçlü bağlam üretir.

Örnek: “Hesap makinesi” gibi sıradan bir uygulamanın kamera erişimi veya ağ dinleme benzeri yetkiler istemesi, “gerçek niyet farklı olabilir” hipotezini doğurur. Bu hipotez, süreç/ağ telemetrisi ve başlangıç zinciri kanıtlarıyla desteklenmelidir.

4. macOS başlangıç öğeleri ve servis mantığı

macOS’te kalıcılık ve otomatik başlama çoğunlukla servis/ajan mantığı üzerinden yönetilir. Orta seviye analistin hedefi, her mekanizmayı ezberlemek değil; başlangıç zincirini kurabilmektir: “ne zaman tetikleniyor, neyi başlatıyor, hangi kanıt eksik?”

4.1. LaunchAgents ve LaunchDaemons: hangi koşulda devreye girer?

LaunchAgents genellikle kullanıcı oturum açtığında çalışan görevlerdir ve kullanıcı alanında konumlanır.

LaunchDaemons sistem açılışında, oturum açılmadan önce devreye girebilen servis mantığını temsil eder ve daha yüksek yetki bağlamlarıyla ilişkilendirilebilir.

Bu yapıların konfigürasyonu çoğu zaman .plist (Property List) dosyalarıyla tutulur; plist içinde “ne çalışacak, hangi parametrelerle, hangi tetikleyiciyle” gibi bilgiler yer alır.

Dikkat: Bir .plist’te “yükleme anında çalıştır” anlamı taşıyan bir tetikleyici ayarı görmek, “kalıcılık kesin kuruldu” demek değildir. Bu tanımın gerçekten tetiklenip tetiklenmediğini ve hangi süreç zincirini doğurduğunu kanıtlamak gerekir.

4.2. “Başlangıç noktası” ile “çalışan süreç” arasındaki köprü

Savunma açısından kritik soru şudur: Başlangıç kaydı hangi bileşeni başlatıyor ve bu bileşen gerçekten yürümüş mü?

Başlangıç kaydı: bir artefakt

Çalışan süreç: davranış kanıtı

Bu ikisi arasındaki ilişki: bağlam kanıtı

İpucu: Köprüyü kuramıyorsan raporu “zayıf” yapmaya çalışma; tam tersine güçlüleştir: “başlangıç tanımı gözlendi; yürütme kanıtı şu telemetriyle doğrulanmalıdır” diye açık yaz. Bu, yanlış kesinliğin en hızlı panzehiridir.

4.3. Cross-platform raporlama: aynı dili korumak

Linux ve macOS’te kalıcılık mekanizmaları farklı görünür; ama rapor dili aynı omurgayı taşıyabilir:

Artefakt: başlangıç noktası / tanım / iz

Bağlam: hangi kullanıcı/süreç/zaman penceresi

Davranış: tetikleniyor mu, tekrar ediyor mu, ritim var mı

Aksiyon önerisi: avcılık mı, kapsam taraması mı, hedefli engelleme mi —kanıt gücüyle orantılı

Bu yaklaşım, platformlar arası vakalarda ekiplerin aynı “kanıt dilini” konuşmasını sağlar.

Bu platformlardaki karmaşık sistem çağrısı manipülasyonları ve çekirdek (kernel) seviyesindeki gizlenme yöntemleri, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

Terimler Sözlüğü

Terim	Açıklama
Cross-Platform	Farklı işletim sistemleri/platformlar arası (Windows/Linux/macOS gibi)
Triage	Hızlı ön inceleme ve önceliklendirme süreci
ELF	Linux/Unix dünyasında yürütülebilir ve kütüphane formatı (Executable and Linkable Format)
Mach-O	macOS’te kullanılan yürütülebilir format (Mach Object)
Universal/Fat Binary	Tek dosyada birden fazla mimari için kod barındıran Mach-O yapısı
Architecture	Mimari; işlemci ailesi/komut seti (x86_64, ARM64 vb.)
Endianness	Uççulluk; çok baytlı verinin bellekteki sıralanma düzeni
ABI	Uygulama ile işletim sistemi arasındaki düşük seviyeli arayüz (Application Binary Interface)
Stripped	Sembolleri/simge bilgileri silinmiş ikili; analizi zorlaştırabilir
Section	İkili dosya içindeki kesit; kod/veri bölümlerinin mantıksal ayrımı
Section	macOS’te uygulamanın talep ettiği yetkiler/kapasiteler
Plist	macOS’te ayarların saklandığı XML tabanlı dosya formatı (Property List)
Persistence	Kalıcılık; yeniden başlatma/oturum sonrası da devreye girebilme
Baseline	Normal sistem davranışı profili; gürültü-sinyal ayrımına yardım eder
False Positive (FP)	Yanlış pozitif; zararsız bir şeyin zararlı sanılması
False Negative (FN)	Yanlış negatif; zararlı davranışın görülmemesi/temiz sanılması

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)Bir ELF örneği analiz ortamında hiç çalışmıyor. En doğru yorum hangisidir?

A) Kesin temizdir

B) Mimari/ortam uyumsuzluğu olabilir; “bu koşullarda belirgin davranış gözlenmedi” diye raporlanmalıdır

C) Sandbox bozuk demektir; rapor atılmalıdır

D) ELF dosyaları zaten davranış göstermez

E) Sadece dosya adı yeterlidir

Doğru: B
Gerekçe: Çalışmama FN kaynağı olabilir; rapor dilini “gözlenmedi” düzeyinde tutmak gerekir. A/D aşırı genelleme; C kanıtsız; E yetersiz.

2)Bir ELF dosyasında “stripped” sinyali en doğru nasıl yorumlanır?

A) Kesin zararlıdır

B) Kesin paketlenmiştir

C) Analizi zorlaştıran bir işarettir; meşru derlemelerde de görülebileceği için bağlamla değerlendirilmelidir

D) Sadece 32-bit çalışır

E) İnternetsiz çalışamaz

Doğru: C
Gerekçe: Stripped tek başına niyet kanıtı değildir; ancak şüpheli bağlamda risk sinyali olabilir. A/B kesinlik içerir; D/E alakasız.

3)Linux’ta periyodik (ritmik) ağ trafiği görülmesi triage açısından neyi de düşündürmelidir?

A) Yalnızca kullanıcı hatasını

B) Zamanlayıcı tabanlı kalıcılık olasılığını ve zaman çizelgesi korelasyonunu

C) Kesin veri sızıntısını

D) Dosyanın imzalı olduğunu

E) Donanım arızasını

Doğru: B
Gerekçe: Ritim, zamanlayıcı/persistence hipotezini güçlendirir ama “kesin” değildir; korelasyon gerekir. C aşırı kesin; diğerleri ilgisiz.

4)Linux persistence bulgusunu savunma ekiplerine en sağlıklı sunan çerçeve hangisidir?

A) Dosya adı + tahmin + sert bloklama

B) Artefakt + bağlam + zaman çizelgesi

C) Sadece “kalıcılık var” cümlesi

D) Sadece IOC listesi

E) Skor + verdict

Doğru: B
Gerekçe: Kalıcılık iddiası iz-bağlam-zamanla taşınır; diğerleri eksik veya aşırı yorum.

5)/dev/shm gibi RAM tabanlı alanların analist için anlamı en doğru hangisidir?

A) Sadece ekran kartı verisi tutar

B) Diskte kalıcı iz bırakmadan geçici çalışma/saklama eğilimine işaret edebilir; bağlamla güçlendirilmelidir

C) İnternet hızını ölçer

D) Sadece tarayıcı kullanır

E) Dosyaları otomatik şifreler

Doğru: B
Gerekçe: RAM tabanlı alanlar iz sürmeyi zorlaştırabilir; yine de tek başına hüküm değildir. Diğerleri yanlış/ilgisiz.

6)macOS’te “Universal/Fat Binary” yapısının analize getirdiği temel zorluk nedir?

A) Dosyanın çok küçük olması

B) Aynı dosyada birden fazla mimari parça bulunduğu için her mimari parçasının ayrı değerlendirilme ihtiyacı

C) Sadece tarayıcıda çalışması

D) Dosya adının değiştirilememesi

E) Sadece gece çalışması

Doğru: B
Gerekçe: Tek dosya içinde iki mimari kanat bulunabilir; triage yanlış mimariyi incelerse FN riski artar.

7)Kod imzalama ve entitlements triage’da en doğru nasıl kullanılır?

A) Tek başına nihai karar için yeterlidir

B) Görsel bir detaydır, dikkate alınmaz

C) Bağlam üretir: beklenmeyen yetkiler hipotez oluşturur, telemetriyle doğrulanmalıdır

D) Sadece Linux için geçerlidir

E) Sadece hash üretmek içindir

Doğru: C
Gerekçe: Yetkiler “niyet” için ipucu verir ama kanıt yerine geçmez. A aşırı kesin; diğerleri yanlış.

8)~/Library/LaunchAgents altında şüpheli bir .plist bulunması en doğrudan neyi düşündürür?

A) Dosyanın kendini sildiğini

B) Kullanıcı oturum açılışında otomatik çalışmayı hedefleyen bir başlangıç kaydı olabileceğini

C) Sistem dosyalarının kesin şifrelendiğini

D) Tarayıcının güncellendiğini

E) Kullanıcının şifresinin değiştiğini

Doğru: B
Gerekçe: LaunchAgents kullanıcı oturumu tetikleyicisiyle ilişkilidir. C/D/E doğrudan çıkarım değildir.

9) Bir .plist içinde “yükleme anında tetiklenme”yi çağrıştıran ayar görülüyorsa rapor dili nasıl olmalıdır?

A) Kesin kalıcılık kurdu

B) Başlangıç tanımı gözlendi; tetiklenme ve yürütme kanıtı süreç/zaman telemetrisiyle doğrulanmalıdır

C) Plist varsa zararlı yoktur

D) Sadece IOC çıkarılır, diğerleri atılır

E) Hiç yazmamak en iyisi

Doğru: B
Gerekçe: Artefakt-davranış ayrımı korunur; eksik kanıt açık yazılır. A/C/D/E hatalı yaklaşım.

10)Strings çıktısında /etc/passwd ifadesi ile 203.0.113.5 gibi bir IP referansı birlikte görülürse en öncelikli hipotez hangisidir?

A) Video oynatıcıdır

B) Hassas sistem verisine erişim ve dışarıyla ilişkilendirme olasılığı; ağ telemetrisi ve süreç bağlamıyla doğrulama gerektirir

C) Sistem saatini günceller

D) Dosya bozuk demektir

E) Sadece belirli bir dağıtımda çalışır

Doğru: B
Gerekçe: Hassas dosya yolu + ağ hedefi birlikte güçlü bir statik sinyal oluşturur; yine de “kesin sızıntı” denmez, doğrulama planı gerekir.

Bu Modülde Kazanılan Yetkinlikler

ELF ve Mach-O örneklerinde kimliklendirme yapıp doğru analiz yönünü seçmeyi
ELF başlık/mimari ve “stripped / alışılmadık kesit” gibi sinyalleri bağlamla yorumlamayı
Strings ve bağımlılık izlerini hükme değil hipoteze dönüştürmeyi; eksik kanıtı açık yazmayı
Linux’ta cron/servis/başlangıç dosyaları gibi kalıcılık örüntülerini zaman çizelgesiyle birleştirerek okumayı
macOS’te universal binary, kod imzalama/entitlements ve LaunchAgents/LaunchDaemons mantığıyla başlangıç zinciri kurmayı
Cross-platform raporlamada artefakt-bağlam-davranış-aksiyon omurgasını korumayı

MODÜL 9 — Tespit Mantığı ve Kural Düşüncesi

Analizde elde edilen ham bulgular (dosya yolları, alan adları, IP’ler, kod içi izler, log örüntüleri) tek başına “bilgi”dir; savunma açısından değer kazanması, bu bilgiyi sahada çalışacak tutarlı kurallara ve paylaşılabilir paketlere dönüştürdüğünde başlar. Bu modülde, IOC’leri standart bir dille paketlemeyi, dosya/binary odaklı tespitte YARA düşüncesini, log/olay odaklı tespitte Sigma yaklaşımını ve en kritik gerçekliği—yanlış alarmları (FP) yönetmeyi—tek bir disiplin altında birleştireceksin. Hedef, bir örneği “çözmekten” öte, benzerlerinin yeniden içeri girmesini zorlaştıran kurumsal “bağışıklık refleksi” üretmektir.

Modül Teması

YARA

Dosya içeriği üzerinde örüntü eşleme; FP riskini iyi tartılan koşullarla sınırlamak şart.

Sigma

Log tabanlı tespit dilinin SIEM-bağımsız yazımı; davranış sorularını standartlaştırır.

Pyramid of Pain

Hash/IP gibi kolay değiştirilenler yerine TTP odaklı tespit; saldırgana en pahalısı budur.

Bu Modülde Hedeflenen Kazanımlar

Analiz çıktısını sahaya uygun bir IOC paketi haline getirmek ve bu paketin hangi ekip tarafından nasıl kullanılacağını öngörebilmek
Tehdit istihbaratını paylaşılabilir kılan STIX/TAXII yaklaşımını kavramsal olarak doğru konumlandırmak
YARA’da temel kural tasarımını “az ama ayırt edici sinyal” ilkesiyle kurup, bakımı yapılabilir tespit çıktısı üretebilmek
Log tabanlı tespitte Sigma mantığını anlayıp, “hangi log nereden gelir?” sorusuna göre kural düşünebilmek
FP/FN dengesini yönetmek, alert fatigue riskini azaltmak ve kural yaşam döngüsünü (tuning) planlamak

1. IOC paketleme standardı

IOC (Indicator of Compromise), bir ihlalin veya şüpheli faaliyetin izini temsil eden göstergedir: domain, IP, URL, dosya yolu, hash, registry yolu, mutex adı, kullanıcı ajanı gibi. Ancak pratikte IOC’ler “tek tek değerler” gibi ele alınırsa, kurum içinde farklı ekipler aynı şeyi farklı dillerle yazar; bu da otomasyonun ve korelasyonun önünü keser.

Bir IOC paketleme standardı, IOC’yi yalnızca “değer” olarak değil; bağlam + kaynak + zaman penceresi + güven düzeyi ile birlikte taşınabilir hale getirir. Böylece firewall, EDR, SIEM gibi farklı ürünler aynı veriyle tutarlı aksiyon alabilir; manuel kopyala-yapıştır azalır, müdahale hızı artar.

1.1. IOC paketi neden “liste” değildir?

Sadece IOC listesi vermek genellikle şu kritik soruları cevapsız bırakır:

IOC nereden çıktı? (statik bulgu mu, dinamik telemetri mi, sandbox mı?)

Hangi zaman aralığında görüldü? (tek sefer mi, periyodik mi?)

Hangi süreç/olay üretti? (parent-child ilişkisi, kullanıcı bağlamı, host rolü)

Ne kadar güveniyoruz? (gözlendi / doğrulandı / doğrulanmadı ayrımı)

Bu yüzden IOC paketi, savunma tarafında bloklama, avcılık (hunt), kapsam taraması ve izleme kararlarını doğrudan etkiler.

Örnek: Bir raporda example.net alan adı geçiyor. Eğer bunun yalnızca dosya içindeki bir metin referansı olarak görüldüğü, ağ trafiğinde doğrulanmadığı ve hangi süreçle ilişkili olduğunun belirsiz olduğu yazılmıyorsa; bir ekip hemen engellemeye giderken başka bir ekip “kanıt zayıf” diyerek yok sayabilir. Aynı veri, bağlam eksikliği yüzünden iki uç karara sürükler.

1.2. Asgari IOC paketi alanları

Kurumdan kuruma format değişir; ama iyi bir paket, en azından şu bilgileri taşır:

Gösterge türü (domain / IP / URL / path / hash / registry yolu / süreç adı vb.)

Değer (value)

Kaynak (statik, dinamik telemetri, sandbox raporu…)

Zaman penceresi (ilk görülme / son görülme mantığı)

Bağlam (hangi süreç, hangi kullanıcı, hangi host rolü, hangi olay zinciri)

Durum (gözlendi / doğrulandı / doğrulanmadı)

Güven düzeyi (düşük/orta/yüksek gibi; kurum diline göre)

Önerilen kullanım (izleme mi, avcılık mı, bloklama adayı mı?)

Dikkat: “Güven düzeyi” ile “ciddiyet” aynı şey değildir. Bazı bulgular yüksek etki riski taşır ama kanıt gücü düşüktür; burada doğru refleks genellikle bloklama değil, hedefli avcılık ve doğrulamadır.

1.3. STIX ve TAXII: ortak dil ve taşınabilirlik

Tehdit istihbaratının “ortak dili” olarak anılan standartlar, IOC paketlerini ürünler arası taşınabilir hale getirir:

STIX (Structured Threat Information eXpression): tehdit istihbaratını yapılandırılmış şekilde ifade etmeyi amaçlayan bir standarttır (modern kullanımda çoğunlukla JSON temsilleriyle anılır). “Kim, neyi, nasıl yaptı?” gibi öğeleri bir modelle anlatmayı kolaylaştırır.

TAXII (Trusted Automated eXchange of Intelligence Information): bu tür istihbaratın sistemler arasında güvenli ve otomatik paylaşımına odaklanan bir aktarım yaklaşımıdır.

Örnek: Bir kampanyada görülen 198.51.100.42 IP’si ile şüpheli bir yürütülebilir dosyanın özeti (hash) birlikte paketlenip, kurum içindeki farklı güvenlik katmanlarına hızlıca dağıtılabilir; böylece aynı göstergeler farklı noktalarda aynı anlamla karşılanır.

1.4. IOA ve IOC’yi doğru yere koymak

IOC daha çok “iz” taşır; IOA (Indicator of Attack) ise “davranış” anlatır. Aynı saldırgan hash’i saniyeler içinde değiştirebilir; ama süreç zinciri, log örüntüsü ve davranış bağı daha kalıcı olabilir. Bu fark, tespit stratejisini belirler: bazı durumlarda dosya imzası yeterli olurken, bazı durumlarda davranışsal sinyale ihtiyaç vardır.

İpucu: Bir göstergenin ne kadar “kalıcı” olduğunu düşünmek için “Pyramid of Pain” fikri işe yarar: hash’ler genelde en kolay değişenlerdendir; davranış örüntüleri ve TTP’ler saldırgan için daha maliyetli değişir. Bu yüzden yalnız hash’e yaslanan savunma çoğu zaman kısa ömürlü olur.

2. YARA mantığı ve temel kural tasarımı

YARA, dosya ve süreçleri içeriklerindeki belirli izler üzerinden tanımlamak için kullanılan bir kural yaklaşımıdır. En çok “dosya taraması” ile anılsa da, uygun ortamlarda bellek üzerinde eşleşme mantığı kurmak için de kullanılabilir. Buradaki amaç, “mükemmel yakala-bitir” kuralı yazmak değil; yanlış pozitif üretmeyen, bakımı yapılabilir bir tespit dili geliştirmektir.

2.1. YARA ne zaman doğru araçtır?

YARA genellikle şu senaryolarda güçlüdür:

Statik analizde ayırt edici string izleri veya karakteristik byte örüntüleri varsa

Kurum içinde dosya artefaktı dolaşıyorsa (e-posta eki, indirilen dosya, disk artefaktı)

Benzer varyantlar bekleniyorsa ve ortak bir “imza çekirdeği” kurulabiliyorsa

Buna karşılık, içerik izleri çok kolay değişiyorsa veya örnekler her seferinde bambaşka görünüyorsa, log/olay korelasyonu daha verimli olabilir.

2.2. Kural anatomisi: meta, strings, condition

Temel YARA düşüncesi üç parçaya dayanır:

meta: kuralın amacı, kapsamı, yazarı, sürüm mantığı (kuralın “kimliği”)

strings: aranacak içerik izleri (metin dizileri veya hex (bayt) örüntüleri)

condition: hangi kombinasyonda eşleşme sayılacağı (tek iz mi, birlikte mi, dosya türü filtresi var mı?)

Örnek: Bir dosyada hem özgün bir protokol ifadesi hem de belirli bir byte dizisi birlikte bulunuyorsa, iki sinyalin birlikte aranması FP’yi ciddi biçimde düşürür. Tek bir yaygın kelimeyi aramak, kalabalık bir şehirde “kırmızı araba gördüm” diyerek hedefi bulmaya çalışmak gibidir.

Aşağıdaki küçük parça, “birden fazla sinyali birlikte arama” fikrini göstermeye yarar:

rule Tespit_Ornek { meta: description = "Belirli bir örüntü kombinasyonu" strings: \$a = "secret_c2_protocol" \$b = { 4D 5A 90 00 } condition: \$a and \$b }

Dikkat: Çok kısa veya çok yaygın string’ler (“Windows”, “System32”, “update”, “error”, “config” gibi) meşru dosyalarda da geçer. Bu tür izleri tek başına kullanmak, kuralı gürültü üretir hale getirir.

2.3. Kapsamı doğru daraltmak: dosya türü ve esneklik dengesi

Kuralın yanlış dosya türlerinde tetiklenmesini engellemek için “format filtresi” düşüncesi önemlidir. Örneğin Windows PE dosyaları için bilinen başlık imzasına (MZ) dayalı bir kontrol fikri, kuralın kapsamını daha anlamlı hale getirebilir. Benzer şekilde, metin eşleşmelerinde büyük/küçük harf duyarlılığı bazen FP’yi etkilemezken, bazen kaçan eşleşmeleri azaltabilir; bu nedenle “esneklik” kararları kuralın kullanım yerine göre verilmelidir.

Bu noktada “wildcard/joker” yaklaşımı da karşına çıkar: değişken olabilecek baytlar için esneklik sağlamak kuralın kapsamını genişletebilir; ancak gereğinden fazla esneklik FP riskini büyütür.

İpucu: YARA’da sağlam yaklaşım, “az ama ayırt edici sinyal” + “birleşik koşul” kurmaktır. Kuralını bir alarm makinesine değil, anlamlı vaka seçicisine dönüştürmeye çalış.

3. Log tabanlı tespit yaklaşımı ve Sigma mantığı

YARA daha çok dosyaya bakar; log tabanlı tespit ise sistemin ürettiği olay kayıtları üzerinden davranışı yakalamaya çalışır. Dosya sistemi üzerinde iz bırakmayan bazı saldırı türlerinde (fileless eğilimli davranışlar gibi) loglar, geriye kalan en güçlü kanıtlardan biri olabilir.

Sigma, bu log sinyallerini SIEM ürünlerinden bağımsız bir formatla ifade etmeyi amaçlayan bir kural yaklaşımı olarak düşünülür; bu nedenle pratikte “loglar için YARA” benzetmesiyle anılır.

3.1. Log tespiti neyi iyi yakalar?

Beklenmedik süreç zincirleri (alışılmadık parent-child ilişkileri)

Ritimli davranış (periyodik DNS sorguları, tekrarlı bağlantı girişimleri)

Kalıcılık belirtileri (servis/başlangıç öğesi değişiklikleri)

Aynı örüntünün farklı makinelerde tekrar etmesi (kampanya sinyali)

Buradaki kritik soru şudur: “Bu tespiti hangi log kaynağı destekler?” Log yoksa, kural “kâğıt üzerinde doğru” olsa bile sahada kör kalır.

3.2. “Alan + koşul + bağlam”: Sigma düşüncesinin omurgası

Sigma ile düşünürken üç parçayı birlikte ararsın:

Hangi olay türü? (ör. süreç oluşturma, DNS sorgusu, proxy isteği)

Hangi alanlar anlamlı? (process name, command line, parent process, destination domain gibi)

Eşik/korelasyon var mı? (tek olay mı, belirli sürede N tekrar mı?)

Örnek: Bir ortamda 203.0.113.20 hedefine bağlantı girişimi tek sefer görülürse “aday” kalabilir; fakat aynı hostta belirli aralıklarla tekrar edip aynı süreç bağlamına bağlanıyorsa, avcılık önceliği artar.

Örnek: Bir uç noktada powershell.exe çalışıyor ve komut satırında -EncodedCommand benzeri bir parametre görünüyorsa, bu her zaman ihlal demek değildir; ama normal dışı bir davranış ihtimalini yükseltir. Bu noktada kuralın gücü, “hangi kullanıcı bağlamında”, “hangi parent süreçten”, “hangi zaman penceresinde” sorularını da içine aldığında artar.

3.3. Raporla köprü kurmak: kural tek başına çıktı değildir

Orta seviyede önemli kırılım şudur: Sigma/YARA kuralı “çıktı” değil, çıktının bir parçasıdır. Savunma için şu sorulara cevap vermeyen kural, sahada yorucu olur:

Bu kural neyi yakalar, neyi yakalamaz?

Hangi log kaynağı olmadan çalışmaz?

Beklenen FP kaynakları neler?

Alarm gelirse ilk bakılacak kanıtlar hangileri?

İpucu: “En iyi kural” en çok alarm üreten değil, en az gürültüyle en anlamlı vakayı yakalayandır. Bir kuralın başarısı çoğu zaman gereksiz yere bağırmamasında saklıdır.

4. Tespitlerde hata kaynakları ve FP azaltma

Mükemmel kural yoktur. Bir kuralın hata yapma potansiyeli vardır ve analistin görevi bunu “inkâr etmek” değil, yönetmektir.

False Positive (FP): temiz bir davranışın/artefaktın zararlı sanılması

False Negative (FN): zararlı davranışın kaçırılması

True Positive (TP): gerçek zararlının doğru yakalanması

FP’lerin en büyük yan etkisi “alert fatigue”tir: çok sayıda asılsız alarm, ekiplerin gerçek alarmı kaçırmasına zemin hazırlar.

4.1. FP’nin tipik kaynakları

Meşru yazılımların benzer davranışı (güncelleyiciler, yönetim ajanları, izleme araçları)

Ortamın doğal gürültüsü (bakım pencereleri, toplu güncellemeler, normal proxy/DNS trafiği)

Eksik bağlam (sadece domain’e bakıp süreç kimliğini görmemek)

Aşırı genel kural (tek kelime/tek olay)

Dönemsel değişimler (kampanya dönemleri, yeni sürüm dağıtımları)

4.2. FP azaltma: sertlik değil, netlik

FP azaltmanın sağlıklı yolları:

Bağlam eklemek: gösterge + süreç bağlamı + zaman penceresi

Eşik ve ritim: tek olay yerine örüntü/tekrar aramak

Dışlamalar (exclusions / allowlist): bilinen meşru bileşenleri kontrollü dışlamak

Korelasyon: tek sinyal yerine birden çok sinyali birlikte değerlendirmek

Kademeli aksiyon: “izleme/avcılık adayı” ile “bloklama adayı” ayrımını net yazmak

Örnek: Bir kural example.com trafiğini yakalıyor diye alarm üretiyorsa, ilk soru “hangi süreç ve ne zaman?” olmalıdır. Aynı domain tarayıcıdan görülüyorsa sıradan olabilir; beklenmedik bir yardımcı süreçten ritmik gidiyorsa anlam değişir.

Dikkat: FP’yi sıfıra indirme hedefi çoğu zaman tehlikelidir; kuralı aşırı daraltıp gerçek vakaları kaçırmaya (FN) iter. Amaç, FP’yi yönetilebilir düzeye çekmek ve alarmın anlamını netleştirmektir.

4.3. Kural yaşam döngüsü: yazmak değil, yaşatmak

Kural düşüncesi tek seferlik bir iş değildir:

İlk sürüm: kontrollü kapsam, net amaç

İzleme: hangi ekip ne kadar yük alıyor, alarm kalitesi nasıl?

İyileştirme (tuning): FP kaynakları görünür oldukça bağlam/eşik/dışlama eklemek

Dokümantasyon: kuralın niyeti, sınırları ve değişiklik notları kaybolmasın

Bazı kurumlarda, kuralı üretime almadan önce “izleme modunda” bir süre çalıştırıp (engellemeden sadece görünürlük sağlayarak) FP oranını gözlemlemek, alarm yorgunluğunu ciddi biçimde azaltır.

Terimler Sözlüğü

Terim	Açıklama
IOC (Indicator of Compromise)	İhlal göstergesi; şüpheli/zararlı aktiviteyle ilişkili olabilecek statik iz
IOA (Indicator of Attack)	Saldırı göstergesi; davranışsal örüntüye dayalı işaret
STIX	Tehdit istihbaratını yapılandırılmış bir modelle ifade etmeye yarayan standart yaklaşım
TAXII	Tehdit istihbaratını sistemler arasında otomatik ve güvenli paylaşmaya odaklanan aktarım yaklaşımı
Normalizasyon	IOC yazımını standardize etme; korelasyon ve otomasyon için tutarlılık
Zenginleştirme (Enrichment)	IOC’ye bağlam ekleme; süreç/zaman/örüntü ilişkisini belirtme
Güven düzeyi (Confidence)	Bulgunun kanıt gücünü ifade eden ölçü; aksiyonu kalibre eder
YARA	Dosya/süreç içeriğinde string/byte örüntüsü eşlemesiyle tespit mantığı kuran kural yaklaşımı
Hex pattern	Dosya içindeki onaltılık bayt dizisi; içerik tabanlı eşleşme için kullanılır
Wildcard / Joker	Değişken olabilecek kısımlarda esneklik sağlayan eşleşme fikri; FP riskini artırabilir
Sigma	Log kaynakları üzerinde SIEM’den bağımsız tespit kuralı yaklaşımı
FP (False Positive)	Yanlış pozitif; temiz davranışın zararlı sanılması
FN (False Negative)	Yanlış negatif; zararlının kaçırılması
TP (True Positive)	Doğru pozitif; gerçek zararlının doğru yakalanması
Alert fatigue	Uyarı yorgunluğu; çok FP nedeniyle gerçek olayların gözden kaçması

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)IOC paketleme standardının en temel faydası hangisidir?

A) IOC’leri daha uzun listeler halinde üretmek

B) IOC’leri bağlam, kaynak, zaman penceresi ve güven düzeyiyle taşınabilir hale getirmek

C) Her IOC’yi otomatik olarak kesin zararlı ilan etmek

D) Sadece hash’lere odaklanmak

E) Sandbox’ı devre dışı bırakmak

Doğru: B
Gerekçe: Standart, IOC’yi “değer” olmaktan çıkarıp operasyonel karara bağlayan alanlarla paketler. Diğer seçenekler ya eksik ya da hatalı yaklaşımdır.

2)STIX ve TAXII birlikte düşünüldüğünde en doğru rol dağılımı hangisidir?

A) STIX taşır, TAXII içerik üretir

B) STIX içerik/ifade modeline; TAXII paylaşım/aktarıma odaklanır

C) İkisi de sadece hash taşır

D) İkisi de sadece antivirüs imzasıdır

E) Sadece firewall’larda çalışır

Doğru: B
Gerekçe: STIX yapılandırılmış ifade/modelleme fikrini, TAXII ise sistemler arası otomatik paylaşım yaklaşımını temsil eder.

3)“Güven düzeyi” ile “ciddiyet” arasındaki en doğru ilişki hangisidir?

A) Her zaman aynıdır

B) Güven düzeyi kanıt gücünü; ciddiyet ise olası etki/riski anlatabilir

C) Güven düzeyi sadece log tespitlerinde olur

D) Ciddiyet sadece hash IOC’lerinde olur

E) Güven düzeyi IOC uzunluğuna göre belirlenir

Doğru: B
Gerekçe: Kanıt gücü düşük olup etkisi yüksek görünen bulgular olabilir; bu durumda doğru aksiyon çoğunlukla hedefli doğrulama/avcılıktır.

4)YARA kuralında FP riskini en çok artıran hata hangisidir?

A) Birden fazla ayırt edici sinyali birlikte şart koşmak

B) Meta alanında amaç ve kapsamı açık yazmak

C) Çok genel ve yaygın bir string’i tek başına eşleşme şartı yapmak

D) Kuralın sürüm notlarını tutmak

E) Kuralın nerede çalışacağını düşünmek

Doğru: C
Gerekçe: Yaygın tek bir string, meşru dosyaları da yakalar. A/B/D/E kural kalitesini artırır.

5)Aşağıdakilerden hangisi YARA’yı “doğru konumlandıran” ifadedir?

A) YARA yalnız saldırı geliştirmek için kullanılır

B) Dosya/süreç içeriğinde eşleşme mantığı kurarak tespit üretmeye yarar

C) YARA yalnızca ağ trafiğini analiz eder

D) YARA yalnız sandbox raporu okur

E) YARA sadece şifre çözme aracıdır

Doğru: B
Gerekçe: YARA içerik tabanlı tespit mantığıdır; savunma odaklı kullanımı tespit üretmeye hizmet eder.

6)Sigma yaklaşımının “kritik sorusu” hangisidir?

A) Kuralın kaç sayfa olduğu

B) Bu tespiti hangi log kaynağının ve hangi alanların desteklediği

C) Kuralın font seçimi

D) IOC’lerin alfabetik sırası

E) Dosya ikonunun türü

Doğru: B
Gerekçe: Log kaynağı/alan yoksa tespit sahada çalışmaz. Diğer seçenekler operasyonel değeri olmayan ölçütlerdir.

7)“Davranışsal tespit” örneği hangisine daha yakındır?

A) Dosyanın SHA-256 özetine bakmak

B) Dosya adında “virus” kelimesi geçmesini kontrol etmek

C) Loglarda bir sürecin alışılmadık parent zinciriyle başlatıldığını görmek

D) Dosya boyutunu kontrol etmek

E) İkonun Word gibi görünmesi

Doğru: C
Gerekçe: Davranışsal tespit, dosyanın kimliğinden çok sistem üzerindeki eylem örüntüsünü yakalar.

8)“Pyramid of Pain” fikrine göre saldırganın en kolay değiştirebildiği göstergeler genellikle hangisidir?

A) TTP’ler

B) Araç ekosistemi

C) Davranış örüntüleri

D) Hash değerleri

E) Operatör alışkanlıkları

Doğru: D
Gerekçe: Hash’ler küçük bir değişiklikle farklılaşır; bu yüzden tek başına hash’e yaslanan tespitler kolay aşınır.

9)“Alert fatigue” neden gerçek bir güvenlik riskidir?

A) Sadece internet faturasını artırdığı için

B) Çok FP üreterek analistlerin gerçek saldırıları önemsememesine veya kaçırmasına yol açabildiği için

C) Sadece oyun oynayan kullanıcıları etkilediği için

D) Antivirüsü otomatik kapattığı için

E) Yalnızca yazım hatalarından kaynaklandığı için

Doğru: B
Gerekçe: Sürekli yanlış alarmlar, dikkati ve reaksiyon kalitesini düşürür; gerçek vakalar gözden kaçabilir.

10)FP’yi azaltmanın “sağlıklı” yolu aşağıdakilerden hangisine daha yakındır?

A) Tek bir domain’e bakıp doğrudan bloklama önermek

B) Gösterge + süreç bağlamı + zaman penceresi/örüntü gibi birleşik sinyaller aramak

C) Eksik kanıtı rapordan silmek

D) Her alarmı kesin ihlal diye işaretlemek

E) Kural amacını belirsiz bırakmak

Doğru: B
Gerekçe: Bağlam ve örüntü eklemek FP’yi düşürür; A/D aşırı sert, C şeffaflığı azaltır, E bakım ve güveni düşürür.

Bu Modülde Kazanılan Yetkinlikler

IOC’nin “değer” değil, bağlam + kaynak + zaman penceresi + güven ile taşınması gerektiğini
STIX/TAXII yaklaşımının, istihbaratı ürünler arası paylaşılabilir hale getiren ortak dil fikrini desteklediğini
YARA’da güvenilir tespit için “az ama ayırt edici sinyal” ve birleşik koşul düşüncesinin kritik olduğunu
Sigma mantığında doğru log kaynağı/alan olmadan tespitin sahada çalışmayacağını
FP/FN dengesini yönetmenin ve alert fatigue’i azaltmanın kural disiplininin parçası olduğunu
Kural yazmanın değil, kuralı yaşatmanın (izleme + tuning + dokümantasyon) savunma kapasitesini büyüttüğünü

MODÜL 10 — Mobile ve IoT Malware Tanıtımı

Masaüstü odaklı “dosya + süreç” refleksini, artık cebimizde ve ev/ofis ağlarımızda yaşayan iki geniş alana taşıyoruz: Android uygulamaları ve IoT cihazları. Bu modülün odağı tersine mühendislik derinliği değil; triage disipliniyle doğru sinyali görmek, eksik kanıtı fark etmek ve savunma ekiplerinin sahada kullanabileceği IOC + rapor çıktısı üretmek.

Modül Teması

Android Triage

APK bileşenleri, izin modeli, manifest sinyalleri ve dinamik ağ örüntüsü.

Mimari (ARM/MIPS)

IoT örneklerinde mimari farkındalık triage’ın ilk filtresidir.

Firmware

İmaj bileşenleri, dosya sistemi izleri, init/systemd ve cron tabanlı kalıcılık örüntüleri.

Bu Modülde Hedeflenen Kazanımlar

Mobil (Android) ve IoT tehdit türlerini, sahada sık görülen davranış örüntüleri üzerinden ayırt etmek.
Bir APK’yı “içeriden” okumadan önce, paket yapısı + izin modeli üzerinden risk sinyali çıkarmak.
Statik bulgulardan “kesin hüküm” yerine kanıt gücü ve bağlam diliyle sonuç üretmek.
Basit dinamik gözlemle mobil ağ davranışında ritim/örüntü yakalayıp güvenilir IOC üretmek.
IoT tarafında mimari farkındalıkla triage yapıp kalıcılık + firmware artefaktlarını savunma diline çevirmek.

1. Mobile (Android odaklı)

1.1. Mobil tehdit türleri ve yaygın örüntüler

Mobil zararlılar çoğu zaman “tek hamlede büyük yıkım” yerine günlük kullanımın içine karışan küçük adımlarla çalışır: kullanıcıyı kandırma, izin toplama, arka planda veri toplama, reklam gelirini suistimal etme veya kurumsal kimlik bilgilerini ele geçirme gibi.

Sahada sık karşılaşılan sınıflar:

Trojan (Truva atı): Masum uygulama gibi görünür, arka planda istenmeyen iş yapar.

Spyware: Rehber, SMS, konum, bildirim, ekran içeriği gibi verileri izinsiz toplayabilir.

Banking Trojan / Banker: Bankacılık uygulamalarını hedefler; sahte ekran (overlay) veya oturum yakalama gibi davranışlar gösterebilir.

Adware: Aşırı reklam, agresif yönlendirme, yoğun izleme ve cihaz deneyimini bozan davranışlarla öne çıkar.

Premium SMS / Dialer: Kullanıcının haberi olmadan ücretli SMS/servis etkileşimi gibi maliyet doğurabilecek aksiyonlara yönelebilir.

Mobil ransomware: Kilitleme/şifreleme senaryoları görülebilir; ancak mobilde davranışlar masaüstüne göre farklılaşır.

Risk sinyali okurken tekrar tekrar karşına çıkacak örüntüler:

İşlevle uyumsuz “tehlikeli izin” talebi (tek başına ihlal değil; öncelik sinyali)

Arka plan servis yoğunluğu ve kullanıcı etkileşimi yokken “ısrarcı çalışma”

Bildirim/erişilebilirlik suistimali (özellikle kimlik bilgisi ve oturum yakalama riskini artırır)

Ağ trafiğinde ritim: belirli aralıklarla aynı hedeflere dönme, anormal alan adı/yol örüntüleri

Örnek: El feneri gibi görünen bir uygulamanın SMS okuma/gönderme ve bildirim erişimi istemesi; kapıyı açmak için anahtar istemek yerine evin tüm anahtarlarını talep etmeye benzer. Tek başına “suç” değildir ama “neden?” sorusunu zorunlu kılar.

1.2. APK bileşenleri ve izin modeli: “niyet beyanı” nasıl okunur?

APK’yı bir uygulamanın “çantası” gibi düşünebilirsin: kod, kaynaklar, tanımlar ve imzalama bilgisi aynı pakette taşınır. Savunma açısından kritik parçalar:

AndroidManifest.xml: Uygulamanın kimliği, bileşenleri (Activity/Service/Receiver), talep ettiği izinler ve bazı çalışma niyetleri burada görünür.

classes.dex (DEX): Uygulama kodunun derlenmiş hali; davranışın izleri çoğunlukla burada saklıdır.

resources.arsc / res/: Metinler, görseller, arayüz kaynakları; bazen URL/domain parçaları gibi izler burada da bulunur.

İmzalama bilgisi: Uygulamanın bütünlüğü ve kökeni için ipucu sağlar; tek başına “güven” garantisi değildir, bağlam ister.

Android izin modelinde savunma bakışıyla kritik soru şudur: “Bu izin, bu uygulamanın işleviyle tutarlı mı?” Kurumsal cihazlarda MDM politikaları, “mağaza dışı yükleme” (sideload) ve uygulama kaynağı gibi faktörler, aynı izin setinin risk anlamını ciddi biçimde değiştirebilir.

İpucu: İzinleri tek tek değil, izin demetleri halinde değerlendir. Örneğin “bildirim erişimi + erişilebilirlik + ağ erişimi” birlikteyse, veri toplama ve arka plan kontrol riski daha ciddiye alınır.

BOOT_COMPLETED sinyali nasıl okunur? Uygulamanın cihaz açılışında otomatik devreye girmesi, triage açısından “kalıcılık niyeti” sinyali olabilir. Pratikte bunun manifest tarafındaki karşılığı, uygun bileşen tanımı ve açılış yayınına (BOOT_COMPLETED) yönelik kurgu ile birlikte, ilgili iznin talep edilmesidir.

Dikkat: Cihaz açılışında çalışma isteği her zaman zararlı değildir (ör. alarm/hatırlatıcı, erişilebilirlik hizmeti, cihaz yönetimi ajanı). Bu sinyali uygulamanın işlevi + izin demeti + ağ ritmi ile birlikte yorumla.

1.3. Statik sinyallerle anormallik analizi: “kesin hüküm” değil, doğru sınıflandırma

Bu modülde statik analizde hedef, decompile/RE’ye dalmadan “hızlı risk sinyali” çıkarmaktır. Aradığın şey “mutlak karar” değil; triage kararını destekleyen kanıt parçalarıdır.

Sık kullanılan statik sinyal kaynakları:

Manifest’teki izinler, bileşen tanımları, otomatik başlatma niyetleri

Paket içi metinlerde domain/URL parçaları, hata mesajları, şüpheli anahtar kelimeler

Paket içi dosyalarda konfigürasyon benzeri yapıların varlığı (tek başına kötü değildir; bağlam önemlidir)

Anormallik yorumlamada pratik çerçeve:

İşlevi dar bir uygulamada aşırı geniş yetki

UI minimal iken arka planda yoğun iş yapmayı ima eden yapı

“Güncelleme / doğrulama / senkron” gibi ifadelerin tek başına değil, başka sinyallerle birleşince anlam kazanması

Örnek: Basit bir not uygulamasında konum + rehber + SMS erişimi istenmesi; alışveriş listesi tutan birinin aynı anda evin alarm paneline erişim istemesine benzer: her zaman suç değildir ama güvenlik ekibinin “neden?” sorusunu hak eder.

Dikkat: Mobilde “şüpheli görünen” pek çok şey meşru SDK’lar (analitik, crash reporting, reklam) nedeniyle oluşabilir. Sadece statik sinyalle bloklama kararı vermek yerine, raporda kanıt gücünü açıkça yazıp doğrulama ihtiyacını belirtmek daha güvenlidir.

1.4. Temel dinamik gözlem ve ağ davranışı: tek bağlantı değil, örüntü

Dinamik gözlemde orta seviye hedef, ileri enstrümantasyon değil; gözlem disiplini kurmaktır. Anlamlı alanlar:

Uygulama açıldığında/arka plana alındığında beklenmedik ağ bağlantıları

DNS sorguları ve HTTP(S) isteklerinde tekrarlayan hedefler ve şüpheli yol örüntüleri

Kullanıcı etkileşimi yokken bile görülen ritimli telemetri

Mobilde önemli bir gerçek: pil ve veri kotaları yüzünden bazı zararlı örüntüler, Wi-Fi/şarj gibi koşullara göre daha “sessiz” çalışacak şekilde zamanlanabilir (bu, otomatik olarak zararlı demek değildir; ama “ne zaman” sorusunu önemli kılar).

Ağ davranışını yorumlarken:

Bu bağlantıyı bu uygulamada bekler miyim?

Hedef domain/URL uygulamanın işleviyle uyumlu mu?

Trafik tek seferlik mi, yoksa bir ritim mi var?

Şüpheli davranışı güçlendiren ikinci sinyal ne (izin demeti, arka plan servisleri, açılışta çalışma niyeti)?

Örnek: Bir duvar kâğıdı uygulamasının kullanıcı hiçbir şey yapmazken düzenli aralıklarla example.org benzeri hedeflere gidip gelmesi; uygulamanın asıl işinin “görsel sunmak” değil, arka planda bir şeyler “taşımak” olabileceğini düşündürür.

İpucu: Dinamik gözlemde “tek bağlantı” yerine tekrar/örüntü daha değerlidir. Aynı hedefe düzenli dönmek, izleme ve avcılık için daha güçlü bir IOC adayına dönüşür.

Bu aşamadaki decompile/çalışma anında müdahale (hooking vb.) gibi ileri doğrulamalar, bu modülün kapsamı dışındadır. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

1.5. Mobil IOC’ler ve raporlama: “liste” değil, aksiyon alınabilir paket

Mobil IOC üretirken yalnız ağ göstergeleri değil, uygulamanın kimliği de savunmada değerlidir:

Paket adı + sürüm bağlamı

Hash (kurum içi örnek etiketleme için)

Domain/IP/URL + path örüntüleri (örneklerde yalnız dokümantasyon IP blokları kullanılmalı)

İzin demeti ve çalışma niyetleri (IOC değil; risk bağlamı)

Raporun okunur ve sahada kullanılabilir olması için üç şey net olmalı:

IOC nereden geldi? (statik mi, dinamik gözlem mi?)

Kanıt gücü nedir? (gözlendi mi, doğrulandı mı, aday mı?)

Ne öneriyorsun? (izleme, avcılık, kısıtlama, bloklama adayı?)

Örnek: “Uygulama X, kullanıcı etkileşimi yokken 192.0.2.110/api/upload hedefine tekrarlayan HTTPS trafiği üretiyor; eş zamanlı olarak bildirim erişimi + erişilebilirlik talep ediyor.” Bu cümlede değerli olan, tek başına URL değil; ritim + bağlam + izin demeti birlikte.

2. IoT Malware Tanıtımı (temel triage ve analiz bakışı)

2.1. IoT tehdit rolleri: botnet, dropper, downloader, proxy

IoT’de hedef çoğu zaman tek cihaz değil, çok cihazdır. Zayıf parolalar, güncellenmeyen firmware’ler ve sınırlı görünürlük, toplu suistimali kolaylaştırır.

Botnet: Cihazları komut alan bir ağa çevirir; DDoS ve yayılma gibi amaçlarla kullanılır.

Dropper: Asıl bileşeni “bırakma/kurma” rolündedir.

Downloader: İnternet erişimini kullanarak ek bileşen indirmeye çalışır.

Proxy malware: Cihazı saldırgan için çıkış noktası/sıçrama tahtası gibi kullanır; kurum ağında görünmez risk yaratır.

Örnek: Akıllı bir priz veya kamera, kendi işlevi dışında sürekli dışarıya trafik çıkarıyorsa; evdeki bir cihazın “elektrik harcamak” yerine komşunun evine uzatma kablosu çekmesine benzer—fayda cihaz sahibine değil, üçüncü tarafa gider.

2.2. Mimari farkındalık: ARM/MIPS/x86 neyi değiştirir?

IoT dünyasında mimari çeşitlilik (ARM, MIPS, x86 vb.) olağandır. Bu, triage’ı iki açıdan etkiler:

Dosyanın hangi cihaz sınıfına ait olabileceğini daha doğru konumlandırırsın.

“Derin analiz” aşamasına geçildiğinde disassembly/emülasyon gibi yaklaşımlarda doğru mimari şarttır.

Buradaki kritik ayrım: Metin izlerini görmek (strings) çoğu zaman hızlı sinyal verir; ancak dosyanın gerçek davranışına dair iddialar, mimari/bağlamla güçlendirilmeden erken hükme dönüşmemelidir.

2.3. Strings temelli triage ve basit C2 çıkarımı: aday göstergeleri doğru konumlandırma

IoT örneklerinde pratik triage sinyalleri:

Dosyanın türü: Linux kullanıcı alanı ikilisi, script, konfigürasyon dosyası vb.

İçerikte görülen strings izleri: domain/URL, hata mesajı, dosya yolu, komut benzeri parçalar

Kalıcılık veya ağ davranışına işaret eden kelime kümeleri (tek başına yetmez; bağlamla anlam kazanır)

C2 (command-and-control), zararlının komut aldığı veya veri gönderdiği altyapıdır. Orta seviyede hedef:

Hedef bilgisi var mı (domain/IP/URL)?

Tek mi, yedekli mi?

Bağlantı ritimli mi, tetiklemeli mi?

Bu izler konfigürasyonda mı, ikilinin içinde mi, script’te mi?

Örnek: Bir ikilinin içinde 203.0.113.0/24 aralığına işaret eden aday hedef izleri görülüyorsa, bunu “gözlenen aday ağ göstergesi” olarak raporlayıp savunma ekibine izleme/avcılık için başlangıç noktası verirsin.

Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

Dikkat: Strings çıktısındaki IP/URL her zaman C2 değildir; güncelleme sunucusu veya zaman sunucusu (NTP) gibi meşru hedefler de görülebilir. Engelleme yerine önce “hangi süreç/servis bağlamı” sorusunu cevaplayacak kanıt aramalısın.

2.4. IoT kalıcılık örüntüleri: init/systemd, cron, startup script

Kalıcılık (persistence), cihaz yeniden başlasa bile istenmeyen bileşenin tekrar devreye girmesidir. IoT tarafında bu çoğu zaman Linux başlangıç mantığı üzerinden okunur:

init / systemd servis mantığı (servis tanımları ve başlangıç zinciri)

cron (zamanlanmış görevlerle tekrar eden çalıştırma)

startup script zincirleri (açılışta koşan betikler)

Orta seviyede hedef, “nasıl kurmuşlar?”dan önce şunu söyleyebilmek: “Kalıcılık denemesi var mı ve nereye temas ediyor?”

Bazı IoT sistemlerinde geçici dizinler özellikle dikkat çeker: /tmp, programlar tarafından kullanılmak üzere geçici dosyalar için ayrılmıştır. Bu yüzden /tmp’de görülen bir artefakt, bazen “hızlı çalışma/iz bırakmama” tercihiyle ilişkili olabilir; fakat tek başına hüküm değildir.

İpucu: IoT triage’da erken değer üretmek istiyorsan önce üçlüye bak: başlangıç script’leri + servis tanımları + ağ hedefleri. Bu üçü, çoğu olayda savunma ekiplerinin hızla aksiyon almasını sağlar.

2.5. Firmware analiz mantığı: imaj bileşenleri ve dosya sistemi izleri

Firmware cihazın yazılım bütünüdür; içinde boot bileşenleri, çekirdek, dosya sistemleri, uygulamalar ve konfigürasyonlar bulunabilir. Orta seviyede amaç “her şeyi sökmek” değil, artefakt haritası çıkarmaktır:

Başlangıç zincirinde olağandışı ekler var mı?

Beklenmeyen ikililer/script’ler nerede?

Gömülü ağ hedefleri/parametreler var mı?

IoT firmware’lerde sık görülen dosya sistemi örneklerinden biri SquashFS’dir; sıkıştırılmış ve genellikle salt-okunur (read-only) yapısıyla bilinir. Yazılabilir flash dosya sistemi örneği olarak da JFFS2, gömülü sistemlerde flash cihazları için tasarlanmış log-yapılı bir dosya sistemi olarak konumlanır.

Firmware bileşenlerini “imza ve gömülü veri” açısından hızlı taramak için kullanılan araçlardan biri binwalk’tır; firmware imajlarında gömülü dosyalar ve çalıştırılabilir kod gibi içerikleri tanımlamaya odaklanır. Komut/uygulama adımı seviyesinde derinleştirme bu modülün hedefi değildir; burada önemli olan, bu yaklaşımın ne işe yaradığı ve ne zaman gerektiğidir. Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

Terimler Sözlüğü

Terim	Açıklama
APK	Android uygulama paketi; uygulamanın dağıtım dosyası
AndroidManifest.xml	Uygulamanın bileşenlerini ve izinlerini tanımlayan manifest dosyası
Permission	Android’de uygulamanın erişim yetkisi; risk değerlendirmesinde sinyal
DEX / classes.dex	Android uygulama kodunun derlenmiş biçimi
resources.arsc	Uygulama kaynaklarının derli toplu tutulduğu yapı (metin/stil vb.)
Spyware	Casus yazılım; kullanıcı verisini izinsiz toplayan tehdit türü
Adware	Reklam yazılımı; agresif reklam/izleme davranışı gösterebilir
Banker / Banking Trojan	Finansal uygulamaları hedefleyen mobil zararlı sınıfı
Premium SMS/Dialer	Ücretli SMS/servis etkileşimi gibi maliyet doğurabilecek kötüye kullanım örüntüsü
Overlay	Meşru uygulamanın üstüne sahte ekran bindirerek aldatma yaklaşımı
IOC	İhlal göstergesi; şüpheli/zararlı aktiviteyle ilişkilendirilebilen iz
C2 (Command-and-Control)	Zararlının komut aldığı veya veri gönderdiği altyapı
Botnet	Çok sayıda cihazın komutla yönetildiği kötüye kullanım ağı
Dropper	Asıl bileşeni bırakmaya/kurmaya odaklı ilk aşama bileşen
Downloader	Ek bileşenleri indirmeye odaklı bileşen
Proxy malware	Cihazı trafik aktarma/çıkış noktası gibi kullanan zararlı sınıfı
init / systemd	Linux başlangıç ve servis yönetimi yaklaşımları
cron	Zamanlanmış görev mekanizması
Firmware	Cihazın gömülü yazılım bütünü; OS + dosya sistemi + konfigürasyonları içerir
SquashFS	Sıkıştırılmış, genellikle salt-okunur Linux dosya sistemi
JFFS2	Flash cihazlar için tasarlanmış log-yapılı dosya sistemi
binwalk	Firmware imajlarında gömülü içerik/imzaları tanımlamaya odaklı analiz aracı

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)Bir Android uygulamasının işlevi çok basitken (ör. fener), SMS okuma/gönderme izinleri istemesi analiste en doğru neyi söyler?

A) Kesin ihlal kanıtıdır

B) Triage önceliğini yükselten bir risk sinyalidir

C) Uygulama mutlaka kurumsal yönetim ajanıdır

D) Yalnız performans optimizasyonu içindir

E) UI tasarımının zayıf olduğunu gösterir

Doğru: B
Gerekçe: İşlevle uyumsuz tehlikeli izinler tek başına “suç” değildir; ama doğrulama ihtiyacını artıran güçlü bir risk sinyalidir. A aşırı kesin; C/D/E bağlam dışıdır.

2)Manifest’te açılışta çalışmaya yönelik kurgu (BOOT_COMPLETED) görülmesi en doğru nasıl yorumlanır?

A) Her zaman zararlıdır

B) Kalıcılık niyeti sinyali olabilir; işlev ve diğer kanıtlarla birlikte değerlendirilmelidir

C) Sadece oyun uygulamalarında görülür

D) Sadece ağ trafiğini azaltır

E) APK’nın bozuk olduğunu kanıtlar

Doğru: B
Gerekçe: Açılışta devreye girme, triage açısından “kalıcılık niyeti” sinyali olabilir; ancak alarm/hatırlatıcı, cihaz yönetimi gibi meşru senaryolar da vardır. A/C/D/E genelleyici veya alakasızdır.

3)Mobil dinamik gözlemde “örüntü” değeri en yüksek sinyal hangisidir?

A) Uygulama bir kez internete çıktı

B) Kullanıcı düğmeye basınca URL açıldı

C) Kullanıcı etkileşimi yokken belirli aralıklarla aynı hedeflere trafik oluştu

D) Uygulama splash ekranı gösterdi

E) İkon rengi değişti

Doğru: C
Gerekçe: Ritimli, tekrarlayan davranış hem avcılık hem tespit için daha güçlüdür. A/B bağlama çok bağımlı; D/E alakasız.

4)“Şüpheli görünen her şey zararlıdır” yaklaşımı mobil statik analizde en çok neyi artırır?

A) True Positive oranını

B) False Positive oranını

C) Log bütünlüğünü

D) Cihaz depolamasını

E) Sertifika süresini

Doğru: B
Gerekçe: Meşru SDK’lar ve kütüphaneler pek çok “şüpheli” iz üretebilir; bağlamsız hüküm FP’yi yükseltir. Diğer şıklar ilgili değil.

5)Mobil raporlamada “aksiyon alınabilir paket” ile “IOC listesi” arasındaki temel fark hangisidir?

A) IOC’leri alfabetik sıralamak

B) IOC’nin kaynağını, kanıt gücünü ve önerilen kullanımını belirtmek

C) Sadece ekran görüntüsü eklemek

D) Sadece uygulama adını yazmak

E) Sadece tarih yazmak

Doğru: B
Gerekçe: Kaynak + güven/kanıt gücü + kullanım önerisi, savunma ekibinin doğru aksiyonu seçmesini sağlar. A/C/D/E eksik kalır.

6)IoT tarafında “strings gördüm, kesin zararlı” yaklaşımının en büyük riski hangisidir?

A) FN artışı

B) FP artışı

C) RAM artışı

D) Firmware küçülmesi

E) Kayıt defteri bozulması

Doğru: B
Gerekçe: IoT’de meşru bileşenlerde de ağ/sistem ifadeleri bulunur; bağlamsız yorum FP üretir. Diğerleri doğrudan ilgili değil.

7)IoT tehdit rolleri içinde “asıl bileşeni bırakma/kurma” rolü hangisine en yakındır?

A) Botnet

B) Dropper

C) Proxy malware

D) Patch manager

E) Firewall

Doğru: B
Gerekçe: Dropper, payload’ı bırakma/kurma rolüyle anılır. A/C farklı; D/E tehdit sınıfı değildir.

8)IoT kalıcılık sinyalleri bu modül kapsamındaki çerçevede en çok nerede aranır?

A) init/systemd servis mantığı, cron ve startup script zincirleri

B) GPU sürücü ayarları

C) Tarayıcı çerezleri

D) Ekran parlaklığı

E) Bluetooth eşleşmesi

Doğru: A
Gerekçe: Modülün kalıcılık odağı Linux başlangıç ve zamanlanmış görev mantığıdır. Diğer şıklar alakasızdır.

9)Firmware triage’da “erken değer” üretmeye en yakın yaklaşım hangisidir?

A) Tüm imajı eksiksiz tersine mühendislik yapmak

B) Başlangıç script’leri, servis tanımları ve ağ hedeflerini artefakt haritasında görünür kılmak

C) Sadece cihaz kasasını incelemek

D) Sadece dosya adlarına bakıp karar vermek

E) Sadece görselleri ayıklamak

Doğru: B
Gerekçe: Orta seviyede hedef tam RE değil; savunmaya hızlı katkı veren artefaktları haritalamaktır. A kapsam dışına taşar; C/D/E yetersizdir.

10)Mimari farkındalık (ARM/MIPS/x86) IoT triage’ında en çok neyi güçlendirir?

A) UI performansını

B) Dosyanın hangi cihaz sınıfına ait olabileceğini ve derin analiz için doğru yaklaşımı seçmeyi

C) E-posta filtrelemesini

D) Parola uzunluğunu

E) SSL sertifika süresini

Doğru: B
Gerekçe: Mimari, özellikle derin analiz yaklaşımını (disassembly/emülasyon gibi) doğru konumlandırır ve cihaz sınıfı çıkarımına yardım eder. Diğerleri alakasızdır.

Bu Modülde Kazanılan Yetkinlikler

Mobil tehdit sınıflarını ve sahada görülen örüntüleri triage kararı verecek netlikte okumayı
APK’nın temel bileşenlerini (manifest/DEX/resources/imza) risk sinyali çıkaracak şekilde yorumlamayı
Mobilde statik sinyallerle “kesin hüküm” yerine kanıt gücü ve bağlam diliyle rapor yazmayı
Dinamik gözlemde tekil bağlantıdan çok ritim/örüntü üzerinden IOC adayları üretmeyi
IoT dünyasında botnet/dropper/downloader/proxy rollerini ve mimari çeşitliliğin analiz bakışını nasıl etkilediğini
IoT’de kalıcılık sinyallerini init/systemd, cron ve startup script mantığıyla ilişkilendirmeyi
Firmware triage’ında “artefakt haritası” çıkararak hızlı savunma değeri üretmeyi

MODÜL 11 — Raporlama Standardı

Malware analizinde doğru bulguyu üretmek önemli; fakat o bulgunun kurum içinde aynı şekilde anlaşılması, denetlenebilmesi ve savunma kararına dönüşmesi asıl farkı yaratır. Bu modül, elde edilen statik/dinamik sinyalleri “teknik notlar yığını” olmaktan çıkarıp standart, anlaşılır ve aksiyon alınabilir bir rapor çıktısına dönüştürmeyi öğretir.

Modül Teması

Yönetici Özeti

Karar odaklı, kısa, etki ve önerilerin net olduğu üst katman.

Teknik Ek

Hash, log alıntısı, ekran görüntüsü, timeline — uygulayanın doğrulayabildiği detay katmanı.

Aksiyon Listesi

Kısa vadeli (engelle, izle) ve uzun vadeli (politika, mimari) ayrımıyla operasyona devir.

Bu Modülde Hedeflenen Kazanımlar

Aynı bulguyu, hem karar vericiye hem de SOC/IR/BT ekiplerine uygun katmanlarda anlatabilecek,
Hash, log, ekran görüntüsü ve zaman çizelgesiyle iddiaları kanıta bağlayabilecek,
Risk seviyesini gerekçeli kurup kısa vadeli aksiyonlar ve uzun vadeli öneriler yazabilecek,
Analizin başka bir analist tarafından doğrulanabilmesi için tekrar üretilebilirlik notlarını standartlaştırabileceksin.

1. Executive summary ve teknik ek ayrımı

Bir raporu okuyan herkes aynı teknik derinlikte değildir. Bu yüzden rapor, “tek bir metin” gibi dursa da iki ayrı ihtiyacı aynı anda karşılar: karar verme ve uygulama. Executive summary karar verdirir; teknik ek uygulamayı mümkün kılar.

1.1. Executive summary: karar odaklı üst katman

Bu bölüm genellikle CISO, BT yöneticisi veya birim sorumluları gibi karar vericiler içindir. Teknik ayrıntılar yerine şunlara odaklanır:

Ne oldu, hangi varlıklar etkilenmiş olabilir?

Etki (iş sürekliliği, itibar, veri riski) hangi düzeyde?

Kanıt gücü (confidence) ne kadar; hangi noktalar kesin, hangileri belirsiz?

İlk yapılacaklar neler?

Örnek: “İncelenen örnek, kullanıcı etkileşimi olmadan düzenli aralıklarla example.net alanına bağlantı kurmayı denemiştir. Trafiğin içeriği şifreli olduğundan aktarılan veri türü doğrulanamamıştır. Bu örüntü, arka planda veri aktarımı olasılığını artırmaktadır. 72 saat hedefli izleme ve ilgili uçlarda kapsam taraması önerilir.”

İpucu: Executive summary’yi, raporu hiç görmemiş birinin “Bu olaya nasıl öncelik vereyim?” sorusuna tek sayfada yanıt alacağı netlikte yaz.

1.2. Teknik ek: uygulamaya dönük detay katmanı

Teknik ek, SOC/IR/BT ekiplerinin “hangi kayıttan neyi doğrulayacağını” ve “hangi savunma adımının neye dayanacağını” görmesi içindir. Burada genellikle şunlar yer alır:

Kanıt kaynakları ve bağlam (hangi log/telemetri, hangi zaman aralığı, hangi uç/segment)

Bulguların dayanakları ve ilişkilendirmeler

IOC’ler ve mümkünse davranış bağlamı (nerede, ne zaman, hangi süreçle)

Zaman çizelgesi (timeline)

Analiz sınırlılıkları ve eksik kanıtlar

Tekrar üretilebilirlik notları (ortam, araç sürümleri, veri seti)

Dikkat: Teknik eki “ham çıktı deposu” gibi kullanmak raporu zayıflatır. Ham veri tek başına anlam üretmez; önemli kısımları seçip bağlamlandırmazsan ekipler kritik sinyali gürültü içinde kaybedebilir.

2. Kanıt sunumu: log, ekran görüntüsü, hash, zaman çizelgesi

Kanıtlar, analistin iddialarını destekleyen dijital mühürler gibidir. İyi rapor; “ne gördüm” ile “ne anlama geliyor” arasındaki köprüyü kanıt üzerinden kurar.

2.1. Hash: örneğin kimliği (özellikle SHA-256) ve iz sürme

Hash, dosya adından bağımsız bir kimliktir. Rapor içinde hash’in değeri iki noktada belirginleşir:

Aynı örneğin kurum içinde başka nerelerde görüldüğünü taramak,

Harici/kurumsal tehdit istihbaratı kaynaklarıyla eşleştirmek.

Hash’i rapora koyarken, bunun hangi dosyaya ait olduğu ve hangi bağlamda toplandığı (örnek nereden geldi, hangi inceleme kapsamında ele alındı) net olmalı.

Dikkat: Hash tek başına çoğu zaman “kesin bloklama gerekçesi” değildir. Varyantlaşmanın hızlı olduğu örneklerde hash kolay değişebilir; hash’i daha çok eşleşme ve kapsam taraması için güçlü bir gösterge gibi düşün.

2.2. Log ve trafik kayıtları: olayın izi ve korelasyon

Log, olayın “gerçekten yaşandığını” kanıtlamada en güçlü araçlardan biridir. Raporun hedefi, başka bir analistin aynı log kaynağına bakarak benzer sonuca ulaşabilmesidir. Bu yüzden log sunarken şu bağlamlar görünür olmalı:

Kaynak: EDR telemetrisi mi, işletim sistemi olayı mı, proxy/DNS kaydı mı?

Bağlam: Hangi uç, hangi rol, hangi kullanıcı bağlamı?

Korelasyon: Aynı zaman penceresinde başka hangi sinyaller var?

Ağ tarafında; URL, domain, IP gibi göstergeler tek başına değil, süreç bağlamıyla anlam kazanır. Süreç ağacındaki (process tree) ebeveyn–çocuk ilişkileri, “bu bağlantıyı hangi süreç başlattı?” sorusuna yanıt verir.

Örnek: “DNS kayıtlarında 198.51.100.0/24 aralığına yönelik çözümleme denemeleri, aynı zaman aralığında arka planda çalışan bir servis süreciyle korele görünmektedir.”

2.3. Ekran görüntüsü: görsel kanıt, ama kontrollü

Ekran görüntüsü; hata mesajı, güvenlik uyarısı, bir ayar değişikliği veya bir trafik görünümü gibi “kanıtın görünür hâli” olduğunda değerlidir. Fakat raporlar paylaşıldığında en sık veri sızıntısı, ekran görüntülerinden olur.

Hassas verileri (kullanıcı adı, iç sistem bilgisi, özel içerikler) görünür bırakma,

Görselin neyi kanıtladığını tek cümleyle açıklayıp bağlama oturt,

Görseli tek başına bırakma; neden önemli olduğunu söyle.

Dikkat: Ekran görüntüsü “ikna edici” olabilir ama her zaman “güçlü kanıt” değildir. Görselin hangi kaynaktan geldiği ve hangi zamanı temsil ettiği belirtilmezse yanlış yorumlanabilir.

2.4. Zaman çizelgesi (timeline): saldırı zincirini okunur kılma

Zaman çizelgesi, olayların sırasını ve birbirini nasıl tetiklediğini görünür kılar. “Tekil bulgu”yu “anlamlı akış”a çevirir.

Örnek:
09:15 — fatura.pdf.exe çalıştırıldı (uç telemetrisi)
09:16 — 192.0.2.45 adresine bağlantı kuruldu (proxy kaydı)
09:17 — Dosya erişim davranışında ani artış gözlendi (EDR olayı)

İpucu: Timeline satırlarını “olay + kaynak + bağlam” bütünlüğüyle yaz. “Ne oldu?” kadar “nereden biliyoruz?” sorusu da raporu güçlendirir.

3. Risk değerlendirme, öneri ve aksiyon listesi

Raporun sonunda okurun zihninde şu soru kalmamalı: “Tamam… şimdi ne yapıyoruz?” Bu bölüm, raporu “okunur” olmaktan çıkarıp “operasyonel” hale getirir.

3.1. Risk seviyesini gerekçeli kurma

Risk; genellikle olasılık ve etki bileşimidir:

Etki: veri kaybı, yetkisiz erişim, operasyon kesintisi, itibar riski

Olasılık: kanıt gücü, davranışın tutarlılığı, tekrar eden örüntüler

Risk seviyesi (Düşük/Orta/Yüksek/Kritik) yazarken “yüksek” demek yetmez; neye dayanarak o seviyeyi verdiğin anlaşılmalıdır.

Örnek: “Etki potansiyeli yüksek (kimlik bilgilerine erişim olasılığı), ancak trafik şifreli olduğu için aktarım içeriği doğrulanamadı. Bu nedenle risk Orta–Yüksek değerlendirilmiş; öncelik hedefli doğrulama ve kapsam taramasıdır.”

3.2. Aksiyonları kısa vadeli ve uzun vadeli düşünmek

Aksiyon listesi iki katmanda güçlenir:

Kısa vadeli aksiyonlar: yayılımı/etkiyi azaltan hızlı adımlar (containment/mitigation yaklaşımı)

Uzun vadeli öneriler: aynı tür vakanın tekrarını azaltan iyileştirmeler (politika, eğitim, tespit iyileştirme)

Aksiyonlar ayrıca “uygulanabilir istihbarat” (actionable intel) üretmelidir: yani ekiplerin doğrudan işleyebileceği kadar net olmalı; fakat gereksiz uygulama detayıyla raporu şişirmemelidir.

Örnek: “Belirli uç grubunda example.net hedefine ritimli trafik için 72 saat izleme; aynı zaman penceresinde şüpheli süreç ağacı eşlik ediyorsa öncelikli IR incelemesi. Doğrulama sağlanırsa ilgili iletişim örüntüsü için kısıtlama ve etkilenen uçlarda kapsam taraması.”

İpucu: Önerileri “başarı kriteri” ile bitir: “Bu aksiyon işe yaradıysa ne görmeyi bekliyoruz?” Böylece rapor, takip edilebilir bir plana dönüşür.

Dikkat: “Her gün parola değiştirin” gibi operasyonel yükü aşırı artıran öneriler genellikle zayıftır. Savunma adımı, riskle orantılı ve gerçekçi olmalıdır.

4. Analiz tekrar üretilebilirliği için standart notlar

Tekrar üretilebilirlik (reproducibility), raporu “kişinin not defteri” olmaktan çıkarıp “kurumsal kanıt” haline getirir. Bir başka analist, aynı girdilerle benzer sonuca ulaşabilmelidir.

Bu bölümde standartlaştırılması beklenen notlar:

Analiz ortamı: izolasyon/VM yaklaşımı, işletim sistemi sürümü, tarih/saat (zaman dilimiyle)

Kullanılan veri kaynakları: statik bulgular, dinamik gözlem, ağ kayıtları, EDR/telemetri

Kullanılan araçlar: araç isimleri ve sürümleri (ör. kullanılan statik analiz aracı ve sürümü gibi)

İncelenen örnek kimliği: hash ve örneğin hangi kanal/olay kapsamında incelendiği

Analiz sınırlılıkları: eksik log, şifreli trafik, erişilemeyen telemetri, gözlemi kesen koşullar

Örnek: “Örnek, dış ağa erişim kısıtı nedeniyle hedef sunucuyla iletişim kuramadığından, sonraki aşama davranışlar gözlemlenememiştir; bu nedenle rapordaki çıkarımlar, görülebilen telemetriyle sınırlıdır.”

Dikkat: Tekrar üretilebilirlik notları yazarken içerik, istemeden “uygulanabilir saldırı talimatına” dönüşmemelidir. Daha ileri düzey kod analizi ve karmaşık decompile bulgularının dökümantasyonu, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

Terimler Sözlüğü

Terim	Açıklama
Executive summary	Yönetici özeti; etki/risk/aksiyon odaklı üst katman
Technical appendix / Deep-dive	Teknik ek; SOC/IR/BT için kanıt, bağlam ve uygulanabilir detay bölümü
Evidence	Kanıt; kaynağı belli, doğrulanabilir bulgu
Confidence	Güven düzeyi; bulgunun kanıt gücü
Hash / SHA-256	Dosya özeti; örneğin kimliği ve eşleştirme için parmak izi
Log	Kayıt; sistem/ağ/uygulama olaylarının zaman damgalı izi
Process tree	Süreç ağacı; ebeveyn–çocuk süreç ilişkileri
Screenshot	Ekran görüntüsü; görsel kanıt (maskeleme ve bağlam şart)
Timeline	Zaman çizelgesi; olay akışının kronolojik özeti
Risk assessment	Risk değerlendirmesi; etki ve olasılığın gerekçeli değerlendirilmesi
Mitigation	Azaltma; tehdidin etkisini düşürmeye yönelik savunma adımları
Containment	Kısıtlama/çevreleme; yayılımı ve etkiyi azaltan hızlı önlemler
IOC	Tehdit göstergeleri; IP, hash, domain, URL gibi izler
Actionable intel	Uygulanabilir istihbarat; doğrudan savunma adımına dönüşebilen bilgi
Reproducibility	Tekrar üretilebilirlik; başka analistin aynı sonuca ulaşabilmesi standardı
Root cause analysis	Kök neden analizi; olayın nasıl başladığını anlamaya yönelik yaklaşım

Kendini değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)Yönetici özetinin temel işlevi aşağıdakilerden hangisidir?

A) Ham logları eksiksiz saklamak

B) Teknik ayrıntılarla analistin yetkinliğini göstermek

C) Etki–risk–aksiyon odağında karar vermeyi hızlandırmak

D) Sadece IOC listesini sıralamak

E) Yalnızca ekran görüntülerini toplamak

Doğru: C
Gerekçe: Executive summary karar odaklıdır; A/D/E tek boyutlu kalır, B hedef kitleyle uyumsuzdur.

2)Teknik ekin asıl değeri hangi ihtiyacı karşılar?

A) Yönetim sunumunu görselleştirmek

B) SOC/IR/BT ekiplerinin doğrulama ve uygulama yapabilmesi

C) Raporu daha uzun göstermek

D) Belirsizlikleri gizlemek

E) Dosya adını paylaşmak

Doğru: B
Gerekçe: Teknik ek operasyonel uygulamayı mümkün kılar; C amaç dışıdır, D güveni düşürür, E yetersizdir.

3)SHA-256 gibi bir hash bilgisini rapora eklemek ne sağlar?

A) Dosyanın kim tarafından yazıldığını kesinleştirir

B) Dosyayı isimden bağımsız tekil kimliklendirip eşleştirmeyi kolaylaştırır

C) Dosyanın otomatik silinmesini sağlar

D) İnternet hızını artırır

E) Dosyanın riskini tek başına kanıtlar

Doğru: B
Gerekçe: Hash kimliklendirme ve eşleştirme içindir; A/E aşırı iddialı, C/D alakasızdır.

4)Ekran görüntüsü eklerken en kritik güvenlik noktası hangisidir?

A) Yüksek çözünürlük

B) Hassas verileri maskelemek ve görselin bağlamını yazmak

C) Siyah-beyaz yapmak

D) Sayfanın ortasına koymak

E) Görsel sayısını artırmak

Doğru: B
Gerekçe: Paylaşımda veri sızıntısı riski yüksektir; diğerleri biçimseldir.

5)Zaman çizelgesi oluştururken olaylar nasıl sıralanmalıdır?

A) En önemli olaydan en önemsizine

B) Alfabetik sıraya göre

C) Kronolojik sıraya göre

D) Dosya boyutuna göre

E) Araç isimlerine göre

Doğru: C
Gerekçe: Akışı anlamak için zaman sırası kritiktir; diğerleri olay ilişkisini bozabilir.

6)“Hash tek başına bloklanmalı” yaklaşımı neden riskli olabilir?

A) Hash hiç değişmez, bu yüzden gereksizdir

B) Hash hızla değişebileceği için tek başına yanlış pozitif riskini artırabilir

C) Hash sadece mobil tehditlerde işe yarar

D) Hash rapora yazılamaz

E) Hash raporu kısaltır

Doğru: B
Gerekçe: Hash bağlam olmadan aşırı reaksiyona yol açabilir; diğer şıklar yanlış/amaç dışıdır.

7)Risk seviyesini “Kritik” yapmak en doğru neye dayanmalıdır?

A) Analistin sezgisine

B) Etki, olasılık ve kanıt gücünün gerekçeli değerlendirmesine

C) Sadece dosya ismine

D) Sadece dosya boyutuna

E) Bilgisayar markasına

Doğru: B
Gerekçe: Risk, etki + olasılık bileşimidir; C/D/E yüzeyseldir.

8)Teknik ekte araç çıktılarıyla ilgili en büyük hata hangisidir?

A) Çıktıları tabloya koymak

B) Teknik terim kullanmak

C) Yorumlanmamış ham veriyi olduğu gibi rapora yığmak

D) PDF olarak paylaşmak

E) Başlıkları kalın yazmak

Doğru: C
Gerekçe: Rapor veri çöplüğü değildir; ham veri bağlamlandırılmadıkça karar üretmez.

9)“IP: 192.0.2.10’u bloklayın” ifadesi hangi kategoriye girer?

A) TTP

B) IOC

C) Hash

D) Donanım markası

E) Kullanıcı adı

Doğru: B
Gerekçe: IP adresi bir tehdit göstergesidir; TTP davranış/teknik kalıbı ifade eder.

10)“Örnek, sanal ortamda çalışmayı durduruyor olabilir” notu rapora ne katar?

A) Dosya adını güçlendirir

B) Analizin sınırlılıklarını şeffaflaştırarak güvenilirliği artırır

C) İnternet bağlantısını düzeltir

D) Ekran çözünürlüğünü artırır

E) İşlemciyi hızlandırır

Doğru: B
Gerekçe: Kısıtları açık yazmak, karar vericilerin bulguyu doğru kalibre etmesini sağlar.

Bu Modülde Kazanılan Yetkinlikler

Raporu katmanlı kurgulayıp executive summary ile teknik ekin rolünü doğru konumlandırma
Kanıt setini (hash, log, ekran görüntüsü, timeline) bağlamla sunarak denetlenebilir çıktı üretme
Risk seviyesini gerekçelendirme ve kısa/uzun vadeli aksiyonları gerçekçi biçimde yazma
Tekrar üretilebilirlik notlarıyla raporu ekip içinde sürdürülebilir ve doğrulanabilir hale getirme
Raporu, savunma operasyonlarına doğrudan girdi sağlayan “uygulanabilir istihbarat” çıktısına dönüştürme

MODÜL 12 — Çıktı Odaklı Bütünleme

Eğitim boyunca ürettiğin triage notları, statik bulgular, dinamik gözlemler, ağ göstergeleri ve rapor parçaları tek başına değerli olsa da, kurum için asıl değer bu parçaların tek bir “teslim paketi” hâline gelmesinden doğar. Bu modül, dağınık analiz çıktılarının profesyonel bir savunma döngüsüne (SOC, IR, tehdit avcılığı) hızlı ve tutarlı şekilde entegre edilebilecek bir bütünlüğe dönüştürülmesini ele alır. Başarının ölçütü “dosyayı çözmek” kadar, bu çözümü kanıt zinciri + operasyonel aksiyon hâline getirebilmektir.

Modül Teması

Kronoloji

İpucu → gözlem → yorum: parçaları birbirine bağlayan saldırı zinciri anlatımı.

IOC Paketi

Liste değil, kullanılabilir paket: bağlam + güven düzeyi + yaşam süresi.

MITRE ATT&CK

TTP eşlemesi: davranışı standart dile çevirip savunma kararını ortaklaştırmak.

Bu Modülde Hedeflenen Kazanımlar

Triage, statik ve dinamik bulguları mantıksal ve kronolojik bir vaka hikâyesine dönüştürmek
Bulguların kanıt gücünü doğru ifade edip eksikleri saklamadan yazmak
SOC/IR için doğrudan kullanılabilir bir IOC paketi hazırlamak (bağlam + güven düzeyi + kullanım önerisiyle)
Davranış örüntülerini TTP bakışıyla çerçeveleyip MITRE ATT&CK eşlemesiyle ortak dil kurmak
Raporu, ekleri ve teslim setini standart hâle getirip tekrar üretilebilirliği desteklemek
Orta seviyenin sınırına gelindiğinde eskalasyon kararını teknik gerekçelerle savunmak

1. Dağınık parçaları tek hikâyeye çevirmek: triage + statik + dinamik

Analiz süreci boyunca topladığın veriler bir yapbozun parçaları gibidir. Bütünleme aşamasında hedef, “parça parça doğrular” yerine tek bir saldırı hikâyesi çıkarmaktır: ne oldu, hangi izler bunu destekliyor, nerede belirsizlik var ve savunma tarafı ne yapmalı?

1.1. Bulguları ilişkilendirme: ipucu → gözlem → yorum

Statik analiz genellikle “potansiyel” sinyaller verir; dinamik analiz ise “gözlenen” davranışı gösterir. Aynı işareti iki farklı kaynaktan yakaladığında kanıt gücü yükselir; çelişki varsa hipotezini revize etmek gerekir.

Örnek: Statik incelemede dosya içinde <https://example.org/v1/gate> benzeri bir uç nokta izi görülür. Dinamik gözlemde aynı hedefe giden POST istekleri tespit edilirse, bu hedefin kontrol/iletişim altyapısı olma ihtimali güçlenir. Trafik şifreli olduğu için içerik doğrulanamıyorsa “kesin” yerine kanıta uygun bir güven ifadesi kullanılır.

Dikkat: Statikte gördüğün bir URL’yi “kesin C2” diye yazmak, doğrulanmamış bir ipucunu hükme dönüştürür ve yanlış aksiyon riskini büyütür. Dilin, kanıtın gücüyle aynı ayarda kalmalı.

1.2. Kronoloji ve “saldırı zinciri” bakışı: neyi nereye oturtuyorum?

Bütünleme sırasında kendine sorman gereken en kritik soru şudur: “Elde ettiğim bulgular saldırı zincirini açıklamak için yeterli mi?” Olayları sıraya dizmek, tekil bulguları anlamlı bir akışa çevirir; “ne önce oldu, neyi tetikledi?” sorusunu görünür kılar.

Örnek: (zaman çizelgesi)
09:15 — Şüpheli dosya çalıştırıldı (uç telemetrisi)
09:16 — 192.0.2.15 adresine bağlantı denemesi görüldü (proxy/DNS kaydı)
09:17 — Aynı hedefe ritimli tekrar başladı (ağ örüntüsü)
09:19 — Dosya sistemi üzerinde beklenmeyen yeni dosya izi oluştu (dosya sistemi gözlemi)

İpucu: Zaman çizelgesinin sonuna bir “tek cümlelik yorum” eklemek, okuyan kişinin akışı hızla kavramasını sağlar: “Bu sıra, arka planda ritimli iletişim denemesi ve olası ikinci aşama davranışını destekliyor.”

1.3. Eksik kanıtları görünür kılmak: “ne bilmiyoruz?”

Bütünleme, sadece güçlü bulguları parlatmak değildir; eksikleri bilinçli şekilde işaretlemektir. Bu, raporu zayıflatmaz; tam tersine denetlenebilirliğini artırır.

Örnek: Yazılımın bir dosya indirdiği düşünülüyor ama indirilen dosyanın ne olduğu görülemiyorsa, “dropped files” veya ağ kayıtları eksiktir. Bu durumda hipotez, “ikinci aşama olabilir” seviyesinde kalır; “neye ihtiyaç var” açıkça yazılır.

Dikkat: “Kanıt yoksa yoktur” cümlesini gizleyip yerine kesinlik koymak, savunma ekiplerini yanlış yola sokabilir. Eksik kanıtı yazmak, profesyonel risk yönetiminin parçasıdır.

2. IOC’yi liste olmaktan çıkarıp operasyona dönüştürmek: paketleme ve kullanılabilirlik

IOC’ler (hash, IP, domain, URL, dosya yolu, registry izi, mutex vb.) raporun en kritik teslim kalemlerinden biridir; ancak tek başına değerleri sıralamak yeterli olmaz. Savunma ekipleri IOC’yi görünce şu sorulara yanıt ister: “Bu nereden geldi?”, “Ne kadar güveniyoruz?”, “Bunu ne yapayım?”

2.1. IOC paketinin taşıması gereken boyutlar

Her gösterge için şu bilgileri standartlaştırmak, IOC’yi doğrudan kullanılabilir hâle getirir:

Tür ve değer: hash / IP / domain / URL / path / registry / mutex…

Kaynak: statik ipucu mu, dinamik gözlem mi, telemetri mi?

Zaman penceresi: ilk/son görülme veya en azından gözlem aralığı

Bağlam: hangi uçta, hangi süreçle ilişkili, kullanıcı etkileşimi var mı?

Güven düzeyi: düşük / orta / yüksek (kanıt gücüyle uyumlu)

Kullanım önerisi: izleme mi, avcılık mı, kısıtlama mı, bloklama adayı mı?

Örnek: “198.51.100.23 hedefi yalnızca belirli bir süreç bağlamında ve ritimli biçimde görüldü. Bu nedenle önce hedefli izleme + avcılık, doğrulama sonrası kısıtlama değerlendirmesi önerilir.”

2.2. “Actionable intelligence” bakışı: kural değil, karar desteği

IOC paketi savunma cihazlarına kural adayı olabilir; fakat bunu “otomatik ve mutlak bloklama” gibi sunmak yanıltıcıdır. Operasyonel gerçeklikte IOC’ler; izleme, korelasyon, tehdit avcılığı ve gerektiğinde kısıtlama için kullanılır.

İpucu: IOC’nin yanına “başarı kriteri” eklemeyi alışkanlık hâline getir: “Bu göstergeyle avcılık yaparsak ne görmeyi bekliyoruz?” Bu cümle, paketi gerçek operasyon diline taşır.

3. Davranışı standart dile çevirmek: TTP ve MITRE ATT&CK eşleme

IOC “nerede bakacağım?” sorusunu güçlendirir; TTP eşleme ise “ne arıyorum, bu neye benziyor?” sorusunu netleştirir. Davranış örüntülerini ortak bir çerçeveye oturtmak, farklı ekiplerin aynı vakayı aynı dilde konuşmasını sağlar.

3.1. MITRE eşlemenin pratik faydası

Bir tekniği standart adıyla belirtmek, playbook seçimini hızlandırır ve benzer saldırıları gelecekte daha erken yakalamayı kolaylaştırır.

Örnek: Yazılımın kendini başlangıç klasörüne kopyalayarak kalıcı olmaya çalıştığı gözlenirse, bu davranış MITRE ATT&CK’te Persistence taktiği altında T1547.001 — Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder ile ilişkilendirilebilir.

Örnek: Dış dünyaya yapılan bağlantı denemeleri, çoğunlukla Command and Control (Komuta-Kontrol) davranış ailesiyle ilişkilendirilir. Burada kritik nokta, bağlantının bağlamını ve ritmini (tekil mi, düzenli mi) raporda netleştirmektir.

Dikkat: Sadece hash’e odaklanan bir savunma, hızlı varyantlaşma karşısında zayıflar. Davranış modelini (TTP) çerçevelemek, “aynı aileden” gelen yeni örnekleri de daha erken fark etmeyi destekler.

4. Teslim standardı: rapor + ekler + dosya seti nasıl “kurumsal” olur?

Bütünleme çıktısı genellikle tek bir belge değildir; bir teslim paketidir. Kurum içi ciddiyet, bu paketin düzeni ve denetlenebilirliğiyle ölçülür.

4.1. Okur hiyerarşisi: önce karar, sonra uygulama

Karar vericiler “etki ve risk” görmek ister; teknik ekipler “kanıt ve uygulanabilir detay” ister. Teslim paketinde bu hiyerarşi korunmalıdır: önce üst seviye özet, ardından teknik detaylar ve ekler.

4.2. Kanıt bütünlüğü: iddia değil, kanıtla destekli yorum

Raporda yazılan her kritik bulgu, uygun bir kanıt iziyle (log kesiti, zaman çizelgesi, hash, maskelemiş ekran görüntüsü vb.) ilişkilendirildiğinde “denetlenebilir” hâle gelir.

Dikkat: Araçların ham çıktılarını olduğu gibi rapora yığmak, kritik sinyali gürültüye boğar. Ham veriyi arşivleyebilirsin; raporun içine ise seçilmiş ve bağlamlandırılmış kısmı koymalısın.

4.3. Teslim paketinde neler bulunur?

Aşağıdaki set, orta seviye bir vakanın çoğunda “operasyonel teslim” ihtiyacını karşılar:

Analiz raporu (genellikle PDF tercih edilir)

IOC listesi (CSV/JSON gibi makine okunur formatlarda)

Zaman çizelgesi (timeline)

Kritik kanıt ekleri (maskelemiş ekran görüntüsü / log kesitleri)

Analiz ortamı notları (işletim sistemi sürümü, kullanılan araçlar ve versiyonları, veri kaynakları, zaman aralığı)

Güvenli şekilde saklandıysa, incelenen örneğe referans (ör. şifreli arşiv referansı ve erişim politikası)

İpucu: “Analiz Ortamı” bölümünde araç versiyonlarını ve analiz zaman penceresini yazmak, aylar sonra aynı vaka tekrar gündeme geldiğinde ekibe ciddi hız kazandırır.

5. Eskalasyon: ne zaman durulur, ne zaman ileri seviyeye devredilir?

Orta seviye analiz her vakayı “tam çözecek” diye bir kural yoktur. Profesyonellik, sınırı doğru çizip riski doğru yönetmektir. Eskalasyon bir başarısızlık değil, kontrollü bir risk yönetimi kararıdır.

5.1. Eskalasyonun güçlü teknik gerekçeleri

Aşağıdaki durumlar, orta seviye yöntemlerle kanıt üretmenin zorlaştığına işaret edebilir:

Gelişmiş obfuscation: statikte anlamlı akış çıkmaması, dinamikte davranışın sürekli belirsiz kalması

Özgün/özel packer izleri: bilinen araçlarla anlamlı gözlem üretilememesi (nasıl açılır detayına girilmez)

Anti-analysis sinyalleri: sanal ortam/analiz koşullarına tepki verip davranışı değiştirme olasılığı

Çok aşamalı yapı: indirilen/oluşturulan ek bileşenlerin (dropped files) tam görülememesi ve zincirin kapanmaması

Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

5.2. Eskalasyon gerekçesi nasıl yazılır?

Eskalasyon cümlesi duygusal değil, kanıt temelli olmalıdır: ne görüldü, nerede tıkandı, belirsizliği kapatmak için neye ihtiyaç var?

Örnek: “Örnek, analiz koşullarına duyarlı davranış gösterebilecek sinyaller üretmektedir ve şifreli iletişim nedeniyle aktarılan içerik doğrulanamamıştır. Mevcut veri setiyle davranışın kritik kısmı kanıtlanamadığı için ileri doğrulama gereksinimi doğmuştur.”

İpucu: İleri analizi yapacak kişiye zaman kazandırmak için, çözemediğin ama şüpheli bulduğun izleri “not” olarak bırak: hangi bulgu nerede görüldü, hangi koşulda tekrarlandı, hangi kanıt eksik kaldı.

Terimler sözlüğü

Terim	Açıklama
Consolidation	Bütünleme; dağınık bulguları tek teslim çıktısında birleştirme
Deliverable	Teslim çıktısı; rapor, IOC paketi, eşleme ve ekler gibi ürünler
Scope	Kapsam; incelenen örnek/host/zaman aralığı ve veri kaynakları
Evidence chain	Kanıt zinciri; bulgu → dayanak → yorum ilişkisi
Correlation	Korelasyon/ilişkilendirme; farklı kaynak sinyallerini birleştirme
Actionable intelligence	Uygulanabilir istihbarat; doğrudan savunma aksiyonuna dönüşen bilgi
IOC package	IOC paketi; bağlam, zaman, güven düzeyi ve kullanım önerisiyle göstergeler
TTPs	Taktikler, Teknikler ve Prosedürler; saldırgan davranış örüntüleri
MITRE ATT&CK	Saldırgan taktik/tekniklerini sınıflandıran bilgi tabanı
Kill chain	Saldırı zinciri; saldırının aşamalar halinde ilerleyiş modeli
Dropped files	Bırakılan dosyalar; zararlı tarafından sisteme yazılan yan bileşenler
Reproducibility	Yeniden üretilebilirlik; başka analistin aynı sonuçlara ulaşabilmesi
Escalation	Eskalasyon; vakanın ileri uzmanlık seviyesine devredilmesi
Escalation	Sınırlılık; analizin neden eksik kalabileceğini açıklayan not
Command and Control	Komuta-Kontrol; saldırgan altyapısıyla iletişim davranışları
Persistence	Kalıcılık; sistemde yeniden başlatmalardan sonra da çalışabilme çabası

Kendini değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)Bütünleme aşamasının en doğru çıktısı hangisidir?

A) Ham logların olduğu gibi rapora yapıştırılması

B) Statik ve dinamik bulguların ayrı ayrı uzun anlatımı

C) Kanıt zinciriyle desteklenen vaka hikâyesi + operasyonel teslim paketi

D) Sadece IOC değerlerinin listesi

E) Sadece yönetici özeti

Doğru: C
Gerekçe: Amaç dağınık parçaları tek hikâyeye ve kullanılabilir pakete dönüştürmektir; diğerleri eksik veya gürültü üretir.

2)Statik bulguyla dinamik gözlem çelişiyorsa en doğru refleks nedir?

A) En kötü senaryoyu seçip raporu kapatmak

B) Statik bulguyu doğru kabul edip dinamiği görmezden gelmek

C) Hipotezi gözden geçirip özellikle dosya sistemi ve ağ izlerini yeniden doğrulamak

D) Dosyayı silip analizi sonlandırmak

E) Sadece ekran görüntüsü eklemek

Doğru: C
Gerekçe: Çelişki çoğu zaman eksik veri veya çok aşamalı yapı işaretidir; doğrulama gerekir

3)IOC’yi “paket” yapan unsur aşağıdakilerden hangisidir?

A) IOC’leri kalın yazmak

B) Sadece değerleri vermek

C) Kaynak + zaman penceresi + bağlam + güven düzeyi + kullanım önerisi eklemek

D) IOC sayısını artırmak

E) IOC’leri alfabetik sıralamak

Doğru: C
Gerekçe: Operasyonel kullanım için bağlam ve öneri şarttır.

4)“Actionable intelligence” bir raporda neyi ifade eder?

A) Raporun uzun olmasını

B) Bulguların doğrudan savunma aksiyonuna çevrilebilmesini

C) Raporun İngilizce yazılmasını

D) Sadece yöneticilere hitap etmesini

E) Kodun karmaşıklığını

Doğru: B
Gerekçe: Değer, “ne yapılmalı?” sorusuna somut veriyle yanıt verebilmektir.

5)Bir örneğin 192.0.2.15 gibi bir IP’ye bağlantı denemesi, MITRE bakışıyla en çok hangi davranış ailesine işaret eder?

A) Persistence

B) Command and Control

C) Privilege Escalation

D) Initial Access

E) Impact

Doğru: B
Gerekçe: Dış hedefe iletişim denemeleri çoğunlukla C2/iletişim davranışıyla ilişkilendirilir; bağlam raporda mutlaka netleştirilmelidir.

6)MITRE ATT&CK’te T1547.001 eşlemesi savunma ekibine ne kazandırır?

A) Saldırganın kimliğini kesinleştirir

B) Kalıcılık yöntemini standart bir terminolojiyle anlatıp doğru playbook’u seçmeyi kolaylaştırır

C) Hash’in değişmesini engeller

D) Ağ trafiğini otomatik çözer

E) Ekran görüntülerini daha güçlü kanıt yapar

Doğru: B
Gerekçe: Standart teknik dili, ekipler arası ortak anlayışı hızlandırır; diğer seçenekler gerçekçi değildir.

7)Yeniden üretilebilirlik için raporda hangisi vazgeçilmezdir?

A) Analistin kişisel yorumları

B) Analiz yapılan günün hava durumu

C) İşletim sistemi ve araçların versiyon bilgileri + veri kaynakları + zaman penceresi

D) Bilgisayar kasasının tipi

E) Yazı tipinin adı

Doğru: C
Gerekçe: Aynı sonuca ulaşabilmek için ortam ve veri koşulları bilinmelidir.

8)Zaman çizelgesinin (timeline) ana amacı hangisidir?

A) Raporu uzatmak

B) Olayların sırasını ve birbirini nasıl tetiklediğini kronolojik olarak göstermek

C) Hash türlerini öğretmek

D) Sadece yönetici özetini süslemek

E) Belirsizlikleri gizlemek

Doğru: B
Gerekçe: Timeline, saldırı akışını görünür kılar ve korelasyonu güçlendirir.

9)Bir dosyanın “dropper” olduğu düşünülüyorsa teslim paketinde ne mutlaka güçlenmelidir?

A) Sadece ana dosyanın hash’i

B) Yalnız ekran görüntüsü arşivi

C) Ana dosyanın yanında oluşturduğu/indirdiği bileşenlere dair izler ve bunların bağlamı

D) Bilgisayarın RAM miktarı

E) Kullanıcının tarayıcı geçmişi

Doğru: C
Gerekçe: Dropper zinciri, tek dosyayla açıklanmaz; bırakılan/indirilen bileşenler zinciri kapatır.

10)Eskalasyon gerekçesi yazarken en doğru dil hangisidir?

A) Bu dosya çok zor, ben yapamadım.

B) Dosyayı başka biri incelesin

C) Şu kanıtlar var; şu sınırlılıklar nedeniyle kritik kısmı doğrulanamadı; şu ek analizle belirsizlik kapanır

D) Bilinmiyor

E) Dosya bozuk olabilir

Doğru: C
Gerekçe: Eskalasyon, somut kanıt + eksik kanıt + ihtiyaç duyulan doğrulama çerçevesiyle profesyonelce gerekçelendirilir.

Bu Modülde Kazanılan Yetkinlikler

Triage, statik ve dinamik çıktıları tek bir kanıt zinciri içinde birleştirerek tutarlı vaka hikâyesi kurma
IOC’leri bağlamlandırıp güven düzeyi ve kullanım önerisiyle operasyonel pakete dönüştürme
Davranış örüntülerini TTP bakışıyla çerçeveleyip MITRE ATT&CK eşlemesiyle ortak savunma dili kurma
Teslim standardını rapor + ekler + makine okunur çıktılarla kurumsal seviyeye taşıma
Orta seviyenin sınırına gelindiğinde eskalasyonu kanıt ve sınırlılıkla gerekçelendirme

MODÜL 13 — Koddan Makineye: C → Assembly → Decompile Köprüsü

Malware analizinde bazen yalnızca “ne yaptı?” sorusunu yanıtlamak yetmez; davranışın arkasındaki mantıksal kurguyu okuyabilmek gerekir. Bu modül, C ile yazılmış bir fikrin derleyici tarafından nasıl makine koduna dönüştürüldüğünü ve bizim araçlarda gördüğümüz disassembly ile decompiler çıktılarının bu yolculukta nereye oturduğunu öğretir. Hedef, “tam tersine mühendislik uzmanı” olmak değil; statik/dinamik bulgulardan sonra karşına çıkan kod parçalarında kritik davranış yollarını seçip okuyarak raporunu kanıtla güçlendirebilmektir.

Modül Teması

C → Assembly

Değişken, koşul ve döngü yapılarının assembly’deki karşılığı: roller kalır, isimler kaybolur.

Stack Frame

Prologue/Epilogue kalıbı, calling convention ve parametre taşımanın okuma rehberi.

Decompile

Decompiler çıktısı kaynak değildir; kritik yol odaklı doğrulama ile kanıt üretilir.

Bu Modülde Hedeflenen Kazanımlar

Kaynak kod → IR → assembly → makine kodu zincirini kavramsal olarak haritalayıp analiz bulgularını doğru yere oturtmak.
Temel C yapılarının (değişken ataması, koşul, döngü) assembly’de bıraktığı izleri tanımak.
Stack frame ve calling convention kavramlarını “okuma” düzeyinde kullanarak parametre/geri dönüş değerlerini yorumlayabilmek.
Prologue/epilogue, compare/jump, loop gibi kalıplarla karar noktalarını hızlıca bulmak.
Decompiler çıktısının sınırlılıklarını bilerek yanlış kesinlik riskini azaltmak ve gerektiğinde disassembly ile doğrulamak.
Tüm kodu satır satır okumak yerine “kritik yollar” yaklaşımıyla savunma çıktısına dönüşecek kanıtı toplamak.

1. Kodun dönüşüm yolculuğu: source → IR → assembly → binary

Bir yazılımcının yazdığı C kodu ile işlemcinin çalıştırdığı ikili talimatlar arasında çok katmanlı bir “tercüme” vardır:

Kaynak kod (source code): C/C++ gibi insan tarafından okunur ifadeler.

Ara temsil (IR — Intermediate Representation): Derleyicinin optimizasyonlar yaparken kullandığı, daha “mantıksal” ara form. Bunu çoğu zaman doğrudan görmezsin ama etkisini görürsün: decompiler çıktısı bazen beklediğinden farklı olur.

Assembly: İşlemci mimarisine (x86/x64, ARM vb.) özgü, talimatların sembolik ve okunabilir temsili.

Makine kodu (binary / opcode): Dosya içinde bayt dizileri olarak duran, işlemcinin doğrudan yürüttüğü talimatlar.

Bu zinciri bilmek, analiz araçlarının neden bazen “en iyi tahmin” ürettiğini anlamanı sağlar. Ghidra/IDA gibi araçlar, elindeki binary’den geriye doğru giderek sana disassembly ve decompile görünümü sunar; ancak isimler, tipler ve bazı kontrol akışları bire bir geri gelmeyebilir.

Örnek: Kaynak kodda tek satır gibi görünen bir if koşulu, assembly’de birkaç karşılaştırma ve dallanma talimatına bölünür; decompiler ise bunu farklı bir ifadeyle toparlayabilir.

İpucu: Raporda “kod okuma” kısmı yazıyorsan, kaynağı açık belirt: “disassembly/decompiler çıktısı üzerinde kontrol akışı ve çağrı ilişkileri incelendi” gibi. Bu, “neye dayanarak söylüyorsun?” sorusunun cevabını güçlendirir.

2. Basit C yapılarını assembly’de tanımak

İşlemci if, for gibi yapıları “bilmez”; o, veriyi taşır, karşılaştırır ve bir adrese dallanır. Orta seviyede önemli olan, bu mikro hareketlerin C’deki makro mantığa nasıl karşılık geldiğini sezebilmektir.

2.1. Değişkenler ve atamalar: “isimler kaybolur, roller kalır”

Binary seviyesinde değişken isimleri çoğunlukla yoktur. Değerler:

register’larda (yazmaçlarda),

stack üzerindeki konumlarda,

bazen global bellek adreslerinde taşınır. Bu yüzden “x değişkeni” yerine “bu değer şu aralıkta şu rolü oynuyor” diye düşünmek daha sağlıklıdır.

Örnek: Decompiler’da v1, v2, v3 gibi isimler görmek, gerçek isimleri bulduğun anlamına gelmez; araç sadece geçici etiket atıyordur. Bu durum özellikle optimizasyonlu derlemelerde daha belirgindir.

Örnek: C’deki x = 5; ataması, assembly’de çoğu zaman “bir yere veri taşıma” şeklinde görünür. mov \[rbp-4\], 5 gibi bir ifade, yığındaki (stack) bir yerel konuma 5 yazıldığını düşündürür.

2.2. Koşullar: karşılaştırma + dallanma (compare/jump)

Koşullar çoğu zaman iki adımda görünür: önce bir cmp/compare, ardından bir koşullu jump.

Örnek: cmp eax, 0 (eax’i 0 ile karşılaştır) ardından jne 0x401050 (eşit değilse başka yere dallan) Bu kalıp, C’de bir if kontrolünün tipik izidir.

Bu yapı, savunma açısından şu soruyu yanıtlar: “Davranış her zaman mı oluyor, yoksa belirli koşulda mı açılıyor?”

Örnek: Statik tarafta şüpheli bir alan adı/dize görüp dinamikte her zaman tetiklenmediğini fark ettiğinde, decompiler çıktısında bu dizenin kullanıldığı bloğun üstündeki koşul kontrolü, “neden her seferinde çalışmadı?” sorusuna açıklama getirebilir.

2.3. Döngüler: sayaç + kontrol + geri dönüş

for/while gibi döngüler genelde:

sayaç değerinin değişmesi,

bir kontrol karşılaştırması,

döngünün başına geri zıplama izleriyle yakalanır.

Örnek: Kodun sonunda bir jmp ile birkaç satır yukarıdaki bir cmp kontrolüne dönüldüğünü görüyorsan, bu yapı çoğu zaman tekrar eden bir akışın işaretidir.

Dikkat: Döngü görmek “kesin beacon/C2” demek değildir. Döngü normal yazılımlarda da çok yaygındır. Anlamlı olan, döngünün içinde neyin tekrarlandığıdır (ağ çağrısı mı, dosya işlemi mi, bekleme mi?). Kanıt gücünü bağlam belirler.

3. Fonksiyon çağrısı, stack frame ve calling convention: okuma rehberi

Bir fonksiyon çalışırken kendine geçici bir alan açar; buna stack frame (yığın çerçevesi) denir. Fonksiyonun başındaki ve sonundaki kalıplar, akışı hızlı anlamanı sağlar.

3.1. Prologue/Epilogue: fonksiyonun “kapı eşiği”

Prologue (giriş): yeni bir fonksiyon alanı kurulur. push rbp ve mov rbp, rsp gibi kalıplar sık görülür.

Epilogue (çıkış): alan toparlanır ve dönüş yapılır. pop rbp ve ret gibi talimatlar tipiktir.

Bu kalıpları tanımak “fonksiyon nerede başlıyor/bitiyor?” sorusunu hızlandırır.

3.2. Calling convention: parametreler nasıl taşınır?

Parametrelerin register/stack üzerinden taşınma kuralları “calling convention” olarak anılır. Orta seviyede amaç, ezber yapmak değil; şu tür çıkarımları daha güvenli yapmak:

“Bu çağrı hangi girdilerle yapılmış olabilir?”

“Çağrıdan sonra hangi değer geri dönmüş gibi görünüyor?”

“Geri dönüş değeri karar veren bir koşulda kullanılmış mı?”

Örnek: Bir çağrıdan sonra kontrol akışının hemen bir cmp/jump ile dallandığını görüyorsan, fonksiyonun geri dönüş değeri “karar” için kullanılıyor olabilir.

İpucu: Decompiler’ın fonksiyon imzası (parametre sayısı/tipleri) her zaman güvenilir değildir. Şüpheli bir yerde “kesin” yazmak yerine, kanıt gücüne uygun ifade kur: “muhtemelen şu tür girdilerle çağrılıyor” gibi. Bu, yanlış yönlendirmeyi azaltır.

4. Decompiler çıktısını doğru okumak ve doğrulamak

Decompiler, assembly’den C’ye benzer bir görünüm üretir; fakat bu çıktı orijinal kaynak kod değildir.

Neden farklı görünebilir?

İsim kaybı: Değişken/fonksiyon isimleri binary’de yoktur; araç geçici isimler verir.

Tip belirsizliği: Tür bilgileri net değildir; araç tahmin eder.

Optimizasyon etkisi: Derleyici satırları birleştirir, yer değiştirir, bazı değişkenleri tamamen ortadan kaldırır.

Kontrol akışı dönüşümü: Döngü/switch yapıları farklı bir formda görünür.

Örnek: Kaynak kodda “anlamlı” bir isimle yazılmış bir dize, decompiler’da s1 gibi bir isimle görünebilir; bu bir şifreleme işareti değil, sembol bilgisinin olmamasının doğal sonucudur.

Dikkat: Decompiler çıktısı “en iyi tahmin”dir. Mantık kırılıyorsa ya da bölüm çok kritikse, disassembly’ye inerek kontrol akışını doğrulamak gerekir. Bu disiplin, raporda “yanlış kesinlik” riskini ciddi biçimde düşürür.

İpucu: Analiz aracında fonksiyon ve değişken isimlerini rolüne göre yeniden adlandırmak büyük fark yaratır. Sürekli ağ iletişimiyle ilişkili görünen bir sub_4012A0 fonksiyonunu, notlarında “Ağ_Bağlantısı_Kur” gibi bir isimle anmak bile, ilerleyen okumalarda zihinsel yükü azaltır.

5. Kritik yollar yaklaşımı: 10.000 satırda kaybolmadan kanıt toplamak

Orta seviye bir analistin başarısı, her satırı çözmekten çok davranışın tetiklendiği anahtar yolları bulabilmesidir. Bu, bir labirentte her koridora girmek yerine, “çıkışa giden işaretleri” takip etmek gibidir.

Kritik yolları ararken tipik odaklar:

Ağ iletişimini başlatan çağrılar ve bu çağrılara giden koşullar

Dosya yazma/çalıştırma gibi yüksek riskli eylemlerin tetiklendiği dallar

Kriptografik işlemlerin döngüler içinde yoğunlaştığı bölgeler (etki analizi için sinyal)

Uzun süre arka planda çalışma hissi veren sonsuz döngüler (ör. while(1) tarzı yapıların decompile görünümü)

Örnek: Decompiler’da while(1) benzeri bir yapı görüp içeride düzenli aralıklarla bir kontrol çağrısı fark edersen, bu kod parçası bir “bekleme/izleme” mantığına işaret ediyor olabilir. Savunma tarafında bu, “hangi telemetri kaynağında sürekli tekrar eden sinyal beklerim?” sorusuna katkı verir.

Örnek: Bazı sabit değerler (“magic constant”) bir kontrolün anahtarı olabilir. Hex bir değer bazen bir dosya imzasına, bazen ASCII karşılığı anlamlı bir iki karaktere, bazen de bir protokol alanına denk gelir. Bu tür sabitler, “bu kontrol neyi ayırt ediyor?” sorusunu yanıtlamaya yardım eder.

Bu yaklaşımın ileri doğrulama/tersine mühendislik tarafı, İleri Malware Analizi & Reverse Engineering eğitiminde ayrıntılı ele alınacaktır.

Dikkat: Bazı örneklerde “ölü kod / junk code” (gürültü amaçlı anlamsız işlemler) çok olabilir.Binlerce satır matematiksel gürültü arasında tek bir call gerçek eylemi tetikleyebilir. Burada amaç, gürültüye takılmadan kritik çağrılara giden yolu bulmaktır; karartma tekniklerinin ayrıntılı sınıflandırması ileri seviyeye bırakılır.

Terimler Sözlüğü

Terim	Açıklama
Compiler	Derleyici; kaynak kodu daha düşük seviyeli temsile çeviren araç
IR (Intermediate Representation)	Ara temsil; derleyicinin optimizasyon yaptığı ara form
Assembly	İşlemci talimatlarının sembolik, okunabilir temsili
Binary / Machine code	Makine kodu; işlemcinin yürüttüğü ikili talimatlar
Opcode	İşlem kodu; talimatın sayısal karşılığı
Disassembly	Binary’nin assembly olarak çözümleme çıktısı
Decompile / Decompiler	Binary’den C benzeri yüksek seviye görünüm üretme süreci/aracı
Register	Yazmaç; işlemci içindeki hızlı küçük depolama alanı
Stack (Yığın)	Parametreler, dönüş adresleri ve yerel veriler için kullanılan geçici bellek alanı
Stack frame	Bir fonksiyonun çalışırken kullandığı yığın çerçevesi
Calling convention	Parametrelerin/geri dönüşün nasıl taşındığını belirleyen çağrı kuralı
Prologue / Epilogue	Fonksiyon giriş/çıkış talimat kalıpları
Control flow	Kontrol akışı; dallanma/döngülerle izlenen yürütme yolları
Data flow	Veri akışı; değerlerin kaynak-hedef arasında taşınma biçimi
Optimization	Optimizasyon; derleyicinin hız/ölçek amaçlı dönüşümleri
Magic constant	Anlam taşıyan sabit değer; imza/anahtar/protokol alanı gibi ipuçları
Junk code	Gürültü amaçlı anlamsız “ölü” kod parçaları
Critical path	Davranışı tetikleyen kritik yol; yüksek değerli akış hattı

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1)Decompiler çıktısını “kaynak kod” sanmak, raporda en çok hangi riski doğurur?

A) Hash değerinin değişmesi

B) Yanlış kesinlikte yorumla savunma aksiyonunu hatalı kalibre etmek

C) DNS kayıtlarının tutulmaması

D) Sandbox’ın rapor üretmemesi

E) IOC’lerin alfabetik sıralanmaması

Doğru: B
Gerekçe: Decompiler “en iyi tahmin”dir; kesin konuşmak yanlış bloklama/yanlış negatif riskini artırır. Diğer şıklar doğrudan ilgili değildir.

2)Binary seviyesinde değişken isimlerinin çoğunlukla görünmemesi en doğru nasıl yorumlanır?

A) Kod okunamaz hâle gelir

B) Araçlar her zaman isimleri geri getirir

C) İsimler yerine değerlerin rolü register/stack bağlamından çıkarılmalıdır

D) Sadece ağ trafiği yeterlidir

E) Rapor yazmak imkânsızdır

Doğru: C
Gerekçe: İsim kaybı normaldir; analiz “isim” değil “akış/rol” okumaya dayanır.

3)cmp eax, ebx komutunun ardından je 0x405000 görülmesi C mantığında en çok neye benzer?

A) eax = ebx;

B) while (eax != ebx)

C) if (eax == ebx) { /* o bloğa geç */ }

D) for (i=0; i

E) return eax;

Doğru: C
Gerekçe: cmp karşılaştırır, je eşitse dallanır; bu bir koşul kontrolüdür. Diğerleri farklı yapıların karşılığıdır.

4)push rbp / mov rbp, rsp ile başlayan ve pop rbp / ret ile biten kalıp genelde neyi işaret eder?

A) Bir döngüyü

B) Standart bir fonksiyon çerçevesini (stack frame)

C) Dosya silme işlemini

D) Ağ bağlantı hatasını

E) Şifre çözmeyi

Doğru: B
Gerekçe: Bu prologue/epilogue dizisi, fonksiyon giriş-çıkış düzenini kurar.

5)Assembly’deki call talimatının en genel anlamı nedir?

A) Döngü başlatmak

B) Değişken tanımlamak

C) Bir fonksiyonu/alt rutini çağırmak

D) Programı sonlandırmak

E) Veriyi rastgeleleştirmek

Doğru: C
Gerekçe: call, başka bir yürütme bloğuna gider ve dönüş adresini saklar; bu fonksiyon çağrısı mantığıdır.

6)Decompiler çıktısının kaynak koddakinden farklı görünmesinin en tipik nedeni hangisidir?

A) DNS önbelleği

B) Derleyici optimizasyonları + tip/sembol bilgisinin kaybı

C) Proxy ayarı

D) Hash çakışması

E) Ekran çözünürlüğü

Doğru: B
Gerekçe: İsim/tip kaybı ve optimizasyonlar, görünümü ciddi biçimde değiştirir.

7)“Kritik yollar” yaklaşımı neden önemlidir?

A) Kod okumak yasak olduğu için

B) Zararlılar binlerce satır gürültü/junk code içerebileceği için asıl eylemi tetikleyen sınırlı bölüme odaklanmak gerekir

C) Sadece 64-bit sistemlerde çalıştığı için

D) Araçlar sadece kritik yolu gösterebildiği için

E) Analistin ekran görüntüsü sayısını artırmak için

Doğru: B
Gerekçe: Zaman/odak yönetimi, savunma için değerli akış hatlarına yoğunlaşmayı gerektirir.

8)Kodda döngü yapısı görmek ile dinamikte periyodik davranış görmek birlikte nasıl ele alınmalıdır?

A) Döngü varsa mutlaka C2’dir

B) Periyodik davranış her zaman zararlıdır

C) Döngü tek başına hüküm değildir; döngü içeriği ve çağrılarla birlikte kanıt gücü artar

D) Dinamik gözlem yanlış kabul edilir

E) Döngüler yalnızca temiz yazılımda olur

Doğru: C
Gerekçe: Döngü geneldir; anlamı bağlam ve tekrar eden eylem belirler. Diğer şıklar hatalı genellemedir.

9)Decompiler’da if (var_8 == 0x5342) gibi bir kontrol gördüğünde, 0x5342’nin anlamını çözmek için en sağlıklı ilk refleks hangisidir?

A) Bilgisayarı yeniden başlatmak

B) Değeri olası anlam katmanlarıyla yorumlamak: ASCII karşılığı, bilinen imza/protokol alanı gibi olasılıkları değerlendirmek

C) Dosya boyutunu kontrol etmek

D) Değişkeni “Şüpheli” diye adlandırıp geçmek

E) Kodu kapatıp raporu bitirmek

Doğru: B
Gerekçe: Magic constant’lar çoğu zaman bir “ayırıcı anahtar”tır; anlamını çözmek kontrolün amacını netleştirir.

10)xor eax, eax talimatının en yaygın kullanım amacı hangisidir?

A) eax yazmacını hızlıca 0’lamak

B) Veriyi internete göndermek

C) Bilgisayarı kapatmak

D) Rastgele sayı üretmek

E) Dosya sıkıştırmak

Doğru: A
Gerekçe: Bir değeri kendisiyle XOR’lamak 0 üretir; bu, register sıfırlamanın yaygın ve verimli yoludur.

Bu Modülde Kazanılan Yetkinlikler

Kodun source → IR → assembly → binary hattında nasıl dönüştüğünü ve analiz araçlarının bu hattı nasıl tersine çevirdiğini anladın
Değişken/koşul/döngü gibi temel C mantıklarının assembly’de hangi kalıplarla göründüğünü okuyabilir hâle geldin
Prologue/epilogue, stack frame ve calling convention kavramlarını ezber değil “yorumlama” amaçlı kullanmayı öğrendin
Decompiler çıktılarının neden yanıltıcı olabileceğini ve kritik yerlerde disassembly ile doğrulama disiplinini kazandın
Satır satır boğulmadan, davranışı tetikleyen kritik yolları bulup savunma raporuna kanıt olarak taşıma yaklaşımını geliştirdin