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
約160万ドルの損失:MokeトークンとLpdFiへの攻撃 | BlockSec週次レポート
Security Insights

約160万ドルの損失:MokeトークンとLpdFiへの攻撃 | BlockSec週次レポート

2026年8月3〜9日の週、BNBチェーンで2件の重大なセキュリティインシデントが発生し、いずれも価格操作により総損失は約160万ドルに上った。LpdFi事件(約69.7万ドル)では、注文評価と利息償還の両方に同じ操作可能なPancakeSwapペアのリザーブが使用され、攻撃者がポジションの元本を水増しし過大な利息を請求した。Mokeトークン(約90.6万ドル)では、操作可能なスポット価格とLP配当の重複計上を組み合わせ、MOKEを水増し請求してBNB配当を複数回取得した。

COLDCARDの事件:ウォレットの「ランダム」シードがランダムではなかった時
Security Insights

COLDCARDの事件:ウォレットの「ランダム」シードがランダムではなかった時

COLDCARDファームウェアのビルド・統合バグにより、Bitcoin種生成がソフトウェアRNGフォールバックに誘導され、脆弱な乱数によりウォレットの秘密鍵がオフラインで復元可能となった。欠陥は種自体にあるためファームウェア更新では修正不可。2026年8月7日までに確認された被害は1,405 BTC(約91億円)、非公式推定では最大2,055 BTCに上る。

〜8800万ドルの損失:COLDCARDとLULAのエクスプロイト|BlockSec週次レポート
Security Insights

〜8800万ドルの損失:COLDCARDとLULAのエクスプロイト|BlockSec週次レポート

2026年7月27日〜8月2日、BitcoinとBNBチェーンで計約8800万ドルの損失をもたらす2件のインシデントが発生。COLDCARDではファームウェアのエントロピー障害により、RNG設定マクロの有効性ではなく存在のみを確認するビルドガードが決定論的なソフトウェアフォールバックへシード生成を誘導。攻撃者は少なくとも1,370 BTC(約8800万ドル)を窃取。BNBチェーンのLULAトークンでは、攻撃者が特権的な`recycle()`関数を呼び出し、PancakeSwap V2のペアからLULAを引き出して流動性を枯渇させ、約57.8万ドルの損失が発生。

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