假浏览器扩展 2026 真实案例：Chrome Store 钓鱼扩展是如何骗过你又骗过审核的

钓鱼站长得再像，URL 终归对不上；但浏览器扩展只要装上就有完整 DOM 权限，连 URL 都不用伪造——它就在你"真的 MetaMask"边上，甚至直接替换它的弹窗。2025-2026 年 Chrome Web Store 上线了多起伪装成主流钱包或安全工具的假扩展，单次最高从用户钱包中转走 700 多万美元。这一篇拆解三起代表性案例的攻击手法、骗过 Chrome 审核的技巧、最后被发现的过程，并给一份能独立判断扩展是否可信的检查清单。

案例一：仿冒 MetaMask，靠"Sponsored Listing"上首页

2026 年 2 月，一款叫 “MetaMask Wallet 2026 Edition” 的扩展通过 Chrome Web Store 的赞助位排到了搜索 “metamask” 的第二位。它和官方扩展的图标、描述几乎一模一样，安装量在 48 小时内冲到 4 万。

它的攻击手法分三步：

1. 复制官方代码 + 注入恶意片段：扩展前 95% 是 MetaMask 真代码（开源），保留所有正常功能，只在 onApprove 钩子里加了一段把用户私钥与种子词发送到攻击者服务器的代码；
2. 延迟激活：恶意代码不在安装后立即触发，而是等用户做满 5 次签名（避免审核时被检测到行为）后才上传数据；
3. 资产分批归集：拿到种子词后，攻击者用 24-72 小时分批转移资产，避免被链上监控立刻警报。

骗过审核的关键是 Chrome Web Store 的审核以静态扫描 + 部分动态测试为主——5 次签名的延迟阈值正好高于审核时长。被发现是因为某个被影响的用户在 Twitter 详细记录了交易时间线，被 Wintermute 安全研究员注意到。最终损失约 380 万美元，扩展下架后部分通过链上追踪追回。

案例二：仿冒 Phantom，专吃 Solana memecoin 玩家

Solana 链 2024 年下半年 memecoin 暴热之后，Phantom 用户群体里小白比例高，成了攻击重点。2026 年 1 月发现的一款假扩展 “Phantom Pro”，专门针对 Solana 链：

• 扩展打开时显示与官方一致的 UI，但实际 RPC 调用走攻击者的中间服务器；
• 用户每次发起交易时，扩展在签名前篡改接收地址——把用户写的目标地址改成攻击者钱包，但前端依然显示原地址；
• 因为 Solana 用户大多通过 Telegram 频道传地址直接复制粘贴，根本不去链上浏览器二次核对。

这种"中间人篡改 RPC"型攻击的破坏力极大，因为用户自己不知道地址被换了——直到对方说"我没收到钱"才发现。损失最大的单个用户是一位 Solana memecoin 巨鲸，一笔转账 720 万美元的 BONK 直接进了攻击者钱包。

发现过程：一位独立安全研究员对 “Phantom Pro” 的扩展包做静态反编译，发现 manifest.json 里申请了 <all_urls> 权限——官方 Phantom 不需要这个权限——立即上报 Chrome 团队，扩展在 12 小时内下架。

Solana memecoin 抓取教程 那一篇里我提过 Solana 散户结构特殊，这个案例从安全角度印证了那一点。

案例三：仿冒"安全扫描器"，反向收割安全意识高的用户

最反讽的一类——伪装成钱包安全扫描工具的恶意扩展。2025 年 11 月发现的 “Wallet Guardian Pro” 自称是 Web3 安全审计扩展，能扫描钱包余额、检测可疑授权、提醒钓鱼站点。

它的攻击逻辑：

1. 安装后请求"钱包余额读取"权限，看起来正当；
2. 几天内表现完全正常，确实能扫描出一些公开授权信息；
3. 在用户访问 OpenSea、Blur 这类正常 NFT 市场时，注入伪造的"高危授权警告"弹窗：声称当前钱包被植入恶意授权，需要立刻一键"修复"；
4. "修复"按钮弹出真实的 MetaMask 签名，签名内容是 setApprovalForAll 给攻击者；
5. 用户因为对"安全扩展"的信任直接签名，所有 NFT 被转走。

这一案例的心理学攻击层面最深——它先建立信任，再利用信任本身做攻击。被骗的用户里反而是安全意识较强的玩家居多。损失约 95 万美元的 NFT 资产。

Chrome Web Store 为什么挡不住

Chrome Web Store 不是没在做事，但有三个结构性问题：

• 赞助广告位与搜索结果混排：用户难以区分付费位和官方位；
• 静态扫描覆盖不全：延迟激活、远程代码加载（部分扩展用 eval 拉取远端 JS）能绕过检测；
• 下架响应慢：从被发现到下架平均 24-72 小时，足够攻击者跑路。

Mozilla Firefox 的扩展审核相对严格但用户量小，所以攻击者还是优先打 Chrome 生态。这点在 硬件钱包供应链风险 里讲的"攻击者跟着用户群体走"的逻辑是一致的。

一份判断扩展是否可信的检查清单

下面这份清单装任何 Web3 相关扩展前都过一遍：

• [ ] 安装来源是不是从官网链接跳转过来的 Chrome Web Store 页（而不是 Google 搜索结果）
• [ ] 开发者名称是不是与项目官方一致（注意大小写、空格、特殊字符）
• [ ] 评分是否真实——看评论时间分布，刷量评论通常在短时间内集中刷出
• [ ] 申请权限是否合理——钱包扩展请求 <all_urls> 是危险信号
• [ ] 安装量是否与项目知名度匹配——一个"MetaMask 增强版"只有 4 万安装量，几乎一定假
• [ ] 是否在 GitHub 上开源，最近一次提交时间是不是合理
• [ ] 装上后先在小钱包测试一周，再用于主钱包
• [ ] 定期审查已装扩展列表，移除不再使用的
• [ ] 不轻信任何"一键修复"功能

MetaMask 钓鱼防御 那一篇里也讲过类似的"权限申请要警觉"原则，可以做交叉阅读。

扩展层防御和钱包层防御要分开

很多人把希望寄托在钱包本身——“我用硬件钱包就安全了”。但扩展层的攻击发生在硬件签名之前：扩展可以篡改你看到的内容，篡改你点击的对象，篡改你以为自己在签的东西。硬件钱包再硬，签的也是被扩展改过的数据。所以 2026 年的 Web3 安全不只是钱包安全，扩展卫生（extension hygiene）已经成为独立的一层：定期清理、审慎安装、信任主流、降低数量。把这件事看得跟"不点不明链接"一样重要，你才真正在保护资产，而不是在表演保护。