Pourquoi votre portefeuille affiche un transfert que vous n’avez jamais envoyé : transactions de valeur nulle et empoisonnement d’adresse

Une transaction sortante inconnue ne signifie pas automatiquement que votre portefeuille a été piraté. Découvrez ce que prouvent réellement les enregistrements de valeur nulle, les adresses ressemblantes et les mouvements effectifs d’actifs.

Que prouve cette entrée au sujet de mon portefeuille ?

Si votre historique indique soudainement que vous avez envoyé 0 USDT à une adresse inconnue, cette entrée ne suffit pas à établir que quelqu’un a accédé à votre clé privée. Un tiers peut créer certains enregistrements de transfert de zéro jeton mentionnant votre adresse, sans votre signature ni votre autorisation de dépenser un montant supérieur à zéro. L’enregistrement peut exister sur la blockchain alors que vous n’avez jamais lancé cette opération.

Les questions utiles sont plus précises : De quel actif s’agit-il ? Quelle quantité a réellement été transférée ? Qui a soumis la transaction ? Qu’est-ce qui a autorisé toute dépense réelle ?

Un événement de transfert de jetons d’un montant nul ne prouve pas que vous avez signé ou dépensé quoi que ce soit. Pour un véritable jeton, un montant exactement égal à zéro signifie que ce transfert précis n’a déplacé aucun jeton.
Un transfert portant le nom d’un jeton connu n’identifie pas l’actif. Un contrat sans rapport peut utiliser le même nom et le même symbole.
Un minuscule paiement entrant peut être réel tout en introduisant dans votre historique une adresse d’expéditeur trompeuse.
Un mouvement sortant confirmé et inexpliqué d’actifs authentiques doit être examiné. Ne l’écartez pas sous prétexte qu’un autre champ indique zéro.

Ce guide porte sur Ethereum, BNB Smart Chain (BSC) et les réseaux similaires utilisant des contrats de jetons de type Ethereum. Les exemples sont volontairement simplifiés et inventés ; il ne s’agit ni de captures d’écran ni de constatations concernant un portefeuille particulier.

Commencez par identifier le champ qui indique zéro

L’expression transaction de valeur nulle désigne plusieurs situations différentes. Un seul de ces affichages indique que la quantité de jetons est nulle :

Montant en jetons : 0 USDC. Pour le véritable contrat USDC, un montant exactement nul signifie que ce transfert particulier ne déplace aucun USDC.
Valeur de la transaction : 0 ETH. Aucun ETH n’a été joint à la transaction principale. Des jetons peuvent néanmoins être transférés et des opérations de contrat exécutées.
Valeur estimée : $0.00. L’interface affiche une valorisation en monnaie fiduciaire. Cela ne permet pas d’établir la quantité de jetons.

Sur BSC, le champ relatif à la monnaie native utilise normalement BNB plutôt que ETH. Une interaction avec un contrat dont la valeur native est nulle peut transférer des jetons, modifier des autorisations de dépense ou déclencher d’autres opérations. La valeur native est distincte des données d’entrée de la transaction.

Un petit montant positif peut être arrondi à $0.00. Un actif dont le prix n’est pas fiable peut également présenter une valorisation fiduciaire peu utile. Affichez le montant des jetons avec toute sa précision : même une quantité affichée de 0.00 peut masquer une valeur positive plus petite. L’évolution de la valorisation d’un portefeuille ne constitue pas un relevé fiable des unités entrées ou sorties d’un compte.

Zéro est un montant de jetons autorisé : il ne suffit donc pas à prouver une attaque. Les adresses ressemblantes et les détails de paiement copiés sont des indices à examiner.

Pourquoi les deux champs From peuvent être différents

L’historique d’un portefeuille peut réunir des informations provenant de plusieurs niveaux :

La transaction : l’instruction signée et soumise au réseau. Pour une transaction Ethereum classique, le champ principal From identifie le compte signataire.
L’événement du jeton : un enregistrement émis par un contrat pendant son exécution. Un événement Transfer possède ses propres champs From, To et montant.
La ligne d’historique : la présentation de ces informations par le portefeuille ou l’explorateur. Elle peut indiquer OUT si l’événement mentionne votre adresse comme expéditeur.

Ces deux champs From ne sont pas interchangeables. La présence de votre adresse dans un événement n’est pas une signature de votre portefeuille. Un contrat malveillant peut inscrire votre adresse dans les données d’un événement, mais son journal ne provient pas pour autant du véritable contrat du jeton. Le contrat émetteur est donc un élément de preuve essentiel.

De même, un hash de transaction identifie une transaction ; il n’établit pas votre consentement. Une transaction incluse et marquée Success montre que son exécution externe n’a pas été annulée. Ce n’est pas une validation du jeton, du destinataire ou de l’objectif.

Cinq exemples commentés d’historique de transactions

Exemple 1 : un transfert sortant de zéro jeton que vous n’avez jamais signé

Entrée d’historique : OUT · 0 USDC · De votre adresse vers une adresse inconnue ressemblante.

From de la transaction : un compte sans rapport a soumis la transaction.
From de l’événement du jeton : l’événement mentionne votre adresse.
Contrat du jeton émetteur : le véritable contrat USDC sur ce réseau.
Montant exact en jetons : zéro.

Ce que cela prouve : le véritable contrat du jeton a enregistré un transfert de zéro jeton mentionnant votre adresse. Ce transfert précis n’a déplacé aucun USDC. Il n’établit ni que votre portefeuille a signé la transaction, ni que l’appelant est autorisé à dépenser un montant positif, ni que votre clé a été volée.

Comment cela se produit : ERC-20, la norme courante des jetons, impose que les transferts d’un montant nul émettent des événements Transfer. Dans les implémentations courantes, la fonction de transfert délégué transferFrom vérifie si le montant demandé dépasse l’autorisation accordée à l’appelant. Zéro ne dépasse pas une autorisation de zéro. Sous réserve des autres règles du contrat, l’appel peut réussir sans approbation préalable.

Cela ne constitue pas une garantie universelle pour tous les jetons. Les contrats individuels peuvent imposer des restrictions supplémentaires.

À vérifier ensuite : examinez le reste de la transaction. Une ligne à zéro ne décrit que cette ligne ; une autre opération pourrait avoir un autre effet. S’il s’agit d’un enregistrement d’empoisonnement isolé, sans dépenses suspectes ni changements d’autorisations, la réponse appropriée consiste à éviter l’adresse introduite, et non à supposer que le portefeuille doit être remplacé.

Exemple 2 : une fausse transaction affichant un montant important de jetons

Entrée d’historique : OUT · 2,500 USDC · De votre adresse vers une adresse inconnue.

Symbole du jeton affiché : USDC.
Contrat émetteur : un contrat sans rapport, et non le véritable USDC.
Montant indiqué dans l’événement : 2,500.
Mouvement réel de USDC dans cette transaction : aucun.

Ce que cela prouve : un autre contrat a émis un enregistrement présenté sous l’étiquette USDC. Cela ne prouve pas que 2,500 véritables USDC ont quitté votre compte.

Une fausse transaction dans un portefeuille peut correspondre à des données réelles de la blockchain, mais interprétées de manière trompeuse. Les attaquants peuvent copier le nom et le symbole d’un jeton et émettre des événements ressemblant à vos paiements antérieurs, y compris leurs montants. Des contrats non standard peuvent également émettre des enregistrements de transfert ne correspondant pas à des changements de leurs propres soldes.

À vérifier ensuite : identifiez le réseau et le contrat exact ayant émis l’événement. Comparez cette adresse aux informations sur le contrat obtenues indépendamment auprès de l’émetteur pour ce réseau. Un symbole familier, un logo ou une mention de vérification du code source ne suffisent pas à établir l’identité de l’émetteur.

Exemple 3 : un minuscule paiement réel provenant d’une adresse ressemblante

Entrée d’historique : IN · 0.000001 USDC · D’une adresse inconnue vers la vôtre.

Supposons que le véritable contrat du jeton confirme le transfert et que votre solde augmente de ce minuscule montant. Dans ce cas, de vrais jetons sont arrivés. Leur réception ne nécessitait pas que vous approuviez l’expéditeur et ne lui donne pas le droit de dépenser vos fonds.

Le piège réside dans l’adresse. Considérez ces exemples inventés, séparés par des espaces pour rendre chaque caractère visible. Les vraies adresses ne contiennent aucun espace ; les groupes centraux en gras sont différents :

Destinataire vérifié : 0x7a2f 1111 2222 3333 4444 5555 6666 7777 8888 9c4d

Adresse introduite : 0x7a2f aaaa bbbb cccc dddd eeee ffff 0000 1111 9c4d

Une interface n’affichant que le début et la fin pourrait présenter les deux adresses comme 0x7a2f...9c4d.

Ce que cela prouve : quelqu’un vous a envoyé un petit montant depuis cette adresse. Cela ne prouve pas que l’expéditeur est votre destinataire habituel ou un compte que vous contrôlez. La correspondance des caractères visibles n’établit pas la propriété de l’adresse.

À vérifier ensuite : récupérez l’adresse de destination prévue auprès d’un contact vérifié séparément ou depuis la page de compte fiable du destinataire. Comparez l’adresse entière. L’empoisonnement d’adresse cherche à faire d’une entrée placée dans l’historique la destination que vous choisirez lors d’un paiement ultérieur. La perte peut survenir plus tard, lorsque vous autorisez un transfert parfaitement valide vers la mauvaise destination.

Exemple 4 : zéro ETH, mais 2,500 véritables jetons sortent

En-tête de transaction : Value · 0 ETH.

Valeur native jointe à l’appel : 0 ETH.
Transfert de jetons authentiques : 2,500 USDC depuis votre adresse.
Modification du solde USDC causée par cette transaction : une diminution de 2,500 USDC.
État d’exécution : Success.

Ce que cela prouve : de véritables USDC sont sortis dans cet exemple. Le zéro décrit les ETH joints à l’appel. Il ne décrit pas le transfert de USDC et n’exclut pas les frais de gas.

Ce qui reste inconnu : pourquoi le paiement a eu lieu et si vous l’aviez voulu. Il pourrait correspondre à un échange, un dépôt, une opération programmée, un paiement à la mauvaise adresse ou une dépense non autorisée. Faites le rapprochement avec l’action effectuée et la destination voulue avant de le classer.

Exemple 5 : de vrais jetons sortent, mais un autre compte soumet la transaction

Entrée d’historique : OUT · 500 véritables USDC · Une destination inconnue.

Supposons que la transaction réussie ait réduit votre solde réel de USDC de 500, mais que son champ principal From indique quelqu’un d’autre.

Ce que cela prouve : les jetons ont été transférés. Un expéditeur de transaction différent ne rend pas ce mouvement fictif.

Un acteur disposant d’une autorisation accordée précédemment peut utiliser cette permission sans vous demander de signer une nouvelle transaction à chaque retrait. Certains jetons prennent aussi en charge les signatures permit, qui autorisent une allocation au moyen d’un message signé qu’un tiers peut soumettre. Les comptes intelligents et les portefeuilles délégués offrent d’autres moyens à un tiers de soumettre une opération autorisée.

À vérifier ensuite : examinez l’acteur autorisé à dépenser, l’allocation correspondante ou l’autorisation signée, ainsi que l’opération du portefeuille. Si le débit reste inexpliqué, traitez-le comme un incident de sécurité. Les indices peuvent révéler une approbation malveillante, une signature trompeuse ou un contrôle du compte compromis ; la ligne seule ne permet pas de les distinguer.

Pour une transaction ordinaire signée directement, votre adresse dans le champ principal From est une preuve de signature valide pour ce compte. Elle ne prouve toutefois pas que vous avez compris l’action, voulu ce destinataire ou personnellement lancé l’opération. Le champ From d’un événement de jeton constitue une preuve beaucoup plus faible.

Ce que les 270 millions de tentatives d’empoisonnement mesurent réellement

Une analyse sur deux ans de l’activité sur Ethereum et BSC, du July 1, 2022 au June 30, 2024, a identifié environ 270 millions d’enregistrements de transferts d’empoisonnement ciblant 17 millions d’adresses.

Les enregistrements se répartissaient en trois catégories :

147.7 millions de transferts de valeur nulle.
118.4 millions de transferts de jetons contrefaits.
4.0 millions de transferts minuscules.

Ces enregistrements figuraient dans environ 18.2 millions de transactions, car les attaquants peuvent regrouper plusieurs enregistrements. Les adresses ciblées ne correspondent pas nécessairement à des personnes, à des portefeuilles compromis ou à des victimes ayant perdu de l’argent.

L’analyse a identifié 6,633 transferts fructueux au bénéfice des attaquants totalisant au moins $83.8 millions. Certaines victimes ont payé plusieurs fois. La détection portait sur certaines stablecoins : l’estimation des pertes est donc une borne inférieure dans ce périmètre, et non un total pour tous les jetons ou toutes les chaînes.

En pratique, vérifier uniquement les montants nuls fait manquer une part importante de l’attaque. Les fausses entrées peuvent imiter un paiement significatif, et un minuscule transfert entrant peut réellement déplacer des jetons tout en introduisant une adresse dangereuse.

Comment examiner votre entrée particulière

Ouvrez la transaction sur le bon réseau. Utilisez l’option d’explorateur de votre portefeuille ou un explorateur connu tel qu’Etherscan ou BscScan. Vérifiez l’état de la transaction. Consulter les détails publics ne nécessite ni connexion du portefeuille, ni approbation de jetons, ni signature d’un message, ni saisie d’une phrase de récupération.
Identifiez l’actif réel. Distinguez les ETH ou BNB natifs d’un jeton portant ce nom. Pour les jetons, vérifiez le réseau exact et le contrat émetteur auprès d’une référence fiable de l’émetteur.
Lisez le montant avec toute sa précision. Distinguez la quantité de jetons de la valeur native de la transaction et de l’estimation fiduciaire.
Distinguez l’expéditeur de la transaction de celui de l’événement. Pour un compte intelligent, examinez également l’opération du portefeuille et ses autorisations. Le fait qu’un tiers paie le gas ne prouve pas que vos actifs n’ont pas pu bouger.
Examinez toute la transaction. Vérifiez tous les mouvements de jetons, transferts de monnaie native et changements d’autorisations pertinents. Si l’explorateur indique les variations de soldes au niveau de la transaction, utilisez-les pour rapprocher le résultat. Un solde inchangé aujourd’hui est une preuve plus faible : des dépôts ultérieurs ou des transferts compensatoires peuvent masquer un mouvement antérieur.
Vérifiez indépendamment la destination. Utilisez les coordonnées de paiement fiables du destinataire ou une entrée de carnet d’adresses préalablement vérifiée. Une ligne récente d’historique est un indice à examiner, pas une preuve de la bonne destination.

Si l’explorateur ne permet pas de comprendre clairement le résultat, communiquez au support officiel du fournisseur de portefeuille le réseau et le hash public de la transaction. Décrivez l’action attendue, le cas échéant. Ces éléments aident à distinguer une opération inconnue mais voulue d’une dépense inexpliquée, sans divulguer les secrets donnant le contrôle de votre portefeuille.

Que faire après vérification

Si vous avez trouvé uniquement un enregistrement d’empoisonnement isolé

Masquez ou signalez le spam si votre portefeuille le permet, et évitez d’utiliser ses adresses. Masquer une ligne modifie l’interface ; cela n’efface pas l’historique de la blockchain et ne révoque aucune autorisation.

Un transfert de zéro peut avoir lieu avec une allocation de zéro : cet enregistrement seul ne justifie donc pas de révoquer toutes les approbations ou de déplacer tous vos fonds. Il se peut qu’aucune permission de dépense liée à cet enregistrement ne puisse être supprimée. N’utilisez jamais le site annoncé par un jeton ou un lien de récupération envoyé par un inconnu pour « nettoyer » votre portefeuille.

Si vous avez trouvé une autorisation de dépense suspecte

Utilisez la fonction fiable de gestion des approbations de votre portefeuille pour examiner et révoquer l’allocation concernée. Déconnecter un site web de votre portefeuille ne révoque pas ses approbations de jetons déjà enregistrées sur la chaîne. La révocation traite cette autorisation ; elle ne peut réparer le vol d’une clé privée.

Si des actifs réels ont bougé sans votre intention

Conservez le hash de transaction, le réseau, l’actif concerné et les adresses pertinentes. Examinez les signatures récentes, les approbations et les opérations du portefeuille par les canaux officiels d’assistance.

Si des éléments indiquent que votre phrase de récupération ou votre clé privée est exposée, créez un nouveau portefeuille avec une nouvelle phrase de récupération sur un appareil fiable, puis suivez un plan prudent pour transférer les actifs restants. Un autre compte dérivé de la phrase compromise ne résout pas cette exposition. Si des fonds disparaissent automatiquement, ne continuez pas à ajouter de l’argent pour le gas : un programme de vidage automatique peut s’en emparer.

Si vous avez sciemment signé un paiement mais copié une destination empoisonnée, consignez cette différence. Le paiement peut avoir été correctement signé et exécuté tout en étant envoyé au mauvais destinataire. Ce résultat ne prouve pas, à lui seul, que votre clé privée a été volée.

Questions fréquentes sur les transactions inconnues

L’attaquant m’a-t-il fait payer le gas ?

Dans le scénario d’empoisonnement ordinaire, l’attaquant soumet la transaction et paie les frais de réseau. Mentionner simplement votre adresse dans un événement de jeton ne débite pas votre compte. Cependant, les transactions sponsorisées et les comptes intelligents font que l’identité du payeur des frais ne suffit pas à déterminer si l’opération était inoffensive. Vérifiez les effets réels.

Que se passe-t-il si la transaction a échoué ?

Un transfert de jetons annulé n’a pas été effectué, même si des frais de gas peuvent être facturés. Si le portefeuille utilise la délégation de compte, vérifiez-la séparément : Ethereum peut conserver une délégation même lorsque l’exécution ultérieure échoue. Une délégation inconnue mérite un examen.

Un portefeuille matériel empêcherait-il l’empoisonnement d’adresse ?

Il offre un autre endroit où vérifier la destination avant de signer. Il ne peut pas rendre correcte une destination contrôlée par un attaquant si vous l’approuvez. Comparez l’adresse entière sur l’écran de signature fiable aux coordonnées du destinataire vérifiées indépendamment.

Puis-je empêcher les inconnus d’ajouter ces entrées ?

En général, vous ne pouvez pas empêcher des tiers d’envoyer des actifs ou de créer des enregistrements applicables impliquant une adresse publique. Les filtres de portefeuille et d’explorateur peuvent réduire ce que vous voyez. Enregistrez les destinataires vérifiés et contrôlez l’adresse de destination entière avant de payer ; masquer seulement les entrées de valeur nulle ne permet pas de détecter toutes les variantes avec faux jetons ou transferts minuscules.