(二维码) 在浏览器隔离环境中实现 C2 通信的突破

(QR) Coding My Way Out of Here C2 in Browser Isolation Environments

执行摘要

• 浏览器隔离是一种安全技术，它通过在安全环境 (如云服务器或虚拟机) 中运行浏览器，然后将视觉内容流式传输到用户设备，从而将网页浏览活动与用户的本地设备分离。

• 组织经常使用浏览器隔离来对抗钓鱼威胁，保护设备免受浏览器传播的攻击，并阻止攻击者使用典型的命令和控制 (C2 或 C&C) 策略。

• 在这篇博文中，Mandiant 展示了一种新颖的技术，可用于绕过当前所有三种类型的浏览器隔离 (远程、本地部署和本地)，以实现通过 C2 控制恶意植入程序的目的。Mandiant 展示了攻击者如何使用机器可读的二维码从攻击者控制的服务器向受害设备发送命令。

浏览器隔离背景

SpecterOps 的优秀团队今年早些时候发布了一篇博文^[1]，介绍了浏览器隔离以及渗透测试人员和红队操作员如何在浏览器隔离场景中绕过工具传输、数据外传和一般性绕过技术。总的来说，浏览器隔离通过在安全环境 (本地或远程) 中沙箱化网络浏览器并将视觉内容流式传输回用户的本地浏览器来保护用户免受基于网络的攻击。这种体验 (理想情况下) 对最终用户来说是完全透明的。根据大多数文档^[2]，存在三种类型的浏览器隔离：

1. 远程浏览器隔离 (RBI) 是最安全和最常见的变体，在基于云的环境中沙箱化浏览器。

2. 本地部署浏览器隔离与 RBI 类似，但在本地运行沙箱化浏览器。这种方法的优势在于可以访问本地基于 Web 的应用程序，而无需复杂的云到本地连接。

3. 本地浏览器隔离或客户端浏览器隔离在本地容器化或虚拟机环境中运行沙箱化浏览器 (例如 Docker 或Windows Sandbox^[3])。

远程浏览器处理从页面渲染到执行 JavaScript 的所有内容。只有网页的视觉外观被发送回用户的本地浏览器 (像素流)。本地浏览器中的按键和点击被转发到远程浏览器，允许用户与 Web 应用程序交互。组织通常使用代理来确保所有 Web 流量都通过浏览器隔离技术提供服务，从而限制出站网络流量并限制攻击者绕过浏览器隔离的能力。

SpecterOps 详细介绍了进攻性安全专业人员在浏览器隔离环境中面临的一些挑战。他们记录了如何通过滥用配置错误来规避浏览器隔离的可能方法，例如使用 HTTP 标头、Cookie 或身份验证参数来绕过隔离功能。

浏览器隔离防止典型的命令和控制

命令和控制 (C2 或 C&C) 指的是攻击者通过恶意植入程序远程控制受感染系统的能力。向受害设备发送命令和从受害设备接收命令的最常见渠道是通过 HTTP 请求：

1. 植入程序通过 HTTP 请求 (例如，在 HTTP 参数、标头或请求正文中) 从攻击者控制的 C2 服务器请求命令。

2. C2 服务器在 HTTP 响应中返回要执行的命令 (例如，在标头或响应正文中)。

3. 植入程序解码 HTTP 响应并执行命令。

4. 植入程序通过另一个 HTTP 请求将命令输出提交回 C2 服务器。

5. 植入程序"休眠"一段时间，然后重复循环。

然而，当使用浏览器隔离时，这种方法会带来挑战——当通过浏览器隔离系统发出 HTTP 请求时，返回到本地浏览器的 HTTP 响应只包含用于渲染远程浏览器视觉页面内容的流引擎。原始 HTTP 响应 (来自 Web 服务器) 仅在远程浏览器中可用。HTTP 响应在远程浏览器中渲染，只有像素流被发送到本地浏览器以视觉渲染网页。这阻止了典型的基于 HTTP 的 C2，因为本地设备无法解码 HTTP 响应 (步骤 3)。

图 1：浏览器隔离 HTTP 请求生命周期的序列图

在这篇博文中，我们将探讨在浏览器隔离环境中实现与受感染系统进行 C2 的不同方法，完全在浏览器隔离上下文中工作。

通过像素发送 C2 数据

Mandiant 的红队为这个问题开发了一个新颖的解决方案。C2 服务器不是在 HTTP 请求标头或正文中返回 C2 数据，而是返回一个显示二维码的有效网页。然后，植入程序使用本地无头浏览器 (例如，使用Selenium^[4]) 来渲染页面，抓取屏幕截图，并读取二维码以检索嵌入的数据。通过利用机器可读的二维码，即使网页在远程浏览器中渲染，攻击者也可以从攻击者控制的服务器向恶意植入程序发送数据。

图 2：通过二维码进行 C2 的序列图

植入程序不是解码 HTTP 响应以获取要执行的命令；而是视觉渲染网页 (从浏览器隔离的像素流引擎) 并从页面上显示的二维码中解码命令。新的 C2 循环如下：

1. 植入程序通过DevTools 协议^[5]控制本地无头浏览器。

2. 植入程序通过无头浏览器从 C2 服务器检索网页。此请求被转发到远程 (隔离的) 浏览器，最终到达 C2 服务器。

3. C2 服务器返回一个有效的 HTML 网页，其中命令数据编码在二维码中 (在页面上视觉显示)。

4. 远程浏览器将像素流引擎返回到本地浏览器，开始显示从 C2 服务器获得的渲染网页的视觉流。

5. 植入程序等待页面完全渲染，然后抓取本地浏览器的屏幕截图。此截图包含二维码。

6. 植入程序使用嵌入式二维码扫描库从截图中读取二维码数据，从而获取嵌入的数据。

7. 植入程序在受感染设备上执行命令。

8. 植入程序 (再次通过本地浏览器) 导航到一个新的 URL，该 URL 包含在 URL 参数中编码的命令输出。此参数传递到远程浏览器，最终传递到 C2 服务器 (毕竟，在合法情况下，可能需要 URL 参数来返回正确的网页)。C2 服务器可以像传统的基于 HTTP 的 C2 一样解码命令输出。

9. 植入程序"休眠"一段时间，然后重复循环。

Mandiant 使用Puppeteer^[6]和无头模式的 Google Chrome 浏览器开发了一个概念验证 (PoC) 植入程序 (尽管可以使用任何现代浏览器)。我们甚至更进一步，将植入程序与Cobalt Strike 的 External C2 功能^[7]集成，允许使用 Cobalt Strike 的 BEACON 植入程序通过 HTTP 请求和二维码响应进行通信。

图 3：在浏览器隔离场景中通过二维码进行 C2 的演示 (在实际应用中 Chrome 浏览器窗口将被隐藏)

由于这种技术依赖于网页的视觉内容，它在所有三种浏览器隔离类型 (远程、本地部署和本地) 中都有效。

虽然 PoC 证明了这种技术的可行性，但也存在一些考虑因素和缺点：

• 在 Mandiant 的测试中，使用最大数据大小的二维码 (2,953 字节，177x177 网格，错误纠正级别"L") 是不可行的，因为在本地浏览器中渲染的网页的视觉流质量不足以可靠地读取二维码内容。Mandiant 被迫退回到包含最多 2,189 字节内容的二维码。注意：二维码可以存储最多 2953 字节^[8]每个实例，具体取决于错误纠正级别 (ECL)。更高的 ECL 设置使二维码更容易读取，但会减少最大数据大小。

• 由于使用无头模式的 Chrome、远程浏览器启动时间、页面渲染要求以及从远程浏览器返回到本地浏览器的视觉内容流的开销，每个请求需要约 5 秒才能可靠地显示和扫描二维码。这在 C2 通道中引入了显著的延迟。例如，在撰写本文时，BEACON 有效负载约为 323 KiB。以每个二维码 2,189 字节和每个请求 5 秒计算，完整的 BEACON 有效负载传输需要大约 12 分 20 秒 (~438 字节/秒，假设每个二维码都能成功扫描且每个网络请求都能顺利通过)。虽然这个吞吐量对于典型的 C2 操作来说肯定足够，但一些技术 (例如 SOCKS 代理) 变得不可行。

• 本博文未考虑浏览器隔离的其他安全功能，如域名信誉、URL 扫描、数据丢失防护和请求启发式分析。进攻性安全专业人员在浏览器隔离环境中操作时还必须克服这些保护措施。

结论和建议

在这篇博文中，Mandiant 展示了在面对浏览器隔离时建立 C2 的新颖技术。虽然这种技术证明了浏览器隔离技术存在弱点，但 Mandiant 仍然建议将浏览器隔离作为防御其他类型攻击 (例如，客户端浏览器利用、钓鱼等) 的强有力保护措施。组织不应仅依赖浏览器隔离来保护自己免受基于 Web 的威胁，而应采用"纵深防御"策略并建立全面的网络防御态势。Mandiant 建议采取以下控制措施：

1. 监控异常网络流量： 即使使用浏览器隔离，组织也应检查网络流量并监控异常使用情况。本文描述的 C2 方法是低带宽的，因此即使传输小数据集也需要多个 HTTP 请求。
2. 监控自动化模式下的浏览器： 组织可以通过检查进程命令行来监控浏览器何时以自动化模式使用 (如上面视频所示)。基于 Chromium 的浏览器使用--enable-automation和--remote-debugging-port等标志来允许其他进程通过 DevTools 协议控制浏览器。组织可以在进程创建期间监控这些标志。

参考资料