2026 年 10 月 29 日，币安发生一起涉及约 63.4 亿美元资产的安全事件（币安披露口径；TRM Labs 估算约 63.6 亿美元）。攻击者获得内部钱包签名服务的未授权访问，在正常提现流程之外发起交易，从多条区块链上的热钱包转出资产。[1][2]
涉事热钱包使用了 MPC（安全多方计算）。币安在 10 月 30 日的公告中表示，目前尚未发现钱包私钥泄露的证据。[3]
私钥没有被证实泄露，资产却已经被转走。这次事件值得思考的是：如果员工电脑、生产服务器，甚至 MPC 签名协调入口被攻破，还有什么能够阻止攻击者动用资产？
事件复盘：从员工电脑到钱包签名服务
根据币安 11 月 3 日发布的初步调查报告，这是一次持续数月的多阶段入侵。[1]
6 月，一名钱包运维工程师为安装 AI 编程工具，下载了被篡改的 Homebrew 安装程序。安全团队随后更换设备并轮换相关凭证，但部分钱包团队成员的身份和职责信息已经暴露。
9 月，另一名工程师在虚假的招聘面试中运行了包含恶意代码的项目，恶意程序当时未被终端安全工具检出。
10 月 20 日，攻击者利用失陷电脑及内部 AI 工具，进一步控制其他钱包工程师的设备，并窃取了另一名钱包运维工程师的容器部署凭证。
10 月 29 日，攻击者使用窃取的凭证部署容器、执行恶意脚本，最终获得内部钱包签名服务的未授权访问。
随后，XRP、Solana、Optimism、比特币等网络相继发生异常转账。据 TRM Labs 的链上分析，此次事件涉及十条区块链。[2]
在以太坊上，攻击者同样利用失陷的签名服务，提前取得了 50 份 EIP-7702 授权签名，并通过一笔链上交易提交。这些授权覆盖连续的账户 nonce，其中一份因 nonce 匹配而生效，将热钱包的执行逻辑委托给攻击者控制的合约。此后，攻击者能够利用这项链上权限持续转移资产，而不必经过正常提现流程。[1][2]
截至 11 月 3 日，币安披露约 28.5 亿美元的相关资产已被冻结或拦截。[1]
这次攻击的关键路径是：
员工终端失陷 → 内网横向入侵 → 部署凭证被盗 → 签名服务遭未授权访问 → 资产转移。
目前没有证据表明 MPC 签名算法遭到破解。MPC 让多个参与方协同生成签名，避免完整私钥集中存储，降低单点密钥泄露的风险。但 MPC 算法本身不会判断一笔交易是否经过合法的业务授权。如果攻击者能够让满足门限要求的参与方接受恶意请求，即使没有取得完整私钥，也可能生成有效签名。
保护私钥和控制私钥的使用权限，是两个不同的安全问题。
币安尚未公开各个 MPC 签名参与方的具体校验机制，因此目前无法判断其内部具体哪一环出现了问题。但可以确定的是，攻击者获得了内部钱包签名服务的未授权访问，并成功转移了资产。这说明机构钱包除了保护私钥，还必须严格控制签名权限，确保每次签名都经过合法授权。
此次攻击从员工电脑开始，而恶意程序当时并没有被终端安全工具检出。[1] 针对这类攻击，企业首先需要加强终端防护，并提高员工的安全意识：
（1）员工不应随意下载、运行来源不明的开发工具、开源项目和脚本；企业应加强软件安装管理和第三方依赖审查，并通过杀毒软件、EDR 等工具监测异常行为。
（2）内部 AI Agent 也应遵循最小权限原则，严格限制其访问生产系统、敏感凭证及执行高风险操作的权限。
（3）通过日常安全培训、安全考试和钓鱼演练，来提高员工识别虚假招聘、恶意项目及供应链攻击的能力。
但终端防护无法保证拦截所有攻击。如果员工电脑已经被攻破，如何阻止攻击者进一步进入内网、窃取权限，最终控制钱包签名服务？
纵深防御之道：单一系统失陷不应直接导致资产损失
机构钱包不能假设员工电脑、内部网络或生产服务器永远不会被攻破。当攻击者突破其中一个环节后，是否还需要跨越其他独立的安全边界，才能获得资产签名权？
下面从三个逐步升级的攻击场景展开：员工电脑失陷、生产部署权限失守，以及业务系统乃至签名协调入口被控制。
假设员工电脑失陷：不要让一台终端变成通往生产系统的跳板
攻击者控制一台员工电脑，不应该因此获得访问整个企业内网和生产系统的能力。
首先，应尽可能缩小网络攻击面。对外业务系统只开放必要的端口和接口；内部管理接口和生产运维入口原则上不直接暴露公网，应通过受控通道访问，降低核心系统直接受到攻击的风险。内部网络访问也应遵循最小权限原则，根据人员角色、设备身份和业务需要授权。普通办公设备不应随意访问生产环境，研发人员也不应默认拥有核心生产服务器的管理权限。不同业务系统及安全敏感区域之间，应建立独立的网络访问边界，限制攻击者横向移动。
其次，需要隔离敏感权限。研发、生产部署、核心代码授权和资金操作应由不同的权限体系管理，避免单个账号掌握过多关键权限。部署凭证和生产访问凭证尤其需要重点保护。此次事件中，攻击者正是在一台失陷的工程师电脑上，使用从另一名钱包运维工程师处窃取的凭证部署容器、触发恶意脚本。[1]
这类高权限凭证不应长期以明文或可直接复用的形式保存在日常办公设备上，而应通过受控凭证管理、按需授权等措施降低暴露风险。生产部署操作也应通过受控环境发起，避免任意办公设备都能直接操作核心生产系统。此外，还应持续监测异常登录、跨系统访问、敏感权限变更及高风险操作。一旦发现设备或账号失陷，应及时隔离设备、撤销相关凭证并阻断异常访问。通过网络隔离和最小权限控制，可以限制单个员工账号或终端失陷后的攻击范围，降低攻击者进一步获取关键权限的风险。
但如果攻击者还是窃取了生产部署凭证，能够将恶意程序部署到生产环境，又该如何阻止它控制核心安全系统？
假设生产部署权限失守：部署权限和应用准入权限形成可信信任链
代码经过安全审计，并不代表线上运行的就是经过审计的版本。如果攻击者能够替换核心程序，并让恶意程序直接获得原有的敏感业务权限，代码审计就可能失去意义。
因此，像分发签名计算任务的核心程序，需要建立从开发、发布、部署到运行的完整信任链。
首先，应通过可复现构建验证，确保发布的程序与经过审计的源码一致。核心程序的新版本还需要经过独立的多人审核与授权，不能由构建系统或部署人员单方面批准。
对于承担关键授权功能的程序，可以通过可信执行环境（TEE）的远程证明机制验证实际运行的代码身份，并确认该版本是否经过授权。只有通过验证的可信程序，才能获得相应的敏感业务能力。
这样，即使攻击者将恶意程序部署到生产环境，未经授权的程序也无法通过可信执行环境校验，无法冒充可信程序生成有效的交易授权结果。通过将生产部署权限与应用准入权限分开，可以防止攻击者仅凭部署权限就替换可信程序、篡改核心安全逻辑。
假设业务系统乃至签名协调入口被控制：签名前独立验证授权与内容
再假设攻击者控制了业务服务器或数据库，能够修改交易金额、收款地址、审批记录或交易策略。如果签名系统直接相信这些数据，就可能将攻击者伪造的交易当作合法请求。因此，对于资产转移等关键交易，应建立独立的策略校验系统，负责验证交易授权、业务规则和风险控制要求。这类系统通常称为策略引擎，可以基于 TEE 构建，避免业务服务器被攻破后直接影响授权校验结果。
在采用 TEE 的设计中，策略引擎根据预先建立的成员权限、审批规则和交易策略，独立验证相关授权签名。检查通过后，生成带有密码学签名的可信报告，记录经过授权的交易关键内容。业务服务器可以传递交易请求，但不能仅凭修改数据库或内部接口数据，就伪造有效的授权报告。
签名系统还需要确认究竟签署了什么。
币安此次事件中的 EIP-7702 授权，并不是一笔普通转账，而是允许账户将执行逻辑委托给其他合约。授权一旦生效，攻击者就可能通过被委托的合约继续转移资产。[2][4] 类似风险还包括代币授权、合约升级、权限委托，以及无法识别真实业务用途的原始哈希签名。
因此，签名系统不能只检查普通转账的金额和收款地址，还需要识别签名内容的真实含义，对高危授权设置独立的审批和权限限制。对于无法确认具体用途的签名请求，不应默认按照普通转账放行。
EIP-7702 只是此次攻击的一条资金转移路径。比特币、XRP、Solana 等网络上的异常转账并不依赖这项机制。仅仅拦截 EIP-7702，并不能解决签名服务整体失陷的问题。
即使攻击者进一步控制了 MPC 签名协调入口，也不应因此获得最终签名权。
各个 MPC 参与方不能只相信协调服务下发的待签名哈希，而应独立验证策略引擎签发的可信报告，核对交易关键字段，并根据原始交易或授权数据确认最终待签名消息。任意一个必要的签名参与方校验失败，即可拒绝参与签名，最大化利用 MPC 分布式计算的特点进行分布式校验，进一步增加攻击门槛。
此外，MPC 还可以通过客户与服务商分别持有密钥分片，进一步限制单方签名权限。例如，在 3/3 MPC 架构中，客户持有一份密钥分片，另外两份分别由服务商的两个独立节点管理。三方必须共同参与，才能生成有效签名，服务商无法单方面完成签名。
在人工审批场景中，客户 App 还可以执行所见即所签（WYSIWYS）校验，在本地核对审批内容、原始交易数据和最终待签名消息。例如，审批人批准向地址 A 转账 100 USDT，如果服务端随后将收款地址替换成 B，客户端及其他签名参与方就能通过独立校验发现这种篡改。
自动化签名的风险有所不同。客户部署的自动签名组件根据预先授权的业务规则参与审批和签名。如果客户业务系统与自动签名组件同时失陷，恶意请求仍可能获得有效授权。因此，两者应通过独立云账号、最小权限等措施隔离开，并通过独立的交易策略和额度限制，降低恶意签名风险。
从可信程序、可信准入到最终签名，每个环节都需要独立验证。签名协调入口可以负责组织 MPC 计算，但不能成为交易授权和签名内容的唯一信任来源。
如果攻击已真实发生，如何尽可能减少损失？
即使建立了多层防护，也需要考虑最坏的情况：攻击者已经取得有效签名，甚至已经在链上完成了恶意授权。
币安此次事件中，暂停正常提现和关闭热钱包服务，并没有立即阻止全部资产转移。原因在于恶意 EIP-7702 授权已经在链上生效，不再依赖正常提现流程。停止新的签名请求，并不会自动撤销已经生效的链上授权。
币安披露，由于涉事热钱包使用 MPC，没有一把可以直接用于撤销授权的完整私钥，团队需要临时制定专门的撤销流程，拖长了处置时间。[1] 这并不意味着 MPC 天然难以应急，而是说明机构钱包需要提前准备独立于正常业务流程的应急签名和资产恢复能力。
应急处置需要区分三种情况：
- 尚未签名的交易： 通过紧急停签、权限冻结等措施阻止新的恶意签名。
- 已经签署的交易： 已经生成的有效签名不会因为签名服务关闭而自动失效，需要根据具体区块链及交易状态处理。
- 已经生效的链上授权： 需要通过新的有效链上操作撤销或替换授权，单纯暂停提现无法收回已经授予的权限。
如果发现某个钱包受到恶意委托控制，还应立即停止向该地址自动归集资金，并停止将其作为新的充值地址使用，避免后续资金继续进入失陷钱包。
除了及时止损，还需要考虑平台本身无法正常提供服务的极端情况。机构钱包应为客户保留独立于线上平台的资产恢复能力。例如，在持有完整有效恢复材料的前提下，客户可以通过离线工具恢复钱包私钥，再导入其他钱包，继续管理或转移资产，而不必依赖原有平台继续正常运行。[6]
对于需要服务商协助的恢复场景，应建立明确的身份核验、授权审批和密钥分片恢复流程，并通过定期演练验证可行性。
离线恢复和紧急撤权解决的是两个不同的问题：前者用于在极端情况下重新取得资产控制权，后者用于尽快终止已经生效的恶意链上授权。两者不能相互替代。
结语
币安此次事件中，攻击者利用内部钱包签名服务的未授权访问完成了异常资产转移。目前没有证据表明 MPC 密码算法遭到破解；币安也表示尚未发现钱包私钥泄露的证据。[1][3]
这次事件说明，私钥安全只是机构资金安全的一部分。从终端安全、网络访问控制、人员权限隔离，到可信代码发布、可信准入及 MPC 多方独立验证，每个环节都需要建立独立的安全边界。
员工电脑被攻破，不应直接导致生产权限失守；攻击者取得部署权限，不应因此能够替换可信程序、控制核心授权；签名协调入口被控制，也不应绕过各个参与方的独立验证。
同时，机构钱包还需要提前准备紧急停签、链上授权撤销和独立资产恢复能力，尽可能减少攻击造成的损失。
纵深防御的核心是避免单一系统或权限失陷直接导致客户资产损失。
Safeheron 即将推出 API 安全态势感知产品
该产品基于真实攻击事件中的行为特征沉淀而成，能够识别异常的 API 调用，并支持告警和应急处置，为客户资产管理系统的内网安全多加一道防线。如需提前了解，欢迎联系我们。
关于 Safeheron
Safeheron 将纵深防御应用于终端安全、内部访问、核心程序授权、交易签名和资产恢复等关键环节。
在终端与内部访问层面，Safeheron 已部署终端安全防护并持续处理安全告警处置，同时开展员工安全意识培训和考核。对于部分高敏环境，实施网络访问限制；内部系统按照岗位职责分配权限，并通过专门的凭证管理措施降低敏感凭证暴露风险。
在核心程序层，可信程序准入需要经过安全、研发及关键人员的多人审批。可信准入与生产部署权限相互独立，运维人员即使拥有部署权限，也无法单方面授权核心程序。经过审计的代码通过独立可复现构建验证、多人授权签名及基于 Intel SGX 的 TEE 远程证明，确保关键业务能力只授予经过授权的可信程序。
在业务及签名层，Safeheron 采用基于 TEE 的策略引擎，独立验证客户授权、审批签名和交易策略，并签发可信报告。客户侧签名组件与两个相互隔离的云端节点共同完成 3/3 MPC 签名，各参与方在签名前独立验证可信报告和交易数据。
在人工审批场景中，客户 App 执行所见即所签校验；自动化场景则由客户自行部署的 API Co-Signer 根据业务授权结果参与 MPC 签名。[5]
在极端情况下，Safeheron 提供开源的离线私钥恢复工具。客户持有完整恢复材料时，可以脱离线上平台恢复钱包私钥，并将其导入其他钱包管理或迁移资产。[6][7]
通过这些措施，Safeheron 将终端防护、权限隔离、可信代码、业务授权、MPC 签名和资产恢复结合起来，降低单个内部系统或权限失陷导致客户资产受损的风险。
参考资料
[1] Binance，2026-11-03：29 October 2026 Binance Security Incident: Initial Findings and Response Update
[2] TRM Labs，2026-10-29：North Korea Steals USD 6.36 Billion From Binance
[3] Binance，2026-10-30：Security Incident Update #2
[4] Ethereum Improvement Proposals：EIP-7702: Set Code for EOAs
[5] Safeheron：API Co-Signer
[6] Safeheron：Offline Private Key Recovery
[7] Safeheron GitHub：Offline Recovery Tool