区块链钓鱼攻击综合分析

05-29

本文为机器翻译

展示原文

本文由X-explore与WuBlockchain联合发布。

介绍

根据 Chainalysis 在 2024 年的文章，非法地址已收到价值 242 亿美元的资金，占链上总交易量的 0.34%。随着人们对区块链行业的兴趣日益浓厚，越来越多的用户和资产开始流入 Web 3 市场，但用户报告的网络攻击事件也越来越多。

在各种攻击中，钓鱼仍然是网络攻击的主要方面之一。攻击者瞄准各种代币，例如稳定币、ETH 甚至山寨币。他们诱使用户签署恶意交易或输入私钥以控制用户的帐户。本文将进一步研究现有的钓鱼诈骗方法，并探讨未来预防或识别恶意帐户的方法。

背景与相关工作

现有的钓鱼攻击方法框架（链下）

网络钓鱼攻击的重点是诱使用户在网络世界中输入私人信息。诱使用户的方法多种多样，但大多数网络钓鱼都是在电子邮件、社交媒体渠道或看似合法的克隆网站等平台上进行的。此类电子邮件或网站诱使用户输入私人信息或签署交易，从而将控制权交给骗子。本文将首先研究骗子在链下使用的 3 个主要框架。

鱼叉式网络钓鱼

鱼叉式网络钓鱼攻击针对的是特定个人或组织。通过事先收集定制信息，攻击者可以制作一封个性化电子邮件发送给特定群体，从而使该电子邮件合法化。此外，随着生成式人工智能的兴起，一个骗子现在有能力收集个性化信息并制作个性化电子邮件，针对比以前更广泛的用户群体。

域名钓鱼攻击

域名钓鱼攻击会制作重定向到虚假网站的 URL。例如，在 Slack 网站上，将“ www.apple.com ”的“i”替换为大写“I”后，看起来与“ www.appie.com ”完全相同。通过这种方法，诈骗者会制作恶意 URL，并通过电子邮件或 Telegram 或 Slack 等 SNS 渠道进行分发。

假冒浏览器扩展程序

诈骗者编写恶意扩展程序，制作下载链接，通过电子邮件或SNS渠道分发。点击后，此类扩展程序将下载到用户环境中，并寻找助记词和私钥等隐私信息。

请注意，一旦用户点击下载链接、输入私人信息或签署交易，诈骗者将完全控制该帐户，用户无法回滚。因此，用户不要点击不信任的来源至关重要。

区块链上的资金提取（链上）

鉴于链下框架，本文将研究诈骗者如何完全控制链上钱包。在区块链领域，攻击者可以通过各种方式控制用户的账户。尤其是对于 ERC-20 代币合约（例如稳定币和山寨币），诈骗者不一定需要用户的私钥，而是需要用户的签名登录链上或链下。本文将研究攻击者用来窃取资金的各种方式。

私钥

如今，提取私钥已经不是一种常用的方法。攻击者会制作网站或电子邮件，要求用户输入种子短语或私钥。一旦攻击者获得用户的私钥或种子短语，攻击者就完全控制了钱包和地址。

基于私钥的网络钓鱼攻击示例图。（来源：X）

虽然这是一种简单的方法，但是过去的用户由于缺乏区块链领域的知识，很容易陷入陷阱。

批准并转移

在 ERC-20 标准下，ERC-20 代币支持推送和拉取交易，适用于 De-Fi 协议的应用。推送交易由付款人发起，付款人决定向收款人发送多少钱。而在拉取交易中，收款人指示付款人发送多少钱。因此，第三方可以控制交易。拉取交易指令在 Web 3 中按照以下流程进行管理。

用户调用并签署 Approve()。 approve( owner, spender, amount)设置收款人地址可以从用户地址中取出多少代币。请注意，可以利用increaseAllowance( spender, amount) 。approve 和 increaseAllowance 之间的区别在于，approve 设置新的限额，而 increaseAllowance 增加现有限额 [设置硬性限制]。
一旦设置了边界，收款人就可以调用transferFrom(to, from, amount) ，将用户的代币移动到收款人的地址。

在实际应用中，收款人通常是智能合约。用户将 ERC-20 代币转移到智能合约，智能合约将据此管理资金。但需要注意的是，一旦智能合约被黑客入侵，用户的资金将根据设置的限额被盗走。在某些情况下，为了简化用户的 UI，智能合约可能会要求高额（无限量）的限额，这样用户就不必每次都签名来设置限额以节省 gas 费用。由于金额设置为无限量，用户必须确保第三方是可靠的来源。

长期以来，设置授权和使用 transferFrom 方法一直是薄弱环节。然而，由于其在去中心化金融 (De-Fi) 和 dApp 中的实际应用，Approve & TransferFrom 如今已得到广泛使用，并进行了改进。

例如，由于EVM的最大容量设置为1024，set allowance → transferFrom等复杂过程通常会导致“1024堆栈深度问题”，因为堆栈超出了给定空间的限制，从而导致交易回滚。

因此，如果调用每个方法并继续执行下一个方法，则调用它将引入一个巨大的漏洞点。主要的利用方式可能是重入攻击。Vitalik 意识到了某些情况，并在 2017 年进行了改进，并引入了 ERC-223 标准。

Vitalk 对 1024 堆栈深度的评论截图。（来源：Github）

已经引入了其他改进的协议，例如 permit 或 permit2，但钱包的安全性取决于用户签署交易。因此，检查 3 个主要方面以防止潜在的诈骗非常重要。

批准金额：诈骗者经常会创建具有异常高额度的批准请求，以获取对专用 ERC-20 代币的完全控制权。签订合同时，请务必检查批准金额。
已验证的智能合约：确保您签署了由已知 dApp 提供的已验证智能合约的授权签名。检查 Etherscan 或任何其他区块链浏览器的标签和备忘录可以帮助确定合约是否被标记为恶意。
检查安全警报：如果您正在与潜在的诈骗合约进行交互，钱包提供商（例如 Meta Mask 或 Wallet Connect）会生成提示。请务必检查此类警报。

案例

让我们直观地看一下实际攻击是如何在区块链浏览器中进行和记录的。

区块链：BSC 链

日期：2023–05–11

攻击者： 0x49Dc14Dd851B6EaE8d685715e12a06cc1BFC5d8d

受害者： 0x5F464c94e93CEbd56aE2F1220912BA0ab0a27a38

步骤1 ：用户签署批准合同

当通过电报频道、Instagram 或钓鱼网站在 Web 2 环境中收到虚假信息时，用户会收到批准签名请求。

受害者批准骗子获取柴犬代币

批准和转移请求。受害者批准了总计 426923054270173310680061630 SHIB，由诈骗者控制

Dex 或 Cex → 受害者 → 诈骗者的资金流向截图

第 2 步：耗尽资金

现在，由于骗子已经控制了受害者地址中426923054270173310680061630或更少的 ERC-20 代币资金，骗子开始将受害者的代币转移到其账户中。如下所示，受害者账户中已盗取总计256153832.56 SHIB。

该交易由攻击者完成，窃取了 256153832.56 SHIB

允许

ERC-2612 引入了 Permit，作为对 approved 和 transferFrom 工作流程的改进。与 approved 和 transferFrom 不同，Permit 会创建链下签名，这意味着用户不必事先在链上签名批准。Permit 和 transferFrom 的工作流程如下：

Permit 协议技术流程（来源：Medium）

用户需要通过permit (owner, spender, value, nounce, deadline)创建签名，返回值r,s,v为已经创建的签名的3个分割。
一旦用户使用 r、s 和 v 创建许可证签名，第三方将使用以下值调用permit(owner,spender, value, deadline, v, r, s) 。一旦进行阶段变更交易，它将相应地设置限额。
在一笔交易内，一旦设定了限额，第三方就会执行转账。

通过利用 permit() 创建离线签名，可以节省 gas 费用，因为无需在链上签署许可。此外，通过创建 r、s、v，安全性得到了极大提高，用户永远不会暴露自己的私钥来创建签名。

需要注意的是，并非所有 ERC-20 标准 token 都支持 permit() 方法。而且 permit() 的核心机制在 approved & transferFrom 的流程中。漏洞点在于用户创建或签署 Permit() 时。

案例

让我们直观地看一下实际攻击是如何在区块链浏览器中进行和记录的。

区块链：ETH

日期：2024–05–24

攻击者： 0x77865b925f96fc49837cfe27ec04cd5a691e61ef

受害者： 0x7cdd2a99fc014194218119a7100c259e31a10bf2

步骤 1 ：用户生成链下签名

由于这个过程是在链下进行的，因此无法在区块链浏览器上追踪。骗子会诱使受害者通过简单的点击生成链下签名。即使受害者没有在线签署交易，通过钱包签署链下签名已经允许骗子稍后执行 TransferFrom。

步骤 2 ：诈骗者通过链下签名签署许可合同

骗子通过链上交易将签名的消息提交给 ERC-20 Token 合约，验证受害者地址和 nonce 后，会发出批准请求。注意，通过 permit 只发生过一次链上交易，相比传统的 Approve&TransferFrom 少了一次交易，节省了 gas 费。

在一次执行中调用了 Permit 和 transferFrom

注意批准数量异常大

共计 173455570204 USDC 已被提取

ERC-4337（账户抽象或智能合约钱包）

Vitalk 于 2021 年推出的新型 AA 方案是基于当前现有的共识层协议创建的。与之前引入的EIP-86 （Bare multi-sig AA）、 EIP-3074 （Auth 和 Authcall）和EIP-2938 （Account Abstraction）等 AA 方案不同，这是第一个在现有共识层协议中引入 AA 的方案，可更轻松地融入当前市场。

帐户抽象（AA）

区块链中主要存在两种类型的账户：外部账户和智能合约账户。两种账户的特点如下表所示。

AA 的目标是创建一个统一的账户，该账户兼具 EOA 和 SC 的优点：完全可编程，并具有发起交易的能力。AA 的优点包括：

能够直接响应合同调用
轻松转移账户所有权（无法通过 EOA 完成）
引入新的验证规则（可以在 SC 级别内检查密码）
消除从 EOA 到智能合约的 gas 费用
管理一个地址，而不是 EOA 和 SC
引入新的 gas 费支付方式（不必是原生代币）

ERC-4337 的工作流程

AA 是一个新的标准，可以创建统一的账户，大大改善用户的 UI。ERC-4337 的技术流程如下：

ERC-4337 的流程图（来源：Eden Network）

ERC-4337 技术流程图（来源：ERC-4337 官方文档）

ERC-4337 可以分为四个主要流程。

步骤 1：创建用户操作

通过 dApp 和钱包，用户可以与 AA 方案操作进行交互以创建用户操作。用户拥有更好的用户界面，因为该应用程序可以支持多种功能，例如多重签名、社交恢复等。创建用户操作后，它将离线创建一个签名，稍后将由帐户验证该签名，然后再执行。

步骤 2 ：打包处理

一旦用户提交了用户操作，它将被存储在用户操作内存池中，打包器将在那里收集并聚合成一个包。打包器将检查交易的有效性，一旦通过，打包的交易将被发送到链上进行处理。

步骤 3 ：入口点合约

关于 EntryPoint 合约的规则。（来源：ERC-4337 官方文档）

上述规则中提到，链上有一个统一的 Entrypoint Contract，在收到打包交易后会进行 Gas 计算，确定智能合约账户需要支付多少 Gas 费。通过 Entrypoint Contract，用户无需像智能合约账户或 Paymaster 那样支付 Gas 费。而且该方案最重要的优势是 Gas 费不必以 Native Token 支付，费用可以在 dApp 上进行管理，并通过 PayMaster 以 ERC-20 Token 支付。这样的安排提高了用户的交易体验。

步骤 4 ：验证和执行

在收到来自入口点合约的方法后，将验证原始用户操作。验证后，它将相应地执行交易。请注意，这是一个入口点合约，它将把交易添加到 ETH 网络内存池中。

漏洞点

从安全角度来看，仍然存在很多漏洞点。由于 AA 方案允许将用户操作从链下托管的打包器执行到链上，这为骗子操纵用户执行用户操作提供了很多漏洞。本文将提供整个操作执行过程中的潜在漏洞点。

伪造的入口点合约

请注意，每条链只能有一个 EntryPoint 合约。但是，诈骗者可以在链上制作他或她自己的 EntryPoint 合约版本来执行用户操作。由于大多数安全协议和监控将重点关注单例 EntryPoint 合约，因此诈骗者可能希望创建他或她的版本来避免这种情况。然而，使用当前的区块链监控系统可以轻松检测到此类合约并进行相应的管理。

恶意捆绑器

诈骗者可以制作带有用户操作内存池的 Bundler 服务版本。Bundler 服务由四个主要部分组成：配置、RPC 服务器、替代内存池和捆绑 UserOperations。

配置设置 EntryPoint 和受益人账户的地址。

RPC 服务器根据给定的 EntryPoint 地址来处理操作。

 async handleMethod (method: string, params: any[]): Promise<any> { let result: any switch (method) { case 'eth_supportedEntryPoints': result = await this.methodHandler.getSupportedEntryPoints() break case 'eth_sendUserOperation': result = await this.methodHandler.sendUserOperation(params[0], params[1]) break case 'eth_estimateUserOperationGas': result = await this.methodHandler.estimateUserOperationGas(params[0], params[1]) break case 'eth_getUserOperationReceipt': result = await this.methodHandler.getUserOperationReceipt(params[0]) break case 'eth_getUserOperationByHash': result = await this.methodHandler.getUserOperationByHash(params[0]) break // ... default: throw new RpcError(`Method ${method} is not supported`, -32601) } return result }

备用内存将操作以数组格式存储，然后再将其发送到链。从打包器的角度来看，应在此处管理 DoS 攻击的预防。

 // add userOp into the mempool, after initial validation. // replace existing, if any (and if new gas is higher) // revets if unable to add UserOp to mempool (too many UserOps with this sender) addUserOp (userOp: UserOperation, userOpHash: string, prefund: BigNumberish, senderInfo: StakeInfo, referencedContracts: ReferencedCodeHashes, aggregator?: string): void { const entry: MempoolEntry = { userOp, userOpHash, prefund, referencedContracts, aggregator } const index = this._findBySenderNonce(userOp.sender, userOp.nonce) if (index !== -1) { const oldEntry = this.mempool[index] this.checkReplaceUserOp(oldEntry, entry) debug('replace userOp', userOp.sender, userOp.nonce) this.mempool[index] = entry } else { debug('add userOp', userOp.sender, userOp.nonce) this.entryCount[userOp.sender] = (this.entryCount[userOp.sender] ?? 0) + 1 this.checkSenderCountInMempool(userOp, senderInfo) this.mempool.push(entry) } this.updateSeenStatus(aggregator, userOp) }

最后，对于捆绑用户操作，它会创建将发送到 EntryPoint 合约的捆绑包。捆绑者必须确保在转发操作之前验证其支付费用的能力，以防止 DoS 攻击。否则，诈骗者可以制作看似支付了费用但会撤销的操作，从而导致链的内存池拥堵。

此外，验证步骤不应违反状态变化，这意味着它将根据与发送者相关的数据进行验证。Bundle 的验证和创建在下面的代码中

async createBundle (): Promise<[UserOperation[], StorageMap]> { const entries = this.mempoolManager.getSortedForInclusion() const bundle: UserOperation[] = []

 // paymaster deposit should be enough for all UserOps in the bundle. const paymasterDeposit: { [paymaster: string]: BigNumber } = {} // throttled paymasters and deployers are allowed only small UserOps per bundle. const stakedEntityCount: { [addr: string]: number } = {} // each sender is allowed only once per bundle const senders = new Set<string>() // all entities that are known to be valid senders in the mempool const knownSenders = entries.map(it => { return it.userOp.sender.toLowerCase() }) const storageMap: StorageMap = {} let totalGas = BigNumber.from(0) debug('got mempool of ', entries.length) // eslint-disable-next-line no-labels mainLoop: for (const entry of entries) { // check reputation system // check duplicate UserOps per sender // check stake // check storage access // check UserOp call gas limit // check Paymaster deposit if present // If sender's account already exist: replace with its storage root hash senders.add(entry.userOp.sender) bundle.push(entry.userOp) totalGas = newTotalGas } return [bundle, storageMap] }

PayMaster 漏洞利用

由于PayMaster是处理交易的定制合约，因此诈骗者可以通过利用代码漏洞来转移Gas费。未来将进行进一步研究。目前PayMaster漏洞利用的案例还不多。

案例

让我们直观地了解一下实际攻击是如何在区块链浏览器中进行和记录的。请注意，AA 是一种以捆绑操作方式处理交易的方案。诈骗者通常利用 AA 方案来处理 Perimt 或 Approve 等交易。以下示例将查看 Approve 和 TransferFrom 请求。

区块链：BSC 链

日期：2024–03–23

攻击者： 0x454b8b645a981e6c197087ea154df94b5187d682，0x170f7be1baf9234af5966d194a0a6bd6073eed99

受害者： 0x3f3ce11b7809ecf6f571943800c28f585e8b187d

https://app.blocksec.com/explorer/tx/bsc/0x812bc694a8c6732b899e81727f128d06c2b7b6717a2dd67936079928b41621b3

步骤 1 ：用户签署链下许可请求

与典型的许可请求一样，诈骗者会诱使用户签署许可消息。它会伪装成批准交易或访问服务的必要步骤。受害者会认为请求是合法的，然后使用私钥在链下签署消息。

步骤2 ：与Bundler交互

诈骗者现在将与打包器进行交互，打包器将把许可交易作为一项操作来处理。诈骗者将交易发送给打包器，打包器现在将交易存储在用户操作内存池下。存储在用户操作内存池中后，它将经过验证过程并移交给 EntryPoint 合约。

步骤3 ：EntryPoint 合约

EntryPoint 合约从打包器接收到操作流程后，会在执行之前验证打包器中的用户操作。如下图所示。一旦检查到 gas 费用的可用性和状态更改的正确性，它就会处理内部操作。

处理 InnerOperations 之前的操作的屏幕截图

步骤 4 ：处理状态更改

如下图所示，本例的内部操作包含两个 transferFrom 操作。注意两个地址的转账金额相差多少： 212856150000000008192 ， 37562849999999991808 。比例大约是 0.85:0.15，这表明 Drainer 可能提供诈骗服务，并将提取的金额按一定比例分享给 Drainer 和客户。关于 Drainer 服务的细节将在文章后面讨论

BSC-USD 代币 TransferFrom 的两个操作，其中 Approval 和 Transfer 位于

批准中价值异常高的通知

资金流与运作流

诈骗者的攻击方法

加密货币耗尽者（以服务提供商身份诈骗）

近期，加密市场中关于服务提供商诈骗的报道越来越多。服务提供商在多链上工作，提供服务以提取 ERC-20 代币，并赚取被盗代币作为奖励。本文将介绍加密提取者的一个示例案例。

地狱火吸取器

根据 Scam Sniffer 的数据显示，Inferno Drainers 在活跃期的 1 年内（2022 年 11 月 - 2023 年 11 月）已窃取了 8000 万美元或更多。Inferno Drainer 使用社交工程学建立钓鱼网站，并与客户共享该平台。

本文基于 Group-IB 的 Scam Sniffer

然后，客户在 Telegram、Facebook、Instagram 或其他社交网络上发送社交工程网站链接来吸引普通用户。通常不具备加密货币和区块链领域知识的受害者会在不知情的情况下向 Inferno Drainer 的客户授予访问权限。

地狱火汲取者的一般攻击流程如下：

地狱之火排水器的运作流程（来源：Group-IB）

如流程图所示，Inferno Drainer 主要通过构建钓鱼社交工程网站盗取受害者资金，而客户则负责将钓鱼网站传播给受害者。一旦受害者打开网站并签署交易，客户将获得被盗代币的 80%，Inferno Drainer 将获得 20%。

Inferno Drainer 通过非常简单的设置和简单的 Approve&TransferFrom 方法或 Permit 方法在链上窃取了超过 8000 万美元的资产。

排水方法

Inferno Drainer 主要使用了经典的 Approve & TransferFrom 方法或 permit 方法。我们来看看它们活跃期间的其中一个 Approve&TransferFrom

受害者： 0xe142C1858b8447238F3953e685e62ED6005DcAaA

攻击者： 0xFC4EAA4ac84D00f1C5854113581F881b42b4A745

代币：PEPE

损失金额：26,372,295.3（220 美元）

步骤1 ：受害者签署同意（）

注意批准金额的值

步骤 2 ：攻击者执行 TransferFrom()

天使吸取器和攻击方法的改进

在 Inferno Drainer 停止服务后，一种更先进的新型 Drainer 服务问世了。其中一个值得注意的 Drainer 是 Angel Drainer。与 Inferno Drainer 不同，Angel Drainer 利用高级技术来操纵智能合约逻辑和用户行为。某些方法侧重于绕过由行为分析和速率限制触发的安全警报。本文将介绍 Angel Drainer 用于榨干资金的两种主要新型攻击方法。

Angel Drainer 提供的服务截图。（来源：CheckPoint）

嵌套智能合约部署机制

和各种利用 Approve&TransferFrom 或 Permit 的钓鱼手段一样，ChainAlysis、BlockAid、Check Point 等区块链安全组织也开发了复杂的监控算法，可以识别链上潜在的骗子。尤其是骗子地址上的 Permit 和 Approve&TransferFrom 等交易非常容易识别。因此，Angel Drainer 采取了一种复杂的方法，通过创建执行 Multicall 功能的新智能合约来绕过安全警报。

例子

为了了解 Angel Drainer 如何绕过安全警报，我们将研究一个真实的攻击示例，并调查已使用的智能合约。让我们探索背后的交易：

0xb60c32fb28aa6160df6f472f494f162b997aa49fb06776dce250aff80602a8a3

步骤 1 ：创建嵌套智能合约

Angel Drainer 首先创建一个具有以下功能的智能合约。

如下图所示，对于这个特定的交易，Angel Drainer 首先使用0x095838d2() ，然后调用0xf2fde38b() transferOwnership(address)。

为了简单起见，我们将这个合约称为主合约。在主合约中，我们需要关注一个函数0x095838d2() 。该函数的逻辑如下：

需要三个参数(secondContractAddress, tokenContractAddress, arrayOf3Elements)
检查 secondContractAddress 是否为现有合约。它检查给定地址的代码大小。如果它大于零，则表示合约存在，否则反之亦然。
如果是，则执行包含（Permit & TransferFrom）的Multicall函数。如果不是，则用该地址部署新合约，然后执行Muticall函数。

对于此交易案例，secondContractAddress 为 Null，导致其首先创建一个新的智能合约。

步骤 2 ：多路调用函数

一旦主合约识别或创建了第二个合约，第二个合约中的 Multicall() 函数就会被执行。这个函数的存在是为了协调合约交互。我们来看看 multicall() 函数的主要功能。

如上图所示，multicall 接受交易操作作为参数，并通过在 v1[v3] 指定的地址进行外部合约来处理各个参数。multicall 的具体执行过程可参见下图。

如上图，muticall 一共处理了 3 笔交易，分别是 Permit 和两笔 transferFrom。Permit 和 transferFrom 是在代币合约Lido: stETH上进行的。

注意 transferFrom 中的值差异。比例为 0.85:0.15。这说明了 Customer 和 Angel Drainer 的利润分配。

步骤3 ：所有权转移

为了让骗子完全控制第二份合约。0x095838d2 0x095838d2()的最后一步包括执行从第二份合约到骗子地址的 TransferofOwnership。

我们查看了 Angel Drainer 用来绕过安全警报的操纵方法，即创建新合约并在新合约的多重调用中处理操作。由于新合约不包含任何交易记录，通过多重调用隐藏交易，并且不是由诈骗者的地址直接部署的，因此它能够绕过安全警报。然而，由于 Check Point Research 的识别，嵌套智能合约攻击方法现在可以被识别，并且不会再绕过安全警报。

2. EigenLayer Restake Farming 攻击

EigenLayer 是一种去中心化协议，旨在通过“重新质押”过程增强区块链网络的安全性和效率，允许用户将其代币锁定到智能合约中。用户可以先质押代币一段时间并获得奖励，然后重新质押更多代币，而不是取消质押并重新质押。通过这样的过程，它允许用户与多种服务进行交互并质押更多代币，最终同时增强了链的安全性和实用性。

攻击向量点

然而，重新质押机制存在一个漏洞。主要是 EigenLayer 协议的queueWithdrawal机制。要理解攻击是如何进行的，我们需要了解质押和重新质押的过程是如何进行的。

EigenLayer 协议采用一种特殊的方法来处理权益提款。

当用户质押一定数量的代币，然后决定提取质押的代币时，交易不会立即处理。相反，它会被存储在队列中。用户必须等待 7 天的托管期才能取消质押，而在以太坊上，验证者清扫后每 4-5 天可以提取一次部分质押资金。由于这种批准方法是新的，大多数安全提供商或内部安全工具都没有验证这种批准类型并将其标记为良性交易。因此，它为 Angel Drainer 留下了一个可以利用的漏洞点。

例子

链：ETH

日期：从 2024 年 1 月 15 日至 2024 年 1 月 29 日

攻击者： 0x8031A648B169a9fa6f63954C0F0B106E57027696

步骤1 ：CREATE2合约

这是他们能够绕过安全警报并掩盖流程的部分。Angel Drainer 使用 CREATE2 准备一个带有参数(salt, bytecode)的合约。然后 CREATE2 将生成一个特定的新地址。新地址将用于收集奖励和取消质押代币，成功绕过安全警报。

步骤2 ：启动queueWithdrawal

攻击者首先从 Eigen 层发起取消质押，从而触发 7 天的托管期。