Una empresa no descubre el valor de sus respaldos cuando los configura, sino cuando deja de poder facturar, responder correos o procesar pedidos. Este ejemplo de recuperación ransomware muestra qué ocurre durante las primeras horas de un incidente y qué decisiones separan una recuperación controlada de varios días de interrupción.

El escenario es común: una pyme chilena opera una tienda online, usa correo corporativo para coordinar ventas y mantiene documentos críticos en servicios compartidos. Un usuario abre un archivo adjunto aparentemente legítimo. Horas después, varios equipos muestran notas de rescate, las carpetas compartidas quedan cifradas y la web comienza a presentar errores porque un administrador reutilizaba la misma contraseña en más de un servicio.

El problema no se resuelve pagando. Tampoco se resuelve restaurando archivos de inmediato. La prioridad es contener el ataque, preservar evidencia y restaurar solo cuando existe certeza razonable de que el entorno está limpio.

Ejemplo de recuperación ransomware: las primeras 24 horas

A las 08:15, el equipo comercial informa que no puede abrir cotizaciones ni fichas de clientes. A las 08:23, soporte interno detecta extensiones desconocidas en el servidor de archivos y una nota que exige un pago en criptomonedas. A las 08:30, la empresa toma su primera decisión correcta: desconecta de la red los equipos afectados.

Aislar no significa apagar todo sin criterio. Los equipos comprometidos deben desconectarse de la red cableada, Wi-Fi, VPN y unidades compartidas para frenar el cifrado lateral. Sin embargo, conviene mantenerlos encendidos si el equipo de respuesta necesita revisar procesos, conexiones y registros de memoria. Si no existe capacidad interna para analizar el incidente, se documenta el estado visible, se registra la hora y se escala a especialistas.

En paralelo, se bloquean temporalmente las cuentas potencialmente comprometidas, especialmente las de administradores, correo, paneles de hosting, VPN y almacenamiento en la nube. Las contraseñas se cambian desde un equipo seguro, nunca desde una estación posiblemente infectada. También se revocan sesiones activas y se habilita autenticación multifactor donde no estuviera implementada.

La empresa del ejemplo comete una omisión frecuente: su respaldo local estaba conectado permanentemente al servidor. El ransomware lo cifra junto con los datos de producción. Afortunadamente, mantenía una segunda copia fuera del entorno principal, con retención de versiones y acceso separado. Esa copia se transforma en el punto de partida de la recuperación.

Contener antes de restaurar

La presión por volver a operar puede llevar a errores costosos. Restaurar una máquina virtual o copiar archivos sobre un servidor infectado no elimina la causa del ataque. Si el acceso inicial sigue abierto, el atacante puede cifrar nuevamente la información restaurada o robarla antes de que la empresa se dé cuenta.

Por eso, el equipo debe responder cuatro preguntas antes de iniciar la restauración: ¿qué sistemas fueron afectados?, ¿cuándo comenzó la actividad anómala?, ¿cómo ingresó el atacante?, ¿hay señales de exfiltración de datos? No siempre habrá respuestas completas el primer día, pero sí debe existir una hipótesis basada en registros de correo, accesos remotos, cuentas administrativas, antivirus, firewall y paneles de control.

En este caso, la investigación encuentra un inicio de sesión inusual en el correo de un usuario y reglas automáticas que ocultaban mensajes de seguridad. Desde esa cuenta se enviaron correos internos con un enlace malicioso. La contraseña expuesta también daba acceso a una VPN antigua que no exigía segundo factor.

El alcance cambia por completo el plan. No basta con recuperar documentos: hay que eliminar la cuenta o sesión atacante, cerrar la VPN vulnerable, revisar privilegios y confirmar que no existan nuevas reglas de reenvío, usuarios administradores desconocidos o tareas programadas sospechosas.

Restaurar por prioridad de negocio

Una recuperación ordenada no parte por el servidor más grande, sino por los servicios que permiten a la empresa volver a trabajar con riesgo controlado. En el ejemplo, el orden fue correo corporativo, sitio web, base de datos de pedidos, archivos comerciales y, por último, estaciones de trabajo.

El correo se recupera primero porque es el canal para coordinar clientes, proveedores y personal. Antes de habilitarlo, se revisan reglas, reenvíos externos, buzones delegados y registros de acceso. Luego se obliga a restablecer credenciales y se activa multifactor para todos los usuarios, no solo para administradores.

El sitio web y la tienda online se restauran en un entorno separado. Esto permite validar archivos, complementos, usuarios de administración y configuraciones antes de devolverlos a producción. Si una web depende de WordPress, por ejemplo, no conviene limitarse a restaurar una copia: también se actualizan el núcleo, los plugins, los temas y las claves de acceso. Un respaldo devuelve disponibilidad; la revisión posterior reduce la posibilidad de restaurar una vulnerabilidad conocida.

La base de datos de pedidos se recupera desde un punto anterior al incidente. Aquí aparece un trade-off real: una copia más antigua puede ser más confiable, pero deja fuera transacciones recientes. La empresa decide restaurar el respaldo de las 02:00 y reconstruir manualmente los pedidos ingresados entre esa hora y el momento de la interrupción, usando comprobantes de pago, correos y registros del procesador de pagos. Es trabajo adicional, pero evita reintroducir datos alterados.

Los documentos compartidos se restauran después de revisar que el servidor o plataforma de destino esté limpio. Se habilitan por áreas y con permisos mínimos. Finanzas recibe primero los archivos contables; ventas, las cotizaciones activas; el resto se incorpora progresivamente. Esta medida disminuye el impacto si se detecta un archivo malicioso oculto entre datos recuperados.

Validar que el servicio funciona de verdad

Un sistema restaurado no equivale automáticamente a un sistema recuperado. Antes de anunciar normalidad, la empresa verifica que los servicios respondan, que los usuarios puedan acceder con nuevas credenciales, que los respaldos vuelvan a ejecutarse y que no existan alertas de seguridad pendientes.

La validación debe considerar la operación completa. En la tienda online, se prueba una compra de punta a punta: navegación, carrito, pago, correo de confirmación, descuento de inventario y registro en la base de datos. En correo, se prueban envío, recepción, calendarios y acceso móvil. En archivos, se confirma que los permisos correspondan a cada área y que las versiones restauradas sean las esperadas.

También se monitorean los registros durante varios días. Un aumento de inicios de sesión fallidos, transferencias inusuales, procesos desconocidos o cambios de privilegios merece investigación. La recuperación es gradual porque la certeza absoluta rara vez existe, pero ignorar señales tempranas convierte un incidente contenido en una reincidencia.

Lo que este caso deja al descubierto

El ransomware no es solo un problema de antivirus. Aprovecha credenciales reutilizadas, software sin actualizar, accesos remotos mal configurados y respaldos sin aislamiento. Una empresa puede tener copias de seguridad y aun así no estar preparada si jamás ha probado cuánto tarda en restaurarlas ni qué información queda fuera de la ventana de respaldo.

Una estrategia seria combina copias versionadas, una copia aislada o inmutable, monitoreo, segmentación de accesos y procedimientos claros. La regla 3-2-1 sigue siendo útil: al menos tres copias de los datos, en dos tipos de almacenamiento y una fuera del entorno principal. Para operaciones críticas, conviene añadir pruebas periódicas de restauración y objetivos definidos de tiempo de recuperación.

La infraestructura también influye. El hosting, el correo y los respaldos no deben administrarse como piezas aisladas. Cuando una empresa conoce quién tiene acceso, dónde se guardan las copias, cómo se escalan incidentes y qué soporte técnico responde, reduce decisiones improvisadas bajo presión. En servicios administrados como los de Smart.cl, la coordinación entre alojamiento, respaldos y soporte especializado puede acortar tiempos de diagnóstico, aunque la responsabilidad sobre usuarios, contraseñas y aplicaciones sigue siendo compartida.

La lección práctica no es esperar un ataque para comprar más capacidad o acumular respaldos. Es definir ahora qué servicio se recupera primero, quién puede autorizar cambios, dónde está la copia aislada y cómo se validará la operación. Cuando el ransomware aparezca, ese plan vale más que cualquier mensaje de rescate.