Siber Olay Sonrası Adli Delil Koruma: Neyi Silmeden Saklamalı?

Fidye saldırısının ilk saatlerinde herkes sistemleri geri getirmeye koşar ve en değerli kanıtı o koşuşturmada kendi eliyle siler. Yeniden başlatılan sunucular, biçimlendirilen diskler, dolup üzerine yazılan olay günlükleri, saklama süresi dolduğu için silinen snapshot’lar: saldırganın nasıl girdiğini ve neyi aldığını gösterecek her şey gider. Bu rehber, kurtarmayı geciktirmeden hangi delillerin hangi sırayla ve nasıl korunacağını anlatır.

Kurtarma ile delil koruma çatışması

Kurumsal siber güvenlik olaylarında delil korumanın amacı yalnız hukuki süreç değildir. İlk erişim noktası, kullanılan hesaplar, kalıcılık mekanizmaları ve sızıntının kapsamı bilinmeden yapılan kurtarma, saldırganı aynı kapıdan geri çağırır. Kişisel veri ihlali bildirimi, sigorta talebi ve müşteri bilgilendirmesi de bu bulgulara dayanır. Delil yoksa cevap da yok.

Çatışma şu noktalarda patlar:

• Etkilenen sanal makineyi yedekten aynı yere geri yüklemek, orijinal diskin üzerine yazar.
• Sunucuyu yeniden başlatmak bellekteki süreçleri, ağ bağlantılarını ve enjekte edilmiş kodu siler.
• Toplu antivirüs temizliği, zararlı dosyaları ve zaman damgalarını değiştirir.
• Dolu olay günlükleri, yeni olaylarla döngüsel olarak üzerine yazılır.
• Yedek yazılımının saklama politikası, saldırı dönemine ait geri yükleme noktalarını otomatik olarak siler.

Pratik ilke basit: kurtarma yeni hedeflere yapılır, orijinaller dondurulur. Bunun için delil saklamaya ayrılmış kapasite ve kurtarmanın yapılacağı ayrı bir ortam önceden planlanmış olmalı; olay günü bunları sıfırdan kurmaya kimsenin vakti olmaz. Kurtarma ortamının tasarımı izole kurtarma ortamı rehberinde ayrıca anlatılıyor.

Oynaklık sırası

RFC 3227, delillerin en oynak olandan en kalıcı olana doğru toplanmasını önerir. Bir kaynak ne kadar çabuk kayboluyorsa o kadar önce korunur. Aşağıdaki tablo bu sırayı tipik bir Windows ve sanallaştırma ortamına uyarlar.

Delil türü	Oynaklık	Kaybolma nedeni	Koruma yöntemi
Bellek, süreçler, ağ bağlantıları	Çok yüksek	Kapatma, yeniden başlatma	Bellek imajı, bellekli VM snapshot
Geçici dosyalar, sayfa dosyası	Yüksek	Yeniden başlatma, temizlik	Disk imajı içinde
Yerel olay günlükleri	Orta–yüksek	Döngüsel üzerine yazma, silme	Dışa aktarma, merkezi log
Disk içeriği	Orta	Yeniden kurulum, geri yükleme	Disk imajı, snapshot
Firewall, proxy, EDR, bulut logları	Orta	Saklama süresi sınırı	Saklama süresini uzatma, dışa aktarma
Yedekler ve arşivler	Düşük–orta	Saklama politikası	Saklama kilidi, ayrı kopya

Firewall, proxy ve bulut logları kalıcı görünür ama saklama süreleri çoğu zaman kısadır. Olayı fark ettiğiniz gün, bu kaynakların ilk erişim dönemini silmek üzere olduğu gün de olabilir. Bu yüzden ilk saatlerde saklama süresini uzatmak veya ham veriyi dışa aktarmak listenin üst sırasına çıkar. Sahada en çok kaybedilen delil budur.

Bellek ve disk imajı alma yaklaşımları

Sanal makineler

Sanallaştırma delil toplamayı kolaylaştırır. VMware vSphere’de belleği dahil eden bir snapshot, bellek içeriğini ayrı bir dosyaya yazar; Hyper-V’de makineyi kaydedilmiş duruma almak bellek durumunu benzer biçimde diske yazar. Ardından sanal disk ve bellek dosyaları, üretimden bağımsız delil deposuna kopyalanır. Konuk işletim sistemine araç kurmak gerekmez ve saldırganın konuk içindeki müdahalesi bu işlemi etkilemez.

Bir şartla: hipervizörün kendisi de etkilenmiş olabilir. Şifreleme hipervizör katmanında yapıldıysa snapshot almak mümkün olmayabilir; o zaman depolama dizisinin snapshot özelliği veya ham LUN kopyası kullanılır.

Fiziksel sunucular ve istemciler

Fiziksel sistemlerde bellek imajı, işletim sistemi çalışırken özel bir araçla alınır (Windows için WinPmem veya Magnet RAM Capture gibi araçlar, Linux için AVML veya LiME). Aracı harici ve yazmaya karşı korumalı bir medyadan çalıştırın, çıktıyı da harici bir diske yazın; sistem diskine yazılan her dosya potansiyel bir delilin üzerine yazabilir. Disk imajı ise sistem kapatıldıktan sonra donanımsal yazma engelleyiciyle veya canlı sistemde mantıksal imaj olarak alınır. Yaygın biçimler ham (raw/dd) ve meta veri ile hash taşıyan E01’dir.

Yöntem ne olursa olsun, imaj alınır alınmaz hash değeri hesaplanır ve kayda geçer. Windows ve Linux’ta örnek:

# Windows (PowerShell)
Get-FileHash -Algorithm SHA256 -Path E:\Delil\SRV-FS01-mem.raw |
  Format-List Path, Hash

# Linux
sha256sum /mnt/delil/srv-fs01-disk0.raw | tee /mnt/delil/srv-fs01-disk0.raw.sha256

Hash değeri delil zinciri kaydına yazılır. İnceleme her zaman bir kopya üzerinde yapılır ve kopyanın hash’i orijinalle karşılaştırılır. Orijinale dokunulmaz.

Log kaynaklarının korunması

Saldırganlar iz silmek için Windows Güvenlik günlüğünü temizleyebilir; günlüğün varsayılan boyutu da yoğun bir sunucuda çok kısa bir süreyi kapsar. Olay anındaki ilk iş, etkilenen ve şüpheli sistemlerdeki günlükleri dışa aktarmak ve gerekirse boyut sınırını büyütmektir. Konsolda ilk bakılacak yer burasıdır.

REM Günlükleri dışa aktarma (yükseltilmiş komut istemi)
wevtutil epl Security E:\Delil\DC01-Security.evtx
wevtutil epl System   E:\Delil\DC01-System.evtx
wevtutil epl "Microsoft-Windows-PowerShell/Operational" E:\Delil\DC01-PS.evtx

REM Güvenlik günlüğünün en büyük boyutunu 1 GB yapma (bayt cinsinden)
wevtutil sl Security /ms:1073741824

Öncelik verilmesi gereken diğer log kaynakları:

• Etki alanı denetleyicileri: Kimlik doğrulama, grup üyeliği değişiklikleri, yeni hizmet ve zamanlanmış görev oluşturma olayları.
• Firewall ve VPN: Uzak erişim oturumları ve dışarıya giden büyük veri aktarımları; sızıntının kapsamı çoğunlukla buradan çıkarılır.
• EDR konsolu: Süreç ağacı ve komut satırı telemetrisi; ürünün saklama süresi sınırlı olabilir, ilgili uç noktaların verisini dışa aktarın.
• Bulut ve Microsoft 365: Denetim günlükleri ve oturum açma kayıtları; saklama süresi lisansa bağlıdır, olay dönemi kayıtlarını dışa aktarın.
• Yedek ve hipervizör konsolları: İş silme, saklama değişikliği, konsol oturumları ve hipervizör kabuk erişim günlükleri.

Merkezi log altyapısı varsa delillerin büyük kısmı zaten oradadır. Ama SIEM’in kendi saklama politikası da olay dönemini kapsayacak şekilde dondurulmalı; yoksa SIEM de kendi kayıtlarını sırayla siler. Saklama süresi ve mimari kararları merkezi log saklama mimarisi yazısında ele alınıyor.

Snapshot ve yedeklerin delil olarak saklanması

Saldırı dönemine ait yedekler hem kurtarma hem inceleme için değerlidir. İnceleme ekibi ilk erişim tarihini ve kalıcılık mekanizmalarını bu geri yükleme noktalarını karşılaştırarak bulur; yöntem temiz kurtarma noktası seçimi rehberinde ayrıntılı anlatılır. Sorun şu: yedek yazılımı bu noktaları normal saklama politikasıyla silmeye devam eder. Kimse durdurmazsa, durmaz.

Olay ilan edildiği anda yapılacaklar:

1. Etkilenen sistemleri kapsayan yedek işlerinde otomatik saklama temizliğini durdurun veya ilgili geri yükleme noktalarını süresiz saklamaya alın.
2. Saldırı dönemini kapsayan geri yükleme noktalarının ayrı bir kopyasını, üretim yedek zincirinden bağımsız bir hedefe alın.
3. Depolama dizisi ve hipervizör snapshot’larının otomatik silinmesini engelleyin; ürün destekliyorsa saklama kilidi uygulayın.
4. Delil olarak ayrılan noktaları geri yükleme testinde kullanmayın; kurtarma için ayrı kopya üzerinde çalışın.

Bu adımlar kapasite ister. Delil saklama alanının kabaca etkilenen sistemlerin toplam disk boyutu, bellek boyutu ve saldırı dönemine ait yedek zincirinin toplamı kadar olacağını varsayıp önceden plan yapın. Olay anında kapasite bulunamadığı için delilin feda edildiği durumlar sahada sanıldığından sık yaşanır.

Delil zinciri kaydı

Delil zinciri, bir delilin kim tarafından, ne zaman, nasıl alındığını ve sonra kimlerin eline geçtiğini kesintisiz gösteren kayıttır. Kayıt yoksa delil teknik olarak doğru olsa bile güvenilirliği tartışmaya açılır. NIST SP 800-86 adli bilişim sürecini toplama, inceleme, analiz ve raporlama aşamalarıyla tanımlar; zincir kaydı ilk aşamadan itibaren tutulur.

Alan	Örnek içerik
Delil kimliği	OLY-2026-004-D07
Kaynak	SRV-FS01, sanal disk 0
Yöntem ve araç	Hipervizör snapshot, disk dosyası kopyası
Zaman (UTC dahil)	Alma başlangıcı ve bitişi
Hash	SHA-256 değeri
Alan kişi ve tanık	Ad, rol, imza
Saklama yeri	Delil deposu yolu veya fiziksel kasa
Devir kayıtları	Her teslimde tarih, teslim eden, teslim alan, amaç

Sistem saatlerinin doğruluğu da kayda geçer. Saat sapması olan bir sistemin zaman damgaları, diğer kaynaklarla karşılaştırılırken düzeltme ister; bu yüzden delil alınırken hedef sistemin saati ile referans saat arasındaki fark not edilir. NTP’si bozuk tek bir sunucu bütün zaman çizelgesini kaydırabilir.

İlk müdahale kontrol listesi

• Olay sorumlusu ve delil koruma kararlarını verecek kişi belirlendi mi?
• Etkilenen sistemlerin ağ bağlantısı kesildi, ama gereksiz yere kapatılmadı mı?
• Bellek imajı veya bellekli snapshot, kapatma ya da yeniden başlatmadan önce alındı mı?
• Yerel olay günlükleri dışa aktarıldı, günlük boyutları büyütüldü mü?
• Firewall, VPN, EDR ve bulut loglarının saklama süresi olay dönemini kapsayacak şekilde uzatıldı mı?
• Yedek ve snapshot saklama temizliği durduruldu mu?
• Kurtarma, orijinallerin üzerine değil ayrı hedeflere yapılıyor mu?
• Her delil için hash ve delil zinciri kaydı oluşturuldu mu?

Bu liste ancak araçlar, delil deposu ve yetki kararları önceden hazırsa olay anında işe yarar; genel hazırlık adımları fidye yazılımına karşı kurtarma hazırlığı yazısında. Olay müdahale planınızı delil koruma adımlarıyla birlikte gözden geçirmek ve tatbikatla sınamak için siber olay müdahale hazırlığı ve tatbikat hizmetimize bakabilirsiniz.

Birincil kaynaklar: RFC 3227 ve NIST SP 800-86.

Sık sorulan sorular

Fidye yazılımı bulaşan sunucuyu hemen kapatmak doğru mu?

Çoğu durumda önce ağ bağlantısını kesmek, kapatmaktan iyidir. Kapatma bellekteki süreçleri, ağ bağlantılarını ve bazen şifreleme anahtarı izlerini yok eder. Sanal makinelerde bellekli snapshot veya askıya alma, fiziksel sunucularda bellek imajı alındıktan sonra kapatma tercih edilir. Şifreleme aktif olarak sürüyor ve veri kaybı büyüyorsa, bu kararı olay sorumlusu hızla vermelidir.

Delil olarak saklanan snapshot’lar ne kadar süre tutulmalı?

Süre teknik değil, hukuki ve sözleşmesel bir karardır. Adli inceleme, sigorta süreci, olası dava ve resmi bildirim yükümlülükleri tamamlanana kadar saklanırlar. Bu yüzden delil snapshot’ları normal saklama politikasının dışına alınır, silinmeleri olay sorumlusu ve hukuk biriminin yazılı onayına bağlanır.

Kendi ekibimiz bellek veya disk imajı alabilir mi?

Alabilir; yeter ki araçlar önceden hazırlanmış, prosedür yazılmış ve tatbikatla denenmiş olsun. İmajın değeri, hash değeri ve delil zinciri kaydıyla birlikte saklanmasından gelir. Hukuki süreç öngörülüyorsa imaj alma işini bağımsız bir adli bilişim uzmanıyla birlikte yürütmek, delile itiraz edilme ihtimalini azaltır.

Kurtarma için izole ortama geri yükleme yapmak delilleri bozar mı?

Geri yükleme yedekten yeni bir kopya üretir, kaynağı değiştirmez. Sorun, etkilenen orijinal disklerin veya sanal makinelerin üzerine yazılmasıdır. Orijinal ortamın imajı ve snapshot’ı alınmadan yeniden kurulum yapılmaz, geri yüklemeler ayrı hedeflere yapılır.