Manipulation et diffusion
Particuliers et entreprisesHameçonnage
Phishing
Un faux message vous pousse à confier vos données à un imposteur.
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
Vous attendez un colis. Un courriel réclame 2,10 € pour débloquer la livraison. Vous suivez le lien et saisissez votre carte sur une page qui copie celle du transporteur. Les données arrivent chez l’escroc : le vrai transporteur n’a rien demandé.
Comment cela fonctionne
L’hameçonnage est une tromperie : quelqu’un se fait passer pour un interlocuteur de confiance afin de vous faire donner une information ou accomplir une action. La demande peut arriver par courriel, messagerie, SMS ou téléphone. Elle peut préparer une fraude, le piratage d’un compte ou une infection. Même bien écrit, le message peut être faux. Quant au cadenas du navigateur, il protège la connexion au site affiché, sans garantir que vous êtes sur le site attendu. Pour vérifier la demande, ouvrez votre application habituelle ou un favori enregistré. Évitez les liens et les coordonnées fournis dans le message.
- Un message crédible
L’escroc se présente comme un service attendu.
- Une demande pressante
Un lien invite à payer ou à se connecter.
- Des données confiées
La fausse page recueille ce que vous saisissez.
- Un compte ou un paiement exposé
Les informations peuvent être réutilisées ailleurs.
Les signes qui doivent attirer l’attention
- Une demande inattendue de mot de passe, de code de validation ou de paiement.
- Une destination de lien différente du domaine habituellement utilisé, parfois dissimulée derrière un bouton.
- Une pression pour agir vite ou poursuivre l’échange hors du canal habituel.
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
Un message vous réclame un paiement ou une connexion ? Ouvrez vous-même l’application du service pour retrouver la demande. Ne donnez aucun code de validation à l’expéditeur.
Si vous êtes responsable du service ou de l’organisation
Prévoyez un bouton ou une adresse de signalement connus de tous. Faites vérifier les messages signalés et protégez les comptes avec des clés d’accès ou de sécurité lorsque le service le permet.
Le logo et une rédaction sans faute ne prouvent pas l’origine d’un message. Un vrai compte peut aussi envoyer des messages trompeurs s’il a été piraté.
À vous de décider
Le courriel porte le bon logo, ne contient aucune faute et ouvre un site HTTPS. Pouvez-vous lui confier votre mot de passe ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Le logo et une rédaction soignée peuvent être imités. HTTPS chiffre les échanges avec le site affiché, mais ne garantit pas qu’il appartient à l’organisme attendu. Ouvrez le service comme vous le faites habituellement.
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
Un message bien authentifié peut tout de même être frauduleux
Le message réussit les contrôles SPF, DKIM et DMARC pour factures-demo.example. Ces contrôles portent sur l’autorisation d’envoi et l’alignement des domaines. Rien dans l’extrait ne prouve que ce domaine appartient au service de facturation annoncé, ni que le message est honnête. Un attaquant peut configurer correctement ces protections sur son propre domaine.
Lire les en-têtes dans l’ordre de réception et retenir les résultats ajoutés par la passerelle de confiance. Un expéditeur peut ajouter lui-même de faux en-têtes en amont. Comparer le domaine de l’adresse visible, l’adresse de réponse et les destinations des liens. Un nom d’affichage familier n’est pas une preuve d’identité.
Pour déterminer l’impact, distinguer réception, ouverture, clic, saisie de secret et utilisation du compte. Un clic peut provenir d’un scanner de sécurité. Un destinataire peut avoir saisi son mot de passe sans que la passerelle ait vu le formulaire. Relier les événements de messagerie aux déclarations de la personne et aux connexions du compte, puis rechercher les autres destinataires du même message.
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
Message et signature
Expéditeur vers Passerelle mail
Trace identité SMTP / DKIM
- Action sur place
Évaluation de l’alignement
Passerelle mail
Trace DMARC pass possible
- Action
Livraison
Passerelle mail vers Destinataire
Trace message_key interne
- Action
Clic éventuel
Destinataire vers Site de destination
Trace scanner ou humain
- Réponse
Formulaire présenté
Site de destination vers Destinataire
Trace pas encore preuve de saisie
- Action
Saisie à confirmer
Destinataire vers Site de destination
Trace éléments disponibles
- Action
Retrait des messages de la campagne
Passerelle mail vers Destinataire
Trace ne révoque pas les sessions
Comment repérer cette attaque
Indices à rechercher
Examiner les domaines ressemblants, les adresses de réponse inattendues et les liens vers une authentification étrangère au service annoncé.
Quelles informations comparer
Relier message livré, URL cliquée puis éventuelle authentification sur le vrai service. Message-ID sert à retrouver le message ; il ne démontre pas à lui seul un clic ni la remise d’un mot de passe.
Ce que ces indices ne permettent pas de conclure
SPF, DKIM et DMARC peuvent réussir pour un domaine contrôlé par l’attaquant. N’accorder de valeur qu’aux résultats ajoutés par votre infrastructure de confiance : un en-tête présent dans un message n’est pas automatiquement fiable.
Comment réagir
Préserver un original, rechercher et retirer les exemplaires de campagne, bloquer les destinations qualifiées et traiter les comptes réellement exposés. Vérifier les sessions et méthodes de récupération si une saisie ou un relais d’authentification est plausible.
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.
- Comparer un domaine ressemblant mais correctement authentifié à une usurpation du domaine exact.
- Vérifier que les clics du scanner ne sont pas comptés comme saisies utilisateur.
- Confirmer le retrait des messages et la révocation des accès déjà compromis.
À vous de raisonner
Un message passe SPF, DKIM et DMARC, mais conduit vers un domaine étranger au fournisseur annoncé. Quelle vérification manque avant de lui faire confiance ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Il faut vérifier que le domaine appartient réellement au fournisseur et que la demande vient de lui, par un canal connu. Les trois contrôles peuvent réussir sur le domaine de l’attaquant. Ils ne valident ni la demande ni la destination du lien.
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.
dmarc=pass- Le domaine du scénario respecte ses contrôles d’authentification ; cela ne le rend pas légitime.
Reply-To- Adresse à laquelle part une réponse, qui peut différer de l’expéditeur visible.
En-têtes d’un message de laboratoire
En-têtes de courrielExemple synthétique : les validations concernent le domaine de l’expéditeur technique, pas la marque affichée.
From: "Service facturation" <support@factures-demo.example>
Reply-To: dossier@reponse-demo.example
Authentication-Results: mx.interne.example;
spf=pass smtp.mailfrom=factures-demo.example;
dkim=pass header.d=factures-demo.example;
dmarc=pass header.from=factures-demo.example
Message-ID: <m17@factures-demo.example>
Lien affiché : espace client
Destination : https://connexion-demo.example/dossierPré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.
Exchange Online — suivi des messages
- Où les trouver
- Centre d’administration Exchange → Mail flow → Message trace. Rechercher expéditeur, destinataire et période ; rapprocher les résultats du Message-ID de l’original conservé au format EML.
- Quoi relever
- Conserver l’original EML et lire From, Reply-To, Message-ID, Received et Authentication-Results. Comparer le domaine réellement authentifié au domaine attendu, pas au nom affiché de l’expéditeur.
- Accès et prérequis
- Droits Exchange adaptés. Le suivi indique le traitement et la livraison, pas la lecture humaine ni le clic. Les en-têtes complets se récupèrent aussi depuis le message d’origine.
Chrome DevTools — panneau Network du navigateur
- Où les trouver
- Dans une capture déjà conservée, ou sur une reproduction autorisée en environnement de test : ouvrir Network et conserver la navigation avec Preserve log. Examiner Headers et Initiator.
- Quoi relever
- Utiliser une capture existante ou les traces du filtrage web pour retrouver l’URL réellement demandée et les redirections. Ne pas ouvrir un lien suspect sur un poste de travail pour créer une preuve.
- Accès et prérequis
- La capture doit être active pendant l’observation : elle ne reconstitue pas le passé. Un export HAR peut contenir des données privées, même après retrait des en-têtes sensibles ; le nettoyer avant partage.
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.
- àGroupeScattered Spider / Octo Tempest
Le support et les identités comme portes d’entrée
Les attaquants imitent des contacts de confiance, appellent l’assistance et détournent des numéros de téléphone. Pour prendre le contrôle des comptes, ils associent hameçonnage, interception de connexions et pression pour faire accepter les validations MFA.
Ce qu’établit la source. Microsoft décrit Octo Tempest comme un périmètre recoupant Scattered Spider, 0ktapus et UNC3944. Ces noms de suivi ne sont pas nécessairement des synonymes exacts.
Consulter le rapport Octo Tempest crosses boundaries to facilitate extortion, encryption, and destructionMicrosoft · Publié 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é
- Si vous avez seulement reçu le message, signalez-le puis supprimez-le ; ne poursuivez pas l’échange.
- Si vous avez saisi un secret, utilisez un appareil fiable pour changer le mot de passe, révoquer les sessions et vérifier les moyens de récupération.
- Si une carte a été utilisée ou une opération validée, contactez immédiatement votre banque par son canal officiel.
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
- MITRE ATT&CK — Phishing — attack.mitre.org
- Cybermalveillance — hameçonnage — cybermalveillance.gouv.fr
- RFC 9989 — DMARC — www.rfc-editor.org
- RFC 8601 — Authentication-Results — www.rfc-editor.org
