2026年8月31日——Confiant披露了一项名为HexMage的Magecart攻击活动：超过40个电商店面（横跨至少15个国家）的结账页面被植入窃卡脚本，而恶意载荷的投递通道是以太坊Sepolia测试网上的智能合约。攻击者利用区块链作为抗封锁的载荷分发基础设施——防御者封锁一个载荷域名，攻击者只需更新智能合约中存储的值或部署新合约，无需重新入侵商家网站。传统Magecart检测依赖的IOC封锁逻辑，在这里遭遇了结构性失效。
三阶段攻击架构
第一阶段：服务端入侵。攻击者攻陷商家服务器，在结账页面注入一个轻量级JavaScript加载器。注入代码伪装成Google Tag Manager代码块——带熟悉的GTM注释与base64混淆的配置数据。但与真实GTM不同，这个伪造块不加载googletagmanager.com的gtm.js，而是从正规的jsDelivr CDN拉取ethers.js Web3库，并向0xrpc.io（以太坊Sepolia测试网的公共RPC端点）发送JSON-RPC请求。
第二阶段：区块链中转。加载器调用攻击者控制的智能合约上公开的getText()函数。合约不直接返回窃取器代码，而是返回一个一次性载荷域名的hostname。浏览器把这个hostname与硬编码路径拼接，静默加载最终的JavaScript窃取器。
第三阶段：结账页面窃取。最终脚本覆盖或替换商家的合法支付字段，捕获卡号、有效期、CVV、持卡人姓名、账单邮箱等全部结账数据，Base64编码外传后再恢复原支付界面——交易正常完成，顾客与商家都毫无察觉。
为什么区块链是完美的死信箱
EtherHiding技术此前多用于恶意软件分发（假浏览器更新、ClickFix诱饵、信息窃取器），HexMage首次系统性地将其应用于支付卡欺诈。区块链在这个场景的优势近乎完美：
合约作为攻击者控制的文本存储，公开getText()与owner()方法。钱包所有者通过签名交易更新存储值，任何人无需钱包即可读取内容——对攻击者是零成本的分发通道，对研究者是可枚举的公开账本。
被入侵的结账页面初始不包含任何硬编码恶意域名：静态检查看不到可疑的IOC，基于域名的封锁无从下手。载荷域名的轮换完全在链上完成，商家侧的感染代码无需任何改动。
链上取证：一个钱包牵出156个合约
区块链的公开性同样为防御者提供了窗口。Confiant分析了25个受害店面、20个Sepolia合约与20个托管窃取脚本的域名，发现所有合约关联同一个所有者钱包（0x88361C914Bb0942da9a1b7Bb396a7513C1917aee）。该钱包在2026年3月至7月间部署了至少144个匹配合约，到8月23日总数已达156个。
合约中存储的内容分两类：明文Base64编码的hostname与加密的hostname信封。载荷域名采用暗黑奇幻主题命名——bloodthornkeep、ashenravenfort、nightstalkerwatch、voidwalkerforge。而大多数受害店面运行WooCommerce，PrestaShop、Magento与标准WordPress也有感染案例。
值得注意的防御盲区：HexMage还包含第二加载器变体——完全跳过区块链检索，直接从Base64解码完整的窃取器URL。这意味着防御者不能仅依赖检测以太坊JSON-RPC活动或意外的ethers.js导入。
定制化的支付网关伪装
窃取器针对各支付网关做了定制，可模仿Stripe、PayPal、ePay、PhonePe、HyperPay及区域支付处理商的界面。恶意代码还内置运营纪律：检测到已登录的WordPress管理员时拒绝执行——商家日常测试结账流程时看到的是完全正常的页面。
行动清单
- 检查结账页面的脚本加载行为：加载Web3库、与公共区块链RPC端点通信、包含GTM样式代码却不请求gtm.js——三者任一都应触发告警；
- 部署内容安全策略（CSP）：限制未批准的脚本来源与出站网络目的地，从架构上压缩窃取器的生存空间；
- 审计服务端网站变更：管理员账户活动、插件漏洞、支付模板中的未授权JavaScript都在排查范围；
- 对已识别合约钱包做链上关联分析：156个合约与关联域名构成了一份现成的威胁情报清单，可用于主动检测；
- 商家需认识到：支付盗窃发生在购物者浏览器中，信任已经建立在合法网站上之后——服务端入侵的每一个瞬间都是损失放大的窗口。
区块链的抗审查特性第一次被大规模武器化到零售支付场景。攻击者赌的是防御体系的僵化：IOC驱动的封锁追不上链上一键轮换的载荷地址。但区块链的公开性同样是双刃剑——每一次合约部署都是永久留痕的证词。HexMage的合约背后，那个钱包地址已经把自己写进了不可篡改的指控记录里。