İçeriğe atla
0 XP 0
14 dkderinleşmeyle 16 dk60 XP7 etkinlik

Zaman damgaları MACB ve anti-forensics

Bu derste
  • MACB damgalarını NTFS'in iki öznitelik kümesinde okumayı, damga bükmeyi USN kaydıyla yakalamayı ve günlük temizliğinin bıraktığı izi bulmayı öğren.
  • Bu derste update.exe dosyasının damgalarını okuyup elle değiştirilmiş olanı yakalayacak, bükmenin gerçek saatini USN günlüğünden çıkaracaksın.
  • Zaman damgası yalan söyleyebilir. Hangi kaynağın daha zor değiştiğini öğreneceksin.

Puan bütün etkinlikleri cevaplayınca hesaba yazılır. Bu dersi tamamlayınca +60 XP alacaksın. Giriş yapmadan ilerlersen puan yalnız bu tarayıcıda durur.

Zaman çizelgesi adli analizin omurgasıdır ve çizelgenin hammaddesi dosya damgalarıdır. Ama damga bir kayıttan ibarettir ve kayıt değiştirilebilir. Bu derste önce MACB denen dört damgayı ve NTFS'in onları nerede tuttuğunu oturtacaksın. Sonra fin-pc12 imajındaki update.exe dosyasının damgalarını okuyacak, geriye çekilmiş damgayı üç ayrı işaretle yakalayacaksın.

Ardından zaman biçimlerini ve saat dilimini çözecek, en son damga bükmenin ötesindeki iz silme yöntemlerine bakacaksın. Temel kural baştan belli: iz silmek de iz bırakır. Analistin işi bu ikinci izi bulmaktır.

MACB: dört damga, iki küme

Dört harfin karşılığını net oturt. M değişim zamanıdır ve içerik değiştiğinde güncellenir. A erişim zamanıdır ve dosya okunduğunda güncellenir. C üstveri değişimidir: izin, sahip ya da ad değiştiğinde güncellenir.

NTFS bu damgaya kayıt değişim zamanı (MFT Modified) der. B ise doğum zamanıdır, yani dosyanın oluştuğu an. NTFS dördünü de tutar.

ext4 ilk üçünü mtime, atime ve ctime alanlarında, doğumu ise crtime alanında saklar. Damgaları tek başına değil, gruplar hâlinde oku. Aynı klasördeki on dosyanın hepsi saniyesi saniyesine aynı doğum zamanını taşıyorsa, bunlar büyük olasılıkla tek bir arşivden çıkmıştır.

NTFS bir dosya için iki damga kümesi tutar. Biri $STANDARD_INFORMATION içindedir.

Gezgin, dir komutu ve çoğu araç bu kümeyi gösterir. Öteki $FILE_NAME içindedir. Bu küme dosya oluşturulurken yazılır, sonra yalnız taşıma ve yeniden adlandırma gibi ad işlemlerinde yenilenebilir. Olağan dosya API'si ona dokunmaz.

Aşağıdaki tablo, sık işlemlerde $STANDARD_INFORMATION kümesinin nasıl davrandığını özetler ve SANS'ın Windows adli analiz posterindeki kurallarla aynı yöndedir. En çok karıştırılan satır kopyalamadır. Başka birime kopyalanan dosyada doğum zamanı kopyalama anıdır, değişim zamanı ise kaynaktan gelir. Kopyalanmış dosyada M damgası B damgasından eskidir ve bu durum bükme değildir.

İşlem ($STANDARD_INFORMATION)   M        A        C        B
Oluşturma                       yeni     yeni     yeni     yeni
İçerik değiştirme               yeni     (*)      yeni     aynı
Yeniden adlandırma              aynı     aynı     yeni     aynı
Aynı birimde taşıma             aynı     aynı     yeni     aynı
Başka birime kopyalama          kaynak   yeni     yeni     yeni
Silme                           aynı     aynı     aynı     aynı

(*) Erişim güncellemesi açıksa değişir. NTFS erişim damgasını diske en çok bir saat gecikmeyle yazar.
Windows 10 ve 11'de sık işlemlerin $STANDARD_INFORMATION damgalarına etkisi. Kopyada M kaynaktan gelir.

Etkinlik 1 / 7

MACB harflerini anlamlarıyla eşleştir.

Soldan bir tane seç, sağdan eşini seç. Kullanılmış bir seçeneği yeniden seçersen yeni öğeye taşınır.

Damga bükmeyi yakalamak

Zaman damgasını değiştirmeye damga bükme (timestomping) denir (MITRE ATT&CK T1070.006). Saldırgan dosyasını eski bir tarihe çeker ve sistem dosyası gibi göstermek ister. Windows'un SetFileTime işlevi oluşturma, erişim ve değişim zamanını içeriğe dokunmadan değiştirir.

Hazır araçlar bu işi tek komutla yapar. Ama çoğu yalnız $STANDARD_INFORMATION kümesini değiştirir. $FILE_NAME kümesi gerçek anı taşımaya devam eder.

Aşağıdaki çıktıda istat komutunu -z UTC ile çalıştırıyorsun. Böylece damgalar analiz makinesinin saat dilimine göre değil, UTC olarak yazılır ve rapora doğrudan girer.

$ istat -z UTC -o 2048 fin-pc12.dd 812
MFT Entry Header Values:
Entry: 812        Sequence: 5
Not Allocated File

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Created:	2009-07-14 00:41:12.000000000 (UTC)
File Modified:	2009-07-14 00:41:12.000000000 (UTC)
MFT Modified:	2026-09-14 00:07:46.218844100 (UTC)
Accessed:	2026-09-14 00:07:19.108274300 (UTC)

$FILE_NAME Attribute Values:
Flags: Archive
Name: update.exe
Parent MFT Entry: 90117 	Sequence: 2
Allocated Size: 1458176   	Actual Size: 1458176
Created:	2026-09-14 00:07:11.421387600 (UTC)
File Modified:	2026-09-14 00:07:11.421387600 (UTC)
MFT Modified:	2026-09-14 00:07:11.421387600 (UTC)
Accessed:	2026-09-14 00:07:11.421387600 (UTC)
İki küme çelişir. $FILE_NAME 2026 der, $STANDARD_INFORMATION 2009 der. Dosya bükülmüş.

Çıktıda üç işaret var. Birincisi iki kümenin çelişmesidir. $STANDARD_INFORMATION doğumu 2009 der, $FILE_NAME doğumu 2026 der.

Bir dosya kendi adının yazıldığı andan önce doğmuş olamaz. İkincisi saniye altı kısımdır. NTFS damgayı 100 nanosaniyelik adımlarla yazar ve olağan bir damganın sonu 421387600 gibi karışık rakamlar taşır.

Bükülen iki damga ise tam saniyeye oturmuş ve sıfırlarla bitiyor. Üçüncüsü C damgasıdır. Bu araç C damgasını değiştirmemiş.

Damga 00:07:46 değerini taşıyor ve bükmenin yapıldığı anı ele veriyor. Seçilen tarih de rastgele değildir. 14 Temmuz 2009, Windows 7 sistem dosyalarında sık görülen tarihtir.

> MFTECmd.exe -f E:\eviz\fin-pc12\$MFT --csv E:\cikti --csvf mft.csv
EntryNumber,InUse,ParentPath,FileName,SI<FN,uSecZeros,Copied,Created0x10,Created0x30
812,False,.\Users\mkaya\AppData\Local\Temp,update.exe,True,True,False,2009-07-14 00:41:12.0000000,2026-09-14 00:07:11.4213876
2231,True,.\Users\Public,svcupd.exe,True,True,False,2009-07-14 00:41:12.0000000,2026-09-14 00:07:44.9021337
57,True,.\Users\mkaya\Documents,sunum_eylul.pptx,False,False,True,2026-09-03 09:12:40.5531870,

> MFTECmd.exe -f E:\eviz\fin-pc12\$J --csv E:\cikti --csvf usn.csv
Name,EntryNumber,UpdateTimestamp,UpdateReasons
update.exe,812,2026-09-14 00:07:11.4213876,FileCreate
update.exe,812,2026-09-14 00:07:12.0339105,DataExtend|FileCreate|Close
update.exe,812,2026-09-14 00:07:46.2188441,BasicInfoChange
update.exe,812,2026-09-14 00:07:46.2188441,BasicInfoChange|Close
update.exe,812,2026-09-14 00:09:30.5521907,FileDelete|Close
Seçilmiş sütunlar. Üst tablo $MFT'nin toplu taraması, alt tablo USN günlüğündeki update.exe satırları.

MFTECmd aynı karşılaştırmayı bütün tablo için yapar. SI<FN sütunu, $STANDARD_INFORMATION doğumu $FILE_NAME doğumundan önceyse True olur. uSecZeros sütunu damganın saniye altı kısmı sıfırsa işaret koyar.

Copied sütunu değişim zamanı doğumdan önceyse True olur ve kopyalanmış dosyayı gösterir. Created0x30 sütunu yalnız iki küme farklıysa dolar. Bu sütunlarla binlerce kayıt içinden update.exe ile svcupd.exe hemen ayrılır.

İkinci komut USN günlüğünü ($UsnJrnl:$J) okur. Aynı kayıt için 00:07:46'da BasicInfoChange nedenli bir satır var. Bu neden, dosyanın damga ya da öznitelik bilgisinin değiştiğini söyler.

Bükmenin gerçek saati bu satırdır. Dosya da 00:09:30'da silinmiş.

Derinleş:İkinci küme de bükülebilir mi?

Bükülebilir, ama daha zordur. $FILE_NAME kümesini olağan dosya API'si değiştirmez. Bazı ileri teknikler önce $STANDARD_INFORMATION kümesini büker, sonra dosyayı aynı birimde başka bir klasöre taşıyıp geri getirir. Amaç, Windows'un ad işlemi sırasında $FILE_NAME kümesini yeniden yazmasıdır.

Dosya sistemini atlayıp $MFT kaydını ham olarak düzenleyen araçlar da vardır. Bu yolları iki kaynak zorlaştırır. Birincisi USN günlüğüdür: taşıma ve yeniden adlandırma RenameOldName ve RenameNewName nedenli satırlar bırakır. İkincisi $LogFile'dır: kayıttaki her değişiklik önce bu işlem günlüğüne yazılır.

Ham disk erişimi de uç nokta kayıtlarında görünebilir. Böyle bir araç diski önce ham olarak okur ve Sysmon'un 9 numaralı RawAccessRead olayı bu okumayı yakalar. Kısacası tek bir kaynağı kandırmak mümkündür.

Bütün kaynakları aynı anda tutarlı biçimde kandırmak ise çok zordur. Analist bu yüzden hiçbir zaman tek damgaya dayanmaz.

Etkinlik 2 / 7

Bir dosyanın $STANDARD_INFORMATION damgası 2009, $FILE_NAME damgası 2026 yılını gösteriyorsa ne çıkarırsın?

Etkinlik 3 / 7

update.exe için hangileri damga bükme savını destekler?

Birden fazla doğru var.

Zaman biçimleri ve saat dilimi

Damga diskte sayı olarak durur, tarih olarak değil. Windows FILETIME biçimini kullanır: 1 Ocak 1601 UTC'den bu yana geçen 100 nanosaniyelik adımların sayısı. Değer 64 bittir ve diskte küçük uçlu yazılır.

Unix ve Linux saniye sayar: 1 Ocak 1970 UTC'den bu yana geçen saniyeler. ext4 buna nanosaniye kısmını ayrıca ekler. İki başlangıç arasında tam 11644473600 saniye vardır.

Dönüşümü bir kez elle yaparsan araçların çıktısını denetleyebilirsin. Aşağıda update.exe dosyasının $FILE_NAME doğum damgasını adım adım çözüyorsun. Önce 10 milyona bölüp saniyeye çevirirsin, sonra farkı çıkarıp Unix zamanına geçersin.

FILETIME (onaltılık)    : 0x01DD43DCFD66ADF4
FILETIME (onluk)        : 134338180314213876
÷ 10 000 000            : 13433818031,4213876 saniye (1601'den beri)
− 11 644 473 600        : 1789344431,4213876 saniye (1970'ten beri, Unix zamanı)
UTC                     : 2026-09-14 00:07:11.4213876
Türkiye saati (UTC+3)   : 2026-09-14 03:07:11.4213876
Aynı an, dört biçimde. Unix zamanının onaltılık karşılığı 0x6AA73AAF'dir.

NTFS damgaları UTC olarak yazar ve saat dilimi değişse de etkilenmez. FAT32 ise yerel saati yazar. Araçlar gösterirken çevirir. istat seçenek verilmezse analiz makinesinin yerel saatini kullanır, bu yüzden dilimi -z bayrağıyla açıkça seçersin.

Makinenin kendi saat dilimini SYSTEM kovanındaki TimeZoneInformation anahtarı söyler. Bias değeri dakika cinsindendir ve UTC'yi bulmak için yerel saate eklenir.

-180 değeri, makinenin UTC'den 180 dakika, yani üç saat ileride olduğunu gösterir. Türkiye 2016'dan beri yıl boyu UTC+3 kullanır. Raporda hangi dilimi kullandığını yazmazsan bütün zaman çizelgesi kayar.

Saat dilimi tek sorun değildir, saatin kendisi de kayabilir. NTP ile eşitlenmeyen bir makine günler içinde dakikalarca ileri ya da geri gidebilir. Kaymayı ölçmek için makinenin kaydettiği bir anı bilinen bir dış kaynakla karşılaştırırsın. Örneğin aynı e-postanın posta sunucusundaki alınma saatini istemcideki kayıt saatiyle yan yana koyarsın.

Kayma bulunursa Sleuth Kit araçlarına -s bayrağıyla saniye cinsinden verirsin. Makine 100 saniye gerideyse değer -100 olur. Kaymayı rapora yaz ve bütün damgaları aynı düzeltmeyle oku. Yarım düzeltme, çizelgedeki sırayı bozar.

$ rip.pl -r /eviz/fin-pc12/SYSTEM -p timezone
ControlSet001\Control\TimeZoneInformation
  TimeZoneKeyName -> Turkey Standard Time
  Bias            -> -180 (-3 hours)
  ActiveTimeBias  -> -180 (-3 hours)
fin-pc12'nin saat dilimi kovandan okunur. Raporun başına bu satır girer.
Derinleş:Neden 1601, neden 2038?

FILETIME'ın başlangıcı rastgele seçilmedi. Windows NT tasarlanırken Gregoryen takvimin 400 yıllık döngüsünün başı olan 1601 yılı seçildi. Bu seçim artık yıl hesabını sadeleştirir.

64 bitlik sayaç, 100 nanosaniyelik adımlarla on binlerce yıla yeter. Unix tarafında durum farklıdır. 32 bitlik işaretli saniye sayacı 19 Ocak 2038'de taşar.

ext4 bu soruna ek bir alanla karşılık verir. 256 baytlık inode'da her damganın yanında 32 bitlik bir ek alan durur. Bu alanın 30 biti nanosaniyeyi, 2 biti dönem uzantısını taşır ve tarih aralığını 2446 yılına kadar genişletir. 128 baytlık eski inode kullanan bir birimde bu ek alan yoktur.

Orada damgalar saniye inceliğinde kalır, doğum zamanı da tutulmaz. FAT ise en kaba biçimdir. Başlangıcı 1980'dir, değişim zamanını iki saniyelik adımlarla tutar, erişimi yalnız gün olarak yazar. Farklı dosya sistemlerinden gelen damgaları yan yana koyarken bu incelik farkını hesaba katarsın.

Etkinlik 4 / 7

Türkiye yerel saati UTC'den kaç saat ileridedir?

Tahminini kaydır, sonra gönder.

012

Temizlik de iz bırakır

Anti-forensics yalnız damga bükmekten ibaret değil. Günlük temizleme, güvenli silme, alternatif veri akışına saklanma ve uzantı değiştirme de aynı aileye girer. Hepsinin ortak noktası şudur: bir izi silmek başka bir iz üretir.

Olay günlüğü temizlenince Windows bunu da yazar. Security günlüğü silindiğinde aynı günlüğe 1102, System günlüğü silindiğinde System günlüğüne 104 olayı düşer. Olay, temizliği yapan hesabı da taşır.

Günlüğü silmek için kullanılan wevtutil.exe, Prefetch klasöründe kendi dosyasını bırakır. USN günlüğündeki boşluklar, $MFT'deki ardışık sıra atlamaları ve eksik Prefetch dosyaları da aynı hikâyeyi anlatır. Yokluk da veri sayılır.

> EvtxECmd.exe -f E:\eviz\fin-pc12\Security.evtx --csv E:\cikti
TimeCreated,EventId,Channel,UserName,MapDescription
2026-09-14 00:31:07,1102,Security,ALTAYKARGO\FIN-PC12$,The audit log was cleared

> PECmd.exe -f E:\eviz\fin-pc12\Prefetch\WEVTUTIL.EXE-8C1A77D2.pf
Executable name: WEVTUTIL.EXE
Run count: 2
Last run: 2026-09-14 00:31:06
Other run times: 2026-09-14 00:31:05
Seçilmiş sütunlar. Temizlik olayı ve temizlik aracının çalıştırma izi aynı dakikada.

Satırlarda üç bilgi var. 1102 olayı Security günlüğünün 00:31:07'de, yani yerel saatle 03:31'de silindiğini söyler. Hesap adı makine hesabıdır ve sonunda $ işareti taşır.

Temizliği SYSTEM yetkisiyle çalışan bir süreç yapmıştır. Bu da hizmet olarak çalışan svcupd.exe ile uyumludur. Prefetch kaydı wevtutil.exe'nin bir saniye arayla iki kez çalıştığını gösterir.

Büyük olasılıkla önce System, sonra Security günlüğü silindi. Bunu System günlüğündeki 104 olayıyla doğrularsın. Savunma tarafının cevabı basittir: günlükleri anında merkezî bir kayıt sistemine yönlendir. Yerel temizlik (T1070.001) o zaman yalnız kopyayı siler, merkezdeki kayıt yerinde kalır.

Öteki yöntemler de benzer izler bırakır. Güvenli silme aracı içeriği ezer, ama kendi Prefetch kaydını üretir, $MFT'de boşluk açar ve USN günlüğüne art arda yazma ve yeniden adlandırma satırları düşürür. Alternatif veri akışına saklanan araç, fls çıktısında ayrı bir satır olarak görünür. Uzantı değiştirmek de işe yaramaz, çünkü dosyanın gerçek türünü baş baytları söyler ve file komutu bu numarayı hemen bozar.

Savunma tarafında Sysmon'un 2 numaralı olayı, bir sürecin dosya oluşturma zamanını değiştirdiğini kaydeder. Meşru programlar da bunu yapabildiği için olay tek başına alarm değildir. Ama bükmenin saatini ve işi yapan süreci verir.

Etkinlik 5 / 7

fin-pc12 günlüklerinden süzülen satırlarda iz silme ya da gizleme girişimini gösterenleri işaretle.

Şüpheli satırlara tıkla. Birden fazla olabilir.

Yorumu doğrulamak

Bükme savını kurarken işaretleri tek tek tart. Tam saniyeye oturan damga şüphe uyandırır ama tek başına karar verdirmez. ZIP arşivleri değişim zamanını çoğu kez iki saniyelik adımlarla saklar ve arşivden çıkan dosya bu damgayı taşır.

FAT32 bellekten kopyalanan dosyanın değişim zamanı da aynı biçimde tam saniyeye oturur. Bazı kurulum araçları da damgayı kendisi yazar. Bu işaret $FILE_NAME çelişkisiyle ve USN günlüğündeki BasicInfoChange satırıyla birleşince güçlenir.

Karşılaştırmada referans noktan $FILE_NAME kümesidir, çünkü olağan dosya API'si ona dokunmaz. Sırayı buna göre kur: önce iki kümeyi yan yana koy, sonra saniye altı kısma bak. Tersini yaparsan arşivden çıkan yüzlerce masum dosyayı şüpheli sayarsın.

Linux'ta da aynı mantık geçerlidir. touch -d komutu bir dosyanın mtime ve atime damgalarını istenen tarihe çeker. ctime ise kullanıcı alanından ayarlanamaz.

touch çalıştığı anda ctime o anın saatini alır. crtime da olağan sistem çağrılarıyla değiştirilemez. Bu yüzden ext4'te mtime 2019'u, ctime ve crtime ise olay gecesini gösteren bir dosya bükmenin tipik izini taşır.

İçerik gerçekten eski olsaydı dosyanın doğumu da eski olurdu. Web sunucusuna bırakılan bir web kabuğu (web shell) çoğu kez komşu dosyaların tarihine çekilir. debugfs çıktısında dört damgayı yan yana okuyarak bu hileyi yakalarsın.

Erişim damgasına fazla güvenme. Windows başarım için erişim güncellemesini kapatabilir ya da sistem yönetimine bırakabilir. Ayar SYSTEM kovanındaki NtfsDisableLastAccessUpdate değerinde durur. Canlı sistemde fsutil behavior query disablelastaccess ile okunur.

Güncelleme açık olsa bile NTFS diske yazmayı bir saate kadar erteler. Erişim zamanının eski kalması, dosyanın okunmadığı anlamına gelmez. Damga yorumunu her zaman ikinci bir kaynakla destekle. Prefetch, olay günlüğü, USN kaydı ve ağ kaydı aynı saati gösteriyorsa damga güvenilirdir.

Tek kaynağa dayanan saat tartışmaya açıktır. Zaman çizelgesine yazdığın her satıra damganın türünü ve kaynağını da ekle. Yoksa iki farklı olay aynı saate düşmüş gibi görünür.

Delili kopyalarken damgayı sen de değiştirebilirsin. Dosyayı çalışma diskine basitçe kopyalarsan kopyanın doğum zamanı kopyalama anı olur. Bu yüzden damga yorumunu kopya üzerinde değil, imaj üzerinde yaparsın. Olay raporunun öneriler kısmına da iki madde yazılır.

Birincisi Sysmon ya da eşdeğer bir uç nokta aracıyla süreç oluşturmayı ve dosya zamanı değişikliklerini kaydetmektir. İkincisi günlükleri merkeze yönlendirmek ve yerel günlük boyutunu büyütmektir. Bu iki önlem hem bükmeyi hem temizliği ilk dakikada görünür kılar. fin-pc12 olayında Sysmon kaydı yerinde kaldı, çünkü saldırgan yalnız Security ve System günlüklerini sildi.

Etkinlik 6 / 7

Doğru mu, yanlış mı?

Bükülmüş NTFS damgası çoğu kez tam saniyeye oturur, bu yüzden saniye altı kısmı sıfırlarla biten damga kümesi şüphe uyandırır.

Etkinlik 7 / 7

NTFS'te bükülmesi zor olan ikinci zaman damgası kümesi hangi öznitelikte durur? ____

Bu derste bir hata mı gördün? Bildir