En bref : une tâche cron cachée est l'une des portes dérobées les plus fréquentes sur les serveurs Linux : elle recharge régulièrement du code malveillant ou relance des processus, même après une mise à jour de PHP. Vérifiez tous les emplacements des tâches planifiées, pas seulement crontab -l : crontabs de tous les utilisateurs, /etc/crontab, /etc/cron.d, les dossiers cron, minuteries systemd et tâches at. Sauvegardez les découvertes avant de les supprimer.
Pourquoi les tâches cron sont si prisées comme porte dérobée
Après une intrusion réussie, un attaquant a un problème : son accès est fragile. Une mise à jour ferme la faille, un administrateur supprime le webshell, un redémarrage met fin au processus. Une tâche cron résout ce problème. Elle lance des commandes à heures fixes, sans que personne n'intervienne, et rétablit ainsi les accès perdus.
Pour PHP2Shell, il n'existe pas d'indicateurs de compromission (Indicators of Compromise) confirmés. Selon les rapports dont nous disposons, les nouvelles tâches cron font toutefois partie des signaux d'alerte généraux après des intrusions via des applications web. Qui a déjà cherché des webshells devrait vérifier aussi les tâches planifiées. Les autres étapes d'un suivi sont énumérées dans la checklist après un piratage.
Où les tâches planifiées peuvent se cacher
Linux connaît plusieurs mécanismes pour les tâches planifiées. De nombreuses vérifications échouent parce qu'on n'en regarde qu'un seul.
| Emplacement | Debian/Ubuntu | Famille RHEL | Qui peut écrire |
|---|---|---|---|
| Crontab par utilisateur | /var/spool/cron/crontabs/ |
/var/spool/cron/ |
l'utilisateur concerné |
| Crontab à l'échelle du système | /etc/crontab |
/etc/crontab |
root |
| Fichiers individuels | /etc/cron.d/ |
/etc/cron.d/ |
root |
| Dossiers périodiques | /etc/cron.hourly à /etc/cron.monthly |
idem | root |
| Minuteries systemd | /etc/systemd/system/, unités utilisateur |
idem | root, parfois utilisateur |
| Tâches at | file d'attente de atd |
idem | utilisateur, si autorisé |
Important pour les serveurs web : l'utilisateur du serveur web peut en règle générale créer sa propre crontab, sans droits root. Un attaquant disposant des droits de www-data n'a donc pas besoin d'une autre faille pour cela. Des entrées dans /etc/cron.d ou des unités systemd indiquent en revanche qu'il a obtenu les droits root.
Les panneaux d'hébergement comme Plesk ou cPanel offrent une interface propre pour les tâches planifiées. Derrière se trouvent en règle générale aussi des crontabs des utilisateurs système concernés. Qui ne regarde que dans l'interface ne reconnaît donc pas toutes les entrées créées directement sur le serveur. En cas de doute, vérifiez les deux.
Comment tout vérifier complètement
Les commandes suivantes ne font que lire. Exécutez-les en tant que root et sauvegardez les sorties avec la date.
# Afficher les crontabs de tous les utilisateurs
for u in $(cut -d: -f1 /etc/passwd); do
out=$(crontab -l -u "$u" 2>/dev/null) && printf '### %s\n%s\n' "$u" "$out"
done
# Entrées à l'échelle du système et dates de modification
cat /etc/crontab
ls -la --time-style=full-iso /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly
# Minuteries systemd et tâches at
systemctl list-timers --all
atq 2>/dev/null
# Chercher des motifs typiques dans tous les fichiers cron
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null
Deux astuces méritent une attention particulière. Certaines entrées cachent des commandes derrière de nombreuses espaces, de sorte qu'elles sortent de l'écran à droite dans l'éditeur. D'autres utilisent des caractères de contrôle qui écrasent du texte à l'affichage. Avec cat -A, de tels caractères deviennent visibles :
cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less
Un second angle d'approche : les journaux du service cron. Sur de nombreux systèmes, cron consigne chaque exécution avec l'utilisateur et la commande. Vous voyez ainsi aussi des entrées qu'un attaquant a entre-temps supprimées, et vous reconnaissez depuis quand une commande suspecte s'exécute :
# Commandes cron exécutées par l'utilisateur du serveur web (Debian/Ubuntu ou journal systemd)
grep -h "CRON" /var/log/syslog* 2>/dev/null | grep -E "\((www-data|apache|nginx)\) CMD"
journalctl -u cron -u crond --since "2026-10-17" --no-pager 2>/dev/null | grep CMD | head -100
Comment reconnaître une porte dérobée cron
- Rechargement depuis Internet : un téléchargement dont le résultat est directement transmis à un shell.
- Contenus encodés : de longues chaînes de caractères qui ne sont décodées qu'à l'exécution.
- Chemins inhabituels : programmes dans
/tmp,/dev/shm, des dossiers cachés ou des répertoires de téléversement. - Mauvais utilisateur : tâches sous l'utilisateur du serveur web, alors que l'application n'en a pas besoin.
- Rythme remarquable : exécution chaque minute ou à chaque redémarrage via
@reboot. - Horodatages incohérents : fichier modifié pendant une période où personne n'a travaillé sur le serveur, par exemple après le 17 octobre.
À ne pas oublier : les applications ont aussi leurs propres planifications. WordPress, par exemple, gère les tâches planifiées dans la base de données. La façon d'y vérifier est décrite dans Trouver les portes dérobées dans WordPress.
Une tâche cron arrive rarement seule. Qui a créé une tâche planifiée a souvent aussi déposé des clés SSH ou caché des fichiers. Vérifiez en plus les clés, comme décrit dans l'article Trouver les clés SSH inconnues.
Sauvegarder la découverte, la comprendre, puis la supprimer
Une tâche cron malveillante est une précieuse pièce à conviction. Elle montre l'adresse de rechargement, le moment de sa création et souvent l'utilisateur par lequel l'attaquant est arrivé. Sauvegardez le fichier avec somme de contrôle et horodatages avant de le supprimer. L'horodatage aide plus tard à reconstituer le déroulement ; comment faire, Établir la chronologie d'un incident le montre. Pour une éventuelle notification à l'autorité de protection des données ou pour l'assureur, la découverte est aussi une pièce importante pour établir depuis quand un attaquant avait accès.
Supprimer ne suffit pas. Si un processus tourne encore et réécrit l'entrée, elle est de retour dès la minute suivante. Et tant que la faille d'origine est ouverte, l'attaquant peut repartir à tout moment. L'ordre est donc : sauvegarder, fermer la cause, supprimer tous les composants, changer les accès, surveiller.
Sécuriser les tâches cron à titre préventif
Pour qu'une porte dérobée cron ne puisse pas naître, ou se remarque vite, trois mesures aident. Premièrement, on peut définir quels utilisateurs ont le droit de créer une crontab. Si le fichier /etc/cron.allow existe, seuls les utilisateurs qui y figurent peuvent utiliser crontab. Si votre application n'a pas besoin de tâche cron sous l'utilisateur du serveur web, cet utilisateur n'a pas sa place sur la liste. Vérifiez au préalable quelles tâches l'application nécessite réellement, et créez-les délibérément sous un utilisateur dédié.
Deuxièmement, une surveillance des fichiers vaut la peine. Un outil de contrôle d'intégrité signale dès qu'un fichier change dans les répertoires cron ou sous /var/spool/cron. Troisièmement, les tâches planifiées font partie de la documentation du serveur : qui sait quelles entrées doivent exister reconnaît immédiatement une entrée étrangère.
Comment PHP SOS aide-t-il concrètement ?
- Vérifier complètement : nous examinons tous les mécanismes de tâches planifiées, y compris minuteries systemd, tâches at et planifications d'applications.
- Situer les découvertes : nous évaluons les entrées suspectes sans les exécuter et en déduisons d'autres traces.
- Nettoyer proprement : avec la suppression de logiciels malveillants, nous retirons tous les composants et fermons la cause.
- Détecter un retour : nous mettons en place une surveillance qui signale les tâches planifiées nouvelles ou modifiées.
Questions fréquentes
Pourquoi les attaquants utilisent-ils des tâches cron ?
Une tâche cron lance des commandes régulièrement et sans autre intervention. Les attaquants s'en servent pour recharger du code malveillant, recréer des fichiers supprimés ou relancer des processus. Leur accès survit ainsi à une mise à jour et souvent aussi à un nettoyage superficiel.
crontab -l suffit-il pour la vérification ?
Non. crontab -l n'affiche que la crontab de l'utilisateur courant. Les tâches planifiées figurent en outre dans les crontabs d'autres utilisateurs, dans /etc/crontab, /etc/cron.d, les dossiers cron.daily, dans les minuteries systemd et dans les tâches at.
Comment reconnaître une tâche cron malveillante ?
Sont typiques des téléchargements depuis Internet avec exécution directe, des commandes avec des chaînes de caractères encodées, des programmes dans des dossiers temporaires, des tâches sous l'utilisateur du serveur web et des entrées exécutées chaque minute. Une caractéristique isolée est un indice, plusieurs un sérieux soupçon.
Puis-je simplement supprimer les tâches cron suspectes ?
D'abord sauvegarder, ensuite supprimer. L'entrée révèle souvent l'origine, l'adresse de rechargement et d'autres composants. Sans avoir clarifié comment elle est née, l'attaquant la recrée souvent.