Etiqueta: backup wordpress

Restaurar backup WordPress: cuándo es seguro y cuándo te reinfectas inevitablemente

Cuando descubres que tu sitio WordPress está comprometido, lo primero que piensas es: «voy a restaurar el backup y listo». Pero aquí está el problema: restaurar un backup infectado es como apagar un fuego con gasolina. En mi experiencia analizando cientos de webs hackeadas, la mayoría de las reinfecciones ocurren precisamente por restaurar backups que ya contenían malware.

Te voy a explicar cuándo es seguro restaurar, cómo identificar si tu backup está comprometido, y qué estrategia debes seguir para no volver a caer en el mismo agujero.

¿Cuándo tu backup ya está infectado sin que lo sepas?

Este es el escenario más común y peligroso. El malware en WordPress puede estar latente semanas o meses antes de que lo detectes. Mientras tanto, cada vez que haces un backup, estás copiando el código malicioso junto con los archivos legítimos.

Los tipos de malware más sigilosos son:

• Backdoors en archivos de configuración: inyectados en wp-config.php, .htaccess o funciones.php del tema. Se ejecutan antes de que WordPress cargue completamente.
• Webshells ocultos: archivos con nombres engañosos (como «config.php» en carpetas anónimas) que permiten acceso remoto al atacante.
• Hooks maliciosos en la base de datos: código insertado en la tabla wp_options o en posts, que se ejecuta dinámicamente sin dejar huella en el sistema de archivos.
• Cryptominers: scripts que consumen CPU silenciosamente. A veces pasan meses sin ser detectados porque el sitio «sigue funcionando».

Si descubriste el malware hace poco, es muy probable que tu backup más antiguo también esté infectado. ¿Cómo saberlo? Aquí viene lo difícil: a menos que hayas scanneado regularmente con herramientas especializadas, probablemente no lo sabes.

Auditoría forense: antes de restaurar nada

Antes de tocar el backup, necesitas responder estas preguntas:

1. ¿Cuándo fue el compromiso real? No la fecha en que lo detectaste, sino cuándo realmente entró el malware. Revisa logs de acceso (si existen), cambios de archivos en el directorio raíz, y queries extrañas en la base de datos.
2. ¿Cuál es el backup más antiguo limpio? Aquí necesitas ser honesto: si no tienes un sistema de backups encriptados y verificados, probablemente todos están comprometidos.
3. ¿Qué plugins y temas estaban instalados cuando fue el ataque? Si usabas un plugin con vulnerabilidad conocida (CVE), ese código malicioso entró por ahí y está en el backup.

En mi experiencia, cuando un cliente restaura sin hacer esta auditoría, se reinfecta en 48 horas. El atacante suele dejar múltiples puertas traseras para asegurar el acceso futuro.

Las tres estrategias de restauración (de menor a mayor riesgo)

Estrategia 1: Migración limpia desde cero (la más segura)

Esta es la que siempre recomiendo para sitios hackeados. No restauras nada; construyes un WordPress nuevo en un servidor limpio y migras solo lo que es seguro:

• WordPress core fresco desde wordpress.org
• Plugins y temas actualizados (no las versiones viejas del backup)
• Solo los posts y usuarios desde la base de datos antigua (mediante exportación XML o queries selectivas)
• Archivos multimedia descargados manualmente después de verificarlos

Ventaja: eliminas todo el código malicioso automáticamente. Inconveniente: requiere más trabajo y conocimiento técnico.

Estrategia 2: Restauración parcial del backup + limpieza manual

Si tienes un backup muy antiguo (anterior a que sospechas del compromiso) y quieres «intentar» usarlo:

1. Restaura solo la base de datos.
2. NO restaures los archivos de WordPress, plugins ni temas.
3. Instala WordPress core actualizado desde cero.
4. Rescadanea con Wordfence (opción CLI de pago) o MalCare después de restaurar.
5. Revisa la tabla wp_options en busca de opciones sospechosas con código PHP o URLs extrañas.

Riesgo: la base de datos puede contener hooks maliciosos que se ejecutan cuando los temas/plugins la consulten. Por eso necesitas verificación posterior con scanners.

Estrategia 3: Restauración completa del backup (la más arriesgada)

Restauras archivo por archivo y base de datos completa desde el backup. Solo hazlo si:

• Tienes pruebas de que el backup es anterior al compromiso (fechas de archivo verificadas).
• Ese período fue reciente (máximo 2 semanas atrás).
• El malware era específico (por ejemplo, solo un redirector, no un backdoor).
• Tienes acceso a logs del servidor para ver exactamente cuándo entró.

Incluso en estas condiciones, yo siempre recomiendo hacer un scan completo después de restaurar, no antes. La probabilidad de reinfección sigue siendo alta.

Señales de que tu backup está comprometido

Si necesitas evaluar si tus backups están infectados, busca estos indicadores:

• Archivos .htaccess modificados recientemente: análisis de timestamps. Si la última modificación es sospechosa, contiene código malicioso.
• Carpetas con permisos extraños: 777 en directorios que deberían ser 755. El malware cambia permisos para ejecutarse.
• Presencia de archivos desconocidos: .php en la raíz con nombres genéricos (test.php, admin.php, config.php, shell.php). Usa find o WP-CLI para listar archivos sospechosos.
• Contenido malicioso en wp-config.php: código añadido antes del cierre ?>, especialmente define() con variables que no reconoces.
• Posts o páginas de borrador con URLs maliciosas: a menudo el atacante crea posts ocultos como prueba de concepto.

Con WP-CLI puedes automatizar esto:

wp db query «SELECT * FROM wp_options WHERE option_value LIKE ‘%eval%’ OR option_value LIKE ‘%base64%’;»

Si obtienes resultados, tu base de datos está comprometida.

Protección de backups: para evitar este problema en el futuro

El verdadero objetivo es que nunca más te encuentres en esta situación. Aquí está cómo:

• Backups incrementales frecuentes: diarios o incluso horarios. Así tienes opciones de cuándo fue el compromiso.
• Almacenamiento encriptado y separado: los backups en el mismo servidor no son backups. Usa servicios como Backblaze, Acronis o backups manuales en un almacenamiento de terceros.
• Verificación de integridad: guarda hashes MD5 de archivos críticos (wp-config.php, wp-settings.php). Si cambian, sabrás exactamente cuándo.
• Monitoreo de cambios de archivos: herramientas como Tripwire o, más simple, Wordfence File Integrity Monitoring te alertan cuando algo cambia sin autorización.
• Scans regulares programados: no esperes a que el cliente diga «mi sitio redirige a casinos». Usa Sucuri, MalCare o Wordfence en modo automático.

Checklist: pasos concretos después de detectar malware

Día 1 (Contención):

1. Cambia todas las contraseñas de WordPress, FTP/SFTP y hosting (WHM/cPanel).
2. Revisa usuarios de WordPress activos. Borra cuentas sospechosas.
3. Desactiva todos los plugins y cambia a un tema por defecto (para eliminar código malicioso temporal).
4. Revisa los 10 últimos accesos al sitio en Google Search Console: ¿hay errores de seguridad reportados?

Día 2 (Análisis):

1. Descarga tus últimos 5 backups (si existen) y análizalos localmente con Wordfence CLI.
2. Revisa logs de acceso del servidor (últimas 4 semanas) en busca de POST requests sospechosos a wp-admin, wp-login.php o /wp-json/.
3. Inspecciona manualmente el wp-config.php actual y el del backup en busca de define() extraños.

Día 3 (Decisión de restauración):

1. Si encontraste un backup anterior al ataque y limpio: procede con estrategia 2 o 1.
2. Si todos los backups parecen comprometidos: opta por migración limpia (estrategia 1).
3. Si quieres arriesgar con un backup completo: hazlo solo en entorno de staging primero.

Día 4+ (Verificación post-restauración):

1. Ejecuta un scan profundo con Sucuri SiteCheck (gratuito) o pago si necesitas análisis manual.
2. Reactiva plugins uno por uno, verificando que el sitio siga limpio.
3. Actualiza WordPress, todos los plugins y temas a sus versiones más recientes.
4. Implementa medidas de hardening: deshabilita edición de temas en wp-config.php, activa 2FA con Wordfence, protege wp-admin con .htaccess.

Las razones reales por las que te reinfectas

Cuando alguien restaura un backup y vuelve a infectarse, casi siempre es por una de estas razones:

• El backup contenía el malware: la razón principal. Nadie scanneó antes de restaurar.
• La vulnerabilidad que permitió el ataque inicial sigue abierta: plugin desactualizado, contraseña débil, falta de 2FA. El atacante entra de nuevo por la misma puerta.
• Backups restaurados sin cambiar permisos de archivos: si el servidor tiene configuración de permisos laxos (carpeta wp-content con 777), el malware se reinstala solo.
• No se eliminó el código de la base de datos: hooks en wp_options, posts drafts con scripts, usuarios fantasma. Vuelven a ejecutarse.

Por eso es crucial que no solo restaures, sino que también cierres la brecha de seguridad original. De lo contrario, es como cambiar las cerraduras de una casa sabiendo que el ladrón tiene acceso a la ventana.

Cuándo contratar ayuda profesional

Si tu sitio es crítico para tu negocio (genera ingresos, contiene datos sensibles), no deberías intentar esto solo. Los errores pueden costar miles de euros en pérdida de tráfico, penalizaciones de Google o robo de datos de clientes.

En ManuelFolgar.com ofrecemos auditorías forenses completas, donde analizamos tus backups, identificamos la fecha exacta del compromiso, removemos el malware y configuramos el hardening necesario. Es mucho más rápido y seguro que intentarlo con chatbots de IA que no entienden tu caso específico.

Resumen: lo que necesitas hacer ahora

No todos los backups son iguales. Antes de restaurar, verifica que está limpio. Si no puedes garantizarlo, haz una migración limpia. Y una vez restaurado, implementa monitoreo continuo para que esto no vuelva a suceder.

La restauración segura requiere auditoría, no prisa. Tómate el tiempo necesario o busca ayuda. Tu negocio lo merece.

¿Tienes un sitio comprometido y no sabes si tus backups están limpios? Ponte en contacto conmigo en ManuelFolgar.com/contacto para una auditoría sin compromiso.