En resumen: la cronología de un incidente informático ordena de forma cronológica todas las observaciones, decisiones y medidas en una zona horaria uniforme, idealmente UTC. Cada línea indica la fuente, la observación, la prueba y una valoración como probado, probable o desconocido. Así se obtiene una imagen comprensible de cuándo estuvo el atacante en el sistema, qué pudo alcanzar y cuándo tuvo usted conocimiento.
Por qué al final todos preguntan por el cuándo
Tras un incidente, las preguntas llegan de todas partes. El responsable de protección de datos quiere saber desde cuándo eran accesibles los datos personales. La aseguradora pregunta cuándo se descubrió y se notificó el daño. La dirección quiere saber si la brecha ya estaba abierta antes de la última actualización. Todas estas preguntas tienen algo en común: giran en torno a momentos concretos.
Sin cronología, cada uno responde de memoria y las respuestas se contradicen. Con una cronología bien llevada hay una base común a la que se remiten todos los implicados. Es además el esqueleto del informe final.
En PHP2Shell la cronología resulta especialmente reveladora porque los datos públicos esenciales están bien documentados. Pueden colocarse como puntos de anclaje junto a las propias observaciones. La secuencia completa de los hechos públicos la describe la guía PHP2Shell: la cronología.
La estructura: qué columnas necesita una cronología
Basta una tabla, ya sea en una hoja de cálculo o en un documento compartido. Lo importante son columnas fijas que se rellenan en cada línea. El siguiente modelo muestra los datos públicos esenciales de PHP2Shell como anclas y, debajo, entradas propias típicas en forma de marcador de posición:
| Hora (UTC) | Fuente | Observación | Prueba | Valoración |
|---|---|---|---|---|
| 17/10/2026 | Informes de prensa | primer intento de ataque observado con PHP2Shell | Informe de prensa | probado como informe de prensa |
| 20/10/2026 | php.net | preaviso de las actualizaciones de seguridad | Aviso en php.net | probado |
| 21/10/2026, 14:00 | php.net | publicación de 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Aviso en php.net | probado |
| hora propia | Access log | acumulación de errores 500 en páginas normales | Extracto del log, número de línea | probablemente relevante |
| hora propia | Sistema de archivos | archivo PHP nuevo en la carpeta de subidas | Copia con suma de verificación | probado, momento incierto |
| hora propia | interna | incidente detectado, dirección informada | Correo, nota de la conversación | probado |
| hora propia | interna | actualización instalada, todos los workers reiniciados | Log de paquetes, lista de procesos | probado |
La columna Valoración es la parte más importante. Separa lo que está demostrado, lo que parece plausible y lo que sigue abierto. Los lectores posteriores ven así de inmediato dónde se sostiene la cronología y dónde hay lagunas.
Cronología de un incidente informático: reunir las fuentes
Las entradas proceden de muchas fuentes, cada una con sus propios formatos y zonas horarias. Proceda en este orden:
- Fijar la zona horaria: lleve todo en UTC. El cambio al horario de invierno del 25/10/2026 desplaza una hora las horas locales alemanas en mitad del periodo. Quien mezcla horas locales desplaza eventos sin darse cuenta.
- Comprobar los relojes: ¿iba bien el reloj del servidor? Una comparación con un evento conocido, por ejemplo el propio inicio de sesión, muestra las desviaciones.
- Primero las fuentes externas: los logs del CDN, del WAF, del hoster o del cortafuegos están fuera del servidor y son difíciles de manipular. Forman el esqueleto.
- Completar con los logs del servidor: servidor web, PHP-FPM, inicios de sesión, journal del sistema. La metodología la describe Analizar los logs del servidor web tras un ataque.
- Situar el sistema de archivos: añadir como indicios las marcas de tiempo de archivos nuevos y modificados.
- Anotar los eventos internos: ¿cuándo se notó algo, a quién se informó, qué decisión se tomó y cuándo?
Lo que revelan las marcas de tiempo de los archivos y lo que no
Linux guarda para cada archivo varios momentos, entre ellos la última modificación del contenido (mtime) y la última modificación de los metadatos (ctime). Ambos pueden mostrarse en modo de solo lectura; aquí, como lista de los archivos PHP modificados desde una fecha de referencia, ordenada por hora en UTC:
# Modificaciones de contenido desde el 17/10/2026, ordenadas, en UTC
TZ=UTC find /var/www -type f -name '*.php' -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Todas las marcas de tiempo de un único archivo
TZ=UTC stat /var/www/ihre-website/verdaechtig.php
Trabaje para ello solo sobre una copia o una imagen asegurada, como se describe en Conservar las pruebas antes de reinstalar el servidor. Tenga en cuenta dos límites. Primero, un atacante puede restablecer con medios sencillos la fecha de modificación de un archivo; una mtime discreta no es una absolución. Segundo, las operaciones de copia y algunas herramientas modifican las marcas de tiempo. Por eso vale esto: los tiempos de los archivos son indicios; las entradas de logs externos son pruebas.
Anote el momento en que su empresa tuvo conocimiento de una posible violación de datos. Según el art. 33 RGPD, el plazo de 72 horas para una notificación comienza, en principio, con el conocimiento. La valoración corresponde a su responsable de protección de datos o a un abogado.
Errores típicos y cómo evitarlos
Los errores más frecuentes son poco espectaculares. La cronología se reconstruye de memoria solo al final, en lugar de llevarla de forma continua. Las entradas contienen conclusiones en lugar de observaciones, por ejemplo «el atacante entró por el formulario» en vez de «petición POST al formulario, después archivo nuevo». Y faltan pruebas porque nadie anotó de qué archivo de log y de qué línea procede una entrada.
Por eso, designe a una persona que lleve la cronología y anote los eventos en cuanto se producen. Las conclusiones van en una columna propia o en el informe, no en la observación.
Trate además la cronología como un documento confidencial. A menudo contiene direcciones IP, nombres de usuario e indicios de vulnerabilidades. Determine quién puede leerla y modificarla, y conserve las versiones anteriores. Si cambia una valoración, por ejemplo porque aparece un nuevo extracto de log, la línea antigua no se sobrescribe, sino que se completa. Así se puede seguir lo que se sabía en cada momento y con qué base se decidió.
¿Cómo ayuda PHP SOS en concreto?
- Llevamos la cronología de forma continua desde el primer contacto y en UTC, con fuente y prueba para cada entrada.
- Analizamos conjuntamente logs externos, logs del servidor y sistema de archivos, y marcamos cada afirmación como probada, probable o desconocida.
- Si es necesario, asumimos con socios especializados el análisis forense informático para una evaluación utilizable ante los tribunales.
- Entregamos la cronología como parte de un informe para la dirección, la protección de datos y el seguro.
Preguntas frecuentes
¿Para qué necesito una cronología tras un incidente de seguridad?
Ordena todas las observaciones en una secuencia y muestra cuándo estuvo el atacante en el sistema, qué pudo alcanzar y cuándo se enteró usted. Estos datos los necesitan los responsables de protección de datos, las aseguradoras, las autoridades y la dirección para sus decisiones.
¿En qué zona horaria debo llevar la cronología?
De forma uniforme en UTC. Los servidores, servicios y avisos usan zonas horarias distintas, y el cambio al horario de invierno a finales de octubre desplaza además las horas locales. Quien lo convierte todo a UTC y solo añade la hora local evita errores al cotejar.
¿Puedo fiarme de las marcas de tiempo de los archivos?
Solo en parte. La fecha de modificación de un archivo se puede falsificar con medios sencillos. Son más fiables las entradas de los logs, sobre todo las de logs ajenos al servidor afectado. Las marcas de tiempo de los archivos son indicios que conviene confirmar con otras fuentes.
¿Qué debe incluir la cronología además de los eventos técnicos?
También decisiones y comunicación: cuándo se notó el incidente, a quién se informó, cuándo se desconectó el servidor de la red, cuándo se parcheó. El momento en que se tuvo conocimiento es especialmente importante para los plazos de notificación.