Détecter la persistance d’un attaquant après incident

Un attaquant qui a obtenu un accès durable n’a aucune raison de brûler son accès immédiatement. La persistance transforme un incident ponctuel en capacité de retour, souvent après une remédiation qui a nettoyé le symptôme et laissé la cause respirer tranquillement.

→ Lire l’explication complète de la marmotte

Persistance : le compromis entre vitesse de retour et furtivité

La persistance est tout mécanisme qui permet de rétablir un accès sans répéter l’intrusion initiale. Elle peut être locale, par exemple une tâche planifiée ou un service modifié, ou distribuée, par exemple un compte de service, une relation de confiance fédérée ou une sauvegarde empoisonnée.

Le compromis central est net : chercher exhaustivement coûte du temps, immobilise des systèmes et élargit le périmètre d’investigation ; se limiter à l’hôte détecté réduit l’interruption mais laisse une probabilité difficilement mesurable de retour. La recommandation est de privilégier l’exhaustivité dès qu’un accès privilégié, une identité de service, une infrastructure de sauvegarde ou une couche de virtualisation a été touchée. À ce stade, la remédiation rapide devient surtout une manière élégante de planifier le prochain incident.

Un attaquant sophistiqué privilégie souvent la survie à l’action immédiate pour trois raisons :

Réduire le bruit : exfiltrer ou chiffrer massivement déclenche plus facilement une détection qu’un compte dormant ou une tâche qui s’exécute une fois par semaine.
Conserver l’initiative : une porte dérobée permet de revenir quand la surveillance baisse, lors d’une fenêtre de maintenance ou après un changement d’équipe.
Contourner la remédiation partielle : supprimer un logiciel malveillant identifié ne révoque ni les identités créées, ni les clés déposées, ni les délégations accordées ailleurs.

Une persistance n’est pas nécessairement un binaire exotique. Un certificat client ajouté à une autorité de confiance, une clé de déploiement dans un projet d’intégration continue, ou une règle de messagerie qui copie certains messages constituent des mécanismes de retour. La sécurité adore les portes dérobées en forme de fonctionnalité d’administration. Elles passent mieux en revue de changement.

La détection doit donc partir d’une question plus large que « quel fichier est malveillant ? » : quels changements permettent encore à une identité, un processus ou une machine non approuvée d’obtenir un niveau d’accès significatif ?

Les mécanismes IAM (Identity and Access Management), c’est-à-dire de gestion des identités et des droits, demandent une investigation séparée. Un compte, un jeton d’accès ou une délégation ne laisse pas les mêmes traces qu’un implant sur disque. La page sur l’authentification des personnes et des services complète ce sujet sur les garanties attendues des identités de travail.

Points de persistance à rechercher sur les systèmes

Sur Windows, les emplacements classiques incluent les tâches planifiées, les services, les clés Run et RunOnce, les objets de stratégie de groupe, les extensions d’authentification, les abonnements permanents à Windows Management Instrumentation (WMI), les raccourcis de démarrage et les pilotes. Les tâches planifiées sont particulièrement rentables pour l’attaquant : un nom qui imite un composant système, une exécution sous SYSTEM, une commande encapsulée et un déclencheur peu fréquent suffisent à disparaître dans un inventaire superficiel.

Sur Linux, examiner les unités systemd, les minuteurs, les travaux cron, les scripts de démarrage, les profils de shell, les clés Secure Shell (SSH), les bibliothèques chargées via le chargeur dynamique, les règles sudo et les comptes locaux. Une unité systemd activée avec un nom banal n’a besoin d’aucun exploit supplémentaire : elle sera relancée par le système, avec une régularité que beaucoup de produits miracles de détection promettent de remplacer par de l’intelligence artificielle.

Sur les postes macOS, les LaunchAgents, LaunchDaemons, profils de configuration, éléments de connexion, extensions système et mécanismes de gestion de périphériques doivent rejoindre la recherche. Une configuration de gestion malveillante peut survivre au nettoyage d’une application compromise si elle reste autorisée à réinstaller des composants.

Le point décisif n’est pas de lister ces emplacements, mais de les comparer à un état de référence. Une tâche inconnue n’est pas automatiquement hostile ; une tâche créée après la compromission, lancée par un compte inattendu, qui exécute un interpréteur de commandes depuis un répertoire temporaire mérite en revanche une réponse immédiate. La chronologie compte plus que le folklore.

Conserver un inventaire versionné des services, tâches, comptes locaux, clés SSH, certificats installés et mécanismes de démarrage permet de calculer un écart. Sans référence, on fait de l’archéologie sur un système vivant. Cela peut marcher, comme chercher une vis dans l’herbe avec un détecteur de métaux acheté pour la photo de couverture.

Exemple : établir un état de référence systemd et cron

L’exemple suivant produit un inventaire Linux exploitable dans une investigation. Il ne détecte pas automatiquement une compromission : il fournit un état diffable, signé ou archivé hors de l’hôte concerné. L’exécuter avec des privilèges d’administration, puis conserver le résultat dans un dépôt ou un stockage auquel l’hôte inspecté ne peut pas écrire.

#!/usr/bin/env bash
# Inventorier les persistances systemd et cron connues sur un hôte Linux.
# Exécuter en administrateur : sudo bash inventaire-persistance.sh

set -euo pipefail
stamp="$(date -u +%Y%m%dT%H%M%SZ)"
out="persistance-${HOSTNAME}-${stamp}.txt"

{
  echo "# Hôte : ${HOSTNAME}"
  echo "# Date UTC : ${stamp}"

  echo
  echo "## Unités systemd activées"
  systemctl list-unit-files --state=enabled --no-pager

  echo
  echo "## Minuteurs systemd, y compris ceux en attente"
  systemctl list-timers --all --no-pager

  echo
  echo "## Fichiers d'unités locaux et empreintes"
  find /etc/systemd/system /usr/lib/systemd/system \
    -type f \( -name '*.service' -o -name '*.timer' \) -print0 2>/dev/null \
    | sort -z | xargs -0r sha256sum

  echo
  echo "## Crontabs des comptes ayant un shell de connexion"
  awk -F: '$7 !~ /(nologin|false)/ {print $1}' /etc/passwd |
  while read -r account; do
    echo "### ${account}"
    crontab -u "${account}" -l 2>/dev/null || true
  done

  echo
  echo "## Cron système"
  find /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly \
    -type f -maxdepth 1 -print -exec sha256sum {} \; 2>/dev/null
} > "${out}"

echo "Inventaire écrit dans ${out}"

Le hachage SHA-256 (Secure Hash Algorithm 256 bits) ne prouve pas qu’un fichier est légitime. Il détecte un changement si la référence est digne de confiance. Une référence stockée sur l’hôte compromis ou créée après l’incident ne sert qu’à documenter le mensonge avec une très belle somme de contrôle.

Comptes de service, identités et accès de retour

Les comptes de service sont une cible de persistance privilégiée : ils sont peu surveillés, rarement utilisés de manière interactive et disposent parfois de droits étendus. Rechercher les comptes créés, réactivés ou modifiés autour de la fenêtre de compromission, puis examiner leurs groupes, délégations, clés, certificats, facteurs d’authentification et dernières utilisations.

Une investigation crédible doit couvrir les identités locales, l’annuaire, les fournisseurs d’identité, les comptes cloud, les robots d’intégration continue et les comptes d’urgence. Supprimer un compte sans invalider ses sessions, ses jetons et ses secrets ne suffit pas. La révocation d’un certificat ou d’un jeton ne ferme pas magiquement toutes les sessions déjà établies : la durée de session, le cache applicatif et les mécanismes de renouvellement déterminent le délai réel de coupure.

Chercher également les changements de confiance : consentements d’application, délégations administratives, règles d’accès conditionnel, clés d’interface de programmation, certificats ajoutés, règles de transfert de messagerie et rôles à privilèges. Les techniques d’authentification et les erreurs de protocole associées sont détaillées dans le durcissement de NTLM.

Le journal d’événements doit être exporté avant toute purge. Un EDR (Endpoint Detection and Response), outil de détection et de réponse sur les postes, peut signaler une création de tâche ou de compte, mais son absence de signal ne démontre rien : l’agent peut avoir été désactivé, exclu, contourné ou installé après les faits. Centraliser les événements dans un SIEM (Security Information and Event Management), plateforme de corrélation de journaux, protège davantage la preuve, à condition que les comptes d’administration du SIEM ne soient pas dans le même périmètre compromis.

Sauvegardes compromises et reconstruction de confiance

Une sauvegarde restaure des données et des configurations. Elle peut donc restaurer une persistance. Les images système, instantanés de machines virtuelles, sauvegardes d’annuaire et dépôts de configuration doivent être traités comme des éléments potentiellement contaminés dès lors qu’ils ont été accessibles avec les privilèges de l’attaquant.

Avant restauration, identifier le dernier point connu sain, pas seulement le dernier point disponible. Cela exige de corréler les premières traces d’accès, les modifications d’identités et les écarts de configuration. Restaurer un instantané antérieur à l’alerte ne garantit rien si l’intrusion a précédé la détection de plusieurs semaines. Les sauvegardes ne voyagent pas dans le temps avec une preuve d’innocence attachée au disque.

Séparer les sauvegardes immuables, les identités d’administration de sauvegarde et les journaux de restauration réduit ce risque. Une restauration doit être réalisée dans un environnement isolé, avec contrôle des comptes, services, clés et tâches avant réintégration. La stratégie de reprise et ses limites sont développées dans la page continuité, sauvegardes et reprise.

Une reconstruction complète depuis une image saine devient la seule option défendable lorsque la chaîne de confiance basse est douteuse : micrologiciel UEFI (Unified Extensible Firmware Interface), contrôleur de gestion matériel, hyperviseur, image de base de conteneur, outil de déploiement, annuaire à privilèges ou infrastructure de sauvegarde. Un implant à ces niveaux peut survivre à une réinstallation du système invité et altérer les outils censés le vérifier.

Le seuil est franchi lorsqu’au moins une de ces conditions est vraie :

l’origine exacte de l’exécution hostile reste inconnue ;
un compte à privilèges a pu administrer plusieurs hôtes ou le plan de virtualisation ;
les journaux nécessaires à la chronologie sont absents, altérés ou non fiables ;
la persistance a été observée dans une image, un modèle, une sauvegarde ou un outil de déploiement ;
le nettoyage exige de faire confiance à une couche potentiellement compromise.

À ce seuil, conserver l’hôte coûte moins aujourd’hui, mais transfère un risque non borné à l’exploitation future. On paie alors une reconstruction, une rotation de secrets et une revalidation des accès. C’est cher. Le retour de l’attaquant l’est davantage, avec une facture qui a tendance à arriver accompagnée d’un comité de crise.

Exploitation après éradication : rotation, supervision et preuve

La remédiation ne se termine pas quand le logiciel malveillant disparaît. Révoquer et renouveler les secrets exposés : mots de passe, clés SSH, jetons d’accès, certificats, secrets applicatifs, clés de chiffrement et identifiants de sauvegarde. Prioriser selon le pouvoir détenu et la possibilité de rebond, pas selon la facilité de rotation.

Une clé de service présente dans une sauvegarde ou un fichier de configuration doit être considérée divulguée, même si aucun usage suspect n’apparaît. L’absence d’événement n’est pas une preuve d’absence quand le journal ne couvre pas l’usage de ce secret. Les mécanismes de gestion de clés et les frontières cryptographiques sont abordés dans la section cryptographie.

Conserver les indicateurs, les horodatages, les empreintes de fichiers et les écarts de configuration dans un dossier d’incident séparé du système remis en service. Réinstaller un agent de supervision depuis une source contrôlée, valider son rattachement à la console centrale et alerter sur toute recréation de compte, tâche, service ou clé observés pendant l’incident.

Enfin, surveiller la réapparition plutôt que déclarer prématurément la victoire. Une période d’observation doit couvrir les déclencheurs réels de la persistance : redémarrage, rotation de certificats, exécution planifiée, renouvellement de session, restauration ou déploiement automatisé. Une porte dérobée qui ne s’active qu’après redémarrage n’est pas absente ; elle attend juste que l’exploitation fasse son travail.

🐝 Ce qui arrive si on s’en passe

Sans recherche systématique des mécanismes de retour, un second accès n’est pas rattaché au premier : il est enregistré comme un incident indépendant, ce qui casse la chronologie, empêche toute corrélation entre les deux évènements et fausse les indicateurs de récurrence. Les journaux utiles à cette corrélation expirent souvent avant la réapparition, puisque les durées de rétention se comptent en semaines alors qu’un déclencheur planifié peut attendre plusieurs mois. L’absence d’inventaire comparable rend aussi impossible la rédaction de règles de détection spécifiques aux points de retour observés, et la clôture de l’incident repose sur une affirmation invérifiable : rien ne permet de démontrer à un auditeur, un assureur ou un partenaire que l’éradication a porté sur autre chose que le fichier initialement identifié.

🦫 Explication de la marmotte 🍫

Après une intrusion, le danger ne vient pas seulement du programme trouvé sur un ordinateur. L’attaquant peut avoir créé un compte supplémentaire, ajouté une tâche qui démarre plus tard, modifié un fichier de lancement ou placé une clé d’accès dans un outil utilisé par les équipes techniques. Ces changements permettent de revenir sans refaire l’effraction initiale.

La recherche commence par comparer les réglages actuels avec une liste connue de réglages autorisés. On examine les programmes lancés au démarrage, les actions prévues à heure fixe, les comptes, les droits donnés aux comptes et les clés permettant de se connecter. Les dates de création, les personnes ayant fait les changements et les journaux d’activité servent à déterminer ce qui est apparu pendant l’intrusion.

Il faut aussi examiner les copies de secours. Si une copie contient un compte caché ou un programme modifié, la restaurer remet le problème en place. Une copie plus ancienne n’est utilisable que si sa date est antérieure au début réel de l’intrusion.

Quand l’attaquant a pu modifier le logiciel qui lance plusieurs machines, le programme qui gère les machines virtuelles ou le matériel de démarrage, nettoyer seulement un ordinateur ne suffit plus. Il faut reconstruire depuis une source vérifiée, recréer les accès et remplacer les secrets. Si les preuves manquent, conserver le système revient à accepter un accès caché dont personne ne peut mesurer le risque.

Pages voisines

La citent

Détecter la persistance d’un attaquant après incident

Elle cite

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

Détecter la persistance d’un attaquant après incident

Détecter la persistance d’un attaquant après incident

Persistance : le compromis entre vitesse de retour et furtivité

Points de persistance à rechercher sur les systèmes

Exemple : établir un état de référence systemd et cron

Comptes de service, identités et accès de retour

Sauvegardes compromises et reconstruction de confiance

Exploitation après éradication : rotation, supervision et preuve

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines