Veeam Backup Dosyalarının Adli Bilişim Açısından İncelenmesi

Veeam Backup Dosyalarının Adli Bilişim Açısından İncelenmesi: 2025 yılının Haziran ayında, kritik bir siber olayın ardından bize başvuran büyük ölçekli bir finans kuruluşu, sistemlerinin fidye yazılımı tarafından şifrelenmiş olduğunu bildirdi. Ancak olayın hemen ardından otomatik alınan Veeam yedekleri sayesinde sistemin o anki hali korunmuştu. Kurumun iç ağında kullanılan yedekleme yapısı, tam yedek dosyası olan .VBK uzantılı bir arşiv dosyası içeriyordu. Olay yeri bir sunucu değil, bir dosya yedeğiydi.

İşte adli bilişimde giderek daha sık karşımıza çıkan bu senaryo, yedek dosyalarının sıradan veri kurtarma araçlarıyla değil; delil bütünlüğünü gözeten, olay zamanlamasını analiz eden, sistem davranışlarını geriye dönük olarak inceleyebilecek yöntemlerle ele alınmasını zorunlu hale getiriyor.

Bu yazıda, Veeam yedekleme dosyalarının hem Veeam GUI uygulaması üzerinden hem de komut satırı araçlarıyla nasıl adli amaçlarla analiz edilebileceğini, bir vaka üzerinden örneklendirerek anlatacağız.

Vaka Senaryosu: Fidye Yazılımı Sonrası .VBK Dosyasından Delil Toplama

Kurum, olayın fark edildiği gün Veeam ara yüzünden son alınan yedeğin hala sağlam olduğunu teyit etmişti. O yedeğe ait .VBK dosyası tarafımıza fiziksel disk olarak ulaştırıldı. Dosyanın ilk analizi, hash kontrolüyle başladı. SHA-256 değeri, hem delil bütünlüğünü korumak hem de işlemler boyunca referans almak açısından kritik bir adımdı.

Bu noktada adli inceleme iki kola ayrıldı:

• Yedeği uygulama üzerinden yükleyerek sistemin tam halini izole bir ortamda gözlemlemek,
• Aynı zamanda komut satırı araçlarıyla yedeği dışa aktarıp, dosya düzeyinde derinlemesine inceleme yapmak.

Her iki yolun da avantajları ve dezavantajları vardı. Uygulama daha kullanıcı dostu bir ara yüz sağlarken, komut satırı yöntemleri daha esnek ve incelemeyi kontrol altına alan bir yapı sunuyordu.

Veeam Yedek Dosyalarının Yapısı ve İçeriği

Veeam yedekleme sisteminde kullanılan başlıca dosya türleri:

• .VBK – Tam yedek (Full Backup): Sistem görüntüsünün eksiksiz yedeğini içerir.
• .VIB – Artımlı yedek (Incremental Backup): Önceki yedekten bu yana yapılan değişiklikleri içerir.
• .VRB – Ters artımlı yedek (Reverse Incremental): Tam yedeğe geri dönülebilecek şekilde değişiklikleri kaydeder.

🔍 Adli analizlerde ilk öncelik .VBK dosyalarının incelenmesidir. Diğer dosyalar olayın zaman çizelgesini anlamada yardımcı olur.

1. Uygulama Üzerinden Geri Yükleme ve İnceleme

Veeam Backup & Replication yazılımı, adli incelemelerde ilk temas noktası olabilir. Vaka senaryomuzda, alınan .VBK dosyası, Veeam GUI kullanılarak içeri aktarıldı.

Veeam arayüzünde, “Backups > Disk > Import Backup” adımıyla manuel olarak yedek dosyasını sisteme tanıttık.

İzole edilmiş bir Hyper-V ortamı üzerinden “Restore entire VM” komutu çalıştırılarak, saldırı anındaki sistem birebir geri yüklendi. Bu noktadan itibaren, kurulu yazılımlar, çalışan servisler ve kullanıcı hesaplarının durumu GUI üzerinden incelenmeye başlandı.

Ancak GUI’nin sınırları da vardı. Örneğin, silinmiş dosyaların analizi, olay loglarının detaylı şekilde dışa aktarımı ve registry tabanlı kullanıcı davranışlarının çıkarımı için sistemin diski ayrı olarak mount edilmek zorundaydı. İşte burada, komut satırı araçları devreye girdi.

3. Dosya Sistemi Üzerinde Derinlemesine Adli İnceleme

Yedek dosyasından dışa aktardığımız dosya sistemini Arsenal Image Mounter ile sanal bir disk olarak mount ettiğimizde, olayın izlerini daha net görebildik. Bu noktada, sistemin görüntüsünü “açmak” adeta bir dijital sahneye girmek gibiydi.

İlk bakışta kullanıcıların masaüstü ve belgeler klasörlerinde ilginç dosyalar görünüyordu; ancak bizim için asıl değerli olanlar silinmiş ama henüz üzerine yazılmamış dosyalar, kullanıcı hareketlerinin zamanlaması, event log’lar, registry kayıtları ve kurulum geçmişleriydi.

3.1 Silinmiş Dosyaların Kurtarılması

Mount edilen disk imajı, FTK Imager üzerinde “File System View” sekmesinden incelendiğinde, NTFS’in “Unallocated Space” alanı dikkatle tarandı. Silinmiş verilerin bir kısmı kurtarılabildi.

Bu sırada dosya adlarının bozulmuş olması doğaldı. Bu gibi durumlarda bulk_extractor devreye girerek, diskin tamamını strings, email header’ları, URL, credit card numarası gibi izler açısından otomatik taradı:

Bu çıktılar, olayın hangi uygulamalar üzerinden yürütüldüğüne dair ilk işaretleri verdi. Örneğin AppData\Roaming klasöründeki bir Python script dosyası, olayın manuel çalıştırılmış bir zararlı yazılım tarafından başlatıldığını gösteriyordu.

3.2 Olay Günlükleri ve Zaman Damgaları

Zaman çizelgesi adli bilişimdeki en kritik kavramlardan biridir. Hangi kullanıcı, hangi saatte, ne yaptı?

İşte bu soruların yanıtları için mount edilen diskten Event Log dosyaları (özellikle Security.evtx, System.evtx) dışarıya alındı. Ardından bu loglar log2timeline ile zaman sıralı hale getirildi:

Ortaya çıkan CSV dosyası, Excel ya da Timeline Explorer gibi araçlarla görselleştirildiğinde, şüpheli oturum açma saatleri ve sıra dışı dosya transferleri dikkat çekti.

3.3 Registry İncelemesi

Kullanıcı profillerindeki NTUSER.DAT dosyaları, adli anlamda oldukça bilgi yüklüdür. Buradan:

• Son çalıştırılan dosyalar (RecentDocs)
• Explorer geçmişi
• USB tak-çıkar geçmişi
• Kurulu programlar
• Kullanıcının sistemle olan etkileşimi gibi izler elde edildi.

Bunları analiz ederken GUI veya CLI fark etmeksizin RegRipper gibi araçlarla doğrudan registry içeriği dışa aktarılabilir:

Elde edilen bulgular, olay sırasında sistemde tek bir kullanıcı değil, birkaç farklı hesabın aktif olduğunu ve bazılarının olaydan hemen sonra oluşturulmuş olduğunu gösterdi. Bu da dış müdahale değil, içeriden sızma ihtimalini güçlendirdi.

4. Komut Satırından Malware ve Script Analizi

Yedek dosyasında kurtarılan PowerShell script’lerinin bazılarında, encode edilmiş Base64 içerikler bulundu. Bunlar doğrudan CyberChef ile çözülüp, ne tür işlemler yaptığı tespit edildi.

Ayrıca mount edilen diskler şu şekilde YARA ile zararlı yazılım taramasına sokuldu:

Buradaki önemli ayrıntı, herhangi bir dosyayı çalıştırmadan içeriğini analiz etmekti. Adli bilişimde hiçbir dosya “çıplak elle” açılmaz.

5. Raporlama ve Delil Zincirinin Korunması

İnceleme sonunda tüm adımlar, zaman ve araç bilgileriyle belgelenerek adli rapora dönüştürüldü. Raporda şu bilgiler yer aldı:

• İncelemenin yapıldığı ortamın tanımı (donanım/sanal)
• Kullanılan araç ve sürümleri
• Alınan hash değerleri
• İnceleme sırasında yapılan işlemler (GUI veya CLI ayrımıyla)
• Elde edilen bulgular (kronolojik ve içeriksel)
• Yorumlar ve analiz sonuçları

Delil zinciri açısından her çıktı, SHA-256 ile hash’lendi ve bağımsız delil dosyaları oluşturuldu. Raporun sonunda, olayla ilişkili dosyalar zaman çizelgesi ve ekran görüntüleriyle desteklendi.

Veeam yedekleme dosyaları, yalnızca sistemleri geri yüklemek için değil; bir dijital olayın anatomisini çıkarabilmek için de eşsiz bir veri kaynağıdır. Bu yedeklerin doğru analiz edilebilmesi için sadece yazılım arayüzüne güvenmek yetersiz kalabilir. Komut satırı araçları, dosya sistemine doğrudan erişim, artefakt incelemeleri, zaman çizelgesi oluşturma ve delil zinciri gibi konular titizlikle yürütülmelidir.

Gerçek bir adli analiz, hem sistematik hem de sezgisel bir süreçtir. Veeam dosyaları da doğru araçlarla birleştiğinde, sistemin olay anındaki gerçekliğini bugüne taşıyan güçlü bir delil haline gelir.

6. VIB ve VRB Dosyalarının Zaman Çizelgesi Üzerinden İncelenmesi

Veeam yedekleme yapısı yalnızca .VBK dosyasından ibaret değildir. Eğer olay sonrası yedekleme sistemi aktif kalmaya devam ettiyse veya olaydan hemen önce birden fazla yedek alınmışsa .VIB (artımlı yedek) ve .VRB (reverse incremental) dosyaları da elimizde olabilir.

Peki bu dosyalar bize ne anlatır?

.VIB dosyaları, tam yedekten sonra dosya sisteminde yapılan değişiklikleri içerir. Adli bilişim açısından, saldırı öncesi ve sonrası sistemde neyin değiştiğini anlamak için eşsizdir. Örneğin, .VBK dosyası olaydan önceki durumu, .VIB dosyası ise saldırganın sisteme yüklediği arka kapıyı gösterebilir.

Bir çalışmamızda, Veeam GUI ile .VBK dosyası geri yüklendikten sonra .VIB dosyası da sisteme dahil edildi. Yedekleme zaman çizelgesi şöyleydi:

• 2025-05-02 → Tam yedek (.VBK)
• 2025-05-03 → Artımlı yedek (.VIB)
• 2025-05-04 → Şifrelenmiş sistem

Yani olay, 3 Mayıs’taki artımlı yedekten hemen sonra gerçekleşmişti. Artımlı yedeğin analiz edilmesi, saldırganın sisteme ne yüklediğini ve hangi dosyaları değiştirdiğini doğrudan ortaya koydu.

Veeam Backup & Replication arayüzünden, zaman çizelgesinde bu yedekleri geri yükleyerek “Before / After” farkı net şekilde gözlemlenebilir. Ancak bu farkı otomatik olarak çıkarabilmek için, dışa aktarılan yedek içerikleri diff mantığıyla karşılaştırıldı.

Bu analiz, kullanıcı tarafından oluşturulmuş bir EXE dosyasının sisteme sızdırıldığını ortaya koydu. Dosya adı zararsız gibi görünüyordu: pdf_reader_update.exe.

7. GUI vs. Komut Satırı: Hangisi Ne Zaman Kullanılmalı?

Birçok uzmanın sorduğu bir soru: “Yedekleri GUI üzerinden açmak mı daha iyi, yoksa komut satırı mı?”

Bu sorunun yanıtı, olayın kapsamına ve eldeki kaynaklara göre değişir. Aşağıda senaryoya göre tercih tabloları sunuyorum:

Bu noktada önerilen yöntem, GUI ile sistemi ayağa kaldırıp kullanıcı deneyimini, CLI ile de dosya düzeyinde izleri yakalayarak analizleri pekiştirmektir.

8. Adli Bilişimde Delil Zincirinin Belgelenmesi ve Rapor Hazırlama

Veeam Backup Dosyalarının Adli Bilişim Açısından İncelenmesi konusunda yapılabilecek en büyük hata, çok şey bulup hiçbir şeyi düzgün belgeleyememektir. Özellikle yedek dosyası gibi büyük ve çok katmanlı yapılarla çalışırken şu yapıya dikkat edilmelidir:

Her Adımı Belgelenmiş Bir Süreç

• Hangi hash algoritması kullanıldı?
• Hangi tarihte, hangi klasöre mount edildi?
• Hangi araç, hangi sürümle kullanıldı?
• Hangi dosyalar hangi anda dışa aktarıldı?
• Alınan çıktıların hash değeri nedir?

Rapor Yapısı Örneği

1. Olay Özeti: Kuruma ait sistemde 4 Aralık 2024 tarihinde şüpheli şifreleme faaliyeti.
2. Yedekleme Yapısı: VBK + VIB mevcut, toplam 2 TB.
3. Yedeklerin İncelenmesi:

• • VBK dosyası restore edildi.
  • Mount edilen disk üzerinden silinmiş dosyalar kurtarıldı.
  • Event log’larda 3 Aralık’ta kimliği belirsiz kullanıcı hesabı açıldığı tespit edildi.

1. Deliller:

• • pdf_reader_update.exe – Zararlı yazılım
  • userlist.txt – Açılan kullanıcı hesapları
  • reg_modifications.reg – Registry’deki izinsiz değişiklikler

1. Sonuç: Olay iç tehdit kaynaklıdır. Saldırı .VIB yedeğinde kayıtlıdır.
2. Ekler: SHA256 hash listeleri, zaman çizelgesi, ekran görüntüleri

9. Hukuki ve Etik Değerlendirme

Adli bilişim sürecinde, özellikle kurumsal Veeam yedek dosyaları ile çalışırken şu konulara dikkat edilmelidir:

• KVKK Uyumlu İşlem: Yedek dosyası içinde kişisel veri varsa, sadece adli sürece uygun kısımlar analiz edilmelidir.
• Yedekleme Sahibi Kurumun Onayı: İnceleme kapsamı mutlaka yazılı hale getirilmelidir.
• Yedek Üzerinden Sistem Çalıştırma Riski: VBK içinden sistem ayağa kaldırılırken “aktif” olarak internete çıkış yapabilecek bir yapı olmamasına dikkat edilmelidir.
• Delil Saklama: Geri yüklenen diskler, olay sonrası en az 5 yıl süreyle imaj olarak saklanmalıdır.

Veeam Yedek Dosyası, Bir Olayın Dijital Haritasıdır

Adli bilişimde en güçlü deliller her zaman log kayıtları ya da çalışan sistemler değildir. Bazen, düzgün yapılandırılmış bir yedekleme sistemi, bir olayın perde arkasını tüm çıplaklığıyla ortaya koyabilir.

Veeam yedek dosyaları, doğru analiz edildiğinde sistemin tüm davranışlarını, kullanıcıların ne yaptığını, saldırganın hangi uygulamaları çalıştırdığını ve hatta silinmiş dosyaları bile gün yüzüne çıkarır.

Ancak bunun için yalnızca yazılıma değil, süreci bilen, analiz adımlarını belgelerle yürüten, hem GUI hem CLI araçlara hakim bir adli bilişim bakışına ihtiyaç vardır.