DeFi 闪贷攻击的完整链上追踪
用三个真实案例,拆解闪贷攻击的完整链上路径——以及 MerkleClaw 如何在攻击发生后数分钟内识别和追踪。
引言
闪贷(Flash Loan)是 DeFi 的天才发明——在单个区块内借走数百万美元,只要交易结束前还回来就不需要抵押品。但这把双刃剑,也让攻击者获得了无本万利的攻击资金。
2026年Q1,仅闪贷相关攻击就造成超过 $1,300万 损失。
本文用三个真实案例,拆解闪贷攻击的完整链上路径——以及 MerkleClaw 如何在攻击发生后数分钟内识别和追踪。
案例一:Solv Protocol BRO Vault — 重入 + 闪贷($2.7M)
案例背景
- 日期:2026年3月6日
- 协议:Solv Protocol(比特币质押协议)
- 损失:$2.7M(38.0474 SolvBTC)
- 合约状态:未经审计,无 Bug Bounty
- 攻击者出口:Tornado Cash(已确认)
攻击手法拆解
漏洞根源:BRO Vault 合约在 callback 触发时账本尚未更新("先转账,后记账"的反模式)。
Step 1: 攻击者部署恶意合约
地址: 0xSolvAttacker...
Step 2: 调用 BRO Vault 存款函数
deposit(135 BRO)
↓
合约触发 callback → 恶意合约
↓
此时账本尚未记录 135 BRO
Step 3: 在 callback 中,攻击者再次调用 deposit()
→ 第二次触发 callback
→ 第三次 callback...
→ 共循环 22 次
Step 4: 每次循环 mint 一份 135 BRO 的收据
135 × 22 ≈ 2,970 BRO(但只存入了 135 BRO)
Step 5: 兑换所有 mint 出的 BRO 收据
→ 获得 2,970 BRO 价值的 SolvBTC
→ 实际等价约 $2.7M
Step 6: 赃款转入 Tornado Cash
时间: 攻击完成后约 40 分钟
MerkleClaw 追踪路径
链上特征识别(对应 RULE-RE-001 + RULE-RE-002):
触发信号:
✅ 同一函数选择器在单笔 tx 内调用 22 次(递归深度 22)
✅ BRO token mint 量:正常均值 ~10 BRO → 本次 2970 BRO(放大 297 倍)
✅ 调用者为新地址(<1周历史)
风险评分:
黑名单命中:0分(攻击时未入库)
行为特征:+11分(递归调用+大额mint+新地址)
混币器:+16分(攻击后 Tornado Cash 直接交互)
攻击后追踪:
0min 攻击完成,账本被抽空
40min 赃款进入 Tornado Cash 100 ETH Pool
4h MerkleClaw 自动将攻击者地址升级至 L2 黑名单
24h 与 Rekt.news 交叉验证,置信度升为 confirmed
资金流向图:
[攻击者合约 0xSolv...]
↓ $2.7M SolvBTC
[中转地址 × 3跳]
↓
[Tornado Cash 100 ETH Pool] ← 已进入混币,追踪中断
MerkleClaw 操作示例:
# 查询攻击者地址风险评分
python3 scripts/risk_scorer.py --address 0xSolvAttacker...
# 输出:87/100 🟠 HIGH | 混币器直接交互 +16分 | 行为异常 +11分
# 查询关联事件
python3 scripts/event_correlator.py --correlate INC-SolvBRO-001
# 输出:与 Stake Nova (AP-009 闪贷+逻辑漏洞) 相似度 50%
# 将攻击者地址添加至 L2 黑名单
python3 scripts/blacklist_manager.py \
--add-l2 0xSolvAttacker... \
--incident "Solv Protocol BRO Vault Exploit" \
--loss 2700000
关键教训
🦞 关键要点
- 未审计合约是最大风险因素:Solv BRO Vault 无审计、无 Bug Bounty,正常部署流程中任一步都能发现此漏洞
- "Check-Effect-Interaction" 模式:先更新状态,再触发外部调用——这是防重入的基础准则,此合约未遵守
- Tornado Cash 仍是首选出口:尽管 OFAC 制裁,攻击者依然在40分钟内使用,显示替代工具仍不成熟
案例二:YieldBlox Oracle 操纵 — 闪贷驱动价格拉升($10.97M)
案例背景
- 日期:2026年2月22日
- 协议:Script3 YieldBlox(Stellar 网络借贷协议)
- 损失:$10.97M
- 攻击链:Stellar
- 核心漏洞:Oracle 采信 DEX 单点价格,无防操纵机制
攻击手法拆解
漏洞根源:YieldBlox 使用 Stellar DEX 的即时价格作为 Oracle,未使用 TWAP(时间加权均价)。攻击者可以用相对小的资金操纵低流动性资产价格。
Step 1: 攻击者在 Stellar DEX 上大量买入 USTRY
USTRY 流动性极低($30万级)
买入操作使价格拉升 100 倍
USTRY 价格: $0.01 → $1.00(100x)
Step 2: 用被拉高价格的 USTRY 作为抵押品
在 YieldBlox 存入 USTRY
抵押品价值:Oracle 读到 $1.00
Step 3: 以虚高抵押品借出大量主流资产
借出:XLM / USDC / 其他资产
价值:$10.97M
Step 4: 还掉步骤1的买入操作(价格恢复)
USTRY 价格回到 $0.01
抵押品实际价值:$109,700
→ 协议形成 $10.87M 坏账
Step 5: 攻击者带走 $10.97M 主流资产
兑换后转出 Stellar 网络
MerkleClaw 追踪路径
链上特征识别(对应 RULE-ORC-001 + RULE-FL-002):
触发信号:
✅ USTRY 10分钟内价格涨幅:10,000%(100倍)
✅ USTRY 流动性:仅 $280,000(远低于 $500K 阈值)
✅ 同时段 YieldBlox 借贷量异常激增:+4,300%
✅ 价格在同一操作序列内恢复(操纵特征)
攻击模式匹配:
AP-003 Oracle价格操纵·低流动性资产拉升 → 相似度 100%
参考案例命中:与 Inverse Finance 操纵模式相似度 53%
组织画像匹配:
Flash Loan MEV Bot Operators → 57.1%
(单人操作,非APT组织,机会型攻击)
资金流向图:
[攻击者]
↓ 买入 USTRY(Stellar DEX)
[USTRY 价格 100x]
↓ 用虚高 USTRY 抵押
[YieldBlox 借出 $10.97M]
↓ 主流资产(XLM/USDC)
[Stellar 跨链转移]
↓
[目标地址] ← 最终追踪位置
MerkleClaw 操作示例:
# 检测 Oracle 异常(批量检查低流动性资产)
python3 scripts/monitor_loop.py --chain stellar --rule ORC-001
# 运行攻击模式匹配
python3 scripts/pattern_matcher.py \
--address <攻击者> \
--behaviors '{"dex_price_manipulation": true, "abnormal_price_multiplier": 100, "uses_flashloan": true}'
# 输出: 与 Oracle价格操纵·低流动性资产拉升 相似度 100% 🔴
# 关联查询:历史类似 Oracle 攻击
python3 scripts/event_correlator.py \
--correlate INC-YieldBlox-2026
# 输出: 与 Inverse Finance 相似度 58%(相同攻击类别+相近时间)
关键教训
🦞 关键要点
- 单点 Oracle = 单点故障:任何仅依赖单一 DEX 价格的 Oracle 都可以被操纵,无论是 $30万还是 $3亿流动性
- TWAP 是最低防线:时间加权均价(至少30分钟窗口)可以显著提高操纵成本
- 低流动性抵押品需要更严格的上限:协议应对低流动性资产设置独立的供应上限和借出系数
案例三:Inverse Finance DOLA — 价格操纵强制清算($240K)
案例背景
- 日期:2026年3月2日
- 协议:Inverse Finance(ETH 链借贷)
- 损失:$240,000
- 手法:DOLA 稳定币价格操纵 → 触发强制清算
- 规模:较小,但手法典型,属于"教科书级"操纵
攻击手法拆解
漏洞根源:DOLA 稳定币的 Oracle 可以被短暂影响,使协议错误触发正常仓位的清算。
Step 1: 获取资金(疑似使用闪贷)
借出大量 DOLA
Step 2: 在 DOLA/USDC 流动性池执行大额卖出
DOLA 价格短暂下跌($1.00 → ~$0.92)
Step 3: Inverse Finance Oracle 读到 DOLA 价格下跌
→ 认为以 DOLA 计价的抵押品"贬值"
→ 触发多个正常仓位的强制清算
Step 4: 攻击者作为清算者获得清算奖励
每次清算可获得 5-8% 的清算奖励
Step 5: 价格恢复(闪贷还款后)
攻击完成,净获利 $240K 清算奖励
MerkleClaw 追踪路径
链上特征识别(对应 RULE-ORC-002):
触发信号:
✅ 5分钟内 LiquidationCall 事件:14次(正常 < 1次)
✅ DOLA Oracle 报价:$0.92(市场价 $1.00,偏差 8%)
✅ 清算者为同一地址(攻击者自作清算者)
✅ 攻击前该地址无清算历史
风险评分:
行为特征:+8分(大额单笔tx + 高频清算操作)
攻击模式:AP-012 价格预言机闪贷操纵 → 相似度 80%
资金规模 vs 影响:
攻击成本:~$50K(Gas + 资金成本)
攻击收益:$240K(清算奖励)
ROI:约 380%,单次操作 < 30分钟
资金流向图:
[攻击者]
↓ 闪贷获取大量 DOLA
[DOLA 价格下跌]
↓ 触发14个仓位清算
[清算奖励 $240K → 攻击者]
↓ 还款闪贷,剩余净利
[攻击者地址] ← 资金留在链上(暂无混币记录)
MerkleClaw 操作示例:
# 查询攻击者组织匹配
python3 scripts/actor_matcher.py \
--demo flashloan # 使用闪贷套利演示案例
# 输出: Flash Loan MEV Bot Operators 57.1%
# 关联三起 Oracle 攻击
python3 scripts/event_correlator.py --correlate-all
# 输出: YieldBlox ↔ Inverse Finance 相似度 58%(相同类别+相近时间)
# Inverse Finance ↔ Moonwell 相似度 45%(Oracle系列)
关键教训
🦞 关键要点
- 清算机制是双刃剑:清算激励是必要的,但高清算奖励(>5%)本身就是可攻击的套利机会
- 稳定币的 Oracle 不等于稳定:即使是 DOLA 这类设计稳定的资产,其价格 Oracle 仍可被短期操纵
- 小损失≠低风险:$240K 看起来小,但同样的手法用更多资金可以放大10倍,需要认真对待
MerkleClaw 闪贷攻击追踪方法论总结
四步追踪流程
Step 1: 实时检测
监控规则(RULE-FL-001/RE-001/ORC-001)自动触发
→ 识别异常信号(闪贷量/递归调用/价格偏离)
Step 2: 攻击确认
获取 tx trace(Alchemy debug_traceTransaction)
→ 重建完整攻击调用链
Step 3: 资金追踪
追踪攻击者地址的后续转账
→ 识别混币器/跨链桥/中转地址
Step 4: 情报入库
自动写入 incidents_db.json
→ 触发 L2/L3 黑名单更新
→ 推送 Discord/桌面告警
→ 与历史事件做相关性分析
三个案例的共同规律
| 维度 | Solv (重入) | YieldBlox (Oracle) | Inverse (清算操纵) |
|---|---|---|---|
| 攻击前准备 | 部署恶意合约 | 积累资金头寸 | 闪贷准备 |
| 核心利用 | callback时序 | 单点Oracle | 清算奖励 |
| 执行时间 | < 1分钟 | < 5分钟 | < 30分钟 |
| 混币使用 | ✅ TC | ❌(部分追踪) | ❌(链上可见) |
| 可预防 | ✅ 审计必发现 | ✅ TWAP可防 | ✅ 清算设计可改 |
最重要的规律:三个案例中,漏洞均在上线前可以被发现。技术上没有一个是"0day",全部是已知风险模式的实例化。