Microsoft Teams 隐蔽通道研究

本文说明了自定义命令和控制 (C2) 植入程序如何通过搭载 Microsoft Teams 流量来绕过网络监控系统和安全措施。此类 C2 通道可以促进未经授权的数据传输或在受害者网络和系统内启用恶意活动。威胁行为者的主要目标是秘密建立此类通道，并在所有其他网络通信中不被注意。这篇文章并没有详细介绍如何在受害者系统上运行恶意代码，而是详细介绍了植入程序如何与攻击者保持交互式通信通道。

Compass 进行了相当多的红队演习。对于红队演习，我们特指全链攻击，包括初始访问、检测规避活动和保持对完成任务的访问。通常，对受害组织知之甚少。在这些领域的工作就像一场小小的军备竞赛，因为检测团队和工具逐渐适应了红队的想法。因此，我们投入了大量时间来寻找绕过恶意软件过滤器的新技术和建立隐蔽通道的方法。

我们明白这些知识非常敏感，但我们也希望与社区分享我们的事实调查结果，以便网络白帽方面的人们有机会了解其影响并获得阐述和讨论有效预防和检测措施的方法。

随着远程工作的兴起，Microsoft Teams 已成为视频会议、聊天和协作的事实标准。Teams 架构的本质是一些在各方之间路由信息的中央系统。因此，必须允许 Teams 客户端软件与 Internet 上的系统进行通信。出于兼容性原因，Microsoft 甚至建议让 Teams 流量绕过检查代理。其网络通信模式与恶意 C2 流量有很大的重叠，因此蓝队几乎不可能发现对手的通信。因此，Teams 是一个有趣的候选对象，可能会被滥用于 C2 流量。

图示的隐蔽通道实现了双方之间的连接，并通过 Microsoft 服务器作为固定跳跃来避免被发现。

图 1：基本概述

上图（图 1：基本概述）描述了隐蔽通道的方案，使用 Microsoft Teams 作为信息载体。一个通道传输来自攻击者的指令，而另一个通道将受害者的查询结果返回给攻击者。

在本文中，讨论了四个隐蔽通道，其中三个专用于传出流量，第四个专用于传入流量。已确定的传出流量隐蔽通道包括 webhook、Teams 消息和 Teams 呼叫通道。但是，对于传入流量，本文概述了一个消息隐蔽通道，它与任何传出消息通道都不同。

传出渠道：Webhook

TL;DR 这是一种有点复杂的方法，可以让 MS Teams 中央服务器代表受害者查询任意 URL（包括渗透负载）。它基本上是某种 SSRF，可以帮助攻击者躲过雷达检查，因为所有受害者请求都会发送到 MS webhook 端点。

Webhook是基于 HTTP 的回调函数，用于将信息转发到 Teams 频道。在 Microsoft Teams 设置中，可以将 Webhook 附加到 Teams 频道，从而提供外部 API 来在该频道中存放消息。端点 URL 组成为 https://xxxx.webhook.office.com/yyyyy，其中 xxxx 对应于 Webhook 所有者的租户，yyyy 对应于随机生成的 ID。Webhook 接受Teams 卡片(JSON) 作为输入。因此，卡片通过 HTTP POST 发送到 Webhook。

以下问题对于建立此类隐蔽渠道起着关键作用：

• 任何人都可以向 webhook 发送消息，无需任何身份验证令牌。

• 可以从任何 URL 获取 Teams 卡片的 JSON 主体中链接的图像。

隐蔽通道是通过制作带有指向攻击者控制的服务器的图片的 Teams 卡片来创建的。要窃取的数据将附加到图片 URL。具体来说，流程如图2 所示。

图 2：传入 Webhook 隐蔽通道流程图

1. 在受害者端，创建一个 Teams 卡（JSON），其中包括链接到攻击者服务器（AS）的图像引用，并附加要窃取的数据（resultquery）。

2. Microsoft 服务器 (MS) 接受来自客户端的输入并以 201 状态代码进行响应。

3. 在渲染过程中，MS 尝试从 AS 获取链接的图像。GET 请求被发送到 AS（例如 https://attacker-webserver.com/resultquery）。

4. AS 将记录传入的请求路径并向 MS 返回 404，表示服务器上缺少资源（服务器也可能返回随机图片）。MS 使用默认图像渲染卡片，没有任何错误。

该视频（图 3：Webhook 数据泄露演示）展示了如何使用 webhook 泄露数据的概念验证设置和程序。

屏幕分为三个区域：

• Teams 窗口显示一个带有恶意 webhook 的频道。

• 左上角的命令shell是攻击者服务器。

• 左下方的命令外壳是受害者工作站。

视频首先会显示攻击者的公共互联网地址，并证明攻击者服务器无法通过 PING 或 HTTP 请求到达。因此，必须通过 Teams webhook 端点 (https://xxxx.webhook.office.com/yyyyy) 发送流量。

之后，受害者将启动一个脚本，该脚本将 Teams 卡片发送到 webhook，并将字符串列表（要窃取的数据）中的每个条目附加到嵌入的图像中，然后最终从攻击者服务器请求该图像。这样，字符串列表就被窃取了。

从攻击者的角度来看，这就是全部了。那么我们如何才能防止这种情况发生呢？

可以通过以牺牲功能为代价阻止对 webhook 端点的请求来阻止这种隐蔽通道。或者，我们可以考虑密切监视带有指向外部图像的潜在恶意链接的 Teams 卡片的 webhook API 请求。

乍一看可能不太明显，但请注意，通过 Teams 配置禁止创建 webhook 并不一定会阻止攻击者使用恶意 webhook 创建自己的频道并使用该频道进行攻击。

传出渠道：Teams 消息

此隐蔽通道利用从文件系统检索身份验证数据的可能性，并利用这些数据与 Microsoft API 进行交互。身份验证数据隐藏在使用密钥加密的 cookie 中，而密钥本身受 DPAPI 保护。

相关文件存储在用户配置文件夹中：

• AppData/Roaming/Microsoft/Teams/cookies（受密钥保护的身份验证数据）

• AppData/Roaming/Microsoft/Teams/LocalState（DPAPI 保护的密钥）

使用 DPAPI 解密密钥可以进一步解密 (AES-GCM) cookie。直接与 API 交互允许攻击者创建、修改、删除和读取聊天中的旧消息。用于与服务器交互的 API 是 https://amer.ng.msg.teams.microsoft.com/，它与Microsoft 宣传的 Graph API明显不同。

我们同意，阻止对 API 的访问并不是解决方案，因为它会使 Teams 变得毫无用处。替代措施可以包括检测与端点通信的异常进程、检测大型聊天消息或高频率的聊天消息，所有这些都是数据泄露活动的模式。然而，这需要拦截或代理 Teams 流量，而这不一定受支持。除此之外，大多数想法都归结为首先防止恶意软件执行。

传出渠道：Teams Call

Microsoft Teams 通话可以通过两种不同的协议建立：STUN（用于 NAT 的会话遍历实用程序）和 TURN（使用中继绕过 NAT 进行遍历）。第一种协议允许 P2P 通信，而第二种协议使用中继服务器以客户端-服务器方式建立通话。可以通过将数据封装到 UDP 数据包中并将其发送到中继服务器来创建隐蔽通道。传入的数据包未经服务器验证，因此会转发给通话中的另一个用户（攻击者）。

由于客户端不知道防火墙强制执行的策略，因此需要ICE协议与服务器协商通道中使用的协议。它需要检查是否可以建立 UDP 或 TCP 连接。ICE 协议还确定连接位置并通知客户端其自身网络的 NAT 设置。一旦客户端成功通过中继服务器的身份验证，它就应该能够使用 UDP 等协议将流量发送到服务器。

对于 PoC 视频，用户 A 和用户 B 都在同一本地网络段上运行。但是，为了避免混淆，PoC 旨在向之前使用 ICE 协议协商的传出 UDP 呼叫（图 4）连接注入额外的数据包，并且所有流量都通过互联网服务器中继。

PoC 概念是等待已建立的呼叫，然后附加到套接字以注入 UDP 数据包，然后将这些数据包发送到中继服务器，中继服务器会将数据包转发给攻击者。

公平地说，这是一个粗略的实现。但是，搭载音频 UDP 流不会影响语音质量，这确实很方便。因此，PoC 清楚地强调了通过标准电话通信协议进行数据泄露的可行性。无论如何，公平地说，Teams 并不是唯一一款实现某种打洞和中继以允许 NATed 设备相互通信的软件。

针对此类通道的缓解措施更难实施。您可以限制 UDP 流量以应对 TCP 语音带来的缺点。注入 TCP 肯定更难实现，并且将成为进一步推动这项研究的一个很好的领域。至少在理论上，网络流量的行为分析可以帮助检测此类流量。不幸的是，通话的 UDP 数据包和要泄露的数据（特别是在泄露前加密数据时）具有非常相似的熵。

接收渠道：消息

第四个也是最后一个隐蔽通道允许从攻击者到受害者建立传入连接。该通道允许将指令从 C2 服务器传送到受害者的计算机。请注意，攻击者和受害者之间的通信始终是间接的，Microsoft 服务器在两者之间传递消息。该通道以与上一个隐蔽通道类似的方式利用消息流。要通过 https://amer.ng.msg.teams.microsoft.com 上的 API 发送 Microsoft Teams 消息，需要以下 JSON 结构：

{   "content":"",   "contenttype":"text",   "messagetype":"text",   "clientmessageid":,   "imdisplayname":"",   "properties":{      "importance":"",      "subject":""   }}

{   "content":"<p value='secretMessage'> message </p> "",   "contenttype":"text",   "messagetype":"RichText/Html",   "clientmessageid":,   "imdisplayname":"",   "properties":{      "importance":"",      "subject":""   }}

在这种情况下，似乎缺乏对标签内特殊属性的验证。段落标签允许定义服务器不会剥离的“值”属性。尽管已将值属性的内容传输到受害者的计算机，但 Microsoft Teams 无法将其可视化。一旦服务器通过接收方的 WebSocket 发送消息，就可以使用 Teams cookie 从 WebSocket 获取整个消息，或者通过读取 Teams 应用程序在以下路径维护的日志文件来获取整个消息：%userprofile%/AppData/Roaming/Microsoft/Teams/IndexedDB/https_teams.microsoft.com _0.indexeddb.leveldb

采用相同的缓解策略：内容过滤和异常内容检测。

总体防御与对策

尽管需要进行充分的内容过滤，但阻止某些提供 webhook 功能的 IP 地址将有助于缓解 webhook 隐蔽通道。当数据被泄露时，Teams 卡的常用图像路径会发生很大变化，这应该很容易发现。

至于消息和呼叫渠道，禁用与外部租户的通信功能将彻底消除这些渠道。然而，这带来了将受信任的对等租户列入白名单的负担。

这也是微软的建议。与其他租户交换信息的最佳做法是使用Microsoft Purview Information Barrier等工具将其单独列入白名单。或者，为了降低风险同时仍允许与外部用户的通信，可以使用 Microsoft 审计服务将检测应用于消息隐蔽通道。

呼叫隐蔽通道的检测极其复杂，因为 UDP 内部（附加）字节的识别具有与媒体数据相似的熵。

结论

即使在存在安全策略和严格的出口流量规则的情况下，在 Microsoft Teams 中发现隐蔽通道也为提取信息提供了新的机会。这项工作展示了利用 Microsoft Teams 的架构建立隐蔽通道的潜力，并强调了配置强化和白名单方法的必要性。

所讨论的隐蔽通道具有相当高的稳定性和性能，能够通过消息泄露 90KB/s，通过呼叫泄露 32KB/s，通过 webhook 隐蔽通道泄露 6KB/s。

目前，我们还没有发现使用这些隐蔽通道的命令和控制框架。也许是因为 Teams 的不断转型。基础设施不断变化，为了使 C2 可靠，植入物也需要不断变化，尤其是即将发布的新 Microsoft Teams 版本。