Plan de recuperación tras un hackeo: de la contención a estar 100% operativo

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

Después de un compromiso, la pregunta no es «¿cómo vuelvo a poner la web?» sino «¿cómo vuelvo a operar con la certeza de que el atacante ya no está dentro?». Un plan de recuperación tras un hackeo es precisamente eso: una secuencia de fases con criterios de salida claros, desde el corte inicial hasta estar 100% operativo, sin saltarse pasos que luego se pagan con una reinfección. Este spoke desarrolla la fase de recuperación dentro de nuestra guía de respuesta a incidentes (DFIR): web hackeada, qué hacer.

El modelo que seguimos es el ciclo de vida del NIST SP 800-61: preparación, detección y análisis, contención, erradicación y recuperación, y lecciones aprendidas. No es burocracia; es lo que evita que apagues el fuego dejando la brasa encendida. En entornos exigentes —banca y comercios con datos de tarjeta, que también atendemos— cada fase lleva además controles de evidencia y notificación.

Fase 1 — Contención: parar el daño sin destruir pruebas

Contener no es apagar el servidor. Es cortar la capacidad del atacante de seguir actuando y de exfiltrar datos, preservando a la vez la evidencia. En la práctica: aísla la aplicación (página de mantenimiento, corte en el WAF o el balanceador), bloquea las IP y credenciales implicadas, y congela una imagen forense antes de modificar nada. La adquisición correcta de esa evidencia sigue el NIST SP 800-86.

Criterio de salida: el atacante ya no puede operar, tienes copia íntegra de ficheros, base de datos y logs, y has documentado hora y alcance.

Fase 2 — Erradicación: eliminar el implante completo

Aquí se elimina la causa: webshells, puertas traseras, usuarios administradores fraudulentos, tareas cron persistentes y cualquier modificación del código. La clave es no fiarse del «lo más visible»: los atacantes dejan redundancia para volver. Reconstruye el core y las extensiones desde fuentes oficiales, no desde la instalación comprometida.

Si te preguntas si conviene limpiar sobre producción o migrar a un entorno nuevo, el detalle está en limpiar malware sin tumbar tu web: limpieza en caliente vs. staging. La decisión depende del tamaño del daño, de si sigues vendiendo y del riesgo de dejar residuos.

Criterio de salida: no queda código no autorizado, todas las credenciales están rotadas y has identificado el vector de entrada. Si no sabes por dónde entraron, no has terminado de erradicar.

Fase 3 — Recuperación y restauración validada

Recuperar es devolver el servicio desde una base limpia y verificada. El error más común es restaurar un backup anterior al incidente asumiendo que estaba sano, cuando muchos compromisos llevan semanas latentes y el respaldo ya contiene la puerta trasera. Por eso la restauración se valida, no se da por buena: revisa integridad de ficheros, compara contra una instalación de referencia y comprueba que no arrastras el implante. Lo explicamos a fondo en restaurar desde copia de seguridad sin reinfectarte: por qué el backup no basta.

Criterio de salida: la web funciona desde una base validada, con monitorización de integridad activa y sin indicadores de compromiso.

Fase 4 — Estar 100% operativo (y quedarse ahí)

Volver a operar al 100% incluye lo que casi nadie hace tras el susto:

• Aplicar el hardening que cerró el vector: parches, 2FA, permisos, WAF y retirada de componentes que no usas.
• Restaurar la reputación: solicitar la revisión en Google Safe Browsing si te marcaron, limpiar spam SEO indexado y revisar listas negras de correo.
• Vigilar durante las semanas siguientes: los reintentos son la norma, no la excepción.
• Cerrar con lecciones aprendidas: qué falló, qué detectó tarde y qué controles añades. Es la fase que convierte un incidente en madurez.

Para el endurecimiento continuo y las buenas prácticas de referencia, apóyate en CISA. Un incidente bien cerrado no es el que se limpia rápido, sino el que no vuelve.

El error de saltarse fases

Casi todas las reinfecciones que vemos nacen de comprimir el plan: se contiene y se restaura, pero se salta la erradicación completa y el análisis del vector. El resultado es una web «limpia» que vuelve a caer a los pocos días con el mismo implante. Un plan de recuperación tras un hackeo ordenado es más lento en apariencia y mucho más rápido en realidad, porque se hace una sola vez.