Imagina que tu empresa detecta un ataque de ransomware un lunes por la mañana. Los empleados no pueden acceder a los archivos, el sistema de facturación está fuera de servicio y varias aplicaciones muestran mensajes que exigen un pago para recuperar la información. El equipo de TI activa el protocolo de emergencia y busca las copias de seguridad para restaurar los sistemas. En ese momento descubre que los respaldos también están cifrados o que las credenciales utilizadas para administrarlos fueron comprometidas durante el ataque.
Lo que parecía un incidente grave se convierte en una crisis operativa. Sin una copia de seguridad confiable, la empresa puede perder días o semanas intentando recuperar información, reconstruir sistemas y restablecer sus servicios. Mientras tanto, los pedidos se retrasan, los clientes esperan respuestas y cada hora de inactividad empieza a tener consecuencias económicas.
Este escenario explica por qué las copias de seguridad siguen siendo una de las principales herramientas para recuperarse de un ataque de ransomware, pero no garantizan por sí solas la continuidad del negocio. Si los atacantes consiguen acceder a ellas, eliminarlas o alterar la información almacenada, la empresa puede quedarse sin una vía de recuperación viable.
Puede que tu organización cuente con backups, pero también necesitas saber si esas copias están protegidas frente a los mismos atacantes que podrían comprometer los sistemas de producción y si realmente permiten recuperar la operación cuando más lo necesitas.
¿Por qué los atacantes también buscan comprometer las copias de seguridad?
El ransomware es un tipo de malware que cifra archivos o sistemas para impedir que sus propietarios puedan utilizarlos con normalidad. En muchos ataques empresariales, los delincuentes también roban información y amenazan con publicarla si la víctima no paga. Esta práctica, conocida como doble extorsión, añade presión a una situación en la que la organización ya está intentando recuperar sus operaciones.
Cuando una empresa dispone de backups recientes y funcionales, puede tener una alternativa para restaurar sus sistemas sin depender exclusivamente de los atacantes. Por eso, muchos grupos de ransomware intentan identificar los mecanismos de respaldo durante las primeras etapas de una intrusión y comprometerlos antes de activar el cifrado a gran escala.
Para lograrlo, pueden aprovechar credenciales administrativas robadas, permisos excesivos, vulnerabilidades en las plataformas de respaldo o conexiones entre la red corporativa y los repositorios donde se almacenan las copias. Si una misma cuenta permite administrar los servidores de producción y eliminar los backups, un atacante que consiga controlarla podría afectar ambos entornos.
En algunos casos, los delincuentes también permanecen dentro de la red durante un tiempo antes de ejecutar el ataque. Ese período les permite reconocer la infraestructura, localizar información valiosa e identificar las herramientas que la empresa utiliza para recuperarse de una interrupción.
Por eso, encontrar un mensaje de rescate en los servidores no siempre representa el comienzo del incidente. Para cuando el ransomware se ejecuta, el atacante podría haber comprometido previamente las cuentas administrativas, desactivado controles de seguridad o preparado la eliminación de los respaldos.
¿Cómo pueden los atacantes destruir o inutilizar tus backups?
1. Robar las credenciales de administración
Las plataformas de respaldo suelen contar con permisos suficientes para leer grandes cantidades de información y restaurar archivos o sistemas completos. En algunos entornos, las cuentas administrativas también pueden modificar las políticas de retención, eliminar repositorios o desactivar tareas de protección.
Si los atacantes obtienen esas credenciales, pueden utilizar las propias herramientas de la empresa para sabotear su recuperación. No necesitan desarrollar un mecanismo sofisticado para destruir las copias si ya tienen acceso autorizado a las funciones que permiten administrarlas.
Este riesgo aumenta cuando se reutilizan contraseñas, las cuentas privilegiadas no tienen autenticación multifactor o los permisos se mantienen abiertos incluso cuando ya no son necesarios. Una cuenta comprometida puede convertirse en una puerta de entrada tanto a los sistemas productivos como a la infraestructura de respaldo.
La medida más importante consiste en separar las identidades y los permisos utilizados para administrar los backups de aquellos que controlan los servidores y las aplicaciones empresariales. También conviene proteger las cuentas privilegiadas con autenticación multi factor, registrar sus actividades y revisar periódicamente quién puede modificar o eliminar las copias.
2. Eliminar los respaldos antes de cifrar los sistemas
En determinados ataques, los delincuentes intentan borrar las copias disponibles o reducir su capacidad de recuperación antes de desplegar el ransomware. De esta forma, dificultan que la empresa pueda volver rápidamente a un estado anterior al incidente.
El impacto puede ser especialmente grave cuando las copias se almacenan en recursos de red accesibles desde los mismos equipos que contienen los datos originales. Si un servidor de archivos puede modificar o eliminar el contenido del repositorio de respaldo, una intrusión con suficientes privilegios puede afectar ambos recursos.
También existe el riesgo de que los atacantes alteren las políticas de retención o eliminen los puntos de recuperación más recientes. En ese caso, puede quedar alguna copia disponible, pero su antigüedad quizá impida recuperar las transacciones y los cambios realizados durante los últimos días.
Para reducir esta exposición, las copias deben almacenarse en repositorios con controles de acceso independientes y permisos de eliminación restringidos. Además, la organización necesita conservar versiones anteriores durante un período adecuado para sus operaciones y requisitos de recuperación.
3. Comprometer los respaldos conectados a la nube
Almacenar copias de seguridad en la nube puede mejorar la resiliencia frente a fallos físicos, incendios o daños en las instalaciones. Sin embargo, trasladar los backups a un servicio cloud no los vuelve automáticamente inmunes al ransomware.
Si la empresa administra los respaldos en la nube con credenciales comprometidas, permisos excesivos o configuraciones deficientes, los atacantes podrían intentar borrar objetos, modificar políticas o afectar las cuentas utilizadas para gestionar el servicio.
Por ejemplo, una organización puede conservar sus backups en un almacenamiento de objetos y utilizar una misma identidad administrativa para gestionar tanto los recursos productivos como los repositorios. Si esa identidad queda comprometida y dispone de permisos suficientes, la separación física entre los servidores y la nube no será suficiente para impedir el sabotaje.
La protección depende de la arquitectura y de los controles configurados. Las políticas de retención inmutables, el versionado, la separación de cuentas, la autenticación multifactor y los permisos mínimos pueden dificultar que un atacante modifique o elimine las copias. También es importante verificar que estos controles estén habilitados correctamente y que las credenciales de recuperación se mantengan protegidas.
4. Cifrar los respaldos sin eliminarlos
Una copia de seguridad puede seguir apareciendo en el inventario y, aun así, resultar inútil. Esto sucede cuando los atacantes cifran los archivos respaldados, alteran su contenido o comprometen los mecanismos necesarios para restaurarlos.
También puede ocurrir que el repositorio permanezca intacto, pero que las claves de cifrado, las credenciales o los componentes de software necesarios para acceder a la información ya no estén disponibles. En ese escenario, la empresa conserva los datos, pero no cuenta con todos los elementos necesarios para recuperarlos.
Por eso, comprobar que una tarea de respaldo terminó correctamente no es suficiente. La organización debe validar que las copias puedan leerse, que los datos estén completos y que las aplicaciones puedan restaurarse en un entorno operativo.
Las pruebas periódicas de restauración permiten descubrir estos problemas antes de que ocurra una emergencia. Si la empresa nunca ha intentado recuperar un sistema completo desde sus backups, todavía no tiene evidencia suficiente para afirmar que podrá hacerlo bajo presión.
El caso más peligroso: cuando la empresa descubre que no puede recuperarse
Supongamos que una compañía depende de un sistema ERP para gestionar sus inventarios, facturación y compras. Cada noche realiza una copia de seguridad automática y almacena el resultado en un servidor conectado a la red corporativa. Los informes indican que las tareas se completan correctamente, por lo que la dirección considera que la información está protegida.
Un atacante consigue acceso a una cuenta administrativa y comienza a explorar la infraestructura. Durante el incidente, identifica el servidor de respaldo, compromete los permisos de administración y elimina las copias disponibles. Después ejecuta el ransomware sobre los sistemas de producción.
Cuando el equipo de TI inicia la recuperación, descubre que los servidores están cifrados y que el repositorio no conserva copias utilizables. La empresa necesita reconstruir parte de la infraestructura, buscar respaldos antiguos en otros medios y comprobar qué información puede recuperar.
Aunque este ejemplo es hipotético, representa una debilidad arquitectónica concreta: la empresa tenía un proceso de respaldo, pero no una separación suficiente entre los sistemas que necesitaba proteger y los recursos utilizados para recuperarlos.
El impacto no se limita a perder archivos. Si la información contable, los pedidos recientes o los movimientos de inventario no pueden recuperarse, la empresa tendrá que reconstruirlos mediante registros alternativos, documentos de clientes y conciliaciones manuales. La recuperación puede prolongarse mucho más de lo esperado y generar costos adicionales incluso después de restablecer los sistemas. Porque un backup solo aporta resiliencia cuando permanece disponible, íntegro y accesible mediante un proceso de recuperación que el equipo ha probado previamente.
Cómo proteger las copias de seguridad frente a un ataque de ransomware
Aplicar la regla 3-2-1-1-0
Una de las referencias más utilizadas para diseñar estrategias de respaldo es la regla 3-2-1. Propone conservar tres copias de los datos, utilizar dos tipos de medios o sistemas de almacenamiento y mantener al menos una copia fuera de la ubicación principal.
Para entornos empresariales expuestos a ransomware, puede ampliarse con el enfoque 3-2-1-1-0: una copia adicional debe permanecer aislada o ser inmutable, y la organización debe procurar cero errores de recuperación mediante verificaciones y pruebas periódicas.
Cada elemento responde a un riesgo diferente:
- Tres copias de los datos: ayudan a reducir la dependencia de un único respaldo.
- Dos medios o sistemas de almacenamiento: limitan el impacto de fallos que afectan a una misma tecnología.
- Una copia fuera de las instalaciones: protege frente a incidentes físicos que afectan al sitio principal.
- Una copia aislada o inmutable: dificulta que los atacantes modifiquen o eliminen los respaldos.
- Cero errores sin resolver en las verificaciones: permite detectar problemas de integridad antes de necesitar una recuperación real.
La regla no sustituye el análisis de riesgos ni garantiza una protección absoluta. Su valor está en ayudar a diseñar una arquitectura en la que un único incidente no pueda destruir todas las alternativas de recuperación.
Implementar copias inmutables
La inmutabilidad impide modificar o eliminar determinados datos durante un período establecido, incluso cuando una cuenta dispone de privilegios administrativos habituales. Según la tecnología utilizada, esta protección puede aplicarse mediante almacenamiento con bloqueo de objetos, repositorios diseñados para backups inmutables o mecanismos equivalentes.
Para una empresa, la ventaja es concreta: si un atacante compromete una cuenta administrativa, la copia protegida puede seguir disponible mientras se mantengan correctamente las condiciones de inmutabilidad.
Eso sí, hay que configurar las políticas de retención con cuidado. Si los períodos son demasiado cortos, la copia podría dejar de estar protegida antes de que se detecte una intrusión. Si son excesivamente largos, el almacenamiento puede generar costos adicionales y dificultades de gestión.
También conviene separar los permisos que permiten crear copias de aquellos que permiten cambiar las políticas de protección. La inmutabilidad funciona mejor cuando forma parte de una estrategia de seguridad más amplia, con identidades independientes, monitoreo y procedimientos de recuperación documentados.
Separar la infraestructura de respaldo de la red corporativa
Los servidores de producción y los sistemas de respaldo no deberían depender de las mismas credenciales administrativas ni compartir permisos innecesarios. Cuanto mayor sea la separación entre ambos entornos, más difícil será que una intrusión en la red principal se extienda a las copias de seguridad.
Esta separación puede incluir cuentas administrativas independientes, segmentos de red específicos, accesos restringidos desde estaciones privilegiadas y controles adicionales para las operaciones de eliminación. En determinados escenarios, también conviene utilizar copias desconectadas que solo se habiliten durante las ventanas de respaldo o recuperación.
La arquitectura debe responder al tamaño y la complejidad de la empresa. No todas las organizaciones necesitan construir un entorno completamente aislado, pero sí deben evitar que una única cuenta comprometida otorgue control irrestricto sobre los datos originales y sus copias.
Probar la restauración de sistemas completos
Las pruebas de recuperación deben ir más allá de abrir un archivo respaldado. Una empresa necesita comprobar que puede restaurar los servidores, las bases de datos, las aplicaciones y las dependencias que permiten mantener la operación.
Por ejemplo, recuperar una base de datos no garantiza que el ERP vuelva a funcionar si también necesita un servidor de aplicaciones, configuraciones específicas, certificados o servicios de autenticación. La restauración debe contemplar esas dependencias y verificar que los datos recuperados sean coherentes.
Conviene realizar pruebas periódicas en un entorno controlado, registrar los resultados y corregir las dificultades encontradas. Estas pruebas permiten medir cuánto tarda realmente la recuperación y comparar ese resultado con las necesidades del negocio.
Dos indicadores ayudan a establecer los objetivos: el RPO (Recovery Point Objective), que define cuánta información puede permitirse perder la empresa medida en tiempo, y el RTO (Recovery Time Objective), que establece cuánto tiempo puede tardar en recuperar un servicio.
Si el sistema de facturación tiene un RPO de cuatro horas, por ejemplo, la organización debe disponer de una estrategia que permita recuperar la información con una antigüedad máxima aproximada de cuatro horas. Si el RTO establecido es de seis horas, también necesita demostrar que puede restablecer el servicio dentro de ese plazo. Ambos objetivos deben ser realistas y validarse mediante pruebas.
¿Qué debe hacer una empresa si sospecha que sus backups están comprometidos?
Cuando se detecta un ataque de ransomware, la prioridad es contener el incidente y evitar que siga propagándose. El equipo responsable debe activar el plan de respuesta, aislar los sistemas afectados según las indicaciones del equipo de seguridad y preservar la evidencia necesaria para investigar lo ocurrido.
También es importante proteger el entorno de respaldo. Antes de iniciar una restauración, la empresa debe comprobar si las cuentas administrativas, los repositorios o las herramientas de gestión fueron comprometidos. Recuperar los sistemas sin haber contenido la intrusión podría permitir que los atacantes vuelvan a cifrar los datos restaurados.
La organización debe identificar qué copias siguen siendo confiables, cuándo se realizó la última restauración válida y qué sistemas deben recuperarse primero para restablecer los procesos críticos. La decisión debe coordinarse con los responsables de tecnología, seguridad y negocio, especialmente cuando existen obligaciones regulatorias o información sensible involucrada.
Si los respaldos están comprometidos, conviene acudir a especialistas en respuesta a incidentes y recuperación de ransomware. El equipo debe evaluar las alternativas disponibles antes de tomar decisiones irreversibles, conservar los registros pertinentes y evitar asumir que pagar un rescate garantiza recuperar los datos. Los atacantes pueden no entregar herramientas funcionales, y el pago tampoco resuelve necesariamente el riesgo de exposición de la información robada.
Conclusión: tener backups no basta si los atacantes también pueden destruirlos
Las copias de seguridad son una parte esencial de la continuidad operativa, pero su eficacia depende de cómo se almacenan, quién puede administrarlas y qué tan bien funciona el proceso de recuperación. Cuando los respaldos comparten credenciales, permisos o vulnerabilidades con los sistemas de producción, un ataque de ransomware puede afectar tanto la operación como su principal mecanismo de recuperación.
Las empresas necesitan proteger sus copias con controles de acceso independientes, almacenamiento inmutable o aislado, políticas de retención adecuadas y pruebas periódicas de restauración. También deben definir objetivos de recuperación que respondan a las necesidades reales de cada proceso y comprobar que pueden cumplirlos.
Una estrategia de respaldo bien diseñada no elimina todos los riesgos, pero puede marcar la diferencia entre una interrupción controlada y una crisis que paralice la organización durante días o semanas.
Si mañana un atacante cifra nuestros servidores y elimina las copias de seguridad accesibles, ¿tenemos otra forma confiable de recuperar la operación? Si la respuesta no está respaldada por pruebas, todavía hay trabajo por hacer.