mimikatz之日志攻防

前置知识

windows vista 以前系统 日志信息

日志扩展名：.evtx

三个主要日志：安全事件 应用事件 系统事件

位置：C:WindowsSystem32config

windows vista+ 及以后系统 日志文件与类型分类更多。

主要日志变成数十个 甚至上百个。

windows日志（三个主要日志依旧存在），应用与服务日志，第三方应用日志等

位置：C:WindowsSystem32winevtlogs注意不同环境位置的差异性

事件日志生成的数据流

控制面板所有控制面板项管理工具服务 查看 或者 进程右键 - 属性 查看

注意不同环境中命名的差异性

可以发现，不同环境中的服务名称的差异性命名

任务管理器中的服务PID与进程svchost.exe PID一致

事件日志服务（属性中），实际上是一个svchost.exe镜像实例。以帮助和管理日志服务。

svchots.exe 元数据中的日志服务项会加载wecsvc.dll文件（其他很多第三方工具也都可查看）

wecsvc.dll文件有很多模块，任何人都可以利用它篡改结果字符串。

命令行是svchost.exe的路径，如下图。但请记住，一切都是通过wecsvc.dll加载得来的。因此，这上面的字符串看上去可能不是真实的。这将引入内存取证的知识。

比如用Volatility，查API hook地址范围的合法性，内存中加载的DLL等。

关注更多的第三方工具，体验它并观察更多颗粒度的细节。

PID关联线程功能

从内核的角度来运行这个进程时，会展现出更多线程的颗粒度。进程之后有线程，线程做实事。

注意数据流与缘由，从表层到里层

event --> svchost.exe --> 加载 wecsvc.dll

event服务属性命令行 --> 第三方工具关联同一个PID svchost.exe实例发现一堆读写文件与路径文件 --> 最后展现内核角度的线程

如果事情很复杂，引入脑图已发现详细颗粒度信息之间的威胁气味。

颗粒度抽象思维是红队成功利用的关键方式之一。我将上面的原理，步骤，数据流处理抽象表示为 1 --> 2 --> 3 -->4。攻击者可以从1234，这四种角度分别入手已进行利用该原理链。只需片刻即可利用，因此请确保您已知晓上述的整个步骤，过程与数据流间的关联。

红队在关注github上最新的项目。一旦有方式，方法出现在github上。他们非常迅速的将它武器化还更新自己的武器库。让我们看看红队的TTPs。

攻击者使用的TTPs

清除日志

具有管理员权限，可以使用 CLI（命令行） 和/或 GUI（图形化界面） 清除事件日志。

在整个攻击者生命周期中，某些组织会间歇性地清除。这种组织计划周详，非常擅长清除日志。

他们有一个非常好的清理计划：毁掉他们所有的恶意软件，输出的文件，安全的删除一切，最后在撤退时清除掉日志文件。

下图为捕获到的清除日志痕迹。您可以关注GitHub上各种蓝队工具并进行测试来呈现更多的细节部分。比如这里的工具：https://docs.microsoft.com/en-us/sysinternals/

如果没有一种机制可以捕获这种清除日志的痕迹，会非常的痛苦。日志都没了，去查谁。。

他们进行特权提升，清除部署的恶意软件的所有事件日志。

清除事件日志的动作会创建一个事件日志，审计日志已被清除。它会被SIEM平台捕捉到并告警。

【注意】攻击者会利用这个告警，在晚上疯狂告警已试图在时间线上欺骗您，但它们真实的攻击过程没有发生在告警的时间线里。有点像计中计。

将日志转发到SIEM平台或者其他存储库

必须要有这种平台来保护日志，这应该在组织中标准化。

不要说承担不起这个费用。可以买几块硬盘来拷贝。

监控 “Audit Log was Cleared" 事件，Security EID为 1102。

干预事件日志和设置

禁用事件日志服务

停止服务会产生很多的其他信息，它阻止日志存储。可以将这些信息与您知道的事件日志清除的信息结合起来。

攻击者不会过分的关注停止服务对于取证方面有什么含义。他们只会学习停止服务这种技巧的手法。

注册表中关于修改事件日志设置的变量位置。注意此处是否被红队光临与篡改过。

HKLMSYSTEMCurrentControlSetServicesEventLog

保存这些基线值在日后进行核查。【注意，不同环境的机器，基线值和键值的差异性】

有不同的攻击组织甚至会在日志大小的细节上做文章，他们篡改大小值让它很小，呈现很多文件与事件，然后用噪声淹没它。

在SIME平台上编写规则来检测这种服务停止攻击，因为SIEM平台没有预期收到该机器的日志转发的数据后，可以判定为异常。

检查注册表或内存以获取事件日志服务的证据。它应该一直运行。注意service state：该日志服务是运行态的。

增减日志

攻击者通常会清除一个，而不是全部

mimikatz干涉日志

mimikatz的事件日志编辑

privilege::debug 提权。没有权限，怎么操控日志。

drop功能：patch events service 抓住这个事件服务防止它生成新的事件

clear：清除这个事件日志

抓住服务，停止生成新事件，再删除。日志就没了。

如上所述：如果有与系统层面交互的权限时（这里为debug权限），可以禁用事件服务。安全事件日志空空如也，脊椎骨发凉。

这种改变是暂时性的。如下图所示。patch前与patch后的文件是一样的。说明没有进行持久化的驻留。当然，您也可以使用文件完整性监控中的hash值来对比。

Invoke-Phant0m 阻断日志线程

使用该工具进行线程中断。记得回想原理数据流，这在哪个阶段动了心思。将日志进程关联中的内核运行资源视角中的线程干掉。

服务（还在运行）-->进程（还在运行）-->线程（线程被干掉了）

日志进程还在运行，但负责日志记录的线程却没有了，日志不再生成。细节颗粒度到了线程的层面。

大楼是正常的，门也是开着的，但内部的工作人员消失了。日志生成不再正常营业。

这种颗粒度攻击的工具非常好，但也非常可怕。

多元化角度的取证

如何在没有日志的情况下跟踪事件？

看看这些利用工具的使用 -- 做好数据间的关联性

日志是如何中断的？

帐户？

运行中的证据？有没有什么工具的名称？

服务中断的时间范围

删除事件日志不是孤立事件

有很多数据围绕着这种正在发生的事件。多多少少都会有一些关联性。

研究工具的类似脚本，事件停止的时间线，利用的基础设施账户是哪个，有没有线程帮助它回传敏感数据，有没有进行过横向移动。

注意从其他角度关联这些攻击的痕迹。请记住，还有其他事情在发生。网络流量？其他主机的信息？

攻击链是一个详细的夺利过程，而不是一个主机的打点：资料被窃取了？横移到其他区域？网络流量监听？转发隧道？内存取证的视角看看能发现什么痕迹？

如果离攻击时间越近的情况下得到这些内存样本，离真相越进。

第一时间获取内存样本很重要。在大型案件中。

这就是为什么需要类似SIEM平台（SOC），姿态感知等产品的意义所在。

感谢师傅很有耐心的看到了这里。

我们还会再见面点。

共勉。

本文始发于微信公众号（疯猫网络）：mimikatz之日志攻防