蓝队:mimikatz之日志攻防 – 作者:sec875

前置知识

windows vista 以前系统 日志信息

日志扩展名:.evtx

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

位置:C:\Windows\System32\config

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

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

windows日志(三个主要日志依旧存在),应用与服务日志,第三方应用日志等

位置:C:\Windows\System32\winevt\logs注意不同环境位置的差异性

事件日志生成的数据流

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

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

image

image

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

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

image

image

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

image

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

image

image

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

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

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

image

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

PID关联线程功能
image

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

image

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

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

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

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

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

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

攻击者使用的TTPs

清除日志

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

image

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

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

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

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

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

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

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

image

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

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

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

监控 “Audit Log was Cleared” 事件,Security EID为 1102。

干预事件日志和设置

禁用事件日志服务

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

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

image

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

HKLM\SYSTEM\CurrentControlSet\Services\EventLog

image

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

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

image

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

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

image

增减日志

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

mimikatz干涉日志

mimikatz的事件日志编辑

image

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

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

clear:清除这个事件日志

image

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

image

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

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

image

Invoke-Phant0m 阻断日志线程

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

服务(还在运行)–>进程(还在运行)–>线程(线程被干掉了)

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

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

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

image

更多的技巧请参阅以下资料

https://hacker.observer/defense-evasion-windows-event-logging-t1562-002/

多元化角度的取证

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

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

日志是如何中断的?

帐户?

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

服务中断的时间范围

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

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

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

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

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

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

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

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

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

我们还会再见面点。

共勉。

来源:freebuf.com 2021-07-20 10:50:13 by: sec875

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论