域名劫持型钓鱼的信任错配与处置边界

摘要　以跨链桥 Across Protocol 于 2026 年 11 月 10 日遭遇的域名劫持事件为样本，考察去中心化金融前端入口被接管后，钓鱼攻击的形态变化与既有防御体系的失效环节。攻击者未触碰智能合约，而是对域名注册服务商实施社会工程，取得官方域名的管理控制权，将合法站点替换为窃取资产的钓鱼页面；项目在发现异常约十五分钟后阻断访问，安全应急组织向主流钱包通报，内容分发网络将域名标记为危险并清除相关解析记录，项目承诺对受损用户全额赔偿。文章提出两个分析概念：信任错配，指安全投入集中于链上代码而风险落于链下入口；处置边界，指链下事件只能靠链下协同与时间竞争收敛，链上既无法回滚已签名授权，也无法撤回已传播的解析结果。结合 2021 至 2026 年间可核验的同类事件序列与行业损失结构数据，文章说明域名为何构成信任汇聚点、授权机制为何使损失与访问时点解耦，并从域名资产治理、前端完整性、授权卫生、响应剧本与责任分配五个方向提出治理路径。结论认为，合约审计所能保证的是代码按写定的方式执行，它无法证明用户访问的正是那段代码。

关键词　域名劫持；钓鱼攻击；信任锚点；代币授权；应急响应

1　问题的提出

2026 年 11 月 10 日协调世界时 18 时 45 分，跨链桥 Across Protocol 的官方域名 across.to 被替换为一个用于窃取用户资产的钓鱼页面。攻击没有发生在链上。合约未被改动，流动性池未被触碰，代码审计所覆盖的全部对象都完好无损。攻击者做的事情只有一件：对域名注册服务商 Namecheap 实施社会工程，取得该域名的管理控制权，然后把合法站点换成一个外观一致的仿冒页面。

事件的处置节奏与它的攻击路径同样值得注意。项目在发现异常约十五分钟后切断了站点访问；安全应急响应组织 SEAL911 将该域名作为钓鱼站点通报给主流加密钱包服务商；Cloudflare 将其归类为危险站点并清除了相关域名系统记录。项目公开承诺，凡在钓鱼页面被完全阻断前访问并遭受损失的用户，将获得全额赔偿；同时说明通过外部服务集成与接口访问的客户未受影响。截至报道时，损失规模与受影响人数尚未披露，前端与接口服务在域名安全性得到确认前保持停用，对域名如何被劫持的调查仍在进行，事后报告尚未发布。项目建议用户在事件当日通过授权管理服务 Revoke.cash 撤销当日所连接钱包的全部授权。按 DeFiLlama 的统计，Across 在事件前三十天处理了约五十九亿美元的资产转移，在跨链桥类别中按处理量排名第三。

围绕这个案例，可以提出一个比 "谁的错" 更有分析价值的问题：一个通过多轮审计、代码公开、运行数年的协议，为什么会被一个注册商账户击穿？答案不在技术细节里，而在安全投入的分布与信任的实际落点上 —— 审计覆盖的是链上执行，用户进入系统的路径却在链下。本文要论证的是，这种错配不是实施疏漏，而是结构性的：只要前端仍由传统域名与注册商承载，域名就必然成为整条信任链的汇聚点，而它的治理层级又长期被当作营销资产而非安全资产。

文章材料包括该事件的公开说明、2021 至 2026 年间可核验的同类域名劫持与前端接管事件、行业损失结构统计、域名与证书体系的技术规范说明，以及国内相关制度文本。方法上采用案例序列对照与机制分析，不作统计推断。同类事件在损失金额、责任认定与调查结论上存在口径差异，本文引用时标明来源与不确定处，不将不同口径的数字合并计算。

2　事件还原：十五分钟窗口里的五个动作

把事件按时间顺序拆开，可以看到处置链条由五个动作组成，每个动作的权限主体都不同。

第一个动作是发现。项目察觉站点异常，判断域名解析指向了非其控制的服务器。这一步依赖的是自身监控或外部提醒，而不是任何链上信号 —— 链上不会出现异常，因为链上没有发生任何事情。

第二个动作是阻断。项目在约十五分钟内切断了通过该域名的访问。需要注意的是，"阻断" 在此处的作用范围有限：它可以阻止新的访问者进入钓鱼页面，但无法撤回已经完成签名的授权，也无法让已经缓存了错误解析结果的递归解析器立刻更新。

第三个动作是通报。SEAL911 向主流钱包服务商报告该域名为钓鱼站点。这一步的实际价值在于把拦截点前移到钱包侧：当用户在钱包内连接站点或准备签名时，钱包依据其风险名单给出警告。对已经打开页面的用户，这是最后一道可用的提示。

第四个动作是清除解析记录。Cloudflare 将该域名标记为危险站点并删除相关域名系统记录。这一动作效果直接，但也暴露了一个治理问题：注册商、解析服务商与内容分发网络在紧急状态下对域名的处置权，边界在哪里、由谁授权、如何避免误伤，缺乏统一约定。此次是协同处置，属于较理想的结果；若各方判断不一致，清除动作可能延迟，也可能互相覆盖。

第五个动作是修复与承诺。域名控制权重获，前端与接口在安全性确认前保持停用，赔偿承诺公开，事后报告待发布。停用是保守但正确的选择：在根因未明时恢复服务，等于把用户重新暴露在尚未排除的风险下。

这五个动作合起来，构成了一个典型的时间竞争结构：损失在攻击窗口内产生，处置只能在窗口关闭后收敛。项目的十五分钟响应在同类事件中属于较快的一档 ——2022 年 8 月 Curve 的窗口约为一小时，2022 年 5 月 MM.Finance 的前端被篡改后约三小时才下线，2021 年 12 月 BadgerDAO 的攻击者则在前端潜伏数周、累积近两百个地址的授权后集中排空。相比之下，Across 的快速阻断确实减少了暴露面，但 "快" 只能压缩损失，不能消灭损失。

3　信任汇聚点：为什么一个注册商账户等于资产控制权

域名之所以在去中心化系统中占据特殊位置，是因为它同时是五条独立信任链的交汇处。

第一条是解析链。用户输入域名，解析器返回地址，浏览器据此连接服务器。这条链的控制权在注册商与解析服务商手中。攻击者取得注册商账户控制权，就取得了对全部查询结果的改写权，且改写对全球所有解析器同时生效，直到记录被纠正。

第二条是证书链。当前主流证书签发采用域名验证型校验，签发机构只验证申请者对域名的控制权，不验证组织身份。这意味着控制域名的一方可以在数分钟内为自己取得一张合法证书，浏览器显示的安全锁与 "https" 前缀完全正常。用户习惯用来判断站点真伪的两个视觉信号 —— 地址栏中的正确域名、有效的加密连接 —— 在此刻同时失效。这是域名劫持型钓鱼与仿冒域名钓鱼的根本差别：后者要求用户看错，前者不需要用户看错任何东西。

第三条是接入链。钱包、聚合器、行情站、浏览器插件维护着项目入口的白名单与合约地址库，这些记录通常以域名为键。域名被接管后，白名单本身不需要被攻破，它指向的对象已经换了。

第四条是接口链。前端调用的接口端点、跨链路由服务、状态查询服务，多以域名或与其绑定的配置定位。攻击者不必攻破接口，只需让前端把请求发往自己的服务器。

第五条是沟通链。官方公告、社群通知、客服渠道、邮件域名，与主域名共享同一套注册信息与账号体系。这让攻击者可以在事件期间同时伪造 "官方说明"，进一步压缩用户的判断空间。

五条链汇聚于一个账户，而这个账户的治理等级通常远低于它实际承担的权限。多数团队对私钥、多签、金库权限设有硬件密钥、多人审批、时间锁；对注册商账户却常常只有一个人、一个密码、一个短信验证码。这种落差不是无知，而是分类错误：域名被归入 "市场与品牌" 事项，其账户由市场人员持有；而它实际承担的权限，等同于对用户入口的完全控制权。

把这一点说得更直接一些：如果攻击者能够改写解析记录，他不需要接触任何私钥，就能让所有访问者看到他想让他们看到的界面；而界面决定了钱包被要求签什么。链上一切不可篡改的保证，在这个环节全部前置失效。据 DiMiao, CN 分析，域名类事件造成的损失之所以与 "网站被黑" 不在同一量级，原因在于它改变的不是内容，而是 "用户在与谁交互" 这一前提；前提被替换后，后续所有的签名行为在链上都是合法有效的，因而不可撤销。

4　授权机制：损失与访问时点为何解耦

域名劫持之所以能直接转化为资产损失，需要第二个条件：授权机制。

在代币授权模型中，用户对某个合约授予额度后，该合约即可在额度范围内转移用户资产。授权是一个独立于转账的动作，一旦写入便持续有效，撤销需要用户主动发起另一笔交易。授权的额度可以是精确数额，也可以是无限。除常规的额度授权外，还存在通过离线签名完成的授权形式，用户只需签署一段结构化数据，不必支付链上手续费，攻击者即可获得可动用其资产的权限。

这套机制的设计初衷是减少交互次数、降低手续费，对正常使用是便利，对攻击者则是杠杆。攻击者不需要私钥，不需要助记词，只需要一次签名。签名完成后，资产并不立即转移，攻击者可以等待授权在多个地址上累积，再集中排空。BadgerDAO 事件中，攻击者从注入恶意脚本到集中排空间隔数周，累积近两百个地址的授权，最终损失超过一亿美元；这一模式说明，授权型攻击的损失不是 "一次点击的代价"，而是 "一次点击 × 累积时间 × 授权额度"。

域名劫持与授权机制结合后，产生了一个很不利的性质：损失与访问时点解耦。用户在被劫持的窗口内访问并签名，损失可能在此后任何时点发生。项目在十五分钟内阻断站点，只关闭了 "新增签名" 的入口，没有关闭 "已签名授权" 的通道。这也是为什么 Across 在通报中特别提示用户通过 Revoke.cash 撤销当日授权 —— 撤销是唯一能在事后削减损失的动作，而它必须由用户自己发起。撤销率取决于用户是否看到通知、是否理解授权含义、是否愿意支付撤销所需的链上费用。这三个环节中任何一个断裂，残留授权就会长期存在。

授权残留的规模并不小。按授权管理服务自身统计，2020 年以来因授权类问题造成的损失累计超过三亿美元；行业中多起事件的受害者在事件后很长时间仍保有对攻击者合约的有效授权。这意味着事件的 "结束" 应以撤销完成为标志，而不是以站点恢复为标志。多数披露并未给出这一指标，这本身是一个值得注意的缺口。

5　错配的量化：损失集中在哪一层

如果域名劫持只是偶发，上述分析就只有个案价值。可核验的事件序列说明它并非偶发。

2021 年 3 月，Cream Finance 与 PancakeSwap 的前端被劫持，原因是其解析服务商的登录凭证被攻破；2022 年 5 月，MM.Finance 因注册商账户凭证被钓鱼而遭劫持，攻击者替换了前端中的路由合约地址，前端约三小时后下线，损失约两百万美元；2022 年 6 月，Convex、Ribbon、DeFi Saver、Allbridge 等多个项目在同一注册商处被劫持，损失约五十五万美元，其中一次事件的复盘提到，涉事账户设有强密码、双因素认证与安全告警，攻击者仍然进入并抑制了告警通知，事后团队核对发现密码与认证方式均未变更；2022 年 8 月，Curve 因解析服务商侧被控而遭劫持，损失约五十七万美元，七名用户受影响；2025 年 5 月，Curve 在同一注册商处第二次被劫持；2024 年，一次注册商迁移中的账号接管缺陷导致两百余个去中心化应用前端暴露，数个知名项目域名被劫持；2026 年 4 月，某交易聚合器因伪造文件提交至注册机构而被劫持，损失约一百二十万美元；2026 年 11 月初，又有十二个去中心化应用站点因同一注册商被劫持。

这条序列有三个特征值得记录。第一，攻击手法高度重复：社会工程针对注册商或解析服务商的支持流程，而非破解加密。第二，责任落在第三方：多数事件的根因不在项目自身账号，而在其上游服务商的账号体系或被迁移流程。第三，复发率高：同一注册商、同一项目多次出现同类事件，说明行业并未从复盘中形成有效约束。

再看损失结构。行业统计显示，2025 年 Web3 领域损失约三十三亿五千万美元、六百三十起事件，其中供应链类占约十四亿五千万美元、比例四成以上，钓鱼类约七亿二千三百万美元、占比两成出头，且是事件数量最多的一类；而合约代码漏洞在事件数量上位居第二，却没有同等量级的损失总额。这组数据的含义很直接：钱主要不是从代码里流失的，是从入口流失的。反网络钓鱼技术专家芦笛在评价这一结构时指出，行业的安全预算仍按 "代码风险" 分配，而攻击者已经把主要精力放在 "入口风险" 上；当防御资源与攻击资源投向不同层，投入越多，边际效果越差。

6　处置边界：链下事件的三重不可逆

前文提到处置是时间竞争。更准确地说，链下事件存在三重不可逆，决定了处置目标只能是 "止损" 而非 "复原"。

第一重是签名不可逆。链上交易一经确认即生效，不存在回滚机制。域名劫持只是把用户带到错误的界面，用户在其中完成的签名在链上完全合法，因此无法被协议方撤销，也无法被司法机关之外的任何主体冻结。可用的补救只有两类：攻击者自愿返还，或通过中心化服务商在资金流出环节拦截。历史案例中，2022 年 Curve 事件里流向某中心化交易所的部分资金被冻结，属于后一类；而流向混币服务的部分则难以追回。

第二重是解析不可逆于瞬时。域名系统采用分布式缓存，记录变更需要时间在全球解析器中扩散。攻击者改写记录后，错误结果的传播是即时的；纠正后，正确结果的回归是渐进的。这就形成了一个尴尬的窗口：即便项目已经夺回控制权，部分用户仍会被缓存导向攻击者服务器。2022 年 Curve 事件的复盘即提到，攻击者的镜像站点被快速下线，但部分解析器仍需时间更新。

第三重是通知不可逆于覆盖。事件通报的到达率取决于渠道与用户习惯。项目能控制的渠道包括官方账号、社群公告、状态页；不能控制的是用户在事发当日是否在线、是否阅读、是否理解。Across 通过 Revoke.cash 提示撤销，是正确动作，但撤销率无法强制。

三重不可逆合起来，给出一个判断：链下事件的处置上限由 "发现速度 × 通知覆盖率 × 用户执行力" 共同决定，三者中任何一项接近零，处置效果就接近零。这也解释了为什么同类事件中，有的项目在数小时内控制住损失，有的项目在数周后才发现问题 —— 差异不在技术能力，而在是否预置了剧本、是否建立了跨机构通报渠道、是否在事前就把 "域名异常" 当作一级事件对待。

7　责任分配：赔偿承诺改变了什么

Across 的全额赔偿承诺，在同类事件中并非孤例。2022 年 Celer 在前端被劫持后同样承诺全额赔偿受影响用户，另有项目在事件后向受害者退款。赔偿承诺的出现，改变了风险承担的结构，但也带来两个需要辨析的问题。

第一个问题是赔偿的边界。全额赔偿的表述在方向上明确，在执行上需要三个前提：受害范围的确定、损失金额的计量、因果关系的认定。域名劫持场景下，这三项都难以自动成立 —— 用户是否在窗口期访问、是否签名、签名是否被利用、被利用的额度多少，需要链上数据与用户申报相互印证。披露中 "损失规模尚未公布" 是诚实的表述，但也意味着赔偿的实际口径仍待确定。若最终以 "申报制" 处理，则赔付率取决于申报率，而申报率又取决于通知覆盖率，形成新的不均衡。

第二个问题是激励方向。事后全额赔偿对用户是保护，对项目则是把 "入口被接管" 的成本内部化。这本身有正面作用：它迫使项目认真对待域名治理，因为赔偿会直接进入损益。但如果赔偿成为惯例而事前控制未见改善，就会出现一种扭曲 —— 项目更愿意承担 "可赔付的损失"，而不愿承担 "会拖慢上线的控制措施"。域名治理恰恰属于后一类：双人审批、硬件密钥、注册商锁定、变更告警，都会增加日常操作的摩擦。若无外部约束，这些措施很容易在业务压力下被简化。

报道提到，观察者把 "赔偿金额何时确定" 与 "注册商如何回应安全问题" 视为未来同类事件责任划分的基准。这个判断有依据：责任划分的关键在于上游服务商是否承担与其权限相称的义务。若注册商在事件中既不披露根因、也不说明改进，则成本最终由项目与其用户承担，上游缺乏改进动力；反之，若注册商的响应成为行业参照，域名注册环节的安全水位才可能整体抬升。这一点在 2022 年多起事件中已有征兆 —— 当多个项目在同一注册商处接连被劫持，行业并未形成对该注册商的实质性约束，随后同类事件继续发生。

8　治理路径：把入口当资产管

针对上述机制，治理的可操作落点有五处，按优先级排列。

8.1　域名的资产化与权限收敛

域名应被登记为与私钥同级的关键资产，纳入配置管理与变更审批。具体要求包括：注册商账户启用硬件密钥形式的双因素认证，账户持有人限定为极少数并经登记；解析记录的变更实行双人审批并留痕；启用注册商锁定与注册机构锁定，阻断未授权的转移与委派变更；对不再使用的子域记录定期清理，避免悬挂记录被第三方接管；为关键域名配置证书授权规范记录，限定可签发证书的机构范围。

这些措施的共同作用是提高攻击成本，而不是消灭攻击。它们无法阻止上游服务商自身被攻陷，这一点必须承认。2022 年 Curve 事件中，项目方与注册商对根因的表述并不一致，一方称名称服务器被控，另一方称是解析缓存污染；无论何者成立，都说明项目对上游的可见性有限。

8.2　解析与证书的独立监测

监测的价值在于缩短发现时间，而发现时间是处置链条的第一项变量。可行手段包括：从多个独立网络位置定期解析自有域名并与基线比对，出现变更即告警；订阅证书透明日志，监测以自身品牌与相似字符串签发的新证书；对页面实际下发的脚本进行完整性校验与变更比对，而不只监测站点可用性。域名系统安全扩展可以提供响应来源的密码学验证，但其边界需要说清：它验证响应来自持有区域私钥的一方，不保证该方未被攻陷。当注册商或名称服务器被控时，签名依然有效。把它当作 "域名防劫持" 的完整方案，是对其能力的误读。

8.3　前端完整性与备用入口

前端应被视为需要签名与校验的发布物，而非可随时覆盖的静态资源。可行做法包括：对页面加载的外部脚本启用子资源完整性校验，对页面可加载的代码来源施加严格的内容安全策略，使注入的脚本无法执行；对构建产物签名，部署时校验签名而非直接信任当前线上版本；保留一条与主域名不共享注册商、不共享解析服务商的备用入口，并在事件中主动公布。历史案例显示，备用入口的实际价值很高：2022 年 Curve 在主域名被劫持期间，正是通过另一域名继续提供服务。

去中心化承载方案（内容寻址存储配合链上命名）可以移除注册商这一单点，但不应被当作万灵药：链上名称的所有权仍由密钥控制，密钥失守同样可以转移；内容寻址网关也可能被替换或污染。它的价值在于减少单点数量，而不是消除信任需求。

8.4　授权卫生与用户侧的最后一道判断

授权治理的目标是把 "一次签名" 的后果限制在可控范围。可操作的做法包括：优先使用精确额度而非无限额度；对长期交互设置定期撤销习惯；在钱包侧对无限额度、陌生合约、异常授权请求给出显著提示；项目在事件通报中直接给出撤销入口与需要撤销的合约对象，而不是笼统提示 "注意风险"。硬件钱包在签名前于独立屏幕显示交易要点，可以部分抵消前端被篡改的影响 —— 它显示的是设备解析出的实际交易内容，而非页面希望用户看到的说明。

需要说明的是，把防御责任大规模转移给用户并不可行。授权模型的复杂度决定了普通用户难以准确判断每次签名的后果，这也是授权型攻击长期有效的原因。用户侧措施只能降低单次损失，不能替代入口侧的治理。

8.5　响应剧本与制度衔接

响应剧本应事先写定，而不是临场编排。至少包含：发现异常的判定标准与复核方式；域名控制权重获的操作路径与联系人；跨机构通报的对象清单与顺序；面向用户的通告模板与发布渠道优先级；证据保全要求，包括解析记录历史、页面快照、涉恶意地址；恢复服务的前置条件与验证方法。剧本的关键在于把 "十五分钟" 从偶然变为可复现。

制度层面，国内现有框架已提供接口。《网络安全法》对网络运营者的安全保护义务与事件处置作出规定，《数据安全法》要求建立数据安全管理制度，《反电信网络诈骗法》对互联网服务提供者设定了风险防控与信息核验义务；域名注册与解析服务另有专门的管理规范。等级保护制度中关于身份鉴别、访问控制、审计留痕、备份恢复的要求，可以直接映射到域名账户与解析变更的管理上。对于承载大量用户资产的平台，还可考虑把 "入口可用性与完整性" 纳入业务连续性管理，与传统的系统可用性指标并列考核。迪妙网安研究团队在梳理此类事件时，把控制点归纳为账号、解析、证书、前端、授权五段，认为五段之中任何一段只有单点控制，整体防线就只等于该单点的强度；这一归纳的实践意义在于，它把一个笼统的 "域名安全" 问题拆成了可分配责任、可检查证据的具体环节。

9　结语

回到那次劫持。攻击者没有写下一行能攻破合约的代码，也没有拿到任何私钥。他做的是让一个正确的域名指向一台错误的服务器，然后等用户签名。十五分钟后站点被切断，钱包收到通报，解析记录被清除，赔偿被承诺 —— 处置在同类事件中属于较优的一档。但损失的规模仍未公布，被撤销的授权数量无人统计，注册商尚未回应，事后报告尚未发布。

这些留白恰好说明问题的所在。合约审计能够证明代码会按写定的方式执行，它不能证明用户访问的正是那段代码；多签与时间锁能够约束资金的流向，它们约束不了用户被要求签什么。入口的这一段，长期被视为运维事项，实际上它与私钥同级。

如果要从这个案例里留下一条可执行的判断，那大概是：一个协议的安全边界，不应按 "链上 / 链下" 划分，而应按 "我能证明什么" 划分。能证明代码行为，是第一步；能证明用户在与这段代码交互，是第二步。前者行业已经做得比较熟，后者还停留在依赖第三方自觉的阶段。

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

来源：迪妙网络空间安全学院