En bref : sous Linux, vous trouvez les fichiers modifiés avec find et une plage de temps, par exemple à partir du 17 octobre 2026, première tentative d'attaque observée sur PHP2Shell selon les médias. Ne vérifiez pas seulement l'heure de modification du contenu (mtime), mais aussi celle des métadonnées (ctime), car la première se falsifie facilement. Le résultat n'est fiable que grâce à la comparaison avec les sommes de contrôle des paquets, Git ou une sauvegarde.
Pourquoi les horodatages sont un bon point de départ, mais pas une preuve
Qui amène du code sur un serveur modifie des fichiers. De nouveaux webshells, des fichiers de configuration adaptés, des lignes ajoutées dans des scripts existants : tout cela laisse des horodatages. La recherche de modifications dans la bonne plage de temps est donc l'un des chemins les plus rapides vers les premières découvertes.
Pour PHP2Shell, le début de la plage se situe naturellement le 17 octobre 2026, jour de la première tentative d'attaque observée selon les médias. Les correctifs sont parus le 21 octobre. Qui n'a mis à jour son serveur qu'après cela cherche jusqu'au jour de sa propre mise à jour et au-delà. Comment reconnaître les webshells parmi les découvertes, Reconnaître et supprimer un webshell le décrit. Il s'agit ici de la méthode de recherche elle-même.
Les trois horodatages d'un fichier
Linux stocke plusieurs moments pour chaque fichier. Pour la recherche de modifications, deux sont décisifs.
| Horodatage | Signification | Falsifiable ? |
|---|---|---|
| mtime | dernière modification du contenu | oui, par ex. avec touch, par quiconque peut écrire le fichier |
| ctime | dernière modification du contenu ou des métadonnées comme les droits | pas avec de simples moyens |
| atime | dernier accès en lecture | souvent désactivé ou imprécis, peu adapté à la recherche |
Les attaquants aiment antidater le mtime à la date des fichiers voisins, pour qu'un nouveau fichier passe inaperçu. Le ctime, lui, change en conséquence. Un fichier avec un mtime ancien et un ctime récent est donc un indice fort de manipulation.
Faites attention aux fuseaux horaires dans la comparaison. find et ls affichent l'heure locale du serveur, alors que de nombreux fichiers journaux et services travaillent en UTC. Qui met côte à côte des découvertes du système de fichiers et des journaux devrait convertir toutes les indications dans le même fuseau horaire, sinon des événements semblent ne pas coïncider. Les correctifs sont parus vers le 21 octobre à 14:00 UTC, soit à 16 h, heure allemande.
Trouver des fichiers modifiés sous Linux avec find
Toutes les commandes ne font que lire. Adaptez le chemin et la date.
# Contenu modifié depuis le 17/10/2026, trié, avec mtime, ctime et propriétaire
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Métadonnées modifiées depuis le 17/10/2026 (trouve aussi les fichiers antidatés)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Écarter le bruit connu : cache, journaux, sessions
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Regarder aussi en dehors du répertoire web
find /etc /usr/local/bin /tmp /var/tmp /dev/shm -xdev -type f -newerct "2026-10-17" -printf '%C+ %p\n' 2>/dev/null | sort
Pour chaque occurrence, comparez les deux horodatages. Si le ctime est nettement plus récent que le mtime et que personne n'a modifié de droits ni copié de fichiers pendant ce temps, le fichier va sur la liste. Faites aussi attention au propriétaire : un fichier de l'utilisateur du serveur web parmi des fichiers de l'utilisateur de déploiement se remarque.
N'oubliez pas les fichiers et répertoires cachés. Les noms commençant par un point ne sont pas affichés par de nombreux gestionnaires de fichiers ni par un simple ls. Les attaquants l'exploitent volontiers, de même que des noms ressemblant à s'y méprendre à de vrais fichiers.
# Fichiers et dossiers cachés dans le répertoire web, sans les connus comme .htaccess et .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Comparer avec une source digne de confiance
Les horodatages montrent où quelque chose a bougé. Qu'il s'agisse d'une modification légitime, seule la comparaison avec une source à laquelle vous faites confiance le montre.
- Gestion des paquets : pour les fichiers système,
dpkg --verify(Debian/Ubuntu) ourpm -Va(famille RHEL) vérifient les fichiers par rapport aux sommes de contrôle des paquets installés. Les fichiers de configuration divergent légitimement, les fichiers programmes non. - Git : si l'application se trouve dans un dépôt,
git -C /var/www/projekt status --porcelainmontre chaque écart par rapport au dernier commit. - Sommes de contrôle du CMS : de nombreux systèmes peuvent comparer leurs fichiers du cœur avec les sommes de contrôle officielles, voir Comparer les fichiers du cœur du CMS avec l'original.
- Sauvegarde antérieure à l'incident : une comparaison en simulation liste les différences sans rien copier.
# Lister seulement les différences entre l'état de la sauvegarde et le système en production (simulation, ne copie rien)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
La comparaison avec la sauvegarde suppose que la sauvegarde date d'avant l'incident et n'a pas elle-même été modifiée. Pourquoi des sauvegardes conservées séparément sont décisives ici, Sauvegardes selon la règle 3-2-1 l'explique.
Enregistrez les résultats de chaque recherche avec la date dans un fichier hors du serveur. Ces listes serviront plus tard à établir la chronologie de l'incident, et elles prouvent ce que vous avez vérifié et quand.
S'il n'y a ni sauvegarde ni dépôt
Pour de nombreux petits sites, il n'existe pas de base de comparaison propre : pas de Git, pas de sauvegarde antérieure à l'incident, des extensions mises à jour à la main depuis des années. Vous n'êtes pourtant pas sans repère.
Téléchargez chez l'éditeur le CMS et les extensions dans exactement les versions installées et comparez ces fichiers avec le serveur. Ce qui diffère ou manque là mérite un coup d'œil. Restent vos propres adaptations, les téléversements et la configuration ; là, la recherche par horodatage aide, complétée par un regard sur le propriétaire et les droits. Les fichiers qui sont les seuls d'un répertoire à avoir un autre groupe, d'autres droits ou un ctime nettement plus récent que leurs voisins vont sur la liste.
Honnêtement : sans base de comparaison, une incertitude résiduelle demeure. Pour les systèmes contenant des données sensibles, une reconstruction à partir de sources saines est alors souvent plus fiable que la recherche de chaque fichier modifié. Pour l'avenir, la leçon est simple : un dépôt pour le code et des sauvegardes régulières, conservées séparément.
Sources d'erreur typiques dans la recherche
- Exclusions trop larges : les dossiers de cache et de téléversement sont des cachettes prisées.
- Seul mtime vérifié : les fichiers antidatés passent à travers.
- Déploiement dans la plage de temps : un déploiement régulier modifie des centaines de fichiers et masque les découvertes isolées. Comparez avec le dépôt.
- Fichiers déjà ouverts ou copiés : des copies sans conservation des horodatages détruisent des traces. Sauvegardez avec des outils qui conservent les horodatages.
- Seul le répertoire web parcouru : les attaquants déposent aussi des outils dans
/tmp,/dev/shmou dans le répertoire personnel de l'utilisateur du serveur web. - Modifications de droits négligées : un fichier dont les droits autorisent soudain l'écriture à tous est une découverte, même si son contenu est inchangé.
La façon d'assembler les découvertes en un déroulement, Établir la chronologie d'un incident le montre.
Comment PHP SOS aide-t-il concrètement ?
- Chercher systématiquement : nous parcourons les répertoires web et les chemins système à la recherche de modifications dans la plage de temps pertinente et exploitons mtime et ctime ensemble.
- Comparer aux originaux : nous comparons avec les paquets, le dépôt, les sommes de contrôle du CMS et vos sauvegardes.
- Évaluer les découvertes : nous distinguons les modifications régulières des manipulations et sauvegardons les preuves.
- Nettoyer : avec la suppression de logiciels malveillants, nous rétablissons un état propre et le documentons.
Questions fréquentes
Comment trouver tous les fichiers modifiés depuis une date donnée ?
Avec find et l'option -newermt, par exemple find /var/www -type f -newermt "2026-10-17". Pour les modifications des métadonnées, utilisez -newerct. Les deux commandes ne font que lire et ne modifient rien.
Quelle est la différence entre mtime et ctime ?
mtime est le moment de la dernière modification du contenu et peut être antidaté avec de simples moyens. ctime est le moment de la dernière modification du contenu ou des métadonnées et ne se falsifie pas aussi facilement. Si les deux divergent fortement, un examen attentif s'impose.
Comment exclure les fichiers de cache de la recherche ?
Avec -not -path pour les dossiers connus de cache, de journaux et de sessions. N'excluez toutefois pas de façon trop large, car les attaquants aiment déposer des fichiers précisément là où de nombreuses modifications sont normales.
Quelle vérification est la plus fiable ?
La comparaison avec une source digne de confiance : sommes de contrôle de la gestion des paquets, dépôt Git ou sauvegarde antérieure à l'incident. Les horodatages sont un bon point de départ, mais pas une preuve.