En resumen: En Linux encuentra los archivos modificados con find y una ventana temporal, por ejemplo desde el 17 de octubre de 2026, el primer intento de ataque observado a PHP2Shell según informes de medios. Compruebe no solo la hora de modificación del contenido (mtime), sino también la de los metadatos (ctime), porque la primera se falsea con facilidad. El resultado solo es fiable al contrastarlo con sumas de comprobación de paquetes, Git o una copia de seguridad.
Por qué las marcas de tiempo son un buen punto de partida, pero no una prueba
Quien lleva código a un servidor modifica archivos. Webshells nuevas, archivos de configuración adaptados, líneas añadidas a scripts existentes: todo ello deja marcas de tiempo. La búsqueda de cambios en la ventana temporal adecuada es por ello uno de los caminos más rápidos hacia los primeros hallazgos.
Para PHP2Shell, como inicio de la ventana resulta adecuado el 17 de octubre de 2026, el día del primer intento de ataque observado según informes de medios. Los parches aparecieron el 21 de octubre. Quien actualizó su servidor solo después busca hasta el día de su propia actualización y más allá. Cómo reconocer webshells entre los hallazgos lo describe Reconocer y eliminar webshells. Aquí se trata del método de búsqueda en sí.
Las tres marcas de tiempo de un archivo
Linux guarda varios momentos por cada archivo. Para buscar modificaciones son decisivos dos.
| Marca de tiempo | Significado | ¿Falsificable? |
|---|---|---|
| mtime | último cambio del contenido | sí, p. ej. con touch, por cualquiera que pueda escribir el archivo |
| ctime | último cambio de contenido o de metadatos como los permisos | no con medios sencillos |
| atime | último acceso de lectura | a menudo desactivado o impreciso, poco adecuado para la búsqueda |
Los atacantes retrasan gustosamente el mtime a la fecha de los archivos vecinos, para que un archivo nuevo no llame la atención. Pero el ctime cambia con ello. Un archivo con mtime antiguo y ctime reciente es por eso un fuerte indicio de manipulación.
Al comparar, preste atención a las zonas horarias. find y ls muestran la hora local del servidor, mientras que muchos archivos de registro y servicios trabajan en UTC. Quien pone uno al lado de otro los hallazgos del sistema de archivos y de los registros debería convertir todos los datos a la misma zona horaria; de lo contrario, los sucesos parecen no encajar. Los parches aparecieron hacia las 14:00 UTC del 21 de octubre, es decir, a las 16:00 hora alemana.
Encontrar archivos modificados en Linux con find
Todos los comandos solo leen. Adapte la ruta y la fecha.
# Contenido modificado desde el 17/10/2026, ordenado, con mtime, ctime y propietario
find /var/www -type f -newermt "2026-10-17" -printf '%TY-%Tm-%Td %TH:%TM %CY-%Cm-%Cd %CH:%CM %u %p\n' | sort
# Metadatos modificados desde el 17/10/2026 (encuentra también archivos con fecha retrasada)
find /var/www -type f -newerct "2026-10-17" -printf '%C+ %T+ %p\n' | sort
# Ocultar el ruido conocido: caché, registros, sesiones
find /var/www -type f -newerct "2026-10-17" \
-not -path "*/cache/*" -not -path "*/logs/*" -not -path "*/sessions/*" -printf '%C+ %p\n' | sort
# Mirar también fuera del directorio 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
En cada coincidencia, compare ambas marcas de tiempo. Si el ctime es claramente más reciente que el mtime y nadie ha cambiado permisos ni copiado archivos en ese tiempo, el archivo pasa a la lista. Fíjese también en el propietario: llama la atención un archivo del usuario del servidor web entre archivos del usuario de despliegue.
No olvide los archivos y directorios ocultos. Los nombres que empiezan por un punto no los muestran muchos gestores de archivos ni un simple ls. Los atacantes lo aprovechan gustosamente, igual que los nombres que se parecen a archivos auténticos hasta confundirse.
# Archivos y carpetas ocultos en el directorio web, sin los conocidos como .htaccess y .git
find /var/www -name ".*" -not -name ".htaccess" -not -name ".well-known" -not -path "*/.git/*" -printf '%C+ %u %p\n' | sort
Contrastar con una fuente de confianza
Las marcas de tiempo muestran dónde se ha movido algo. Si fue un cambio legítimo solo lo muestra la comparación con una fuente en la que usted confía.
- Gestión de paquetes: para archivos del sistema,
dpkg --verify(Debian/Ubuntu) orpm -Va(familia RHEL) comprueban los archivos con las sumas de los paquetes instalados. Los archivos de configuración difieren legítimamente; los archivos de programa, no. - Git: si la aplicación está en un repositorio,
git -C /var/www/projekt status --porcelainmuestra cualquier desviación respecto al último commit. - Sumas de comprobación del CMS: muchos sistemas pueden contrastar sus archivos del núcleo con las sumas oficiales, véase Comparar los archivos del núcleo del CMS con el original.
- Copia de seguridad anterior al incidente: una comparación en modo de prueba enumera diferencias sin copiar nada.
# Solo enumerar las diferencias entre el nivel de la copia y el sistema en vivo (modo de prueba, no copia nada)
rsync -rcn --out-format="%n" /backup/www-2026-10-15/ /var/www/
La comparación con la copia presupone que la copia se hizo antes del incidente y que no ha sido modificada. Por qué las copias guardadas por separado son decisivas aquí lo explica Copias de seguridad según la regla 3-2-1.
Guarde con fecha los resultados de cada búsqueda en un archivo fuera del servidor. De esas listas surge después la línea temporal del incidente, y prueban qué comprobó y cuándo.
Si no hay ni copia ni repositorio
En muchos sitios web pequeños no existe una base de comparación limpia: ni Git, ni copia anterior al incidente, y los plugins se han actualizado a mano durante años. Aun así, no se queda sin ningún punto de apoyo.
Descargue del fabricante el CMS y las extensiones exactamente en las versiones instaladas y compare esos archivos con el servidor. Lo que difiera o falte merece una mirada. Quedan sus propias adaptaciones, las subidas y la configuración; ahí ayuda la búsqueda por marcas de tiempo, complementada con una mirada a propietario y permisos. Los archivos que son los únicos de un directorio con otro grupo, otros permisos o un ctime claramente más reciente que sus vecinos pasan a la lista.
Hablando con franqueza: sin una base de comparación queda una incertidumbre residual. En sistemas con datos sensibles, una reconstrucción desde fuentes limpias suele ser entonces más fiable que buscar cada archivo modificado. Para el futuro la lección es sencilla: un repositorio para el código y copias de seguridad regulares guardadas por separado.
Fuentes de error típicas en la búsqueda
- Exclusiones demasiado generosas: las carpetas de caché y de subida son escondites favoritos.
- Solo se comprobó mtime: los archivos con fecha retrasada se escapan.
- Despliegue dentro de la ventana: un despliegue regular modifica cientos de archivos y oculta hallazgos sueltos. Contraste con el repositorio.
- Archivos ya abiertos o copiados: las copias que no conservan las marcas de tiempo destruyen huellas. Asegure con herramientas que conserven las marcas de tiempo.
- Solo se buscó en el directorio web: los atacantes dejan herramientas también en
/tmp,/dev/shmo en el directorio personal del usuario del servidor web. - Cambios de permisos pasados por alto: un archivo cuyos permisos permiten de pronto escritura a todos es un hallazgo, aunque su contenido no haya cambiado.
Cómo se ensamblan los hallazgos en un desarrollo lo muestra Crear la línea temporal de un incidente.
¿Cómo ayuda PHP SOS en concreto?
- Buscar de forma sistemática: examinamos directorios web y rutas del sistema en busca de cambios en la ventana temporal relevante y evaluamos conjuntamente mtime y ctime.
- Contrastar con originales: comparamos con paquetes, repositorio, sumas de comprobación del CMS y sus copias de seguridad.
- Valorar los hallazgos: separamos los cambios regulares de las manipulaciones y aseguramos pruebas.
- Limpiar: con la eliminación de malware restablecemos un estado limpio y lo documentamos.
Preguntas frecuentes
¿Cómo encuentro todos los archivos modificados desde una fecha determinada?
Con find y la opción -newermt, por ejemplo find /var/www -type f -newermt "2026-10-17". Para cambios en los metadatos use -newerct. Ambos comandos solo leen y no modifican nada.
¿Cuál es la diferencia entre mtime y ctime?
mtime es el momento del último cambio de contenido y puede retrasarse con medios sencillos. ctime es el momento del último cambio de contenido o de metadatos y no se falsea tan fácilmente. Si ambos difieren mucho, merece la pena una mirada atenta.
¿Cómo excluyo de la búsqueda los archivos de caché?
Con -not -path para carpetas conocidas de caché, registros y sesiones. Pero no excluya con demasiada generosidad, porque los atacantes dejan archivos justo donde muchos cambios son normales.
¿Qué comprobación es la más fiable?
La comparación con una fuente de confianza: sumas de comprobación de la gestión de paquetes, un repositorio Git o una copia de seguridad anterior al incidente. Las marcas de tiempo son un buen punto de partida, pero no una prueba.