涨知识|Windows系统日志

前言

最近遇到不少应急都提出一个需求,能不能溯源啊?这个事还真不好干,你把证据,犯案时间都确定的时候,要求翻看监控(日志)对应犯罪嫌疑人时,突然说监控(日志)没有记录。不过现在都要求保留至少6个月的日志,因此这种原因会少了很多,然而我对于Windows中系统日志不了解,在解读时经常摸不着头脑,所以就认真的分析了evtx格式的系统日志。这篇文章可能记录的不是很全面,师傅们多多指教。

Windows系统日志简介

Windows操作系统在其运行的生命周期中会记录其大量的日志信息,这些日志信息包括:Windows事件日志(Event Log),Windows服务器系统的IIS日志,FTP日志,Exchange Server邮件服务,MS SQL Server数据库日志等。处理应急事件时,客户提出需要为其提供溯源,这些日志信息在取证和溯源中扮演着重要的角色。

Windows事件日志文件实际上是以特定的数据结构的方式存储内容,其中包括有关系统,安全,应用程序的记录。每个记录事件的数据结构中包含了9个元素(可以理解成数据库中的字段):日期/时间、事件类型、用户、计算机、事件ID、来源、类别、描述、数据等信息。应急响应工程师可以根据日志取证,了解计算机上上发生的具体行为。

查看系统日志方法,Windows系统中自带了一个叫做事件查看器的工具,它可以用来查看分析所有的Windows系统日志。打开事件查看器方法:开始->运行->输入eventvwr->回车的方式快速打开该工具。使用该工具可以看到系统日志被分为了两大类:Windows日志和应用程序和服务日志。早期版本中Windows日志只有,应用程序,安全,系统和Setup,新的版本中增加了设置及转发事件日志(默认禁用)。

系统内置的三个核心日志文件(System,Security和Application)默认大小均为20480KB(20MB),记录事件数据超过20MB时,默认系统将优先覆盖过期的日志记录。其它应用程序及服务日志默认最大为1024KB,超过最大限制也优先覆盖过期的日志记录。

image.png

Windows事件日志中共有五种事件类型,所有的事件必须拥有五种事件类型中的一种,且只可以有一种。五种事件类型分为:

1.     信息(Information)

信息事件指应用程序、驱动程序或服务的成功操作的事件。

2.     警告(Warning)

警告事件指不是直接的、主要的,但是会导致将来问题发生的问题。例如,当磁盘空间不足或未找到打印机时,都会记录一个“警告”事件。

3.     错误(Error)

错误事件指用户应该知道的重要的问题。错误事件通常指功能和数据的丢失。例如,如果一个服务不能作为系统引导被加载,那么它会产生一个错误事件。

4.     成功审核(Success audit)

成功的审核安全访问尝试,主要是指安全性日志,这里记录着用户登录/注销、对象访问、特权使用、账户管理、策略更改、详细跟踪、目录服务访问、账户登录等事件,例如所有的成功登录系统都会被记录为“ 成功审核”事件。

5.     失败审核(Failure audit)

失败的审核安全登录尝试,例如用户试图访问网络驱动器失败,则该尝试会被作为失败审核事件记录下来。

事件日志文件存储位置(Vista/Win7/Win8/Win10/Server2008/Server 2012及之后的版本)

类型事件类型描述文件名
Windows日志系统包含系统进程,设备磁盘活动等。事件记录了设备驱动无法正常启动或停止,硬件失败,重复IP地址,系统进程的启动,停止及暂停等行为。System.evtx
安全包含安全性相关的事件,如用户权限变更,登录及注销,文件及文件夹访问,打印等信息。Security.evtx
应用程序包含操作系统安装的应用程序软件相关的事件。事件包括了错误、警告及任何应用程序需要报告的信息,应用程序开发人员可以决定记录哪些信息。Application.evtx
应用程序及服务日志MicrosoftMicrosoft文件夹下包含了200多个微软内置的事件日志分类,只有部分类型默认启用记录功能,如远程桌面客户端连接、无线网络、有线网路、设备安装等相关日志。详见日志存储目录对应文件
Microsoft Office Alerts微软Office应用程序(包括Word/Excel/PowerPoint等)的各种警告信息,其中包含用户对文档操作过程中出现的各种行为,记录有文件名、路径等信息。OAerts.evtx
Windows PowerShellWindows自带的PowerShell应用的日志信息。Windows PowerShell.evtx
Internet ExplorerIE浏览器应用程序的日志信息,默认未启用,需要通过组策略进行配置。Internet Explorer.evtx

表1 事件日志存储位置

提示:%SystemRoot%为系统环境变量,默认值为C:\WINDOWS。

image.png

图 EVTX事件日志文件

使用事件查看器工具可以将这些EVTX事件日志文件导出为evtx,xml,txt和csv格式的文件。

常见的Windows事件的分析方法

Windows事件日志中记录的信息中,关键的要素包含事件级别、记录时间、事件来源、事件ID、事件描述、涉及的用户、计算机、操作代码及任务类别等。其中事件的ID与操作系统的版本有关,以下列举出的事件ID的操纵系统为Vista/Win7/Win8/Win10/Server2008/Server 2012及之后的版本:

事件ID说明
1102清理审计日志
4624账号成功登录
4625账号登录失败
4768Kerberos身份验证(TGT请求)
4769Kerberos服务票证请求
4776NTLM身份验证
4672授予特殊权限
4720创建用户
4726删除用户
4728将成员添加到启用安全的全局组中
4729将成员从安全的全局组中移除
4732将成员添加到启用安全的本地组中
4733将成员从启用安全的本地组中移除
4756将成员添加到启用安全的通用组中
4757将成员从启用安全的通用组中移除
4719系统审计策略修改

表 常见Windows账户及相关shijain 对照表

五种事件类型中,最为重要的是成功审核(Success Audit),所有系统登录成功都会被标记成为成功审核。每个成功登录的事件都会标记一个登录类型:

登录类型描述
2交互式登录(用户从控制台登录)
3网络(例如:通过net use,访问共享网络)
4批处理(为批处理程序保留)
5服务启动(服务登录)
6不支持
7解锁(带密码保护的屏幕保护程序的无人值班工作站)
8网络明文(IIS服务器登录验证)
10远程交互(终端服务,远程桌面,远程辅助)
11缓存域证书登录

表 登录类型

Windows XML 事件日志格式

系统事件日志主要保存的类型为:*.evtx,*.xml,*.txt,*.csv。对于后三种文件格式已经比较了解,现在分析下evtx后缀额格式。事件日志(evtx)文件是一种二进制格式的文件。

image.png

图 evtx文件类型

文件头部签名为十六进制45 6C 66 46 69 6C 65 00(ElfFile\x00)。Evtx文件结构包含三部分:文件头,数据块,结尾空值。文件头由4096字节大小组成,具体的结构如下表:

偏移长度描述
08“ElFile\x00”签名
88第一个数据块
168最后一个数据块
248下一个记录标识符
324128头的大小
3621次版本号
3823主版本号
4024096数据块偏移量
422数据块的数量
4476空值
1204文件标志
1244校验和
1283968空值

 

表 File Header内容

Windows XML 事件日志大小

事件日志文件大小 = (数据块的数量*65536)+4096。

文件头偏移量为120的数据值为文件标志,该部分的组成如下表:

标识符描述
0×0001已更新
0×0002已填充

image.png

图 File Header文件格式

每个数据块大小为65536字节,数据块的头部标签名为45 6C 66 43 68 6E 6B 00(ElfChnk\x00),数据块由数据块头部,事件记录,闲置空间,数据块文件头由512字节大小组成,具体结构如下表:

偏移长度描述
08“ElfChnk\x00”签名
88第一个事件记录编号
168最后一个事件记录编号
248第一个事件记录标识符
328最后一个事件记录标识符
404128指针数据偏移量
444最后一个事件记录数据偏移量
484自由空间偏移
524事件记录校验和
5664空值
1204未知
1244校验和

表 Chunk header

image.png

图 Chunk Header文件格式

数据块包含多个事件记录,一个事件记录对应一条日志信息。事件记录的的大小及组成如下表:

偏移量长度描述
04“**\x00\x00”签名
44事件记录块的大小
88事件记录标识符
168事件记录写入时间
24事件记录内容
4尺寸拷贝

表 Event Record

Windows事件日志取证分析注意要点

Windwos操作系统默认没有提供删除特定日志记录的功能,仅提供了删除所有日志的操作功能。也就意味着日志记录ID(Event Record ID)应该是连续的,默认的排序方式应该是从大到小往下排列。

通过对Windows事件日志的取证分析,取证人员可以对操纵系统、应用程序、服务、设备等操作行为记录,通过关键的时间点进行回溯。

事件查看器单条日志记录删除思路

分析事件记录格式后,了解到Windows系统在解析事件记录日志时,按照Event Record的大小逐条读取日志的内容。假设修改某条日志的长度,使长度覆盖下一条日志,理论上Windows系统解析日志时,就会跳过下一条日志,相当于下一条日志被”删除”。 DanderSpritz中的eventlogedit 就是这个思路,仅仅时修改了程度,实际上并没有删除日志内容。实现思路如下图:

image.png

图 删除事件记录思路

为了确保修改后的日志文件能够被正确识别,还需要修改多个标志位和重新计算校验和。

image.png

图 不正确修改事件日志

为了确保不出现如上图所示的错误,总结一下删除单条日志内容的方法:

1.     File Header中的Next recordidentifier的值减一(偏移量为24字节)

2.     重新计算File Header中CheckSum(偏移量为124字节)

3.     修改Event Record,找到需删除的记录和需删除前一条记录并计算日志的长度,更新Event Record的Event record identifier

4.     更新ElfChnk,需要修改的内容为:Last event record number,Last event recordidentifier,Last event record data offset,Event recordschecksum,Checksum

根据以上的方式进行删除单条日志是NAS方程式组织的DanderSpritz中的eventlogedit实现方式。实际上只是将信息进行了隐藏,在此基础上,将指定日志的内容清空,就能够实现真正的日志删除。

单条日志删除

准备:测试文件(test.evtx—系统中的Setup.evtx),Winhex,python

下载地址:https://github.com/ByPupil/delete-windows-log

该文件中包含了8条日志,下面演示删除第8条记录的实践过程。使用事件查看器打开确认最后一条事件的EventRecordID,该实验中的值为8。

image.png

图 test.evtx文件

1.     File Header中的Next recordidentifier的值减一

File Header是整个文件最开始的部分,Nextrecord identifier的偏移量为24(0×18),其长度为8字节。实验文件test.evtx内容如下:

image.png

图 test.evtx文件内容

Next record identifier的值为0×09。将该值减一0×08 写入。这儿需要提一下的是,该文件的字节序为小端,因此低位会在前面。

2.     重新计算File Header中CheckSum

计算方法:前120字节做CRC32运算,偏移量为124(0x7c),长度为4。修改后的文件内容如下图:

image.png

图 修改后的test.evtx

现在提取前120字节的内容:

[/crayon]
使用python中binascii模块计算CRC32。代码如下:

image.png

图 计算CRC32代码

输出的结果为:0xfb027480,修改文件内容,修改后如下图:

image.png

图 修改checksum

3.     修改Event Record

通过find hex values查找2A2A0000,定位到第8条Event Record。该条Event Record的长度为 0×180。如下图:

image.png

图 第8条EventRecord

第7条Event Record的长度为0×170。如下图:

image.png

图 第7条EventRecord

计算需要修改的内容长度。新长度为0×170+0×180=0x2f0。由于是删除最后一条记录,所以不需要更新Event record identifier。修改长度的位置有两个,分别为第7条日志的长度和第 8条日志的最尾部。

image.png

图 第7条日志

image.png

图 第8条日志

4.     更新ElfChnk

搜索ElfChuk关键字,找到对应ElfChuk位置。如下图:

image.png

图 Elfchnk

修改如下内容:

Last event record number减1,为0×07

Last event record identifier减1,为0×07

Last event record data offset,为0x13c8

Event records checksum,为0xf403d736

Checksum,为0x7563439c

Event records checksum的数据计算范围:chunk中的事件记录的偏移量是固定的,是从文件头偏移0×1200个字节,意思就是checksum的数据起始位置为0×1200。事件记录的结束位置的计算方式:chunk的起始块地址+ Free space offset= events records data。

Checksum的数据计算范围:是固定地址0×1000-0×1078,0×1080-0×1200 。

修改后的ElfChnk如下图:

image.png

图 修改后的ElfChnk

经过修改后,使用系统自带的事件查看器打开,此时日志文件中最后一条记录被成功删除。

image.png

图 成功删除单条日志记录

此处讲的是删除最后一条记录的详细过曾,删除第一条和中间的记录在实际操作中会有一些不一样的部分,只要对了解evtx文件的格式,删除evtx格式内容中的记录方法并不唯一。只需要删除对应的数据块,并最终使该文件的校验通过即可。

恢复被删除的记录

使用以上的方式删除单挑记录,其实被删除的数据并没有真正的被删掉,严格意义上讲就是将部分数据进行了隐藏。恢复原本的数据可以使用fox-it的danderspritz-evtx工具,原因就是用删除数据的思路反向恢复就行。使用该工具,确实可以将被删除的数据提取出来,不过恢复的evtx格式的文件并不能被打开。暂时没有研究该代码的实现过程,所以不能下分析具体原因。

工具使用如下图:

image.png

图 danderspritz-evtx使用

恢复数据被导出为xml格式文件,如下图:

image.png

图 该条为被删除的第8条记录

恢复的evtx格式文件打开出错,如下图:

image.png

如果需要将日志真正的删除,可以使用\x00填充被隐藏的数据部分填充。并重新计算相应的checksum。

参考链接

https://blog.fox-it.com/2017/12/08/detection-and-recovery-of-nsas-covered-up-tracks/

https://github.com/libyal/libevtx/blob/master/documentation/Windows%20XML%20Event%20Log%20(EVTX).asciidoc#2-file-header

* 本文作者:TomKing

本文由 孤独常伴 作者:孤独常伴 发表,其版权均为 孤独常伴 所有,文章内容系作者个人观点,不代表 孤独常伴 对观点赞同或支持。如需转载,请注明文章来源。

0

发表评论