日志清理与反取证痕迹识别

日志清理与反取证痕迹识别

很多应急现场最棘手的情况，并不是日志太多，而是日志“不完整”。攻击者一旦拿到主机控制权，通常很快就会尝试清理登录记录、命令历史、系统日志、Web 访问痕迹，甚至直接修改文件时间戳，让分析人员在最关键的时间窗里失去可用证据。

在 0x02电子取证 中，系统日志检查 已经给出了 Linux 的 /var/log/*、Windows 的 wevtutil、Get-WinEvent 等基础取证入口。这些内容主要解决“去哪里拿日志”。到了 0x03取证分析，更重要的问题变成了：这些日志还可信吗，攻击者是否对它们动过手脚，我们又该如何从断裂和缺口中反推反取证行为。

0x01 反取证分析要回答的三个问题

日志清理与反取证分析建议优先回答：

1. 哪些证据源可能被清理了？ 包括系统日志、应用日志、命令历史、Web 日志、浏览器痕迹、邮件痕迹。
2. 清理发生在什么时候？ 是否发生在登录成功、样本执行、持久化建立之后。
3. 清理动作是否影响核心结论？ 即便主证据被删，是否还能通过其他来源补齐时间线。

反取证分析的价值，不是简单说一句“日志被删了”，而是尽量回答“删了什么、何时删的、是谁删的、删之前发生了什么”。

0x02 攻击者最常清理哪些痕迹

1. Windows 侧

常见清理对象：

• Security / System / Application 日志
• PowerShell 日志
• 远程桌面日志
• IIS 日志
• Prefetch、Recent、Jump List
• 计划任务、服务安装痕迹

常见命令或动作：

wevtutil cl Security
wevtutil cl System
Clear-EventLog Security
Clear-History
Remove-Item (Get-PSReadLineOption).HistorySavePath

2. Linux 侧

常见清理对象：

• /var/log/secure
• /var/log/auth.log
• /var/log/messages
• Web 访问日志
• ~/.bash_history
• wtmp, btmp

常见命令或动作：

history -c
history -w
unset HISTFILE
rm -f ~/.bash_history
echo > /var/log/secure
sed -i '/1.2.3.4/d' /var/log/auth.log
touch -t 202401010101 /var/log/secure

攻击者并不一定会“全部删除”，更常见的是删掉自己最敏感的那一小段。

0x03 识别日志清理的四个核心信号

1. 时间线断层

最典型的反取证信号就是日志时间轴突然断裂。

例如：

• Security 日志在凌晨 02:11 到 02:24 之间完全空白
• /var/log/secure 少了一整段爆破或成功登录记录
• IIS 日志在告警时间窗恰好缺失

如果缺口正好落在异常行为发生时段，反取证概率极高。

2. 日志量与系统运行状态不匹配

例如：

• 一台高频登录的堡垒机，wtmp 却异常干净
• 长期运行的 Web 服务器，某一天访问日志文件大小突然极小
• 活跃 Windows 终端，Security 日志记录数异常偏低

“本应很多，却几乎没有”本身就是证据。

3. 文件时间与内容不匹配

常见异常：

• 日志文件修改时间很新，但内容只到很早之前
• 文件创建时间、修改时间、归档时间互相矛盾
• 日志轮转编号异常跳号

这类现象常见于：

• 覆盖式清空
• 手工替换旧日志
• 时间戳伪造

4. 命令历史本身出现清理命令

很多时候最直接的证据不是日志本身，而是攻击者顺手留下的清痕命令：

• wevtutil cl
• history -c
• rm ~/.bash_history
• Clear-History

这类命令一旦出现，应直接提升为“攻击者进入反取证阶段”的关键事件。

0x04 Windows：事件日志被清理后还能看什么

Windows 下最常见的清痕手法是 wevtutil cl 或事件查看器手工清理。

1. 清理日志本身可能留下痕迹

尽管攻击者想删除事件，但清理动作本身也经常会留下线索，例如：

• Security 中的日志清理事件
• System / PowerShell 中的命令执行痕迹
• 进程创建日志中的 wevtutil.exe

也就是说，攻击者删的是“历史事件”，但不一定能完美抹掉“执行了清理这个动作”的事实。

2. 日志缺失后要立刻转向旁证

优先补充以下证据：

• 4688 进程创建
• Prefetch
• Amcache / Shimcache
• IIS / 应用日志
• 文件创建时间
• 计划任务、服务、注册表变更

如果 Security 被清空，但你还能看到：

• psexec.exe
• powershell.exe -enc
• 新服务创建
• 新文件落地

依然可以把事件链大致还原出来。

3. wevtutil 既是取证工具，也是清痕工具

这正是分析中的一个关键点：在 0x02 中它是高效导出日志的工具；在 0x03 中，同一个工具也可能是攻击者用于清理日志的手段。

因此分析 wevtutil 相关痕迹时，必须结合：

• 命令参数
• 执行时间
• 父进程
• 操作者身份

区分它究竟是蓝队导出日志，还是攻击者清空日志。

0x05 Linux：删除历史比删除日志更常见

Linux 攻击者有时不会大面积删日志，因为那样太显眼；他们更常做的是清理命令历史、删掉单个 IP 的记录、或者篡改局部时间戳。

1. 命令历史缺失的判断方法

应重点观察：

• 登录会话存在，但 ~/.bash_history 明显为空
• 历史文件更新时间与登录时间不匹配
• 某用户登录后没有任何命令记录，但系统中出现大量新文件

这类现象往往说明：

• 攻击者使用了非交互 shell
• 历史未写回
• 历史被主动清理

2. 认证日志被局部篡改的判断方法

常见方式：

• 用 sed -i 删除指定 IP
• 复制旧日志覆盖新日志
• 仅删除成功登录记录，保留失败爆破记录

识别信号：

• 时间顺序突然不连续
• 某一小时只有失败记录没有成功记录
• last, wtmp, auth.log 三者互相对不上

真正可信的判断必须来自多源交叉。

0x06 反取证常发生在攻击链的哪个阶段

日志清理通常不是一开始就做，而是发生在以下阶段之后：

1. 初始进入之后

攻击者确认已拿到主机，就会删掉明显的登录或上传痕迹。

2. 建立持久化之后

在创建计划任务、服务、公钥、后门后，攻击者往往开始清理前置痕迹，降低被第一时间发现的概率。

3. 数据外传之前或之后

如果攻击者已开始打包、导出、外传，反取证通常会同步进行，以拖慢调查速度。

因此，一旦你在时间线上定位到清痕动作，往前一小段时间，往往就是最关键的攻击动作窗口。

0x07 如何从“缺失”反推真实事件

反取证分析的核心能力，是从缺失中找回事件。

1. 用其他日志补系统日志

例如：

• 系统日志缺失，用 Web 日志、数据库日志、EDR 告警补
• Windows Security 缺失，用 PowerShell、Prefetch、文件时间补
• Linux auth.log 缺失，用 wtmp、命令历史、网络连接补

2. 用结果反推过程

如果已经看到：

• 新增服务
• 新建计划任务
• 新公钥
• 新后门文件

即使中间一段登录日志没了，仍然可以反推出“此前一定发生过控制建立和命令执行”。

3. 用批量异常补局部缺失

例如一批主机在同一夜间：

• 同时缺失某时段 Security 日志
• 同时出现同样的计划任务
• 同时连到同一 C2

这就足以说明不是偶发故障，而是统一攻击和统一清痕。

0x08 三个常见误区

1. 看到日志少就认为系统没问题

日志少并不等于安全，反而可能意味着日志被清理过。必须结合资产类型和业务活跃度判断“少得是否合理”。

2. 把日志清理等同于完全无解

攻击者很难同时完美清除所有证据源。系统日志没了，并不代表浏览器、文件时间、网络连接、计划任务、服务、数据库与邮件侧也都没了。

3. 忽略蓝队自身操作带来的覆盖

现场处置时，蓝队自己的操作也可能改变日志状态。例如：

• 手工打开工具覆盖痕迹
• 直接运行清理脚本
• 导出不规范导致时间变化

因此固定证据前要尽量避免高干扰操作。

0x09 建议的交付结构

反取证分析结果适合整理成如下表格：

这种结构能帮助你在报告里清楚说明：

• 哪段证据已经不可信
• 哪些结论仍然可以通过旁证成立
• 调查结论的可信边界在哪里

0x0A 总结

反取证分析的关键，不是抱怨“日志没了”，而是系统性回答：

• 哪些日志被删或被改
• 删除发生在攻击链的什么阶段
• 还有哪些旁证足以支撑事件结论

当你能从日志断层、文件时间异常、清痕命令和多源证据不一致中读出攻击者的意图时，0x02 里的系统日志采集就真正升级成了 0x03 的取证分析能力。因为在真实战场上，最有价值的证据，往往就藏在“本应存在却突然消失”的那一段空白里。