Skip to content

Lors de l'investigation d'un serveur Linux compromis, où cherchez-vous la persistance de l'attaquant ?

Réponse courte

La persistance Linux se cache dans les chemins d'exécution planifiée et de démarrage : cron et timers/unités systemd, clés ajoutées dans authorized_keys SSH, fichiers rc du shell et scripts de profil modifiés, et binaires de service ou bibliothèques préchargées trojanisés. Examinez-les systématiquement. L'historique du navigateur et les réglages du fond d'écran ne sont pas des mécanismes de persistance, et redémarrer ne supprimera rien qui se rétablit au démarrage — cela ne fait que le relancer. Tout l'intérêt de la persistance est de survivre aux redémarrages, donc un redémarrage ne prouve rien.

La persistance est la manière dont un attaquant conserve son accès après le point d'entrée initial — et sous Linux, elle réside dans un ensemble d'emplacements bien connus : tout ce que le système exécute automatiquement selon un planning, au démarrage ou à la connexion. Un répondeur compétent parcourt cette liste méthodiquement plutôt que de poursuivre ce qui est le plus visible.

Où chercher réellement

  • Exécution planifiée : les crontab utilisateur et système, /etc/cron.*, et surtout les timers et unités systemd (systemctl list-timers, fichiers d'unité dans /etc/systemd/system et ~/.config/systemd/user).
  • Accès SSH : clés ajoutées dans ~/.ssh/authorized_keys pour chaque utilisateur, y compris les comptes de service ; une clé d'attaquant ici est une porte dérobée discrète et durable.
  • Fichiers de démarrage du shell : ~/.bashrc, ~/.bash_profile, ~/.profile, /etc/profile.d/* — le code déposé ici s'exécute à chaque connexion interactive.
  • Binaires et bibliothèques trojanisés : binaires de service modifiés, détournements via LD_PRELOAD//etc/ld.so.preload, et objets partagés altérés qui se chargent dans des processus légitimes.

Recoupez ces éléments avec une référence saine, les dates MAC des fichiers et les vérifications d'intégrité du gestionnaire de paquets.

Pourquoi les distracteurs sont faux

  • L'historique du navigateur est une activité utilisateur, pas un mécanisme de persistance. Il peut donner du contexte, mais ne relancera pas le code de l'attaquant.
  • Les réglages du fond d'écran sont cosmétiques et sans rapport avec la persistance d'un serveur.
  • « Un redémarrage efface la persistance » est exactement l'inverse de la réalité. La propriété qui définit la persistance est qu'elle survit à un redémarrage — cron, systemd et les fichiers rc se redéclenchent tous au démarrage ou à la connexion. Redémarrer ne fait que relancer le code malveillant et risque de détruire des preuves volatiles au passage.

Ce que l'examinateur cherche à évaluer

Si vous disposez d'une véritable cartographie mentale des surfaces de démarrage automatique de Linux et abordez un hôte compromis de manière systématique, plutôt que de tâtonner sur le premier artefact graphique à portée. Le distracteur du redémarrage teste spécifiquement si vous comprenez ce que signifie réellement « persistance ».

Questions de suivi probables

  • Comment LD_PRELOAD ou un /etc/ld.so.preload altéré donnerait-il à un attaquant une persistance au niveau bibliothèque ?
  • Quels répertoires systemd compareriez-vous à une référence saine, et pourquoi ?
  • Comment distinguez-vous un binaire de service trojanisé d'un binaire légitimement mis à jour ?

Sources

Recevez 100 questions d'entretien en cybersécurité + réponses

Laissez votre e-mail et nous vous enverrons le pack PDF gratuit et le jeu de flashcards.

Pas de spam. Désabonnez-vous à tout moment.