闲聊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，超过最大制约也优先笼盖过期的日记记录。
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。
图 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）文件是一种二进制格式的文件。
图 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 | 已加添 |
图 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
图 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 就是这个思路，仅仅时修改了程度，实际上并没有删除日记内容。完成思路以下图：
图 删除事故记录思路
为了确保修改后的日记文件能够被正确识别，还需要修改多个标志位以及重新计算校验以及。
图 不正确修改事故日记
为了确保不出现如上图所示的错误，总结一下删除单条日记内容的要领：
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。
图 test.evtx文件
1. File Header中的Next recordidentifier的值减一
File Header是全部文件最最先的部分，Nextrecord identifier的偏移量为24(0×18)，其长度为8字节。实验文件test.evtx内容以下：
图 test.evtx文件内容
Next record identifier的值为0×09。将该值减一0×08 写入。这儿需要提一下的是，该文件的字节序为小端，因此低位会在前面。
2. 重新计算File Header中CheckSum
计算要领：前120字节做CRC32运算，偏移量为124(0x7c)，长度为4。修改后的文件内容以下图：
图 修改后的test.evtx
现在提取前120字节的内容：
456C6646696C650000000000000000000000000000000000080000000000000080000000010003000010010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000使用python中binascii模块计算CRC32。代码以下：
图 计算CRC32代码
输出的效果为：0xfb027480，修改文件内容，修改后以下图：
图 修改checksum
3. 修改Event Record
通过find hex values查找2A2A0000，定位到第8条Event Record。该条Event Record的长度为 0×180。以下图：
图 第8条EventRecord
第7条Event Record的长度为0×170。以下图：
图 第7条EventRecord
计算需要修改的内容长度。新长度为0×170+0×180=0x2f0。由因而删除最后一条记录，所以不需要更新Event record identifier。修改长度的地位有两个，分别为第7条日记的长度以及第 8条日记的最尾部。
图 第7条日记
图 第8条日记
4. 更新ElfChnk
搜索ElfChuk症结字，找到对应ElfChuk地位。以下图：
图 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以下图：
图 修改后的ElfChnk
经过修改后，使用体系自带的事故查看器关上，此时日记文件中最后一条记录被成功删除。
图 成功删除单条日记记录
此处讲的是删除最后一条记录的具体过曾，删除第一条以及中间的记录在实际操作中会有一些不同样的部分，只需对了解evtx文件的格式，删除evtx格式内容中的记录要领并不唯一。只要要删除对应的数据块，并终极使该文件的校验通过即可。
恢复被删除的记录
使用以上的方式删除单挑记录，实在被删除的数据并没有真实的被删掉，严格意义上讲就是将部分数据进行了隐躲。恢回复再起本的数据可以使用fox-it的danderspritz-evtx工具，缘故起因就是用删除数据的思路反向恢复就行。使用该工具，确凿可以将被删除的数据提取出来，无非恢复的evtx格式的文件并不能被关上。暂时没有研究该代码的完成过程，所以不能下阐发详细缘故起因。
工具使用以下图：
图 danderspritz-evtx使用
恢复数据被导出为xml格式文件，以下图：
图 该条为被删除的第8条记录
恢复的evtx格式文件关上失足，以下图：
要是需要将日记真实的删除，可以使用\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
*
