Imaginez la scène : un email arrive dans votre boîte, il ressemble trait pour trait à une notification Docusign. Un document important vous attend, il suffit de cliquer pour le signer. Vous cliquez. Vous entrez vos identifiants. Et là, quelque chose cloche — la page ne répond plus normalement. En quelques secondes, vous réalisez que vous venez de donner vos credentials à un cybercriminel.
Ce scénario n'est pas fictif. C'est l'un des vecteurs d'attaque les plus courants en 2025, et il est à l'origine de plus de 90% des cyberattaques dans le monde selon la CISA. C'est aussi le point de départ d'un exercice que j'ai réalisé récemment : construire de A à Z un Playbook de Réponse à Incident Phishing, un document structuré qui guide une équipe sécurité pas à pas lorsqu'une telle attaque survient.
Voici la méthodologie complète, les concepts clés, et les livrables produits.
Pourquoi un playbook ?
Quand un incident de sécurité se produit, le stress et l'urgence font perdre un temps précieux. Sans procédure définie, chacun improvise, les actions se chevauchent, et pendant ce temps l'attaquant continue d'exploiter la brèche.
Un playbook résout ce problème en apportant trois choses essentielles :
- La rapidité — les étapes sont prédéfinies, pas besoin de réfléchir sous pression
- La coordination — chaque membre de l'équipe sait exactement ce qu'il doit faire
- La traçabilité — chaque action est documentée, ce qui est indispensable pour les analyses post-incident et les obligations légales
Le playbook que j'ai construit suit le modèle PICERL (Preparation → Identification → Containment → Eradication → Recovery → Lessons Learned), aligné avec le framework MITRE ATT&CK et les recommandations du NIST SP 800-61.
Étape 1 — Comprendre comment l'attaquant a opéré (TTPs)
Avant de savoir comment répondre, il faut comprendre comment l'attaque fonctionne. En cybersécurité, on parle de TTPs — Tactics, Techniques and Procedures — soit la façon dont un attaquant opère.
La référence en la matière, c'est le framework MITRE ATT&CK, une base de données collaborative qui répertorie toutes les techniques observées dans de vraies attaques. Pour notre scénario Docusign, les TTPs identifiés sont :
| ID MITRE | Technique | Ce qui s'est passé |
|---|---|---|
T1566.002 |
Spearphishing Link | L'email contenait un lien vers le faux site |
T1056.003 |
Web Portal Capture | Le faux formulaire a capturé les credentials |
T1539 |
Steal Web Session Cookie | Vol potentiel du cookie de session |
T1036 |
Masquerading | Le site imitait visuellement Docusign |
T1583.001 |
Acquire Infrastructure | L'attaquant avait enregistré un domaine typosquatté |
Ce travail de mapping est fondamental : il permet de construire des procédures de réponse précises plutôt que génériques. On ne répond pas "à un phishing" en général, on répond à des techniques précises, avec des actions adaptées à chacune.
Étape 2 — Structurer le playbook
Un bon playbook, c'est d'abord une structure claire. Quatre éléments sont indispensables.
Les rôles et responsabilités — qui fait quoi pendant l'incident : l'Incident Commander qui coordonne, l'Analyste SOC qui détecte et analyse, l'Administrateur Système qui désactive les comptes, le DPO qui gère les obligations légales...
Les canaux de communication — une règle d'or souvent oubliée : ne jamais utiliser les systèmes potentiellement compromis pour communiquer sur l'incident. Un canal dédié et sécurisé est défini à l'avance.
Les niveaux de sévérité — notre scénario correspond au niveau Élevé (credentials utilisateur compromis), avec un SLA de réponse inférieur à une heure. Un incident avec des credentials administrateur serait Critique, avec un SLA de 15 minutes.
La timeline cible — de T+0 (signalement) à T+48h (clôture du ticket), chaque étape a un timing défini qui permet de mesurer l'efficacité de la réponse.
Étape 3 — Les IOCs : savoir ce qu'on cherche
Les Indicateurs de Compromission (IOCs) sont les traces laissées par l'attaquant. Les identifier à l'avance permet de les détecter rapidement en cas d'incident.
Pour un phishing de type credential harvesting, on surveille quatre catégories :
Réseau — domaines typosquattés (docusign-secure[.]net),
certificats SSL émis récemment sur des domaines inconnus, requêtes POST vers des
serveurs non répertoriés.
Compte utilisateur — connexions depuis des localisations inhabituelles, authentifications hors des horaires normaux, changement de mot de passe soudain, nouvelles sessions sur des appareils non reconnus.
Email — expéditeur dont le domaine échoue aux vérifications
SPF/DKIM/DMARC, URLs raccourcies dans le corps du message, pièces jointes
.html simulant un formulaire de connexion.
Endpoint — processus inconnus lancés après la visite du site frauduleux, modifications du fichier hosts, extensions navigateur installées silencieusement.
Un concept utile pour prioriser : la Pyramid of Pain. Les IPs et hashs de fichiers sont en bas de la pyramide — l'attaquant les change en quelques heures. Les TTPs sont en haut — ils restent stables pendant des années. C'est là qu'il faut concentrer la surveillance.
Étape 4 — Les procédures concrètes
C'est le cœur opérationnel du playbook. Pour chaque TTP identifié, une procédure détaille les actions à mener phase par phase.
Pour le cas le plus critique — les credentials saisis sur le faux portail (T1056.003) — la procédure se déroule ainsi :
- Identification : confirmer la saisie via les logs proxy (requête POST vers un domaine inconnu)
- Containment : désactiver immédiatement le compte dans Active Directory ou l'IAM
- Eradication : réinitialiser le mot de passe, invalider toutes les sessions actives, révoquer les tokens OAuth
- Recovery : recréer le compte avec un MDP fort (16+ caractères) et activer un MFA résistant au phishing (FIDO2 de préférence, pas un simple SMS)
La timeline idéale : compte désactivé à T+30 min, investigation complète à T+1h, compte restauré avec MFA à T+2h.
Étape 5 — La boîte à outils
Un playbook sans outils, c'est une recette sans ingrédients. Les outils sont organisés par phase :
- Détection : SIEM (Splunk, Microsoft Sentinel), EDR (CrowdStrike, Defender), Email Gateway (Proofpoint)
- Investigation : VirusTotal, URLScan.io, DNSTwist pour les domaines typosquattés, MXToolbox pour les vérifications email
- Forensique : Autopsy pour le disque, Volatility pour la mémoire RAM, Wireshark pour le trafic réseau
- Containment : Active Directory, IAM (Okta), Firewall, DNS Filtering
Étape 6 — Récupération et obligations légales
La récupération ne se limite pas à remettre le compte en service. Avant toute restauration, il faut évaluer les dégâts : des données ont-elles été exfiltrées ? Des règles de redirection email ont-elles été créées ? Des applications tierces ont-elles été autorisées pendant la compromission ?
Pour les backups, la règle des 3-2-1 s'applique : 3 copies des données, sur 2 supports différents, dont 1 hors ligne (air-gapped). En cas de doute sur la machine victime : on réimage. Un système potentiellement compromis ne retourne jamais en production sans certitude absolue.
Côté légal, si des données personnelles ont été exposées, le RGPD impose une notification à la CNIL dans les 72 heures (Article 33). C'est une obligation souvent sous-estimée mais qui peut avoir de lourdes conséquences en cas de manquement.
Les livrables produits
L'exercice ne s'est pas arrêté à la théorie. Trois livrables concrets ont été produits :
Un flowchart interactif (fichier HTML autonome) qui représente visuellement tout le processus de réponse, de la détection à la clôture, avec des branches décisionnelles et un panneau de détail cliquable sur chaque nœud.
Une application web interactive également en HTML autonome, comprenant un dashboard avec la progression globale, une checklist PICERL de 25 tâches cochables (avec sauvegarde locale), un tableau d'IOCs filtrable par catégorie, une boîte à outils classée par phase, et une timeline détaillée. Le tout fonctionne hors ligne, sans installation, avec un simple double-clic.
Un rapport PDF de méthodologie de 8 pages, qui documente l'ensemble de la démarche avec tous les tableaux, procédures, et références — utilisable comme support de cours ou de présentation.
Ce qu'on retient
Construire un playbook de réponse à incident, c'est avant tout un exercice de pensée structurée sous contrainte. On apprend à :
- Mapper des comportements réels d'attaquants sur un framework de référence (MITRE ATT&CK)
- Transformer des connaissances théoriques en procédures opérationnelles actionnables
- Anticiper les obligations légales souvent oubliées dans le feu de l'action
- Produire des livrables utilisables par une vraie équipe sécurité
Le phishing reste en 2025 le vecteur d'entrée numéro un des cyberattaques. Avoir un playbook structuré n'est plus une option — c'est une nécessité pour toute organisation qui prend sa sécurité au sérieux.
Cet article fait partie d'une série sur la cybersécurité et la réponse à incident.
Sources : MITRE ATT&CK (attack.mitre.org), CISA Advisories, NIST SP 800-61, Verizon DBIR 2025