Une porte dérobée fermée… et une remédiation qui a éteint 16 VM
Un compte administrateur caché a été trouvé et supprimé. La commande de nettoyage a elle-même provoqué la panne la plus lourde du mois.
Symptômes
- Compte inconnu d'UID 0
- Mot de passe réappliqué toutes les 30 min par une tâche planifiée
- Service systemd déguisé en « contrôle de santé »
- Connexion root par mot de passe réactivée
Hypothèses
- Intrusion depuis Internetinfirmée
- Script d'auto-provisionnement d'un agent localnon prouvée
Problème
Un compte d'identifiant 0 (équivalent root) déguisé, avec deux mécanismes de persistance, avait été créé deux jours plus tôt par un script local.
Diagnostic
Création locale avec la clé de l'hôte, aucune intrusion distante, aucune charge utile. L'opérateur exact n'est pas vérifiable (pas d'audit système à l'époque).
Décision
Supprimer le compte et ses deux persistances.
Correction
Seconde remédiation, sans aucun signal envoyé : compte verrouillé puis retiré de façon atomique, tâche et service supprimés, connexion par mot de passe refusée partout sauf depuis un seul poste du réseau local.
Retour arrière
Aucun nécessaire pour la porte dérobée. Pour la panne : redémarrage ordonné des services et des VM.
Test
Absence du compte et des persistances vérifiée ; configuration SSH contrôlée avant rechargement ; 0 connexion réussie du compte caché dans deux jours de journaux.
Résultat mesuré
Porte dérobée fermée. Mais 16 VM éteintes et 1 h 12 d'infrastructure aveugle, causées par la remédiation.
Ce qui a été mal fait
« Tuer les processus de l'utilisateur » visait un compte d'UID 0 : la commande a résolu l'UID 0 et envoyé l'arrêt à TOUS les processus root, dont systemd et les hyperviseurs. Seuls les conteneurs non privilégiés ont survécu, ce qui a confirmé le diagnostic.
Apprentissage
Avant une commande d'urgence, mesurer sa portée réelle. Pour neutraliser un compte : verrouiller, retirer le shell, puis retirer ses lignes de façon atomique, avec des garde-fous vérifiés avant écriture. Après un arrêt brutal, vérifier les démons secondaires : un seul service inactif rendait les VM impossibles à démarrer, avec trois messages d'erreur trompeurs.