Temiz Kurtarma Noktası Seçimi: Yedekte Zararlı Tarama ve IOC

Fidye saldırısından sonra en sık verilen yanlış karar, şifrelemeden hemen önceki yedeğe dönmektir. Saldırgan ağda günlerce, bazen haftalarca kalmış olabilir ve o süre boyunca alınan her yedek onun hesaplarını, kalıcılık mekanizmalarını ve araçlarını da taşır. Son yedek, son temiz yedek değildir. Aşağıda son temiz kurtarma noktasını bulmak için saldırı zaman çizelgesinin nasıl çıkarılacağını, yedekte zararlı taraması, IOC ve YARA araması ile şifreleme belirtilerinin nasıl kullanılacağını ve bulguların bir karar tablosunda nasıl birleştirileceğini anlatıyoruz.

Son yedek neden güvenli olmayabilir

Bir yedek üç farklı anlamda “temiz” olabilir. Bunları birbirine karıştırmayın:

• Şifrelenmemiş: Veriler okunabilir durumda. En düşük eşik budur.
• Zararlı içermeyen: Bilinen zararlı dosyalar, araçlar ve web kabukları yok.
• Saldırgan değişikliği içermeyen: Saldırganın açtığı hesaplar, servisler, zamanlanmış görevler, grup ilkesi değişiklikleri ve güvenlik duvarı istisnaları yok.

Şifrelemeden bir gün önceki yedek genellikle ilk koşulu sağlar; ikinci ve üçüncüyü çoğu zaman sağlamaz. Üçüncüsü en zorudur, çünkü saldırganlar sıklıkla meşru yönetim araçlarını kullanır ve bu değişiklikler antivirüs taramasında görünmez. Bu yüzden kurtarma noktası tek bir taramayla seçilmez; zaman çizelgesi ve birden fazla yöntem birlikte kullanılır.

Kurtarma noktası seçimi ile veri kaybı arasında bir denge de var. Daha eski bir nokta kurumsal siber güvenlik açısından daha güvenli olabilir, ama aradaki iş verisi gider. Dengeyi kurmanın yolu sistemi ve veriyi ayrı düşünmektir: işletim sistemi ve uygulama daha eski, temiz bir noktadan; iş verisi taranarak daha yeni bir noktadan geri yüklenebilir.

Saldırı zaman çizelgesinin çıkarılması

Kurtarma noktası kararı, saldırının ne zaman başladığına dair en iyi tahmine dayanır. Zaman çizelgesi şu kaynaklardan derlenir:

Kaynak	Aranan iz
EDR telemetrisi	İlk şüpheli süreç, yanal hareket, kimlik bilgisi erişimi
Domain denetleyicisi Security logu	Yeni hesap (4720), güvenlik grubuna ekleme (4728, 4732, 4756)
Sunucuların System ve Security logları	Yeni servis kurulumu (System 7045), zamanlanmış görev oluşturma (Security 4698, denetim açıksa)
VPN ve güvenlik duvarı logları	Olağan dışı kaynaktan başarılı oturumlar, büyük veri çıkışı
Yedek konsolu logları	İş silme, saklama değişikliği, oturum açma
Yedek iş istatistikleri	Artımlı yedek boyutunda ani artış

Çizelgedeki en erken güvenilir saldırı izi, aramanın başlangıç sınırıdır. Bu tarihten önceki noktalar “aday temiz”, sonrakiler “şüpheli” kabul edilir. Logların saklama süresi kısaysa ya da saldırgan logları sildiyse sınır bulanıklaşır; o zaman aday nokta daha geriye çekilir ve yedekteki inceleme ağırlık kazanır. Sahada en sık gördüğümüz sorun DC Security logunun birkaç günlük kapasiteyle dönüp durmasıdır. İz çoktan üzerine yazılmıştır. Konsoldaki saldırı belirtilerini önceden izlemek bu aşamayı kolaylaştırır; ayrıntılar yedek altyapısına yönelik saldırı belirtileri yazısında.

Yedekte zararlı tarama yöntemleri

Yedekteki diskleri taramanın üç yolu var ve hepsinde temel kural aynı: disk salt okunur bağlanır, tarama da üretimden ve yedek sunucusundan ayrı bir sistemde yapılır.

1. Yedek yazılımının yerleşik taraması: Veeam Backup & Replication’ın Secure Restore özelliği, geri yükleme öncesinde diskleri bağlayıp antivirüsle tarar. Sürüm 12.1 ile gelen kötü amaçlı yazılım tespiti ve yedek tarama özellikleri, son temiz kurtarma noktasının aranmasını ve YARA kurallarıyla taramayı da kapsar; özelliklerin kapsamını kullandığınız sürümün dokümantasyonundan doğrulayın.
2. Diskleri bir tarama sunucusuna bağlamak: Yedek yazılımının disk yayınlama veya bağlama özelliğiyle kurtarma noktası bir Linux ya da Windows tarama sunucusuna salt okunur bağlanır, istenen araçlar çalıştırılır.
3. İzole ortamda açmak: Sistem ağsız açılır, EDR ile canlı tarama yapılır. Kalıcılık kontrolü için en kapsamlı yöntem budur; ortam tasarımı izole kurtarma ortamı yazısında.

Aşağıdaki örnek, dışa aktarılmış bir sanal diski Linux tarama sunucusuna salt okunur bağlayıp ClamAV ile tarıyor. Disk biçimi ve bölüm numarası ortama göre değişir; lsblk ile kontrol edin. -o ro parametresini atlamayın.

sudo modprobe nbd max_part=8
sudo qemu-nbd --read-only --connect=/dev/nbd0 /yedek/inceleme/srv-app01.vmdk
lsblk /dev/nbd0
sudo mkdir -p /mnt/rp
sudo mount -t ntfs-3g -o ro /dev/nbd0p2 /mnt/rp

sudo clamscan -r -i --log=/inceleme/srv-app01-clam.log /mnt/rp

# İş bitince
sudo umount /mnt/rp
sudo qemu-nbd --disconnect /dev/nbd0

IOC ve YARA kuralı ile arama

İmza tabanlı tarama, olayda kullanılan özel araçları veya yeniden derlenmiş zararlıları kaçırabilir. Olay müdahalesinde elde edilen göstergeler (dosya hash değerleri, dosya adları, yollar, alan adları) yedekte doğrudan aranmalıdır. Hash araması basit ama iş görür:

# ioc-sha256.txt: her satırda bir küçük harfli SHA-256 değeri
sudo find /mnt/rp -type f -size -100M -print0 |
  sudo xargs -0 sha256sum 2>/dev/null |
  grep -F -f ioc-sha256.txt

# Belirli bir zaman aralığında değişen çalıştırılabilir dosyalar (örnek tarih aralığı;
# zaman damgaları saldırgan tarafından değiştirilmiş olabilir)
sudo find /mnt/rp -type f \( -iname '*.exe' -o -iname '*.dll' -o -iname '*.ps1' \) \
  -newermt '2026-09-20' ! -newermt '2026-10-05'

YARA kuralları dosya içindeki dizgi ve bayt desenlerine göre arama yapar ve bir zararlı ailesinin varyantlarını hash aramasından daha iyi yakalar. Kurallar olay müdahale ekibinden, güvenilir tehdit istihbaratı kaynaklarından veya olayda bulunan örneklerden türetilebilir. Taramayı tüm disk yerine yüksek riskli yollarla başlatmak süreyi kısaltır:

yara -r -w olay-kurallari.yar "/mnt/rp/Windows/System32/Tasks" > yara-tasks.txt
yara -r -w olay-kurallari.yar "/mnt/rp/ProgramData" > yara-programdata.txt
yara -r -w olay-kurallari.yar "/mnt/rp/Users" > yara-users.txt

Eşleşme bulunursa aynı arama bir önceki kurtarma noktasında tekrarlanır. Böylece göstergenin yedeklerde ilk göründüğü nokta bulunur; bu nokta çizelgedeki başlangıç sınırını ya doğrular ya da daha geriye çeker. İkinci durum sandığınızdan sık yaşanır.

Şifreleme belirtileri: entropi ve değişim oranı

Şifrelenmiş dosyalar rastgele veriye yakın görünür; bayt başına Shannon entropisi teorik üst sınır olan 8 bit değerine yaklaşır. Ama sıkıştırılmış biçimler de yüksek entropi gösterir, yani tek bir dosyanın entropisi kanıt değildir. Daha güvenilir göstergeler şunlar:

• Kurtarma noktaları arasındaki değişim: Normalde düşük entropili dosya türlerinde (düz metin, CSV, bazı veritabanı dışa aktarımları) iki nokta arasında ani entropi artışı.
• Artımlı yedek boyutu: Toplu şifreleme çok sayıda bloğu değiştirir, artımlı yedek boyutu olağan düzeyin çok üzerine çıkar.
• Dosya adı ve uzantı değişimi: Çok sayıda dosyanın aynı yeni uzantıyı alması veya her klasörde aynı adlı fidye notu.
• Toplu silme veya yeniden adlandırma: Dosya sistemi dizinleri karşılaştırıldığında kısa sürede binlerce dosyanın kaybolması.

Bu göstergeler şifrelemenin hangi noktada başladığını bulmaya yarar; saldırganın daha önceki varlığını göstermez. Şifreleme belirtisi olmayan bir nokta yalnızca birinci düzeyde temizdir. Gerisi ayrı iş.

Kurtarma noktası karar tablosu

Bulgu	Değerlendirme	Eylem
Şifreleme belirtisi var	Kullanılamaz	Daha eski noktaya geç
IOC veya YARA eşleşmesi var	Ele geçirilmiş	Göstergenin ilk göründüğü noktadan öncesine geç
Eşleşme yok, nokta saldırı başlangıcından sonra	Şüpheli	Yalnız veri geri yükle veya izole ortamda kalıcılık kontrolü yap
Eşleşme yok, nokta saldırı başlangıcından önce	Aday temiz	İzole ortamda doğrula, sonra kullan
Hiçbir aday nokta yok	Temiz nokta bulunamadı	Sistemi yeniden kur, yalnız taranmış veriyi aktar

Kararı sistem bazında kayda alın: hangi kurtarma noktası seçildi, hangi taramalar hangi kural ve imza sürümüyle yapıldı, sonuçlar neydi, kim onayladı. Bu kayıt hem yeniden enfeksiyonda geriye dönük analiz hem de olay sonrası raporlama için gerekir. Olaydan iki hafta sonra kimse neyi neden seçtiğini hatırlamaz.

Kalıcılık mekanizmalarının kontrolü

Zararlı taraması ve IOC araması temiz çıkan bir noktada bile saldırganın değişiklikleri bulunabilir. Bu yüzden aday temiz noktada, bağlanmış disk üzerinden veya izole ortamda şu konumlara bakılır:

• Zamanlanmış görevler: Windows\System32\Tasks altındaki XML dosyaları ve oluşturma tarihleri.
• Servisler: SYSTEM kayıt defteri hive’ındaki Services anahtarı; bilinmeyen yollar ve geçici klasörlerden çalışan servisler.
• Otomatik başlatma: SOFTWARE ve kullanıcı NTUSER.DAT hive’larındaki Run ve RunOnce anahtarları, başlangıç klasörleri.
• WMI olay abonelikleri: Windows\System32\wbem\Repository içeriği.
• Uzak erişim araçları: olağan dışı RMM veya uzak masaüstü yazılımları.
• Domain denetleyicilerinde SYSVOL altındaki grup ilkesi betikleri ve yeni oluşturulmuş grup ilkesi nesneleri.
• Linux sunucularda /etc/cron*, kullanıcı crontab’ları, /etc/systemd/system ve ~/.ssh/authorized_keys dosyaları.

Domain denetleyicilerinde kalıcılık şüphesi tam giderilemiyorsa kurtarma noktası aramayı bırakıp forest kurtarma yaklaşımına geçin; adımlar fidye saldırısı sonrası AD forest kurtarma yazısında.

Bu karar sürecinin olay anında hızlı işlemesi; yeterli değiştirilemezlik süresine, logların saklanmasına ve önceden hazırlanmış tarama araçlarına bağlıdır. Hazırlığın gözden geçirilmesi siber olay müdahale hazırlığı ve tatbikat, yedek tarafı ise yedekleme güvenliği ve fidye yazılımına hazırlık çalışmamızın kapsamındadır. Kural yazımı için birincil kaynak YARA dokümantasyonudur.

Sık sorulan sorular

Şifrelemeden hemen önceki yedek neden güvenli kabul edilmez?

Çünkü şifreleme saldırının son aşamasıdır. Saldırgan ağa çok daha önce girmiş, hesap açmış, servis veya zamanlanmış görev gibi kalıcılık mekanizmaları kurmuş olabilir. Şifreleme öncesindeki yedek bu değişiklikleri de içerir; geri yüklediğinizde saldırganın erişimi de geri gelir.

Antivirüs taraması temiz çıkan yedek güvenli midir?

Tek başına bunu göstermez. İmza tabanlı tarama bilinen zararlıları yakalar; meşru yönetim araçlarıyla kurulan kalıcılığı, saldırganın açtığı hesapları veya değiştirilmiş yapılandırmaları görmez. Tarama sonucunu IOC araması, kalıcılık kontrolü ve olay zaman çizelgesiyle birlikte değerlendirin.

Entropi analizi yanlış alarm üretir mi?

Evet. Sıkıştırılmış ve şifreli biçimler, örneğin zip, jpeg, mp4 ya da docx ve xlsx gibi Office belgeleri doğası gereği yüksek entropi gösterir. Entropiyi tek dosya düzeyinde değil; klasördeki dosya türüne göre beklenen değer ve kurtarma noktaları arasındaki ani değişim üzerinden yorumlayın.

Temiz bir kurtarma noktası bulunamazsa ne yapılır?

Sistem en eski uygun yedekten geri yüklenip izole ortamda temizlenebilir ya da sıfırdan kurulup yalnızca veri yedekten aktarılabilir. Domain denetleyicileri ve yönetim sunucuları gibi kritik sistemlerde kalıcılık şüphesi giderilemiyorsa yeniden kurulum genellikle daha güvenli yoldur.