Por qué el ransomware convierte las copias de seguridad en el objetivo y no en la red de seguridad
Durante años, el backup fue la excepción que permitía sobrevivir al ransomware: se cifraba producción, se restauraba desde la copia de seguridad y se pasaba página. Los atacantes se han puesto al día. El 2025 Ransomware Trends report de Veeam encuestó a 1.300 organizaciones, 900 de las cuales habían sufrido al menos un ataque de ransomware en los 12 meses anteriores. Veeam informa de que el 89 % de las organizaciones vio cómo el atacante tenía como objetivo sus repositorios de backup, y de que, de media, el 34 % de los repositorios de backup fue modificado o eliminado. Destruir o corromper el recurso de reserva le quita a la víctima su margen de maniobra antes incluso de que llegue la nota de rescate.
El resultado se refleja en las cifras de recuperación. El State of Ransomware 2025 de Sophos encuestó a 3.400 responsables de TI y seguridad cuyas organizaciones habían sufrido un ataque de ransomware el año anterior. Entre las organizaciones cuyos datos fueron cifrados, solo el 54 % los restauró a partir de copias de seguridad, la tasa más baja en los seis años que Sophos lleva realizando la encuesta. De las 151 organizaciones que acabaron pagando más que la demanda inicial del atacante, el 38 % dijo que sus copias de seguridad habían fallado o no funcionaban correctamente (los encuestados solían citar dos motivos). Una copia de seguridad que existe sobre el papel no es lo mismo que una copia de seguridad que se restaura sin problemas bajo presión.
Esa distancia, entre "tenemos copias de seguridad" y "tenemos copias de seguridad resilientes frente al ransomware", se reduce a tres pilares: inmutabilidad, aislamiento y recuperación probada. No son controles independientes que se puedan combinar a voluntad. Si falta cualquiera de ellos, los otros dos no lo compensan. Una copia inmutable que un atacante no puede alcanzar solo es útil si realmente se restaura, y un plan de restauración bien probado no vale nada si la copia de la que depende se eliminó antes de que empezara el simulacro.
Los tres pilares en detalle
1. Inmutabilidad: copias que un atacante no puede tocar
La inmutabilidad significa que una copia de seguridad no se puede alterar ni eliminar dentro de su periodo de retención: ni por un script de retención mal configurado, ni por una cuenta de administrador comprometida, ni por un atacante que ya tiene credenciales de administrador de dominio. En la práctica se aplica mediante Object Lock en almacenamiento de objetos, hardware Write Once Read Many (WORM) o un repositorio Linux reforzado (hardened repository) con la retención aplicada en la capa de almacenamiento, con independencia de los propios controles de acceso de la aplicación de backup.
La distinción importa porque los operadores de ransomware buscan copias de seguridad a las que puedan llegar con credenciales robadas. La #StopRansomware Guide de CISA lo dice directamente: "Ransomware actors often hunt for and collect credentials stored in the targeted environment and use those credentials to attempt to access backup solutions" (los actores de ransomware a menudo buscan y recopilan las credenciales almacenadas en el entorno atacado y las utilizan para intentar acceder a las soluciones de backup). Si la misma cuenta administrativa que gestiona su software de backup también puede eliminar los puntos de restauración del mes pasado, la inmutabilidad no está realmente implantada. Es una opción que un atacante con suficientes privilegios puede desactivar en minutos.
El propio consejo de CISA sobre backup es "maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario" (mantener copias de seguridad cifradas y desconectadas de los datos críticos, y probar periódicamente su disponibilidad e integridad en un escenario de recuperación ante desastres). La misma guía es prudente con el almacenamiento inmutable en la nube por sí solo: "Use immutable storage with caution as it does not meet compliance criteria for certain regulations and misconfiguration can impose significant cost" (use el almacenamiento inmutable con precaución, ya que no cumple los criterios de cumplimiento de determinadas normativas y una configuración incorrecta puede suponer un costo considerable). La inmutabilidad es un control sólido. No sustituye a una copia desconectada ni a una restauración probada.
2. Aislamiento: un plano de identidad separado y una copia que los atacantes no pueden alcanzar en absoluto
La inmutabilidad protege una copia de seguridad frente a los cambios. El aislamiento impide que se llegue a ella en primer lugar. Ambos son complementarios, no intercambiables, y las empresas que solo implementan uno suelen descubrir la carencia durante un incidente real y no durante una revisión de diseño.
El aislamiento tiene dos componentes. El primero es un plano de identidad separado: la infraestructura de backup no debe confiar en el mismo dominio de Active Directory, las mismas credenciales administrativas ni el mismo segmento de red plano que producción. Un controlador de dominio comprometido no debería implicar automáticamente un entorno de backup comprometido; si lo implica, el atacante solo tuvo que comprometer una cosa, no dos. El segundo es una copia realmente desconectada o con air gap: al menos una copia de los datos críticos que no tenga ninguna ruta de red permanente desde producción. Puede ser una rotación de cintas desconectadas, un destino de replicación desconectado que solo se conecta brevemente para recibir datos o un nivel en la nube sin credenciales persistentes almacenadas en ningún lugar accesible desde el entorno de producción.
El informe de 2025 de Veeam afirma que las organizaciones que priorizan la resiliencia de los datos "can recover from attacks up to seven times faster and experience significantly lower data loss rates" (pueden recuperarse de los ataques hasta siete veces más rápido y sufren tasas de pérdida de datos considerablemente menores). Veeam atribuye ese resultado a la resiliencia de los datos en su conjunto (backup y recuperación, seguridad proactiva, respuesta a incidentes), no solo al aislamiento. Aun así, el aislamiento es una parte importante del cuadro: es la diferencia entre un atacante que tiene que hacer un trabajo adicional real para llegar a su punto de recuperación y otro que ya tiene una sesión abierta en él porque comparte un plano de identidad con los sistemas que acaba de comprometer.
3. Recuperación probada: demostrar que se puede restaurar antes de necesitarlo
El menos vistoso de los tres pilares es también el más fácil de dejar a medias. En el informe de 2025 de Veeam, el 98 % de los encuestados tenía un playbook de ransomware, pero solo el 44 % había incluido en él las verificaciones de las copias de seguridad y su frecuencia. El 2024 Ransomware Trends report de Veeam, basado en 1.200 organizaciones afectadas por al menos un ataque en 2023, concluyó que el 63 % de las organizaciones corría el riesgo de reintroducir infecciones durante la recuperación, porque los equipos presionados para restaurar rápidamente se saltan pasos como volver a analizar los datos en cuarentena.
Las restauraciones no probadas fallan de maneras que permanecen invisibles hasta el momento en que más importan: cadenas de backup rotas, dependencias de coherencia de aplicaciones que faltan, credenciales de cuentas de servicio que caducaron hace meses o runbooks escritos para una topología de infraestructura que ya no existe. Saltarse el análisis de integridad y de malware conlleva un riesgo más grave que el tiempo de inactividad: restaurar el mismo payload que causó la caída.
Un programa real de recuperación probada implica simulacros programados de restauración completa en un entorno de recuperación aislado, no solo notificaciones de "trabajo de backup completado correctamente". Mida esos simulacros frente a los RTO que el negocio necesita de verdad, no frente a cifras que simplemente resultan tranquilizadoras en una presentación.
Lo que dicen realmente las cifras de recuperación
Los datos de 2025 de Sophos tienen un titular que parece tranquilizador: el 97 % de las organizaciones cuyos datos fueron cifrados pudo recuperarlos. El desglose es menos reconfortante. Algo más de la mitad (54 %) restauró desde copias de seguridad, el 49 % pagó el rescate y recuperó los datos y el 29 % utilizó otros medios; muchas usaron más de una vía. Recuperar los datos y recuperarlos a partir de sus propias copias de seguridad son resultados diferentes. La distancia entre ambos es donde se manifiestan los pilares débiles: un bloqueo de retención que el rol equivocado podía anular, una red de backup "separada" que seguía confiando en el mismo dominio o una restauración que nunca se había ensayado de principio a fin.
El costo de equivocarse
Los tres pilares no son una lista abstracta de buenas prácticas. Se corresponden directamente con cuánto cuesta un incidente de ransomware y cuánto dura. El informe de 2025 de Sophos sitúa el costo medio de recuperación de un ataque de ransomware, sin incluir ningún rescate pagado, en 1,53 millones de dólares, frente a 2,73 millones de dólares en 2024. El 53 % de las víctimas se había recuperado por completo en una semana, frente al 35 % del año anterior. El resto pasó más de siete días en algún grado de interrupción, con el tiempo de inactividad, la pérdida de productividad y el trabajo de respuesta a incidentes acumulándose cada día.
La postura de backup es una de las pocas variables de esa ecuación que una organización controla por completo. Que el primer movimiento de un atacante contra su repositorio de backup tenga éxito o fracase depende en gran medida de decisiones tomadas meses antes, no durante el propio incidente. Cuando un actor de amenazas ya tiene credenciales de administrador de dominio y está buscando su plataforma de backup, la inmutabilidad, el aislamiento y la recuperación probada ya están implantados o no lo están; no hay oportunidad de añadirlos a posteriori bajo presión.
Errores habituales que debilitan discretamente los tres pilares
Hay unos cuantos patrones que aparecen una y otra vez en las revisiones posteriores a los incidentes:
- Confundir snapshots con copias de seguridad. Un snapshot de VMware es un registro de cambios del disco virtual original, no una copia independiente. El artículo de buenas prácticas sobre snapshots de Broadcom es tajante: "Do not use VMware snapshots as backups" (no utilice los snapshots de VMware como copias de seguridad). El archivo de snapshot sigue creciendo cuanto más tiempo se conserva, lo que puede llenar el datastore y perjudicar el rendimiento, y si se pierden los discos base, "the snapshot files alone are not sufficient to restore a virtual machine" (los archivos de snapshot por sí solos no bastan para restaurar una máquina virtual). Los snapshots son una función de comodidad para reversiones de corta duración (Broadcom recomienda no conservar un único snapshot más de 72 horas), no una estrategia de recuperación.
- Tratar "inmutable" como una casilla que marcar en lugar de como una propiedad verificada. Object Lock y las políticas de retención deben probarse frente al rol administrativo exacto que gestiona la plataforma de backup, no solo documentarse en una guía de configuración.
- Llamar "aislada" a una segunda copia que está en el mismo dominio de identidad. Si las mismas credenciales que se vieron comprometidas en producción pueden autenticarse en el repositorio de backup, la separación geográfica o de plataforma no proporciona un aislamiento real.
- Medir el éxito por la finalización del backup y no por la verificación de la restauración. Una marca verde en el trabajo de anoche le indica que los datos se escribieron en algún sitio. No le indica que esos datos se puedan recuperar, que sean coherentes a nivel de aplicación ni que estén libres del malware que obligó a restaurar.
El papel de BackupSec
BackupSec no sustituye su plataforma de backup. Tres de nuestros servicios se corresponden con los pilares anteriores:
- ZeroMON monitorea Veeam Backup & Replication. Se ejecuta on-premises como OVA, se conecta con una cuenta de solo lectura y no envía nada a BackupSec ni a terceros. Supervisa el estado de los trabajos, registra los cambios de configuración en su módulo Forensic & Audit (quién cambió qué y cuándo), ejecuta una lista de comprobación del Security Analyzer, genera informes y envía alertas por correo electrónico y como notificación dentro de la aplicación. Muestra el estado de inmutabilidad de cada repositorio tal como lo indica la propia configuración de repositorios de Veeam y avisa cuando esa configuración cambia. Lee la configuración de Veeam; no verifica los bloqueos a nivel de objeto en el propio almacenamiento.
- ZeroTAM es un asesor dedicado de seguridad de backup, no un software: diseño de arquitectura y aislamiento, planificación de capacidad, planificación de la recuperación ante ransomware y soporte prioritario durante una crisis.
- ZeroPEN es una prueba de penetración guiada por amenazas de Veeam Backup & Replication, Veeam ONE y Enterprise Manager. Simula una kill chain de ransomware alineada con MITRE ATT&CK en ocho fases: acceso inicial, descubrimiento e inventario, abuso de credenciales, compromiso del servidor de Veeam, acceso a repositorios, neutralización de las copias de seguridad, simulación de exfiltración y prueba de capacidad de cifrado. Nunca elimina copias de seguridad reales, no realiza cifrado real ni detiene servicios de producción o de backup. Usted obtiene evidencias listas para auditoría, y los hallazgos críticos se vuelven a probar. El servicio también incluye la verificación de la integridad de la restauración y de la inmutabilidad. Es una prueba puntual, por lo que los simulacros de restauración periódicos del pilar 3 siguen siendo necesarios.
Hable con BackupSec sobre la postura de seguridad de su backup →
¿Quiere ver cómo resistirían sus propias copias de seguridad? La Backup Security Assessment gratuita plantea 28 preguntas en siete áreas, desde la estrategia de backup y el control de acceso hasta las pruebas de recuperación.