フィッシングサイトはウォレットセキュリティアラートをどう回避するか:その戦略を解明

フィッシングサイトはウォレットセキュリティアラートをどう回避するか:その戦略を解明

概要

最近、Web3のフィッシングサイトが多数のユーザーに数十万ドルの損失をもたらしました。これらのフィッシングサイトでは、ユーザーは知らず知らずのうちに、トークンを詐欺師が管理するアカウントに送金することを承認するトランザクションに署名しています。フィッシング攻撃からユーザーを保護するために、多くのWeb3ウォレットは、既知のフィッシングアカウントが関与するトランザクションを積極的にブロックするブラックリストメカニズムを実装しています。

しかし、私たちの観察によると、この戦略はフィッシングアカウントのブロックに効果がないことが証明されています。詐欺師は、このセキュリティメカニズムを回避するためのいくつかの方法を開発しました。最初​​の方法は、Create2 関数を使用してフィッシングコントラクトのアドレスを予測し、トークンを盗んだ後にフィッシングコントラクトをデプロイすることです。2番目の方法は、ブラックリストの更新速度を上回るペースで、毎日新しいフィッシングコントラクトをデプロイすることです。

既存のウォレットセキュリティアラートメカニズム

フィッシングサイトに関するアラート
フィッシングサイトに関するアラート

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

セキュリティアラートのバイパスのためのCreate2の活用

EthereumのCreate2オペコードにより、コントラクトアドレスが実際にデプロイされる前に予測することが可能になります。これは、次の式を使用して達成されます。

address = hash(deployer address, bytecode, salt)

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

明らかに、デプロイメントアドレス、バイトコード、およびソルト値があれば、デプロイメント前にコントラクトアドレスを予測できます。フィッシングウェブサイトでは、ユーザーはCreate2を介して予測され、ブラックリストに載っていないEOA(Externally Owned Account)にETHを送信するか、トークンを承認するように促されます。その後、トークンの盗難が成功すると、フィッシングコントラクトがデプロイされ、被害者のトークンがさらに処理のために別のアカウントに転送されます。プロセス全体は自動的に行われます。

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
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.