Post-Block Blindness
- Catégorie
- Detection & Response Process
- Publiée
- 29 juin 2026
- Mise à jour
- 28 août 2026
The Failure
Un contrôle de détection sur poste bloque une technique — exécution d’un binaire, tentative de mouvement latéral, début de chiffrement. L’alerte est classée « bloqué », donc « traité ». Personne ne reconstruit ce qui a précédé le blocage (comment l’attaquant est arrivé en position de tenter cette technique) ni ce qui a suivi (ce qu’il fait maintenant avec les accès qu’il conserve).
Le pattern est structurel, pas accidentel : le processus de triage mesure le statut de l’alerte, pas l’état de l’adversaire. La file d’attente incite à fermer, l’outil présente le blocage comme un verdict final, et aucune étape du processus n’exige d’établir une chronologie. Or un blocage est un point de données sur une technique à un instant donné — pas une conclusion sur l’intrusion. Le contrôle a fait son travail ; le processus s’arrête là où le sien commençait.
Why It Matters
Un attaquant qui subit un blocage n’abandonne pas : il apprend. Le blocage lui coûte une technique ; il pivote vers une autre, souvent moins bien couverte. Pendant ce temps, la défense considère l’affaire close — c’est l’asymétrie du pattern : le même événement informe l’attaquant et rassure le défenseur.
Concrètement : l’accès initial est conservé (identifiants valides, session ouverte, mécanisme de persistance déjà posé), la progression continue par d’autres moyens, et la découverte réelle intervient des semaines plus tard, souvent au moment de l’impact. La fenêtre entre le blocage et la découverte est du temps de séjour offert.
Le coût se paie une seconde fois pendant l’investigation : on retrouve l’alerte « bloquée », fermée sans analyse. Le signal existait — daté, localisé, exploitable — et n’a déclenché aucune investigation. C’est la conclusion la plus fréquente et la plus évitable des post-mortems.
How to Identify It
Prenez les dix dernières alertes fermées avec un verdict « bloqué » ou « mis en quarantaine », et vérifiez pour chacune :
- existe-t-il une trace d’investigation au-delà du verdict de l’outil — d’où venait le binaire, quel compte était en jeu, que s’est-il passé sur la machine dans les 30 minutes avant et après ?
- l’analyste a-t-il regardé si la même technique a été tentée ailleurs ?
Puis interrogez le processus lui-même :
- votre procédure de triage distingue-t-elle formellement « la technique a été bloquée » de « l’intrusion est terminée » ?
- un blocage sur un serveur, un contrôleur d’annuaire ou un compte à privilèges déclenche-t-il un traitement différent d’un blocage sur un poste bureautique ?
Mesure simple : le taux d’alertes « bloquées » ayant conduit à une recherche de contexte. S’il est proche de zéro, le pattern est présent — indépendamment de la qualité de l’outillage.
Fix Before the Incident
Poser une règle de processus explicite : un blocage ouvre une investigation, il ne la ferme pas.
- Définir un standard minimal de contextualisation post-blocage : origine du fichier ou de l’action, compte impliqué, chronologie de la machine sur une fenêtre encadrant l’événement, recherche de la même technique sur le reste du parc.
- Prioriser par actif et par compte, pas par verdict : un blocage sur un serveur d’infrastructure ou un compte d’administration escalade systématiquement, même « réussi ».
- Écrire un playbook post-blocage court, avec des seuils d’escalade nets : récidive sur la même machine, technique de fin de chaîne (chiffrement, effacement de sauvegardes), cible à privilèges.
- Mesurer le temps de contextualisation et le taux d’escalade post-blocage, pas seulement le temps de fermeture — ce qu’on mesure est ce que l’équipe optimise.
If You’re Already in an Incident
L’historique des blocages devient une source d’investigation de premier ordre :
- relire tous les blocages sur la rétention disponible (90 jours si possible) pour les machines et comptes du périmètre : ils datent souvent l’intrusion plus précisément que l’alerte qui a déclenché l’incident ;
- traiter chaque blocage passé comme un point de chronologie gratuit — machine, compte, technique, horodatage — et les intégrer à la frise de l’incident ;
- traiter les machines à blocages historiques comme périmètre à vérifier en priorité, même si rien d’autre n’y a été vu ;
- ne jamais supposer qu’une technique bloquée n’a pas réussi ailleurs par une autre voie : chercher l’objectif de la technique (le mouvement latéral, l’élévation), pas seulement sa forme.
Le réflexe inverse — écarter les blocages parce qu’ils ont « marché » — reproduit le pattern pendant l’incident lui-même.
Contrôles associés
- CIS Controls v8 — 17.4
- CIS Controls v8 — 17.8
- NIST CSF 2.0 — DE.AE-02
- NIST CSF 2.0 — RS.AN-03
- ISO 27001:2022 — A.5.25
- ISO 27001:2022 — A.5.26