Web hackeada: qué hacer en las primeras 24 horas

Lo primero: tres decisiones en los primeros 15 minutos

Antes de tocar nada, decide y anota. Estas tres decisiones condicionan todo lo que viene después:

• Aislar, no borrar. Se pone el sitio en mantenimiento para todo el mundo menos para tu dirección IP. El visitante ve una página de mantenimiento; tú sigues pudiendo investigar. Lo que nunca se hace es borrar archivos, reinstalar o restaurar copia en caliente.
• Dejar de usar equipos sospechosos. Cambia todas las contraseñas desde un ordenador limpio, con antivirus actualizado y sin sesiones guardadas del navegador. Si el atacante tiene tu equipo, da igual lo que limpies en el servidor.
• Preservar evidencia. Los registros de acceso (logs) de los últimos 30 días son la prueba de por dónde entraron. Muchos hostings los rotan a los pocos días: descárgalos hoy.

Las primeras 24 horas, franja a franja

Este es el reparto de trabajo que aplicamos en incidentes reales. El objetivo de cada franja es distinto y conviene no mezclarlas.

Franja	Objetivo	Acciones clave
0 – 1 h	Contener el daño	Modo mantenimiento, rotación de contraseñas, cierre de sesiones, revisión de usuarios administradores, 2FA en hosting y panel
1 – 3 h	Preservar evidencia	Copia completa de archivos y base de datos, descarga de logs de acceso y errores, capturas del estado comprometido
3 – 8 h	Identificar la vía de entrada	Usuarios falsos, plugins y temas vulnerables, cron, .htaccess, archivos modificados, contenido spam en la base de datos
8 – 24 h	Reconstruir y endurecer	Núcleo y extensiones desde fuentes oficiales, limpieza de base de datos, permisos, WAF y backups externos
Día 2 – 30	Volver a producción y vigilar	Revisión en Search Console, aviso a clientes si procede, monitorización de cambios de archivos

Hora 0 a 1: contener sin destruir pruebas

La contención se hace en el servidor y en las cuentas, no en el contenido:

• Bloquea el acceso público con una regla que permita solo tu IP, o activa el modo mantenimiento desde el propio hosting (no desde un plugin que el atacante puede desactivar).
• Cambia contraseñas de todo lo que toque la web: panel de hosting, FTP/SFTP, base de datos, usuario administrador del CMS y correo asociado. Empieza por el correo, porque desde ahí se solicitan los restablecimientos del resto.
• Cierra todas las sesiones activas. En WordPress, cambiar las claves de seguridad de wp-config.php invalida todas las cookies de sesión de golpe. Es más rápido que expulsar usuario por usuario.
• Revoca claves y accesos de terceros: API del ERP, pasarela de pago, servicios de correo transaccional, accesos de colaboradores que ya no trabajan contigo.
• Activa doble factor en hosting y en el panel del CMS antes de volver a abrir el sitio.

Hora 1 a 3: la copia forense que casi nadie hace

Esta copia no es una copia de seguridad: es la escena del delito. Se guarda en un almacenamiento externo, con fecha, y no se restaura encima del servidor.

• Archivos completos del sitio, incluidos wp-content/uploads, mu-plugins y cualquier carpeta oculta.
• Volcado completo de la base de datos, tabla a tabla.
• Logs de acceso de 30 días y logs de errores de PHP.
• Capturas de pantalla de lo que veía el visitante: redirecciones, páginas spam, aviso del navegador.
• Anotación con hora de cada hallazgo y nombre de quien lo detectó.

Si más adelante hay que notificar una brecha o reclamar al proveedor, este material es lo que sostiene la explicación.

Hora 3 a 8: encontrar la vía de entrada

Aquí se responde a la única pregunta que importa: ¿cómo entraron? Estos son los puntos donde aparece la respuesta en la mayoría de los casos que tratamos.

• Usuarios administradores desconocidos. Revisa la lista completa, no solo la primera página, y comprueba el correo asociado a cada uno.
• Plugins y temas. Extensiones abandonadas con vulnerabilidades conocidas y, muy frecuentemente, plugins o temas descargados de sitios no oficiales (versiones “nulled”). Ahí no solo hay malware: hay acceso permanente del que lo publicó.
• Archivos modificados recientemente. Ordenar el árbol de ficheros por fecha de modificación delata qué se tocó en las últimas 48 horas: index.php, functions.php, un nuevo .htaccess o un archivo con nombre inofensivo en uploads.
• Tareas programadas (cron). Un cron creado por el atacante vuelve a introducir el código aunque limpies todo lo demás.
• Base de datos. Opciones inyectadas en wp_options, publicaciones o páginas con enlaces externos, usuarios con capacidades elevadas en wp_usermeta.
• Credenciales filtradas. Contraseñas reutilizadas que aparecen en listados públicos de filtraciones, o accesos de hosting compartidos por correo o chat.

Hora 8 a 24: reconstruir en lugar de parchear

La regla que seguimos: se reinstala, no se limpia a mano. Buscar líneas maliciosas una por una lleva días y siempre queda algo.

• Descargar el núcleo del CMS desde su fuente oficial y sustituirlo completo, conservando únicamente el archivo de configuración y el contenido subido.
• Reinstalar cada plugin y tema desde su repositorio oficial, en su versión actual. Los que no se usen, se eliminan. Los abandonados, se sustituyen.
• Auditar la base de datos tabla a tabla antes de dar por buena la limpieza; comparar el listado de usuarios y sus permisos con el inventario real.
• Corregir permisos: archivos en 644, carpetas en 755, y bloquear la ejecución de PHP dentro de la carpeta de subidas.
• Añadir capa de protección: WAF, bloqueo de intentos de acceso, limitación de peticiones y cabeceras de seguridad.
• Comprobar que las copias de seguridad se guardan fuera del servidor y que se han restaurado alguna vez. Una copia que vive en el mismo hosting comprometido no sirve de nada.

Un sitio comprometido no se arregla borrando archivos: se arregla cerrando la puerta por la que entraron. Si no sabes cuál era esa puerta, la limpieza es solo una pausa hasta el siguiente intento.

Obligaciones legales y aviso a clientes

Si el atacante ha podido acceder a datos personales de clientes —pedidos, direcciones, correos, contraseñas—, hay obligaciones que no dependen del tamaño de tu empresa:

• Notificación a la autoridad de control en un plazo máximo de 72 horas desde que se conoce la brecha, salvo que sea improbable que suponga un riesgo para los derechos de las personas.
• Comunicación a los afectados cuando el riesgo sea alto: qué ha pasado, qué datos, qué consecuencias y qué pueden hacer.
• Registro interno del incidente con hechos, efectos y medidas adoptadas, aunque no se notifique.

El mensaje a clientes debe ser claro y sin tecnicismos: qué ha ocurrido, qué datos pueden estar afectados, qué medidas hemos tomado y qué recomendamos hacer (cambiar la contraseña si es compartida con otros servicios). Ocultarlo suele costar más reputación que el propio incidente.

Volver a Google: avisos, spam indexado y revisión

El hackeo tiene una segunda vida en los buscadores, y hay que desactivarla:

• Revisar en Search Console el apartado de problemas de seguridad y las acciones manuales, y enviar la solicitud de revisión cuando el sitio esté limpio. Sin esa solicitud, el aviso puede mantenerse semanas.
• Comprobar qué páginas spam se indexaron y devolver 410 o 301 según corresponda. Nunca dejarlas respondiendo 200.
• Revisar enlaces salientes inyectados en el contenido y retirarlos.
• Volver a enviar el sitemap y verificar las URLs principales una a una.
• Pedir la retirada de la advertencia de navegador revisando la configuración de la cuenta de propietario del sitio en los servicios de navegación.

Conclusión: 24 horas para contener, 30 días para recuperar

El error más caro es actuar por impulso: borrar, reinstalar y restaurar copia en la primera hora. Eso destruye la evidencia, oculta la vía de entrada y garantiza la reincidencia. El orden correcto es contener, copiar, entender y reconstruir, y dedicar el mes siguiente a vigilar y a cerrar los huecos que permitieron el acceso.

Los casos que salen bien comparten dos cosas: había una copia de seguridad externa verificada y alguien con criterio llevando el protocolo. Ese es exactamente el trabajo que describimos en seguridad y recuperación web, y la parte de prevención continua está en mantenimiento y backups gestionados. En el caso de la tienda de moda recuperada tras un hackeo puedes ver el procedimiento aplicado de principio a fin, sin días de caída añadidos.