3MIKAN
仮想通貨直コン

ウォレットが侵害されたかも?seed・approval・session・delegationを切り分ける初動ガイド

不審なwallet activityを見つけた直後に追加操作を止め、証拠を保存し、seed・private key、approval、Permit、session、EIP-7702 delegation、端末侵害を切り分ける初動ガイドです。

3MIKANのブランドキャラクターが、seed・approval・session・delegation・端末を表す別々の鍵箱を停止trayと証拠封筒の前で初動確認する記事画像

「walletが侵害された」と感じても、最初に原因を一つへ決めないでください。追加の署名・送金・接続を止め、秘密を含まない証拠を保存し、seed / private key、token権限、署名、session、delegation、端末のどこが疑われるかを分けるのが初動です。

Disconnectだけでon-chain approvalは消えません。approvalをrevokeしても、漏れたseed phraseやprivate keyは安全に戻りません。この記事は回収手順ではなく、追加被害と二次詐欺を避けながら、公式supportやsecurity担当者へ渡せる状態を作るためのread-onlyガイドです。

実被害wallet、個人account、実資産、seed phrase、private key、raw signatureは検証に使っていません。wallet接続、署名、transaction、revoke、資産移動も行っていません。

最初に止める7つの行動

原因が分からない間は、次の操作を止めます。

  1. 突然開いた署名、transaction、approvalをConfirmしない
  2. DM、検索広告、返信欄から届いたlinkを開かない
  3. 「確認」「同期」「取消」「復旧」のためにseed phraseやprivate keyを入力しない
  4. raw signature、password、2FA backup code、本人確認書類を公開issueやSNSへ貼らない
  5. 見知らぬ相手へscreen sharingやremote-control toolの導入を許可しない
  6. 「回収用gas」「解除料」「保証金」という先払いをしない
  7. sweeperの疑いがあるaccountへ、自己判断で追加gasを送らない

MetaMaskの公式supportは未依頼のDMをせず、電話supportを提供せず、Secret Recovery Phraseを要求しないと案内しています。連絡先はDMのprofileや検索結果ではなく、自分で開いたwallet・serviceの公式siteから確認してください。

秘密を含めず、事実を固定する

browserやwalletの表示を操作する前に、次を保存します。URLは履歴から文字列を控え、不審siteを確認のために開き直しません。

保存する項目 公開共有の境界
公開address 0x…、smart-account address public chain上の値。ただしaccountとの本人関係は必要先にだけ共有
chain chain名とchain ID 名前だけでなくchain IDを保存
transaction tx hash、status、block、日時とtimezone explorer URLよりhashを優先。未確定・失敗・成功を分ける
関係address fromto、recipient、spender、delegate、token contract 役割を決めつけず、addressと見えたfieldを保存
call / event method selector、transfer / transferFrom、Approval event、input data 解析結果とraw inputを分ける。raw signatureは保存先を限定し公開しない
authority state allowance、account code、owner / threshold、module、session expiry chain、block、確認時刻を一緒に残す
local environment wallet / extension、browser、OS、appのversion extensionの入手元、更新日時、見覚えのない変更も記録
接触履歴 URL、DM sender、support ticket ID、先払い要求 screenshotはseed、key、password、個人情報を隠す

seed phraseとprivate keyは「証拠」としてsupportへ送らないでください。画面共有で見せる、写真を添付する、cloud noteへ置くことも避けます。Ethereum.orgはrecovery phraseをwallet全体のmaster key、private keyを対応accountの操作権限として説明しており、正規supportが要求する情報ではありません。

見覚えのないtxではなく、自分の送信先・network選択を誤った可能性がある場合は、侵害と決めつけず誤network・誤addressをtx statusから確認するガイドでbroadcast前、pending、confirmed-failed、confirmed-successを先に分けます。

追加操作を止め、証拠を保存してから7つの権限・端末層へ分ける初動確認を、3MIKANのキャラクターと7区画の保管棚で示した図

7つの候補層を同じ表で分ける

一つのincidentで複数層が同時に関係する場合があります。この表は診断ではなく、追加確認先を決めるための入口です。

候補層 保存するsignal 最初の境界 そのsignalだけでは分からないこと
seed / private key 自分が作っていないdirect tx、複数account / chainの動き、secret入力・file保存・remote accessの履歴 署名権限そのものを疑い、疑わしい端末で新しい秘密を作らない unauthorized tx一件だけでは漏えい経路を確定できない
ERC-20 approval transferFrom、owner、spender、token、allowance、Approval event dapp接続とon-chain allowanceを別に見る Disconnectしてもallowanceが消えた証拠にはならない
Permit / Permit2 typed-data request、owner、spender、value、nonce、deadline、Permit2 contract 未提出署名はchainに見えない場合がある。raw signatureを公開しない 全tokenに共通する取消方法はなく、token / protocolのnonce実装が必要
dapp / WalletConnect session origin、account、chain、methods、session topic、expiry session終了とon-chain権限を分ける Disconnectはapproval、permit、delegationの解消を証明しない
EIP-7702 delegation account code、delegate、authorization tx、chain ID、nonce delegate codeとallowance / storage / sessionを別に見る code clearだけで他stateが消えたとは言えない
smart-account authority owners、threshold、modules、guards、fallback handler、session key wallet固有のauthority構成として確認 token approval一覧だけではmodule権限を確認できない
device / browser extension入手元・version、OS / browser更新、remote access、clipboard異常、email / SIM alert chain外の認証・端末incidentとして分ける browser変更だけでは既存authorityの封じ込めを証明できない

seed phrase・private key侵害の候補

自分が作っていないnative transferやcontract callが、account自身をfromとして成立している場合は、seed / private key、悪意ある署名、端末上のwallet操作、automationなどを候補にします。複数accountや複数chainで近い時刻に動きがあっても、それだけで漏えい経路までは確定できません。

secretを偽siteへ入力した、写真・cloud sync・平文fileへ保存した、偽extensionを導入した、第三者へremote accessを許可した、という事実があれば、その時刻と端末を公式supportやsecurity担当者へ伝えます。秘密そのものは渡しません。

MetaMaskの侵害時guideは、別のbrowser / profile / deviceで新しいwalletを用意し、残る資産を移すdamage-limitationを案内する一方、sweeperが疑われるaccountへgasを追加しないよう注意しています。これは時間、端末、asset、account設計で結果が変わるprovider固有の案内です。本記事だけを根拠に一律の移動手順を実行せず、公式supportまたは信頼できるsecurity担当者へ緊急性を伝えて個別に判断してください。

既にconfirmedになったchain transactionをwallet providerが取り消したり、失われた資産を必ず復元したりすることはできません。新しいwalletを作ることも、古いauthority、token approval、delegation、dapp sessionが自動で消えた証拠にはなりません。

ERC-20 approvalとPermitを分ける

ERC-20のallowance(owner, spender)は、ownerに代わってspenderが使える残量です。transferFromが見える場合は、token contract、owner、spender、amount、直前のApproval eventとallowanceを同じchain・blockへ対応させます。

siteからDisconnectする操作は、通常はaddress共有やdapp connectionの境界です。on-chain allowanceを変更するrevokeとは別です。さらにrevokeはtransactionであり、特定spenderのallowanceを変えるだけなので、漏れたseed phraseやprivate keyを安全なものへ戻しません。approvalの確認項目はMetaMaskのtoken approvalを安全に確認するガイドへ分けています。

ERC-2612 Permitはownerspendervaluenoncedeadlineへ署名し、仕様上は第三者が提出できます。署名がまだ提出されていなければ、chain上のtransactionやallowanceだけでは見つからない場合があります。ERC-2612は全token共通の「未提出署名を取消す」操作を定義していないため、token contract、nonce、deadline、使用済みstateを個別に確認します。

Permit2では、token contractからPermit2へのapprovalと、Permit2内のAllowanceTransferまたはSignatureTransferを別の層として保存します。「一回の署名」「gasなし」という表示だけで権限が小さいとは判断しません。署名requestのfieldと、raw signatureを公開しない理由はwallet署名要求の見分け方で確認できます。

dapp sessionはon-chain権限ではない

WalletConnectのsessionは、topicに対応するchains、methods、events、accountsを含み、disconnectまたはexpiryまでdappとwalletの通信を結びます。sessionを終了すればその接続経路は止められますが、token allowance、提出済みPermit、EIP-7702 delegation、application側login sessionまで消えた証拠にはなりません。

保存するのは、dapp origin、session topic、account、chain、許可method、作成・更新・expiry時刻です。session controlを操作する場合も、検索結果やDMのtoolではなく、使用しているwalletまたはdappの公式画面・docsへ自分で戻ります。

EIP-7702 delegationとsmart-account authority

EIP-7702ではEOA codeが0xef0100 || addressというdelegation indicatorを持ち、delegate codeを実行入口にできます。不審なactivityでは、対象accountのcode、delegate address、authorizationを含むtransaction、chain ID、authority nonceを保存します。

delegationをclearしたように見えても、contract storage、ERC-20 allowance、Permit2 permission、dapp sessionが消えたとは限りません。delegateがproxyなら、codeの役割が将来変わる可能性もあります。read-onlyで確認するstateと残存境界はEIP-7702 delegation lifecycleガイドへ分けています。

Safeのようなsmart accountでは、ownersとthreshold、modules、guards、fallback handler、session keyが別のauthority層になり得ます。Safe公式docsは、moduleが通常のowner確認とは別のexecution pathを提供し、悪意あるmoduleがSafeをtake overし得ると注意しています。token approvalだけを見て「権限は全部正常」と判断せず、wallet固有の公式docsとsecurity reviewerへ構成snapshotを渡してください。

device・browser・email・SIMをchain外の層として扱う

見覚えのないextension、非公式storeからのinstall、clipboardのaddress差し替え、remote-control tool、OS / browserの不自然な変更、emailやSIMのsecurity alertは、chain外の候補です。端末の電源断や初期化を一律に勧めると証拠を失う場合があるため、時刻、version、入手元、alert、接触履歴を先に記録します。

不審なtransactionはなく、送金履歴の似たaddress、zero-value transfer、同一symbolのtoken row、copy / paste後の不一致を見つけた段階なら、Address poisoningの送金前確認手順で履歴、contract、event、端末の境界を先に分けます。

疑わしい端末で新しいseed phrase、password、2FA backup codeを作成・表示しません。別環境を使う必要がある場合も、「別だから安全」と自己判定せず、wallet provider、device / OS vendor、組織のsecurity担当者など、対象に合う公式窓口の案内に従います。

incident対応が終わった後に平時のaccount loginを見直す場合は、物理Security KeyのFIDO2・NFC・復旧設計で、primaryとspareの別登録、recovery code、失ったkeyの削除を確認してください。購入や登録を緊急対応の途中へ混ぜず、既存sessionや権限の確認とは別工程にします。

公式窓口へ渡すevidence package

問い合わせは、目的ごとに分けます。

窓口 渡す情報 期待してはいけないこと
wallet / dapp公式support public address、chain、tx hash、時刻、origin、wallet / app version、見えたrequest chain transactionの取消、必ずの回収、seed / keyの受領
custodial exchange / service deposit / withdrawal ID、chain、tx hash、destination、account内時刻、公式ticket ID 即時凍結、返金、相手情報の開示を保証しない
security担当者 incident timeline、authority snapshot、device / extension情報、公開chain evidence 証拠なしの断定、保証付きrescue、秘密の提出
警察相談 被害・接触の時系列、tx / payment evidence、DM / URL、相手の要求、添付可能な資料 凍結、追跡、逮捕、返金、解決時期を保証しない

日本では警察庁のサイバー事案相談窓口から、都道府県警察を選び、相談・通報・情報提供とfile添付へ進めます。これは相談経路の案内であり、資産の凍結、返金、回収、捜査結果を約束するものではありません。緊急性や身の安全に関わる場合は、該当する公的緊急窓口を使ってください。

二次詐欺のred flag

未依頼DM、seed / private keyの要求、remote-control tool、screen sharing、先払い、成功報酬を装う追加gas、必ず回収できるという断定、公式に似せたdomainは停止条件です。相手が「急がないと消える」と言っても、秘密や資産を渡さず、公式siteから別経路で確認します。

最終checklist

  • 追加署名、未知site、DM、remote access、先払いを止めた
  • public address、chain ID、tx hash、時刻とtimezone、関係addressを保存した
  • seed phrase、private key、raw signature、password、2FA codeを公開・送信していない
  • direct txとtransferFrom、approvalとPermit、sessionとon-chain権限を分けた
  • account code、delegate、smart-account owners / modulesをapproval一覧と分けた
  • device / browser / email / SIMのsignalをchain上の証拠と分けた
  • 公式siteから目的に合うsupportへ入り、ticket IDを保存した
  • 回収、凍結、返金、追跡、解決時期を保証する相手を信用していない

このchecklistを終えても「安全になった」とは断定できません。どの権限層が疑われ、何が未確認かを明示して、security reviewerへ引き継ぐところまでが初動です。

確認した一次情報