（QR）用代码解决问题：浏览器隔离环境中的 C2

执行摘要

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

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

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

浏览器隔离的背景

SpecterOps 的优秀员工在今年早些时候发布了一篇博客文章，介绍了浏览器隔离以及渗透测试人员和红队操作员如何解决浏览器隔离场景中的入口工具传输、出口数据传输和一般绕过技术。总之，浏览器隔离通过在安全环境（本地或远程）中对 Web 浏览器进行沙盒处理并将视觉内容流回用户的本地浏览器来保护用户免受基于 Web 的攻击。这种体验（理想情况下）对最终用户完全透明。根据大多数文档，存在三种类型的浏览器隔离：

• 远程浏览器隔离 (RBI) 是最安全和最常见的变体，它在基于云的环境中对浏览器进行沙盒化。

• 本地浏览器隔离与 RBI 类似，但在本地运行沙盒浏览器。这种方法的优点是无需复杂的云到本地连接即可访问本地基于 Web 的应用程序。

• 本地浏览器隔离，或客户端浏览器隔离，在本地容器化或虚拟机环境（例如，Docker 或Windows Sandbox）中运行沙盒浏览器。

远程浏览器处理从页面渲染到执行 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）呈现页面、抓取屏幕截图并读取二维码以检索嵌入的数据。通过利用机器可读的二维码，即使网页在远程浏览器中呈现，攻击者也可以将数据从攻击者控制的服务器发送到恶意植入程序。

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

植入程序不会解码 HTTP 响应来执行命令，而是直观地呈现网页（来自浏览器隔离的像素流引擎），并从页面上显示的二维码解码命令。新的 C2 循环如下：

1. 该植入物通过DevTools 协议控制本地无头浏览器。

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

3. C2 服务器返回一个有效的 HTML 网页，其中命令数据以二维码形式编码（以可视方式显示在页面上）。

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

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

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

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

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

9. 植入物会“休眠”一段时间，然后重复这个循环。

Mandiant 使用Puppeteer和 Google Chrome 浏览器在无头模式下开发了概念验证 (PoC) 植入体（尽管可以使用任何现代浏览器）。我们甚至更进一步，将植入体与Cobalt Strike 的外部 C2 功能集成在一起，允许在通过 HTTP 请求和二维码响应进行通信时使用 Cobalt Strike 的 BEACON 植入体。

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

由于该技术依赖于网页的视觉内容，因此它适用于所有三种浏览器隔离类型（远程、内部部署和本地）。 

虽然 PoC 证明了该技术的可行性，但仍存在一些注意事项和缺点：

• 在 Mandiant 的测试中，使用最大数据大小（2,953 字节、177x177 网格、错误更正级别“L”）的二维码是不可行的，因为本地浏览器中呈现的网页视觉流质量不足以可靠地读取二维码内容。Mandiant 被迫回退到包含最多 2,189 字节内容的二维码。注意：每个二维码最多可以存储2953 字节，具体取决于错误更正级别 (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 协议控制浏览器。组织可以在进程创建期间监控这些标志。