Address poisoningとは？似た送金履歴・ゼロ送金・clipboard改ざんの確認手順

送金履歴に、いつもの取引先と先頭・末尾が同じaddressがあっても、そこから再送金しないでください。Address poisoningは、よく似たaddressを履歴へ混ぜ、利用者が次回それをコピーすることを狙います。ゼロ送金、少額送金、同じsymbolの偽token eventなど、履歴の作り方は一つではありません。

送金先の正本は履歴ではなく、取引先の公式invoice、事前に検証したaddress book、認証済みの連絡経路など、履歴から独立した情報です。 そこから得たfull addressとchainを固定し、tokenならcontractとTransfer event、最後に貼り付け後と署名画面を照合します。

この記事は、実wallet、被害者address、実資産、署名、transaction送信を使っていません。clipboard malwareや似たaddressの生成方法も実装しません。公開仕様と安全な合成データから、送金前の停止条件だけを整理します。

いま送金画面を開いているなら先に止める

次のどれか一つでも当てはまれば、Confirmや署名へ進まず画面を閉じます。

recipientをwalletやExplorerの履歴からコピーした
addressの先頭と末尾しか比較していない
chain名やchain IDを独立した依頼元と照合していない
token名・symbolだけを見てcontract addressを確認していない
copyしたfull addressとpaste後のfull addressが一文字でも違う
walletやhardware deviceの最終画面でrecipient全体を確認できない
DMの相手がseed phrase、private key、remote access、追加送金を求めている

少額test送金を先に済ませていても、この停止条件は変わりません。前回の一件が成功したことは、今回のclipboard、履歴、address book、送金画面が同じ値を保持している証明ではないからです。

4種類を同じ「怪しい履歴」にまとめない

履歴の一行だけでは、何が起きたかを決められません。まず表示の種類を分けます。

見え方	chain上・端末上で確認するもの	その行だけで言えないこと	送金前の判断
通常のnative / token transfer	chain ID、tx hash、full from / to、value。tokenならcontractとTransfer log	表示されたrecipientが今も意図した相手か	履歴からコピーせず、独立した正本へ戻る
zero-value transfer	token contract、Transfer eventのfrom / to / value、似たaddress	秘密鍵が漏れたこと、tokenを失ったこと、相手の本人性	履歴rowを宛先情報に使わない
同じsymbolの偽token event	eventを出したcontract、symbol、decimals、from / to / value	有名tokenと同じcontractであること、正規airdropであること	symbolではなくcontractから確認する
clipboard差し替え	copy元のfull value、paste後のfull value、最終確認画面	chain履歴だけから差し替え時点やmalwareを特定できること	一文字でも違えば署名前に停止する

ERC-20仕様ではvalueが0のtransferも通常のtransferとして扱い、Transfer eventを発生させます。したがって、ゼロのeventが存在すること自体は規格外ではありません。一方で、そのrowにあるaddressを次のrecipientとして信頼する理由にもなりません。

偽tokenは、正規tokenと同じnameやsymbolを表示できます。Explorerやwalletに「USDC」のような見慣れたsymbolがあっても、eventをemitしたcontractが違えば別tokenです。tokenのidentityは、対象chain上のcontract addressから確認します。

clipboard改ざんはchain外で起きます。copyした値がpaste時に変わっても、署名・broadcast前ならchain上のeventはありません。履歴を調べる前に、独立した正本とpaste後のfull valueを比較し、違えばそこで止めます。

確認順は「正本 → chain → full address → contract → event → 最終画面」

1. 履歴の外にあるrecipientの正本へ戻る

取引先の公式invoice、交換所やserviceがlogin後の公式画面で発行したdeposit address、事前に検証したaddress book、組織内の承認済み台帳などへ戻ります。検索結果、SNSの返信、未依頼DM、履歴rowは正本にしません。

address bookも、登録時の入手元が誤っていれば安全ではありません。登録日、chain、用途、承認者を確認できないentryは、履歴と同じく未検証として扱います。ENSなどの名前を使う場合も、解決後のchainとfull addressを最終確認します。

2. chainを名前とchain IDで固定する

同じ0x形式でも、Ethereum、Base、Arbitrumなどのstateは別です。invoiceやdeposit画面が示すnetworkと、walletで選択したchainをchain IDまで照合します。tokenの場合は、そのchain上のcontract addressも一組で保存します。

chainが違う、testnet / mainnetが不明、walletのcustom network情報を出所不明の相手から渡された場合は止めます。すでに別chainや別addressへ送った疑いがあるなら、新しい送金を作らず誤ったnetwork・addressの確認順へ進んでください。

3. full addressを全体で比較する

0x1234…abcdのような短縮表示は一覧を読む補助で、identityではありません。先頭4文字と末尾4文字が同じでも、中間32文字が違えば別addressです。MetaMaskも、address poisoningでは中間文字まで確認し、履歴からaddressをコピーしないよう案内しています。

EIP-55の大文字・小文字checksumは、入力誤りを検出しやすくするencodingです。checksumがvalidでも、そのaddressが意図した相手であることは証明しません。攻撃者側の別addressも、それ自身のvalidなchecksum表記を持てます。

比較するときは、次の3値を別々に表示します。

独立した正本から得たfull address
walletのrecipient欄へpasteされたfull address
署名直前にwalletまたはhardware deviceが示すfull address

三つが完全一致し、chainと用途も一致して初めて次へ進みます。見えない、途中が省略される、比較元が同じ端末の履歴しかない場合は停止します。

4. tokenはcontract addressを確認する

token transferでは、transactionのtoがrecipientではなくtoken contractになる場合があります。walletのasset名だけでなく、対象chain上のtoken contractを公式projectやserviceの独立した案内と照合します。

contractが違う、proxyやmigrationの関係が不明、symbolだけ同じ、未知tokenを「受け取ったから換金できる」と案内された場合はinteractionしません。偽token rowをhideすることと、そのtokenをswap・approve・transferすることは別の操作です。

5. transactionとTransfer eventを分けて読む

native transferならtransactionのfrom、to、valueを確認します。ERC-20なら、eventをemitしたcontractとTransfer(from, to, value)を確認します。Explorerのactivity一覧は複数種類をまとめる場合があるため、一覧の方向矢印やsymbolだけを証拠にしません。

確認対象	native asset	ERC-20 token
identity	chainのnative asset	chain + token contract
recipient	transactionの`to`	Transfer eventの`to`
amount	transactionの`value`	Transfer eventの`value`とtoken decimals
zero表示	0 valueのtxか別eventかを確認	仕様上zero-value Transfer eventがあり得る
履歴rowの限界	正しい相手の正本にはならない	symbolやrowだけではcontract identityを示さない

zero-value rowと同じsymbolの偽token rowは、似た表示でも根拠が異なります。一つの「spam判定」にまとめず、contractとevent fieldを保存してください。

6. paste後と最終確認画面をもう一度比較する

clipboardからwalletへ貼り付けた直後に、正本とfull valueを比較します。送金内容を編集した、別tabへ移動した、walletが再接続した、QRを読み直した場合も再比較します。

hardware walletを使う場合は、hostのPCやphoneではなくdevice自身の画面でrecipient、chain、amountを確認します。ただしdeviceに十分なfieldが出ないrequestを「hardware walletだから安全」として承認しません。機種ごとの表示境界はハードウェアウォレット5機種の公式仕様比較で整理しています。

小額test送金が証明する範囲

小額testは、特定時点の一回の送金が、特定chain・特定addressへ届いたかを確認する手段です。次のことまでは証明しません。

次回もclipboardが同じaddressを貼り付ける
履歴の最新rowがtest時のrecipientである
address bookが更新・差し替えされていない
同じsymbolのtoken contractが同じである
相手が今もそのaddressを管理し、今回の入金用途に使う
大きな送金が取引所のminimum、Memo・Tag、compliance条件を満たす

test後も毎回、独立した正本、chain、full address、token contract、paste後、device表示を確認します。履歴から「前に成功した行」を選び直すと、test送金を行った意味が失われます。

取引所入金が反映されない場合は、同じ送金を繰り返さず、TxID・confirmations・Memo・Tagの確認手順でchain上の成功とservice内の反映を分けてください。

walletやExplorerのwarningは補助であって正本ではない

MetaMaskは、過去のaddressと似て中間が異なるrecipientや、初めて使うrecipientにwarningを出すと案内しています。Etherscanも、zero-value transferや低評価tokenを非表示・警告する対策を説明しています。

これらは誤操作を減らす補助ですが、warningが出ないことを安全証明にはできません。wallet version、表示surface、chain、token、攻撃手法で検出範囲は変わります。反対にwarningが出たからといって、秘密鍵漏えいや資産損失が確定したわけでもありません。

判断は「警告あり／なし」ではなく、独立した正本とfull valueの一致へ戻します。

貼り付けた値が違う、または誤送金したとき

broadcast前なら署名しない

recipientが違う、clipboardの値が変わった、chainやcontractが不明ならConfirmしません。問題を調べるために同じ端末で新しいseed phrase、private key、password、2FA backup codeを表示・入力しないでください。

copy元、paste後の値、時刻、wallet / browser / OS version、導入済みextensionの入手元を、秘密を含めず保存します。端末のscanや隔離方法はOS・組織ごとに異なるため、使用中のOS vendorやsecurity担当者の公式手順へ引き継ぎます。

broadcast後なら追加送金を止めて証拠を固定する

次を一つのメモへ保存します。

tx hash、chain名、chain ID、block、status、日時とtimezone
full from / to、native value
tokenならcontract address、Transfer eventのfrom / to / value、decimals
独立した正本にあったrecipientと、実際に送ったrecipient
wallet、browser、OS、extensionのversionと確認時刻
相手やsupportを名乗る連絡のURL、account、要求内容

confirmed transactionをwallet providerが取り消したり、凍結・返金・回収を保証したりすることはできません。追加の「確認送金」「回収用gas」「解除料」を送りません。seed phraseやprivate keyを要求するDM、remote-control tool、screen sharing、先払い、必ず回収できるという案内は二次詐欺の停止条件です。

自分が作っていないtransaction、他chainでも続く動き、seed入力や不審extensionの事実がある場合は、原因をaddress poisoningだけに決めず、wallet侵害時に権限層を分ける初動ガイドでseed、approval、Permit、session、delegation、端末を切り分けてください。

組織・wallet UIの予防checklist

recipient masterを履歴と分離し、chain、用途、登録日、承認者を持つ
新規・変更addressは別経路で確認し、同じDM threadだけで承認しない
一覧の短縮addressからcopyできない、またはfull表示を先に開く設計にする
zero-value、unknown contract、同一symbol collisionを一つの通常履歴へ混ぜない
token名よりcontract addressを表示し、event emitterとrecipientを分ける
paste直後と署名前にfull-address comparisonを行う
high-value transferは複数人承認やallowlistを使い、履歴再利用を禁止する
warningをdismissした事実、source、chain、full recipientを監査logへ残す

最終checklist

Address poisoningへの最短の対策は、怪しいrowを完全に消すことではありません。履歴をrecipientの正本にせず、chainとfull addressを独立した情報へ戻し、token contract、event、paste後、最終確認画面を順に照合することです。

この記事にaffiliate、sponsor、回収serviceへの導線はありません。緊急時の確認手順と商業案内は分離します。