J’ai cassé root pour tester un EDR… et j’ai dû m’échapper par Docker

Je voulais tester un EDR. J’ai surtout réussi à me verrouiller hors du serveur, avant de le récupérer par une voie que j’aurais dû considérer comme critique dès le départ.

Le test qui a dérapé

Le contexte était simple : vérifier si une modification sensible sur le système serait détectée par l’EDR et par les mécanismes de supervision en place. L’idée n’était pas de “casser” la machine, mais de provoquer un événement réaliste pour valider la chaîne d’alerte.

J’ai donc touché à un élément qu’on ne devrait jamais modifier à la légère : l’identité du compte root. Le but était de simuler un changement critique sur le système, puis de revenir en arrière rapidement pour voir ce que l’EDR allait remonter.

Sur le papier, c’était un test contrôlé. En pratique, j’ai découvert une règle très simple : si tu modifies l’ossature d’un système sans filet, le système finit par te le rappeler.

L’erreur de base

Le symptôme a été immédiat. Au moment d’utiliser sudo, le système a répondu avec une erreur fatale :

sudo: unknown user root
sudo: error initializing audit plugin sudoers_audit

À partir de là, plus d’élévation de privilèges possible. L’utilisateur root n’existait plus, du moins aux yeux du système. La ligne correspondante dans /etc/passwd avait été renommée, ce qui avait rendu l’administration normale inutilisable.

C’est le genre d’erreur qui paraît presque anecdotique quand on la lit dans un terminal. En vrai, c’est un lockout total.

Pourquoi la restauration a échoué

La cause racine était assez claire une fois l’historique des commandes relu. J’avais lancé une simulation pour tester le File Integrity Monitoring, avec une séquence du style :

sudo sed -i 's/^root:/modified_root:/' /etc/passwd
sleep 2
sudo sed -i 's/^modified_root:/root:/' /etc/passwd

La première commande avait bien fonctionné. La seconde, elle, supposait encore que sudo puisse fonctionner normalement.

Le problème est là : si sudo a besoin de root pour tourner correctement, et que root n’existe plus dans la base locale, tu te retrouves dans une boucle très désagréable. La restauration qui devait annuler le test ne pouvait plus s’exécuter. J’avais créé moi-même le verrouillage.

C’est un bon rappel de sécurité : un test “réversible” ne l’est vraiment que si la voie de retour est indépendante du mécanisme que tu es en train de casser.

Le chemin de sortie

À ce stade, je n’avais plus accès à sudo, et sortir le support de stockage du serveur pour le corriger depuis une autre machine n’était pas pratique. Il fallait donc trouver une autre voie d’administration déjà disponible.

La solution venait d’un détail de configuration : l’utilisateur courant appartenait au groupe docker. Et quand on connaît Docker, on sait que ce n’est pas un simple groupe de confort.

J’ai donc lancé un conteneur temporaire avec le système de fichiers hôte monté dedans :

docker run -it --rm -v /:/host debian bash

Depuis l’intérieur du conteneur, j’avais un shell root sur l’environnement du conteneur, et donc la possibilité de corriger le fichier cassé sur l’hôte :

sed -i 's/^modified_root:/root:/' /host/etc/passwd

Une fois la correction faite, les droits d’administration sont revenus immédiatement. Le serveur était récupéré.

Ce que cet incident montre vraiment

Le point important n’est pas seulement “j’ai cassé quelque chose puis j’ai réparé”. Le vrai sujet, c’est la surface de confiance autour des outils d’administration.

Quelques leçons ressortent très clairement :

• Modifier des fichiers système critiques sans voie de retour indépendante est une mauvaise idée.
• Un test de détection doit inclure un plan de récupération avant même de commencer.
• Être membre du groupe docker revient souvent à disposer d’un accès quasi root sur la machine.
• Un EDR qui ne remonte pas l’action ne rend pas le test anodin ; il faut aussi regarder l’impact opérationnel réel.

Pour un lecteur défense, c’est un excellent exemple de ce qu’il faut surveiller. Pour un lecteur red team, c’est un rappel utile : la réussite d’un test ne se mesure pas seulement à la détection, mais aussi à la capacité à sortir proprement du lab.

Ce que je referais différemment

Si je devais rejouer le test, je ferais trois choses avant de toucher à quoi que ce soit :

1. Prévoir un accès console ou une méthode de secours hors bande.
2. Tester sur une copie isolée du système plutôt que sur l’hôte principal.
3. Considérer Docker, LXD, Podman ou tout autre moteur de conteneurs comme des privilèges sensibles, pas comme un simple outil de développement.

C’est souvent là que la prévention rejoint la red team : on apprend moins en évitant les erreurs qu’en comprenant précisément pourquoi elles deviennent des incidents.

Conclusion

Je voulais valider un scénario de détection. J’ai surtout validé une vieille vérité de terrain : si tu touches à root, tu dois déjà avoir planifié comment le retrouver.

Et si tu laisses docker dans le chemin critique de ton administration, tu n’as pas un simple groupe d’utilisateurs. Tu as une clé de sortie déguisée en outil pratique.

Le test était utile, mais la leçon l’était encore plus : en sécurité, la récupération fait partie de l’attaque.