Back to Blog

フィッシングサイトはいかにしてウォレットのセキュリティ警告を回避するのか:その手法を解剖する

May 10, 2024
4 min read

概要

近年、Web3フィッシングサイトは、多くのユーザーに対して合計数百万ドル規模の損失をもたらしています。これらのフィッシングサイトにおいて、ユーザーは知らぬ間に、自身のトークンを詐欺師が管理するアカウントへ転送することを許可するトランザクションに署名させられています。フィッシング攻撃からユーザーを保護するため、多くのWeb3ウォレットは、既知のフィッシングアカウントに関連するトランザクションを積極的にブロックするブラックリストメカニズムを実装してきました。

しかし、我々の観察によると、この戦略はフィッシングアカウントのブロックにおいて効果的ではないことが判明しています。詐欺師はこのセキュリティメカニズムを回避するためにいくつかの手法を開発しました。第一の手法は、Create2関数を使用してフィッシングコントラクトのアドレスを予測し、トークンの盗難に成功した後にフィッシングコントラクトをデプロイするというものです。第二の手法は、ブラックリストの更新頻度を上回るペースで、毎日新しいフィッシングコントラクトをデプロイするというものです。

既存のウォレットセキュリティ警告メカニズム

フィッシングサイトに関する警告
フィッシングサイトに関する警告

ウォレット内のセキュリティ警告メカニズムには、ウェブサイトとアカウントの両方のチェックが含まれています。現在、すべてのシステムにおいて、ウェブサイトのドメインとアカウントに関するブラックリストが維持されています。ユーザーがウェブサイトにアクセスすると、ウォレットはそのドメインがブラックリストに載っているかどうかを確認します。もし載っていれば、そのウェブサイトへのアクセスは拒否されます。同様に、ユーザーがトランザクションに署名する前に、ウォレットはトランザクションに介在するアカウントがブラックリストに載っていないかを確認します。もし載っていれば、ユーザーが手続きを進めないようにトランザクションはブロックされます。これらのセキュリティ機能は、MetaMaskのようなシステムによって例示されます。

Create2を活用したセキュリティ警告の回避

イーサリアムの Create2 オペコードを使用すると、コントラクトを実際にデプロイする前にアドレスを予測することが可能です。これは以下の式を使用して実現されます:

address = hash(deployer address, bytecode, salt)

デプロイヤーの署名、コントラクトのバイトコード、そして指定されたソルト値があれば、事前にコントラクトアドレスを特定することが可能になります。

当然ながら、デプロイヤーのアドレス、バイトコード、ソルト値があれば、デプロイ前にコントラクトアドレスを予測できます。フィッシングサイトでは、ユーザーはETHの送信またはトークンの承認を、外部所有アカウント(EOA)に対して行うよう促されます。このEOAは Create2 を通じて予測されたものであり、ブラックリストには含まれていません。その後、トークンの盗難に成功した時点でフィッシングコントラクトがデプロイされ、被害者のトークンがさらなる処理のために別のアカウントへ転送されます。このプロセス全体が自動的に行われます。

Phalcon Explorerによって実証された事例を以下に示します:

フィッシングサイトは最初、0x0ddbへのトークン承認をユーザーに要求します。その後、詐欺師がフィッシングトランザクションを開始します。これには2つの内部トランザクションが含まれています。最初の内部トランザクションは、Create2を使用してフィッシングコントラクトをデプロイします。2番目の内部トランザクションは、そのフィッシングコントラクトを呼び出し、被害者のトークンを転送します。

セキュリティ警告を回避するためのフィッシングコントラクトの頻繁なデプロイ

フィッシングコントラクトのデプロイからブラックリストが更新されるまでのわずかな時間差を突くことで、詐欺師はセキュリティ警告を回避しています。彼らは毎日新しいフィッシングコントラクトをデプロイすることでこれを実現しています。その結果、ユーザーがフィッシングサイトにアクセスした際、これらのコントラクトはまだブラックリストに登録されていないため、一部のウォレットでの警告をすり抜けてしまいます。

Phalcon Explorerで解説されているPink Drainerの事例を以下に示します。0x5d77のDeploy関数が毎日呼び出され、新しいフィッシングコントラクトがデプロイされています。

まとめ

フィッシングサイトの開発者は、Web3ウォレットが採用しているセキュリティ検知メカニズムを回避するために、絶えず新しい戦略を編み出しています。我々は引き続き警戒を怠らず、彼らの最新の手口を継続的に監視していきます。ユーザーの皆様には、細心の注意を払い、トランザクションに署名する前に詳細を慎重に確認することを強く推奨します。

関連資料


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
ニュースレター - 2026年6月
Security Insights

ニュースレター - 2026年6月

本月報は2026年6月の主要セキュリティインシデント3件を対象とし、確認済み損失総額は約2,200万ドルです。高度なハニーポット攻撃がトークン許可の未検証を悪用し、JaredFromSubwayのMEVボットから約1,500万ドルを流出。旧型Aztecロールアップ2件はプルーフ決済の境界ギャップにより約435万ドルを損失。SecondFiのEd25519実装欠陥により374ウォレットの秘密鍵が露出し約240万ドルが流出。3件に共通するのは、表面上は保たれているように見えたセキュリティ保証が実際には機能していなかった点です。

約400万ドルの損失:TaikoとSecondFiのエクスプロイト|BlockSec週次レポート
Security Insights

約400万ドルの損失:TaikoとSecondFiのエクスプロイト|BlockSec週次レポート

2026年6月22〜28日のブロックチェーンセキュリティ報告:EthereumとCardanoで約410万ドルの損失を確認。Taikoブリッジ攻撃はSGX署名鍵の露出と不完全なアテステーションポリシーを悪用し、悪意のあるプルーバー登録とL2状態証明の偽造を可能にした。SecondFiはEd25519ナンス導出の欠陥により、公開Cardanoトランザクションから秘密鍵の復元が可能となった。

〜1800万ドルの損失:jaredFromSubway、Aztecなど|BlockSecウィークリー
Security Insights

〜1800万ドルの損失:jaredFromSubway、Aztecなど|BlockSecウィークリー

ブロックチェーンセキュリティ週次レポート(2026年6月15日〜21日):EthereumとBNB Chainで3件の重大インシデントが発生し、総損失約1830万ドル。注目のjaredFromSubway事件では、MEVボットが裁定取引のために自身の資産を未検証の第三者コントラクトに承認するという逆承認攻撃が判明。攻撃者は実イベントを発行しながら承認を消費しない偽トークンとプールを構築し、損失は約1500万ドル。またAztecでは3日間で2度目の攻撃が発生、エスケープハッチZK回路でold_data_rootの等価制約欠如を悪用し、偽マークルツリーに対するノート所有権の証明が可能となった。