对于加密货币机构和服务提供商——包括加密货币交易所、支付公司、数字资产托管方,以及托管型和非托管型钱包提供商——区块链渗透测试对于处于测试范围内的相关方而言,并非可有可无的预防措施。当漏洞可能触及签名或资金,或适用规则要求进行对抗性验证时,这就是一层必要的保障。这一论断基于两个支点:合约代码之外的风险来源,以及监管要求或对对抗性验证的期望。
机构面临的风险敞口不仅限于合约漏洞,还延伸至签名、托管、密钥、人员、供应链和基础设施 [1]。因此,这一攻击面并不能被人们熟悉的 web3 安全解决方案——代码级审计和交易级监控——或仅靠传统渗透测试所完全覆盖。这适用于任何这样的机构:其中人员、供应商、接口或应用程序都可能影响哪些内容被签署、批准、入账或转移——包括托管被外包的情况。与此同时,多个市场的监管机构提出了不同范围、频率和独立性规则的要求、附条件义务或监管期望。
本文开启我们的区块链渗透测试系列文章。在整个系列中,区块链渗透测试(blockchain penetration testing)和 web3 渗透测试(web3 penetration testing)指的是同一学科:我们使用前者作为主要术语,后者作为其常见的行业同义词。本文从宏观层面全面阐述其必要性;后续文章将详细定义该学科、其运作边界以及机构层面的攻击面。
Blockchain Penetration Testing
Find the path in — across contracts, nodes, APIs, and cloud
第一部分:风险从何而来
1.1 合约之外的风险
智能合约漏洞仍然重要,但近期许多最大规模的损失起源于其他地方,尤其是密钥、签名系统和运营基础设施。2024 年,攻击者通过入侵一家钱包软件提供商并操纵一笔合法的交易请求,从 DMM Bitcoin 窃取了约 3.05 亿美元 [2]。2025 年,Bybit 因供应链遭入侵、其签名界面被操纵,损失约 15 亿美元 [3];BtcTurk 的热钱包损失同样可追溯至私钥被泄露 [4]。我们的研究指向同样的方向:在我们于 2026 年追踪的损失超过 10 万美元的事件中,合约外故障约占事件数量的八分之一,却占总损失的四分之三以上。截至 2026 年 8 月,在 rekt.news 公开排行榜上最大的十起黑客攻击事件中(不包括欺诈和其他非黑客条目),有七起属于合约外入侵,无论按事件数量还是按美元损失金额计算,都约占 70% [5]。
钱包和托管系统使这一模式具体化,而钱包安全在近年来一直是事件高发的重点领域。我们的调查将故障归为以下几类:密钥管理、交易签名流程、供应链与依赖项、敏感数据泄露,以及加密实现。
| 合约外故障 | 代表性事件 | 大致损失(据报道) |
|---|---|---|
| 密钥管理 | BtcTurk [4], SwissBorg [6] | 约 5170 万美元(BtcTurk),约 4150 万美元(SwissBorg) |
| 交易签名流程 | Bybit [3] | 约 15 亿美元 |
| 供应链与依赖项 | TrustWallet [7] | 约 850 万美元 |
| 敏感数据泄露 | Slope [8] | 约 410 万美元 |
| 加密实现 | Wintermute [9], Coldcard [10] | 约 1.6 亿美元(Wintermute),约 9000 万美元(Coldcard)* |
* Coldcard 约 9000 万美元是经链上验证的底线数字(约 1,405 枚 BTC);私下估算最高可达约 1.3 亿美元。
将这些事件与渗透测试联系起来的关键,并不仅仅在于它们发生在合约之外,而在于它们是否可被利用,往往取决于已部署的各个组成部分——身份、依赖项、签名控制、审批流程和资金逻辑——是否恰好排列成一条攻击者可以从入口点一路走到资金的完整路径。
Best Security Auditor for Web3
Validate design, code, and business logic before launch
1.2 代码级审计与交易级监控:必要但有限
现有各类知名 web3 安全解决方案分别作用于特定层面。代码级审计(code audit)检查的是代码——合约、钱包或服务逻辑。交易级监控(monitoring)检查的是交易到达链上时的情况;例如,Phalcon Security [11] 会在运行时检测、告警并阻止恶意活动。
这些解决方案很有用,但在面对加密货币机构的资金处理链条——即价值从入口点流向资金转移动作所经过的相互连接的身份、云基础设施、签名工作流、审批链条、钱包、供应商和操作员控制台——时,它们的作用是有限的。攻击者可触达的路径,就是穿越这一链条的一条路线:它可能从 Web、dApp、移动端、API、云端或身份入口点开始,经过签名、审批和资金逻辑,并可能穿越合约在实际运行环境中的行为方式,最终到达另一端的资金转移动作。审查代码并不能拼出这条路径,监视交易也无法预见它。即便两者结合使用,仍可能留下一个组合层面的空白:审计只能证明代码在编写时是安全的,而不能证明部署后的身份、审批和签名者仍然在实际执行这一逻辑;监控则可能放行一笔在技术上有效、但从未被操作员本意所允许的转账。能够弥合这一空白的,是对运行系统中各项控制是否正确组合而成的独立对抗性验证。
区块链渗透测试通过对已组装、正在运行的系统进行实际演练,来发现并证明这样一条路径是否能够在事故暴露之前就触及资金。Bybit 事件的模式揭示了这一问题的本质:一个被入侵的签名界面,把操作员自己的审批变成了他们从未打算进行的转账——这一结果无论是合约本身、对其的审计,还是交易监控,都可能将其判定为合法。区块链渗透测试直接针对这种组合方式:它站在被入侵的供应商、操作员或界面的立场上,测试这样一个立足点是否能够将一个看似有效的审批转变为未经授权的资金转移,以及部署的哪些控制措施——身份、审批步骤、签名检查——真正能够阻止这一切。合约代码层面的保障仍然是审计的职责;区块链渗透测试仅在已部署合约的实时行为构成机构层面通往资金的路径的一部分时,才通过该实时行为对其进行测试——两者的范围是互补的,区别在于侧重点,而非一道硬性边界。第二部分将定义区块链渗透测试所验证的内容,以及其范围的终点。
1.3 传统渗透测试:有用但不够
传统渗透测试在云、Web 和 API、身份以及特权访问等层面仍然具有价值。它的局限在于范围和领域背景:常规的测试项目可能无法涵盖加密货币的业务语义,以及其相互耦合的安全与合规模型。
在加密货币领域,一个签名可以授权不可逆的价值转移;提款审批是一项资金控制决策,而不仅仅是一次表单提交。存款入账、余额记账和内部转账都属于资金逻辑。地址和交易也可能带有制裁或资金来源方面的含义。一名测试人员可能发现了身份验证绕过漏洞,却未能察觉它如何与签名显示不一致、审批策略薄弱或舍入误差等问题相结合,形成一条通往资金的路径。
区块链渗透测试将成熟的对抗性技术应用于传统攻击面,以及整个运行系统中 web3 特有的签名、审批、资金逻辑和合约动态行为等攻击面。它的区别所在是专业的 web3 安全判断力,而非新的工具:测试人员会像攻击者一样解读托管、交易意图、资金流动和合规控制。二者的差异在于目标不同:传统测试通常证明的是 IT 控制层面的影响——例如管理员会话被接管、服务器被攻破——而区块链测试则将价值的转移视为最终判定条件。它会继续深入:在一个合法的签名请求内部篡改收款人或金额,并检查审批者所看到的内容、审批策略,以及实际转移的资金,三者是否仍然保持一致。
总而言之,这是一种互补性的保障,而非静态与动态之间的一道壁垒。代码级审计、交易级监控和传统渗透测试仍然是必要的。区块链渗透测试通过验证可触达路径将它们连接起来;它并不能替代它们,也不能保证发现漏洞,或保证能够防止事故发生。
第二部分:监管机构要求什么
不同司法辖区的要求各不相同,针对特定实体和系统,形成了从许可要求、持续性义务到监管机构触发式义务的一整条谱系。
以下示例仅供说明之用,不构成法律建议。各机构应就自身身份、豁免情形、系统和义务咨询法律顾问以确认。
-
美国纽约州:明确要求,附有限豁免。 根据 NYDFS 23 NYCRR Part 500 [12] 受监管的实体,包括获得 DFS 许可的虚拟货币企业,必须根据风险评估结果,至少每年一次从系统边界内外对信息系统进行测试。可由合格的内部或外部方进行测试。符合条件的小型实体可获得该测试条款的有限豁免,但仍需遵守 Part 500 中其他适用条款。
-
迪拜:每年及变更触发式要求。 获许可的 VASP 必须至少每年进行一次漏洞评估和渗透测试,并在引入新系统、应用程序或产品之前进行测试 [13],且须使用合格的独立第三方。智能合约审计适用于与该 VASP 业务和活动相关的场景。威胁导向渗透测试(TLPT)没有统一的执行频率:VARA 可根据风险,在必要且相称的情况下要求进行此类测试。
-
香港:视为已获牌申请人的牌照条件要求。 被视为已获牌的虚拟资产交易平台申请人,必须在受限运营之前完成渗透测试和漏洞评估,并取得令人满意的结果 [14]。另有针对新设公司申请人的单独指引。独立第三方必须对特定的基础设施和应用程序进行测试,覆盖应用层和网络层。在受限运营之前,管理层必须针对中高风险的发现事项,完成所有主要及关键的整改步骤。
-
欧盟:比例性框架;TLPT 以被识别为前提。 DORA 涵盖金融实体,包括加密资产服务提供商 [15]。该法规要求对支撑关键或重要职能的系统,至少每年进行一次适当的测试——并非专指渗透测试。渗透测试是根据风险和相称性原则可选用的方法之一。威胁导向渗透测试仅适用于由主管机构识别出的实体,在实时生产系统上开展,通常至少每三年进行一次;主管机构可根据风险因素调整该频率。DORA 还规定了测试人员独立性方面的条件。微型企业不在该测试计划要求范围之内。
-
新加坡:非强制性的监管期望。 新加坡金融管理局(MAS)的技术风险管理指引指出,金融机构应进行渗透测试,并期望互联网可访问系统至少每年测试一次,或在重大变更或更新后进行测试 [16]。这是非强制性的监管指导,并不要求由独立第三方进行测试。具有约束力的、面向银行的《网络卫生通告》(Cyber Hygiene Notice)并未具体规定渗透测试。具有约束力的支付或数字支付代币通告不在本文讨论范围之内。
综合来看,这些监管制度要求或期望进行渗透测试——而不是某种打上"web3"标签的特定类别。web3 专业版本的必要性源自其测试范围所涵盖的系统:当这些系统涉及授权、签名、托管或核算加密货币价值时,对其进行妥善测试就需要具备第一部分所述的同等签名与资金流动方面的专业能力。
结论是精确的:在特定司法辖区中,相当一部分获得许可的实体已经面临某项要求或监管期望——但并非在每个市场都是相同的强制性规定。这些差异决定了测试的范围、频率、测试人员独立性、整改要求、证据留存,以及测试所服务的目的,是支持获牌、持续合规,还是监管机构触发的专项检查。
结论:两个支点的汇聚
风险来源与监管要求或期望共同指向同一个结论:对于处于测试范围内的机构而言,区块链渗透测试是一层必要的保障。它验证了跨越访问、审批、签名和资金各环节的可触达路径,同时对现有控制措施加以补充。它无法保证能够防止事故发生,也无法证明它本可以阻止过去发生的任何特定事件,更不能保证发现所有可利用的路径。其目标是在上线、运营、检测、响应和监管取证等各个阶段提供持续性的保障——而非一份一次性的报告。
继续阅读本系列文章:
本系列还包括以下文章,即将发布:
- 第五部分:授权与签名安全:Web、dApp 与移动端
- 第六部分:云与 CI/CD 安全:自动化运营攻击面
- 第七部分:资金管理控制平面安全:签名与提款审批
- 第八部分:交易所账本安全:盗窃路径与数据平面逻辑
BlockSec 可帮助机构精准定位这一保障层次:梳理资产、资金流、信任边界及现有保障措施;确认法律顾问所指出的适用义务;然后明确测试目标、范围、访问权限、生产环境保护措施、整改证据及复测计划。若要识别贵机构的保障缺口,请联系我们的区块链渗透测试团队;测试范围与报价可应要求提供。从资金流动的地方开始。
参考文献
按首次出现顺序编号。
- BlockSec, Crypto Payment Security Playbook.
- U.S. Federal Bureau of Investigation, DC3, and Japan National Police Agency, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (December 2024).
- BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack.
- rekt.news, BtcTurk — Rekt.
- rekt.news, Leaderboard.
- SwissBorg, SwissBorg Security Update: Kiln Breach.
- BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor.
- Slope, Slope Wallet Sentry Vulnerability: Digital Forensics and Incident Response Report.
- BlockSec, Our Short Analysis of the Profanity Tool Vulnerability.
- BlockSec, Coldcard Entropy Failure and Seed Recovery.
- BlockSec, Phalcon Security.
- New York State Department of Financial Services, 23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies.
- Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Part I, Section E.
- Hong Kong Securities and Futures Commission, Circular 24EC65 (18 December 2024, PDF).
- European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Articles 24–27.
- Monetary Authority of Singapore, Technology Risk Management Guidelines (January 2021), Sections 2 and 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).
