🎣Phishing / Ingénierie sociale

Le phishing consiste à envoyer un e-mail à des fins malveillantes afin d’inciter les destinataires à divulguer des informations sensibles, à télécharger des fichiers malveillants ou à effectuer une action qu’ils ne feraient pas normalement, en exploitant une ou plusieurs techniques d’ingénierie sociale.

Protocoles de messagerie :

Protocole	Non sécurisé	Sécurisé (SSL/TLS)
SMTP (Simple Mail Transfer Protocol)	25	465 ou 587
POP3 (Post Office Protocol v3)	110	995
IMAP (Internet Message Access Protocol)	143	993

Les différents types de phishing :

E-mails de reconnaissance (Recon) : Ces messages servent surtout à “prendre la température” avant une vraie campagne de phishing. L’objectif est de vérifier si une adresse e-mail est valide et si quelqu’un lit réellement la boîte. Ils ne contiennent en général aucun lien ou pièce jointe clairement malveillant : parfois juste quelques mots, voire une suite de caractères sans sens. Certains intègrent des pixels de suivi (images invisibles) pour savoir si le mail a été ouvert, depuis quel type d’appareil, avec quel client de messagerie, à quelle heure et depuis quelle adresse IP. Toutes ces informations aident l’attaquant à préparer des attaques plus ciblées par la suite.

Récolte d'identifiants (Credential Harvester) : Le but est explicite : voler des identifiants (login / mot de passe, parfois codes 2FA). Le mail contient généralement un lien vers une fausse page de connexion qui imite un service légitime (webmail, portail VPN, Microsoft 365, banque, etc.). La victime pense se connecter normalement, mais en réalité elle envoie ses identifiants au serveur de l’attaquant. Ce type de phishing peut aussi passer par des QR codes (“quishing”) ou des formulaires intégrés.

L'ingénierie sociale (Social Engineering) : Ce type de phishing mise avant tout sur la psychologie plutôt que sur la technique. Le contenu de l’e-mail est conçu pour provoquer une réaction émotionnelle : urgence (“votre compte va être fermé”), peur (menace légale, sécurité), curiosité (fichier sensible, nouvelles importantes), ou autorité (fausse demande de la direction, du support IT, d’un fournisseur). L’attaquant adapte le ton, le vocabulaire et parfois les éléments visuels pour rendre le message crédible et pousser la victime à cliquer, répondre ou fournir des informations.

Vishing et Smishing : Le vishing (voice phishing) utilise le téléphone : appels frauduleux se faisant passer pour la banque, un service client, le support technique, parfois combinés avec des e-mails pour renforcer la crédibilité. Le smishing (SMS phishing) passe par des textos qui contiennent souvent un lien vers un site malveillant ou un numéro à rappeler. Ces canaux profitent du côté direct et intrusif du téléphone, et du fait que beaucoup de personnes font moins attention aux liens sur mobile que sur un PC.

Whaling (Ingénierie sociale ciblé, avec du renseignement en amont sur la cible. Exemple : Arnaque au Président) : Le whaling est une forme de phishing très ciblée contre des profils “à forte valeur” : dirigeants, cadres, responsables financiers, administrateurs IT, etc. Avant d’envoyer le moindre e-mail, l’attaquant réalise souvent un important travail de renseignement (OSINT) : poste, contexte actuel de l’entreprise, projets en cours, partenaires, style de communication… Le message est ensuite sur-mesure : demande de virement urgent, validation d’une facture, partage d’un document sensible. Le niveau de personnalisation rend l’attaque particulièrement crédible et dangereuse.

Fichier malveillants (Malicious File) : L’e-mail contient une pièce jointe qui semble légitime (facture, CV, bon de commande, document interne), souvent au format Office ou PDF. Le fichier contient soit une macro malveillante, soit un exploit d’une vulnérabilité, soit un script caché. Une fois ouvert et exécuté, il peut installer un malware (RAT, ransomware, voleur d’identifiants), ouvrir une connexion vers un serveur de commande et contrôle, ou déposer un outil permettant à l’attaquant de se maintenir dans le système.

A faire attention

Courriers indésirables (Spam) : Le spam regroupe tous les e-mails non sollicités envoyés massivement, sans forcément être toujours directement malveillants : publicité douteuse, arnaques grossières, spams commerciaux non conformes, etc. Cependant, le spam est aussi un vecteur fréquent pour des liens vers des sites piégés ou des pièces jointes malveillantes. Pour un analyste, il est important de distinguer le “bruit” (simple nuisance) des messages qui constituent une vraie menace.

Les faux positifs (False Positive) : Les faux positifs ne sont pas un type d’attaque, mais un phénomène important pour la défense : il s’agit de messages légitimes qui sont à tort classés comme spam ou phishing par les filtres de sécurité. Un volume trop élevé de faux positifs peut entraîner une perte de confiance dans les outils, des blocages métiers et des demandes de désactivation de protections. L’enjeu pour les équipes de sécurité est donc de trouver un équilibre entre détection efficace des attaques et limitation des faux positifs grâce au tuning, aux listes blanches et aux retours des utilisateurs.

Tactiques et techniques utilisées

Les acteurs malveillants ne se contentent pas d’envoyer un simple e-mail frauduleux ; ils combinent plusieurs tactiques pour rendre leurs attaques plus crédibles et plus difficiles à détecter.

Le spear phishing : est une forme de phishing ciblé : au lieu d’envoyer un message générique à des milliers de personnes, l’attaquant prépare un e-mail spécifiquement pour une personne ou un petit groupe. Il s’appuie souvent sur des informations collectées en amont (OSINT, réseaux sociaux, actualités de l’entreprise) pour personnaliser le contenu, le ton et le contexte. Résultat : le message paraît légitime et la victime est beaucoup plus susceptible de cliquer ou de répondre.

L’impersonation (usurpation d’identité): vise à se faire passer pour quelqu’un de confiance : un collègue, un supérieur hiérarchique, un prestataire, un client, voire un organisme officiel. L’attaquant copie la signature, le style d’écriture, le logo, parfois même des échanges antérieurs. Combinée à une demande urgente (paiement, changement de RIB, partage de documents sensibles), cette technique exploite la confiance et l’effet d’autorité.

Typosquatting : consiste à enregistrer des noms de domaine très proches d’un domaine légitime, mais contenant de petites erreurs volontaires : par exemple micorsoft.com au lieu de microsoft.com, ou amzon.fr au lieu d’amazon.fr. Les victimes qui ne remarquent pas la faute tapent l’adresse dans leur navigateur ou cliquent sur un lien piégé et se retrouvent sur un site malveillant qui imite l’original (vol d’identifiants, téléchargement de malware, etc.).

Homographs : Les homograph attaques vont plus loin en jouant sur des caractères visuellement identiques mais différents en Unicode. Par exemple, le « o » latin et le « o » cyrillique ont un code Unicode différent, mais à l’œil nu le nom de domaine semblera identique. Un utilisateur verra exemple.com, alors qu’en réalité une ou plusieurs lettres appartiennent à un autre alphabet. Ce type d’attaque est pratiquement impossible à détecter pour un utilisateur non averti, surtout si le reste du site est une copie fidèle du site légitime.

Le sender spoofing (usurpation de l’expéditeur) : consiste à manipuler l’adresse d’envoi d’un e-mail pour qu’elle ressemble à une adresse légitime. Le but est de faire croire au destinataire que le message provient d’une source connue (direction, service comptable, fournisseur, banque, etc.). Sans vérification des enregistrements SPF/DKIM/DMARC ou des en-têtes techniques, l’utilisateur se fie uniquement au nom et à l’adresse affichés, ce qui rend la tromperie très efficace.

Hyperlinks et URL-Shortening Services (Bitly, TinyURL, etc.) : permettent de masquer la véritable destination d’un lien. Au lieu de voir un domaine suspect ou une URL très longue et étrange, la victime ne voit qu’un lien raccourci “propre”. Cette technique complique la vérification manuelle, et perturbe parfois certaines analyses automatisées, tout en facilitant le “clic réflexe” sur un lien présenté comme un simple suivi de colis, une facture ou un document à consulter.

BEC (Business Email Compromise / La compromission de la messagerie professionnelle) : est une catégorie d’attaque particulièrement dangereuse. L’attaquant parvient d’abord à compromettre ou à usurper un compte de messagerie légitime (souvent celui d’un dirigeant, d’un directeur financier ou d’un fournisseur), puis l’utilise pour envoyer des demandes frauduleuses parfaitement crédibles : changement de coordonnées bancaires, validation urgente d’un virement, partage de documents sensibles, etc. Comme les messages proviennent d’un compte réel, au sein d’un échange existant, ils sont très difficiles à identifier comme malveillants sans une vigilance accrue côté processus métier.

Composition d'un e-mail

Un e-mail n’est pas qu’un simple message affiché dans la boîte de réception : c’est un objet structuré composé de plusieurs parties. Pour un analyste ou quelqu'un de la blue team, comprendre cette structure est essentiel pour reconstruire le chemin de l’e-mail, identifier des anomalies et extraire des artefacts utiles.

On distingue principalement les en-têtes et le corps du message.

En-tête de l’e-mail

L’en-tête (header) contient les métadonnées du message : informations sur l’expéditeur, le destinataire, le sujet, la date d’envoi, ainsi que tout le parcours du mail entre les différents serveurs.

On y trouve par exemple les champs :

• visibles pour l’utilisateur : From:, To:, Subject:, Date:, Reply-To:, Cc:, Bcc: (même si Bcc n’apparaît pas chez le destinataire) ;

• plus techniques : les lignes Received:, Message-ID:, Return-Path:, MIME-Version:, Content-Type:, ainsi que les résultats d’authentification (DKIM-Signature, Authentication-Results, SPF, DMARC, etc.).

Les lignes Received: sont ajoutées par chaque serveur SMTP qui traite le message, ce qui permet de reconstruire le chemin parcouru par l’e-mail. En pratique, certains en-têtes sont relativement fiables (en particulier ceux ajoutés par les serveurs de ton organisation) ; beaucoup d’autres champs peuvent être ajoutés.

En-têtes « X- » personnalisés

Les en-têtes commençant par X- (par exemple X-Originating-IP, X-Mailer, X-Spam-Status, etc.) sont des champs personnalisés ajoutés par des logiciels ou des infrastructures (clients de messagerie, passerelles antispam, relais SMTP, etc.).

Ils peuvent donner des informations intéressantes sur :

• le client utilisé pour envoyer le mail ;

• des scores antispam ;

• l’IP d’origine supposée ;

• des marquages internes de sécurité.

Les en-têtes d’un e-mail ne sont pas entièrement fiables : un attaquant peut modifier certains champs (par exemple l’expéditeur “From:” ou la date “Date:”) pour faire croire que le message vient d’une source légitime. On ne peut donc pas se baser uniquement sur ces valeurs pour prouver qui a envoyé le mail ou à quel moment il a réellement été envoyé. En analyse, on les considère donc comme des indicateurs, pas comme des preuves absolues, et on les croise avec d’autres informations (logs, SIEM, contexte).

Corps du mail

Le corps (body) d’un e-mail est la partie visible par le destinataire : c’est là que s’affichent le texte, la mise en forme et les éventuels éléments intégrés.

Il peut être :

• en texte brut (plain text)

• en HTML, avec du style, des images, des tableaux, des boutons, etc...

• ou en version multipart, c’est-à-dire plusieurs versions (plain + HTML) dans le même message

Le corps peut contenir :

• des hyperliens

• des images distantes (parfois utilisées comme pixels de suivi)

• des blocs HTML masqués ou obfusqués pour contourner certains filtres

• des pièces jointes (PDF, Word, ZIP, etc...)

D’un point de vue sécurité, c’est souvent dans le corps du mail que l’on trouve les éléments d’ingénierie sociale (texte manipulatoire, urgence, fausse autorité) et les vecteurs techniques (liens malveillants, formulaires suspects, instructions pour ouvrir un fichier joint).

Analyse d'un mail et collecte d'artefacts

Ne jamais analyser les e-mails de phishing sur un système professionnel ou personnel.

Il est recommandé de toujours utiliser une machine virtuelle ou un système « sale », comme un vieil ordinateur portable ou un ordinateur conçu spécifiquement pour les tâches de sécurité à risque

Idéalement, cette machine est :

• isolée du réseau (pas de partage avec l’AD, pas d’accès aux serveurs internes)

• facile à remettre à zéro (snapshot de VM, image système) après une analyse.

Une fois dans cet environnement contrôlé, l’idée est de travailler sur une copie du message (format .eml / .msg) plutôt que de l’ouvrir directement dans le client de messagerie d’entreprise. On peut alors inspecter :

• les en-têtes (headers) pour comprendre le chemin parcouru par l’e-mail, l’adresse réelle d’envoi, le domaine utilisé, les résultats SPF/DKIM/DMARC ;

• le corps du message, en affichant le HTML brut pour repérer les liens réels, les images distantes, les trackers éventuels ;

• les pièces jointes, en notant leur type, leur nom, leur taille, puis en calculant des empreintes (hashs) pour alimenter les IOC.

L’objectif est de collecter des artefacts réutilisables comme les adresses e-mail, domaines, URL, adresses IP, noms de fichiers, hash de pièces jointes, sujets récurrents, modèles de texte, etc...

Ces éléments pourront ensuite être corrélés dans le SIEM, ajoutés à des listes de blocage, ou utilisés pour rechercher d’éventuels autres destinataires dans l’organisation.

Remarque : La liste des outils présentés dans cette section n’est pas exhaustive. J’ai choisi de mettre en avant les outils les plus connus et les plus couramment utilisés en pratique, afin de disposer d’une base de travail solide. D’autres solutions existent pour chaque cas d’usage, et il est toujours possible d’enrichir ou d’adapter cette liste en fonction des besoins et de l’évolution des outils.

Analyse de l'e-mail

1. Récupération et ouverture du message

La première étape consiste à télécharger l’e-mail au format brut :

• depuis le client de messagerie, exporter le message au format .eml ou .msg

• ouvrir ce fichier dans un éditeur de texte (Sublime Text, VS Code, Notepad++, etc.).

L’objectif est de voir l’intégralité des en-têtes et du corps, sans interprétation par le client de messagerie.

2. En-têtes : collecte des artefacts

Dans les headers, plusieurs informations nous intéressent :

• Adresse d’envoi et d’affichage :

  • From: (expéditeur affiché)

  • Reply-To: (adresse de réponse, parfois différente et plus révélatrice)

  • Return-Path:, Message-ID:

• Destinataires : To:, Cc: (utile pour voir si c’est une campagne de masse ou très ciblée).

• Ligne d’objet : Subject:

• Date et heure : Date: (à croiser avec les logs si besoin).

Pour les trouver rapidement, on peut utiliser la fonction recherche de l’éditeur (Ctrl+F / Cmd+F).

IP et serveur d’envoi

On cherche ensuite les informations sur le serveur d’envoi :

• certains headers personnalisés indiquent directement une IP, par exemple X-Sender-IP ou X-Originating-IP

• sinon, on regarde les différentes lignes Received: pour remonter la chaîne de relais et repérer l’IP d’origine la plus probable (souvent l’une des premières lignes en partant du bas).

Une fois l’IP identifiée, on peut effectuer une recherche DNS inversée (reverse DNS) ou un WHOIS pour obtenir le nom d’hôte et plus d’infos sur le propriétaire :

• via des services en ligne de type whois / IP lookup (ex. DomainTools, ipvoid, etc.).

Ces éléments (IP, hostname) deviennent des artefacts techniques que l’on pourra corréler dans le SIEM ou vérifier dans des flux de menaces.

3. Corps du mail : contenu et structure

Dans le corps de l’e-mail, on regarde :

• le texte : ton, urgence, pression, impersonation, fautes, incohérences

• la présence de liens (URLs), de boutons “cliquables”

• les balises HTML (si message en HTML) :

  • <a href="..."> pour les liens

  • images distantes utilisées comme pixels de suivi

  • parties masquées ou obfusquées.

L’idéal est d’examiner le HTML brut pour voir :

• le texte affiché au destinataire (parfois “https://banque.fr”)

• l’URL réelle dans href (parfois totalement différente).

On évite évidemment de cliquer sur quoi que ce soit : tout ce travail se fait en lecture uniquement.

4. Collecte automatisée (ex. PhishTool)

En complément de la collecte manuelle, des outils comme PhishTool peuvent faciliter le travail :

• import du message (souvent au format .eml)

• extraction automatique des artefacts intéressants :

  • adresse d’envoi, sujet, destinataires, date/heure

  • IP et domaine d’envoi, DNS inversé

  • URLs présentes dans le corps

  • noms de fichiers joints et hash de fichiers.

Ce type d’outil peut aussi intégrer directement des vérifications de réputation (VirusTotal, WHOIS, etc.) et permettre de générer un rapport PDF d’enquête.

Analyse des URLs

Une fois l’e-mail décortiqué, on passe aux liens qu’il contient : ce sont souvent le vecteur principal pour le credential harvesting ou le dépôt de malware.

1. Extraction des URLs

Toujours sur le fichier .eml / .msg ouvert dans un éditeur de texte :

• rechercher le mot http pour repérer toutes les adresses http:// et https://

• repérer les balises HTML <a> :

  • l’attribut href="..." contient l’URL réelle

  • le texte entre <a> ... </a> est ce que voit l’utilisateur.

On note pour chaque lien :

• l’URL complète

• le domaine racine (ex : exemple.com), et éventuellement les sous-domaines (login.exemple.com, secure.exemple.com, etc.)

• la présence éventuelle de services de raccourcissement (Bitly, TinyURL, etc.) qui masquent la destination réelle.

2. Analyse statique des URLs (sans cliquer)

Pour analyser une URL suspecte, on utilise des outils en ligne adaptés, au lieu d’ouvrir la page dans un navigateur classique :

• des services de capture d’écran / rendu distant (type URL2PNG, URLScan, etc.) pour voir à quoi ressemble la page sans l’ouvrir nous-même

• des outils de réputation d’URL

  • plateformes comme VirusTotal, URLScan.io, etc..., qui indiquent si l’URL ou le domaine a déjà été signalé comme malveillant.

On peut également consulter des bases de menaces (threat feeds) qui recensent des liens malveillants :

• exemples : URLhaus, PhishTank, et d’autres services de blacklist / threat intelligence

• l’idée est de vérifier si l’URL, le domaine ou l’IP est déjà connu comme malveillant.

3. Analyse complémentaire (domaine / IP)

Selon le besoin, on peut approfondir :

• WHOIS du domaine (registrar, date de création, pays, lien avec d’autres domaines)

• résolution DNS, sous-domaines, certificats TLS

• réputation de l’IP associée (via des services type ipvoid).

Tous ces éléments deviennent des artefacts web (URL complète, domaine racine, IP associée) à intégrer dans l’enquête et potentiellement dans les règles de détection (SIEM, proxy, firewall, etc...).

Analyse des pièces jointes

Les pièces jointes sont un autre vecteur classique : documents Office avec macros, PDF piégés, archives ZIP, exécutables, etc.

1. Collecte des artefacts de fichier

Pour chaque pièce jointe, on collecte au minimum :

• le nom du fichier (et son extension)

• le type réel de fichier (via les propriétés, file sous Linux, etc.)

• le ou les hashs (empreintes cryptographiques).

Le nom de fichier peut parfois être utilisé comme indicateur dans certaines solutions EDR / antispam, mais ce n’est pas le plus fiable. Le plus important est la valeur de hachage, en particulier SHA256.

Les hachages MD5 et SHA1 ne sont plus considérés comme sûrs d’un point de vue cryptographique (collisions possibles), mais ils restent parfois utilisés pour des raisons de compatibilité. En sécurité moderne, SHA256 est la référence pour identifier un fichier.

Calcul des hash (Windows / PowerShell)

Dans une console PowerShell, depuis le répertoire qui contient le fichier :

# SHA256 (recommandé)
Get-FileHash .\fichier.exe

# MD5 (compatibilité, pas pour la sécurité)
Get-FileHash -Algorithm MD5 .\fichier.exe

# SHA1 (compatibilité, pas pour la sécurité)
Get-FileHash -Algorithm SHA1 .\fichier.exe

# Tout d'un coup (SHA256 + MD5 + SHA1)
Get-FileHash .\fichier.exe;
Get-FileHash -Algorithm MD5 .\fichier.exe;
Get-FileHash -Algorithm SHA1 .\fichier.exe;

Calcul des hash (Linux)

sha256sum fichier.exe
sha1sum fichier.exe
md5sum fichier.exe

On consigne au minimum le SHA256, les autres peuvent servir si certains outils anciens ne supportent que MD5/SHA1.

2. Réputation de fichiers

Avec le hash (plutôt que le fichier lui-même quand c’est possible), on interroge des services de réputation :

• VirusTotal : agrège de nombreux antivirus et moteurs d’analyse

• Talos File Reputation (Cisco) et autres plateformes équivalentes.

Certaines plateformes (comme Talos) demandent explicitement un hash SHA256.

Le but est de savoir :

• si le fichier est déjà connu comme malveillant

• à quelle famille de malware il peut être rattaché

• quels sont les IOC associés (domaines contactés, clés de registre, etc.).

3. Sandboxing / Analyse dynamique

Quand la réputation n’est pas claire ou que l’on veut comprendre le comportement, on peut recourir au sandboxing :

• exécuter le fichier dans un environnement confiné (sandbox, VM sacrifiable) ;

• observer :

  • les processus créés

  • les fichiers et clés de registre modifiés

  • le trafic réseau (tentatives de connexion à un serveur C2, téléchargement de modules supplémentaires, etc.).

Des plateformes d’analyse en ligne (par ex. Hybrid Analysis / “Analyse hybride” et autres sandbox publiques ou internes) permettent d’automatiser cette observation et de produire un rapport détaillé.

En comprenant comment fonctionne le malware, il devient plus facile de :

• mettre en place des signatures ou des règles de détection (SIEM, EDR, IDS…) ;

• enrichir les IOC ;

• renforcer les défenses pour bloquer des activités similaires à l’avenir.

Rédaction de rapport de phishing

Un rapport de phishing doit permettre de :

• décrire ce qui s’est passé

• lister les artefacts techniques (pour la détection / blocage)

• expliquer les décisions prises et pourquoi

• tracer qui a fait quoi, quand.

L’objectif n’est pas seulement de raconter l’histoire, mais de produire un document actionnable pour le SOC, le RSSI ou les équipes métiers.

Désinfection des artefacts

Lors de la rédaction d’un rapport de phishing, il est essentiel de désinfecter (defang) tous les artefacts techniques (URL, adresses IP…) afin d’éviter qu’un lecteur clique par erreur dessus ou que certains outils les interprètent comme des liens actifs. Pour cela, on applique quelques règles simples : remplacer chaque « . » par « [.] » dans les domaines et les adresses IP (8.8.8.8 devient 8[.]8[.]8[.]8), et transformer http en hxxp (https://exemple.com devient hxxps[://]exemple[.]com). L’outil CyberChef permet d’automatiser cette opération avec le module Defang.

Un profil déjà paramétré peut être utilisé à cette adresse : CyberChef_Defang.

Exemple de rapport :

Artefacts collectés :

• Expéditeur déclaré : facturation@fournisseur-xyz[.]com

• Répondre à (Reply-To) : support-compta@fournisseur-xyz-payments[.]com

• Date : 15/01/2026 – 09:42 (heure locale)

• IP du serveur d’envoi : 185[.]231[.]223[.]17

• DNS inversé : mail17[.]secure-smtp[.]host

• Destinataires : comptabilite@entreprise[.]fr

• Sujet : FACTURE EN RETARD – RÈGLEMENT IMMÉDIAT REQUIS

• URL : hxxps[://]portal-factures[.]com/login[.]php

• Pièces jointes :

  • Nom : Facture_4587_URGENT.pdf.exe

  • Type réel : exécutable Windows (PE)

  • Hash SHA256 : 7b3a6f4f1c1b0de0c08c5e24a9d1f12c6bd7f87c2f5a7e1f4c9b5c2d9e8af321

Description de l’e-mail : L’e-mail se présente comme un rappel de facture en retard provenant d’un fournisseur supposé “XYZ”. Le message précise qu’un montant significatif reste dû et qu’en l’absence de règlement immédiat, des frais supplémentaires et une suspension de services pourraient être appliqués. Le ton est formel mais très pressant. Deux voies d’action sont proposées au destinataire :

1. ouvrir la “facture détaillée” en pièce jointe ;

2. se connecter au “portail de paiement sécurisé” via un lien dans le corps du message.

L’e-mail cible directement le service comptabilité via une adresse générique (comptabilite@entreprise[.]fr), ce qui montre une tentative de phishing orienté métier.

Analyse de des artefacts malveillants :

L’adresse d’expéditeur facturation@fournisseur-xyz[.]com ressemble à une adresse de facturation classique, mais le domaine n’est pas celui du véritable fournisseur XYZ connu de l’entreprise (domaine officiel vérifié dans les contrats et factures légitimes). Le champ Reply-To: pointe vers support-compta@fournisseur-xyz-payments[.]com, ce qui est un premier indicateur de dissimulation : les réponses éventuelles seraient redirigées vers un domaine totalement différent, contrôlé par l’attaquant.

L’analyse de l’IP du serveur d’envoi 185[.]231[.]223[.]17 et du DNS inversé mail17[.]secure-smtp[.]host montre qu’il s’agit d’un service SMTP hébergé générique, sans lien avec le fournisseur légitime. Une recherche de réputation sur cette IP révèle qu’elle a déjà été utilisée dans d’autres campagnes de spam/phishing.

La pièce jointe Facture_4587_URGENT.pdf.exe est particulièrement suspecte :

• l’extension visible “.pdf” est suivie de “.exe”, ce qui peut être masqué dans certains environnements (Windows n’affichant parfois pas les extensions connues) ;

• le type réel du fichier est un exécutable Windows (et non un PDF) ;

• le hash SHA256 7b3a6f4f1c1b0de0c08c5e24a9d1f12c6bd7f87c2f5a7e1f4c9b5c2d9e8af321 ressort comme malveillant dans plusieurs moteurs VirusTotal, appartenant à une famille de trojans bancaires visant notamment les environnements entreprise.

L’URL hxxps[://]portal-factures[.]com/login[.]php renvoie vers un site imitant un portail de paiement/facturation, mais :

• le domaine portal-factures[.]com est récent, sans historique légitime, et n’est associé à aucun fournisseur connu de l’entreprise ;

• les vérifications sur URLScan et VirusTotal indiquent la présence d’un formulaire de connexion recueillant des identifiants, sans certificat ni mentions légales claires.

On conclut que l’e-mail combine :

• un malware distribué via la pièce jointe (trojan bancaire/exécutable) ;

• une tentative de credential harvesting via un faux portail de paiement.

L’attaque est donc classée comme phishing ciblé contre le service comptable, avec double vecteur (pièce jointe et URL).

Mesures mises en place / à mettre en place :

1. Blocage de la pièce jointe malveillante

   • Type d’action : règle de blocage sur la passerelle de messagerie / EDR

   • Valeur bloquée : hash SHA256 7b3a6f4f1c1b0de0c08c5e24a9d1f12c6bd7f87c2f5a7e1f4c9b5c2d9e8af321

   • Date / heure : 15/01/2026 – 10:05

   • Opérateur : Jean Bonbeur (Analyste SOC)

   • Justification : fichier identifié comme exécutable malveillant par plusieurs moteurs AV. Le blocage sur base de hash permet d’empêcher toute nouvelle livraison de ce fichier spécifique, sans impacter les échanges légitimes.

2. Blocage du domaine malveillant sur le proxy Web

   • Type d’action : blocage d’URL/domaine sur le proxy / filtrage Web

   • Valeur bloquée : portal-factures[.]com

   • Date / heure : 15/01/2026 – 10:09

   • Opérateur : Jean Bonbeur (Analyste SOC)

   • Justification : domaine non lié à un fournisseur réel, utilisé pour voler des identifiants de paiement. Aucun besoin métier identifié. Blocage global du domaine pour empêcher tout accès aux pages de phishing actuelles et futures.

3. Renforcement de la détection côté messagerie

   • Mise à jour des règles antispam pour renforcer le scoring sur :

     • sujets contenant des mentions d’urgence liées à des factures (“FACTURE EN RETARD”, “RÈGLEMENT IMMÉDIAT”, etc.) combinés avec des pièces jointes exécutables ;

   • Surveillance de nouveaux e-mails provenant de fournisseur-xyz[.]com et domaines similaires (typosquatting) pendant une période donnée.

4. Communication interne ciblée

   • Envoi d’une alerte de sensibilisation au service comptabilité, rappelant :

     • la procédure interne pour vérifier une facture ou un changement de coordonnées bancaires ;

     • la nécessité de ne jamais ouvrir de pièces jointes exécutables (.exe, .bat, .scr, etc...) reçues par e-mail ;

     • la consigne de transférer immédiatement au SOC tout e-mail suspect relatif à des paiements ou à des modifications de RIB.

5. Désinfection des artefacts dans le rapport

   • Toutes les URL, adresses IP et domaines mentionnés dans ce rapport ont été défangés (. → [.], http → hxxp) afin d’éviter tout clic accidentel ou interprétation automatique.

Modèle de rapport d’analyse de phishing

1. Artefacts collectés

• Expéditeur déclaré : exemple@domaine[.]com

• Répondre à (Reply-To) : exemple-reply@domaine[.]com

• Date de réception : JJ/MM/AAAA – HH:MM (heure locale)

• IP du serveur d’envoi : X[.]X[.]X[.]X

• DNS inversé (reverse DNS) : hostname[.]exemple[.]com

• Destinataires : prenom.nom@entreprise[.]fr (indiquer s’il s’agit d’un compte individuel, d’une liste ou d’une boîte fonctionnelle)

• Sujet : Sujet complet de l’e-mail

• URL(s) trouvée(s) (défangées) :

  • hxxps[://]exemple[.]domaine[.]com/path

  • hxxp[://]autre-lien[.]exemple[.]net

• Pièce(s) jointe(s) :

  • Nom : Nom_Fichier_1.ext

    • Type réel : PDF / DOCX / EXE / ZIP ...

    • Hash SHA256 : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

2. Description de l’e-mail

Décrire comment l’e-mail se présente du point de vue de l’utilisateur :

• Qui semble l’envoyer ? (banque, fournisseur, service interne…)

• Quel est le prétexte ? (facture, colis, sécurité de compte, alerte urgente…)

• Quel est le ton ? (urgent, menaçant, très commercial, trop insistant…)

• Quelle action est demandée ? (cliquer sur un lien, ouvrir une pièce jointe, répondre avec des infos, valider un paiement, etc.)

Exemple de formulation :

L’e-mail se présente comme une notification de sécurité provenant de <nom_du_service>. Le message indique que le compte de l’utilisateur aurait été compromis et l’invite à “vérifier immédiatement son identité” en cliquant sur un lien. Le ton est alarmiste et insiste sur le caractère urgent de l’action, sous peine de suspension du compte.

3. Analyse de(s) l’artefact(s) malveillant(s)

Ici tu expliques ce que tu déduis des artefacts : expéditeur, IP, domaine, URL, pièce jointe, etc.

Points à couvrir (adapter selon le cas) :

• Expéditeur / domaine :

  • L’adresse d’expéditeur est-elle légitime ou usurpée ?

  • Le domaine correspond-il à l’organisation réelle (ex : vrai domaine de la banque / du fournisseur) ?

  • Le Reply-To redirige-t-il vers un domaine différent ou suspect ?

• Serveur d’envoi :

  • L’IP et le reverse DNS sont-ils cohérents avec l’organisation supposée ?

  • L’IP ou le domaine du serveur d’envoi ont-ils une mauvaise réputation (spam/phishing connus) ?

• URL(s) :

  • Domaine principal (racine) : légitime ou inconnu ?

  • Sous-domaine trompeur (ex : secure-login, support-client, nom de marque) ?

  • Résultat des vérifications (VirusTotal, URLhaus, URLScan, etc.) ?

• Pièces jointes :

  • Type réel du fichier (document, archive, exécutable…)

  • Résultat de la réputation (VirusTotal, Talos…)

  • Comportement suspect identifié (si sandbox utilisée) ?

Exemple de phrase type :

L’adresse d’expéditeur support@banque-exemple[.]com semble légitime, mais l’analyse des en-têtes montre que l’e-mail a été envoyé depuis une IP hébergée chez un fournisseur tiers, sans lien avec la banque. L’URL contenue dans le message pointe vers hxxps[://]secure-verification[.]client-login[.]net, un domaine récemment créé, identifié comme malveillant par plusieurs moteurs de réputation. La pièce jointe Avis_securite.pdf.exe est en réalité un exécutable Windows, détecté comme trojan par VirusTotal.

4. Mesures mises en place / à mettre en place

Décrire clairement ce qui a été fait (ou doit l’être), avec traçabilité.

Pour chaque mesure :

• Action n°X :

  • Type : (blocage domaine / blocage URL / blocage sujet / blocage hash de pièce jointe / alerte / recherche globale, etc.)

  • Valeur ciblée : valeur défangée

  • Système concerné : (passerelle de messagerie, proxy Web, EDR, SIEM…)

  • Date / heure : JJ/MM/AAAA – HH:MM

  • Opérateur : Nom Prénom / équipe

  • Justification :

    • Pourquoi cette valeur ?

    • Impact attendu / pas d’impact métier prévu ?

Exemple :

Action 1 – Blocage de l’URL malveillante

• Type : Blocage d’URL sur le proxy Web

• Valeur : hxxps[://]secure-verification[.]client-login[.]net

• Système : Proxy Web d’entreprise

• Date / heure : 15/01/2026 – 14:32

• Opérateur : Jean Dupont (SOC)

• Justification : Domaine identifié comme malveillant, utilisé pour une page de phishing de type credential harvesting. Aucun usage légitime connu pour l’entreprise.

Action 2 – Blocage de la pièce jointe par hash

• Type : Blocage de fichier sur la passerelle de messagerie / EDR

• Valeur : SHA256 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

• Date / heure : …

• Opérateur : …

• Justification : Fichier détecté comme malware par plusieurs moteurs. Blocage sans impact attendu.

Action 3 – Communication interne / sensibilisation

• Type : Alerte interne

• Cible : Utilisateurs / équipe métier concernée

• Contenu : Rappel des bonnes pratiques, capture d’écran de l’e-mail (sans artefacts cliquables), procédure à suivre en cas de doute.

5. Avertissement sur la désinfection des artefacts

Remarque : Toutes les URL, adresses IP et domaines présents dans ce rapport ont été désinfectés (defang) (. → [.], http → hxxp) afin d’éviter tout clic accidentel ou toute interprétation automatique par les outils. Pour l’analyse technique, ils peuvent être “refangés” dans un environnement sécurisé si nécessaire.