Une découverte récente met en lumière un angle mort potentiel des paiements sans contact : des chercheurs de l’université de Massachusetts Amherst ont décrit une attaque baptisée « Zombie Card ». L’idée est simple, mais inquiétante : rendre à nouveau utilisables, dans certains cas, des cartes de crédit Visa contactless expirées, tout en évitant de « casser » la cryptographie de la carte.
Plus précisément, l’attaquant ne tente pas de contourner les signatures au sens strict. Il modifie la représentation de la date d’expiration que lit le terminal de paiement, via une architecture en relais proche du mécanisme man-in-the-middle (MitM). Résultat : selon la manière dont les systèmes des différents réseaux et banques implémentent les contrôles, certaines transactions peuvent être acceptées.
Le principe de « Zombie Card »
Selon le papier présenté au 35e USENIX Security Symposium (Baltimore, 12–14 août 2026), l’attaque nécessite un cadre matériel et logique assez précis. Elle exige notamment :
- la possession physique de la carte expirée, ou un maintien prolongé de la proximité NFC ;
- un relais MitM placé entre la carte et le terminal ;
- que le compte reste ouvert sous le même identifiant principal (PAN), ce qui correspond au cas standard lors d’un remplacement de carte par l’émetteur ;
- et que la banque n’effectue pas de re-vérification indépendante de l’expiration au moment de l’autorisation.
La partie la plus notable est que les chercheurs affirment ne pas avoir besoin d’invalider les mécanismes cryptographiques qui protègent les échanges. L’attaque vise plutôt les informations d’expiration consommées par le terminal, sans altérer la partie de données qui demeure cryptographiquement cohérente côté carte.
Où se cache la date d’expiration dans une transaction
Le fonctionnement décrit par les chercheurs repose sur un fait important : l’expiration apparaît deux fois dans une transaction Visa contactless, et ces deux représentations sont traitées par des acteurs différents.
D’un côté, le terminal évalue ses règles de traitement à partir de la Application Expiration Date, transportée dans une donnée de type TLV (tag 5F24). De l’autre, l’émetteur dérive l’expiration à partir des informations envoyées dans une requête d’autorisation en ligne, notamment via des éléments de la Track 2 Equivalent Data (tag 57).
Dans les travaux, un point technique clé concerne la manière dont certaines composantes du noyau (kernel) lient ou non ces éléments à ce qui est contrôlé cryptographiquement. Les auteurs indiquent que, dans le cas de Visa Kernel 3, le mécanisme de vérification de données dynamiques côté terminal n’inclut pas le tag 5F24 dans ce qui est protégé. Ainsi, un relais peut réécrire la date que le terminal utilise pour ses contrôles, tout en laissant les autres données — y compris les éléments validés par la signature — rester suffisamment valides.
Le rôle du relais MitM : deux téléphones, NFC et modification
Sur le banc d’essai, le relais ne nécessite pas de matériel exotique. Les chercheurs ont utilisé deux smartphones Android capables de NFC, exécutant des logiciels personnalisés d’émulation de carte et d’émulation de terminal. Les deux appareils communiquaient entre eux via Wi‑Fi.
Concrètement, le dispositif relaye les échanges NFC pour que le terminal croie communiquer avec une carte valide, tout en modifiant la date d’expiration dans la partie que le terminal consomme. Les auteurs notent également que l’attaquant n’a pas besoin de connaître la vraie date du remplacement : une valeur postérieure à la date de la transaction suffit.
Sur la contrainte temporelle, chaque aller-retour APDU (Application Protocol Data Unit) ajoute environ 20 millisecondes pour le relais et environ 50 millisecondes supplémentaires lorsque la modification est appliquée. En moyenne, cela donne environ 415 millisecondes par transaction, sous la limite EMV de 500 millisecondes par commande.
Des résultats variables selon les réseaux et les implémentations
Un élément essentiel de l’histoire est l’absence d’un résultat « universel ». Les chercheurs indiquent avoir testé la modification sur plusieurs noyaux EMV contactless (les implémentations propres à chaque réseau).
Les conclusions rapportées sont contrastées :
- Visa (Kernel 3) : la modification passe les restrictions de traitement du terminal et ne casse pas la signature concernée, car le tag 5F24 n’est pas inclus dans les données signées.
- Mastercard (Kernel 2) : le terminal effectue une vérification de cohérence entre les deux représentations d’expiration lors du traitement des données READ RECORD, et en cas de divergence, il refuse la carte plutôt que de basculer vers une validation en ligne.
- American Express (Kernel 4) : l’expiration fait partie d’un élément imposé par le format de données lié à l’authentification hors ligne ; la validation de signature échoue (mismatch de hachage).
- Discover (Kernel 6) : la combinaison Dynamic Data Authentication lie les objets TLV renvoyés dans le hachage de transaction vérifié ; les transactions modifiées sont refusées.
En parallèle, la logique des banques testées n’obéit pas au même scénario. L’article rapporte un ensemble d’expériences couvrant cinq banques majeures américaines. Les chercheurs mentionnent que, sur les cas où des transactions « réanimées » ont été tentées avec des cartes remplacées ou expirées :
- un cas a abouti à l’acceptation de transactions pour certains montants ;
- un autre a entraîné un refus systématique ;
- et un troisième échec, parce que la carte utilisait un kernel EMV différent sur lequel la modification ne fonctionne pas.
Quels montants et quels signaux côté terminaux ?
Dans un des scénarios, les auteurs indiquent avoir observé des paiements acceptés pour des montants de test (par exemple 1,00 $, 100,00 $ et 500,00 $) sur un terminal du laboratoire associé à une catégorie commerçante. Ils citent aussi des essais sur des achats internes (campus) avec des montants plus élevés.
À d’autres endroits, les terminaux acceptent d’abord la date modifiée, mais l’émetteur déclenche ensuite un refus et pousse le titulaire vers l’usage de la carte de remplacement. Les chercheurs observent également que, dans les signaux envoyés à l’émetteur, certaines valeurs liées aux résultats de validation terminale peuvent être positionnées de façon à ne pas révéler clairement si le terminal a réellement effectué — ou réussi — ses contrôles locaux sur l’expiration.
Pourquoi les cartes expirées « passent » encore hors ligne
Le papier met en évidence un mécanisme complémentaire : une carte expirée peut continuer à réussir des validations hors ligne, car la durée de vie des certificats côté émetteur et côté carte est gérée indépendamment de la date imprimée d’expiration. Autrement dit, le fait qu’une carte soit « expirée » sur le formulaire ne signifie pas nécessairement que l’authentification hors ligne s’effondre immédiatement.
Dans cette configuration, le relais exploite une absence de protection cryptographique directe sur le champ d’expiration telle qu’il est utilisé par le terminal. Tant que la partie des données pertinentes reste cohérente avec ce que la carte et le kernel vérifient, la transaction peut avancer plus loin dans le processus.
Absence de correctif public et contexte de fraude NFC
Au moment de la publication de l’information, aucun conseil de mitigation clair n’était repéré par les auteurs et par les rapporteurs côté presse : ni Visa, ni EMVCo, ni Mastercard, ni d’autres réseaux, ni des acteurs de terminaux tels que SumUp, ne publiaient de bulletin ou de guidage détaillé lié à cette technique.
Les chercheurs précisent aussi qu’aucune CVE n’aurait été attribuée, et qu’ils n’ont pas constaté de signalement d’exploitation réelle correspondant à la technique décrite. Ils indiquent toutefois avoir transmis leurs constatations aux responsables concernés (Visa et banques touchées) en mai 2025, puis avoir refait un contact en décembre 2025.
Enfin, l’article mentionne un lien conceptuel avec un autre signal : une famille de malwares NFC/relais sur Android suivie par Group-IB (WindRelay), qui emploie une primitive de relais multi-appareils. Dans ce cas, le relais documenté ne modifierait pas la date d’expiration, mais il s’appuie sur une technique de relayage en temps réel.
Quelles contre-mesures les chercheurs recommandent
Pour limiter les effets d’une attaque de type Zombie Card, les auteurs proposent des corrections à plusieurs niveaux : noyau, terminal et émetteur.
1) Lier cryptographiquement les données critiques
Ils recommandent que les champs critiques liés à l’expiration (comme la Application Expiration Date et les éléments de vérification du titulaire) soient protégés par une signature vérifiable par l’émetteur, ou couverts par des mécanismes de hachage propres au kernel, afin que toute modification en cours de route rompe la validation.
2) Comparer les deux représentations d’expiration
Lorsque le protocole expose plusieurs formes de la date, le terminal devrait vérifier leur cohérence et produire un signal exploitable côté émetteur si une divergence apparaît.
3) Traiter l’expiration comme partie de l’identité de la carte
Les émetteurs devraient aussi considérer que l’expiration fait partie de l’ensemble d’identification présenté au système (par exemple, sous la forme d’un tuple associant PAN et expiration). En cas de non-correspondance avec la version actuellement valide, la transaction devrait être refusée.
4) Préserver et transmettre les signaux de validation terminale
Enfin, les chercheurs suggèrent de s’assurer que les résultats de validation du terminal relatifs à l’expiration soient transmis fidèlement à l’émetteur, ou remplacés par un indicateur équivalent visible côté banque.
Conseils pratiques pour les titulaires
Au-delà des mises à jour côté infrastructure, les chercheurs indiquent une recommandation simple pour les personnes détentrices de cartes : détruire la puce ainsi que la bande magnétique des cartes expirées, plutôt que de les ranger intactes. Ils invitent aussi à surveiller l’état des comptes fermés, en cohérence avec l’hypothèse du test (un compte fermé et une configuration différente changeraient l’issue).
Conclusion
Avec Zombie Card, les chercheurs montrent qu’un attaquant peut, dans certaines conditions, faire accepter des transactions à partir de cartes Visa contactless expirées sans briser les signatures. Le point central tient à la manière dont l’expiration est représentée, vérifiée et transmise entre le terminal et l’émetteur, ainsi qu’au fait que certains noyaux ne lient pas systématiquement le champ d’expiration à ce qui est protégé cryptographiquement.
La leçon pour l’écosystème est claire : pour contrer ce type de fraude, il faut renforcer le chaînage cryptographique des champs d’expiration, améliorer la cohérence des contrôles et veiller à ce que l’émetteur reçoive des signaux reflétant réellement les validations locales du terminal.
Source: https://thehackernews.com/2026/08/zombie-card-attack-can-revive-expired.html
