Restaurar desde copia de seguridad sin reinfectarte: por qué el backup no basta

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Ante una web comprometida, el reflejo es casi universal: «tengo copia, la restauro y listo». Pero restaurar backup de web hackeada es también la causa número uno de reinfección que vemos en incidentes reales. El motivo es incómodo: la mayoría de los compromisos llevan latentes días o semanas antes de manifestarse, así que el backup «bueno» que vas a restaurar probablemente ya contiene la puerta trasera. El backup, por sí solo, no basta. Este artículo forma parte de la guía de respuesta a incidentes (DFIR): web hackeada, qué hacer.

Antes de entrar en materia, una nota de contexto: cuando la web maneja datos de tarjeta —comercios y entornos de banca que también atendemos— restaurar a ciegas no solo arriesga volver a caer, sino reactivar un skimmer que sigue capturando pagos. Aquí la validación no es opcional.

Por qué restaurar un backup no elimina el compromiso

Un ataque bien hecho separa dos momentos: la intrusión (cuando entran) y la monetización (cuando lo notas: redirecciones, spam SEO, fraude). Entre ambos pueden pasar semanas. Durante ese tiempo, tus copias automáticas van fotografiando un sistema ya comprometido. Cuando restauras «al día antes de que empezara el problema», muchas veces vuelves a un punto que ya tenía el webshell instalado.

Además, restaurar solo resuelve el estado del código y los datos, pero no cierra el vector de entrada. Si entraron por una credencial robada, un plugin vulnerable o un servidor sin parchear, esos tres siguen igual tras la restauración. El atacante vuelve por la misma puerta. El ciclo del NIST SP 800-61 es claro en esto: la recuperación va después de la erradicación y del análisis de causa, no en su lugar.

Restaurar backup de web hackeada: cómo hacerlo sin reinfectarte

Restaurar bien es un proceso de validación, no un botón. Los pasos que marcan la diferencia:

• Preserva primero la evidencia. Antes de sobrescribir nada, congela una imagen del estado comprometido. La necesitarás para saber por dónde entraron y desde cuándo. La adquisición correcta sigue el NIST SP 800-86.
• Data la intrusión. Con los logs, determina la fecha real del primer acceso no autorizado. Solo así sabes qué copia es anterior al compromiso —si es que existe—.
• No confíes en la copia: verifícala. Compara los ficheros del backup contra una instalación limpia de la misma versión del CMS y extensiones. Lo que sobre —ficheros extra, código ofuscado, usuarios administradores desconocidos— es implante, venga de donde venga.
• Separa código y datos. A menudo la restauración más segura combina un code base reinstalado desde fuentes oficiales con los datos de negocio (pedidos, clientes) revisados e importados, en lugar de restaurar el paquete completo comprometido.
• Cierra el vector antes de publicar. Parchea, rota todas las credenciales y aplica el hardening. Restaurar sin esto es programar la siguiente caída.

El escenario en que el backup sí ayuda

El backup es valioso —para recuperar datos de negocio, para acelerar el retorno— pero como pieza dentro de una limpieza, no como sustituto de ella. Si aún estás decidiendo entre limpiar sobre la instalación actual o partir de una base restaurada en un entorno nuevo, contrasta las dos vías en limpiar malware sin tumbar tu web: limpieza en caliente vs. staging. Y si estás en las primeras horas del incidente y necesitas una secuencia inmediata, empieza por web hackeada: qué hacer en las primeras 24 horas.

Señales de que restauraste sobre un compromiso

Si tras «restaurar y quedar tranquilo» aparecen de nuevo redirecciones, ficheros modificados que no tocaste, picos de tráfico a URLs raras o Google vuelve a marcarte, no es mala suerte: restauraste una copia ya infectada o dejaste el vector abierto. En ese punto conviene detener el bucle de restaurar-caer-restaurar y hacer una erradicación completa con validación de integridad. Para el endurecimiento posterior, CISA mantiene guías de referencia útiles.