Analyse d'Artefact : Persistance Héritée Linux (init.d, rc.local)

Note

Résumé exécutif : bien que systemd soit devenu le standard absolu pour la gestion des services dans les distributions Linux modernes, le système d’exploitation conserve une profonde rétrocompatibilité avec le modèle d’exécution hérité SysVinit. Les acteurs de la menace exploitent massivement ces anciens scripts de démarrage (rc.local, init.d, profile.d) pour établir leur persistance. Ces mécanismes sont privilégiés car ils sont simples à mettre en œuvre, rarement surveillés par les règles EDR modernes conçues pour systemd, et souvent ignorés par les administrateurs système juniors.

1. La persistance simple et rapide : /etc/rc.local

Historiquement, /etc/rc.local était le script traditionnel exécuté tout à la fin du processus d’amorçage (boot), juste avant l’apparition de l’invite de connexion. Il a été conçu pour permettre aux administrateurs d’ajouter facilement des commandes de démarrage personnalisées sans avoir à écrire des fichiers de service complexes.

Dans les environnements systemd modernes, ce fichier est exécuté via une unité de compatibilité (rc-local.service). Si le fichier existe et possède le bit d’exécution, systemd le lancera.

Exploitation et investigation DFIR

Un attaquant ajoute simplement une commande malveillante (ex: un reverse shell ou un chargeur de payload) à la fin du fichier, garantissant ainsi son exécution avec les privilèges root à chaque redémarrage.

Pour investiguer une image forensique montée (ex: /mnt/analyse/), les analystes doivent scruter le contenu du fichier :

cat /mnt/analyse/etc/rc.local

Focus de chasse : recherchez toute commande s’exécutant avant l’instruction exit 0, en particulier les invocations de /bin/bash -i, curl, wget, ou l’exécution de binaires cachés résidant dans /tmp/ ou /dev/shm/.

2. SysVinit et niveaux d’exécution (/etc/init.d/)

Avant systemd, Linux gérait les services à l’aide de scripts SysVinit et de niveaux d’exécution (Runlevels, numérotés de 0 à 6). Le niveau 3 (mode texte multi-utilisateurs) et le niveau 5 (interface graphique) sont les états opérationnels standards.

Le mécanisme d’attaque

Pour qu’un script situé dans /etc/init.d/ s’exécute au démarrage, un lien symbolique doit être créé dans le répertoire du niveau d’exécution correspondant (ex: /etc/rc3.d/). Ce lien symbolique doit commencer par la lettre S (pour Start), suivie d’un numéro de priorité (01-99).

1. L’attaquant dépose un script bash malveillant (ex: network-daemon) dans /etc/init.d/.
2. Il crée le lien d’activation : ln -s /etc/init.d/network-daemon /etc/rc3.d/S99network-daemon.
3. Le préfixe S99 garantit que le script malveillant s’exécute en dernier, après l’initialisation de tous les services réseau légitimes.

Triage DFIR

Les analystes doivent lister les liens d’activation et remonter jusqu’à leurs scripts d’origine :

ls -l /mnt/analyse/etc/rc*.d/S*

Focus de chasse : identifiez les liens symboliques pointant vers des scripts non reconnus. Accordez une attention particulière aux scripts ayant un numéro de priorité élevé (ex: S99).

3. Scripts d’ouverture de session globaux (profile.d)

Bien qu’il ne s’agisse pas strictement de scripts de “démarrage” de la machine, les scripts de profil globaux sont exécutés chaque fois qu’un shell interactif est généré. Contrairement au fichier ~/.bashrc, qui n’affecte qu’un utilisateur spécifique, ces fichiers affectent tous les utilisateurs, y compris root.

• Emplacement des artefacts :
  • /etc/profile
  • /etc/profile.d/*.sh
  • /etc/bash.bashrc

Si un attaquant dépose un fichier backdoor.sh dans /etc/profile.d/, la charge utile explosera avec des privilèges administratifs au moment exact où un administrateur système légitime se connectera via SSH ou un TTY local.

4. Stratégie DFIR et intégrité des paquets

Les acteurs de la menace avancés utilisent le “Timestomping” (l’altération des dates de modification des fichiers) pour fondre leurs scripts malveillants présents dans /etc/init.d/ avec des fichiers système légitimes datant de l’installation du système d’exploitation. Se fier uniquement au mtime (date de modification) est insuffisant.

Les analystes DFIR doivent exploiter les gestionnaires de paquets natifs (DPKG ou RPM) pour effectuer des contrôles d’intégrité sur les scripts suspects.

Debian / Ubuntu (DPKG)

verify_dpkg_integrity.sh

# Interroger le gestionnaire de paquets pour déterminer si le script appartient à un paquet légitime
# À exécuter sur un système actif ou via un environnement chroot
dpkg -S /etc/init.d/script_suspect

# Si la sortie est "dpkg-query: no path found matching pattern", le fichier est NON VÉRIFIÉ et hautement suspect.

RHEL / CentOS (RPM)

verify_rpm_integrity.sh

# Interroger la base de données RPM
rpm -qf /etc/init.d/script_suspect

# Si la sortie est "file is not owned by any package", l'artefact nécessite une analyse immédiate.

Bash (Script d'audit hérité)

audit_legacy_persistence.sh

#!/bin/bash
TARGET="/mnt/analyse"

echo "[+] Audit de rc.local..."
if[ -f "$TARGET/etc/rc.local" ]; then
    cat "$TARGET/etc/rc.local" | grep -v "^#" | grep -v "^exit 0"
fi

echo "[+] Audit des liens symboliques SysVinit non vérifiés..."
ls -l $TARGET/etc/rc*.d/S* | awk '{print $9, $10, $11}'

echo "[+] Audit des scripts de profil globaux..."
ls -la $TARGET/etc/profile.d/

---

Références et lectures complémentaires

• MITRE ATT&CK : Boot or Logon Initialization Scripts (T1037)
• SANS Institute : Advanced Incident Response and Threat Hunting
• Artefact lié : Persistance Linux via Cron et tâches planifiées
• À venir : Persistance Linux via les services Systemd