企业协作平台身份滥用攻击机理与防御研究

摘要

随着软件即服务模式的广泛部署，企业协作平台已经深度嵌入组织日常业务流程，成为员工交换信息、共享文件、协调项目的核心基础设施。Palo Alto Networks Unit 42 研究数据显示，过去十二个月内与协作工具相关的恶意活动终端警报增长超过四倍，其中百分之九十九的警报关联聊天或语音钓鱼操作。攻击者不再局限于传统电子邮件钓鱼渠道，而是将受信任的企业协作平台转化为身份钓鱼、仿冒欺骗、凭证窃取、恶意软件投递与社会工程的新型攻击面。本文以 Unit 42 公开威胁研究报告及 KnowBe4 安全分析为核心材料，系统梳理攻击者滥用企业协作平台的完整攻击链路，剖析初始访问、身份仿冒、持久化三个核心阶段的技术机理，结合 APT29、Contagious Interview、Axios 供应链投毒、Linux Foundation 社区攻击、CERT Polska 防火墙入侵等真实案例展开论证，基于 MITRE ATT&CK 框架完成攻击行为映射，评估该类攻击对企业身份安全边界造成的结构性冲击。反网络钓鱼技术专家芦笛指出，企业协作平台已经不再是单纯的生产力工具，而是企业身份攻击面的关键组成部分，仅依靠邮件安全网关与多因素认证不足以抵御该类威胁，必须将身份安全控制延伸至认证后的协作会话行为层面。文章从减少外部暴露、完善身份控制、建立验证程序、强化用户意识、主动监控五个维度提出分层防御策略，为企业构建协作平台安全防护体系提供参考。

关键词：企业协作平台；身份滥用；聊天钓鱼；社会工程学；MITRE ATT&CK；身份安全

1 引言

在云计算与远程办公常态化的双重驱动下，Microsoft Teams、Slack 等企业协作平台已经取代传统内部通讯工具，成为组织内部及跨组织协作的主要载体。这类平台通常与企业身份提供商深度集成，员工使用企业统一身份登录后即可访问消息会话、共享工作区、外部联邦组织、访客账户以及第三方应用集成。协作平台的实时通信特性、外部联邦能力、访客访问机制和第三方集成生态，在提升业务效率的同时，也为攻击者提供了新的攻击通道。

传统网络安全防御体系长期以电子邮件为核心防护对象，邮件网关、反钓鱼沙箱、域名信誉分析、附件扫描构成了相对成熟的防护链条。随着邮件安全控制能力持续提升，攻击者开始寻找自动化安全覆盖薄弱的替代渠道。企业协作平台恰好具备攻击者所需的全部条件：平台本身经过企业安全审批，属于受信任的 sanctioned 服务；消息来源于已认证用户身份，天然携带信任属性；平台通知机制合法合规，容易绕过用户的安全警觉；会话内容处于认证后状态，传统安全监控工具对其可见性有限。

Palo Alto Networks Unit 42 于 2026 年 8 月发布的威胁研究报告披露了一组关键数据：在 2025 年 7 月至 2026 年 6 月的十二个月观测周期内，与协作工具相关的恶意活动终端警报数量从每月约 1490 起攀升至 6799 起，整体增幅超过四倍。进一步分析显示，百分之九十九的警报与聊天或语音钓鱼操作直接相关，表明攻击者主要通过定向钓鱼操作获取协作环境访问权限，随后以被攻陷用户的身份和权限开展后续恶意活动。这一数据趋势说明，协作平台滥用已经从个别攻击手法演变为规模化、常态化的威胁类别。

KnowBe4 安全团队在同期分析中强调，几乎所有此类恶意活动都始于一次传统钓鱼攻击。攻击者首先通过电子邮件等渠道获取某个内部账户的访问凭证，随后利用该账户登录企业协作平台，在认证后的会话环境中开展身份钓鱼、仿冒欺骗、凭证窃取和恶意软件投递。由于活动发生在已认证用户的正常协作行为之中，安全工具很难将其与合法业务操作区分开来。这一攻击模式从根本上改变了协作平台在企业安全架构中的定位 —— 它们不再仅仅是生产力应用，而是企业攻击面的有机组成部分。

当前企业安全建设中存在一个普遍认知偏差：许多组织将多因素认证部署完毕即视为身份安全建设完成，认为只要登录环节有 MFA 保护，账户就不会被滥用。然而 Unit 42 的研究清晰表明，多因素认证只能降低账户被攻陷的概率，无法阻止攻击者在获取有效会话之后滥用合法身份开展后续操作。攻击者一旦通过钓鱼获得有效企业身份，就可以以该用户的权限访问企业和云服务，其全部行为在日志层面均表现为合法用户的正常操作。

本文立足于 Unit 42 公开威胁研究报告及 KnowBe4 安全分析的全部事实材料，系统拆解攻击者滥用企业协作平台的攻击机理，结合多起真实入侵案例展开论证，基于 MITRE ATT&CK 框架完成行为映射，分析现有防御体系的结构性短板，提出覆盖减少暴露、身份控制、验证程序、用户意识、主动监控五个维度的分层防御策略。反网络钓鱼技术专家芦笛强调，国内大量企业的安全建设仍停留在邮件网关和终端防护层面，对协作平台认证后行为的监控几乎处于空白状态，随着协作平台在企业业务中的占比持续提升，这一防御盲区带来的风险将不断放大。研究全部论证锚定公开可查证的事件细节，不做过度推演，旨在为企业构建协作平台身份安全防护体系提供现实依据。

2 企业协作平台的信任属性与攻击面分析

2.1 协作平台的核心信任机制

企业协作平台与电子邮件在信任模型上存在本质差异。电子邮件系统中，每封邮件的发送方身份需要通过 SPF、DKIM、DMARC 等协议进行验证，邮件网关可以在邮件到达用户收件箱之前完成多层检测。而企业协作平台的消息传递建立在已认证会话基础之上，用户登录平台时已经完成身份验证，后续发出的每一条消息都自动携带该用户的身份上下文，平台不再对每条消息的发送方真实性做独立校验。

这种信任模型的设计初衷是提升协作效率。员工在 Teams 或 Slack 中收到同事发来的消息时，不需要也不应该怀疑消息来源的真实性，因为消息发送方是经过企业身份提供商认证的内部用户。平台提供的头像、姓名、职位信息等身份标识进一步强化了这种信任感知。然而，当攻击者攻陷某个内部账户之后，这一信任机制就被完整继承 —— 攻击者发出的每一条消息都携带被攻陷用户的真实身份标识，接收方无法从消息外观上区分消息来自用户本人还是攻击者。

协作平台的外部联邦功能进一步扩展了攻击面。Microsoft Teams 支持与外部租户的联邦通信，Slack 支持共享频道和多工作区连接，这些功能使企业员工可以与合作伙伴、客户、供应商在同一平台上直接沟通。攻击者可以利用外部联邦功能，从企业租户外部发起会话请求，冒充 IT 支持人员或其他可信角色与目标员工建立联系。由于会话请求通过平台合法机制发起，接收方看到的是平台原生的聊天邀请界面，而非陌生的电子邮件，警惕性显著降低。

访客账户和第三方集成是另外两个容易被忽视的攻击入口。许多企业为外部合作伙伴开通协作平台访客账户，这些账户拥有部分内部频道和文件的访问权限。第三方应用集成则通过 API 令牌和 Webhook 与协作平台交互，一旦集成配置被篡改或 API 令牌泄露，攻击者可以借助合法集成通道执行恶意操作。Unit 42 研究中提及的 CERT Polska 案例，正是攻击者利用防火墙设备的原生 Slack 通知功能，将窃取的凭证通过合法 Webhook 发送到攻击者控制的 Slack 频道，整个外泄过程不涉及任何自定义恶意工具。

2.2 协作平台成为攻击面的结构性原因

协作平台从生产力工具演变为攻击面，是多重结构性因素共同作用的结果。

第一，安全控制资源分配失衡。企业长期将反钓鱼资源集中投入电子邮件渠道，邮件安全产品市场成熟、检测能力强，而协作平台的安全监控工具相对滞后。许多企业的安全信息与事件管理系统中，协作平台的消息日志、文件共享事件、外部租户交互数据并未被纳入采集范围，安全运营团队对认证后协作会话内的活动缺乏可见性。攻击者选择协作平台作为攻击通道，本质上是在利用防御资源分配的不均衡。

第二，用户安全意识的渠道差异。KnowBe4 的分析明确指出，许多人能够识别电子邮件中的钓鱼指标，但不会将同样的审慎态度应用于协作平台及相关通知工作流。用户在电子邮件中收到陌生链接时会保持警惕，但在 Teams 或 Slack 中收到同事发来的链接时，往往默认链接是安全的。这种渠道差异源于用户对协作平台的信任惯性，而攻击者恰恰利用了这种惯性。

第三，实时交互特性提升社会工程成功率。与电子邮件的异步通信不同，协作平台支持实时对话，攻击者可以在聊天过程中即时回应用户的疑问，动态调整社会工程话术。如果用户提出质疑，攻击者可以立刻编造新的解释；如果用户表现出犹豫，攻击者可以施加时间压力。这种交互式社会工程的成功率远高于静态的钓鱼邮件，因为攻击者可以根据用户反应实时优化欺骗策略。

第四，平台通知机制的合法性掩护。协作平台的消息通知、邮件提醒、移动推送都是平台原生功能，攻击者发出的消息会触发与正常消息完全相同的通知流程。用户在手机上收到 Teams 消息推送时，看到的是平台官方的通知界面，不会怀疑通知本身的真实性。攻击者甚至可以利用平台的托管内容功能，将钓鱼页面托管在平台认可的服务上，使链接域名看起来属于合法服务范畴。

反网络钓鱼技术专家芦笛指出，协作平台攻击面的核心矛盾在于：平台的安全设计假设所有已认证用户都是可信的，但现实中攻击者可以通过钓鱼获取有效认证身份，从而完整继承平台赋予合法用户的全部信任属性。这一矛盾不是某个平台的产品缺陷，而是所有基于身份认证的协作系统共同面临的结构性挑战。

3 攻击链路拆解与技术机理分析

3.1 攻击整体框架

Unit 42 研究将攻击者滥用协作平台的活动按照 MITRE ATT&CK 入侵阶段划分为三个核心环节：初始访问阶段的身份钓鱼、隐身阶段的身份仿冒、持久化阶段的认证过程篡改。三个阶段并非孤立存在，而是构成一条完整的攻击链路：攻击者首先通过外部协作渠道实施身份钓鱼获取初始访问，随后利用被攻陷账户的身份开展仿冒欺骗扩大战果，最后通过篡改认证过程和滥用合法集成实现持久化驻留。

需要特别强调的是，几乎所有协作平台滥用活动都始于一次传统钓鱼攻击。攻击者通常先通过电子邮件钓鱼、短信钓鱼或语音钓鱼获取某个内部员工的账户凭证，然后使用该凭证登录协作平台。这意味着协作平台并不是攻击的起点，而是攻击者在获得初始访问之后选择的主战场。选择协作平台作为主战场的原因在于：在该环境中开展后续攻击被检测到的概率远低于在电子邮件环境中，因为所有活动都以合法用户身份在认证后会话中进行。

3.2 初始访问：通过协作渠道实施身份钓鱼

初始访问阶段的核心技术是通过企业协作平台的外部通信渠道实施身份钓鱼。Unit 42 研究记录了两种主要模式。

第一种模式是滥用 Microsoft Teams 外部联邦功能。APT29（也被称为 Cozy Bear）是已知使用该手法的高级持续性威胁组织。攻击者首先攻陷某个外部租户的 Teams 账户，然后利用 Teams 联邦功能向目标企业员工发起聊天请求。攻击者在聊天中冒充 IT 支持人员或其他可信角色，发送指向凭证收集页面的链接，或者诱导目标批准多因素认证请求、安装远程访问软件、提供账户凭证。由于聊天请求通过 Teams 原生界面呈现，目标员工看到的是平台标准的外部联系人聊天邀请，而非可疑的陌生邮件，初始信任度显著高于电子邮件钓鱼。

第二种模式是利用攻击者控制的 Slack 工作区实施钓鱼。Okta 威胁情报团队记录了此类活动：攻击者创建仿冒目标企业的 Slack 工作区，在工作区内冒充目标组织的管理员和员工，通过直接消息、频道提及和合法平台通知向目标发送钓鱼链接。这些链接将受害者重定向至中间人代理（Adversary-in-the-Middle，AiTM），代理实时捕获受害者的企业凭证和多因素认证令牌。与传统钓鱼网站不同，AiTM 代理在受害者和真实身份提供商之间中转通信，可以绕过基于时间的一次性密码等多因素认证机制，获取完整的会话令牌。

在初始访问阶段，攻击者还会通过协作平台投递恶意文件。Unit 42 报告中记录了一个具体案例：威胁行为者通过 Teams 聊天向受害者发送一个 RAR 压缩文件链接，受害者下载后解压，其中包含一个伪装成 Windows 语言包动态链接库的恶意 lpk.dll 文件，用于实施 DLL 侧加载攻击。值得注意的是，攻击者有时会避免直接通过 Teams 发送文件，因为平台的 Safe Links 和 Safe Attachments 功能会对文件进行检测，攻击者转而在通话过程中引导受害者访问外部网站或执行脚本，以规避平台内置检测。

协作平台的实时交互特性在初始访问阶段发挥关键作用。与静态钓鱼邮件不同，攻击者可以在聊天过程中即时回应用户的疑问。如果用户问 "为什么需要我的密码"，攻击者可以立刻编造 "系统升级需要重新验证身份" 等解释；如果用户犹豫，攻击者可以施加 "不尽快处理账户将被锁定" 的时间压力。这种动态调整的社会工程策略显著提升了攻击成功率。

3.3 身份仿冒：利用可信身份扩大攻击范围

攻击者获得有效企业身份之后，进入身份仿冒阶段。这一阶段的核心是利用被攻陷账户的身份上下文，向其他员工、合作伙伴或客户开展欺骗活动。由于消息来源是真实的内部账户，接收方的信任度远高于来自外部的钓鱼消息。

Unit 42 报告记录了多起精心策划的身份仿冒案例，展示了攻击者如何利用协作平台的信任属性实施复杂社会工程。

第一起案例是 2026 年 1 月 Fireblocks 披露的招聘主题社会工程活动，被评估为与朝鲜关联的 Contagious Interview 行动模式高度吻合。攻击者冒充 Fireblocks 高管、招聘人员和招聘经理，针对技术工作者实施定向攻击。攻击流程经过精心设计：攻击者首先通过社交媒体联系目标，提供专业制作的招聘材料，然后通过 Google Meet 安排视频面试。面试过程中，冒充 Fireblocks 人力资源经理的人员讨论候选人的工作经历、薪酬待遇等正常招聘话题，随后分配一个虚构的 Fireblocks 项目代码审查任务。候选人被指示克隆一个 GitHub 仓库并运行标准设置命令，其中包含的软件包安装操作实际执行了恶意代码，将恶意软件下载到受害者系统。整个攻击过程使用合法的 Google Meet 通信和逼真的面试流程来强化 Fireblocks 身份仿冒的可信度，说服受害者执行恶意代码。

第二起案例发生在 2026 年 3 月，威胁行为者针对 Axios npm 包的主要维护者实施定向社会工程攻击。攻击者冒充一家合法公司，创建了一个高度仿真的 Slack 工作区环境，包含公司品牌标识、频道、用户和消息历史，使目标相信自己正在与真实的企业团队协作。交互随后转移到一个设计成 Microsoft Teams 外观的会议中。在会议过程中，维护者被说服安装一款软件，该软件实际交付了一个远程访问木马。攻击者随后获得了维护者的 npm 账户访问权限，发布了两个被投毒的 Axios 版本，导致安装了受影响版本的项目检索并执行恶意依赖。这起案例的特殊之处在于，攻击者不仅利用协作平台实施社会工程，还将攻击成果转化为软件供应链投毒，影响范围从单个维护者扩展到所有使用 Axios 包的开发者项目。

第三起案例由 OpenSSF 于 2026 年 4 月报告，针对 Linux Foundation TODO Group Slack 工作区成员及相关社区。攻击者冒充一位知名的 Linux Foundation 社区领袖，通过 Slack 直接消息联系目标。消息中包含一个 Google Sites 链接，指向一个欺诈性的 Google Workspace 认证页面。该页面要求目标输入电子邮件地址和验证码，随后指示目标安装一个恶意根证书。在 macOS 系统上，该过程还下载并执行一个可以提供系统访问权限的二进制文件。这起案例利用了知名社区成员的身份信誉和已建立的 Slack 工作区环境来支撑凭证收集和恶意软件投递，目标群体是开源社区开发者，其账户被攻陷后可能影响大量开源项目的安全性。

上述三起案例共同揭示了身份仿冒攻击的几个关键特征。其一，攻击者投入大量资源构建可信的仿冒环境，包括仿真的 Slack 工作区、专业的招聘材料、逼真的视频面试流程，而非简单发送一条钓鱼消息。其二，攻击过程跨越多个通信渠道，从社交媒体到 Slack 再到 Google Meet 或 Teams，多渠道的一致性强化了身份仿冒的可信度。其三，攻击者利用目标的职业动机 —— 求职意愿、技术合作兴趣、社区参与热情 —— 来降低其安全警惕，使恶意操作看起来像是正常的职业活动。

反网络钓鱼技术专家芦笛指出，身份仿冒攻击的难点在于，攻击者使用的通信渠道、平台服务、会议工具全部是合法的，安全设备无法通过域名信誉或文件哈希来识别恶意性。攻击的恶意性完全体现在社会工程交互的内容和意图之中，而这正是自动化安全工具最难检测的层面。

3.4 持久化：篡改认证过程与滥用合法集成

在获得初始访问并通过身份仿冒扩大战果之后，攻击者进入持久化阶段，目标是在被攻陷环境中长期维持访问权限，即使原始凭证被重置也能保持入侵状态。Unit 42 研究记录了一种新颖的持久化手法：滥用协作平台的合法集成功能实现凭证外泄和认证过程篡改。

最具代表性的案例是 CERT Polska 于 2025 年 12 月调查的一起入侵事件。攻击者攻陷了波兰一家制造企业的防火墙 - VPN 设备，随后利用设备的内置脚本机制创建每周定时执行的计划任务。这些脚本执行三项操作：第一项脚本检索一个特权身份的密码；第二项脚本修改安全设置并禁用该特权账户的双因素认证；第三项脚本利用设备的原生 Slack 通知功能，将操作结果发送到攻击者控制的 Slack 频道。

这一攻击手法的精妙之处在于多个层面。首先，攻击者没有安装任何自定义恶意软件，全部操作利用设备内置的脚本引擎和通知功能完成，属于典型的 "就地取材"（Living off the Land）技术，终端防护软件很难将其识别为恶意活动。其次，凭证外泄通道是设备原生的 Slack Webhook 集成，该集成在企业环境中通常被视为合法的运维通知工具，出站流量指向 Slack 官方域名，不会被网络防火墙拦截。第三，攻击者通过禁用双因素认证实现持久化，即使企业后续重置了特权账户密码，攻击者仍然可以通过已禁用 MFA 的配置重新获取访问权限。

Unit 42 报告指出，许多网络和安全设备（包括防火墙、VPN 设备、负载均衡器和管理型交换机）都支持自动化、通知集成和定时任务功能。这些功能在正常运维中用于发送告警、执行备份、自动配置，但在被攻陷后可以被攻击者用于恶意目的。安全团队应当监控来自这些设备的异常 Slack Webhook 流量、不常见的用户代理以及未批准 Slack 集成的系统发起的 Webhook 活动。Microsoft Teams 也支持类似的传入 Webhook 工作流，用于从外部服务发布消息，同样需要纳入监控范围。

持久化阶段的另一种手法是通过协作平台的第三方应用集成获取持久化 API 访问权限。攻击者在攻陷某个用户账户后，可以授权一个恶意第三方应用访问该用户的协作平台数据，获取长期有效的 API 令牌。即使用户后续修改密码，第三方应用的授权令牌仍然有效，攻击者可以持续通过 API 访问用户的消息、文件和联系人。这种持久化手法更加隐蔽，因为第三方应用授权在协作平台中属于常见操作，用户和管理员往往不会逐一审查每个应用的授权范围。

3.5 基于 MITRE ATT&CK 框架的攻击行为映射

Unit 42 研究将上述攻击手法映射到 MITRE ATT&CK 框架的三项核心技术。

第一项技术编号 T1566，即钓鱼（Phishing），对应初始访问阶段。攻击者通过外部协作渠道实施身份钓鱼，利用 Teams 联邦功能、攻击者控制的 Slack 工作区等途径向目标发送钓鱼链接、恶意文件或社会工程消息。与传统电子邮件钓鱼的区别在于，钓鱼载荷通过协作平台的实时通信渠道投递，而非电子邮件附件或链接。

第二项技术编号 T1684.001，即社会工程：身份仿冒（Social Engineering: Impersonation），对应隐身阶段。攻击者通过合法平台通知、托管内容和直接消息实施身份仿冒，冒充 IT 支持人员、企业高管、招聘经理、社区领袖等可信角色，利用被攻陷账户的真实身份上下文增强欺骗效果。

第三项技术编号 T1556，即修改认证过程（Modify Authentication Process），对应持久化阶段。攻击者通过篡改设备配置禁用双因素认证，并利用原生 Slack Webhook 集成实现特权凭证外泄，在不安装恶意软件的情况下维持长期访问权限。

从 ATT&CK 映射可以看出，整套攻击链属于以身份为核心的攻击活动，不依赖传统恶意软件或漏洞利用，而是围绕身份凭证、认证过程和信任关系展开。这一特征决定了传统基于恶意样本和漏洞特征的检测手段难以奏效，防御重心必须转向身份行为分析和认证后会话监控。

4 攻击危害评估与防御短板分析

4.1 多层次安全危害评估

攻击者滥用企业协作平台造成的危害呈现多层次传导特征，从单个账户被攻陷开始，逐步扩展到身份体系、业务数据、供应链乃至行业生态。

第一层次是单个账户的身份凭证泄露。攻击者通过协作平台钓鱼获取员工的企业账户凭证和多因素认证令牌，可以直接访问该用户权限范围内的全部企业和云服务。由于活动以合法用户身份进行，安全日志中不会显示异常登录来源，入侵行为很难被及时发现。

第二层次是内部横向扩散。攻击者利用被攻陷账户在协作平台内向其他员工发送钓鱼消息，由于消息来源是可信的内部同事，接收方的警惕性显著降低，攻击可以在企业内部快速横向扩散。一个账户被攻陷可能在短时间内导致多个关联账户相继被攻陷，形成链式入侵效应。

第三层次是业务数据与知识产权泄露。协作平台中存储着大量业务文档、项目计划、客户信息、财务数据和技术资料。攻击者获得账户访问权限后，可以浏览和下载这些敏感信息，造成企业核心资产泄露。对于研发型企业，技术文档和源代码的泄露可能直接削弱企业的核心竞争力。

第四层次是软件供应链污染。Axios 案例表明，攻击者可以通过协作平台社会工程攻陷开源软件维护者的账户，随后发布被投毒的软件版本，将恶意代码注入依赖该软件的所有下游项目。这种攻击的影响范围远超单个企业，可能波及整个行业的软件供应链，造成大规模安全事件。

第五层次是关键基础设施风险。CERT Polska 案例中，攻击者攻陷的是制造企业的防火墙 - VPN 设备，这类设备是企业网络边界的核心安全设施。如果类似攻击发生在能源、交通、医疗等关键基础设施领域，攻击者禁用特权账户的双因素认证并获取设备控制权，可能对关键业务系统的可用性和完整性造成严重威胁。

反网络钓鱼技术专家芦笛强调，协作平台滥用攻击的危害具有放大效应。单个账户被攻陷在传统安全模型中可能只是局部风险，但在协作平台环境中，被攻陷账户的信任属性可以被攻击者用于欺骗更多目标，攻击影响呈几何级数扩散，企业不能再以单个账户失陷的风险等级来评估此类威胁。

4.2 当前企业防御体系的结构性短板

Unit 42 研究和 KnowBe4 分析共同揭示了当前企业防御体系在应对协作平台滥用攻击时存在的多重结构性短板。

第一，安全监控可见性不足。大多数企业的安全运营中心主要监控电子邮件日志、身份验证日志和终端告警，对协作平台认证后会话内的消息活动、文件共享事件、外部租户交互数据缺乏系统性采集和分析。攻击者的活动发生在认证后会话中，表现为合法用户的正常操作，如果不专门采集协作平台遥测数据，安全团队根本无法发现异常。

第二，外部访问管控松散。许多企业的协作平台开放了外部联邦功能，但没有建立严格的外部租户白名单机制，任何外部租户都可以向企业员工发起聊天请求。访客账户的审批和定期复核流程也不完善，大量不再需要的访客账户长期保留访问权限，成为潜在的攻击入口。第三方应用集成的授权审查同样存在盲区，用户可以随意授权第三方应用访问协作平台数据，管理员缺乏统一的应用授权治理能力。

第三，身份验证程序缺失。多数企业没有针对通过协作平台收到的安全敏感请求制定明确的身份验证程序。员工收到同事通过 Teams 发来的 "请批准这个 MFA 请求" 或 "请安装这个远程工具" 的消息时，没有制度要求其通过独立渠道核实请求真实性，完全依赖个人判断。在社会工程压力下，个人判断的可靠性远远不足。

第四，用户安全意识存在渠道偏差。如前所述，大多数员工能够识别电子邮件中的钓鱼指标，但不会将同样的审慎态度应用于协作平台。安全意识培训通常以电子邮件钓鱼为主要案例，很少涉及协作平台聊天钓鱼、平台通知钓鱼、托管内容钓鱼等场景。员工在协作平台中收到链接时，默认认为链接来自可信同事，不会执行与电子邮件相同的安全检查流程。

第五，网络设备集成功能未纳入监控。防火墙、VPN 设备、负载均衡器等网络安全设备的自动化脚本、通知集成和定时任务功能通常被视为运维工具，安全团队不会专门监控这些功能的异常使用。CERT Polska 案例表明，这些内置功能可以被攻击者用于凭证外泄和持久化，如果不将其纳入安全监控范围，攻击者可以利用合法运维通道长期隐蔽活动。

第六，多因素认证被过度信任。许多企业将部署多因素认证视为身份安全的终极解决方案，忽视了 AiTM 代理可以实时捕获 MFA 令牌、攻击者可以欺骗用户批准 MFA 请求、攻陷设备后可以禁用 MFA 等现实威胁。多因素认证只是降低了账户被攻陷的概率，不能替代认证后的行为监控和身份验证程序。

5 分层防御策略研究

针对协作平台滥用攻击的特征和现有防御体系的短板，Unit 42 研究提出了覆盖五个维度的防御框架。本文在此基础上结合国内企业安全建设实际，对各维度防御策略进行系统阐述。

5.1 减少外部暴露面

减少不必要的外部暴露是协作平台安全防护的第一道防线。协作平台管理员应当定期审查外部联邦配置、访客访问权限和第三方应用集成，确保每一项外部访问都对应明确的合法业务需求。

在外部联邦管控方面，应当尽可能将外部通信限制在经过审批的可信组织范围内，建立外部租户白名单机制，禁止与未审批租户的自动联邦。对于确实需要与外部组织协作的场景，应当通过正式的安全评估流程审批联邦关系，并定期复核联邦关系的持续必要性。Microsoft Teams 管理员可以通过 Azure AD 外部身份设置配置联邦域名白名单，Slack 管理员可以通过企业管理后台控制共享频道和外部连接的审批流程。

在访客账户管理方面，应当建立访客账户的申请、审批、定期复核和自动回收流程。每个访客账户应当关联明确的业务事由和有效期，到期后自动禁用或删除。管理员应当定期审计访客账户列表，清理不再需要的访客访问权限，避免长期闲置的访客账户被攻击者利用。

在第三方应用集成治理方面，应当建立应用授权的统一审批和管理机制。禁止用户自行授权未经过安全评估的第三方应用访问协作平台数据。管理员应当定期审查已授权的第三方应用列表，撤销不再使用或存在安全风险的应用授权。对于需要使用 Webhook 集成的场景，应当限制 Webhook 的创建权限，仅允许经过审批的运维账户创建和管理 Webhook，并对 Webhook 的出站流量进行监控。

反网络钓鱼技术专家芦笛指出，减少外部暴露面的核心原则是 "最小权限"—— 只开放业务确实需要的外部访问能力，关闭一切非必要的联邦、访客和集成功能。许多企业为了图方便开放了全部外部协作功能，实际上大部分功能日常很少使用，却给攻击者留下了大量可利用的入口。

5.2 完善综合身份控制

身份保护应当从认证环节延伸到认证后的会话行为层面。多因素认证、条件访问策略和会话风险评估可以降低账户被攻陷的概率，但无法阻止攻击者在获取有效会话之后滥用合法身份，因此必须配套建立认证后行为监控机制。

在认证防护层面，应当为所有协作平台账户强制启用多因素认证，优先使用基于硬件密钥的抗钓鱼多因素认证（如 FIDO2 安全密钥），而非基于短信或验证器应用的一次性密码。FIDO2 安全密钥通过域名绑定机制可以有效抵御 AiTM 代理攻击，因为密钥只会对注册时绑定的合法域名作出响应，攻击者控制的钓鱼域名无法获取有效的认证断言。条件访问策略应当结合用户位置、设备合规状态、登录风险等级等因素动态控制访问权限，对来自高风险位置或不合规设备的访问要求额外验证或直接阻止。

在认证后行为监控层面，安全团队应当建立针对协作平台用户行为的基线画像，监控可能指示身份被攻陷的异常行为，包括：异常的消息发送活动（如在非工作时间大量发送外部消息）、意外的文件共享行为（如向外部租户共享敏感文档）、与陌生外部租户的通信、异常的登录地点和设备变化、协作平台中第三方应用授权的突然增加。这些行为指标应当与身份验证日志、终端告警数据进行关联分析，当多个维度同时出现异常时触发安全告警。

在特权账户管理方面，应当对协作平台管理员账户和拥有敏感频道访问权限的账户实施更严格的保护。特权账户应当使用独立的硬件密钥进行多因素认证，禁止在日常办公设备上登录特权账户，应当通过特权访问管理平台进行 Just-in-Time 临时授权。定期审查特权账户的操作日志，关注异常的配置变更和权限分配操作。

5.3 建立标准化身份验证程序

身份和安全团队应当定义并向全体员工传达针对协作平台安全敏感请求的标准化验证程序。这一程序的核心原则是：任何涉及凭证、多因素认证批准、软件安装、远程访问工具、敏感数据传输的请求，都不能仅凭协作平台中的一条消息就执行，必须通过经过批准的独立辅助渠道进行身份核实。

具体而言，验证程序应当明确以下规则。第一，员工不得仅凭协作平台消息批准多因素认证提示。当收到 MFA 批准请求时，应当通过电话、企业内部工单系统或当面确认等独立渠道核实请求是否由本人发起。第二，员工不得仅凭协作平台消息安装远程访问工具或其他软件。软件安装应当遵循企业标准的软件分发流程，通过企业应用商店或 IT 服务台正式申请。第三，员工不得在协作平台聊天中分享账户凭证、验证码、恢复密钥等敏感信息。任何要求在聊天中提供此类信息的请求都应当视为高风险。第四，员工不得仅凭协作平台消息修改访问权限或共享敏感文件。权限变更和文件共享应当通过正式的审批流程完成。

验证程序还应当明确指定可用的独立验证渠道。企业应当公布 IT 服务台的官方电话号码、工单系统入口和标准操作流程，员工在收到可疑请求时应当使用这些官方渠道进行核实，而不是使用消息中对方提供的联系方式。验证程序应当纳入员工入职安全培训和定期安全意识更新，确保全体员工理解并遵守。

反网络钓鱼技术专家芦笛强调，身份验证程序的有效性取决于其可执行性。如果验证流程过于繁琐，员工在日常工作中会倾向于绕过流程直接执行请求，导致制度形同虚设。企业应当在安全要求和业务效率之间找到平衡，对高风险操作实施严格验证，对普通咨询类消息不增加额外负担，同时通过技术手段简化验证流程，如在协作平台中集成一键验证按钮，使员工可以方便地发起身份核实请求。

5.4 强化用户安全意识培训

用户安全意识是协作平台安全防护的基础层。Unit 42 研究明确指出，用户意识仍然是有效验证程序的重要组成部分，人们应当像对待电子邮件一样谨慎对待协作消息、平台通知和托管内容链接。

安全培训内容需要针对协作平台场景进行专门设计，不能简单复用电子邮件钓鱼的培训材料。培训应当涵盖以下核心主题。第一，协作平台内容并非自动可信。安全培训应当明确告知员工，与企业协作平台相关联的内容并不因为来自平台就具备可信性，攻击者可以发送直接消息、触发合法的平台通知、使用托管在批准服务上的内容将受害者引导至钓鱼网站。第二，识别协作平台钓鱼的常见指标。培训应当展示真实的聊天钓鱼案例，教员工识别冒充 IT 支持的消息模式、紧急时间压力话术、要求提供凭证或批准 MFA 的异常请求、来自陌生外部联系人的聊天邀请等钓鱼指标。第三，平台通知的安全审查。员工应当了解协作平台的邮件通知和移动推送可能被攻击者利用，收到包含链接的通知时应当像审查邮件链接一样审查链接目的地，而不是默认通知内容安全。第四，托管内容的风险认知。员工应当了解攻击者可以将钓鱼页面托管在 Google Sites 等看似合法的服务上，链接域名属于合法服务并不代表页面内容安全。

培训方式应当从单向知识灌输转向交互式仿真演练。安全意识团队应当将协作平台钓鱼场景纳入钓鱼模拟和安全意识练习，定期向员工发送模拟的聊天钓鱼消息，测试员工的识别和报告能力。仿真演练的结果应当用于识别安全意识薄弱的部门和岗位，开展针对性的补充培训。KnowBe4 作为安全意识培训提供商，其分析本身就强调了将协作平台场景纳入仿真演练的重要性。

培训还应当关注高风险岗位的专项教育。IT 支持人员、财务人员、人力资源人员、开源软件维护者、高管助理等岗位是协作平台钓鱼的重点目标，应当接受更深入的专项培训，了解针对其岗位的特定攻击手法，如 IT 支持人员可能遇到的冒充员工请求密码重置，财务人员可能遇到的冒充高管要求转账，开源维护者可能遇到的冒充合作方要求安装工具等。

5.5 构建主动监控与事件响应能力

安全团队应当将协作平台遥测数据纳入常规监控和事件响应流程，建立覆盖认证、消息、文件、外部交互全维度的监控体系。

在数据采集层面，应当确保协作平台的以下遥测数据被采集并接入安全信息与事件管理系统：用户登录和登出事件、消息发送和接收记录（至少包含元数据，如发送方、接收方、时间、是否包含链接或文件，不涉及消息内容明文）、文件上传和下载事件、外部租户交互记录、第三方应用授权和撤销事件、管理员配置变更操作、Webhook 创建和调用记录。这些数据应当与身份验证日志、终端告警、网络流量数据进行关联分析，构建完整的攻击链可见性。

在网络设备监控层面，应当将防火墙、VPN 设备、负载均衡器、管理型交换机等网络设备的自动化功能纳入安全监控。具体监控内容包括：管理员登录和配置变更操作、定时任务的创建和修改、出站 Webhook 调用（特别是指向 Slack、Teams 等协作平台的 Webhook）、与协作或 SaaS 服务的异常连接。CERT Polska 案例表明，这些设备的内置功能可以被攻击者用于恶意目的，如果不纳入监控，攻击者可以利用合法运维通道长期隐蔽活动。对于未批准 Slack 或 Teams 集成的系统发起的 Webhook 流量，应当触发高优先级告警。

在威胁狩猎层面，安全团队应当定期开展针对协作平台滥用的主动威胁狩猎。狩猎场景可以包括：查找协作平台进程衍生系统命令行解释器的异常行为（如 Teams 或 Slack 启动 PowerShell 或命令提示符）、识别向外部租户异常共享敏感文件的行为、检测短时间内大量添加外部联系人的操作、排查第三方应用授权的异常增长、分析来自异常地理位置的协作平台登录。Unit 42 报告提供了一个具体的威胁狩猎查询示例，用于识别 Slack 或 Teams 衍生系统 Shell 的行为，安全团队可以在此基础上结合自身环境扩展狩猎规则。

在事件响应层面，应当制定针对协作平台账户被攻陷的标准化应急响应流程。流程应当包括：立即撤销被攻陷账户的所有活动会话、重置账户密码并强制重新注册多因素认证、审查并撤销可疑的第三方应用授权、检查并移除异常的 Webhook 配置、审查被攻陷账户近期发送的消息和共享的文件以评估影响范围、通知可能收到钓鱼消息的联系人提高警惕、保留相关日志和证据用于后续调查。事件响应流程应当定期演练，确保安全团队在真实事件发生时能够快速有效处置。

在用户报告机制层面，安全团队应当为员工提供便捷的可疑协作平台消息报告渠道。员工应当能够通过一键按钮或专用邮箱报告可疑的聊天消息、平台通知、托管内容和链接。每一份报告都应当结合身份遥测、登录活动、终端告警、文件共享事件和外部租户信息进行分诊分析，确定活动属于用户误报、外部滥用还是身份被攻陷，及时采取相应处置措施。便捷的报告机制可以显著缩短从攻击发生到安全团队介入的时间窗口，降低攻击造成的损失。

6 讨论

本文基于 Unit 42 公开威胁研究报告及 KnowBe4 安全分析，系统分析了攻击者滥用企业协作平台实施身份钓鱼、仿冒欺骗和持久化攻击的完整机理。研究揭示了一个核心安全范式转变：在企业身份已经成为主要安全边界的当下，协作平台不再仅仅是生产力工具，而是企业身份攻击面的关键组成部分。传统以电子邮件和认证事件为核心的安全控制体系，对认证后协作会话内的活动提供的可见性极为有限，攻击者正是利用这一防御盲区，将受信任的协作平台转化为隐蔽的攻击通道。

研究中分析的多起真实案例展示了攻击者手法的多样性和复杂性。从 APT29 利用 Teams 联邦功能实施身份钓鱼，到 Contagious Interview 通过仿真招聘流程诱导执行恶意代码，再到 Axios 维护者被社会工程攻陷后引发软件供应链投毒，以及 CERT Polska 案例中攻击者利用防火墙设备原生 Slack 通知功能外泄凭证，这些案例共同表明攻击者正在不断创新协作平台滥用手法，将社会工程、合法服务滥用、供应链攻击等多种技术融合使用，攻击的复杂度和影响范围持续提升。

需要客观认识本研究的局限性。由于公开威胁报告的性质，本文无法获取攻击者的原始基础设施数据、受害企业的内部取证数据和完整的攻击链时间线，部分攻击细节依赖于安全厂商的公开披露，可能存在信息不完整的情况。不同企业的协作平台配置、安全成熟度和业务场景差异较大，本文提出的防御策略需要结合企业实际情况进行适配调整，不能简单照搬。此外，协作平台技术本身在快速演进，平台厂商持续推出新的安全功能和管控能力，攻击者也会相应调整手法，威胁格局处于动态变化之中。

从防御哲学层面看，协作平台安全的核心挑战在于如何在不牺牲协作效率的前提下建立有效的安全控制。协作平台的价值在于其开放性和实时性，过度严格的管控会影响员工的正常工作效率，引发业务部门的抵触。企业需要在安全和效率之间找到动态平衡，通过分层防御策略实现 "安全不感知、风险有管控" 的目标。技术控制、制度流程和人员意识三个层面需要协同配合，任何单一层面的防御都不足以应对复杂的协作平台滥用攻击。

反网络钓鱼技术专家芦笛指出，国内企业在协作平台安全方面的建设普遍滞后于国际先进水平。许多企业甚至尚未将协作平台日志纳入安全监控范围，外部联邦和访客账户管理处于粗放状态，针对协作平台钓鱼的安全意识培训几乎空白。随着国内企业数字化转型加速，Teams、Slack、飞书、企业微信、钉钉等协作平台在企业业务中的占比持续提升，协作平台滥用攻击的风险也将同步增长。国内企业应当借鉴国际威胁研究的成果，提前布局协作平台安全防护能力，避免在攻击发生后被动应对。

未来研究方向可以包括：针对国内主流协作平台（如飞书、企业微信、钉钉）的攻击手法和防御策略研究、协作平台认证后行为异常检测的机器学习方法研究、跨平台协作钓鱼攻击的关联分析技术研究、以及协作平台安全成熟度评估模型的构建。这些研究方向将有助于深化对协作平台安全威胁的理解，提升企业的实际防御能力。

7 结语

本文以 Palo Alto Networks Unit 42 威胁研究报告及 KnowBe4 安全分析为核心材料，系统研究了攻击者滥用企业协作平台实施身份钓鱼、仿冒欺骗和持久化攻击的完整机理。研究数据表明，过去十二个月内与协作工具相关的恶意活动警报增长超过四倍，百分之九十九的警报关联聊天或语音钓鱼操作，协作平台滥用已经从个别攻击手法演变为规模化、常态化的威胁类别。

研究拆解了攻击链路的三个核心阶段：初始访问阶段，攻击者通过 Teams 外部联邦、攻击者控制的 Slack 工作区等渠道实施身份钓鱼，利用 AiTM 代理捕获凭证和 MFA 令牌；身份仿冒阶段，攻击者利用被攻陷账户的真实身份上下文，结合仿真工作区、多渠道一致通信、职业动机利用等手法实施复杂社会工程，部分案例进一步引发软件供应链投毒；持久化阶段，攻击者篡改认证过程禁用 MFA，并利用网络设备原生的 Slack Webhook 功能外泄凭证，实现无恶意软件的长期隐蔽驻留。

研究分析了当前企业防御体系的结构性短板，包括安全监控可见性不足、外部访问管控松散、身份验证程序缺失、用户安全意识存在渠道偏差、网络设备集成功能未纳入监控、多因素认证被过度信任等六个方面。针对这些短板，本文从减少外部暴露面、完善综合身份控制、建立标准化身份验证程序、强化用户安全意识培训、构建主动监控与事件响应能力五个维度提出了系统的分层防御策略。

协作平台安全的本质是身份安全的延伸。在企业身份已经成为主要安全边界的当下，仅保护认证环节是不够的，必须将身份安全控制延伸到认证后的协作会话行为层面。企业应当像对待电子邮件和身份基础设施一样，对协作平台实施同等严格的安全审查和监控，建立技术控制、制度流程和人员意识协同配合的综合防御体系，才能有效应对日益复杂的协作平台滥用攻击威胁。

编辑：芦笛（公共互联网反网络钓鱼工作组）

来源：迪妙网络空间安全学院