快捷搜索:  网络  后门  CVE  渗透  木马  扫描  黑客  as

闲聊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
应用程序及服务日记 Microsoft Microsoft文件夹下包含了200多个微软内置的事故日记分类,只有部分类型默认启用记录功能,如遥程桌面客户端连接、无线收集、有线网路、设备装置等相干日记。 详见日记存储目录对应文件
Microsoft Office Alerts 微软Office应用程序(包括Word/Excel/PowerPoint等)的种种正告信息,其中包含用户对文档操作过程中出现的种种举动,记录有文件名、路径等信息。 OAerts.evtx
Windows PowerShell Windows自带的PowerShell应用的日记信息。 Windows PowerShell.evtx
Internet Explorer IE阅读器应用程序的日记信息,默认未启用,需要通过组策略进行设置。 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 账号登录失败
4768 Kerberos身份验证(TGT要求)
4769 Kerberos服务票证要求
4776 NTLM身份验证
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字节大小组成,详细的结构以下表:

偏移 长度 描摹
0 8 “ElFile\x00” 署名
8 8   第一个数据块
16 8   最后一个数据块
24 8   下一个记录标识符
32 4 128 头的大小
36 2 1 次版本号
38 2 3 主版本号
40 2 4096 数据块偏移量
42 2   数据块的数量
44 76   空值
120 4   文件标志
124 4   校验以及
128 3968   空值

 

表 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字节大小组成,详细结构以下表:

偏移 长度 描摹
0 8 “ElfChnk\x00” 署名
8 8   第一个事故记录编号
16 8   最后一个事故记录编号
24 8   第一个事故记录标识符
32 8   最后一个事故记录标识符
40 4 128 指针数据偏移量
44 4   最后一个事故记录数据偏移量
48 4   自由空间偏移
52 4   事故记录校验以及
56 64   空值
120 4   未知
124 4   校验以及

表 Chunk header

image.png

图 Chunk Header文件格式

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

偏移量 长度 描摹
0 4 “**\x00\x00” 署名
4 4   事故记录块的大小
8 8   事故记录标识符
16 8   事故记录写入时间
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字节的内容:

456C6646696C650000000000000000000000000000000000080000000000000080000000010003000010010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

使用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

单条日记删除参考链接:

https://www.secpulse.com/archives/73273.html

*

您可能还会对下面的文章感兴趣: