Situación actual: PHP2Shell. Dos vulnerabilidades críticas de PHP (CVSS 9.2) permiten ejecutar código malicioso sin autenticación. Parches desde el 21/10/2026.Qué hacer ahora →

Análisis forense informático tras un ataque a un servidor web

Conservación de rastros con valor probatorio y evaluación tras un ataque a servidores web, junto con socios forenses especializados.

Actualizado 5 min de lecturaServicios

En resumen: El análisis forense informático de servidores responde a la pregunta de qué ha ocurrido realmente en un ataque: cuándo, cómo y con qué consecuencias. Junto con socios forenses especializados, aseguramos los rastros con valor probatorio, evaluamos registros, sistemas de archivos y bases de datos y entregamos un informe trazable. Sirve de base para las notificaciones, el seguro y, en su caso, la persecución penal.

Cuándo necesita un análisis forense informático para su servidor

No todo incidente requiere una investigación forense. Es conveniente sobre todo cuando podrían estar afectados datos personales, datos de pago o secretos empresariales, cuando se prevé una denuncia o un litigio, o cuando una aseguradora espera una prueba sólida. También para decidir si es necesaria una notificación a la autoridad de control, los hechos demostrados ayudan más que las suposiciones.

Tras PHP2Shell se añade un punto especial. Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 permiten ejecutar código sin autenticación, y no hay indicadores de compromiso (IOC) confirmados y publicados. Por eso no se puede dar por descartado con una lista de comprobación si un servidor estuvo afectado, sino solo mediante el análisis del comportamiento: ¿qué procesos se ejecutaron, qué archivos se crearon, qué conexiones salieron? Los primeros indicios los ofrece ¿Ya estoy comprometido?.

En qué se diferencia el análisis forense de una limpieza rápida

La limpieza quiere dejar el servidor de nuevo en buen estado. El análisis forense quiere entender y demostrar. Una pregunta es «¿vuelve a ser seguro el servidor?» y la otra «¿qué ha ocurrido exactamente y a qué datos se podía acceder?». Para las notificaciones, el seguro y la información a los clientes suele ser decisiva la segunda pregunta. Ambas son compatibles si el orden es el correcto: primero asegurar, después modificar. Quien primero borra, parchea o reinicia pierde rastros volátiles y después a menudo ya no puede mostrar qué vio el atacante.

Importante

Conserve todos los registros del servidor desde el 20/10/2026 y pida a su proveedor de hosting que no rote ni borre los registros. La falta de registros es la causa más frecuente de preguntas sin respuesta en el informe.

Qué rastros cuentan en un servidor web con PHP

En un servidor web típico hay más rastros de lo que muchos operadores suponen. Que sean aprovechables depende de cuánto tiempo se conserven y de si se aseguraron antes de la intervención.

  • Registros de acceso y de errores del servidor web y de PHP-FPM, incluidos los workers que se hayan bloqueado
  • Sistema de archivos: archivos nuevos o modificados, sus marcas de tiempo y propietarios, código ejecutable en carpetas de cargas
  • Base de datos: cuentas de usuario nuevas, ajustes modificados, contenidos introducidos
  • Sistema: tareas cron, usuarios, claves SSH, registros de inicio de sesión, procesos en ejecución y conexiones de red
  • Sistemas situados por delante: registros de CDN, WAF, cortafuegos, balanceador de carga y servidor de correo

Precisamente los sistemas situados por delante se olvidan con frecuencia. Están fuera del servidor web y, por eso, son más difíciles de manipular para un atacante. Algunos proveedores solo los conservan poco tiempo, así que conviene exportarlos pronto.

¿Cómo ayuda PHP SOS en concreto?

  1. Aclarar el encargo: definimos con usted qué preguntas deben responderse, por ejemplo puerta de entrada, periodo, datos afectados o desplazamiento por la red. De ahí resulta qué sistemas se investigan.
  2. Asegurar con valor probatorio: nosotros y nuestros socios especializados creamos copias de soportes de datos, registros, bases de datos y, cuando es posible, de la memoria. Cada copia lleva una suma de verificación y cada entrega queda documentada.
  3. Evaluar: analizamos los registros de acceso y de errores, los cambios en archivos, las cuentas de usuario, las tareas cron, los procesos y las conexiones salientes. La metodología para los registros se describe en Evaluar los registros del servidor web tras un ataque.
  4. Elaborar la cronología: con los hallazgos se elabora una cronología del incidente en la que cada afirmación remite a una prueba concreta.
  5. Entregar el informe: recibirá un informe técnico y un resumen comprensible para la dirección.

Lo que recibe y lo que necesitamos

El informe contiene las pruebas aseguradas con sus sumas de verificación, la documentación de la cadena de custodia, la cronología, la puerta de entrada determinada o probable, los sistemas y tipos de datos afectados y recomendaciones. Cada afirmación está señalada como demostrada, probable o desconocida.

De usted necesitamos:

  • acceso a los sistemas afectados o la autorización para que su proveedor de hosting nos facilite copias
  • una persona con capacidad de decisión que fije el alcance y las prioridades
  • información sobre el panorama de sistemas, los proveedores y los cambios conocidos de las últimas semanas
  • los registros disponibles, también de cortafuegos, CDN, WAF o servidores de correo
  • la indicación de si ya participan la aseguradora, la policía o un abogado

Si desea presentar una denuncia, encontrará indicaciones en Presentar una denuncia: Zentrale Ansprechstellen Cybercrime. Lo que las aseguradoras suelen esperar en caso de siniestro se explica en Ciberseguro: qué cuenta en caso de siniestro.

Lo que no prometemos

El análisis forense solo puede evaluar los rastros que existan. Si faltan registros, se han sobrescrito o los ha manipulado el atacante, quedan lagunas, y las señalamos. No prometemos que un tribunal valore nuestros resultados de una determinada manera, y no hacemos una valoración jurídica. No nombramos autores, sino que describimos lo que muestran los rastros. Tampoco hacemos afirmaciones como «seguro que no se han filtrado datos» salvo que las pruebas las sostengan.

Si el ataque aún está en curso, la contención tiene prioridad. Entonces empezamos con la respuesta a incidentes y aseguramos en paralelo tantos rastros como sea posible.

Preguntas frecuentes

¿Qué significa una conservación de pruebas válida ante los tribunales?

Los rastros se aseguran de modo que después pueda demostrarse que no han cambiado. Para ello se usan sumas de verificación, una cadena de custodia documentada y el trabajo sobre copias en lugar de sobre el original. Si un tribunal admite un medio de prueba, no obstante, lo decide el propio tribunal.

¿Puede el análisis forense aclarar si se han filtrado datos de clientes?

A menudo puede delimitarse a qué datos tuvo acceso un atacante y si hay indicios de filtración. No siempre es posible descartarlo con seguridad, sobre todo si faltan registros. Por eso el resultado se separa en demostrado, probable y desconocido.

¿Durante cuánto tiempo hay que conservar los registros?

Para el esclarecimiento, el mayor tiempo posible, como mínimo hasta que termine la investigación. En el caso de PHP2Shell, la prensa especializada aconseja conservar los registros del servidor desde el 20/10/2026. Las obligaciones legales de conservación y de supresión debe aclararlas con su delegado de protección de datos.

¿Puedo reiniciar o parchear el servidor antes del análisis forense?

Un reinicio borra rastros volátiles de la memoria y un parche modifica archivos. Si puede, asegure primero o hable brevemente con nosotros. Si el peligro es agudo, la contención tiene prioridad, y se documenta.

Fuentes

Contacto inmediato

Cada hora cuenta. Escríbanos ahora.

Describa brevemente el sistema, la versión de PHP y lo que ha observado. Nos pondremos en contacto, aclararemos la situación y trabajaremos en remoto hasta que el incidente quede cerrado y documentado.

Ayuda inmediata