En resumen: Si un servidor ha sido hackeado mediante PHP2Shell no puede deducirse de una sola característica. No hay indicadores de compromiso confirmados y publicados; la detección se basa en el análisis del comportamiento. Indicios típicos son archivos PHP nuevos, tareas cron desconocidas y conexiones inusuales. Asegure primero los registros a partir del 20 de octubre, antes de modificar nada.
¿Hay indicios inequívocos de un ataque de PHP2Shell?
No, y esa es la respuesta honesta. Para muchas vulnerabilidades conocidas, los fabricantes o las empresas de seguridad publican rastros concretos: nombres de archivo, sumas de verificación, direcciones IP. Para PHP2Shell no existen hasta ahora tales indicadores de compromiso confirmados.
Lo que se sabe: según informes de los medios, se observó un primer intento de ataque el 17 de octubre, cuatro días antes de los parches del 21 de octubre. Cloudflare informó de otros intentos. Según el BSI (Oficina Federal alemana para la Seguridad de la Información), al principio no se conocían ataques exitosos de forma generalizada. Quien estuvo accesible y sin protección entre el 17 de octubre y su propio parche debería, por tanto, comprobarlo en lugar de esperar.
Para la valoración cuenta sobre todo el periodo. Entre el primer intento de ataque observado, el 17 de octubre, y los parches, el 21 de octubre, no hubo ninguna actualización oficial. Todo servidor PHP accesible públicamente fue en ese tiempo potencialmente atacable. Cuánto tiempo estuvo abierto su servidor más allá de eso depende de cuándo se instaló la actualización y se reinició PHP. Cuanto más largo sea ese periodo y más sensibles los datos, por ejemplo cuentas de clientes, pedidos o candidaturas, más a fondo debería ser la revisión.
Indicios típicos de que un servidor ha sido hackeado
Tras una ejecución de código exitosa, los atacantes suelen intentar afianzarse y utilizar el servidor. De ahí resultan indicios que no son específicos de PHP2Shell, pero que cuentan en toda revisión de intrusión:
- Archivos PHP nuevos o modificados, sobre todo en directorios de cargas, de caché o de imágenes, donde normalmente no hay archivos PHP.
- Tareas cron desconocidas o tareas programadas, por ejemplo para el usuario del servidor web.
- Conexiones salientes inusuales hacia direcciones desconocidas, carga de red elevada o envío de correo que nadie ha iniciado.
- Cuentas de administrador nuevas en el CMS o la tienda, contraseñas modificadas, claves SSH desconocidas.
- Carga llamativa: uso de CPU permanentemente alto por procesos desconocidos, a menudo un indicio de minería de criptomonedas.
- Consecuencias visibles: redirecciones a sitios ajenos, páginas de spam en el índice de Google, avisos en el navegador o en la Search Console.
Ninguna de estas señales demuestra por sí sola una intrusión, y su ausencia no demuestra lo contrario. Lo decisivo es el conjunto.
Primeras comprobaciones sin destruir rastros
Antes de borrar o reiniciar nada: asegure los registros. La prensa especializada aconseja conservar los registros del servidor desde el 20 de octubre. Copie los registros del servidor web, de PHP y del sistema a un lugar seguro fuera del servidor.
Después ayudan las comprobaciones de solo lectura. Las rutas y los nombres de usuario varían según el sistema:
# Archivos PHP modificados desde el 17/10.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# Archivos PHP en directorios de cargas (ejemplo WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# Tareas cron del usuario del servidor web y del sistema
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# conexiones de red activas con su proceso
ss -tunp
# últimos inicios de sesión
last -n 30
Tenga en cuenta: los atacantes pueden falsificar las marcas de tiempo de los archivos. Un resultado sin anomalías de find no es, por tanto, una absolución. Cómo evaluar los registros de forma específica se describe en Evaluar los registros del servidor web tras un ataque; cómo encontrar puertas traseras, en Reconocer y eliminar webshells.
Si encuentra indicios concretos, por ejemplo un archivo PHP desconocido en la carpeta de cargas: no lo borre, no reinstale, no «repare rápido» la aplicación. Desconecte o aísle el servidor de la red, asegure los registros y una imagen del sistema, y empiece una gestión estructurada del incidente.
Lo que no debe hacer
- Solo parchear y seguir adelante. Un parche no elimina el software malicioso ya introducido.
- Borrar de inmediato los archivos sospechosos. Con ello desaparecen las pruebas de lo ocurrido y de qué datos pueden estar afectados.
- Reinstalar el servidor antes de asegurar. La causa queda sin aclarar y una puerta trasera en la base de datos o en las credenciales sobrevive a la reinstalación.
- Restaurar copias de seguridad antiguas sin revisar. También una copia puede contener ya la puerta trasera.
- Olvidar las credenciales. Tras una ejecución de código, las contraseñas de bases de datos, las claves de API y otras credenciales pueden haberse filtrado desde los archivos de configuración. Renuévelas después de la limpieza, no antes, para que un atacante todavía activo no lea de inmediato las nuevas.
Si la sospecha se confirma
Entonces se trata de más que de técnica. Compruebe con su delegado de protección de datos si es necesaria una notificación conforme al RGPD; el plazo es de 72 horas desde que se tiene conocimiento, detalles en Obligación de notificación del RGPD. Informe pronto a su ciberaseguradora, si la tiene, y aclare con un abogado si debe presentarse una denuncia. Nosotros damos indicaciones generales sobre ello, no asesoramiento jurídico.
¿Cómo ayuda PHP SOS en concreto?
Con nuestra respuesta a incidentes abordamos una sospecha de forma estructurada:
- Asegurar: registros a partir del 20 de octubre y, donde haga falta, una imagen del sistema, antes de modificar nada.
- Investigar: análisis del comportamiento de archivos, procesos, conexiones y cuentas; si es necesario, con valor probatorio ante los tribunales mediante análisis forense informático.
- Limpiar y cerrar: eliminar puertas traseras, actualizar PHP, renovar credenciales, reforzar el servidor.
- Documentar, hasta que el incidente esté cerrado y documentado, como base para la protección de datos, el seguro y la dirección.
Preguntas frecuentes
¿Demuestra la actualización de PHP que mi servidor está limpio?
No. Un parche cierra la vulnerabilidad de cara al futuro, pero no elimina el software malicioso ya introducido. Tampoco dice nada sobre si alguien entró antes del parche.
¿Hay un escáner que detecte con seguridad los ataques de PHP2Shell?
Hasta ahora no. No hay indicadores de compromiso confirmados y publicados que un escáner pueda buscar de forma específica. Los escáneres de malware encuentran webshells conocidas, pero la valoración de un servidor se basa en el análisis del comportamiento.
¿Debo notificar una sospecha a la autoridad de protección de datos?
Depende de si pueden estar afectados datos personales. El RGPD prevé para las violaciones de datos notificables un plazo de 72 horas desde que se tiene conocimiento. Aclárelo pronto con su delegado de protección de datos o con un abogado; nosotros no prestamos asesoramiento jurídico.
¿Debo reinstalar sin más el servidor hackeado?
No como primer paso. Asegure primero los registros y, si es posible, una imagen del sistema. Quien reinstala de inmediato pierde los rastros que muestran lo ocurrido y qué datos podrían estar afectados.