Un serveur semble compromis — le redémarrer ou l'éteindre règle-t-il le problème ?
Réponse courte
Non. La plupart des vraies intrusions établissent une persistance (services, tâches planifiées, clés de démarrage, implants) qui survit à un redémarrage, donc l'attaquant revient simplement. Pire, éteindre efface les preuves volatiles — processus en cours, connexions réseau, malware en mémoire et clés de chiffrement — dont vous avez besoin pour cadrer l'incident. La bonne action est de confiner en isolant l'hôte tout en préservant la mémoire, puis d'enquêter. Redémarrer ou éteindre comme « solution » est un réflexe néfaste.
Le réflexe « éteindre et rallumer » est profondément ancré dans l'informatique. Face à une compromission, il se retourne deux fois contre vous : il ne supprime généralement pas l'attaquant, et il détruit les preuves mêmes qui permettraient de comprendre ce qui s'est passé.
Pourquoi un redémarrage n'éjecte pas l'attaquant
Les intrus compétents ne dépendent pas d'un seul processus en cours — ils établissent une persistance pour survivre exactement au type de réinitialisation que vous êtes tenté de faire. Les mécanismes courants incluent :
- Services et tâches planifiées qui relancent l'implant au démarrage.
- Clés de registre Run et dossiers de démarrage sous Windows.
- Tâches cron, unités systemd ou scripts d'init modifiés sous Linux.
- Abonnements WMI, détournements de DLL et bootkits pour des ancrages plus profonds.
Au redémarrage, tout cela se relance. L'attaquant revient, souvent avant que vous ayez fini de vous féliciter. Un redémarrage n'« aide » que contre le rare implant purement en mémoire sans persistance — et vous ne pouvez pas le savoir à l'avance.
Pourquoi éteindre complique le cadrage
Pire qu'inefficace, éteindre est destructeur pour l'enquête. Un système en marche détient des preuves volatiles qui disparaissent dès la coupure :
- Processus en cours et leurs relations parent-enfant.
- Connexions réseau actives, y compris le canal C2 en direct.
- Malware injecté, sans fichier, en mémoire, n'ayant jamais touché le disque.
- Clés de chiffrement, données déchiffrées et identifiants/presse-papier en RAM.
L'ordre de volatilité dit de capturer d'abord les preuves les plus fragiles — la mémoire avant le disque. Éteindre inverse cela, jetant la partie qui détient souvent la réponse.
Que faire à la place
Confiner sans détruire :
- Isoler l'hôte — le retirer du réseau (ou utiliser le confinement réseau de l'EDR) pour que l'attaquant perde son accès, la machine restant allumée.
- Capturer les preuves volatiles — acquérir une image mémoire, puis collecter les artefacts disque.
- Enquêter et cadrer — identifier persistance, mouvement latéral et comptes touchés.
- Puis remédier — généralement réimager, après avoir compris l'étendue.
À retenir pour l'entretien
La bonne réponse est « isoler, préserver la mémoire, enquêter — ne pas redémarrer ». Recourir à un redémarrage ou un arrêt signale que vous échoueriez à la fois à éjecter l'attaquant et à préserver les preuves nécessaires au cadrage de l'incident.
Questions de suivi probables
- Quels mécanismes de persistance survivraient à un redémarrage, et comment les traqueriez-vous ?
- Quels artefacts volatils sont perdus à l'instant où une machine s'éteint ?
- Comment l'isolation réseau confine-t-elle un hôte sans détruire les preuves ?