前置知识

windows vista 以前系统 日志信息
日志扩展名：.evtx
三个主要日志：安全事件 应用事件 系统事件
位置：C:\Windows\System32\config
windows vista+ 及以后系统 日志文件与类型分类更多。
主要日志变成数十个 甚至上百个。
windows日志（三个主要日志依旧存在）应用与服务日志第三方应用日志等
位置：C:\Windows\System32\winevt\logs注意不同环境位置的差异性

事件日志生成的数据流

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

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



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

任务管理器中的服务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。
干预事件日志和设置
禁用事件日志服务
停止服务会产生很多的其他信息 它阻止日志存储。可以将这些信息与您知道
的事件日志清除的信息结合起来。

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


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

HKLM\SYSTEM\CurrentControlSet\Services\EventLog


保存这些基线值在日后进行核查。【注意 不同环境的机器 基线值和键值的差异性】
有不同的攻击组织甚至会在日志大小的细节上做文章 他们篡改大小值让它很小 呈现很多文件
与事件然后用噪声淹没它。


在SIME平台上编写规则来检测这种服务停止攻击 因为SIEM平台没有预期收到
该机器的日志转发的数据后 可以判定为异常。
检查注册表或内存以获取事件日志服务的证据它应该一直运行。
注意service state：该日志服务是运行态的。


增减日志

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

mimikatz干涉日志

mimikatz的事件日志编辑


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

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

clear：清除这个事件日志


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


如上所述：如果有与系统层面交互的权限时 这里为debug权限 可以禁用事件服务。安全事件日志空空如也 脊椎骨发凉。
这种改变是暂时性的。如下图所示。patch前与patch后的文件是一样的。说明没有进行持久化的驻留。
当然您也可以使用文件完整性监控中的hash值来对比。


Invoke-Phant0m 阻断日志线程
使用该工具进行线程中断。记得回想原理数据流 这在哪个阶段动了心思将日
志进程关联中的内核运行资源视角中的线程干掉。
服务（还在运行）-->进程（还在运行）-->线程（线程被干掉了）
日志进程还在运行 但负责日志记录的线程却没有了 日志不再生成。细节颗粒度到了线程的层面。
大楼是正常的 门也是开着的 但内部的工作人员消失了。日志生成不再正常营业。
这种颗粒度攻击的工具非常好 但也非常可怕。


多元化角度的取证

如何在没有日志的情况下跟踪事件？
看看这些利用工具的使用 -- 做好数据间的关联性
日志是如何中断的？
帐户？
运行中的证据？有没有什么工具的名称？
服务中断的时间范围
删除事件日志不是孤立事件
有很多数据围绕着这种正在发生的事件。多多少少都会有一些关联性。

研究工具的类似脚本 事件停止的时间线 利用的基础设施账户是哪个 有没有线程帮助它回传敏感数据有没有进行过横向移动。
注意从其他角度关联这些攻击的痕迹。请记住，还有其他事情在发生。网络流量？其他主机的信息？
攻击链是一个详细的夺利过程，而不是一个主机的打点：资料被窃取了？横移到其他区域？网络流量监听？
转发隧道？内存取证的视角看看能发现什么痕迹？

如果离攻击时间越近的情况下得到这些内存样本 离真相越进。
第一时间获取内存样本很重要。在大型案件中。
这就是为什么需要类似SIEM平台SOC 姿态感知等产品的意义所在。
感谢师傅很有耐心的看到了这里。
我们还会再见面点。
共勉。