--- title: "アドレスポイズニング" description: "アドレスポイズニングは、取引履歴など信頼できそうな画面に受取人の類似アドレスを紛れ込ませ、後の送金を攻撃者へ誘導する詐欺です。正規アドレスの改変や鍵の窃取ではなく、受取人確認の不備を突きます。" image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # アドレスポイズニング > 教育目的の情報であり、投資助言ではありません。誤ったアドレス宛てに署名した送金は取り消せない場合があり、凍結や回収も一切保証されません。 ## 要点 アドレスポイズニングは受取人をすり替える詐欺です。攻撃者は、画面に見える先頭と末尾が信頼済みの受取人に似た別アドレスを生成し、取引履歴など信頼できそうな画面へ紛れ込ませます。後日、送金者がその類似アドレスをコピーし、そこへの有効な支払いに署名することを狙います。正規アドレスの改変、秘密鍵の解読、コンセンサスによる誤配送ではありません。 植え付けられる記録は、実際のネイティブ資産取引、標準準拠のゼロ数量トークン送付、または別のトークンコントラクトが発したログから生じ得ます。ウォレットやエクスプローラーのアクティビティ画面は派生ビューです。「送信」と表示された行が、画面上の `from` アドレスによる外側の取引署名ではなく、イベントフィールドに由来する場合があります。外側の取引の送信者と宛先、呼び出されたコントラクト、イベント発行コントラクト、indexed フィールド、実際の残高変化を分けて確認します。 ERC-55 チェックサムは一部の偶発的な入力ミスを検出しますが、攻撃者の別アドレスも構文上有効で、正しいチェックサムを持てます。通常の 20 バイト EVM アドレスだけでは、対象チェーン、資産、受取人の役割、入金メモ、コントラクト呼び出しも特定できません。安全な支払指図は、これらすべてを完全な宛先に結び付けます。 ## 仕組み 攻撃者は公開された支払パターンを観察し、ウォレットが省略表示する文字列に一致する vanity アドレスを探索します。選んだ16進文字が一致しても口座が複製されるわけではありません。見えないバイトは異なり、新しい鍵は攻撃者が管理します。微小な送付で、その実在するアドレスを履歴に載せられます。一方、ERC-20 はゼロ数量の送付を通常の送付として扱い `Transfer` を発行するよう求めるため、ゼロ数量の記録だけでは偽造、侵害、承認、経済損失の証拠になりません。 悪意あるトークンコントラクトは、独自に `Transfer(victim, lookalike, 0)` ログを発行することもできます。このログは発行元コントラクトに帰属する本物のレシートデータですが、正規資産コントラクトのイベントではなく、被害者が外側の取引に署名した証拠でもありません。それでも、コントラクトや呼び出しの文脈を十分に確認せずイベントトピックだけで分類するインデクサーは、誤解を招く送信行を表示し得ます。 決定的な管理対象は最終的な支払意図です。チェーンとネットワーク、ネイティブ資産または正確なトークンコントラクト、完全な受取アドレス、受取人種別、数量と raw unit、calldata、メモ、destination tag、有効期間を結び付けます。取引所の入金アドレス、ブリッジ、プロキシ、一回限りのルートは失効する場合があり、アドレス以外の情報を必要とすることもあります。クリップボード型マルウェアや改ざん QR コードは別攻撃ですが、署名前の完全な宛先確認で同じすり替えを検出できます。 名前とテスト送金は補助策であり、本人確認ではありません。署名時に対象チェーン向けの ENS 名を解決して記録し、逆引き名が表示された場合は同じアドレスへ正引きできることを確認します。少額テストが有効なのは、受取人が独立に着金確認し、本送金が同じ固定済み宛先を再利用する場合だけです。履歴から再コピーすれば、その保護は失われます。 次の手順を使います。 1. 認証済みの独立情報源から、チェーン、ネットワーク、資産と正確なトークンコントラクト、受取人種別、アドレス形式、数量、メモ、タグ、calldata、版、有効期限を固定する。 2. 名前または QR コードは一度だけ解決し、形式とチェックサムを検証して完全な宛先バイトを対象チェーンへ結び付ける。逆引き名は正引き確認し、ラベルを身元証明として扱わない。 3. 取引履歴ではなく、管理された許可リスト、アドレス帳、署名済み請求書と照合する。新規または重要な変更には独立確認か二者承認を求める。 4. 未署名取引そのものをデコードする。ネイティブ資産の `to` とトークンまたはブリッジコントラクトを区別し、calldata の受取人、トークン、raw 数量、承認、期限、宛先の意味を確認する。 5. 必要に応じて固定済み宛先へ少額テストを送り、受取人から独立した確認を得る。本送金用アドレスを履歴から再コピーしない。 6. 検証済み記録だけから本送金に署名し、信頼できる表示装置で完全な宛先と数量を比較する。その後、正しいチェーンでレシート、発行コントラクト、ログ、残高差分を確認する。 7. ポイズニングまたは誤送金が疑われる場合は後続支払を止め、ハッシュと証拠を保存し、必要に応じて受取サービス、発行者、捜査機関へ速やかに連絡する。凍結、返還、回収は条件付きであり、保証ではない。 ## 例 - **省略表示が差異を隠す。** 正規の `0x12ab1111111111111111111111111111111189ef` と攻撃者の `0x12ab9999999999999999999999999999999989ef` は、どちらも `0x12ab...89ef` と表示されます。表示される16進文字は `4 + 4 = 8` 個共通しますが、中間の `32` 文字はすべて異なります。表示された両端だけなら誤一致しますが、全バイト比較なら一致しません。 - **vanity 探索の作業量。** 選んだ16進文字 `k = 8` 個を合わせる期待作業量は `16^8 = 4,294,967,296` 候補です。仮定速度 `50,000,000 candidates/s` なら期待時間は `4,294,967,296 / 50,000,000 = 85.89934592 s` です。これは探索空間の例であり、実行時間やウォレット警告基準の保証ではありません。 - **ログと状態。** トークンコントラクトが `Transfer(victim, lookalike, 0)` を発行します。被害者の残高は `250,000.000000` から `250,000.000000` へ移り、差分は `0.000000` ですが、アクティビティインデックスには送付行が表示され得ます。発行コントラクトと呼び出し承認を確認してください。この行だけでは価値移転も被害者の署名も証明できません。 - **テストでは宛先を固定する。** 資金管理者が `50,000 USDC` を支払う際、検証済みアドレスへ `1 USDC` を送り、独立した確認後に同じ固定済み記録から `49,999 USDC` を送れば、`1 + 49,999 = 50,000 USDC` です。第2回分に履歴の類似アドレスを再コピーすれば、テストはその `49,999 USDC` を保護しません。 ## リスク - 送金者が汚染された取引履歴から類似アドレスをコピーする。 - 省略表示が異なる中間文字を隠す。 - vanity の接頭辞や接尾辞を受取人の身元と誤認する。 - ゼロ数量の ERC-20 送付が誤解を招く履歴行を作る。 - 偽装トークンやそのログを正規資産の活動と誤認する。 - インデクサーがイベントフィールドを誤分類するか、訂正が遅れる。 - スパムトークンの名称、シンボル、アイコンが信頼済み資産を装う。 - クリップボード型マルウェアが署名前に検証済みアドレスを置換する。 - ローカルまたは同期済みアドレス帳が汚染されるか古くなる。 - 許可リストが誤ったチェーン、資産、役割、アドレス版を結び付ける。 - 無効または欠落したチェックサム警告が無視される。 - 有効なチェックサムを受取人の身元証明と誤認する。 - ENS 解決結果が変わる、誤った coin type を使う、または古くなる。 - 逆引き名を正引き確認せず表示する。 - 少額テスト後に信頼できない情報源から再コピーする。 - 取引所の入金アドレス、ネットワーク、メモ、タグが誤っているか失効する。 - ブリッジ、プロキシ、コントラクト宛先と必要な calldata を誤解する。 - ハードウェア機器上でも省略文字列だけを確認する。 - 介入前に誤った受取人への取引が正規チェーンに確定する。 - 発行者の裁量的な凍結に依存するか、回収詐欺に遭う。 ## よくある誤解 - **アドレスポイズニングはウォレット、鍵、ブロックチェーンの侵害を意味する。** 通常は受取人選択を突く攻撃で、有効な暗号とコンセンサスが誤って署名された意図を実行します。 - **ゼロ数量の行は偽のオンチェーン取引に違いない。** 標準準拠の送付や実在ログにもゼロ数量はあります。発行元と状態への影響を確認します。 - **両端の一致とチェックサムで受取人を証明できる。** 別の有効アドレスも可視文字に一致し、独自の有効なチェックサムを持てます。 - **一度テストに成功すれば次の送金も自動的に守られる。** 本送金が固定、確認済みの宛先を再利用しなければ保護は失われます。 - **ウォレット、バリデーター、発行者は常に送金を取り消せる。** 回収権限と協力は、資産、サービス、法域、証拠、時機によって異なります。 ## 関連トピック - [フィッシング詐欺](/ja/crypto/phishing-scam/) - [トランザクションシミュレーション](/ja/crypto/transaction-simulation/) - [暗号資産ウォレット](/ja/crypto/wallet/) ## 出典 - [Address poisoning scams](https://support.metamask.io/stay-safe/protect-yourself/wallet-and-hardware/address-poisoning-scams/) - MetaMask Help Center（参照日：2026-08-13） - [Anatomy of an Address Poisoning Scam](https://www.chainalysis.com/blog/address-poisoning-scam/) - Chainalysis（参照日：2026-08-13） - [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals（参照日：2026-08-13） - [ERC-55: Mixed-case checksum address encoding](https://eips.ethereum.org/EIPS/eip-55) - Ethereum Improvement Proposals（参照日：2026-08-13） - [Transactions](https://ethereum.org/en/developers/docs/transactions/) - ethereum.org（参照日：2026-08-13） - [Resolution](https://docs.ens.domains/resolution/) - ENS Documentation（参照日：2026-08-13） - [Frequently asked questions](https://ethereum.org/en/community/support/faq/) - ethereum.org（参照日：2026-08-13） - [USDC Terms](https://www.circle.com/legal/usdc-terms) - Circle（参照日：2026-08-13） Source: https://wiki.fcontext.com/ja/crypto/address-poisoning/index.mdx