Estrategia de Backup Anti-Ransomware: La Regla 3-2-1-1-0 y Más Allá
Guía completa de estrategia de backup contra ransomware. La regla 3-2-1-1-0, backups inmutables, air-gapped, testing de restauración, protección de Veeam/Commvault, y por qué los atacantes priorizan destruir tus backups antes de cifrar.
Los atacantes destruyen tus backups primero
No es una hipótesis: es un procedimiento estándar documentado en los Conti Leaks, en advisories de CISA, y en cientos de informes de respuesta a incidentes. Los operadores de ransomware dedican tiempo específico a identificar y destruir la infraestructura de backup antes de lanzar el cifrado.
Según Veeam, el 93% de los ataques de ransomware intentan destruir los repositorios de backup. De las organizaciones que tenían backups, solo el 16% pudo recuperarse completamente sin pagar si sus backups no estaban protegidos específicamente contra ransomware.
Los backups son la defensa definitiva contra el ransomware, pero solo si sobreviven al ataque.
La regla 3-2-1: fundamento clásico
La regla 3-2-1 ha sido el estándar de backup durante décadas:
- 3 copias de los datos (producción + 2 copias de seguridad)
- 2 tipos de medios diferentes (disco + tape, disco + cloud, etc.)
- 1 copia offsite (fuera de la ubicación física principal)
Por qué 3-2-1 no es suficiente contra ransomware
La regla 3-2-1 protege contra fallos de hardware, desastres naturales y errores humanos. No fue diseñada para un adversario inteligente que:
- Compromete el servidor de backup (está en la misma red)
- Elimina las copias offsite si accede a las credenciales del cloud storage
- Cifra tanto producción como backup simultáneamente
- Corrompe los backups gradualmente durante semanas antes de cifrar (time bomb)
La regla 3-2-1-1-0: el estándar anti-ransomware
| Componente | Requisito | Motivo |
|---|---|---|
| 3 | 3 copias de datos | Redundancia ante fallo de una copia |
| 2 | 2 tipos de medios diferentes | Diversificación de riesgo (no todo en el mismo storage) |
| 1 | 1 copia offsite | Protección contra desastres físicos |
| 1 | 1 copia offline o inmutable | Protección contra ransomware y adversarios |
| 0 | 0 errores en testing de restauración | Verificación de que la recuperación funciona |
El componente clave es el 1 offline/inmutable: una copia que el atacante no puede destruir ni cifrar, incluso con acceso de Domain Admin a toda la red.
Backups inmutables
Concepto
Un backup inmutable no puede ser modificado, cifrado ni eliminado durante un período definido (retention period). La inmutabilidad se implementa a nivel de storage, no a nivel de software de backup. Ni siquiera las credenciales de administrador del sistema de backup pueden alterar los datos inmutables.
Implementaciones
| Tecnología | Tipo | Inmutabilidad |
|---|---|---|
| AWS S3 Object Lock | Cloud | Compliance mode (ni root puede eliminar) o Governance mode (con permisos especiales) |
| Azure Immutable Blob Storage | Cloud | Time-based retention o legal hold |
| Wasabi Object Lock | Cloud | S3-compatible, coste bajo |
| Backblaze B2 | Cloud | Object Lock vía API |
| Veeam Hardened Repository | On-premise | Linux con immutable flag (chattr +i), sin SSH habilitado |
| Dell PowerProtect DD | Appliance | Retention Lock (Compliance o Governance) |
| ExaGrid | Appliance | Retention Time-Lock, tiered backup storage |
| HPE StoreOnce | Appliance | Catalyst immutability |
Veeam Hardened Repository
Para organizaciones que usan Veeam (la herramienta de backup más atacada por ransomware), el Hardened Repository es una implementación recomendada:
- Servidor Linux dedicado (Ubuntu Server LTS)
- Solo accesible por el servicio de Veeam (sin SSH habilitado post-configuración)
- Backups almacenados con immutable flag del filesystem (
chattr +i) - Sin credenciales de este servidor almacenadas en el servidor de Veeam principal
- Sin conexión de red directa a Active Directory
Esto significa que incluso si el atacante compromete el servidor de Veeam (que está en AD), no puede acceder al Hardened Repository porque:
- No tiene credenciales del servidor Linux
- SSH está deshabilitado
- Los archivos tienen el flag de inmutabilidad del filesystem
Backups air-gapped
Concepto
Un backup air-gapped está físicamente desconectado de la red. No hay forma de acceder a él remotamente. La única forma de modificar o destruir un backup air-gapped es tener acceso físico al medio.
Implementaciones
| Método | Descripción | Coste | Complejidad |
|---|---|---|---|
| Tape (LTO) | Cintas magnéticas almacenadas en armario ignífugo o off-site | Bajo | Media |
| Disco USB rotativo | Discos externos que se rotan y desconectan | Bajo | Baja |
| NAS con desconexión programada | NAS que solo se conecta a la red durante la ventana de backup | Medio | Media |
| Vault cloud con acceso restringido | Cuenta cloud sin acceso desde la red corporativa, solo vía consola dedicada | Medio | Baja |
Tape: el superviviente
Las cintas LTO siguen siendo la opción más resiliente contra ransomware:
- Desconectadas por defecto: la cinta sale del drive y se almacena en un estante. No hay forma de cifrarla remotamente
- Coste de almacenamiento: LTO-9 ofrece 18 TB nativos (45 TB comprimidos) por cinta (~100 EUR). Más barato que cualquier storage online
- Longevidad: cintas LTO tienen vida útil de 30+ años en condiciones adecuadas
- Compliance: muchas regulaciones (ENS Alto, HIPAA, SOX) reconocen tape como medio de backup aceptable
La desventaja es la velocidad de restauración: restaurar terabytes desde tape es más lento que desde disco o cloud. Para RPO (Recovery Point Objective) de horas, tape no es práctico como copia primaria, pero es excelente como copia de último recurso.
Protección del servidor de backup
Por qué Veeam es un objetivo
Veeam es el software de backup más usado en entornos Windows y, por tanto, el más atacado. Los operadores de ransomware buscan específicamente:
- Procesos
Veeam.Backup.Service.exe - Bases de datos de configuración de Veeam
- Repositorios de backup de Veeam
- Credenciales almacenadas en Veeam (que frecuentemente incluyen credenciales de Domain Admin)
Hardening del servidor de backup
| Medida | Descripción | Prioridad |
|---|---|---|
| Separar de AD | El servidor de backup no debe ser miembro del dominio Active Directory | Critica |
| MFA obligatorio | Acceso al servidor de backup solo con MFA | Critica |
| Credenciales únicas | Credenciales del servidor de backup diferentes a las de AD | Critica |
| Red separada | VLAN dedicada para tráfico de backup, firewall entre backup y producción | Alta |
| Inmutabilidad | Hardened Repository o S3 Object Lock | Critica |
| Sin RDP | Acceso al servidor de backup solo por consola local o VPN dedicada | Alta |
| Monitorización | Alertar en detención del servicio Veeam, eliminación de jobs, cambios de configuración | Alta |
| Encryption at rest | Cifrar los backups con clave que no está en AD | Media |
Credenciales de Veeam como vector de ataque
Un hallazgo frecuente en incidentes de ransomware: el atacante compromete el servidor de Veeam, extrae las credenciales almacenadas (que a menudo incluyen cuentas con privilegios elevados en toda la red), y usa esas credenciales para movimiento lateral y escalada de privilegios.
Mitigación: usar cuentas de servicio dedicadas con mínimos privilegios para cada job de backup. No almacenar credenciales de Domain Admin en Veeam.
Testing de restauración: el "0" de 3-2-1-1-0
Por qué testear
Estadísticas de la industria indican que el 30-40% de los backups fallan al intentar restaurar. Las causas más comunes:
- Corrupción silenciosa de datos (bit rot)
- Incompatibilidad de versiones del software de backup
- Dependencias no incluidas en el backup (certificados, configuraciones, licencias)
- Backup incompleto (archivos en uso no capturados)
- Error en la configuración de retención (backups más antiguos de lo esperado purgados)
Programa de testing
| Frecuencia | Alcance | Método |
|---|---|---|
| Semanal | Verificación automática de integridad | SureBackup (Veeam), backup verification job |
| Mensual | Restauración de un sistema crítico a entorno de test | Restaurar VM a sandbox, verificar funcionalidad |
| Trimestral | Simulacro de DR parcial | Restaurar un servicio completo (AD + app + DB) |
| Anual | Simulacro de DR completo | Restaurar toda la infraestructura desde backup |
Métricas de backup
| Métrica | Objetivo | Cómo medir |
|---|---|---|
| RPO (Recovery Point Objective) | Cuántos datos puedes perder (horas) | Frecuencia de backup real vs planificada |
| RTO (Recovery Time Objective) | Cuánto tiempo para restaurar | Tiempo real de restauración en simulacros |
| Backup success rate | Porcentaje de jobs exitosos | Dashboard de Veeam/Commvault |
| Restore success rate | Porcentaje de restauraciones exitosas | Resultado de testing trimestral |
| Immutability coverage | % de datos con backup inmutable | Auditoría de repositorios |
Estrategia de retención anti-ransomware
El problema del time bomb
Algunos atacantes corrompen backups gradualmente durante semanas antes de lanzar el cifrado. Si la retención de backup es de solo 7 días, todos los backups disponibles pueden contener datos ya corrompidos.
Retención recomendada
| Tipo de backup | Retención | Motivo |
|---|---|---|
| Backup diario | 30 días | Ventana suficiente para detectar corrupción gradual |
| Backup semanal | 3 meses | Punto de restauración pre-compromiso |
| Backup mensual | 12 meses | Restauración a estado anterior a infección latente |
| Backup inmutable | 30 días mínimo | Garantía de una copia limpia |
| Backup air-gapped (tape) | 12 meses | Último recurso absoluto |
La retención de 30 días en backups inmutables es el mínimo. Considerando que el dwell time medio de ransomware es de 5 días (Mandiant 2025) pero puede ser de semanas, 30 días proporciona un margen razonable.
Checklist de implementación
Inmediato (esta semana)
- Verificar que existe al menos un backup no accesible desde la red de producción
- Comprobar que las credenciales del servidor de backup son diferentes a las de AD
- Verificar la última restauración exitosa de cada sistema crítico
- Habilitar alertas en detención del servicio de backup
Corto plazo (este mes)
- Implementar backup inmutable (S3 Object Lock o Veeam Hardened Repository)
- Separar el servidor de backup del dominio AD
- Establecer programa de testing de restauración trimestral
- Configurar retención de 30 días mínimo en todos los backups
Medio plazo (este trimestre)
- Implementar backup air-gapped (tape o disco desconectado)
- VLAN dedicada para tráfico de backup
- MFA en acceso al servidor de backup
- Primer simulacro de DR completo
Fuentes y referencias
- Veeam. "2024 Ransomware Trends Report." Veeam, 2024.
- Veeam. "Hardened Repository: Best Practices." Veeam Documentation, 2024.
- CISA. "Protecting Against Ransomware: Backup Best Practices." CISA Publication, 2024.
- NIST. "SP 800-209: Security Guidelines for Storage Infrastructure." NIST, 2020.
- Sophos. "The State of Ransomware 2025: Backup Impact Analysis." Sophos, 2025.
- Mandiant. "M-Trends 2025: Dwell Time and Recovery Statistics." Google Cloud Security, 2025.
- Conti Leaks. Internal playbooks documenting backup destruction procedures. 2022.
- AWS. "Amazon S3 Object Lock." AWS Documentation.
- Microsoft. "Azure Blob Immutable Storage." Azure Documentation.
- Gartner. "Protect Backup Infrastructure from Ransomware." Gartner Research, 2024.
Preguntas frecuentes
Libros recomendados
Artículos relacionados
Cadena de Infección de Ransomware: Del Acceso Inicial al Cifrado
Detección Temprana de Ransomware: Indicadores, Reglas y Estrategias para Actuar Antes del Cifrado
Incident Response para Ransomware: Playbook Completo Paso a Paso
BlackCat/ALPHV: Doble Extorsión y Data Leak Investigation
Conti: De Cobalt Strike a Exfiltración y Cifrado en 72 Horas
LockBit 3.0: Incident Response Completo de Principio a Fin
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.