Réagir aux premières minutes d’un incident suspecté

Parcours « Débuter en cybersécurité » — étape 12/12

← 11IoC ou TTP pour détecter une compromissionFin du parcours

Réagir aux premières minutes d’un incident suspecté

Les premières minutes fixent souvent la qualité de toute la réponse : préserver des traces exploitables tout en empêchant une compromission de se propager. La priorité n’est pas de réparer vite, mais de stabiliser la situation sans détruire ce qui permettra de comprendre, contenir et notifier correctement.

Explication de la marmotte

Découvrir une anomalie de sécurité ressemble à trouver une fuite d’eau derrière un mur : il faut empêcher l’eau de gagner les autres pièces sans casser le mur avant d’avoir compris d’où elle vient. Les premières décisions servent à garder des indices et à éviter que le problème devienne plus grand.

→ Lire l’explication complète de la marmotte

Isolement réseau et préservation de la mémoire

Le compromis central est brutal : isoler vite limite la propagation, mais chaque action modifie potentiellement l’état de la machine. La recommandation est donc de couper les communications, pas l’alimentation. Cette règle reste valable tant qu’aucun danger physique, incendie ou instruction des autorités compétentes n’impose autre chose.

1. Qualifier l’anomalie sans enquêter pendant une heure

Noter immédiatement l’heure locale et universelle, le nom de l’équipement, l’adresse IP, l’utilisateur connecté, la source de l’alerte et l’observation factuelle. Écrire « processus inconnu rundll32.exe lançant une connexion vers 203.0.113.10 » ; éviter « poste piraté ». Le premier est vérifiable, le second est une hypothèse.

Déclencher l’isolement immédiat devant au moins un de ces signaux :

• exécution d’un binaire inconnu depuis un répertoire temporaire ou profil utilisateur ;
• authentifications inhabituelles, élévation de privilèges ou création de comptes ;
• connexions sortantes répétées vers des destinations non attendues ;
• chiffrement, suppression ou renommage massive de fichiers ;
• désactivation de l’antivirus, de l’EDR (Endpoint Detection and Response) ou de la journalisation ;
• alerte de fuite d’identifiants, de jeton d’accès ou de clé privée.

Une alerte isolée du SIEM (Security Information and Event Management) ne prouve pas une compromission. En revanche, une machine qui chiffre un partage réseau n’attend pas un comité de qualification avec café et slides pastel.

2. Déconnecter le poste, ne pas l’éteindre

Pour un poste de travail suspect, retirer le câble réseau et désactiver les interfaces sans fil. Si l’accès est distant, demander une intervention locale ou appliquer une règle d’isolement via l’EDR, à condition que cette action ne redémarre pas l’agent.

Ne pas éteindre, redémarrer, mettre en veille ni forcer l’arrêt du système. La mémoire vive peut contenir des processus injectés, des connexions actives, des clés de chiffrement, des jetons de session et des commandes reçues. Après extinction, ces données disparaissent. Elles ne reviennent pas par magie parce qu’un outil de forensic possède un logo intimidant.

Pour un serveur de production, l’isolement doit être proportionné. Couper brutalement un serveur d’identité, une base de données ou un nœud d’orchestration peut provoquer une panne plus large et détruire des journaux distribués. Bloquer d’abord les flux sortants non nécessaires, les accès d’administration externes et les chemins de propagation connus. La cartographie réseau doit permettre de savoir quels flux sont réellement nécessaires avant l’incident, pas après.

3. Éviter les gestes qui détruisent les preuves

Ne pas supprimer de fichiers, lancer d’antivirus « nettoyage », vider les répertoires temporaires, modifier des règles de pare-feu à l’aveugle ni restaurer immédiatement une sauvegarde sur l’hôte concerné. Ces actions peuvent effacer les artefacts, écraser les journaux et informer l’attaquant que sa présence a été repérée.

Ne pas non plus saisir un mot de passe sur une machine suspecte, même pour « vérifier un accès ». Un enregistreur de frappe ne respecte pas les bonnes intentions. Utiliser un poste sain pour modifier les identifiants, révoquer les sessions et consulter les consoles d’administration.

Escalade sécurité, hiérarchie et données personnelles

L’escalade suit l’impact potentiel, pas l’organigramme idéal. Prévenir trop tôt l’équipe sécurité coûte quelques minutes de triage ; prévenir trop tard coûte souvent des jours de reconstruction. En cas de doute raisonnable, déclarer l’événement comme suspect et laisser l’équipe de réponse à incident le requalifier.

4. Prévenir l’équipe sécurité en premier

Contacter le canal d’urgence défini, puis le responsable sécurité si le canal ne répond pas. Transmettre uniquement les faits collectés : heure, équipement, utilisateur, symptôme, actions déjà menées, statut réseau et risque de propagation observé.

Indiquer explicitement si des identifiants à privilèges ont été utilisés sur l’équipement, si des secrets applicatifs peuvent y résider ou si l’hôte accède à des partages, sauvegardes, annuaires ou consoles cloud. Un poste administrateur compromis n’est pas un incident de poste : c’est un problème d’identité qui attend de devenir un problème d’infrastructure. La gestion des comptes et des facteurs d’authentification relève de la page Identités et accès.

5. Alerter la hiérarchie selon l’impact opérationnel

Prévenir la hiérarchie technique dès qu’un isolement dégrade un service, qu’un serveur est concerné ou qu’une propagation est possible. La hiérarchie arbitre la continuité d’activité, elle ne remplace pas l’analyse technique. Éviter les formulations dramatiques sans élément factuel : annoncer un niveau d’incertitude et la prochaine décision attendue.

Une grille opérationnelle suffit :

Gravité estimée	Exemples	Action immédiate
Faible	alerte isolée, pas d’exécution confirmée	sécurité, conservation des journaux
Élevée	poste isolé, compte potentiellement volé	sécurité et hiérarchie technique
Critique	chiffrement actif, privilèges élevés, propagation	sécurité, hiérarchie, cellule de crise si prévue

6. Saisir le DPO si des données personnelles sont plausiblement touchées

Le DPO (Délégué à la protection des données) doit être alerté quand l’incident peut concerner des données personnelles : extraction de base clients, accès anormal à des dossiers RH, exposition d’une boîte aux lettres ou transfert sortant de fichiers identifiants. Il ne faut pas attendre la preuve complète d’une exfiltration pour signaler le risque.

Le rôle du DPO est d’évaluer les obligations de protection des données avec les équipes compétentes. Cette page ne donne aucun conseil juridique : elle impose seulement de conserver les éléments techniques nécessaires à cette évaluation, notamment les catégories de données accessibles, les comptes impliqués et les destinations réseau observées.

Collecte minimale de preuves et commandes reproductibles

La collecte minimale vise à empêcher l’écrasement des journaux et à donner un point de départ à une équipe spécialisée. Elle ne remplace pas une acquisition forensique. Une copie de fichier n’est pas une image disque, et un export de journal n’est pas une preuve absolue : les horloges dérivent, les journaux sont altérables et certains attaquants les effacent précisément parce qu’ils savent lire.

7. Créer une fiche d’incident horodatée

Depuis un poste sain ou un ticket d’incident, ouvrir une fiche avec :

• identifiant de l’incident ;
• heure de découverte, fuseau horaire inclus ;
• personne ayant constaté l’événement ;
• hôte, adresse IP, adresse matérielle et système concerné ;
• actions menées, dans leur ordre exact ;
• emplacement des exports et sommes de contrôle ;
• personnes prévenues et heure de notification.

Utiliser une heure synchronisée par NTP (Network Time Protocol), le protocole de synchronisation d’horloge. Une chronologie sans fuseau horaire est un puzzle dont plusieurs pièces viennent d’une autre boîte.

8. Capturer les éléments visibles et les journaux volatils

Prendre des captures d’écran horodatées des alertes, de la console de supervision et des processus suspects. Inclure l’horloge système dans au moins une capture. Ne pas recadrer ni annoter l’original ; les commentaires vont dans la fiche d’incident.

Exporter les journaux pertinents avant leur rotation : journaux système, authentification, proxy, pare-feu, VPN (Virtual Private Network), EDR et identité. Conserver aussi les journaux centralisés, souvent moins manipulables que ceux du poste local. Les fondations de journalisation et de supervision doivent définir rétention, synchronisation d’horloge et accès de secours avant l’incident.

9. Exécuter une collecte limitée sur Linux ou Windows

Lancer les commandes depuis une session déjà ouverte, sans installer d’outil supplémentaire sur l’hôte. Installer un collecteur en pleine alerte modifie le système et ajoute un paquet de variables. L’industrie adore appeler cela une « plateforme de réponse unifiée » ; la machine compromise, elle, s’en moque.

# Linux : créer un répertoire daté et relever l'heure UTC.
sudo mkdir -p /var/tmp/ir-$(date -u +%Y%m%dT%H%M%SZ)
IR_DIR=$(find /var/tmp -maxdepth 1 -type d -name 'ir-*' | sort | tail -n 1)

# Conserver processus, connexions et sessions sans interrompre l'hôte.
ps auxww > "$IR_DIR/processus.txt"
ss -plantue > "$IR_DIR/connexions.txt"
who -a > "$IR_DIR/sessions.txt"
ip address show > "$IR_DIR/interfaces.txt"

# Exporter les journaux récents, puis calculer une empreinte de contrôle.
journalctl --since "24 hours ago" --no-pager > "$IR_DIR/journal-24h.txt"
sha256sum "$IR_DIR"/* > "$IR_DIR/SHA256SUMS.txt"

Sous Windows, exporter les journaux avec wevtutil epl System system.evtx et wevtutil epl Security security.evtx depuis une console administrateur déjà autorisée. Copier ensuite les exports vers un stockage contrôlé et calculer leur empreinte avec Get-FileHash -Algorithm SHA256. Noter le support de destination, son propriétaire et l’heure de copie.

Ne pas ouvrir un exécutable suspect pour « voir ce qu’il fait », ni transférer des artefacts vers une messagerie ordinaire. Les pièces jointes douteuses ont une carrière étonnamment longue dans les boîtes partagées.

Contention des comptes, secrets et accès latéraux

L’isolement d’un poste ne suffit pas si l’attaquant a déjà obtenu des identifiants, des jetons ou des clés. La machine arrêtée reste peut-être une source de traces ; l’identité associée, elle, doit être traitée comme suspecte jusqu’à preuve contraire.

10. Révoquer selon le type de secret compromis

Révoquer les sessions actives, jetons d’accès, clés API (Application Programming Interface), certificats clients et comptes de service utilisés sur l’hôte. Changer un mot de passe seul ne coupe pas nécessairement les sessions existantes ni les jetons déjà émis. La révocation doit couvrir le mécanisme qui a accordé l’accès.

Pour une clé privée exposée, générer une nouvelle paire de clés, déployer le nouveau certificat, puis révoquer l’ancien selon les capacités de l’infrastructure. Pour un secret applicatif, effectuer une rotation contrôlée en vérifiant les dépendances. La rotation à l’aveugle peut provoquer une panne généralisée ; ne rien faire peut laisser une porte ouverte. Le choix dépend de l’exposition et du privilège associé, pas de la peur d’un voyant rouge.

11. Chercher la propagation sans contaminer les preuves

Depuis les consoles centralisées, rechercher les mêmes indicateurs sur les équipements comparables : nom de fichier, empreinte SHA-256, compte, adresse de destination, commande ou tâche planifiée. Éviter de se reconnecter directement aux autres hôtes suspects avec un compte privilégié tant que la stratégie de confinement n’est pas définie.

Examiner les événements d’authentification autour de la première occurrence connue. Une compromission est souvent détectée au milieu de sa chronologie, pas au début. Les journaux d’identité, de réseau et de sauvegarde permettent de déterminer si l’accès latéral a précédé l’alerte visible.

Conditions d’exploitation avant le prochain incident

Cette procédure ne garantit ni l’absence d’exfiltration ni l’éradication d’un attaquant. Elle donne du temps, réduit le rayon de propagation et préserve des éléments pour décider. La réponse complète exige une capacité de forensic, une procédure de crise, des contacts testés et une architecture qui produit des journaux exploitables.

Maintenir un inventaire des actifs, propriétaires, flux réseau, comptes à privilèges et dépendances de sauvegarde. Tester l’isolement EDR, les listes de contacts et l’accès aux journaux hors bande. Vérifier que les sauvegardes sont séparées des identités d’administration courante et que leur restauration est testée. Une sauvegarde non restaurée est une théorie intéressante, au même titre qu’un parachute encore dans son emballage.

Définir à l’avance les accès d’urgence à la console cloud, au gestionnaire de secrets et aux équipements réseau. Ces accès doivent être protégés par des facteurs distincts, journalisés et régulièrement revus. Les menaces et scénarios d’attaque aident à prioriser ces préparatifs selon les chemins de compromission réalistes.

🐝 Ce qui arrive si on s’en passe

Sans procédure arrêtée à l’avance, chaque découverte se traite à l’improvisation : plusieurs personnes interviennent en parallèle sur le même hôte, les actions se recouvrent et plus personne ne sait quel changement vient de l’attaquant ou de l’intervenant. Sans horodatage commun ni empreinte de contrôle sur les exports, les éléments collectés restent invérifiables et une équipe spécialisée ne peut plus établir une chronologie fiable, ni situer le point de départ réel de la compromission. Sans seuils d’escalade définis, la qualification consomme les minutes pendant lesquelles la rotation des journaux efface les traces les plus utiles. Sans contacts testés, l’alerte circule par les canaux ordinaires, parfois via la messagerie déjà exposée. La reprise se fait alors à l’aveugle : restauration sur un hôte dont l’état reste inconnu, secrets laissés valides, périmètre touché jamais délimité.

🦫 Explication de la marmotte 🍫

Quand une activité anormale est découverte, il faut d’abord empêcher l’ordinateur ou le serveur concerné de communiquer avec les autres systèmes. Pour un poste, couper le réseau limite la propagation. Il ne faut pas l’éteindre, car sa mémoire contient parfois des informations qui disparaissent à l’arrêt : programmes en cours, connexions ouvertes et éléments utilisés pour accéder à des services.

Il faut ensuite noter ce qui a été vu, avec l’heure, le nom de la machine et les actions déjà faites. Ces notes évitent que plusieurs personnes modifient la situation sans savoir ce qui a changé. L’équipe de sécurité doit être prévenue rapidement, puis la hiérarchie technique si le service risque d’être perturbé. Si des informations sur des personnes peuvent avoir été vues, copiées ou envoyées, le responsable de leur protection doit aussi être informé.

Avant que les traces ne soient remplacées par de nouvelles, il faut copier les journaux, les listes de programmes actifs et les connexions réseau. Ces copies doivent être conservées avec une empreinte de contrôle, une valeur calculée qui permet de détecter une modification. Enfin, les mots de passe, accès temporaires et clés présents sur la machine peuvent devoir être remplacés. Couper le réseau ne suffit pas si quelqu’un possède déjà un moyen de se connecter ailleurs.

À lire aussi

• Configurer une détection open source avec WazuhGuide pratique pour centraliser les journaux, installer Wazuh et détecter les premières tentatives d’accès suspectes sans SIEM commercial.
• Préparer la capture réseau pour des preuves légalesGuide pratique pour positionner des captures réseau, définir leur rétention et préserver leur intégrité avant un incident.
• Détecter l’impossible travel sur les connexionsGuide pratique pour déployer la détection d’anomalies de connexion par impossible travel et géolocalisation incohérente.
• Exécuter un threat hunting à partir d'une hypothèseGuide pas-à-pas pour préparer, exécuter et pérenniser un exercice de threat hunting fondé sur une hypothèse vérifiable.

Pages voisines

La citent

• Évasion de VM et isolation matérielle des hyperviseurs
• SIEM open source coûte-t-il vraiment moins cher

Réagir aux premières minutes d’un incident suspecté

Elle cite

• ⇄Lien dans les deux sens :Réponse à incident NIST SP 800-61r3, cycle complet et architecture
• Analyse mémoire et réseau après un incident
• Forensics numérique et chaîne de conservation après incident

⇄ : les deux pages se citent l’une l’autre.