基于SharePoint信任链的AiTM钓鱼与BEC攻击机理及防御

摘要

随着企业数字化转型的深入，微软Office 365生态已成为全球协作的核心平台。然而，云服务的信任机制正被攻击者利用，演变为新型高级持续性威胁的载体。本文基于微软威胁情报中心披露的最新案例，深入剖析了一种利用Microsoft SharePoint合法功能进行多阶段中间人（Adversary-in-the-Middle, AiTM）钓鱼与商业电子邮件入侵（BEC）的复合攻击活动。该攻击模式通过入侵合作伙伴账户上传恶意文件，触发SharePoint原生的自动通知机制，向目标发送源自no-reply@sharepointonline.com的“文件共享”邮件。由于发件人信誉极高且链接指向合法的微软域名，此类攻击能有效绕过传统基于域名信誉和发件人策略框架（SPF/DKIM/DMARC）的安全过滤。受害者点击链接后，被重定向至精心伪造的登录页面，攻击者利用反向代理技术实时拦截身份验证请求，窃取会话Cookie以绕过多因素认证（MFA）。成功入侵后，攻击者进一步实施BEC诈骗，造成严重的财务损失与数据泄露。本文详细阐述了该攻击链的技术实现原理，分析了现有防御体系的盲区，并提出了一套包含零信任架构、条件访问策略（Conditional Access）、FIDO2密钥部署及异常行为监测的综合防御方案。文章最后通过Python代码示例，展示了针对SharePoint异常共享行为的检测逻辑，旨在为企业构建针对云服务滥用型攻击的主动防御体系提供理论依据与实践指导。

1. 引言

在当前的网络安全威胁景观中，攻击者的战术、技术和过程（TTPs）正经历着从“利用技术漏洞”向“滥用合法功能”的深刻转变。传统的网络攻击往往依赖于软件漏洞（如缓冲区溢出、SQL注入）或恶意软件的投递，而现代高级威胁则更多地利用云服务平台内置的信任机制和社会工程学原理。微软Office 365套件，特别是SharePoint Online，作为企业文档协作的关键基础设施，其广泛的互信关系和自动化通知功能，不幸成为了攻击者眼中的“特洛伊木马”。

近期，微软威胁情报中心披露了一起极具代表性的多阶段攻击活动。该活动并未利用任何未公开的0-day漏洞，而是巧妙地利用了SharePoint的文件共享与通知机制。攻击者首先通过社会工程学或其他手段攻陷一个合法的第三方账户（通常是受害企业的合作伙伴或供应商），随后在该账户权限下将恶意链接或诱导性文档上传至SharePoint。一旦上传完成，SharePoint系统会自动向预设的目标联系人发送通知邮件。这些邮件具有极高的欺骗性：它们直接来自微软官方的no-reply@sharepointonline.com地址，内容包含指向真实sharepoint.com域名的链接。这种“寄生”于合法云服务的攻击方式，使得传统的基于黑名单的邮件网关、基于域名信誉的过滤系统以及依赖SPF/DKIM/DMARC验证的身份鉴别机制完全失效。

当受害者点击邮件中的链接时，并非直接访问文件，而是被引导至一个由攻击者控制的中间人代理服务器。该服务器实时转发请求至真实的微软登录页面，并在用户输入凭据及完成多因素认证（MFA）的过程中，同步窃取生成的会话Cookie（Session Cookie）。由于现代Web应用广泛采用基于Cookie的身份维持机制，攻击者利用窃取的Cookie即可在不触发MFA的情况下直接接管用户会话，从而实现了对账户的完全控制。这一过程被称为中间人（AiTM）攻击，它有效地规避了MFA带来的安全增益。

在获取账户控制权后，攻击者随即转入商业电子邮件入侵（BEC）阶段。他们利用受害者的合法身份，向内部财务人员发送伪造的发票，或向外部客户发送更改收款账户的通知，甚至利用受害者的联系人列表进行横向扩散，发起新一轮的钓鱼攻击。这种攻击链条环环相扣，隐蔽性极强，从初始入侵到造成实质性财务损失，往往只需数小时，给企业带来了巨大的安全风险。

本文旨在对这一新型攻击模式进行全方位的技术解构。首先，文章将详细复盘攻击链路，分析攻击者如何利用SharePoint的信任链突破外围防御；其次，深入探讨AiTM攻击的技术原理及其对传统MFA机制的 bypass 逻辑；再次，评估当前主流安全产品在应对此类“合法流量伪装”攻击时的局限性；最后，提出一套基于零信任原则的深度防御策略，包括细粒度的条件访问控制、FIDO2无密码认证的引入、以及基于用户实体行为分析（UEBA）的异常检测机制。通过理论分析与代码实证相结合，本文期望为应对云服务滥用型威胁提供系统的解决方案。

2. 攻击链路深度解析与信任链滥用机制

2.1 初始入侵点：供应链与合作伙伴账户的沦陷

该攻击活动的起点并非直接针对最终受害者，而是瞄准了其生态系统中的薄弱环节——合作伙伴或供应商的Office 365账户。攻击者可能通过常规的钓鱼邮件、密码喷洒（Password Spraying）或利用其他已泄露的凭证，成功攻陷这些外部账户。由于现代企业间的业务协作高度依赖云共享，这些被攻陷的账户通常拥有向外部域发送文件共享邀请的权限。

一旦攻击者控制了合作伙伴账户，他们便获得了微软云环境的“合法居民”身份。在此身份下，任何操作（如上传文件、创建共享链接）都被视为可信行为。这种初始立足点的建立，利用了企业间天然的信任关系，使得后续的攻击流量在源头上就具备了合法性特征。

2.2 载荷投递：SharePoint自动通知机制的武器化

攻击的核心创新在于对SharePoint自动通知功能的武器化利用。在传统钓鱼攻击中，攻击者需要自行搭建邮件服务器、伪造发件人地址，并设法绕过垃圾邮件过滤器。而在本案例中，攻击者只需在SharePoint中执行“共享”操作，微软的基础设施便会自动代劳发送邮件。

这封自动生成的邮件具有几个关键特征，使其极难被拦截：

权威发件人：邮件头中的From字段显示为no-reply@sharepointonline.com。这是微软官方的系统账号，拥有完美的SPF、DKIM和DMARC记录，任何基于发件人信誉的过滤系统都会将其标记为可信。

合法域名链接：邮件正文中的链接指向*.sharepoint.com或*.microsoft.com子域名。传统的安全网关通常会将这些域名加入白名单，因为它们是全球数百万企业正常业务所必需的。

情境化内容：邮件内容通常包含具体的文件名、共享者姓名以及“您已被授予访问权限”等标准话术，符合正常的业务逻辑，难以引起用户的警觉。

这种利用云服务原生功能进行载荷投递的方式，彻底改变了攻击者与防御者在邮件安全领域的博弈格局。防御者无法简单地封锁微软的域名或IP地址，否则将导致正常的业务中断。

2.3 中间人攻击（AiTM）：会话劫持与MFA绕过

当受害者点击邮件中的合法SharePoint链接后，攻击的真正技术核心开始显现。链接实际上经过了攻击者的重定向处理，或者攻击者利用URL参数注入，将用户引导至一个部署了AiTM工具包（如Evilginx、Modlishka等）的反向代理服务器。

该代理服务器位于受害者浏览器和真实的微软登录页面（login.microsoftonline.com）之间。其工作流程如下：

请求转发：代理服务器接收受害者的HTTPS请求，并将其实时转发给微软的真实登录服务器。

内容镜像：微软返回的登录页面HTML、CSS和JavaScript被代理服务器截获，并原样返回给受害者。此时，受害者看到的URL栏可能仍显示为合法的SharePoint路径（通过URL重写技术），或者是一个极其逼真的伪造域名。

凭据捕获：当受害者在页面上输入用户名和密码并提交时，代理服务器首先记录下这些凭据，然后立即将其提交给微软服务器。

MFA挑战传递：微软服务器验证密码通过后，会触发MFA挑战（如推送通知、短信验证码）。代理服务器将此挑战页面透传给受害者。

会话Cookie窃取：受害者完成MFA验证后，微软服务器生成认证成功的会话Cookie（如ESTSAUTH、ESTSAUTHPERSISTENT等）。代理服务器在将这些Cookie发送给受害者浏览器的同时，将其复制并存储在自己的数据库中。

至此，攻击者完成了最关键的一步：窃取了有效的会话Cookie。由于现代Web应用（包括Office 365）在会话有效期内主要依赖Cookie来维持登录状态，攻击者只需将这些Cookie注入到自己的浏览器或自动化工具中，即可直接访问受害者的邮箱、OneDrive和Teams，而无需再次输入密码或通过MFA验证。这种攻击方式从根本上绕过了MFA的安全防护，因为MFA仅在初始登录瞬间生效，而无法保护后续的会话状态。

2.4 商业电子邮件入侵（BEC）与横向扩散

在成功接管账户后，攻击者进入获利阶段。他们通常会潜伏一段时间，观察邮件往来规律，了解组织架构和业务术语。随后，发起BEC攻击：

发票欺诈：冒充高管向财务部门发送紧急付款指令，附上伪造的发票，要求将款项汇入攻击者控制的账户。

数据窃取：搜索敏感合同、客户名单或知识产权文档，并通过加密压缩包等形式外传。

横向移动：利用受害者的联系人列表，发送带有恶意附件或链接的邮件。由于邮件来自受信任的内部账户，收件人的警惕性极低，从而导致攻击在企业内部迅速扩散。

这种多阶段的攻击模式，将技术漏洞利用与社会工程学完美结合，形成了一个难以阻断的闭环。

3. 现有防御体系的局限性与技术盲区

面对上述高度隐蔽的攻击链，传统的网络安全防御体系暴露出了显著的局限性。

3.1 基于签名的检测失效

传统的反病毒软件和邮件网关严重依赖已知恶意特征（Signature-based Detection）。然而，在此次攻击中，没有恶意附件，没有恶意IP地址，没有恶意域名。所有的流量都经过加密（HTTPS），且指向合法的微软服务器。基于签名的检测机制对此类“无文件”、“纯合法流量”的攻击束手无策。

3.2 域名信誉与白名单机制的双刃剑

为了保障业务连续性，企业通常将microsoft.com、sharepoint.com等域名加入白名单。攻击者正是利用了这一信任假设。如果安全团队试图封锁所有来自这些域名的可疑链接，将会导致大量的误报，严重影响正常办公。如何在保持白名单便利性的同时，识别出被滥用的合法链接，是当前防御的一大难题。

3.3 MFA的局限性认知

长期以来，多因素认证（MFA）被视为防止账户被盗的“银弹”。然而，AiTM攻击的出现打破了这一神话。大多数MFA协议（如SMS OTP、Push Notification）仅在第一跳认证时生效，一旦认证成功，生成的Session Token即成为新的“钥匙”。攻击者窃取的是这把“钥匙”本身，而非开锁的过程。因此，传统的MFA无法防御会话劫持。除非采用能够绑定设备上下文或抵抗钓鱼的认证方式（如FIDO2），否则MFA在面对AiTM时显得脆弱不堪。

3.4 日志监控的滞后性

虽然Office 365提供了丰富的审计日志（Unified Audit Log），但在海量正常操作背景下，识别出异常的登录行为极具挑战性。攻击者利用窃取的Cookie登录时，其IP地址、User-Agent可能与受害者日常习惯略有不同，但如果缺乏智能化的行为分析模型，这些细微的异常很容易被忽略。此外，从Cookie窃取到实际利用之间可能存在时间差，导致事后追溯困难。

4. 基于零信任的综合防御架构设计

针对SharePoint滥用及AiTM攻击的特性，必须构建一套基于零信任（Zero Trust）原则的深度防御体系。零信任的核心理念是“永不信任，始终验证”，不再默认内网或合法域名下的流量是安全的。

4.1 强化身份认证：全面部署FIDO2安全密钥

抵御AiTM攻击最有效的手段是采用抗钓鱼的身份认证协议。FIDO2（Fast Identity Online 2.0）标准，特别是基于WebAuthn的实现，通过公钥密码学和非对称加密机制，从根本上解决了会话劫持问题。

源站绑定（Origin Binding）：FIDO2认证过程中，私钥签名操作会将当前的域名（Origin）纳入计算。如果攻击者将用户重定向到伪造的代理页面（即使URL看起来很像），浏览器与认证器的通信会检测到域名不匹配，从而拒绝签名。

设备绑定：FIDO2密钥通常与特定设备绑定，即使攻击者窃取了凭据，也无法在没有物理密钥的情况下在其他设备上模拟登录。

企业应强制要求所有特权账户及高风险用户启用FIDO2安全密钥（如YubiKey）或平台级生物识别（Windows Hello for Business），逐步淘汰易受钓鱼的OTP和Push认证方式。

4.2 实施细粒度的条件访问策略（Conditional Access）

利用Azure AD（现Entra ID）的条件访问功能，构建动态的访问控制策略：

设备合规性检查：配置策略，仅允许加入域（Hybrid Azure AD Join）或符合公司安全基线（Intune Compliance）的设备访问SharePoint敏感资源。攻击者通常在非受管设备上操作，此策略可直接阻断其访问。

地理位置与网络限制：对于异常地理位置的登录请求（如用户常驻地之外的国家），强制要求进行额外验证或直接阻止。

应用程序控制：限制仅允许受保护的浏览器或特定的客户端应用访问Office 365服务，防止攻击者使用自动化脚本或不受控的浏览器插件注入Cookie。

持续访问评估（CAE）：启用CAE功能，使服务端能够实时响应风险事件。例如，一旦检测到用户密码更改或高风险登录，立即撤销现有的会话Token，迫使攻击者手中的Cookie失效。

4.3 SharePoint共享策略的收紧与治理

针对SharePoint的滥用风险，管理员需重新审视外部共享设置：

限制外部共享范围：默认关闭全局外部共享，仅针对特定业务需求开启，并限制为“仅限特定域”（Allow listing specific domains），禁止向任意个人邮箱共享。

访客链接有效期与权限最小化：设置共享链接的自动过期时间（如7天），并默认赋予“只读”权限，禁止外部用户编辑或下载敏感文档，除非经过审批。

匿名链接禁用：彻底禁用“任何人（Anonymous）”可访问的链接类型，确保所有访问者都必须经过身份验证。

敏感标签保护：利用Microsoft Purview信息保护（MIP）功能，对包含敏感信息的文档自动应用加密标签。即使文档被非法下载，未授权用户也无法打开查看内容。

4.4 智能化威胁检测与响应

建立基于UEBA（用户实体行为分析）的检测机制，利用Microsoft Defender for Office 365和Microsoft Sentinel：

异常登录检测：监控“不可能旅行”（Impossible Travel）、陌生设备登录、非常规时间访问等异常行为。

令牌异常分析：检测User-Agent字符串的突变、IP地址与地理位置的不匹配、以及短时间内大量文件访问行为。

自动化响应（SOAR）：一旦确认高风险会话，自动触发Playbook，强制重置用户密码、撤销所有刷新令牌（Refresh Tokens）、隔离受影响设备，并通知安全团队介入。

5. 异常共享行为检测算法与代码实现

为了在实际环境中及时发现潜在的SharePoint滥用行为，安全团队需要部署定制化的监控脚本。以下是一个基于Python的示例，演示如何利用Microsoft Graph API查询SharePoint共享活动，并基于启发式规则识别异常模式。

5.1 检测逻辑设计

该检测模块主要关注以下异常指标：

高频共享：单个用户在短时间内发起大量外部共享请求。

敏感文件外发：标记为“机密”或“内部专用”的文件被共享给外部域。

异常目标域：文件被共享给与该企业无历史业务往来的新域名。

匿名链接创建：检测到创建了无需登录即可访问的链接。

5.2 代码实现示例

import requests

import datetime

from typing import List, Dict, Any

class SharePointAnomalyDetector:

def __init__(self, tenant_id: str, client_id: str, client_secret: str):

self.tenant_id = tenant_id

self.client_id = client_id

self.client_secret = client_secret

self.token_url = f"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"

self.graph_url = "https://graph.microsoft.com/v1.0"

self.access_token = None

self.known_partner_domains = {"partner-a.com", "supplier-b.net", "client-c.org"}

def get_access_token(self) -> str:

"""获取Microsoft Graph API访问令牌"""

headers = {"Content-Type": "application/x-www-form-urlencoded"}

data = {

"grant_type": "client_credentials",

"client_id": self.client_id,

"client_secret": self.client_secret,

"scope": "https://graph.microsoft.com/.default"

}

response = requests.post(self.token_url, headers=headers, data=data)

if response.status_code == 200:

self.access_token = response.json().get("access_token")

return self.access_token

else:

raise Exception(f"Failed to get token: {response.text}")

def fetch_sharing_activities(self, days: int = 1) -> List[Dict[str, Any]]:

"""获取过去指定天数内的共享活动日志"""

if not self.access_token:

self.get_access_token()

headers = {"Authorization": f"Bearer {self.access_token}"}

# 计算时间范围

end_time = datetime.datetime.utcnow()

start_time = end_time - datetime.timedelta(days=days)

# 使用Audit Logs API查询SharePoint共享操作

# 注意：实际生产中可能需要分页处理

query_params = {

"$filter": f"activityDateTime ge {start_time.isoformat()}Z and activityDateTime le {end_time.isoformat()}Z and (operationName eq 'FileShared' or operationName eq 'LinkCreated')",

"$top": 100

}

url = f"{self.graph_url}/auditLogs/directoryAudits" # 简化示例，实际应使用unifiedAuditLogs

# 注：Graph API中统一审计日志的端点可能需要特定权限和不同的查询方式

# 此处仅为逻辑演示，实际调用需参考最新MS Graph文档

# 模拟返回数据用于演示逻辑

mock_logs = [

{

"user": "alice@company.com",

"operation": "FileShared",

"target": "confidential_budget.xlsx",

"recipient": "external_user@unknown-domain.xyz",

"link_type": "edit",

"timestamp": datetime.datetime.utcnow()

},

{

"user": "bob@company.com",

"operation": "LinkCreated",

"target": "project_plan.docx",

"recipient": "anonymous",

"link_type": "anonymous_view",

"timestamp": datetime.datetime.utcnow()

}

]

return mock_logs

def analyze_risk(self, logs: List[Dict[str, Any]]) -> List[Dict[str, Any]]:

"""分析日志并识别高风险活动"""

alerts = []

for log in logs:

risk_score = 0

reasons = []

# 规则1：检测匿名链接

if log.get("link_type") == "anonymous_view" or log.get("link_type") == "anonymous_edit":

risk_score += 40

reasons.append("Anonymous link created for sensitive file")

# 规则2：检测未知外部域

recipient = log.get("recipient", "")

if "@" in recipient:

domain = recipient.split("@")[-1]

if domain not in self.known_partner_domains:

risk_score += 30

reasons.append(f"Shared with unknown domain: {domain}")

# 规则3：敏感文件名关键词匹配

sensitive_keywords = ["budget", "confidential", "salary", "password", "key"]

target_file = log.get("target", "").lower()

if any(keyword in target_file for keyword in sensitive_keywords):

risk_score += 30

reasons.append(f"Sensitive file detected: {log.get('target')}")

# 判定阈值

if risk_score >= 50:

alerts.append({

"severity": "High" if risk_score >= 70 else "Medium",

"score": risk_score,

"user": log.get("user"),

"details": "; ".join(reasons),

"raw_log": log

})

return alerts

def run_detection(self):

"""执行完整检测流程"""

try:

print("Fetching SharePoint sharing activities...")

logs = self.fetch_sharing_activities(days=1)

print(f"Analyzing {len(logs)} activities...")

alerts = self.analyze_risk(logs)

if alerts:

print(f"\n!!! DETECTED {len(alerts)} HIGH RISK ACTIVITIES !!!\n")

for alert in alerts:

print(f"[{alert['severity']}] Score: {alert['score']}")

print(f"User: {alert['user']}")

print(f"Reasons: {alert['details']}")

print("-" * 30)

else:

print("No suspicious activities detected.")

except Exception as e:

print(f"Error during detection: {e}")

if __name__ == "__main__":

# 配置实际环境的凭证

detector = SharePointAnomalyDetector(

tenant_id="YOUR_TENANT_ID",

client_id="YOUR_CLIENT_ID",

client_secret="YOUR_CLIENT_SECRET"

)

detector.run_detection()

5.3 代码逻辑与应用价值

上述代码展示了一个轻量级的检测引擎原型。fetch_sharing_activities函数负责从Microsoft Graph API拉取审计日志（实际部署中需处理分页和API限流）。analyze_risk函数实现了核心的启发式规则引擎：

匿名链接检测：直接标记创建匿名链接的行为，这是极高风险的信号。

白名单校验：对比接收者域名与已知合作伙伴白名单，识别未知的潜在恶意接收方。

内容敏感度分析：通过文件名关键词匹配，识别涉及财务、人事等敏感数据的共享行为。

当综合风险评分超过阈值时，系统生成告警。在实际生产环境中，该脚本可集成到SIEM系统或作为Azure Function定时运行，一旦发现高危行为，立即触发自动化响应（如禁用共享链接、冻结用户账户）。这种基于行为的检测能够有效弥补静态防御的不足，实现对AiTM前置动作（即恶意共享）的早期发现。

6. 结论

利用SharePoint进行的多阶段AiTM钓鱼与BEC攻击，代表了云时代网络威胁的新范式。攻击者不再单纯依赖技术漏洞，而是通过滥用云平台的信任机制、自动化功能和合法流量通道，构建了极具隐蔽性和破坏力的攻击链。从入侵合作伙伴账户，到利用官方通知邮件投递，再到通过反向代理窃取会话Cookie，每一步都精准地击中了传统防御体系的软肋。

面对这一挑战，企业必须摒弃“边界防御”的旧思维，全面转向零信任架构。技术上，强制部署FIDO2抗钓鱼认证是阻断AiTM攻击的根本之策；策略上，实施细粒度的条件访问控制和严格的SharePoint共享治理是减少攻击面的关键；运营上，建立基于UEBA的智能化监测与自动化响应机制是提升发现与处置能力的保障。

本文提出的综合防御体系，强调了身份、设备、应用与数据的全方位协同防护。通过代码示例展示的异常检测逻辑，证明了利用现有云原生能力构建定制化防御工具的可行性。未来，随着AI技术在攻防双方的进一步应用，攻击的自动化与智能化程度将更高，防御体系也需不断演进，引入更先进的行为分析与威胁狩猎技术。唯有保持高度的警惕，持续优化安全策略，企业才能在享受云服务便利的同时，有效抵御日益复杂的网络威胁，确保持续的业务韧性与数据安全。

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