Cómo recuperar una web hackeada, paso a paso

La primera hora

La primera hora no es para limpiar, es para parar el daño y no perder información. Por orden:

1. Mira qué está pasando desde fuera. Abre la web desde el móvil con datos y en incógnito, entrando desde Google. Anota lo que ves: redirección, aviso de Chrome, página cambiada, formulario de pago raro. Haz capturas con la fecha.
2. Si es una tienda, revisa el pago antes que nada. Si el checkout muestra un formulario de tarjeta que no debería estar ahí, desactiva ese método de pago. Cada pedido con un skimmer activo es una tarjeta robada. Lo explico en robo de tarjetas en tu tienda.
3. Valora poner la web en mantenimiento. Si está redirigiendo a estafas o repartiendo malware, una página de mantenimiento protege a tus visitantes mientras trabajas. Hazlo desde el hosting o con una regla del servidor, no desde un plugin de la propia web infectada.
4. Avisa a tu hosting. No para que «lo limpien» con un escáner, sino para saber si han visto algo (correo masivo, procesos raros) y para que no te suspendan la cuenta sin aviso. Pídeles los logs de acceso de los últimos días.
5. Apunta las fechas: cuándo te diste cuenta, cuándo empezaron las quejas, si ha habido cambios recientes (un plugin nuevo, una actualización, un proveedor con acceso).

No restaures todavía

Restaurar la copia de ayer parece lo más rápido, pero tiene tres problemas:

• No sabes si la copia está limpia. Muchas infecciones llevan semanas dentro antes de dar la cara. La copia de ayer puede tener ya la puerta trasera.
• El fallo sigue abierto. Si entraron por un plugin o módulo vulnerable, la copia trae el mismo plugin vulnerable. Volverán a entrar por el mismo sitio, a menudo de forma automática.
• Borras las pruebas. Los archivos infectados, sus fechas y los logs dicen por dónde entraron y qué se llevaron. Si hay datos de clientes en juego, vas a necesitar contarlo.

Antes de tocar nada, haz una copia completa del estado actual, infectado incluido: todos los archivos, la base de datos y los logs del servidor. Guárdala fuera del servidor. Desde SSH, algo así:

# Archivos (desde la carpeta superior a la web)
tar -czf web-hackeada-$(date +%F).tar.gz public_html/

# Base de datos
mysqldump -u USUARIO -p NOMBRE_BD > bd-hackeada-$(date +%F).sql

Sin SSH, el panel del hosting suele tener una opción de copia completa o de descarga de la base de datos con phpMyAdmin. Esa copia no se restaura nunca tal cual: es tu prueba y tu red de seguridad.

Contraseñas en orden

Hay que cambiar todas las credenciales que dan acceso a la web, desde un ordenador que sepas limpio (si el tuyo tiene un troyano, el atacante verá las contraseñas nuevas):

• Panel del hosting y cuenta del registrador del dominio.
• FTP y SFTP, y las claves SSH que no reconozcas en ~/.ssh/authorized_keys.
• Usuario de la base de datos (y actualízalo en la configuración de la web: wp-config.php en WordPress, app/config/parameters.php en PrestaShop 1.7 y posteriores).
• Todos los administradores de la web, y borra los que no reconozcas.
• En WordPress, las claves y «salts» de wp-config.php, para cerrar las sesiones abiertas.
• Cuentas conectadas: pasarela de pago, Google Search Console, correo del dominio.

Activa la verificación en dos pasos donde se pueda, empezando por el hosting y el registrador: con ellos, un atacante puede llevarse el dominio entero.

Limpiar sin perder pruebas

La limpieza buena no consiste en borrar lo que parece raro, sino en sustituir lo conocido por su original y revisar a mano lo que no tiene original. Así trabajo yo:

1. Núcleo: comparo cada archivo con el original de la misma versión. En WordPress, wp core verify-checksums; en PrestaShop, contra el paquete oficial de esa versión exacta. Lo que no coincide se sustituye.
2. Plugins, módulos y temas: los que tienen versión pública se reinstalan desde la fuente oficial. Los comprados o hechos a medida se revisan archivo por archivo.
3. Archivos que no deberían existir: PHP dentro de carpetas de subidas o imágenes, archivos con nombres aleatorios en la raíz, .htaccess añadidos en subcarpetas.
4. Base de datos: scripts inyectados en opciones, contenidos y configuración; usuarios administradores nuevos; tareas programadas.
5. Servidor: tareas cron del usuario del hosting (crontab -l), que a veces reinstalan la infección cada hora.
6. La entrada: con lo anterior y los logs, busco por dónde entraron. Si no se encuentra, se cierran todas las candidatas (actualizar todo, quitar lo que no se usa).

Cada cosa que quites, muévela a una carpeta fuera de la web en lugar de borrarla, y apunta de dónde la sacaste. Si luego resulta que hay datos personales afectados, esa lista es la base del informe. Para encontrar qué tocar, tienes las guías de WordPress hackeado, de PrestaShop hackeado y la general de cómo saber si tu web está hackeada.

Si tienes copia y si no la tienes

Si tienes copias

Una copia sirve, y mucho, pero como fuente de archivos limpios, no como botón de deshacer. Busca la copia más reciente que sea anterior a la infección (las fechas de los archivos infectados y los logs te dan una pista) y úsala para recuperar lo que no tiene original público: el tema a medida, las imágenes, la base de datos de antes del ataque. Si restauras la base de datos antigua en una tienda, perderás los pedidos y clientes posteriores: en ese caso es mejor limpiar la base de datos actual.

Después de restaurar, actualiza o quita lo que estaba vulnerable antes de volver a abrir la web. Si no, se repite el ciclo.

Si no tienes copias

Se puede recuperar igual, solo que con más trabajo manual: el núcleo y los plugins o módulos públicos se reinstalan desde su origen, y lo propio (tema, contenidos, base de datos) se limpia a mano. Es lo más habitual en los casos que me llegan. Cuando acabes, configura copias diarias fuera del servidor: una copia que vive en el mismo hosting cae con él.

Pedir la revisión a Google

Si Google muestra «Este sitio puede haber sido pirateado» o Chrome enseña la pantalla roja, el aviso no se va solo. Cuando la web esté limpia:

1. Verifica la web en Google Search Console si no lo estaba, y revisa que no haya propietarios que no conozcas.
2. Abre Seguridad y Acciones manuales → Problemas de seguridad y comprueba las URL de ejemplo: deben dar 404 o mostrar tu contenido.
3. Pulsa Solicitar revisión y explica qué encontraste, qué hiciste y cómo cerraste la entrada.

Lo explico con todo detalle, incluidos los plazos que publica Google, en cómo quitar el aviso de sitio peligroso.

Datos personales: no lo dejes para el final

Si la web guarda datos de clientes (una tienda, un área privada, formularios) y el atacante ha podido verlos, en España el RGPD te da 72 horas desde que lo sabes para notificarlo a la AEPD, salvo que no suponga un riesgo para las personas. Ese reloj corre mientras limpias. Lo tienes paso a paso en brecha de datos en tu tienda online.

Cuándo pedir ayuda (precio)

Puedes hacerlo tú si tienes acceso SSH, sabes moverte por la base de datos y tienes tiempo. Te recomiendo pedir ayuda si se cumple alguna de estas:

• Es una tienda y hay sospecha de robo de tarjetas o datos de clientes.
• Ya lo limpiaste (tú o tu hosting) y ha vuelto.
• No sabes por dónde entraron.
• La web factura y cada día con el aviso de Google te cuesta dinero.

Mis precios, publicados y sin sorpresas:

• WordPress: 219 € (IVA no incluido). Con prioridad sobre el resto de trabajos: +80 €. Qué incluye, en limpiar un WordPress hackeado.
• PrestaShop o WooCommerce: 349 € (IVA no incluido), con la revisión del pago y de los datos de clientes. Con prioridad: +100 €. Qué incluye, en limpiar un PrestaShop hackeado.
• Otros CMS o PHP a medida: desde 390 €, con presupuesto cerrado antes de empezar.

Todas las limpiezas incluyen la revisión en Google Search Console, el cierre de la entrada, el informe de lo que había y de lo que hice, y 90 días de garantía: si se vuelve a infectar en ese plazo, la limpio sin coste. Todo, en web hackeada. Si no tienes claro si está infectada, empieza por el análisis gratuito.

Fuentes

• web.dev: limpiar y mantener tu sitio (copia del sitio infectado antes de limpiar, restaurar solo una copia anterior al hackeo y cambiar todas las contraseñas).
• web.dev: identificar la vulnerabilidad (contraseñas débiles, software sin actualizar y equipos de administración infectados como vías de entrada).
• WordPress: FAQ «My site was hacked» (documentar fechas, revisar el equipo local, cambiar los accesos FTP, panel y MySQL y renovar las claves de wp-config.php para cerrar sesiones).
• WP-CLI: wp core verify-checksums (compara el núcleo con las sumas de comprobación de WordPress.org).
• Reglamento (UE) 2016/679, RGPD, artículo 33 (BOE) y AEPD: notificación de brechas de datos personales (plazo de 72 horas).