Copias de seguridad contra ransomware: regla 3-2-1-1-0, backup inmutable y pruebas de restauración

Una copia de seguridad protege frente al ransomware si el intruso no puede borrarla ni cifrarla y si se restaura antes de que la parada cause un daño que el negocio no pueda asumir. Las encuestas del sector muestran que la primera condición falla a menudo. La segunda solo se conoce cuando alguien ha medido una restauración.

En la encuesta State of Ransomware 2024 de Sophos, el 94 % de las organizaciones atacadas dijo que los delincuentes habían intentado comprometer sus copias, y el 57 % de esos intentos salió bien. El análisis de Sophos sobre copias comprometidas compara a las víctimas que sufrieron copias comprometidas con las que las mantuvieron intactas. Las primeras recibieron una petición de rescate inicial de 2,3 millones de dólares de mediana, frente a 1 millón, y pagaron en el 67 % de los casos, frente al 36 %. Su coste mediano de recuperación fue ocho veces mayor.

¿Por qué el ransomware ataca primero las copias de seguridad?

El ransomware ataca primero las copias de seguridad porque una víctima que puede restaurar tiene pocos motivos para pagar por el descifrador. Al atacante solo le quedaría la amenaza de publicar lo robado.

Una secuencia habitual pasa por el robo de credenciales de administrador del dominio. Si el servidor de backup está unido a ese dominio, esas mismas credenciales abren su consola, y el intruso las usa para borrar trabajos, acortar la retención y eliminar puntos de restauración antes de lanzar el cifrado. MITRE ATT&CK recoge esta fase como T1490, Inhibit System Recovery, con comandos como vssadmin.exe delete shadows /all /quiet, wbadmin delete catalog -quiet o, en hipervisores ESXi, vim-cmd vmsvc/snapshot.removeall.

Como son herramientas legítimas del sistema, detectar su abuso exige vigilar cuándo se ejecutan fuera de contexto, algo que tratamos en nuestra guía sobre detección del abuso de binarios legítimos.

También se ataca el software de copias. A 1 de octubre de 2026, el catálogo KEV (Known Exploited Vulnerabilities) de CISA recoge cuatro vulnerabilidades de Veeam Backup & Replication explotadas en campañas de ransomware. Las dos más recientes son estas:

• CVE-2023-27532 permitía obtener las credenciales cifradas guardadas en la base de datos de configuración. BlackBerry detectó su explotación por el grupo Cuba en 2023. WithSecure relacionó con FIN7, o con un actor que usaba sus técnicas, varios ataques de ese año contra servidores Veeam expuestos, y estimó con una confianza entre baja y media que la vía de entrada había sido este fallo.
• CVE-2024-40711 permitía ejecutar código en remoto sin autenticación y tiene una puntuación CVSS de 9,8. Sophos X-Ops la encontró en ataques de Akira y Fog cuyos autores habían entrado por pasarelas VPN sin autenticación multifactor.

Hay poco margen para detectar al intruso antes de que llegue a las copias. El Active Adversary Report 2026 de Sophos, con casos de noviembre de 2024 a octubre de 2025, situó en tres días la mediana de permanencia y en 3,4 horas la mediana hasta que los atacantes iban a por Active Directory. Mandiant, en su M-Trends 2025, dio seis días de mediana para las intrusiones con ransomware y 29 cuando las descubría la organización atacada y no un tercero.

Veeam, en su informe de 2025 From Risk to Resilience, encontró que los atacantes fueron a por los repositorios de copias en el 89 % de las organizaciones atacadas. De media, modificaron o borraron el 34 % de esos repositorios, según resume el fabricante en su blog.

¿Qué es la regla 3-2-1-1-0?

La regla 3-2-1-1-0 amplía la regla 3-2-1 de copias de seguridad con una copia inmutable o desconectada y con cero errores al comprobar que las copias se restauran. La ha popularizado Veeam, que la describe en su artículo sobre la regla 3-2-1. Ninguna de las normas que repasa esta guía la menciona, y la guía técnica de ENISA cita solo la 3-2-1.

La 3-2-1 original la acuñó el fotógrafo Peter Krogh en la primera edición de The DAM Book, publicada en 2005, según contó él mismo en el pódcast Backup Wrap-Up. Guardar varias copias, una de ellas fuera de la oficina, era un consejo antiguo; Krogh le puso el nombre con el que se ha quedado.

Cada cifra corresponde a un requisito:

• 3: tres copias de los datos, contando la de producción.
• 2: dos tipos de almacenamiento distintos, para que un mismo fallo no afecte a todas las copias.
• 1: una copia fuera de las instalaciones.
• 1: una copia inmutable o desconectada (offline o air gap).
• 0: cero errores en la verificación de la restauración.

Los dos últimos requisitos se añadieron pensando en el ransomware. Una copia inmutable sigue accesible por la red, pero el sistema que la guarda impide modificarla o borrarla durante el periodo de retención. Una copia desconectada, como una cinta fuera de la librería, queda fuera del alcance de quien controla la red.

Las dos opciones tienen inconvenientes. Restaurar desde cinta es lento. Sobre la inmutabilidad, la guía #StopRansomware de CISA aconseja usarla «con cautela», porque no cumple los criterios de algunas regulaciones y porque un error de configuración puede salir caro.

¿Cómo se configura un backup inmutable en S3, Azure, Linux o NAS?

Un backup inmutable se configura con un bloqueo de retención que ni un administrador puede levantar antes de plazo ni un atacante con privilegios puede relajar después. Cada plataforma lo resuelve a su manera: Object Lock en Amazon S3, políticas bloqueadas en Azure, el Hardened Repository de Veeam en Linux y carpetas WORM o instantáneas inmutables en los NAS. La definición completa está en la entrada de nuestro glosario sobre backup inmutable.

Almacenamiento de objetos en la nube

En Amazon S3, la inmutabilidad se activa con Object Lock, que exige tener activado el versionado del bucket y ofrece dos modos. En modo de cumplimiento (compliance), ningún usuario, ni siquiera el usuario raíz, puede borrar o sobrescribir el objeto ni acortar su retención antes de que venza. La única salida es cerrar la cuenta de AWS.

El modo de gobierno (governance) protege mucho menos. Una identidad con el permiso s3:BypassGovernanceRetention puede saltarse el bloqueo, y la consola de AWS incluye por defecto la cabecera que lo permite. Frente a un atacante con privilegios en la cuenta, solo aguanta el modo de cumplimiento, y siempre que tampoco pueda desactivar ni borrar las claves de AWS KMS que cifran los objetos. Desactivar una clave es inmediato, mientras que borrarla exige una espera de 7 a 30 días, tiempo suficiente para reaccionar si una alerta avisa del borrado programado.

Azure Blob Storage usa políticas de inmutabilidad bloqueadas o sin bloquear, y las que están sin bloquear se pueden acortar y borrar. Microsoft recomienda bloquearlas, normalmente en menos de 24 horas desde que se configuran. Una vez bloqueadas, la retención solo puede ampliarse.

Repositorios en servidor Linux

El Hardened Repository de Veeam guarda las copias en un servidor Linux, normalmente con XFS, que es el sistema de archivos que recomienda el fabricante, y marca los ficheros como inmutables mediante atributos del sistema de archivos. Usa credenciales de un solo uso que no se almacenan en el servidor de backup, así que quien compromete la consola no consigue con ello borrar las copias.

La guía de buenas prácticas de Veeam reconoce los límites de este diseño. Pide desactivar SSH y retirar los permisos de sudo tras la instalación, y advierte de que alguien con acceso físico al equipo podría comprometerlo. Las interfaces de gestión fuera de banda, como iDRAC o iLO, dan un acceso equivalente y necesitan una red y unas credenciales exclusivas.

NAS y cintas

En los modelos compatibles, Synology ofrece instantáneas inmutables sobre volúmenes Btrfs y carpetas WORM con su función WriteOnce. Según su documentación, esas instantáneas no se pueden eliminar por ningún medio mientras dura el periodo de protección. QNAP tiene carpetas WORM en dos modos, y solo el de cumplimiento impide borrar la carpeta compartida, aunque un administrador todavía puede eliminar el grupo de almacenamiento que la contiene.

Sea cual sea el fabricante, el panel de administración del NAS no debe estar expuesto a Internet ni compartir credenciales con el dominio. Quien lo controle puede, como mínimo, detener las copias nuevas.

La cinta extraída de la librería sigue siendo la copia más difícil de alcanzar desde la red. Su precio es el tiempo de restauración, que debe medirse en una prueba antes de que haga falta.

¿Cuánto tiempo deben conservarse las copias inmutables?

Las copias inmutables deben conservarse más tiempo del que un intruso puede pasar dentro sin ser detectado, sumado al que se tarda en descubrir que las copias recientes ya estaban contaminadas. Las medianas publicadas son de tres días en el conjunto de casos de Sophos y de seis en las intrusiones con ransomware que investigó Mandiant. La distribución tiene, sin embargo, una cola larga: en los datos de Mandiant, solo el 56,5 % de esas intrusiones duró una semana o menos, y las que descubrió la organización atacada tuvieron una mediana de 29 días.

Synology, por ejemplo, recomienda periodos de protección de 7 a 14 días para sus instantáneas. Con los datos anteriores, a nuestro juicio, siete días se quedan cortos para los sistemas críticos. Recomendamos como punto de partida que al menos una copia inmutable cubra un mes, y más si la organización tarda en detectar intrusiones. El límite superior lo marca el coste del almacenamiento. Como en modo de cumplimiento una retención mal configurada no se puede acortar, la primera configuración debe ensayarse en un bucket de pruebas con plazos cortos.

¿Cómo se aísla del dominio la infraestructura de backup?

La infraestructura de backup se aísla tratándola como un sistema de nivel 0 (tier 0), con la protección que el modelo de tiering de Active Directory reserva a los controladores de dominio. Eso supone sacarla del dominio de producción, protegerla con credenciales separadas y MFA, ponerla en un segmento de red aparte y no dejar accesos remotos permanentes. Mandiant, en su M-Trends 2026, recomienda expresamente sacar del dominio corporativo de Active Directory los hipervisores y la infraestructura de copias.

La CVE-2025-23120 de Veeam, con una puntuación CVSS de 9,9, ilustra el riesgo. Permitía ejecutar código a un usuario autenticado del dominio, pero, según el aviso del fabricante, solo afectaba a servidores de backup unidos al dominio. En octubre de 2025, Veeam corrigió otras dos, también de 9,9, con la misma limitación a usuarios del dominio y equipos unidos a él. Son la CVE-2025-48984, en el servidor de backup, y la CVE-2025-48983, en el servicio Mount de los servidores de la infraestructura de copias. A 1 de octubre de 2026, ninguna de las tres figuraba en el catálogo KEV.

Estas son las medidas que revisamos en cada auditoría de plataforma de copias:

• Servidor de backup y repositorios fuera del Active Directory de producción, o en un bosque de gestión separado.
• Cuentas exclusivas para la consola, sin reutilizar contraseñas del dominio y con MFA, siguiendo el principio de mínimo privilegio.
• Un segmento de red dedicado, abierto solo a los puertos que necesitan los agentes y sin acceso a la consola desde la red de usuarios, según el diseño que explicamos en el artículo sobre segmentación de red interna.
• Ni RDP ni SSH abiertos de forma permanente, y la gestión fuera de banda en una red de administración aislada.
• Parches del software de backup con prioridad máxima, porque sus fallos figuran en el catálogo KEV de CISA.
• Custodia de las claves de cifrado por separado de los datos copiados, como recomienda ENISA.
• Alertas por borrado de trabajos, cambios de retención o borrado masivo de puntos de restauración, que lleguen a alguien que vigile de noche. En el informe de Sophos de 2026, el 88 % del ransomware analizado se desplegó fuera del horario laboral.

Si nadie atiende esas alertas de madrugada, un SOC gestionado cubre ese hueco.

¿Cada cuánto hay que probar la restauración?

La restauración debe probarse con una frecuencia acorde con la criticidad de los datos y cada vez que cambia la infraestructura. Como referencia, la guía técnica de ENISA para NIS2 pone como ejemplo comprobar las copias cada semana si los datos son de criticidad alta, cada mes si son de criticidad media o baja y justo después de un cambio significativo.

La prueba corresponde al cero de la regla 3-2-1-1-0 y, por lo que vemos en auditorías, es el paso que más se descuida. Que un trabajo de copia termine sin errores solo indica que los datos se copiaron. Según el mismo informe de Veeam, apenas el 28 % de los encuestados restauró los datos en un entorno aislado (sandbox) y comprobó su integridad, mientras que el 39 % tuvo que restaurarlos directamente sobre producción, con riesgo de reintroducir al atacante.

Una prueba útil incluye estos elementos, por este orden:

1. Definición, para cada servicio, de un RTO (cuánto tiempo puede estar parado) y un RPO (cuántos datos puede perder) dentro del plan de recuperación ante desastres.
2. Restauración en un entorno separado de la red de producción, nunca encima de ella.
3. Análisis de lo restaurado en busca de persistencia, porque la copia se hizo mientras el atacante podía estar dentro.
4. Recuperación por fases: primero la identidad (Active Directory y DNS), después las bases de datos y al final las aplicaciones.
5. Medición del tiempo total, comparación con el RTO y registro de lo que hubo que corregir.

Active Directory se ensaya por separado. La guía de recuperación de bosques de Microsoft pide copias periódicas de al menos dos controladores de dominio con escritura por dominio y ordena empezar por el dominio raíz del bosque. La copia de un controlador de solo lectura no sirve para restaurar uno con escritura. La guía advierte, además, de que no incluye recomendaciones de seguridad para recuperar un bosque atacado o comprometido. Tras un ataque de ransomware, elegir un punto de restauración limpio requiere análisis forense y un plan de respuesta a incidentes que lo tenga previsto.

¿Qué exigen el ENS, ISO 27001, NIS2 y DORA sobre las copias de seguridad?

El ENS, ISO 27001, NIS2 y DORA exigen copias de seguridad, y la mayoría también pruebas de restauración, pero ninguno pide de forma expresa que las copias sean inmutables. El ENS solo exige las pruebas desde el nivel medio. En NIS2, la obligación expresa de probarlas está en un reglamento de ejecución que solo se aplica a ciertos proveedores digitales.

• ENS (RD 311/2022), medida mp.info.6. Se aplica según el nivel de la dimensión de disponibilidad, no según la categoría del sistema. Desde el nivel medio, el refuerzo R1 obliga a probar con regularidad la copia y la restauración. En el nivel alto, el R2 exige guardar al menos una copia por separado y en un lugar diferente, para que un mismo incidente no afecte a la vez al original y a la copia. Revisamos esta medida en cada proyecto de adecuación al ENS.
• ISO/IEC 27001:2022, control A.8.13. Pide mantener copias de la información, el software y los sistemas y probarlas con regularidad según una política específica de copias. Los auditores de ISO 27001 piden evidencias de su cumplimiento.
• NIS2, artículo 21.2.c. Incluye la gestión de copias de seguridad y la recuperación en caso de catástrofe dentro de la continuidad de las actividades. El Reglamento de Ejecución (UE) 2024/2690 añade copias fuera de la red del sistema, comprobaciones de integridad y pruebas de recuperación documentadas, pero solo para una lista cerrada de proveedores digitales, entre ellos los de nube, centros de datos, servicios gestionados y seguridad gestionada. La guía técnica de ENISA sugiere la regla 3-2-1 y menciona las copias inmutables o desconectadas. La situación en España la analizamos en qué hacer con NIS2 sin ley de transposición.
• DORA, artículo 12. Obliga a las entidades financieras a probar periódicamente la copia, la restauración y la recuperación, y a comprobar la integridad de los datos después de recuperarlos. Cuando restauran con sus sistemas, estos deben estar separados física y lógicamente del sistema de origen. Más detalle en nuestra página sobre DORA.

Para demostrar la copia separada que piden el ENS en nivel alto y el reglamento de NIS2, lo más sencillo suele ser una copia inmutable o desconectada guardada en otro emplazamiento. En las auditorías, lo que más falta son las actas de las pruebas de restauración.

Lista de comprobación para proteger las copias de seguridad del ransomware

Siete preguntas para comprobar en una tarde si las copias aguantarían un ataque:

• ¿Hay al menos una copia que un administrador del dominio no pueda borrar ni acortar?
• ¿El servidor de backup y los repositorios están fuera del dominio de producción?
• ¿La consola de copias pide MFA y usa cuentas que no existen en Active Directory?
• ¿Cubre la retención inmutable más días de los que se tardaría en detectar una intrusión?
• ¿El software de backup está al día con los parches de seguridad publicados?
• ¿Cuándo fue la última restauración completa en un entorno aislado y cuánto tardó?
• ¿Saltaría una alerta de noche si alguien borrara trabajos o puntos de restauración?

Cada respuesta «no» o «no lo sé» señala algo que corregir. Si el ataque ya está en marcha, nuestra guía me han hackeado indica qué hacer en las primeras horas. Para diseñar o revisar la plataforma, nuestro servicio de continuidad de negocio y recuperación cubre la estrategia de copias y las pruebas. El de bastionado de sistemas se ocupa del endurecimiento de servidores y repositorios.

Este artículo es orientativo. Las configuraciones citadas proceden de la documentación pública de AWS, Microsoft, Veeam, Synology y QNAP a 1 de octubre de 2026 y pueden cambiar con nuevas versiones. Las cifras de encuestas corresponden a las ediciones citadas. Toda política de retención inmutable debe ensayarse antes en un entorno de pruebas separado de producción, porque en modo de cumplimiento no se puede deshacer.