時間と戦略との戦い:AnySwap復旧とその教訓

時間と戦略との戦い:AnySwap復旧とその教訓

1月18日、当社の監視システムはAnySwapプロジェクト(別名Multichain)に対する攻撃を検出しました。この脆弱性は、anySwapOutUnderlyingWithPermit()関数の不備に起因するもので、その検証メカニズムを迂回して承認済みのトークンを引き出すことが可能でした。

プロジェクトは影響を受けたユーザーに通知するために様々なアプローチ(図1に示すように、ユーザーにトランザクションを送信するなど)を採用しましたが、多くのユーザーは資金を保護するためにタイムリーな対応(承認の取り消しなど)をとれませんでした。その結果、攻撃者は継続的に攻撃を仕掛け、被害者の資金を奪うことができました。

図1: プロジェクトはEthereumメッセージを通じて被害者に通知しました
図1: プロジェクトはEthereumメッセージを通じて被害者に通知しました

潜在的な被害者を保護するため、当社チームは慎重な検討の結果、Ethereum上のAnySwap脆弱性コントラクト(0x6b7a87899490EcE95443e979cA9485CBE7E71522)に対して緊急救済を実行することを決定しました。具体的には、脆弱なアカウントの資金を、Ethereum上のマルチシグウォレット(0xd186540FbCc460f6a3A9e705DC6d2406cBcc1C47)であるホワイトハットウォレットに移管することができます。

ホワイトハット救済を透明化するため、我々はPDFファイルにその意向を文書化し、ファイルハッシュをコミュニティと共有しました。これにより、緊急救済を攻撃と区別しつつ、脆弱性がまだ悪用される可能性があるため詳細を漏洩しないようにしました。我々は2022年1月21日から2022年3月11日まで緊急救済を実施し、対応するメッセージを公開しました。以下の通りです。

図2: 救済実施の告知
図2: 救済実施の告知
図3: 救済停止の告知
図3: 救済停止の告知

緊急救済は簡単な作業ではありません。実際、成功した救済には技術的および非技術的な課題がいくつか存在します。緊急救済は既に終了したため、プロセス全体を包括的にレビューし、学んだ教訓を共有することができます。この経験がDeFiエコシステムのセキュリティに光明をもたらすと信じています。

主なテイクアウェイ(TL;DR)

  • ホワイトハットと攻撃者を含む様々な参加者間の競争が存在します。Flashbotsの支払い手数料は時間とともに急速に増加しました。
  • Flashbotsは常に機能するわけではありませんでした。代わりに、一部の攻撃者は洗練された戦略を採用して、通常のメモリプールを使用して攻撃を成功させました。
  • 一部の攻撃者は、盗まれた資金の一部を返却し、残りを報奨金として保持することで、ホワイトウォッシュされました。この現象は、初めてではありませんが、このようなインセンティブは実際のホワイトハットにとって公平ではない可能性があるため、コミュニティでは物議を醸しています。
  • コミュニティを説得するためには、ホワイトハットが詳細な機密情報を漏洩することなく、事前に行動を公表することが良い方法です
  • コミュニティは協力して、より効果的かつ効率的に救済を実行することができます。例えば、ホワイトハット間の競争を減らす/回避するための調整メカニズムを構築するなどです。

以下では、まずこの期間中の救済の全体像を示します。次に、救済の実施方法と解決すべき課題を説明します。その後、救済から学んだ教訓について議論します。最後に、エコシステムのセキュリティに役立つ可能性のあるいくつかの考え/提案を提供します。

0x1 救済と攻撃

0x1.1 全体結果

本レポートで観測・調査した攻撃と救済は、ブロック14028474(2022年1月18日)からブロック14421215(2022年3月20日)まで、数ヶ月にわたって行われました。

救済と攻撃を実行したアカウントを以下の表にまとめます。簡潔にするため、EOAを表すためにアドレスの最初の4ビットのみを示します。 アカウントは、救済アカウントまたは攻撃アカウントのいずれかです。アカウントの種類は、Etherscan.ioによってマークされたラベル、または観測された転送先アドレスのいずれかによって決定されることに注意してください。

合計で9つの救済アカウントが483.027693 ETH(手数料295.970554 ETH、総額の61.27%)を救済し、21の攻撃アカウントが1433.092224 ETH(手数料148.903707 ETH、総額の10.39%)を収穫しました。一部の複雑な相互作用により、損失はおおよその推定値であることに注意してください。例えば、攻撃アカウントがAnySwapと交渉した後に救済アカウントになる可能性があり、この現象については後で議論します。表の最後の列は、Flashbotsの使用競争に勝つために使用されたマイナーへの手数料を示しています。

No. アカウント タイプ 被害者数 損失額 (ETH) 手数料 (ETH)
1 0x14ca** 救済アカウント 50 432.958062 287.849654
2 0x9a65** 救済アカウント 23 22.569429 0.000000
3 0x9117** 救済アカウント 14 18.897622 7.213585
4 0x17d2** 救済アカウント 3 3.552833 0.000000
5 0x6360** 救済アカウント 21 3.540061 0.907168
6 0x0edd** 救済アカウント 7 1.498706 0.000000
7 0x281e** 救済アカウント 1 0.006000 0.000000
8 0xd83b** 救済アカウント 1 0.004000 0.000000
9 0x8af3** 救済アカウント 6 0.000980 0.000147
10 0x4986** 攻撃アカウント 332 456.004547 0.000000
11 0xfa27** 攻撃アカウント 42 433.438935 46.636389
12 0x48e9** 攻撃アカウント 66 312.014657 0.000000
13 0x5738** 攻撃アカウント 67 83.589240 62.587238
14 0x34b2** 攻撃アカウント 7 63.599821 20.642705
15 0xd374** 攻撃アカウント 86 45.452703 12.824763
16 0x1fe7** 攻撃アカウント 9 12.817241 0.000000
17 0x98f5** 攻撃アカウント 20 8.381273 0.000000
18 0x455d** 攻撃アカウント 11 5.047377 0.544263
19 0x1b45** 攻撃アカウント 6 4.942442 3.074813
20 0x3ec7** 攻撃アカウント 6 3.705686 0.741137
21 0xbca4** 攻撃アカウント 1 2.784250 1.392125
22 0xb0ab** 攻撃アカウント 18 0.834068 0.296000
23 0x0a5b** 攻撃アカウント 1 0.286750 0.143375
24 0x2d3a** 攻撃アカウント 2 0.080090 0.000000
25 0x835d** 攻撃アカウント 5 0.063945 0.000000
26 0x1dbd** 攻撃アカウント 1 0.027431 0.012893
27 0x813d** 攻撃アカウント 1 0.019528 0.008007
28 0x85dd** 攻撃アカウント 6 0.002240 0.000000
29 0x2394** 攻撃アカウント 1 0.000000 0.000000
30 0x6360** 攻撃アカウント 2 0.000000 0.000000

0x1.2 Flashbots入札のための手数料のトレンド

前述したように、ホワイトハットはトランザクションを送信するために攻撃者と競争する必要があります。その結果、マイナーへの手数料の割合(Flashbotsトランザクションの場合)は競争のレベルを反映している可能性があります。これを定量的に測定するために、各ブロックの手数料の割合(攻撃トランザクションと救済トランザクションそれぞれ)を調査します。

図4は、これまでに観測されたトレンド(ブロック14028474からブロック14369199まで)を示しています。 最初のいくつかの攻撃トランザクションには手数料はかかりませんでした。これは、その期間の競争がほとんど(あるいは全く)なかったことを意味します。これは、これらの初期の攻撃が他の人にあまり知られていなかった可能性があるため、合理的です。

事実、手数料(10%)がかかった最初の攻撃はブロック14029765で発生しました。 それ以来、より多くの参加者が関与するにつれて、手数料の割合は急速に増加しました。 例えば、ブロック14072385では割合が80%に達し、すぐにブロック14129449では91%に達しました。

要するに、このトレンドは、マイナーへの手数料をより多く調整することで競争に勝つための軍拡競争であることを示唆しています。

図4: 攻撃と救済の手数料の割合
図4: 攻撃と救済の手数料の割合

0x2 当社の救済と課題

0x2.1 救済の実施方法

救済の基本アイデアは非常に単純です。具体的には、脆弱なコントラクトにWETHを承認したアカウントを監視する必要があります。WETHがアカウントに転送されると、脆弱なAnySwapコントラクトを悪用して、それをマルチシグウォレットに直接転送できます。主な要件は以下の通りです。

  • R1: 被害者アカウントにトークンを転送するトランザクションを効率的に特定すること。以下では、これらのトランザクションを転送TXと呼びます。
  • R2: 救済を実行するためのトランザクションを正確に作成すること。以下では、これらのトランザクションを救済TXと呼びます。
  • R3: 攻撃者(およびその他の第三者)が送信したトランザクションを首尾よくフロントランニングすること。以下では、これらのトランザクションを攻撃TXと呼びます。

R1とR2は私たちにとって障害ではありません。具体的には、メモリプールの監視システムを構築しており、転送トランザクションをタイムリーに特定できます。また、トランザクションを自動的に構築するツールも開発しました。

しかし、R3は依然として課題です。競争に勝つためにFlashbotsを使用できると期待するかもしれません。しかし、目標を達成するのはそれほど簡単ではありません。まず、攻撃者もFlashbotsを採用する可能性があります。手数料入札システムとして、成功率はマイナーに指定された手数料に依存する可能性があります。手数料の設定戦略を決定する必要があります。次に、Flashbotsの使用は激しい競争のために良い選択ではないかもしれません。したがって、メモリプールを使用して通常のトランザクションも送信します。成功を保証するために、トランザクションを正しい位置に配置する戦略を考慮する必要があります。最後に、他のホワイトハットとも競合し、それらの行動は時々疑わしいように見えました。

0x2.2 参加した競争

合計で171件の潜在的な被害者を保護しようと試みましたが、そのうち10件は、救済を実行しようとする直前に承認を取り消すことで自己保護しました。残りの161件の有効な被害者については、競争のために14件しか成功しませんでした。失敗したケースは、3つの救済アカウントと16の攻撃アカウントが関与した以下の表にまとめられています。

No. アカウント タイプ 被害者数 損失額 (ETH) 手数料 (ETH) 平均手数料率
1 0x14ca** 救済アカウント 44 431.651020 286.891724 66.46%
2 0x9a65** 救済アカウント 7 11.321441 0.000000 0.00%
3 0x6360** 救済アカウント 3 3.300000 0.891000 27.00%
4 0x48e9** 攻撃アカウント 35 301.681589 0.000000 0.00%
5 0x5738** 攻撃アカウント 58 78.482472 58.851862 74.99%
6 0x34b2** 攻撃アカウント 2 53.591712 17.685265 33.00%
7 0xd374** 攻撃アカウント 6 23.658698 10.073638 42.58%
8 0x4986** 攻撃アカウント 16 22.900105 0.000000 0.00%
9 0x1fe7** 攻撃アカウント 6 12.057241 0.000000 0.00%
10 0x1b45** 攻撃アカウント 5 4.402442 3.010013 68.37%
11 0xbca4** 攻撃アカウント 1 2.784250 1.392125 50.00%
12 0x98f5** 攻撃アカウント 8 2.339543 0.000000 0.00%
13 0x455d** 攻撃アカウント 3 0.741817 0.175454 23.65%
14 0xfa27** 攻撃アカウント 3 0.320288 0.032590 10.18%
15 0x0a5b** 攻撃アカウント 1 0.286750 0.143375 50.00%
16 0x3ec7** 攻撃アカウント 1 0.245000 0.049000 20.00%
17 0xee7e** 攻撃アカウント 1 0.190000 0.096900 51.00%
18 0x835d** 攻撃アカウント 3 0.024533 0.000000 0.00%
19 0xb0ab** 攻撃アカウント 1 0.000618 0.000000 0.00%

したがって、共有すべき教訓がいくつか存在します。

0x3 学んだ教訓

0x3.1 Flashbotsマイナーへの手数料の決定方法?

要約すると、私たちは12人の競合相手(2つの救済アカウントと10の攻撃アカウント)に敗れました。彼らはFlashbotsを使用していました。

マイナー手数料の設定戦略は非常に保守的でした。具体的には、可能な限り少ない手数料で被害者を保護することを目指しました。したがって、成功した攻撃TXがすでに手数料を設定している場合を除き、積極的に手数料を使用/増加させることはありませんでした。例えば、攻撃者が手数料を資金の10%に設定した場合、私たちは次の救済で11%を使用してその攻撃者と競争するかもしれません。 しかし、結果は、攻撃者(あるいはホワイトハットでさえ)がしばしば(常にではないにしても)他者に勝つために手数料を積極的に増加させたため、この戦略は機能しなかったことを示唆しています。

  • 図5は、攻撃者0x5738**がブロック14071986で手数料を70%に設定したことを示しています。
  • 図6は、ホワイトハット0x14ca**がブロック14072255で手数料を79%に設定したことを示しています。
  • 図7は、ホワイトハット0x14ca**がブロック14072385で手数料を80%に設定したことを示しています。
  • 図8は、ホワイトハット0x9117**がブロック14072417で手数料を81%に設定したことを示しています。
  • 図9は、攻撃者0x5738**がブロック14073395で手数料を86%に設定したことを示しています。
図5: 攻撃者0x5738**による70%の手数料
図5: 攻撃者0x5738**による70%の手数料
<center>図6: ホワイトハット0x14ca**による79%の手数料</center>
図6: ホワイトハット0x14ca**による79%の手数料
<center>図7: ホワイトハット0x14ca**による80%の手数料</center>
図7: ホワイトハット0x14ca**による80%の手数料
<center>図8: ホワイトハット0x9117**による81%の手数料</center>
図8: ホワイトハット0x9117**による81%の手数料
<center>図9: 攻撃者0x5738**による86%の手数料</center>
図9: 攻撃者0x5738**による86%の手数料

要するに、競争に勝つためには、様々な参加者の行動をモデル化する必要があるゼロサムゲームのようです。

しかし、実際には、より良い/最適な戦略を見つけ、同時にコストを可能な限り削減することは困難です。

0x3.2 メモリプールでの正しい位置にトランザクションを配置するには?

現在、救済はFlashbotsの入札手数料競争の軍拡競争に依存しているようです。 しかし、私たちは、他の参加者からの激しい競争のために、Flashbotsの使用は万能薬ではなかったことを見出しました。このような場合、攻撃TXが指定した最高手数料であっても、Flashbotsの使用機会を確実に獲得することはできませんでした。

代わりに、適切な位置にある通常のトランザクションが目標を達成する機会を持つ可能性があります。適切な位置とは、救済/攻撃TXが転送TXの後ろの位置に配置され、転送TXに非常に近い位置(近いほど良い)にあることを意味します。この戦略を使用することで、攻撃者0x48e9**はFlashbotsマイナーに手数料を支払うことなく312.014657 ETHを収穫したことに注意してください。

以下の4つの図は、攻撃者が得た最大の利益トップ2を示しています。

  • 図10は、被害者がブロック14051020の65番目の位置に50 ETHを預けたことを示しており、図11は、攻撃者が同じブロックの66番目の位置で50 ETHを収穫したことを示しています。
  • 図12は、被害者がブロック14052155の161番目の位置に200 ETHを預けたことを示しており、図13は、攻撃者が同じブロックの164番目の位置で200 ETHを収穫したことを示しています。
<center>図10: 被害者0x3acb**によって送信された65番目の位置の転送TX</center>
図10: 被害者0x3acb**によって送信された65番目の位置の転送TX
<center>図11: 攻撃者0x48e9**によって送信された66番目の位置の攻撃TX</center>
図11: 攻撃者0x48e9**によって送信された66番目の位置の攻撃TX
<center>図12: 被害者0xbea9**によって送信された161番目の位置の転送TX</center>
図12: 被害者0xbea9**によって送信された161番目の位置の転送TX
<center>図13: 攻撃者0x48e9**によって送信された164番目の位置の攻撃TX</center>
図13: 攻撃者0x48e9**によって送信された164番目の位置の攻撃TX

明らかに、この洗練された戦略は非常に有用で啓発的であり、そこから学ぶためにより多くの注目と努力に値します。

0x4 その他の考察

0x4.1 ホワイトハットハックか攻撃か?

ホワイトハットハックの認識に関しては、予想されるほど単純ではないかもしれません。

例えば、アドレス0xfa27はEtherscan.ioによってMultichain Exploiter 4 (Whitehat)とラベル付けされていました。実際、当初はMultichain Exploiter 4とラベル付けされていました。攻撃者とAnySwapプロジェクトの間で数回の交渉が行われた後、攻撃者は盗まれた資金の一部を返却するように説得されました。

  • TX 0x3c3d**では、AnySwapが攻撃者に連絡しました。

まず、wethを入手してくれてありがとう。ハックに気づいていなかったのですが、cowswapトランザクションの後もwethが私のウォレットに届かなかったので状況を認識しました。リスクの額を考慮して、公正なチップとして50 ethを受け入れていただけますか? これが私のトランザクションです: 0x2db9a6a51604e2be8b2c3469773afb201f0b48a318fb7e5f5e49175e818df5ba 0xe50ed602bd916fc304d53c4fed236698b71691a95774ff0aeeb74b699c6227f7

  • TX 0xd360**では、攻撃者は次のように返信しました。

トランザクションを送信して確認してください。残りの258 ethを送ります。39 ethはマイナーに渡りました。他の攻撃者がいたため、そのチップを支払って資金を節約する必要がありました。

  • TX 0x354f**では、AnySwapは資金を受け取った後、感謝の意を表明しました。

確かに受け取りました。正直さに感謝します。

明らかに、この攻撃者はホワイトウォッシュされ、攻撃から利益も得ました。 同様のケースは過去に数回発生しており、このようなインセンティブは公平ではない可能性があるため、コミュニティでは依然として物議を醸しています。

0x4.2 ホワイトハットハック間の競争?

ホワイトハット間の競争を減らす/回避するための調整メカニズムを構築することが必要です。そのような競争は必然的に救済力の無駄につながります。 この救済では、私たちも救済を実行しようとしていた間、他の3人のホワイトハットによって保護された54人の被害者(4億5000万ETHの資金)が存在しました。

ホワイトハット間の競争は、救済力の無駄遣いだけでなく、救済のコストも増加させました。例えば、図7と図8に示すように、異なるホワイトハットによる2つの救済TXによって費やされた手数料は、それぞれ80%と81%でした。

残念ながら、調整メカニズムが存在しない限り、ホワイトハットは後退しません。そうでなければ、競争をなくすことは不可能です。

0x4.3 より良い救済を行うには

一方、コミュニティを説得するためには、ホワイトハットが詳細な機密情報を漏洩することなく、事前に行動を公表することが良い方法です。 救済は通常、複数の試行を伴うシーソーゲームであり、特定の攻撃をブロックするような一度限りの努力とは異なるため、これを行うには十分な時間があります。もちろん、脆弱性に関する詳細情報は開示されるべきではありません。

これを達成するために、詳細情報は最初には開示されず、AnySwap救済で行ったように、救済完了後にコミュニティに開示されます。ただし、ホワイトハットの意向を示す文書のハッシュはコミュニティと共有できます。

他方、コミュニティは、救済をより効果的かつ効率的に実行するために、さらに多くのことができます。これには以下が含まれますが、これらに限定されません。

  • Flashbots/マイナーは、認定ホワイトハットにグリーンチャンネルを提供する可能性があります。グリーンチャンネルは、攻撃者のTXをフロントランニングするための高い優先度を提供し、ホワイトハット間の競争を回避できます。
  • 攻撃されているプロジェクトは、Flashbots/マイナーのコストをカバーします。
  • プロジェクトは、ユーザーへの便利で高速な通知メカニズムを適用する可能性があります。
  • プロジェクトは、コードに緊急メカニズムを適用する可能性があります。

BlockSecについて

BlockSecは、世界的に著名なセキュリティ専門家グループによって2021年に設立された、先駆的なブロックチェーンセキュリティ企業です。同社は、Web3の台頭を促進するために、新興のWeb3の世界のセキュリティとユーザビリティの向上に尽力しています。この目的のために、BlockSecはスマートコントラクトおよびEVMチェーンのセキュリティ監査サービス、セキュリティ開発と脅威のプロアクティブなブロックのためのPhalconプラットフォーム、資金追跡と調査のためのMetaSleuthプラットフォーム、そしてWeb3ビルダーが暗号世界を効率的にサーフィンするためのMetaSuites拡張機能を提供しています。

現在までに、同社はMetaMask、Uniswap Foundation、Compound、Forta、PancakeSwapなど300以上の著名なクライアントにサービスを提供し、Matrix Partners、Vitalbridge Capital、Fenbushi Capitalといった有力な投資家から2回の資金調達で数千万米ドルを受け入れています。

公式ウェブサイト:https://blocksec.com/

公式Twitterアカウント:https://twitter.com/BlockSecTeam

Sign up for the latest updates
Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

During the week of February 9 to February 15, 2026, three blockchain security incidents were reported with total losses of ~$657K. All incidents occurred on the BNB Smart Chain and involved flawed business logic in DeFi token contracts. The primary causes included an unchecked balance withdrawal from an intermediary contract that allowed donation-based inflation of a liquidity addition targeted by a sandwich attack, a post-swap deflationary clawback that returned sold tokens to the caller while draining pool reserves to create a repeatable price-manipulation primitive, and a token transfer override that burned tokens directly from a Uniswap V2 pair's balance and force-synced reserves within the same transaction to artificially inflate the token price.

Top 10 "Awesome" Security Incidents in 2025

Top 10 "Awesome" Security Incidents in 2025

To help the community learn from what happened, BlockSec selected ten incidents that stood out most this year. These cases were chosen not only for the scale of loss, but also for the distinct techniques involved, the unexpected twists in execution, and the new or underexplored attack surfaces they revealed.

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

On August 29, 2025, Panoptic disclosed a Cantina bounty finding and confirmed that, with support from Cantina and Seal911, it executed a rescue operation on August 25 to secure roughly $400K in funds. The issue stemmed from a flaw in Panoptic’s position fingerprint calculation algorithm, which could have enabled incorrect position identification and downstream fund risk.