与Cobalt Strike和赛门铁克共度的早晨
Joff Thyer //
如果你从事渗透测试有一段时间了，很可能已经或即将参与红队行动。从命令通道的角度来看，Raphael Mudge为Cobalt Strike所做的工作使其成为团队协作的理想平台。与使用Linux “screen"配合PowerShell Empire和/或Metasploit等传统方法不同，Cobalt Strike允许建立操作攻击基础设施，进一步促进真实的威胁模拟可能性。
社区中的Black Hills朋友（Lee Kagan）贡献了一篇优秀的博客文章，详细介绍了如何使用威胁模拟配置文件设置Cobalt Strike，可在https://www.blackhillsinfosec.com/build-c2-infrastructure-digital-ocean-part-1/找到。（他承诺第二部分即将发布。）
作为该文章的一部分，它包含一个指向shell脚本的链接，该脚本自动化了部分设置过程，从而创建适当的Cobalt Strike配置文件。这可以从@KillSwitch的GitHub仓库https://github.com/killswitch-GUI/CobaltStrike-ToolKit/blob/master/HTTPsC2DoneRight.sh找到。
在最近的一些红队活动中，我利用了上述所有信息，配合一些精美的自定义域名和我自己独特的DNS名称服务器基础设施，所有这些都在Digital Ocean的虚拟机中运行。这使我能够创建一个操作基础设施，可以通过适当"成熟"的域名正确提供DNS、HTTP或HTTPS命令通道，并完全模拟类似亚马逊的Web流量。所有这些都使用IP地址不易追溯到我自己的虚拟系统。
我对此感到相当满意，并开始我的冒险，向客户网络投递C2有效载荷。在这种情况下，客户实际上很乐意为运行一些东西，从而消除了测试中的社会工程学方面。我的自然倾向是转向PowerShell和/或可执行内容，尽管我需要意识到端点保护解决方案的存在。
一些使用可执行内容的初步尝试显示，赛门铁克端点保护正在起作用，某些东西会在端点上触发签名。赛门铁克（和其他厂商）随着时间的推移在功能集上发生了一些有趣的变化，其中一些有效，一些则不太有效。我确实保持了非企业消费者版赛门铁克的订阅，因此我进入了一段时间的研究模式。
就赛门铁克端点保护功能而言，我在渗透测试过程中主要遇到以下障碍：
- 端点/基于主机的入侵防御（HIPS）
- 对磁盘上可执行内容的基于签名的保护
- 似乎在进程创建管道期间利用应用程序兼容性工具包（ACT）填充程序的基于签名的保护
- 基于内存的shellcode检测
鉴于这些知识，以及正确威胁模拟的目标，我决定用Cobalt Strike设置三种不同的场景，对赛门铁克端点保护响应进行一些高级测试。在这些场景中，我故意避免了DLL/EXE内容和任何TLS通道。我想专注于防御的HIPS和基于内存的检测功能。
- Cobalt Strike团队服务器，没有自定义HTTP/HTTPS配置文件，使用HTTP在端口80上设置监听器。
- Cobalt Strike团队服务器，使用由HTTPSC2DoneRight.sh脚本生成的亚马逊Web服务器配置文件，并使用HTTP监听器。
- Cobalt Strike团队服务器，使用自定义版本的亚马逊HTTP监听器配置文件。
我用于此测试的赛门铁克软件版本在以下屏幕截图中显示。是的，它截至今天已完全更新。
上述所有场景的有效载荷都是作为PowerShell命令从Cobalt Strike生成的，并粘贴到测试系统的命令shell中。Cobalt Strike可以生成基于32位的shellcode或基于64位的shellcode。
32位有效载荷生成IPS警报
第一个发现是，无论服务器端监听器配置如何，32位有效载荷总是会生成IPS警报，并在任何流量到达服务器之前被阻止。上面显示了一个示例警报。
64位有效载荷成功！
在64位有效载荷的情况下，在以上两个用例中成功建立了到Cobalt Strike团队服务器的命令通道会话：
- 完全没有特定/自定义配置文件的HTTP监听器
- 高度自定义配置文件的HTTP监听器
最奇怪的情况是第二个场景，其中使用了HTTPSC2DoneRight.sh脚本来生成类似亚马逊的配置文件。在这种情况下，使用64位有效载荷，我观察到第二阶段的有效载荷二进制文件传递得很好。在那之后是初始的HTTP GET请求。上面的类似亚马逊脚本生成如下GET请求。
|
|
完全奇怪的是，回到Cobalt Strike的C2通道没有建立，而且客户端工作站上绝对没有恶意活动的输出或反馈。
我决定使用数据包嗅探器，并注意到第二阶段有效载荷传递的观察结果，然后看到当客户端尝试上述GET请求时，连接请求立即被TCP RESET拆除。
客户端工作站的四次单独重试，每次重试之间等待五秒
Cobalt Strike团队服务器上"amazon.Profile"文件的摘录
然后我决定在团队服务器上为相同的配置文件使用嗅探器，但在没有安装赛门铁克端点保护的客户端系统上。
果然，如下面Wireshark的屏幕截图所示，流量按预期顺利通过。
从未安装赛门铁克的系统捕获的C2通道GET请求
我变得非常清楚，赛门铁克HIPS在TCP堆栈尝试传输上述GET请求时阻止并重置TCP连接，这一定是为匹配脚本化亚马逊配置文件而编写的特定签名。
极其轻微修改的配置文件
自然，我决定对团队服务器配置文件进行一个小更改，将GET请求中的原始数字序列全部替换为8。请注意，这是一个非常小的更改，甚至不会绕过构造良好的正则表达式和/或具有多个匹配条件的IPS签名。我没有为此测试更改任何其他参数。其他可能暴露的参数包括主机头，当然还有一些固定的cookie值。
结果？是的，你猜对了，建立了一个愉快的C2会话。
已建立的C2会话
总之，虽然我认为端点保护套件总体上正在变得更好，但对于自定义恶意软件活动仍然有很多工作要做。在执行这项测试工作时，我推测在赛门铁克端点保护环境中：
- 使用典型注入技术传递到内存中的64位shellcode仍然有很好的成功机会。
- HIPS功能似乎完全不会检查第二阶段shellcode的传递。
- 针对广泛发布的渗透测试人员威胁建模技术编写特定的HIPS签名似乎相当武断，而且不是有效的防御。
- 不通知最终用户潜在的恶意活动是一种"假阴性”。坦率地说，没有比不知道更糟的了。
这里给渗透测试人员学到的教训是不要陷入尝试按下"简单按钮"的陷阱。我知道我们经常急于完成事情，但使用互联网上的现成脚本最终会以某种形式被阻止。即使现成脚本是善意的威胁建模，情况显然也是如此。始终审查和验证你将要做什么！祝大家狩猎愉快。