基于浏览器扩展的Microsoft 365钓鱼攻击实时阻断机制研究

摘要

近年来，针对Microsoft 365（原Office 365）生态系统的网络钓鱼攻击呈现高发态势，传统依赖邮件网关与服务器端策略的防护手段已难以应对通过短信、社交媒体、语音通话等非邮件渠道传播的恶意链接。本文聚焦于CyberDrain公司于2025年发布的开源浏览器扩展工具“Check”，深入剖析其技术架构、检测逻辑与阻断机制，并结合实际部署场景评估其在中小托管服务提供商（MSP）环境中的有效性与局限性。研究表明，Check通过本地化运行的启发式规则匹配与域名指纹比对，在用户点击恶意链接后、输入凭证前实现精准拦截，有效弥补了现有纵深防御体系中的终端侧空白。文章进一步探讨了该工具在权限模型、隐私保护、可扩展性等方面的设计考量，并提出与Azure AD条件访问策略、多因素认证（MFA）及日志审计体系协同部署的最佳实践。最后，通过提供核心检测逻辑的代码示例与部署配置方案，为安全社区贡献可复现、可验证的技术参考。

关键词：网络钓鱼；Microsoft 365；浏览器扩展；纵深防御；开源安全；托管服务提供商

1 引言

Microsoft 365作为全球部署最广泛的云生产力平台，已成为高级持续性威胁（APT）与大规模自动化攻击的首要目标。攻击者利用其身份认证入口（如login.microsoftonline.com）构建高度仿真的钓鱼页面，诱导用户泄露账户凭证或授权恶意OAuth应用，进而窃取敏感数据、横向移动或部署勒索软件。据微软2024年度数字防御报告，超过70%的企业安全事件始于身份凭证的失窃，其中绝大多数源于社会工程学驱动的钓鱼攻击。

传统的反钓鱼措施主要集中在两个层面：一是邮件传输层的URL重写、附件沙箱与发件人信誉分析；二是身份认证层的条件访问（Conditional Access）策略与多因素认证（MFA）。然而，这些措施存在显著盲区。首先，当攻击载体脱离电子邮件（如通过WhatsApp、Telegram、电话引导用户访问短链接），邮件网关完全失效；其次，即使启用了MFA，若用户在钓鱼页面上同时输入主密码与一次性验证码，攻击者仍可实施“MFA疲劳攻击”或实时代理认证（Real-time Phishing Proxy），绕过第二因子保护。

在此背景下，终端侧的主动防御能力变得至关重要。浏览器作为用户与Web应用交互的最终界面，是阻止凭证提交的最后一道防线。2025年9月，专注于MSP生态的安全厂商CyberDrain发布了名为“Check”的免费开源浏览器扩展，旨在填补这一防御缺口。与仅提供视觉警告的同类工具不同，Check采取“硬阻断”策略，在检测到可疑登录页面时直接禁止表单提交，并向用户和管理员发出告警。

本文的核心贡献在于：（1）系统性解析Check工具的技术实现原理，包括其本地化检测引擎、域名指纹库更新机制与用户交互设计；（2）评估其在真实MSP运维环境中的部署成本、效能与潜在风险；（3）提出与现有Microsoft 365安全控制措施的集成框架；（4）通过可运行的代码示例，展示其核心检测逻辑，为后续研究与社区贡献提供基础。

2 相关工作与技术背景

2.1 Microsoft 365钓鱼攻击模式演进

当前针对Microsoft 365的钓鱼攻击主要分为两类：凭证钓鱼（Credential Phishing） 与 OAuth滥用（OAuth Abuse）。

凭证钓鱼：攻击者注册与微软官方域名高度相似的域名（如microsoft-login[.]com、office365-secure[.]net），并克隆Azure AD登录页面。用户在不知情的情况下输入账户密码，凭证被实时捕获。

OAuth滥用：攻击者诱导用户授权一个看似无害的第三方应用（如“PDF Viewer”、“Calendar Sync”），该应用请求过度的API权限（如Mail.ReadWrite, Calendars.ReadWrite, User.Read.All）。一旦授权，攻击者即可通过合法API令牌访问用户邮箱、日历等资源，规避传统邮件监控。

这两种攻击均可通过非邮件渠道发起，使得基于邮件内容的过滤器形同虚设。

2.2 现有防御体系的局限性

Microsoft自身提供了多项安全功能：

Exchange Online Protection (EOP) 与 Microsoft Defender for Office 365：提供邮件级URL过滤与恶意附件检测。

Azure AD Identity Protection：基于风险信号（如匿名IP、不可能的旅行）触发自适应访问控制。

Conditional Access Policies：强制MFA、设备合规性检查等。

然而，这些服务均为云端集中式策略，无法干预用户在本地浏览器中与任意Web页面的交互行为。一旦用户被诱导离开受保护的邮件环境，进入攻击者控制的页面，上述所有云端策略均无法生效。

2.3 终端侧浏览器防护的兴起

近年来，学术界与工业界开始关注浏览器扩展作为安全执行环境的潜力。例如，Google Safe Browsing API允许扩展查询已知恶意URL；部分企业级密码管理器也集成了钓鱼页面检测功能。但这些方案多为商业闭源产品，且检测逻辑不透明，难以被MSP定制或审计。Check的出现，正是对这一需求的直接回应——提供一个透明、可审计、可定制的开源解决方案。

3 Check工具架构与工作机制

3.1 整体架构

Check采用典型的浏览器扩展架构，由以下组件构成：

Content Script：注入到每个页面上下文，负责监听页面DOM结构、表单元素与URL变化。

Background Service Worker：常驻后台，管理域名指纹库、处理跨域通信、触发告警。

Options Page：供管理员配置白名单、查看拦截日志、设置告警通知方式。

Local Storage：用于缓存最新的钓鱼域名指纹列表，避免频繁网络请求。

整个工具遵循“零数据外传”原则，所有分析均在用户本地浏览器中完成，不收集任何用户行为或凭证信息。

3.2 核心检测逻辑

Check的检测机制基于双重验证：

URL与域名指纹匹配：维护一个动态更新的已知钓鱼域名列表（如phish-mso365[.]xyz, secure-azure-login[.]top）。该列表通过GitHub仓库定期同步，支持增量更新。

页面内容特征识别：即使域名未被列入黑名单，若页面包含以下特征，亦视为可疑：

存在<form>元素，其action属性指向非微软官方域名；

页面中包含login.microsoftonline.com、account.activedirectory.windowsazure.com等微软登录关键词，但当前域名并非*.microsoft.com或*.microsoftonline.com；

存在隐藏的<input type="password">字段，且页面无有效的SSL证书或证书颁发机构不可信。

一旦满足任一条件，Check立即执行阻断操作。

3.3 阻断与告警机制

阻断并非简单关闭页面，而是通过JavaScript劫持表单的submit事件，并覆盖页面内容为标准化的告警界面。示例如下：

// content-script.js

const SUSPICIOUS_KEYWORDS = [

'microsoftonline', 'azuread', 'office365', 'microsoft account'

];

function isPhishingPage() {

const url = new URL(window.location.href);

const hostname = url.hostname.toLowerCase();

// 规则1: 域名黑名单匹配（简化示例）

if (PHISHING_DOMAINS.has(hostname)) {

return true;

}

// 规则2: 关键词出现在非官方域名中

const hasKeyword = SUSPICIOUS_KEYWORDS.some(kw =>

document.body.innerText.toLowerCase().includes(kw)

);

const isOfficialDomain = hostname.endsWith('.microsoft.com') ||

hostname.endsWith('.microsoftonline.com') ||

hostname === 'login.live.com';

if (hasKeyword && !isOfficialDomain) {

return true;

}

// 规则3: 表单提交到非HTTPS或非官方端点

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

for (const form of forms) {

const action = form.getAttribute('action');

if (action) {

try {

const actionUrl = new URL(action, window.location.origin);

if (!actionUrl.protocol.startsWith('https') ||

(!actionUrl.hostname.endsWith('.microsoft.com') &&

!actionUrl.hostname.endsWith('.microsoftonline.com'))) {

return true;

}

} catch (e) {

// invalid URL, treat as suspicious

return true;

}

}

}

return false;

}

function blockPage() {

document.body.innerHTML = `

<div style="display:flex;justify-content:center;align-items:center;height:100vh;background:#f8f9fa;">

<div style="text-align:center;padding:2rem;background:white;border-radius:8px;box-shadow:0 2px 10px rgba(0,0,0,0.1);">

<h2 style="color:#d32f2f;">⚠️ 安全警告</h2>

<p>此网站已被识别为Microsoft 365钓鱼页面。</p>

<p>您的凭据不会被提交。</p>

<p><strong>请勿刷新或尝试绕过此页面。</strong></p>

<p>您的IT管理员已收到告警。</p>

</div>

</div>

`;

// 禁用所有表单提交与键盘输入

document.addEventListener('keydown', e => e.preventDefault(), true);

document.querySelectorAll('form').forEach(f => f.style.display = 'none');

}

// 主逻辑

if (isPhishingPage()) {

blockPage();

// 向后台发送告警

chrome.runtime.sendMessage({ type: 'PHISHING_DETECTED', url: window.location.href });

}

该脚本在页面加载完成后立即执行，确保在用户有机会输入凭据前完成检测与阻断。

3.4 管理员告警与日志

当阻断发生时，扩展通过chrome.runtime.sendMessage通知后台服务。后台服务可配置为：

在浏览器通知中心弹出告警；

将事件记录到本地存储，供管理员通过Options Page查看；

（可选）通过Webhook将事件推送到MSP的SIEM系统（需用户明确授权）。

所有日志仅包含时间戳、被拦截的URL与事件类型，不包含任何用户输入内容。

4 部署实践与效能评估

4.1 部署要求

Check的部署极为轻量：

支持Chrome、Edge、Firefox等主流浏览器；

无需安装额外代理或客户端软件；

MSP可通过组策略（GPO）或MDM工具（如Intune）强制推送扩展ID，实现静默部署。

唯一前提条件是用户浏览器允许安装来自Web Store的扩展。对于高度锁定的企业环境，MSP可自行打包.crx文件进行内部分发。

4.2 优势分析

即时阻断：在凭证提交前拦截，从根本上防止凭证泄露。

零配置用户体验：普通用户无需学习新操作，阻断界面清晰明确。

开源透明：代码公开于GitHub，MSP可自行审计、定制或贡献规则。

低资源开销：检测逻辑简单，内存与CPU占用极低。

白标支持：MSP可替换Logo与告警文案，融入自有品牌。

4.3 局限性与挑战

依赖域名指纹更新：新型钓鱼站点若未及时加入黑名单，可能漏报。需社区持续贡献。

无法防御高度定制化钓鱼页：若攻击者使用全新域名且页面不含关键词，仅靠内容特征可能不足。

无Graph API集成：当前版本不自动撤销会话或令牌，需管理员手动响应。

权限范围审慎：扩展需activeTab与storage权限，虽无敏感权限，但仍需用户信任。

5 与Microsoft 365安全体系的协同

Check并非替代现有安全措施，而是作为纵深防御的补充层。最佳实践建议如下：

强制启用MFA：即使发生钓鱼，MFA可增加攻击难度。

禁用旧式认证协议：如Basic Auth、IMAP/POP3，防止凭证被直接用于API调用。

配置条件访问策略：限制登录地理位置、设备合规性。

启用审计日志长期保留：通过Microsoft Purview保留90天以上日志，便于事后溯源。

部署Check作为终端侧哨兵：拦截非邮件渠道的钓鱼尝试。

三者结合，形成“预防—检测—响应”的闭环。

6 安全与隐私考量

Check在设计上严格遵循最小权限原则：

不请求webRequest或cookies权限，无法读取用户浏览历史或认证Cookie；

所有分析在本地完成，无远程服务器接收用户数据；

域名指纹库通过HTTPS从官方GitHub仓库拉取，支持SHA-256校验。

尽管如此，MSP在部署前仍应：

审计源代码，确认无后门；

限制扩展更新源，防止供应链攻击；

向用户明确告知扩展功能与数据处理方式，符合GDPR等合规要求。

7 未来工作方向

CyberDrain团队已规划以下增强功能：

OAuth授权页面监控：检测异常权限请求，阻止过度授权。

URL解包与沙箱集成：对短链接（如bit.ly）进行递归解析，并在隔离环境中渲染页面以提取真实域名。

与Microsoft Graph API联动：在检测到钓鱼后，自动调用/revokeSignInSessions终结用户所有活动会话。

机器学习辅助检测：基于页面布局、CSS样式等视觉特征训练轻量级模型，提升对新型钓鱼页的泛化能力。

这些方向将进一步提升工具的自动化与智能化水平。

8 结论

本文系统研究了CyberDrain推出的开源浏览器扩展Check在阻断Microsoft 365钓鱼攻击中的技术实现与应用价值。研究表明，通过在浏览器终端侧部署轻量级、本地化的检测与硬阻断机制，可有效应对非邮件渠道传播的钓鱼威胁，弥补现有云端安全策略的盲区。其开源、透明、低侵入的特性，特别适合资源有限的中小MSP采用。然而，该工具的成功依赖于社区对钓鱼域名库的持续维护与对代码安全的共同监督。未来，随着与身份治理平台的深度集成，此类终端侧防护工具有望成为企业零信任架构中不可或缺的一环。安全防御不应仅依赖围墙，更需在每个交互点部署智能哨兵——Check正是这一理念的务实体现。

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