La alerta llega cuando la web empieza a redirigir visitas, aparecen archivos desconocidos o la tienda muestra pedidos extraños. Tienes varias copias de seguridad y la urgencia empuja a restaurar la más reciente, pero esa copia puede contener ya la puerta trasera, el código malicioso o los cambios del atacante.
La recuperación tras hackeo usando backups no consiste en restaurar la última copia disponible: primero aísla el sitio, localiza una copia anterior al compromiso y valídala fuera de producción. Después, elige restauración completa, selectiva o limpieza manual según el alcance, para recuperar el servicio sin reintroducir malware ni perder más datos de los necesarios.
Índice
Anuncio
Aísla el incidente antes de elegir una copia
Corta los accesos activos y evita una reinfección inmediata. Activa el modo mantenimiento desde el hosting o bloquea el acceso público con una regla temporal del firewall de aplicaciones web, también llamado WAF. Si hay una tienda WooCommerce de Madrid con pagos activos, deja una página temporal que no acepte pedidos y avisa al equipo de atención al cliente.
Bloquea cada puerta de entrada
Cambia las credenciales fuera de WordPress antes de restaurar. Modifica las claves del panel de hosting, FTP/SFTP, phpMyAdmin, usuarios MySQL, correo, CDN, cuentas de administrador y accesos de colaboradores. SFTP es el protocolo para mover archivos al servidor; si esas credenciales siguen abiertas, una instalación restaurada puede infectarse de nuevo en pocos minutos.
Conserva pruebas sin reutilizarlas
Descarga los registros y marca la hora de cada acción. Crea un documento sencillo con la hora de detección, síntomas, usuarios nuevos, archivos sospechosos, alertas del antivirus y cambios aplicados. Este trabajo suele llevar entre 10 y 20 minutos si el hosting ofrece un panel de logs claro.
Elige el último backup limpio con RPO y RTO
Selecciona una copia anterior a la intrusión y calcula la pérdida asumible. El RPO, objetivo de punto de recuperación, indica cuántos datos puedes perder. El RTO, objetivo de tiempo de recuperación, marca cuánto tiempo puede estar caída la web sin causar un daño inaceptable.
Calcula cuándo empezó el compromiso
Busca la primera señal técnica, no la fecha en que alguien vio el problema. Compara varias copias: fecha de archivos modificados, usuarios creados, picos de peticiones, correos enviados y cambios en el tráfico orgánico. Revisa también alertas del WAF y el historial de actualizaciones de plugins y temas.
Revisa el tipo y la cadena de copia
Comprueba que la copia puede restaurarse completa y sin huecos. Un backup completo contiene todos los archivos y la base de datos. Un backup incremental guarda solo cambios desde la copia anterior, mientras que uno diferencial guarda cambios desde el último backup completo.
| Tipo de copia | RPO habitual | Tiempo de prueba | Cuándo elegirla |
|---|---|---|---|
| Completa diaria | Hasta 24 horas | 30 a 90 minutos | Web corporativa con pocos cambios diarios |
| Completa más incremental | 1 a 12 horas | 45 a 120 minutos | Tienda o portal con actividad continua |
| Snapshot del hosting | Depende de la frecuencia | 20 a 60 minutos | Solo si incluye archivos, base de datos y fecha verificable |
| Backup offsite | Según su programación | 30 a 120 minutos | Incidente que afecta al propio servidor |
Prioriza una copia fuera del servidor
Elige una copia offsite si el servidor afectado también pudo ser manipulado. Una copia offsite se guarda fuera de la infraestructura principal, por ejemplo, en otro proveedor o en un almacenamiento separado. La regla 3-2-1 propone tres copias, dos soportes distintos y una fuera de la ubicación principal.
Prueba la copia fuera de producción
Restaura el backup en un entorno aislado y detecta residuos antes de abrir la web. Un staging es una copia de pruebas que no recibe visitas reales ni usa claves de pago, correo o analítica de producción. Piensa en él como un taller cerrado donde se revisa un coche antes de volver a ponerlo en carretera.
Monta un entorno que no contagie
Usa credenciales y servicios de prueba en la copia restaurada. Cambia las claves secretas de WordPress en wp-config.php, sustituye las API de producción y bloquea llamadas a pasarelas, CRM y SMTP. Si importas una base de datos, reemplaza las URL para que la copia no apunte al dominio público.
Comprueba archivos, datos y salidas
Compara el núcleo de WordPress con archivos oficiales y revisa la base de datos. Descarga desde WordPress.org una versión limpia de la misma rama y compara wp-admin y wp-includes. No copies esos directorios desde la copia salvo que haya un motivo documentado.
Decide entre restaurar, limpiar o reconstruir
Elige la vía que limite la pérdida de datos sin conservar código comprometido. Una restauración completa encaja cuando tienes una copia limpia, el servidor está controlado y el alcance del hackeo es conocido. Si hay dudas sobre archivos ejecutables, reconstruirlos desde fuentes oficiales suele ser más seguro que devolverlos desde un backup.
| Ruta | Pérdida de datos | Riesgo residual | Uso adecuado |
|---|---|---|---|
| Restauración completa | Desde el RPO elegido | Bajo si la copia fue validada | Compromiso acotado y backup limpio |
| Solo archivos | Muy baja | Medio si MySQL no se revisa | Base de datos reciente y verificada |
| Solo base de datos | Según fecha de exportación | Medio si hay inyección SQL | Archivos reconstruidos desde fuentes fiables |
| Limpieza o reconstrucción | Mínima si hay exportaciones | Variable, requiere revisión experta | No hay copia limpia o existe un backdoor |
Escala cuando afecta al servidor
Solicita apoyo especializado si el atacante puede controlar la infraestructura. Hay señales claras: permisos alterados, usuarios del sistema desconocidos, procesos extraños, ransomware, claves SSH expuestas o varias aplicaciones afectadas. En esos casos, restaurar una web sobre el mismo servidor puede ser como cerrar una puerta mientras la cerradura sigue rota.
Restaura y blinda el sitio antes de abrirlo
Publica solo después de verificar usuarios, tareas, redirecciones y servicios externos. Prepara un servidor actualizado, con SSL/TLS válido, permisos mínimos y versiones compatibles de PHP y MySQL. Mantén el modo mantenimiento mientras importas datos y haces pruebas funcionales.
Haz la revisión final de integridad
Comprueba los elementos que un escáner no siempre detecta. Revisa usuarios administradores, roles, claves de autenticación, tareas WP-Cron, cron del servidor, redirecciones de .htaccess, DNS, CDN y reglas del WAF. Prueba formularios, carrito, pago en modo seguro, correos transaccionales y enlaces internos.
Vigila y comunica lo ocurrido
Monitoriza durante al menos 7 a 14 días y deja un registro de la recuperación. Revisa cada día logs de acceso, archivos modificados, alertas del WAF, cuentas creadas y peticiones salientes. Configura alertas por cambios de archivos y copias de seguridad automatizadas con prueba periódica de restauración.
Anuncio
Lo que más preguntan
Consulta estas respuestas para resolver bloqueos habituales durante la recuperación. Cada respuesta parte de una condición verificable, porque una restauración segura depende del alcance real del incidente.
¿Cómo recupero un WordPress hackeado?
Aísla el sitio, cambia todas las credenciales y prueba una copia anterior al compromiso en staging. Pásala a producción solo tras revisar archivos, MySQL, usuarios, redirecciones y tareas programadas. Si hay acceso al servidor, la restauración sola no basta.
¿Debo restaurar el último backup?
No, restaura el último backup que sea anterior a la intrusión estimada y haya superado una prueba aislada. La copia más reciente puede contener malware desde hace días o semanas. Compara al menos dos o tres fechas si el historial está disponible.
¿Cómo sé si un backup tiene malware?
Un backup puede considerarse candidato limpio cuando no muestra archivos alterados, usuarios extraños, redirecciones ni tareas ocultas en staging. Comprueba WordPress core frente a archivos oficiales y revisa la base de datos. Un escáner ayuda, pero no sustituye esas comprobaciones.
¿Puedo recuperar pedidos posteriores al backup?
Sí, puedes recuperar pedidos posteriores desde exportaciones revisadas de WooCommerce, pasarelas de pago, correos o ERP. Importa solo los datos necesarios en la base limpia. No restaures toda la base reciente si sospechas inyección o cuentas fraudulentas.
¿Cuánto tarda restaurar una web hackeada?
Una restauración probada puede tardar entre 2 y 8 horas en una web sencilla y entre 1 y 3 días en una tienda compleja. El tiempo aumenta si hay que validar pedidos, limpiar malware o reconstruir el servidor. El RTO acordado debe guiar esta prioridad.
- Aísla el sitio y rota todas las credenciales antes de restaurar.
- Elige una copia anterior a la intrusión, no la última disponible por defecto.
- Prueba archivos, base de datos y salidas externas en staging antes de volver a producción.
- Reconstruye el código desde fuentes oficiales cuando no puedas confiar en los archivos del backup.
- Vigila logs y cambios durante 7 a 14 días tras reabrir la web.
Deja una recuperación repetible
Documenta el punto limpio y convierte esta respuesta en un plan que puedas repetir. Guarda la fecha elegida, el motivo de la elección, los archivos excluidos, las credenciales rotadas y las comprobaciones superadas. Así, la próxima incidencia no dependerá de recordar decisiones tomadas bajo presión.
Programa copias que sirvan de verdad
Combina copias frecuentes con retención suficiente y una ubicación independiente. Para una web corporativa con cambios diarios, una copia completa diaria puede ser adecuada. Para comercio electrónico, añade copias de base de datos cada hora o cada pocas horas según el RPO aceptado.
Ensaya antes de necesitarlo
Restaurar una copia en pruebas cada 3 o 6 meses revela fallos que el panel del hosting no muestra. Mide el tiempo real de descarga, importación, validación y apertura. Es la única forma honesta de saber si tu RTO de 4 horas se puede cumplir.
Lecturas adicionales
Si quieres ampliar información sobre este tema, estas fuentes pueden interesarte:
- Cómo Recuperar WordPress después de ser Hackeado — hostinet.com
- Cómo recuperar WordPress hackeado paso a paso — sgsys.es
- En WordPress, responder no basta sin contingencia previa
- Mantenimiento WordPress tras crear tu web desde cero
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.