--- title: "Wallet drainer" description: "Un wallet drainer pousse l'utilisateur à signer un transfert ou une autorisation réutilisable. Cette fiche présente ses vecteurs, signaux d'alerte, limites et mesures d'urgence." 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. # Wallet drainer > À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement. Investir peut entraîner des pertes. ## Réponse directe Un **wallet drainer** est un kit ou scénario d'attaque qui présente un faux site ou une fausse application afin de faire autoriser un vol. Connecter un portefeuille ne lui donne pas, à lui seul, le contrôle. Le vol exige une action lourde de conséquences : révéler une phrase de récupération ou une clé privée, envoyer des actifs, signer une transaction ou signer un message conférant un pouvoir exploitable. Ce pouvoir peut être un transfert direct, une allowance ERC-20, un `permit` ERC-2612, une approbation ERC-721 ou un droit d'opérateur `setApprovalForAll`. L'attaquant peut agir immédiatement ou attendre de futurs actifs. « Drainer » désigne le scénario, pas un contrat, format de signature ou logiciel malveillant précis. ## Fonctionnement Le leurre imite généralement un airdrop, un mint, une migration, une alerte de compte, une assistance ou une dApp connue. Après exposition de l'adresse publique, la page inventorie les actifs et demande le pouvoir le plus utile. - Une transaction directe peut envoyer la monnaie native ou appeler un contrat malveillant. - ERC-20 `approve` autorise un spender à appeler `transferFrom` dans la limite accordée. - ERC-2612 `permit` crée une allowance quand un tiers soumet plus tard la signature on-chain ; le signataire ne paie pas nécessairement le gas d'exécution. - ERC-721 `approve` vise un NFT ; `setApprovalForAll` couvre tous les NFT du propriétaire dans la collection. - EIP-712 rend les champs structurés visibles et sépare les domaines, mais n'assure ni protection contre le rejeu ni conformité à l'intention. Le drainer soumet ensuite la signature ou emploie l'approbation, transfère les actifs accessibles, puis les échange ou les déplace souvent par bridge. Droits et soldes sont propres à chaque chaîne. Déconnecter le site ne révoque pas les droits on-chain et n'annule pas toutes les signatures en attente. ## Exemple Une fausse page de mint demande `setApprovalForAll`, alors que minter ne nécessite pas de gérer les NFT existants. En confirmant l'opérateur inconnu, l'utilisateur lui permet de transférer les NFT de la collection tant que le droit demeure. La page peut aussi demander un permit ERC-2612. Rien ne bouge à la signature, mais l'attaquant le soumet ensuite et appelle `transferFrom`. Fermer la page n'annule aucun droit. Il faut comparer intention et pouvoir : chaîne, contrat vérificateur, fonction, spender ou opérateur, adresse du token, montant ou portée, destinataire, nonce et échéance doivent tous correspondre à l'action voulue. ## Risques et contrôles - Ouvrir les applications depuis un domaine officiel vérifié indépendamment ou un favori ; publicité, message spontané, QR code et réponse d'assistance sont des entrées non fiables. - Lire la demande du portefeuille et l'écran de l'appareil fiable ; refuser données opaques, réseau inattendu, spender inconnu, montant illimité, droit d'opérateur large et action sans rapport. - Utiliser des droits limités et brefs, séparer les avoirs durables du portefeuille d'essai et contrôler les approbations sur chaque chaîne active. - Simulation et alertes sont des indices, non des garanties : l'état peut changer, le décodage être incomplet et un contrat authentique exercer un droit nuisible. - Un portefeuille matériel isole la clé, mais ne sécurise pas une demande malveillante confirmée par son propriétaire. Si la phrase ou la clé a fuité, créer sur un appareil fiable un nouveau portefeuille avec un nouveau secret et déplacer les actifs restants ; révoquer ne répare pas une clé compromise. Si seule une approbation ou signature est suspecte, vérifier la bonne chaîne, révoquer allowance ou opérateur via une interface fiable et déplacer les actifs si la signature en attente ne peut être invalidée sûrement. La révocation est une transaction on-chain qui peut perdre la course. Conserver domaine, messages, données signées, adresses, hachages et horodatages, puis les signaler. Ignorer les « récupérateurs » demandant secret, nouvelle signature ou avance. ## Idées reçues - **La connexion donne la garde au site.** Elle révèle normalement des adresses publiques et permet de proposer des demandes ; un acte supplémentaire confère le droit. - **Sans gas, aucun risque.** Un tiers peut exécuter un permit et payer le gas. - **EIP-712 ou un portefeuille matériel prouve la sûreté.** Ils améliorent lisibilité ou isolation, pas la fiabilité du spender, du contrat ou de l'intention. - **Déconnexion ou révocation unique clôt l'incident.** D'autres chaînes, tokens, opérateurs, signatures ou clés peuvent rester exposés. - **Révoquer restitue les actifs volés.** Cela limite l'usage futur après confirmation sans inverser les transferts achevés. ## Sujets connexes - [Hameçonnage crypto](/crypto/phishing-scam/) - [Approbation de portefeuille](/crypto/wallet-approval/) - [Signature de portefeuille](/crypto/wallet-signature/) - [Simulation de transaction](/crypto/transaction-simulation/) - [Signature typée EIP-712](/crypto/eip712-typed-signature/) - [Gestion des clés privées](/crypto/private-key-management/) ## Sources - [Ethereum security and scam prevention](https://ethereum.org/security/) - Ethereum.org (consulté le 2026-08-22) - [Signature phishing](https://support.metamask.io/stay-safe/protect-yourself/wallet-and-hardware/signature-phishing/) - MetaMask Help Center (consulté le 2026-08-22) - [How to revoke smart contract allowances and token approvals](https://support.metamask.io/more-web3/learn/how-to-revoke-smart-contract-allowances-token-approvals/) - MetaMask Help Center (consulté le 2026-08-22) - [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulté le 2026-08-22) - [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consulté le 2026-08-22) - [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (consulté le 2026-08-22) - [ERC-721: Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) - Ethereum Improvement Proposals (consulté le 2026-08-22) Source: https://wiki.fcontext.com/fr/crypto/wallet-drainer/index.mdx