Dijital Adli Bilişim - Windows Gerçekte Ne Yaşandığını Hatırlar mı? Programlar, Belgeler, USB ve Dosya Hareketlerinin İzinde

Bir kurumda önemli bir belgenin yetkisiz olarak başka bir ortama aktarıldığından şüphelenildiğini düşünün. İlgili bilgisayarda belge hâlâ bulunuyor. Ancak çalışan, belgeyi açmadığını ve herhangi bir USB belleğe kopyalamadığını belirtiyor.

Bilgisayara bir USB bellek bağlandığı biliniyor. Belgenin adı da yakın zamanda değişmiş görünüyor. Üstelik dosya işlemlerinde kullanılabilecek bir uygulamanın daha önce çalıştığına ilişkin izler bulunmuş. İlk bakışta oldukça güçlü bir tablo var. Fakat bu bilgiler gerçekten aynı olayın parçaları mı?

İşte dijital adli bilişimin en ilginç sorunlarından biri burada ortaya çıkıyor. Windows, kullanıcıların ve uygulamaların gerçekleştirdiği bazı faaliyetlerden geriye çeşitli teknik kayıtlar bırakabilir. Ancak bu kayıtların hiçbiri tek başına bütün olayın hikâyesini anlatmak zorunda değildir.

Bir bilgisayarda ne bulunduğunu anlamakla, o bilgisayarda gerçekten ne yaşandığını açıklamak farklı uzmanlıklardır.

Bir program silindiyse çalıştırıldığı anlaşılabilir mi?

Bir uygulamanın artık bilgisayarda bulunmaması, geçmişteki bütün izlerinin kaybolduğu anlamına gelmez.

Windows'un belirli performans ve uyumluluk mekanizmaları, programlarla ilişkili bazı kayıtları saklayabilir. Bu kayıtlar arasında Prefetch, Amcache ve Shimcache özellikle dikkat çeker. Ancak bunların üçünü aynı tür kanıt gibi değerlendirmek önemli bir hatadır.

Prefetch: Program çalıştırmanın izleri

Windows, uygun yapılandırmalarda uygulamaların daha verimli başlatılmasına yardımcı olmak için Prefetch kayıtları oluşturabilir. Bu kayıtlar genellikle, Windows dizini altında "Prefetch"  klasöründe bulunur ve ".pf" uzantılı dosyalar içerebilir.

Bir Prefetch kaydı; belirli yürütülebilir dosyayla ilişkili çalışma göstergeleri, çalıştırma sayacı ve desteklenen sürümlerde belirli son çalıştırma zamanları hakkında bilgi verebilir. Ancak bütün Windows sistemlerinde aynı Prefetch davranışı görülmez.

Örneğin ilgili özellik devre dışı olabilir, eski kayıtlar temizlenmiş olabilir veya uygulama çalışmasına rağmen beklenen kayıt oluşmamış olabilir. Dolayısıyla bir Prefetch kaydının bulunması araştırma açısından değerli olabilirken, bulunmaması programın kesinlikle çalışmadığını ispatlamaz.

Amcache: Bir dosyanın sistemdeki geçmişine ilişkin ipuçları

Amcache, uygulama uyumluluğu ve envanter bilgileriyle ilişkili bir Windows veri kaynağıdır. Belirli yürütülebilir dosyalar hakkında yol, dosya tanımlayıcıları ve başka metadata bilgileri içerebilir.

Ancak önemli sınır şudur: Amcache içerisinde bir dosyanın kayıtlı olması, her durumda o dosyanın kullanıcı tarafından çalıştırıldığını kanıtlamaz. Bazı kayıtlar sistemin uygulama envanteri faaliyetleri sonucunda oluşabilir. Bu nedenle Amcache, diğer program çalıştırma göstergeleriyle birlikte değerlendirilmelidir.

Shimcache: Görünen kayıt her zaman gerçekleşen işlem değildir

Shimcache, Windows'un uygulama uyumluluğu mekanizmalarıyla ilişkili başka bir kaynaktır. Belirli dosya yollarının veya metadata bilgilerinin bulunması, ilgili dosyaların geçmişi hakkında fikir verebilir.

Fakat kayıtların anlamı, Windows sürümüne ve oluşum davranışına bağlıdır. Özellikle Shimcache'de bir dosyanın bulunması, tek başına programın çalıştırıldığına dair kesin hüküm oluşturmaz.

Bu ayrımın pratik önemi büyüktür. Çünkü teknik raporda "Program sistemde tanınmış" demekle "Program kullanıcı tarafından çalıştırılmış" demek aynı iddia değildir.

Üç ayrı kayıt bir araya gelirse ne olur?

Diyelim ki şüpheli uygulamayla ilişkili bir Prefetch dosyası, Amcache kaydı ve Shimcache girdisi bulundu. Bu sonuç araştırmayı güçlendirebilir. Ancak önce kayıtların aynı dosyayı temsil edip etmediği incelenmelidir.

Dosya yolları, zaman alanları, dosya kimlikleri ve uygulama sürümleri farklı olabilir. Üstelik aynı program adı, farklı dizinlerde birden fazla dosyaya ait olabilir.

Örneğin "backup.exe" adını taşıyan iki dosyanın aynı program olduğu otomatik olarak kabul edilmemelidir. Gerçek incelemede; kaynak kayıtların ham verileri, ayrıştırma yöntemi ve araç sürümleri de önem taşır. Bir aracın ekranda gösterdiği program adı, incelemenin son noktası değil, araştırılması gereken bir bulgudur.

Belgenin bilgisayarda bulunması açıldığını gösterir mi?

Şimdi olayın ikinci bölümüne geçelim. İlgili bilgisayarda "strateji_raporu.docx" dosyası bulunduğunu düşünün. 

Dosyanın sistemde mevcut olması, kullanıcının onu açtığını kanıtlamaz. Windows'ta belge ve klasör kullanımını araştırmak için farklı dokümanlar" incelenebilir. Bunların arasında; LNK dosyaları, Jump Lists ve ShellBags bulunur.

LNK dosyaları: Bir bağlantının ardındaki bilgiler

Windows kısayolları ".lnk" uzantısıyla saklanabilir. Bu dosyalar hedef dosya yolu, depolama birimi ve başka tanımlayıcı bilgiler içerebilir. Kullanıcı profilindeki yakın zamanda kullanılan öğelerle ilişkili LNK kayıtları, belirli dosyalar hakkında araştırmaya değer göstergeler sağlayabilir.

Örneğin bir LNK kaydı, geçmişte harici depolama birimindeki bir dosyaya ilişkin yol bilgisi içerebilir. Ancak böyle bir kayıt, dosyanın içeriğinin insan tarafından okunduğunu veya bir yerden başka bir yere kopyalandığını otomatik olarak göstermez. LNK dosyasının ne zaman ve hangi işlem sonucunda oluşturulduğunu değerlendirmek gerekir.

Jump Lists: Uygulamanın hatırladığı belgeler

Windows, belirli uygulamalarla ilişkili yakın zamanda kullanılan veya sabitlenmiş öğeleri Jump Lists yapıları içinde saklayabilir. Bir kelime işlemciye ait Jump List kaydında belirli bir belge görünüyorsa, ilgili uygulama ile belge arasında kullanım ilişkisi araştırılabilir.

Ancak burada da dikkatli olunmalıdır. Bir dosyanın uygulama geçmişinde bulunması, dosyanın gerçekten okunup anlaşıldığını kanıtlamaz. Uygulamalar bazen otomatik işlemler sonucunda dosyalarla etkileşime girebilir.

ShellBags: Klasör geçmişinin farklı anlamı

ShellBags kayıtları, Windows Gezgini ile ilişkili bazı klasör görüntüleme ve görünüm tercihlerini saklayabilir. Örneğin belirli bir klasör yolunun kullanıcı profiliyle ilişkili olarak görüntülenmiş olabileceğine dair işaretler bulunabilir.

Fakat klasörün görüntülenmesi, içindeki bütün belgelerin açıldığı anlamına gelmez. Bir klasörün incelenmesiyle bir belgenin okunması arasında ayrı bir kanıt gereksinimi vardır.

USB belleğin çıkarılması bütün izleri ortadan kaldırır mı?

Olayın üçüncü aşamasında artık bilgisayarda takılı olmayan bir USB bellek olduğunu düşünelim.

Windows, USB depolama aygıtlarını tanırken belirli sistem ve Registry kayıtları oluşturabilir. Örneğin "USBSTOR, USB, MountedDevices"  ve aygıt kurulum günlükleri araştırılabilir.

Bu kayıtlar cihaz üreticisi, model, tanımlayıcılar veya sistemdeki birim eşleştirmeleri hakkında bilgi sağlayabilir. Ancak tüm USB aygıtları benzersiz ve güvenilir fiziksel seri numaraları sunmaz. Ayrıca Registry anahtarındaki son değiştirilme zamanının doğrudan USB belleğin son çıkarılma zamanı olduğu varsayılmamalıdır.

Bu nedenle USB bağlantısı araştırılırken üç farklı soru vardır: Hangi aygıt sistem tarafından tanındı? Ne zaman ve hangi bağlamda bağlantı göstergesi oluştu? Bu aygıt üzerinde hangi dosya faaliyetleri gerçekleşti?

İlk soruya cevap bulmak diğer ikisini otomatik olarak çözmez. Asıl zor soru: Dosya gerçekten kopyalandı mı? 

  • Bir USB belleğin bilgisayara bağlandığını belirledik.
  • Belgeyle ilişkili bir uygulama kaydı da var.
  • Peki bunlar dosyanın kopyalandığını kanıtlar mı?

Hayır. Dosya aktarımı iddiasında mümkünse kaynak ve hedef dosyaların birlikte incelenmesi önemlidir. Hedef USB bellekte aynı dosya bulunuyorsa içerik bütünlüğü SHA-256 gibi bir mekanizmayla karşılaştırılabilir.

Ancak iki dosyanın aynı baytlardan oluşması bile kopyalama yönünü tek başına açıklamaz. Her iki dosya başka bir ortak kaynaktan da elde edilmiş olabilir. Aktarımın zamanı, kullanılan yöntem ve olayın gerçek bağlamı farklı delillerle araştırılmalıdır.

NTFS değişiklik günlüğü, uygun koşullarda belirli dosya sistemi faaliyetleri hakkında bilgi sağlayabilir. Ancak USN kayıtları, normalde bir dosyanın harici aygıta hangi kullanıcı tarafından kopyalandığını açıkça anlatan eksiksiz bir işlem geçmişi değildir.

Bulguları nasıl birleştirmeliyiz?

Aynı olay için elde edilen göstergeleri ayrı ayrı değerlendirelim:

Bu tabloyu önemli yapan şey, neyin bulunabileceğini göstermesi kadar neyin kanıtlanamadığını da açıkça belirtmesidir.

Dijital izler kişiyi mi, hesabı mı gösterir?

Diyelim ki bütün faaliyetler belirli bir Windows kullanıcı profili altında gerçekleşmiş gibi görünüyor. Bu durum önemli bir teknik bulgu olabilir. Ancak hesabın kime ait olmasıyla, işlemi fiziksel olarak kimin gerçekleştirdiği farklı sorulardır.

Paylaşılan bilgisayarlar, açık bırakılan oturumlar, uzaktan erişim veya otomatik uygulamalar değerlendirilmesi gereken ihtimallerdendir. Böyle bir durumda kesin kişi atfı yapabilmek için daha güçlü ve bağımsız kanıtlar gerekebilir.

Sonuç: Windows iz bırakır, ama olayın tamamını anlatmaz

  • Windows'un sunduğu kayıtlar, geçmiş faaliyetleri anlamak için son derece değerlidir.
  • Bir programın çalıştırılması, bir belgenin uygulamayla ilişkili olması, bir USB aygıtının bağlanması ve dosyaların aynı içeriğe sahip olması araştırmanın farklı parçalarını oluşturur.
  • Gerçek uzmanlık, bu parçaları önceden belirlenmiş bir suçlamaya uydurmak değil, teknik anlamlarına sadık kalarak bir araya getirmektir.
  • Bazen bulunan kayıtlar dosya aktarımını güçlü biçimde destekler. Bazen yalnızca aktarım ihtimalini gösterir. Bazen de mevcut veri kesin bir sonuca ulaşmak için yeterli olmaz.

Bu üç durumun birbirinden ayrılması, güvenilir dijital adli incelemenin temelidir. Bilgisayar bazı faaliyetleri hatırlayabilir. Fakat hatırladığı şeyin gerçek olayın hangi bölümüne ait olduğunu belirlemek, incelemecinin sorumluluğudur.

Kaynaklar

  1. Microsoft — Shell Links: https://learn.microsoft.com/en-us/windows/win32/shell/links
  2. Microsoft — NTFS Change Journal Records: https://learn.microsoft.com/en-us/windows/win32/fileio/change-journal-records
  3. Eric Zimmerman — Windows Forensic Tools and Documentation: https://ericzimmerman.github.io
  4. NIST — Guide to Integrating Forensic Techniques into Incident Response: https://doi.org/10.6028/NIST.SP.800-86
  5. SWGDE — Best Practices for Computer Forensic Examination: https://www.swgde.org/18-f-001