通过NTFS日志分析文件的时间属性是否被篡改
前期准备
NTFS日志记录了什么东西?
NTFS日志会记录NTFS文件系统中文件的创建、修改、增加数据、删除等操作执行的时间,虽说这个日志也可以被第三方程序修改,但仍然可以作为一个重要的参考依据。
NTFS日志文件在哪里?
NTFS日志保存在每个虚拟磁盘(CDE...分区)的$Extend中,这个文件夹在资源管理器中不可见,即便是输入路径,也无法访问
不过我们仍然可以使用取证工具X-ways找到它
进入其中可以看到$UsnJrnl
,这就是日志文件,只不过其中还包含了两个数据流
这两个数据流分别是$J
和$Max
,其中$Max
保存的是$J
的配置信息,而$J
中就保存了日志内容。
由于$J
记录对文件的操作行为,所以一般文件操作越频繁的分区的NTFS日志文件会越大,笔者的C盘分配了147GB
的空间,而$J
的大小就来到了惊人的32.2GB
反观分配了465GB
的E盘,其$J
的大小才1.7GB
如何分析NTFS日志?
笔者通过X-ways导出日志文件
之后分析软件NTFS Log Tracker
将日志文件解析并生成一个数据库
这时就可以看到日志中的数据
当然,可以使用数据库软件来查看生成的db文件,如DB Browser for SQLite
等
使用软件可以方便我们过滤、查找想要的文件的内容以及对应的时间,数据库中的内容依照USN
进行排列,依次将对文件的操作写入Event
字段中,因此通过分析文件的创建操作File_Created
和关闭操作File_Closed
,就可以初步分析出文件的创建时间和修改时间,通过对比进一步确认是否经过修改。
案例分析
本次以司鉴院2022年真实性能力验证中的一题为实际案例,要求判断文件test.docx
的时间属性是否被篡改,如果被篡改需要给出篡改前的修改时间。
首先查看文件的修改时间为2022-07-22 9:51:20
这个时间可以帮助我们初步确定日志范围
接下来打开解析完的日志数据库,直接过滤test.docx
,可以发现第1条记录就是重命名,记录的时间是2022-07-22 09:41:31
,最后1条记录的时间是2022-07-22 09:52:03
,将这两个时间段扩充一下,利用查询语句过滤出时间及对应的事务
发现test.docx
是从模板.docx
重命名而来
而模板.docx
的日志记录显示没有做其他的额外操作
而针对test.docx
后续的日志记录,发现在2022-07-22 09:47:07
又进行了一次重命名
通过定位发现这次重命名是将test.docx
重命名为test.zip
后续在2022-07-22 09:48:05
时,将test.zip
解压到了test
后来在2022-07-22 09:49:21
对core.xml
进行了修改,这个文件中保存了word文档中的创建时间和上一次保存时间
紧接着在2022-07-22 09:49:33
重新打包出test.zip
之后在2022-07-22 09:49:43
将test.zip
重命名为test.docx
再然后,又将test.docx
删除,重复了一遍上述操作
最后将产生的其他文件删除
综上所述,对test.docx
的最敏感的操作就是修改了配置文件core.xml
,使用压缩软件打开test.docx
,查看core.xml
可以发现文档的上一次修改日期竟然在创建日期之前,很明显这里是被修改了,因此得到第1个结论:test.docx
的时间属性被篡改。
接下来找到篡改前的修改日期,一般情况下,文档中的修改时间和利用资源管理器查看文件属性获得的修改时间是相同的,因此找到test.docx
被篡改前正常关闭的时间即可。
通过分析找到正常的关闭时间为2022-07-22 09:46:12
因此test.docx
的篡改前的修改时间为2022-07-22 09:46:12