Comment les voleurs de portefeuilles vident les comptes

Les siphonneurs de portefeuille fonctionnent en récoltant une autorisation réutilisable du portefeuille d'une victime, puis en utilisant cette permission pour déplacer des tokens, des NFTs et parfois des pièces natives sans demander à nouveau. La chaîne applique ces approbations signées et ces autorisations de type données comme des instructions valides, donc le vol se présente souvent comme une activité DeFi normale plutôt que comme un « hack ».

Points clés

• Un siphonneur de portefeuille réussit généralement sans une phrase de récupération en amenant la victime à signer une approbation ERC-20 , une approbation d'opérateur NFT , ou une signature de type données de style permis.
• L'escroquerie est généralement en deux étapes : capture de permission d'abord, puis un balayage automatisé immédiatement ou plus tard en utilisant des fonctions comme transferFrom ou setApprovalForAll.
• Le phishing par signature est souvent plus dangereux qu'il n'y paraît, car les signatures de données saisies peuvent être transformées en approbations on-chain après coup.
• Les drainages passent fréquemment par des canaux légitimes.DEXdes routeurs afin que la trace on-chain ressemble à un échange normal, ce qui retarde la détection et la réponse.

Les siphonneurs de portefeuilles et les bases du phishing d'approbation

Le truc principal est simple : l'attaquant n'a pas besoin de casser la cryptographie du portefeuille si la victime peut être convaincue d'autoriser l'attaquant en tant que dépensier. C'est pourquoi un draineur de portefeuille se trouve à l'intérieur de l'expérience utilisateur DeFi normale, et non à l'extérieur. La victime connecte un portefeuille, voit une invite familière et signe quelque chose qui semble routinier.

La blockchain fait alors ce pour quoi elle est conçue, c'est-à-dire faire respecter l'autorisation exactement comme signée.

C'est pourquoi le phishing par approbation est le bon modèle mental. L'attaquant ne "se connecte" pas en tant que victime. L'attaquant obtient une autorisation que le protocole reconnaît, puis l'utilise comme une ligne de crédit permanente.

Le rapport de campagne de FinanceFeeds sur le draineur de Trust Wallet indique clairement que ces flux peuvent vider des portefeuilles "la seconde où un utilisateur clique sur approuver", et que les mécanismes reflètent une utilisation légitime de la DeFi plutôt qu'un malware ou une exploitation.

Une distinction utile pour les lecteurs venant de la sécurité Web2 est qu'un portefeuille peut être "compromis" dans le sens où il peut être vidé sans leclé privéesans jamais quitter l'appareil. CryptoAdventure le présente comme un consentement : l'utilisateur signe, la chaîne valide, l'attaquant transfère. C'est aussi pourquoi "J'utilise un portefeuille matériel" n'est pas une défense complète.

FinanceFeeds note que les portefeuilles matériels réduisent le risque de vol de clé privée, mais ils ne préviennent pas les drains approuvés par l'utilisateur si ce dernier signe la mauvaise approbation.

Cette explication s'inscrit dans le sujet plus large des arnaques aux portefeuilles crypto et comment les éviter, car la défense repose principalement sur l'hygiène des autorisations, et non sur un antivirus.

Le flux d'attaque de connexion et d'approbation

Le chemin de drainage le plus probable est d'abord un problème de distribution et un problème de smart contracten second.

FinanceFeeds décrit un plan en cinq étapes lié à l'avis national sur la cybercriminalité de l'Inde TAU/ADV/013 : usurpation d'identité DM sur Telegram, Discord ou X, un site cloné, une invite de connexion de portefeuille via WalletConnect ou un navigateur intégré au portefeuille, une seule approbation, puis un balayage automatisé.

Le démontage de Blockaid ajoute un autre vecteur de distribution qui importe pour les traders qui agissent rapidement : le détournement de l'interface utilisateur, où l'UI d'un site légitime est remplacée par une version malveillante.

De bout en bout, le flux est généralement :

1. Attirer l'utilisateur vers un domaine similaire ou un front-end détourné. L'appât est souvent « vérifier », « réclamer » ou « airdrop», et il est conçu pour créer un sentiment d'urgence. 2. Forcer la connexion du portefeuille tôt. Blockaid a observé une page où n'importe quel bouton déclenchait la boîte de dialogue de connexion, ce qui est un indicateur comportemental courant. 3. Collecter le contexte du portefeuille.

Blockaid montre le drainer communiquant avec l'infrastructure de commande et de contrôle et utilisant des lectures JSON-RPC comme eth_call pour apprendre quels assetset l'état nonce qu'il peut cibler. 4. Récoltez la permission. C'est le moment où la victime pense qu'elle fait quelque chose d'inoffensif, comme approuver un token pour un échange, ou « signer un message ». 5. Exécutez le balayage.

FinanceFeeds décrit « balaie tout en quelques secondes », et Coca souligne que le drain peut être retardé, ce qui est la raison pour laquelle les victimes sont confuses quant à l'action qui a causé la perte.

L'angle « drainer en tant que service » est important car il explique pourquoi ces flux semblent modélisés. Coca décrit les drainers comme des kits vendus aux escrocs, et cet emballage est la raison pour laquelle les mêmes modèles d'UX se répètent à travers les chaînes et les portefeuilles.

Les drainers de permissions abusent de la chaîne

Les allocations ERC-20 sont le cheval de bataille. Une dApp normale demande une approbation afin de pouvoir déplacer des tokens au nom de l'utilisateur lors d'un échange ou d'un dépôt. Un drainer crypto demande la même approbation, mais dirige le dépensier vers un contrat contrôlé par un attaquant ou adresseet pousse souvent un plafond illimité.

Une fois que cette approbation existe, l'attaquant peut revenir plus tard et déplacer des tokens en utilisant transferFrom sans aucune nouvelle invite pour la victime. FinanceFeeds et Coca soulignent tous deux que les approbations illimitées sont le levier qui rend cela évolutif.

Le modèle de drain retardé est celui où les gens diagnostiquent mal ce qui s'est passé. Coca décrit la séquence où un utilisateur approuve aujourd'hui, ne voit aucun mouvement immédiat, puis recharge le portefeuille plus tard et se fait drainer en quelques secondes parce que l'approbation en cours était déjà en place.

C'est pourquoi la bonne façon de lire une approbation n'est pas « de l'argent est-il parti tout de suite », mais « qui viens-je d'autoriser à retirer de l'argent plus tard ».

Les NFTs ont leur propre version du même piège. FinanceFeeds et Coca pointent tous deux vers setApprovalForAll, qui accorde à un opérateur la capacité de déplacer tous les NFTs d'une collection pour ce portefeuille. Les utilisateurs traitent souvent cela comme une étape unique pour lister ou frapper. Pour un drainer, c'est une clé maîtresse pour cette collection.

Deux implications pratiques en découlent :

1. L'avantage de l'attaquant est la persistance. Une seule approbation peut rester valide jusqu'à révocation. 2. L'avantage de la victime est la réversibilité des permissions. FinanceFeeds et Coca pointent tous deux vers des outils comme Revoke.cash et le vérificateur d'approbation de token d'Etherscan pour examiner et révoquer les allocations et les approbations d'opérateurs.

C'est également ici que le terme "wallet drainer" devrait être expliqué : ce n'est pas un contrat magique qui "casse" les portefeuilles. C'est une automatisation qui abuse des rails de permission exacts sur lesquels repose le DeFi.

Draineurs basés sur des signatures et pièges à autorisations

Les pop-ups les plus coûteux sont souvent ceux qui ne ressemblent pas à des transactions. L'analyse de Blockaid du 2024-10-13 montre un drainer utilisant eth_signTypedData_v4 pour capturer une signature de données typées EIP-712 qui encode un permis EIP-2612.

Le drainer a d'abord rassemblé le nonce et les métadonnées du jeton via eth_call, puis a incité la victime à signer des données structurées qui autorisaient un dépensier pour une valeur très élevée. Le point clé est que la signature est hors chaîne au moment où la victime la signe, mais elle peut être soumise sur chaîne plus tard via la fonction de permis du jeton.

C'est du phishing par signature dans sa forme la plus pure. La victime pense "Je n'ai pas envoyé de transaction." L'attaquant pense "Je viens d'obtenir une approbation que je peux exécuter quand je veux."

Les drapeaux Coca signalent les risques de signature de type permit et Permit2 comme faisant partie des kits de drainage modernes, et CryptoAdventure les regroupe en tant que drainers basés sur des signatures distincts des drainers d'approbation classiques sur la chaîne.

Blockaid a également observé wallet_switchEthereumChain dans le même flux, forçant un changement vers Arbitrum One même si la page se faisait passer pour unBNBAirdrop de chaîne. Cette demande de changement de chaîne n'est pas cosmétique. C'est un moyen de cibler le réseau où la victime détient réellement des actifs.

Deux conséquences sont importantes pour les utilisateurs :

1. Les signatures de données typées peuvent être plus difficiles à comprendre qu'une invite d'approbation sur la chaîne car elles se présentent comme « signer un message ». Blockaid soutient que la plupart des portefeuilles ne peuvent pas simuler ces signatures hors chaîne de la manière dont ils peuvent simuler des transactions sur chaîne. 2. L'attaquant peut séparer la capture de permission de l'exécution.

Cette flexibilité temporelle est la raison pour laquelle les drainers peuvent attendre des moments de faibles frais ou que le portefeuille soit rechargé.

C'est aussi pourquoi la signature aveugle est un mode de défaillance récurrent. Si l'interface du portefeuille ne montre pas clairement ce que les données saisies autorisent, l'utilisateur signe effectivement dans l'ignorance.

Pourquoi les drains ressemblent à une activité normale

Un opérateur de drain veut que la chaîne ait l'air ennuyeuse. Blockaid montre un drain d'actif natif routé à travers un contrat de routeur SushiSwap légitime, appelant swapETHForExactTokens, plutôt qu'un transfert direct de ETH vers une adresse d'attaquant. Le point n'est pas que SushiSwap est compromis. Le point est que le routage à travers un routeur largement utilisé fait ressembler la transaction à un comportement d'échange de routine.

FinanceFeeds fait la même observation du point de vue de la victime : Darktrace a suivi une variante qui a drainé 470 000 $ d'une seule victime en deux minutes, et la transaction on-chain "ne ressemble pas à un échange de routine de Uniswap." C'est la couche de camouflage. Si le vol ressemble à un échange, les observateurs occasionnels et même certaines heuristiques automatisées perdent du temps.

C'est ici que la thèse prend tout son sens : l'autorisation est le produit. Une fois que l'attaquant a une allocation valide, une approbation d'opérateur ou une signature de permis, la blockchain l'exécutera fidèlement plus tard, rapidement, et d'une manière qui peut être routée à travers des contrats légitimes.

Pour les traders et les utilisateurs avancés, la leçon opérationnelle est que "détecter le vol on-chain" est une défense faible. Au moment où un drain ressemblant à un échange est visible, les actifs ont déjà été déplacés et souvent déjà échangés contre des tokens plus liquides.

Le moment à signal plus élevé est plus tôt, à la frontière de permission : des invites de changement de chaîne inattendues, des dialogues de connexion répétés, et un site qui pousse les approbations avant de faire quoi que ce soit d'utile.

Comment réduire le risque de drain

La défense consiste principalement à réduire l'autorité qu'un seul clic peut accorder et à diminuer la valeur qui se cache derrière cette autorité. FinanceFeeds recommande de commencer par le panneau « Sites connectés » ou « Autorisations » du portefeuille pour révoquer tout ce qui n'est pas utilisé activement, puis de vérifier les approbations de jetons avec Revoke.cash. Coca présente la révocation comme une routine, pas une urgence, car le drain peut être retardé.

Un flux de travail propre ressemble à ceci :

1. Séparer les rôles entre les portefeuilles. Gardez un portefeuille « coffre-fort » qui ne se connecte jamais aux dApps, et un portefeuille de dépenses ou de brûleur pour les mint, airdrops et nouveaux protocoles. Coca recommande explicitement cette structure pour limiter le rayon d'explosion. 2. Traitez chaque approbation ou signature comme une ligne de crédit permanente.

Si l'invite montre illimité, supposez que le dépensier peut retirer le solde total plus tard, à moins que la dApp n'offre une limite plus stricte. 3. Surveillez les signaux d'alerte UX qui corrèlent avec les drainers. L'exemple de Blockaid inclut des invites de connexion incessantes et une demande wallet_switchEthereumChain qui contredit la chaîne déclarée du site. 4. Auditez et révoquez selon un calendrier.

FinanceFeeds et Coca pointent tous deux vers Revoke.cash et le vérificateur d'approbation de jetons d'Etherscan pour examiner les allocations et les révoquer. 5. Si vous êtes ciblé, agissez d'abord sur les autorisations. Déconnectez les sites connectés, révoquez les approbations et les autorisations d'opérateur NFT, et déplacez les fonds restants vers une nouvelle adresse.

FinanceFeeds souligne que le drainer n'exploite pas Trust Wallet lui-même, et le même risque s'applique aux portefeuilles chauds comme MetaMask et Phantom.

C'est la partie des arnaques de portefeuilles crypto et comment les éviter qui tient réellement sous pression : supposez que le portefeuille de dépenses finira par signer quelque chose de stupide, et concevez le système de manière à ce que cette erreur soit survivable.

La prise

J'ai vu trop de gens présenter un drainer comme un « hack » et ensuite perdre la première heure à chercher des logiciels malveillants alors que le véritable problème se trouve sur la chaîne comme une autorisation qu'ils ont accordée. Le changement mental coûteux consiste à traiter les approbations et les signatures de données tapées comme l'ouverture d'une ligne de crédit permanente.

Une fois que cette ligne existe, l'attaquant n'a pas besoin de demander à nouveau. Ils apparaissent simplement plus tard avec transferFrom ou un transfert d'opérateur et la chaîne l'applique.

Le mode d'échec qui se répète est la signature aveugle déguisée en clic inoffensif. Le démontage de Blockaid du 2024-10-13 est l'exemple clair : eth_signTypedData_v4 récolte un permis, puis le drain peut être acheminé via un véritable routeur afin qu'il ressemble à un échange normal. Les portefeuilles matériels gardent les clés en sécurité, mais ils ne sauvent pas le jugement. L'hygiène des autorisations le fait.

Sources

• FinanceFeeds
• Blockaid
• Coca
• CryptoAventure