关键发现

• Check Point Research 在微软 Teams 中发现了四个漏洞，攻击者可以利用这些漏洞假冒高管、操纵消息、篡改通知以及在视频和音频通话中伪造身份。
• 外部访客用户和恶意内部人员均可利用这些漏洞，从根本上破坏了全球超过3.2亿用户所使用的平台的信任机制。
• 现实风险包括高管冒充、金融欺诈、恶意软件传播、虚假信息活动和敏感通信中断。
• Check Point Research 已于2024年3月23日向微软负责任地披露了这些漏洞。微软确认了报告并展开调查，随后发布了修复程序。截至2025年10月底，所有漏洞均已修复，微软官方将其中一个通知欺骗漏洞追踪为 CVE-2024-38197。

自2017年3月推出以来，微软 Teams 已成为全球使用最广泛的通信和协作平台之一。作为 Microsoft 365 套件的一部分，Teams 为超过3.2亿月活跃用户的工作场所提供聊天、视频会议、文件存储和应用程序集成功能。从全球最大的企业到中小型企业，Teams 已成为现代工作场所通信的关键支柱。

我们的研究揭示了 Teams 中一系列破坏这些可信通信渠道的漏洞。我们发现，外部访客用户和恶意内部人员都可以操纵消息、冒充高管，甚至伪造通知。实际上，这意味着攻击者可以以访客身份进入，并令人信服地伪装成首席执行官，这是组织机构赖以安全运作的信任基础的根本性崩溃。

不断演变的威胁形势

近年来，我们见证了包括国家资助组织和国家级行为者在内的复杂威胁行为体，越来越将协作平台和通信工具作为更广泛的间谍活动和数据外泄行动的目标。这些高级持续性威胁（APT）组织表现出对以下方面的特别兴趣：

• 针对广泛使用的软件平台的供应链攻击
• 利用可信通信渠道的社会工程活动
• 利用对熟悉界面的信任的商业电子邮件入侵（BEC） 攻击
• 针对远程工作工具的凭证窃取行动

如今，威胁行为体利用用户对熟悉的通信和工作区界面固有的信任，使用社会工程技术通过组织日常运营所依赖的平台来操纵员工。

最近的威胁情报报告强调了这些威胁行为体如何特别针对远程工作基础设施，认识到通信平台已成为关键的业务基础设施。鉴于这种不断演变的威胁格局，Check Point Research 着手调查广泛应用的工作区工具中潜在的安全漏洞。作为对这些平台进行更广泛研究计划的一部分，我们检查了微软 Teams，以确定其信任机制可能被颠覆的方式。此处展示的研究结果凸显了 Teams 作为一个更广泛问题的例证：攻击者可以利用现代工作区工具中的信任。

我们的研究发现

我们从两个关键的攻击角度进行了这项研究：试图渗透组织的外部访客用户，以及寻求滥用其现有访问权限的内部恶意用户（例如被入侵的员工或内部威胁）。

我们的研究揭示了微软 Teams 中几个可被利用来操纵消息内容和发送者身份、更改通知外观的漏洞。最关键的是，我们发现外部访客用户和内部恶意行为者都可以有效地转变其身份，使其看起来像是值得信赖的人员，包括C级高管，这从根本上打破了组织依赖的安全通信信任边界。

这些发现意义重大，不仅展示了理论风险，而且展示了可用于传播虚假信息、身份冒充和隐私泄露的实际漏洞。无论是从外部访客用户开始，还是作为恶意内部人员操作，攻击者都可以无缝过渡，看起来像是一位值得信赖的权威人物，可能欺骗员工，让他们相信自己正在与CEO、财务总监或其他高级权威人物沟通。

具体来说，我们能够：

• 不留痕迹地编辑消息：我们发现了一种可以修改已发送消息内容的方法，而不留下通常的"已编辑"标签。
• 操纵消息通知：我们的研究揭示了一种可以更改消息明显发送者的技术，例如能够显示来自CEO等高知名度人物的通知，从而利用通常与此类通信相关的信任和紧迫感。
• 通过私聊中的会话主题更改显示名称：我们发现了一个漏洞，允许攻击者通过修改会话主题来更改私聊对话中显示的名称。双方参与者都会将修改后的主题视为对话名称，可能会误导他们对对话上下文的理解。
• 伪造视频/音频通话中的来电者身份：我们发现，通过特定操纵通话发起请求，可以任意修改通话通知（以及通话过程中）中使用的显示名称。此漏洞允许攻击者伪造来电者身份，向通话接收方呈现任何选定的名称。

这些漏洞共同展示了攻击者如何侵蚀使协作工作区工具有效的基本信任，将 Teams 从业务推动者转变为欺骗的媒介。

微软此前已将 CVE-2024-38197 披露为微软 Teams iOS 版中的一个中危欺骗问题，指出早期客户端版本未正确验证消息发送者字段，因此在有限情况下可能误报用户身份。我们的研究扩展了这些发现，展示了一条影响更大的利用途径：我们开发了一个概念验证，展示了恶意机器人或网络钩子如何制作带有伪造"发件人"属性的负载，这些负载在 Teams 界面中能够令人信服地呈现为可信用户。这种放大不仅凸显了目标冒充的实际风险，也凸显了跨 Teams 客户端进行更严格验证控制的更广泛需求。

技术深度剖析

尽管微软 Teams 提供了功能相似的网页版和应用程序版本，但我们的研究重点集中在网页版上。该版本与其应用程序版本一样，接受并处理用于各种操作（例如发送消息和拨打电话）的JSON负载。

理解 Teams 消息架构

当发送消息时，请求正文中包含多个参数：

• content：实际的消息文本，用HTML标签包围。
• messagetype：对于标准文本消息，通常设置为 RichText/Html。然而，对于其他操作（如添加新用户或发起新对话），此参数会更改以反映正在执行的具体操作。
• clientmessageid：每条用户消息的唯一标识符，确保每条消息可以被单独跟踪和管理。
• imdisplayname：发送消息用户的显示名称，允许收件人查看消息来源。

发送 POST 请求后，响应中包含 OriginalArrivalTime 参数，该参数携带一个 Unix 时间戳值，这对于发送后修改消息（例如编辑、删除或引用自己或他人的消息）的操作至关重要。

此外，另一个关键信息是分配给每个用户的唯一 UUID。可以通过获取特定用户的对话或其消息（无论是来自私聊还是群聊）来找到它：

https://teams.microsoft.com/api/chatsvc/emea/v1/users/ME/conversations/<USER_ID>/messages?...

这个 UUID（从上图截图看，它以 8:orgid:37f85325... 开头）对于在系统内识别用户至关重要，并在我们将要探讨的漏洞中扮演重要角色。

消息操纵技术

让我们从基础开始，探索可以对自己消息进行哪些修改。如前所述，当我们发送消息时，我们包含了 clientmessageid 参数（以及消息内容），并收到 OriginalArrivalTime 参数的 Unix 时间戳值：

1
2

OriginalArrivalTime: 1709414616944
clientmessageid: 2711247313308716623

在检索整个聊天记录后，我们可以看到这些值：

https://teams.microsoft.com/api/chatsvc/emea/v1/users/ME/conversations/<CONVERSATION_ID>/messages?...

现在，尝试直接在 MS Teams 中编辑我们的消息。不幸的是，此操作会导致消息上方出现"已编辑"标签。为了绕过此限制，我们可以制作一条新消息，并用先前消息中的值（2711247313308716623）替换 clientmessageid。这种方法有效地掩盖了我们的编辑，使其对他人不可检测。

操纵通知

无论是在手机应用还是 PC 上，这些警报都会立即引起我们的注意，尤其是当它们暗示消息来自组织内的关键人物时。例如，收到暗示消息来自 CEO 或其他高级官员的通知，本身就意味着更高的紧迫性和重要性。这种心理效应使得通知不仅具有信息性，而且具有影响力。

在每个发送的消息中，都有一个名为 imdisplayname 的参数，默认情况下显示发送者的名称：

https://teams.microsoft.com/api/chatsvc/emea/v1/users/ME/conversations/<CONVERSATION_ID>/messages?...

通过调查，我们发现这个参数可以被更改为任何期望的值。这种操纵导致收件人收到看似来自实际发送者以外的人的通知：

请求负载：

1
2
3
4
5
6
7

{
    "content": "<div>This is a spoofed notification</div>",
    "messagetype": "RichText/Html",
    "contenttype": "text",
    "imdisplayname": "Spoofed Sender Name", // 被篡改的显示名称
    ...
}

结果： 收件人设备上弹出的通知显示发送者为 “Spoofed Sender Name”（例如 “Jane Doe, CEO”），而非实际发送者。

在私聊中更改显示名称

微软 Teams 提供了通过特定的 PUT 端点更新群聊中会话主题的功能。此功能旨在帮助用户更有效地组织和识别他们的聊天。

PUT /api/chatsvc/emea/v1/threads/<Conversation ID>/properties?name=topic

通过操纵对此端点的请求，不仅可以更改群聊（这种更改是预期且允许的）中的会话主题，而且令人惊讶的是，在私人对话中也可以更改。

在私聊（两个人之间的直接对话）的情况下，鉴于私聊在传统意义上没有"主题"，对主题的任何更改理想情况下应该受到限制或不适用。

• 更改前：私聊窗口标题显示为双方用户名。
• 更改后：通过发送包含修改后主题的 PUT 请求（例如 {"topic": "Sensitive Budget Discussion with CFO"}），双方看到的私聊窗口标题变成了"与首席财务官进行的敏感预算讨论"。

这种更改一旦执行，可能会误导用户，使他们相信自己正在与不同的人进行对话。

伪造视频/音频通话中的来电者身份

我们发现，通过特定操纵通话发起请求，可以任意修改通话通知中使用的显示名称。此漏洞允许攻击者伪造来电者身份，向通话接收方呈现任何选定的名称。

在通话发起阶段，一个 JSON 负载被发送到： POST /api/v2/epconv 该负载包含定义通话特性的各种参数。其中，“participants” 部分内的 “displayName” 参数特别值得关注。此参数旨在向接收方显示来电者的姓名。

通过修改负载中的 “displayName” 值，我们能够更改来电者的明显身份。例如，将其更改为任意名称会导致通话接收方看到来自修改后名称的来电，而不是实际来电者的身份：

请求负载：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
    "operationId": "...",
    "participants": [
        {
            "mri": "8:orgid:...", // 实际用户ID
            "displayName": "Spoofed Caller Name (e.g., IT Support)", // 被篡改的显示名称
            ...
        }
    ],
    ...
}

这导致： 接收方的来电通知屏幕上显示来电者为 “Spoofed Caller Name”（例如 “IT Support”）。

实际攻击场景

这些漏洞造成了几个与复杂威胁行为体（包括国家级组织）所使用的技术相一致的令人担忧的攻击场景：

高管冒充与社会工程

攻击者可以显著地冒充他人，使消息看起来是由其他人发送的。在私聊中，恶意访客用户可以冒充内部人员，例如财务部门的成员。通知可以被欺骗以显示错误的发送者姓名，利用用户信任官方外观通知（可能来自权威人物或高层管理人员）的本能。

高级持续性威胁与数据外泄

这些攻击可以直接促进通常在国家级行动中看到的更严重的恶意活动：

• 恶意软件传播：攻击者可以发送看似来自可信来源（如高层管理人员）的欺骗性通知，要求采取紧急行动或点击链接，从而安装恶意软件。
• 凭证窃取/欺诈：通过冒充内部人员（特别是财务人员），攻击者可以诱骗获取敏感数据或通过假装讨论预算数字或其他敏感信息进行欺诈。
• 虚假信息活动：创建虚假消息历史记录并破坏对话完整性的能力，使得传播虚假信息活动成为可能。
• 隐私泄露：总体漏洞影响包括隐私泄露。
• 简报干扰：在 Teams 上托管的敏感简报中冒充个人的能力可能传播混淆或诱骗参与者泄露敏感信息。这意味着对任何参与高风险通信的角色都存在广泛风险。

风险缓解策略

组织如何降低风险

微软随后修复了我们在 Teams 中报告的漏洞，无需用户采取任何行动。然而，协作平台仅提供原生安全性的基线，我们的研究表明这一层可以被绕过。

为了保护免受信任利用，组织需要一个额外的防御层，包括：

• 零信任访问控制 – 持续验证用户身份和设备状况，而不仅仅在登录时。
• 高级威胁防护 – 检查在协作应用程序内共享的文件、链接和负载。
• 数据丢失防护（DLP） – 执行细粒度策略以防止未经授权的数据外泄。
• 用户意识和验证协议 – 培训员工对高风险请求提出质疑，并对敏感操作使用带外验证。

保护现代工作场所需要超越协作平台原生提供的安全性。只有通过第二层、多层次的防御，组织才能保护维持业务运行的通信、数据和信任。

加入我们的网络研讨会，深入了解研究结果和实际防御措施： https://pages.checkpoint.com/2025-nov-ww-critical-microsoft-teams-vulnerabilities-uncovered.html

组织如何降低风险（行为实践）

微软随后修复了我们在 Teams 中报告的漏洞。

然而，我们发现的漏洞强调了减少暴露的行为实践的重要性：

• 批判性思维：我们的研究比以往任何时候都更强调持续需要批判性思维。用户应始终质疑他们在网上看到和听到的内容，即使它似乎来自他们通常信任的来源。
• 数字意识：了解这些特定的攻击向量对于提高数字意识至关重要。组织应教育其团队了解这些特定的操纵技术。
• 验证协议：鉴于这些漏洞容易被利用，组织应为敏感通信（尤其是涉及金融交易或敏感数据的通信）实施带外验证方法。

披露时间线

• 2024年3月23日 – 漏洞向微软披露。
• 2024年3月25日 – 微软确认披露，并确认将调查报告的问题。
• 2024年4月18日 – 微软确认报告的行为，并表示将继续调查以确定适当的解决方案。
• 2024年5月8日 – “不留痕迹地编辑消息"问题被修复。
• 2024年7月31日 – “在私聊中更改显示名称"问题被修复。
• 2024年8月13日 – 计划发布修复"操纵通知"问题的日期，该问题被追踪为 CVE-2024-38197。
• 2024年9月13日 – “操纵通知"问题被修复。
• 2025年10月 – “视频/音频通话中的来电者身份"问题被修复。