Évolution des wallet drainers : panorama 2026 des menaces

L'écosystème des wallet drainers a muté en industrie à part entière. En 2026, les opérateurs drainer-as-a-service tournent comme des franchises, avec des réseaux d'affiliés, de l'infra phishing hébergée, et un support cash-out 24/7. Des drains individuels ont dépassé la barre des 20 M$. Les patterns ont évolué au-delà de ce que la plupart des utilisateurs (et beaucoup d'équipes sécurité) reconnaissent. Cet article détaille le paysage drainer 2026 et ce qui défend contre.

L'économie drainer-as-a-service

Les wallet drainers modernes opèrent comme du SaaS :

• Les opérateurs construisent et maintiennent le kit drainer : smart contracts, logique de signature, UIs de drain, infra mixer.
• Les affiliés drivent le trafic via campagnes de phishing, faux posts X / Discord, extensions de browser malicieuses.
• Le partage de revenus est typiquement 70/30 en faveur de l'affilié (parfois inversé pour les affiliés peu compétents qui utilisent le kit complet de l'opérateur).
• Le tooling inclut des dashboards montrant le taux de succès des drains, les types de wallets ciblés, le flux de fonds par adresse, et un support « VIP » pour les gros drains.

Le modèle économique fait que les opérateurs drainer peuvent dépenser des ressources significatives en innovation technique. L'écart entre la sophistication d'un drainer et les défenses d'un utilisateur typique ne cesse de se creuser.

Pattern 1 : phishing d'approval gasless

L'attaque approval phishing classique demandait à l'utilisateur de signer une transaction (approve(spender, max)) et de payer le gas. Les drainers modernes éliminent la friction :

• Drains basés permit : le drainer demande à l'utilisateur de signer un message permit off-chain (EIP-2612). La signature elle-même autorise le transfert ; aucune transaction on-chain de l'utilisateur n'est requise. Le drainer soumet ensuite le permit et drain immédiatement.
• Drains basés Permit2 : beaucoup de tokens ne supportent pas les permits EIP-2612. Le contrat Permit2 d'Uniswap a ajouté une couche permit universelle. Un message Permit2 signé peut autoriser des transferts de tout token pour lequel l'utilisateur a approuvé Permit2, et la plupart des utilisateurs l'ont fait, vu l'adoption large de Permit2.

L'utilisateur voit une demande de signature « gratuite ». Il signe. Les fonds sont partis avant qu'il réalise que la signature était l'autorisation de drain.

Défense : ne jamais signer un message off-chain qu'on ne comprend pas pleinement. Les wallets qui montrent les détails permit / Permit2 décodés avant de signer sont une défense partielle. Les hardware wallets qui affichent la structure EIP-712 brute aident. La plupart des utilisateurs ne sont pas formés à les lire.

Pattern 2 : abus de typed data EIP-712

La signature de typed data EIP-712 était censée rendre les signatures lisibles : au lieu de signer un hash opaque, les utilisateurs signent un message structuré qu'ils peuvent reviewer.

En pratique, les drainers exploitent deux failles :

1. Confusion de domaine : le séparateur de domaine EIP-712 inclut un nom et une version. Les drainers fabriquent des domaines qui ressemblent à des dApps légitimes (« Uniswap V3 Router », mais pointant sur un contrat malicieux). Les utilisateurs voient « Uniswap » dans l'UI du wallet et signent.
2. Détournement de champs : les champs typed data peuvent être nommés n'importe comment. Une transaction de drain peut être présentée comme un message « Login » ou « Verification » avec un champ labelé « amount » que l'utilisateur suppose être le gas, mais qui est en fait le montant du drain.

Défense : lire l'adresse verifyingContract du domaine, pas seulement le nom. Les adresses de contrat sont la vérité terrain. Les noms et versions sont des chaînes d'affichage.

Pattern 3 : pièges de délégation ERC-7702

Le pattern émergent en 2026 : drainers utilisant ERC-7702 pour déléguer un EOA de manière permanente vers un contrat malicieux.

Le flow :

1. L'utilisateur est phishé pour signer un message de délégation ERC-7702.
2. Le message signé autorise l'EOA de l'utilisateur à déléguer l'exécution vers un contrat drainer.
3. Une fois soumis, l'EOA est le contrat drainer pour toute transaction subséquente.
4. Crucialement, la délégation persiste jusqu'à révocation explicite. Un utilisateur qui délègue et oublie a un wallet compromis de manière permanente.

Le drain n'a même pas besoin d'arriver immédiatement. Un drainer patient attend des semaines, drain quand des fonds apparaissent, et l'utilisateur ne réalise jamais que la signature originale était la compromission.

Défense : les demandes de délégation ERC-7702 devraient être présentées dans les UIs wallet avec un niveau de friction bien plus élevé que les signatures ordinaires. Certains wallets de 2026 commencent à exiger un acknowledgement explicite (« Je comprends que ceci délègue mon compte de manière permanente »). La plupart non.

Pattern 4 : drainer-as-a-page (lien drainer dans un site d'apparence légitime)

Les drainers ne nécessitent plus de pages de phishing évidentes. La technique 2026 :

• Résultats de recherche compromis : URLs drainer payées dans Google ads, indexées via SEO poisoning, ou surfacées via des sites partenaires compromis.
• Hijacking de mint NFT : l'URL officielle de mint d'un projet NFT légitime est brièvement hijackée (DNS poisoning, social compromis, hijack BGP) et sert un drainer à la place.
• Prompts wallet-connect sur dApps légitimes : une dApp compromise sert la demande de signature drainer depuis le même domaine que les utilisateurs trustent.
• Supply chain d'extensions browser : une extension populaire est vendue à un opérateur malicieux et mise à jour pour injecter des prompts drainer.

L'utilisateur a tout fait correctement : il est allé sur « la bonne » URL, a utilisé « le bon » wallet, a signé ce qui ressemblait à une transaction normale. La compromission était en amont.

Défense : tout ce qui vient de toute URL doit être traité comme untrusted avant signature. Les hardware wallets qui affichent les données de transaction décodées donnent à l'utilisateur une chance de repérer les anomalies. La simulation côté wallet (Blockaid, Wallet Guard, simulation native dans Rabby / Frame) est la couche de défense pratique.

Ce que les opérateurs de dApp doivent à leurs utilisateurs

Si vous opérez une dApp qui prompt des signatures wallet, le standard minimum 2026 :

• Ne jamais demander un permit sans contexte explicite. Le prompt de signature doit clairement énoncer ce que le permit autorise.
• Utiliser des signatures type-safe (EIP-712) avec un verifying contract qui est votre vrai contrat de production.
• Ne pas demander de signatures avec des scopes d'approval trop larges (ex. max approval vers un spender générique) quand des approvals scopés feraient l'affaire.
• Implémenter des hints de simulation de transaction lors de l'intégration avec des wallets qui les supportent (Blockaid, Wallet Guard).
• Avoir un chemin clair « signaler du phishing » pour les utilisateurs qui pensent avoir été ciblés via votre marque.

Ce que les protocoles doivent à leurs trésoreries

Pour les opérateurs de protocoles et trésoreries DAO, la menace drainer arrive différemment. La trésorerie ne visite généralement pas de sites de phishing, mais ses signataires sont des individus avec des wallets personnels qui sont ciblés.

• Wallets de trésorerie et personnels doivent être séparés. Un signataire drainé personnellement ne doit pas avoir accès à l'autorité de trésorerie via le même chemin.
• Hardware wallets avec vérification d'affichage sont le plancher. Un signataire qui click à travers un prompt de wallet logiciel signe ce que le prompt dit, ce qui peut ne pas être ce qu'il voulait.
• Simulation de transaction avant signature : les UIs wallet qui montrent ce qui va se passer, pas seulement ce qui est signé, sont critiques.
• Surveillance de wallets sur la trésorerie et les adresses adjacentes signataires : un monitoring continu attrape l'activité post-compromission même quand la signature initiale ne pouvait pas être prévenue.

Quand un drain arrive

La première heure compte. Notre article sur la réponse à incident DeFi dans la première heure déroule le playbook. Spécifiquement pour les drains de wallet :

1. Révoquer les approvals immédiatement sur le wallet compromis, mais seulement via un wallet différent et non compromis, puisque signer depuis le wallet drainé peut être intercepté.
2. Tracer les fonds au fur et à mesure de leurs mouvements. La trace est ce qui rend la recovery éventuelle possible (parfois des semaines plus tard).
3. Contacter les off-ramps. Les exchanges et custodians peuvent geler les fonds si la trace les atteint à temps.
4. Tout documenter. La trace de drain est l'artefact dont tout engagement avec les forces de l'ordre aura besoin.

Les missions de réponse à incident pour drains de wallet réussissent parfois, généralement quand l'engagement est dans les heures, pas les jours.