利用协作平台的钓鱼攻击：以Microsoft Teams与Slack为例的技术分析与防御机制研究

原创于 2025-12-02 09:30:34 发布 · 489 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#microsoft #网络 #服务器 #安全 #人工智能

公共互联网反网络钓鱼专栏收录该内容

460 篇文章

订阅专栏

摘要

随着远程办公和混合工作模式的普及，Microsoft Teams 与 Slack 等企业级协作平台已成为组织内部通信的核心基础设施。然而，其高信任度、低监控强度及丰富的集成能力也为高级网络钓鱼攻击提供了新的攻击面。近期多起安全事件表明，攻击者正系统性地利用这些平台发起高度伪装的钓鱼活动，通过伪造内部消息、共享文档或会议邀请诱导用户点击恶意链接或执行恶意脚本。本文基于2025年披露的“Scattered Spider”组织攻击案例，深入剖析其在Teams与Slack环境中的攻击链构建、社会工程策略、横向移动技术及绕过多因素认证（MFA）的手法。研究发现，攻击者通过滥用平台API、伪造发件人身份、结合实时交互式钓鱼页面，成功规避传统邮件网关与终端防护机制。针对此类威胁，本文提出一套融合行为分析、权限最小化、安全基线配置与自动化响应的纵深防御框架，并提供可落地的YARA规则、PowerShell检测脚本及OAuth应用审查策略。全文严格依据公开技术指标与平台日志数据展开论证，旨在为组织构建面向现代协作平台的安全防护体系提供实证参考。

关键词：协作平台；Microsoft Teams；Slack；钓鱼攻击；Scattered Spider；MFA绕过；OAuth滥用；行为分析

1 引言

企业协作平台如 Microsoft Teams 和 Slack 已从辅助通信工具演变为关键业务操作系统。根据Gartner 2024年报告，全球超过85%的大型企业将Teams或Slack作为默认内部沟通渠道。这类平台集成了文件共享、应用插件、视频会议、机器人自动化等功能，极大提升了工作效率，但也显著扩展了攻击面。

传统网络安全体系主要围绕电子邮件构建，而协作平台因其“内部属性”常被排除在深度检测之外。用户对来自“同事”的消息天然信任，安全团队亦缺乏对平台内消息流的有效监控手段。这一认知盲区正被高级威胁组织系统性利用。2025年7月，美国联邦调查局（FBI）与网络安全和基础设施安全局（CISA）联合发布警报，指出黑客组织“Scattered Spider”正大规模利用Teams与Slack发起钓鱼攻击，目标直指金融、医疗及科技企业的核心凭证。

本文聚焦于该类攻击的技术实现细节，从攻击入口、载荷投递、凭证窃取到横向移动，完整还原攻击链。在此基础上，结合平台原生安全能力与第三方工具，提出可操作的防御措施。研究不依赖推测性归因，而是基于实际捕获的恶意链接、OAuth权限请求日志及终端进程行为，确保论据闭环、技术准确。

2 攻击背景与威胁主体特征

“Scattered Spider”是一个以经济利益为导向的黑客组织，活跃于2022年至今，曾多次针对呼叫中心、保险公司及云服务客户实施社会工程攻击。其典型特征包括：

高度依赖社会工程：攻击者常冒充IT支持人员，通过电话或聊天诱导用户执行操作；

实时交互能力：攻击过程中保持与受害者的实时对话，动态调整话术；

MFA绕过技巧娴熟：熟练使用“推送轰炸”（Push Bombing）、条件访问策略滥用等手段；

无文件或低文件攻击偏好：避免部署持久化恶意软件，降低被检测概率。

在本次针对协作平台的攻击中，该组织展现出对Teams与Slack API、OAuth授权流程及企业身份管理系统的深入理解，表明其已具备专业化红队能力。

3 攻击技术路径分析

3.1 初始访问：伪造内部消息

攻击通常始于一个看似来自内部同事的Teams或Slack消息。例如：

“Hi, I shared the Q3 budget file with you on Teams. Please review and approve by EOD.”

[点击查看文档]

该消息附带一个超链接，指向攻击者控制的钓鱼页面。尽管链接域名非企业官方域（如 teams-docs[.]xyz），但由于消息显示为“来自John（财务部）”，用户往往忽略URL异常。

技术上，攻击者可通过以下方式伪造发件人身份：

利用被盗账户直接发送：若前期已通过其他途径获取某员工凭证，则直接以其身份发送消息；

创建同名外部联系人：在Teams中添加外部用户并设置显示名为“IT Support”；

滥用Slack Incoming Webhooks：若企业允许任意Webhook集成，攻击者可配置自定义机器人发送消息。

3.2 钓鱼页面与实时凭证窃取

点击链接后，用户被重定向至高度仿真的Microsoft 365登录页。页面不仅复刻品牌UI，还动态显示用户所在企业的租户名称（通过SAML请求中的whr参数获取）。关键代码如下：

const urlParams = new URLSearchParams(window.location.search);

const tenant = urlParams.get('tenant') || 'yourcompany';

document.getElementById('tenant-name').innerText = tenant;

</script>

用户输入账号密码后，页面进一步要求输入MFA验证码。此时，攻击者采用“实时中继”策略：前端JavaScript立即将凭证与OTP发送至C2服务器，后者在数秒内向真实Azure AD发起登录请求。若成功，攻击者获得有效会话Cookie，可长期访问邮箱、OneDrive及Teams。

3.3 OAuth应用滥用与权限提升

更隐蔽的攻击方式是诱导用户授权恶意OAuth应用。例如，消息中附带一个“新审批系统测试版”链接，点击后跳转至OAuth同意页面：

“Approve access for ‘DocReview Pro’ to:

Read your email

Access files in OneDrive

Send messages as you”

由于OAuth同意页面由Microsoft官方域名（login.microsoftonline.com）托管，用户误以为安全。一旦授权，攻击者即可通过合法API调用访问资源，无需凭证。

此类应用通常申请过度权限，如 Mail.Read, Files.Read.All, User.ReadWrite.All。安全日志显示，部分恶意应用注册名称包含“Teams”, “Slack”, “Approval”等关键词，刻意模仿企业内部工具。

3.4 横向移动与持久化

获得初始访问后，攻击者利用以下手段扩大战果：

通过Teams搜索功能定位高权限用户：查找“admin”, “finance”, “HR”等关键词；

发送伪造的IT支持消息：“We detected suspicious activity on your account. Click here to verify.”；

部署远程访问工具（RAT）：通过OneDrive共享恶意LNK文件或ISO镜像，诱导用户执行。

值得注意的是，由于Teams与Windows深度集成，恶意链接可触发本地协议处理（如 ms-teams:），进一步模糊攻击边界。

4 平台安全机制的局限性

尽管Microsoft与Slack均提供安全功能，但在实际部署中存在明显短板：

4.1 链接扫描延迟

Teams内置的Safe Links功能虽可重写URL并进行实时扫描，但仅对首次点击生效。攻击者常采用“延迟激活”策略：初始页面为无害内容，数小时后替换为钓鱼表单。此时Safe Links缓存仍标记为安全。

4.2 第三方应用审查缺失

企业管理员往往未启用“仅允许批准应用”的策略。默认情况下，任何用户均可授权外部OAuth应用，且无自动权限审计机制。CISA数据显示，超过60%的受攻击企业存在未审查的高权限第三方应用。

4.3 内部消息无内容检测

与电子邮件不同，Teams与Slack的消息内容通常不经过DLP（数据防泄漏）或AV引擎扫描。即使消息包含已知恶意URL，也难以被拦截。

5 防御体系构建

5.1 技术检测层

5.1.1 YARA规则识别恶意OAuth应用

基于已知恶意应用的清单（如 DocReviewPro, TeamsVerifyTool），可编写YARA规则监控Azure AD应用注册日志：

rule Suspicious_OAuth_App_Names {

strings:

$name1 = "DocReview" nocase

$name2 = "TeamsVerify" nocase

$name3 = "SlackApprove" nocase

$perm1 = "Mail.Read"

$perm2 = "User.ReadWrite.All"

condition:

(any of ($name*)) and (any of ($perm*))

}

该规则可集成至SIEM系统，对新注册应用实时告警。

5.1.2 PowerShell脚本检测异常登录

以下脚本可识别来自非企业IP但声称来自Teams客户端的登录事件：

# 检测可疑Teams相关登录

$events = Get-AzureADAuditSignInLogs -Filter "appDisplayName eq 'Microsoft Teams'"

foreach ($event in $events) {

if (-not $event.IpAddress.StartsWith("10.") -and

-not $event.IpAddress.StartsWith("192.168.") -and

$event.Status.ErrorCode -eq 0) {

Write-Host "Suspicious Teams login from $($event.IpAddress) for user $($event.UserPrincipalName)"

# 可集成至自动化响应系统

}

5.1.3 DNS层阻断钓鱼域名

维护动态更新的恶意域名列表，并在企业DNS服务器（如Windows DNS或Pi-hole）中阻断：

# blocklist.txt

virtualeoffice.cloud

teams-docs.xyz

slack-verify.online

配置示例（dnsmasq）：

address=/virtualeoffice.cloud/0.0.0.0

5.2 配置加固层

强制启用条件访问策略：要求所有登录必须来自合规设备，且地理位置在允许范围内；

限制第三方应用权限：在Azure AD中设置“用户无法注册应用”，仅允许IT部门审批；

禁用高风险协议：关闭Legacy Authentication（如IMAP、SMTP），防止凭证重放；

启用MFA疲劳保护：在Entra ID中开启“阻止重复MFA请求”功能，防范推送轰炸。

5.3 人员与流程层

开展针对性钓鱼演练：模拟Teams/Slack钓鱼场景，测试员工识别能力；

建立“二次确认”文化：对涉及敏感操作的消息（如文件共享、权限变更），要求通过电话或面对面确认；

定期审查应用权限：每季度导出OAuth应用清单，移除未使用或高权限应用。

6 讨论

协作平台钓鱼攻击的成功，本质上源于“信任边界模糊化”。传统安全模型将“内部网络”视为可信区域，而现代SaaS架构下，攻击者可直接从互联网接触高价值用户，绕过外围防火墙。

此外，平台厂商的安全设计存在“可用性优先”倾向。例如，OAuth同意页面虽由官方托管，但未对应用权限进行风险评级提示；Teams消息未提供“来源验证”标识，使伪造身份成本极低。这要求组织不能完全依赖厂商默认配置，而需主动实施安全增强。

值得警惕的是，攻击者正将AI技术融入社会工程。已有证据表明，部分钓鱼消息由LLM生成，语言风格高度贴近目标企业内部沟通习惯，进一步降低识别难度。未来防御需引入自然语言异常检测模型，识别语义层面的欺骗特征。

7 结语

Microsoft Teams 与 Slack 的普及重塑了企业通信范式，但也重构了网络攻击的入口点。Scattered Spider等组织利用平台的信任属性、API开放性与用户心理弱点，构建了高效且隐蔽的钓鱼攻击链。本文通过技术还原其攻击流程，证实了从初始诱骗到横向移动的可行性，并据此提出分层防御策略。

防御的核心在于打破“内部即安全”的假设，将协作平台纳入统一威胁检测体系。技术上，需结合日志分析、权限控制与自动化响应；管理上，需强化人员意识与流程规范。唯有如此，方能在保障协作效率的同时，守住数字工作空间的安全底线。

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