En resumen: si su sitio web ha sido hackeado, esta lista de control ayuda a no olvidar nada: primero contener y conservar las pruebas, después encontrar la causa y limpiar, luego renovar todos los accesos, revisar las obligaciones y cerrar el incidente de forma documentada. El orden es importante, porque quien borra primero pierde rastros, y quien solo limpia sin cerrar la vulnerabilidad vuelve a ser atacado.
Para qué sirve esta lista de control cuando el sitio web ha sido hackeado
La lista de control se dirige a la dirección, los propietarios y los responsables de TI tras un ataque confirmado o probable a un sitio web, una tienda o un servidor web con PHP. Sirve también tras PHP2Shell, cuando un servidor era accesible antes de la actualización y hay indicios de compromiso.
No todos los puntos encajan en todos los entornos. Aun así, recorra la lista por completo y anote en cada punto si está hecho, no es aplicable o está pendiente. Este registro será valioso más adelante para el seguro, la protección de datos y la revisión interna.
Anote para cada paso la fecha, la hora, la persona responsable y el resultado. Si participan varias personas, determine una que lleve la lista y deje constancia de las decisiones.
Fase 1: contener y conservar de inmediato
- Limitar el daño: poner el sitio web en modo de mantenimiento o desconectarlo de la red si los visitantes están en peligro o podrían filtrarse datos. En PHP2Shell, el BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda desconectar temporalmente de la red los servidores web sin parchear cuando no es posible actualizar de inmediato.
- No borrar nada: no eliminar archivos, no reinstalar el servidor y no vaciar registros antes de haber conservado los rastros.
- Conservar los registros: copiar a otro sistema los registros de acceso, de errores, de PHP-FPM y del sistema, y guardar las sumas de comprobación. Sobre PHP2Shell, la prensa especializada recomienda conservar los registros desde el 20/10/2026.
- Conservar una imagen: crear como estado de prueba una copia de los archivos y de la base de datos y, en servidores virtuales, una instantánea, y no modificarla.
- Informar a los responsables: implicar pronto a la dirección, al delegado de protección de datos, al proveedor de hosting y, si existe, al ciberseguro. Muchos seguros tienen obligaciones de notificación.
Fase 2: encontrar la causa y limpiar
- Determinar la puerta de entrada: analizar registros, cambios en archivos y versiones. Revise PHP en sí, el CMS, los temas, las extensiones, las credenciales y los servicios del servidor. Sin causa conocida, permanece el riesgo de un nuevo ataque.
- Cerrar la vulnerabilidad: llevar PHP a una versión corregida (8.5.12, 8.4.27, 8.3.36 u 8.2.35, o bien un backport confirmado del proveedor), actualizar el CMS y las extensiones y reiniciar todos los workers de PHP.
- Acotar el periodo: determinar el momento más temprano de actividad sospechosa. Decide qué copias de seguridad pueden estar limpias y qué datos podrían estar afectados.
- Eliminar las puertas traseras: revisar y eliminar webshells, archivos PHP ajenos en las carpetas de subidas y de caché, archivos del núcleo modificados, tareas cron, claves SSH y servicios del sistema. Sustituir los archivos del núcleo desde una fuente limpia.
- Limpiar la base de datos: eliminar las cuentas de administrador desconocidas, los scripts introducidos en contenidos y ajustes y los contenidos de spam.
- Plantearse la reconstrucción: ante un compromiso profundo del servidor, una reconstrucción en un sistema nuevo y parcheado con datos verificados suele ser el camino más fiable que una limpieza en el sistema en funcionamiento.
Fase 3: renovar los accesos y reforzar
- Cambiar las contraseñas: del CMS, la cuenta de hosting, el panel, la base de datos, FTP, SFTP, SSH y el correo, y hacerlo desde un equipo limpio.
- Cambiar claves y tokens: volver a generar las claves de API, las interfaces de los servicios de pago y de envío, las claves de aplicación del CMS, las claves SSH y los certificados que estaban en el servidor.
- Cerrar las sesiones: desconectar todos los inicios de sesión activos en el CMS y en los servicios y revisar los dispositivos de dos factores registrados.
- Activar la autenticación de dos factores: para todos los accesos de administración, incluidos hosting, dominio y DNS.
- Reforzar el servidor: revisar y documentar los ajustes de PHP, los permisos de archivos, los bloqueos de ejecución en las carpetas de subidas, el cortafuegos y las cabeceras de seguridad.
Fase 4: obligaciones, comunicación y cierre
- Revisar las obligaciones de notificación: si pueden estar afectados datos personales, puede ser necesaria una notificación en 72 horas según el art. 33 del RGPD. La valoración corresponde al delegado de protección de datos o a un abogado. Las obligaciones sectoriales, por ejemplo según NIS2, deben revisarse aparte.
- Considerar una denuncia: las Zentrale Ansprechstellen Cybercrime (ZAC, puntos de contacto centrales de cibercrimen) de la policía alemana reciben denuncias de empresas. Los registros conservados son una base importante para ello.
- Informar a clientes y a Google: informar a los afectados de forma objetiva y coordinada. Si Google muestra una advertencia, solicitar la revisión tras la limpieza, como se describe en Quitar la advertencia de Google.
- Documentar el cierre y vigilar: dejar constancia en un informe de la causa, el periodo, las medidas y los puntos pendientes, extraer lecciones para el plan de emergencia y vigilar los sistemas de forma reforzada durante las semanas siguientes.
Errores frecuentes en el seguimiento
Muchos incidentes se alargan porque, en la primera agitación, se ahorra en el lugar equivocado o se actúa demasiado deprisa. Conviene evitar estos errores:
- Eliminar solo lo visible: una página de spam borrada o una redirección eliminada no prueban que el sitio web esté limpio. Las puertas traseras suelen pasar inadvertidas.
- Cambiar las contraseñas desde el sistema afectado: si en el equipo o en el servidor sigue ejecutándose software malicioso, las nuevas credenciales pueden filtrarse de inmediato.
- Restaurar a ciegas una copia de seguridad: sin vulnerabilidad cerrada y sin revisar la copia, el atacante vuelve enseguida a la puerta.
- Entender el parche como señal de que todo está bien: una actualización a una versión corregida de PHP no demuestra que antes no pasara nada y no elimina el software malicioso introducido.
- Revisar las obligaciones demasiado tarde: los plazos comienzan con el conocimiento del incidente, no con el final de la limpieza.
- Sin documentación: sin registro, las preguntas del seguro, las autoridades o los clientes son difíciles de responder más adelante.
Esta lista de control no sustituye al asesoramiento jurídico. Ante dudas sobre obligaciones de notificación, responsabilidad o seguro, diríjase a su delegado de protección de datos, a un abogado o a su aseguradora.
¿Cómo ayuda PHP SOS en concreto?
- Asumimos la respuesta a incidentes estructurada y seguimos la lista de control junto con usted, punto por punto y con registro.
- Conservamos registros y estados del sistema de modo que sigan siendo utilizables para el seguro, las autoridades y un posible análisis forense informático.
- Cerramos la vulnerabilidad, limpiamos o reconstruimos y renovamos los accesos en el orden correcto.
- Entregamos un informe final con causa, medidas y recomendaciones y, si lo desea, seguimos vigilando después los sistemas.
Preguntas frecuentes
¿Qué es lo primero que debo hacer si mi sitio web ha sido hackeado?
Mantener la calma, no borrar nada y limitar el daño. Si hace falta, desconecte el sitio web de la red o póngalo en modo de mantenimiento y conserve los registros y archivos antes de limpiar. Después vienen la búsqueda de la causa y la limpieza.
¿Basta con restaurar el sitio web desde una copia de seguridad?
Normalmente no. La copia ya puede contener código malicioso, y la vulnerabilidad por la que entró el atacante sigue abierta tras la restauración. Primero hay que cerrar la causa y después restaurar un estado verificado y limpio en un sistema actualizado.
¿Debo notificar un hackeo a la autoridad de protección de datos?
Si pueden estar afectados datos personales, el art. 33 del RGPD prevé en principio una notificación en las 72 horas siguientes a tener conocimiento, siempre que no sea improbable un riesgo para los afectados. La valoración corresponde a su delegado de protección de datos o a un abogado.
¿Cuándo está realmente cerrado un incidente?
Cuando la causa está cerrada, se han eliminado todas las puertas traseras conocidas, se han renovado los accesos, se han cumplido las obligaciones y las medidas están documentadas. Forma parte de ello un periodo posterior de vigilancia reforzada para detectar rastros pasados por alto.