Archivos modificados y timestamps: el IoC que revela el backdoor

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Cuando investigamos una intrusión en WordPress, el primer artefacto que pedimos no es un plugin de seguridad ni un informe de terceros: es el sistema de ficheros con sus fechas intactas. El estudio de los archivos modificados en un WordPress hackeo es, con diferencia, el indicador de compromiso (IoC) que más veces nos ha llevado directamente al backdoor. Un fichero que no debería haber cambiado y que, sin embargo, tiene una fecha de modificación posterior al despliegue del core delata la puerta trasera con más fiabilidad que cualquier firma antivirus. Este artículo forma parte de nuestra investigación de referencia, Anatomía del hackeo: persistencia, backdoors y SEO-spam, donde encuadramos esta técnica dentro del ciclo completo de un compromiso.

Por qué los archivos modificados de un WordPress hackeo son el mejor IoC

WordPress es, en esencia, un conjunto de ficheros con fechas muy predecibles. El core (los directorios wp-admin y wp-includes, más los .php de la raíz) se despliega de golpe en cada actualización: todos sus archivos comparten prácticamente el mismo minuto de modificación. Los plugins y temas se actualizan en lotes. Los uploads crecen de forma orgánica pero contienen imágenes y PDF, no código ejecutable. Cualquier desviación de este patrón es sospechosa por definición.

Un atacante que instala un web shell tiene que escribir en disco. Ese acto deja una huella temporal. Aunque logre camuflar el contenido con ofuscación, ocultar el nombre entre ficheros legítimos o esconderlo en wp-content/uploads, el momento de la escritura queda registrado en los metadatos del inodo. Reconstruir esa línea temporal es la base del análisis DFIR sobre sistemas de ficheros.

mtime, ctime y atime: tres relojes, no uno

El error habitual es fijarse solo en la fecha que muestra el explorador de archivos o el gestor del panel. En sistemas Unix cada fichero tiene tres marcas de tiempo distintas y entenderlas es lo que separa un análisis serio de una corazonada:

• mtime (modification time): última vez que cambió el contenido. Es el que la mayoría de herramientas muestra por defecto y el que un atacante intentará falsear.
• ctime (change time): última vez que cambiaron los metadatos del inodo (permisos, propietario, enlaces) o el contenido. Aquí está la clave: touch y las funciones estándar de PHP pueden reescribir el mtime, pero el ctime lo controla el kernel y es mucho más difícil de manipular sin privilegios de root.
• atime (access time): último acceso de lectura. Poco fiable en la práctica porque muchos servidores lo desactivan (noatime) por rendimiento.

La técnica de manipulación se conoce como timestomping: el atacante ejecuta el equivalente a touch -d para que el web shell aparente ser tan antiguo como el resto del core. Funciona contra un vistazo superficial, pero la asimetría entre mtime y ctime lo desenmascara. Cuando encontramos un fichero cuyo mtime dice «marzo de 2021» pero cuyo ctime dice «anteanoche a las 03:14», tenemos al backdoor localizado. El core original nunca presenta esa discrepancia. Esta manipulación se cataloga en el framework MITRE ATT&CK como Server Software Component: Web Shell (T1505.003), dentro de las técnicas de persistencia que documentamos en nuestras investigaciones.

Cómo levantar la línea temporal en la práctica

Con acceso por SSH, el barrido inicial busca todo lo escrito en las últimas horas o días dentro del árbol de la web. Un find . -type f -mmin -1440 lista los ficheros modificados en las últimas 24 horas; ordenar por ctime en lugar de mtime evita caer en la trampa del timestomping. El objetivo es contrastar ese listado con lo que debería haber cambiado: si nadie ha actualizado plugins y aparece un .php nuevo en wp-content/uploads/2024/, no hay explicación legítima.

Los patrones que más nos hacen levantar la ceja son concretos y repetibles:

• Ficheros PHP dentro de uploads, wp-content/cache o cualquier carpeta pensada para datos, no para código.
• Nombres mimetizados con el core (wp-conf.php, wp-load-old.php, class-wp-cache.php) que no existen en una instalación limpia.
• Un único fichero del core con mtime distinto al de sus vecinos: casi siempre index.php, wp-config.php o el functions.php del tema activo, alterados para incluir el payload.
• Archivos con permisos anómalos (777) o propietario distinto al del resto del sitio.

La comparación contra un checksum de referencia cierra el círculo. WordPress publica los hashes de cada versión del core, de modo que verificar la integridad revela al instante qué ficheros oficiales han sido tocados. Para plugins y temas la lógica es la misma: reinstalar sobre una copia oficial y comparar diferencias saca a la luz las líneas inyectadas.

El timestamp también delata el SEO-spam

Los mismos metadatos temporales sirven para acotar la inyección de contenido basura. Cuando un sitio empieza a posicionar por farmacias o casinos, el punto de entrada suele ser un fichero modificado que reescribe el .htaccess o inyecta enlaces ocultos según el user-agent. Cruzar la fecha de esa modificación con los picos de rastreo de Google acota la ventana del incidente y ayuda a estimar cuánto lleva el sitio sirviendo spam, algo que importa de cara a las políticas de spam de Google y a la recuperación de la reputación en el buscador.

Un IoC no basta: por qué el timestamp es el principio, no el final

Localizar el fichero modificado es el primer eslabón, no la solución. Un backdoor rara vez viaja solo. Muchas intrusiones dejan una tarea programada que reescribe el web shell minutos después de que lo borres; por eso, tras identificar los archivos sospechosos, revisamos siempre los mecanismos que los regeneran. Lo explicamos en detalle en Cron jobs y tareas fantasma: el IoC que reinfecta tu web una y otra vez. Y cuando el sitio vuelve a infectarse pese a haber limpiado todo lo visible, el problema es una persistencia más profunda que abordamos en Por qué tu web se reinfecta: erradicar puertas traseras persistentes.

En incidentes exigentes -banca, comercios que manejan datos de tarjeta- este análisis temporal no es opcional: es la evidencia que sostiene un informe forense defendible y la reconstrucción precisa de la línea de tiempo del ataque. Referencias como el blog de Sucuri documentan a diario campañas donde el timestamp fue lo que rompió el caso. La disciplina de leer bien los tres relojes del fichero es lo que convierte una limpieza superficial en una erradicación real.

Si sospechas que tienes ficheros modificados sin explicación pero no sabes por dónde empezar a leer las fechas, habla con nuestro equipo y revisamos tu caso.