Fraudes et atteintes aux personnes
Particuliers et entreprisesFraude à la carte bancaire en ligne
Card-not-present fraud
Les données d’une carte sont utilisées pour des achats non autorisés.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
Une situation concrète
Une opération inconnue apparaît sur votre relevé alors que votre carte est toujours dans votre portefeuille. Les données ont pu être saisies sur une fausse boutique, volées dans un formulaire compromis ou récupérées ailleurs. La présence physique de la carte ne suffit pas à empêcher son utilisation à distance.
Comment cela fonctionne
Cette fraude utilise vos données de carte ou une autorisation de paiement pour une opération que vous n’avez pas souhaitée. Elle peut suivre un hameçonnage, un appel de faux conseiller ou le piratage d’un commerçant. Une ligne inconnue sur votre relevé peut aussi correspondre à un abonnement oublié ou à un nom commercial inhabituel. Vérifiez-la et, si vous soupçonnez une fraude, contactez rapidement votre banque.
- Les données sont exposées
Carte, compte ou validation détournés.
- Une opération est tentée
La carte physique n’est pas nécessaire.
- Le compte peut être débité
Le titulaire découvre une opération qu’il n’a pas demandée.
Les signes qui doivent attirer l’attention
- Un achat ou une demande de validation ne correspond à aucune action de votre part.
- Un site collecte des informations inhabituelles pour un paiement.
- Un appel vous dicte la validation d’une opération que vous n’avez pas initiée.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Lisez le montant et le bénéficiaire avant chaque validation. Pour une opération inconnue, contactez rapidement la banque par son canal officiel et relevez sa référence.
Si vous êtes responsable du service ou de l’organisation
Définissez des plafonds et des alertes pour les cartes professionnelles. Rapprochez les relevés des achats autorisés et prévoyez qui contacte la banque en cas d’anomalie.
Votre carte peut être utilisée à distance même si vous ne l’avez pas perdue. Le relevé seul ne permet pas de savoir comment ses données ont été obtenues.
À vous de décider
Votre carte est dans votre poche. Un achat frauduleux en ligne reste-t-il possible ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Oui. Pour certains achats à distance, des données de carte ou un accès de paiement volés suffisent. L’escroc n’a pas besoin de votre carte physique.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Une authentification bancaire réussie n’explique pas toute la transaction
Pour l’opération O17, la vérification 3-D Secure réussit, puis le paiement de 89 € est autorisé et capturé. L’adresse de livraison est changée ensuite. Examinez ce changement avec la transaction : l’authentification de départ ne valide pas automatiquement les modifications ultérieures de la commande.
Le second cas est différent : l’authentification aboutit, mais l’autorisation est refusée et aucune capture n’est enregistrée. Confondre authentification, autorisation et capture conduirait à compter un paiement qui n’a pas eu lieu. Les journaux du marchand et du prestataire doivent être rapprochés avec les identifiants de transaction, pas seulement le montant et l’heure.
Une authentification réussie n’établit pas à elle seule l’intention du titulaire. Il peut avoir été trompé sur l’objet de la validation ou avoir subi un détournement de compte. L’enquête technique doit conserver les éléments du parcours, les changements de commande et l’état des fonds. Les règles de responsabilité ou de contestation ne se déduisent pas du seul résultat 3-D Secure.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Commande O17
Acheteur / client vers Marchand
Trace version et montant
- Action
Authentification 3DS
Marchand vers 3DS / émetteur
Trace D8
- Réponse
Résultat Y
3DS / émetteur vers Marchand
Trace ne vaut pas capture
- Action
Demande d’autorisation
Marchand vers PSP / banque
Trace A8
- Réponse
Autorisation puis capture
PSP / banque vers Marchand
Trace C8
- Action sur place
Rapprochement livraison
Marchand
Trace adresse modifiée
Comment repérer cette attaque
Indices à rechercher
Repérer les paiements non reconnus, les changements d’adresse ou de bénéficiaire après validation et les incohérences d’appareil entre commande et paiement.
Quelles informations comparer
Suivre une même commande de l’authentification à l’autorisation puis à la capture. Confirmer le résultat chez le prestataire ; une page de succès ou une notification non vérifiée ne prouve pas un encaissement.
Ce que ces indices ne permettent pas de conclure
Une authentification 3-D Secure réussie n’implique ni autorisation bancaire, ni capture, ni absence de fraude. Le lecteur non marchand devra demander ces éléments à sa banque ; il n’a pas accès aux logs du commerçant.
Comment réagir
Préserver les références, bloquer les accès ou moyens exposés avec les acteurs concernés et rapprocher captures/remboursements. Examiner l’origine de l’exposition : compte client, terminal, formulaire ou simple réutilisation de données volées ailleurs.
Vérifier la correction
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- Vérifier qu’une authentification réussie avec autorisation refusée ne compte pas comme encaissement.
- Tester reprises idempotentes et captures partielles sans double comptage.
- Contrôler l’absence de données sensibles de carte dans les logs et rapports.
À vous de raisonner
3-D Secure réussit, mais l’autorisation est refusée et aucune capture n’est enregistrée. Peut-on comptabiliser ce cas comme un paiement encaissé ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Non. Il faut rapprocher les statuts du marchand et du prestataire avec l’identifiant de transaction. La réussite de l’authentification ne prouve ni l’encaissement ni l’intention du titulaire. Conservez les résultats de chaque étape pour qualifier ce qui s’est réellement produit.
Consulter les détails techniques
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.
status=Y- Résultat d’authentification 3-D Secure illustré, pas statut universel d’un objet Stripe et pas preuve de débit.
capture- Étape distincte de l’autorisation : c’est son résultat et son montant qu’il faut vérifier dans le rapprochement marchand.
Chaîne de transaction
JournalDonnées fictives ; conserver uniquement des tokens ou références, jamais le PAN complet ni le cryptogramme.
order=O17 three_ds_id=D8 authentication_status=Y flow=challenge
order=O17 authorization_ref=A8 result=approved amount=89.00
order=O17 capture_ref=C8 result=success amount=89.00
order=O17 delivery_address_changed=true device_first_seen=true
order=O18 authentication_status=Y authorization=declined capture=nonePréparer une collecte dans votre environnement
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.
Stripe — paiement et journaux de requêtes API
- Où les trouver
- Dans le Dashboard, ouvrir le paiement concerné ; dans Workbench → Logs, retrouver les requêtes API correspondantes et leur identifiant de requête.
- Quoi relever
- Retrouver identifiants de paiement, commande et requête, résultat 3-D Secure, autorisation, capture et éventuel remboursement. Comparer montants et heures ; le vocabulaire dépend du prestataire.
- Accès et prérequis
- Accès habilité au compte marchand. Un autre prestataire utilise ses propres statuts et identifiants. Ne jamais exporter le numéro complet de carte ou le cryptogramme pour cette analyse.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Dans la boutique, rechercher création de commande, changement d’adresse et traitement des notifications du prestataire. Conserver les identifiants d’événements pour reconnaître les doublons et les notifications reçues en retard.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- RéseauMagecart
MyPillow : un script espion au milieu du paiement
En octobre 2018, un script ajouté à la boutique MyPillow copie les informations de paiement. Un premier script est retiré, mais les attaquants gardent un accès. Ils en ajoutent un autre et le cachent derrière un domaine ressemblant à celui d’un service légitime.
Ce qu’établit la source. Microsoft documente ce cas dans sa présentation des investigations sur Magecart. Cette appellation recouvre plusieurs groupes de cybercriminels ; elle ne permet pas d’attribuer tous les vols de carte sur le Web à la même équipe.
Consulter le rapport Gather threat intelligence and perform infrastructure chaining — cas MyPillowMicrosoft Learn · Mis à jour le
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’aucun de ces groupes.
Si vous pensez être concerné
- Contactez immédiatement la banque par son canal officiel pour les mesures adaptées.
- Relevez les opérations concernées et conservez les éléments de la commande éventuelle.
- Sécurisez les comptes associés si un mot de passe ou une session a aussi été exposé.
Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- Cybermalveillance — fraude à la carte bancaire — cybermalveillance.gouv.fr
- PCI Security Standards Council — sécurité des paiements — pcisecuritystandards.org
- EMVCo — EMV 3-D Secure — www.emvco.com
- PCI SSC — bibliothèque documentaire — www.pcisecuritystandards.org
