Ransomware: por qué borrar un backup debería tardar 7 días, no 0Ransomware: why deleting a backup should take 7 days, not 0
Si tu sistema de backup permite un borrado instantáneo y definitivo, no tienes un backup: tienes una copia que el ransomware puede destruir en el mismo ataque.
If your backup system allows instant, permanent deletion, you don't have a backup — you have a copy the ransomware can destroy in the same attack.
Cuando se piensa en ransomware, la imagen mental suele ser la del cifrado masivo de archivos. Pero eso es solo la mitad del ataque. La otra mitad, la que decide si una empresa puede recuperarse sin pagar, ocurre en silencio antes: el ransomware busca y destruye las copias de seguridad.
El vector de ataque real
El ransomware moderno no es un script que cifra una carpeta. Es una operación con reconocimiento previo: una vez dentro de la red, el atacante busca activamente credenciales de administración, servidores de backup, y consolas de gestión de copias. Si las encuentra, borra o cifra los backups antes de lanzar el cifrado final sobre los datos de producción. El objetivo es simple: si no tienes de dónde restaurar, el rescate es tu única salida. Grupos como LockBit, Conti o BlackCat han incorporado esta fase como parte estándar de su manual de ataque.
Por qué el borrado instantáneo es un riesgo
Aquí está el problema de diseño que casi nadie cuestiona: en la mayoría de sistemas de backup, borrar es borrar. Si un atacante consigue una sesión con privilegios de administrador — por phishing, por una contraseña reutilizada, por un empleado con la sesión comprometida — puede eliminar semanas o meses de copias de un solo clic, sin ninguna ventana de recuperación. No hace falta que el ransomware "rompa" nada técnicamente sofisticado: basta con que el sistema confíe ciegamente en cualquier orden de borrado que llegue con las credenciales correctas.
La solución: una papelera con periodo de gracia
La respuesta no es impedir el borrado — eso rompería la gestión normal de espacio y retención. La respuesta es introducir fricción temporal: cuando se solicita borrar un backup, este no desaparece al instante. Queda retenido en una papelera durante un periodo de gracia (por ejemplo, 7 días) antes del borrado definitivo. Si el borrado fue malicioso — o un error humano, que en la práctica es igual de frecuente — hay una ventana real para detectarlo y revertirlo antes de que la copia se pierda de verdad.
Esta protección funciona a nivel de aplicación: no depende de que el sistema de archivos o el proveedor de almacenamiento la soporten. Funciona igual en Windows que en Linux, en un servidor local que en la nube, porque la lógica vive en el propio software de backup.
Papelera con periodo de gracia vs. Object Lock/WORM
Es importante no confundir esto con WORM (Write Once, Read Many) u Object Lock de S3, que resuelven un problema relacionado pero distinto. Object Lock es una protección a nivel de almacenamiento: una vez que un objeto se marca como inmutable durante un periodo, ni siquiera un administrador con credenciales completas — ni el propio proveedor cloud, en modo compliance — puede borrarlo o modificarlo antes de que expire el plazo. Es una garantía más fuerte, respaldada por el propio backend de almacenamiento.
El precio de esa fortaleza es que requiere un destino específico que lo soporte, típicamente S3 (o compatible) con Object Lock activado. No todos los destinos de backup lo ofrecen, y activarlo correctamente exige configuración deliberada.
La papelera con periodo de gracia, en cambio, no necesita ningún backend especial: protege desde el primer minuto, en cualquier destino. La combinación ideal es usar ambas capas: la papelera como red de seguridad universal, y Object Lock/WORM en el destino de almacenamiento cuando la infraestructura lo permite, para el nivel de protección más alto posible.
Cómo lo resuelve TitanVault
TitanVault implementa exactamente esta doble estrategia: cada backup borrado pasa primero por una papelera con periodo de gracia de 7 días antes de eliminarse de forma definitiva, como protección de aplicación activa por defecto, sin configuración adicional. Y para empresas que necesitan el nivel máximo de resistencia frente a un atacante con credenciales de administrador comprometidas, recomendamos combinarlo con un destino S3 con Object Lock activado. Ninguna de las dos capas sustituye a la otra — juntas cierran la ventana que el ransomware moderno intenta explotar.
Preguntas frecuentes
¿Por qué el ransomware ataca los backups?
Porque si puedes restaurar desde una copia limpia, el rescate pierde su poder de presión. Por eso buscan activamente credenciales de administración de backup.
¿Qué es una papelera con periodo de gracia?
Una protección de aplicación: el backup borrado queda retenido varios días antes de eliminarse para siempre, dando margen para revertir un borrado malicioso.
¿Es lo mismo que Object Lock/WORM?
No. Object Lock es una protección de almacenamiento más fuerte pero requiere un backend compatible; la papelera funciona en cualquier sistema. Son complementarias.
When people picture ransomware, they usually imagine mass file encryption. That's only half the attack. The other half — the one that decides whether a company can recover without paying — happens quietly beforehand: the ransomware hunts down and destroys the backups.
The real attack vector
Modern ransomware isn't a script that encrypts a folder. It's an operation with prior reconnaissance: once inside the network, the attacker actively searches for admin credentials, backup servers, and backup management consoles. If found, they delete or encrypt the backups before triggering the final encryption of production data. The goal is simple: if you have nothing to restore from, the ransom is your only way out. Groups like LockBit, Conti, and BlackCat have made this phase a standard part of their playbook.
Why instant deletion is a risk
Here's the design flaw almost nobody questions: in most backup systems, deletion is final. If an attacker gets an admin-privileged session — via phishing, a reused password, or an employee's compromised session — they can wipe out weeks or months of backups in a single click, with no recovery window at all. The ransomware doesn't need to be technically sophisticated: it just needs the system to blindly trust any deletion request that arrives with valid credentials.
The fix: a grace-period trash
The answer isn't to block deletion outright — that would break normal space and retention management. The answer is to introduce time friction: when a backup deletion is requested, it doesn't vanish instantly. It's held in a trash for a grace period (say, 7 days) before permanent deletion. If the deletion was malicious — or a human mistake, which in practice is just as common — there's a real window to detect and reverse it before the copy is truly lost.
This protection works at the application layer: it doesn't depend on the filesystem or storage provider supporting it. It works the same way on Windows and Linux, on a local server or in the cloud, because the logic lives in the backup software itself.
Grace-period trash vs. Object Lock/WORM
It's important not to confuse this with WORM (Write Once, Read Many) or S3 Object Lock, which solve a related but different problem. Object Lock is a storage-layer protection: once an object is marked immutable for a period, not even an administrator with full credentials — not even the cloud provider itself, in compliance mode — can delete or modify it before that period expires. It's a stronger guarantee, backed by the storage backend itself.
The cost of that strength is that it requires a specific supporting destination, typically S3 (or compatible) with Object Lock enabled. Not every backup destination offers it, and enabling it correctly requires deliberate configuration.
A grace-period trash, by contrast, needs no special backend: it protects from minute one, on any destination. The ideal combination uses both layers: the trash as a universal safety net, and Object Lock/WORM at the storage destination when infrastructure allows, for the highest possible level of protection.
How TitanVault handles it
TitanVault implements exactly this two-layer strategy: every deleted backup first goes through a 7-day grace-period trash before permanent removal, active by default as an application-layer protection with no extra configuration. And for businesses that need the highest resistance against an attacker with compromised admin credentials, we recommend pairing it with an S3 destination with Object Lock enabled. Neither layer replaces the other — together they close the window modern ransomware tries to exploit.
FAQ
Why does ransomware target backups?
Because if you can restore from a clean copy, the ransom loses its leverage. That's why attackers actively hunt for backup admin credentials.
What is a grace-period trash?
An application-layer protection: a deleted backup is held for several days before permanent removal, giving a window to reverse a malicious deletion.
Is it the same as Object Lock/WORM?
No. Object Lock is a stronger storage-layer protection but needs a compatible backend; the trash works on any system. They're complementary.