Durante una semana, en Rumanía no se pudo vender una casa ni firmar una hipoteca. No por una huelga ni por una ley: porque el 14 de julio un atacante borró la base de datos del registro de la propiedad del país entero, y con ella los backups que pudo alcanzar. Diecinueve millones de personas dependiendo de una pregunta que en seguridad se hace poco y se responde peor: ¿queda alguna copia donde el atacante no haya podido llegar? En Rumanía la respuesta fue sí. Por eso este post existe en la categoría «lecciones» y no en la de «catástrofes».
Una semana con el mercado inmobiliario de un país en pausa
La cronología, según lo publicado por Risky Business y Help Net Security: el 14 de julio, e-Terra —el sistema de catastro y registro de la ANCPI, la agencia nacional rumana— deja de estar disponible. El 15 de julio, la agencia confirma el ciberataque y, ese mismo día, los datos robados aparecen a la venta en un foro. El atacante, que firma como ByteToBreach, afirma haberse llevado datos de ciudadanos, servidores GitLab y el código fuente de los sistemas del registro. Mientras tanto, en el mundo físico: notarios sin poder autenticar compraventas, hipotecas sin poder registrarse, ciudadanos sin poder demostrar que su casa es suya.
El 20 de julio, la ANCPI comunica que está reconstruyendo su red entera desde cero —«un proceso extenso de reinstalación y consolidación», en sus palabras— y que espera tener e-Terra de vuelta hacia el final de la semana. Sobre los datos hay dos versiones que conviene citar tal cual: la agencia sostiene que la información que administra «no se ha visto comprometida»; el atacante vende en un foro lo que dice haber robado, y la firma de inteligencia KELA apunta que sus reivindicaciones anteriores resultaron ciertas. La investigación sigue abierta; nosotros no vamos a resolverla desde aquí.
El detalle que lo cambia todo: también borró los backups
Según el boletín de Risky Business, el atacante entró con credenciales válidas, se paseó por la red interna mapeando sistemas, intentó extorsionar a la agencia y, cuando no coló, borró los sistemas y los backups. Léelo otra vez: los backups. No es un descuido del guion, es el procedimiento estándar. Nadie que quiera cobrar un rescate deja intacta tu capacidad de restaurar. Primero localizan las copias, luego las destruyen, y solo entonces cifran o borran producción. Lo llevamos años viendo en empresas; ahora lo hemos visto a escala de país.
Y aun así Rumanía está recuperando sus datos. La propia ANCPI lo explicó: copias de seguridad almacenadas en varias ubicaciones evitaron la pérdida total. Dicho de otro modo: existía al menos una copia a la que las credenciales del atacante no llegaban. Esa copia —la aburrida, la que no aparece en ningún diagrama bonito, la que alguien mantenía fuera del alcance de la red comprometida— es la diferencia entre «una semana muy mala» y un país teniendo que reconstruir la titularidad de millones de fincas a base de escrituras en papel.
La regla que este caso deja grabada: si un juego de credenciales de administrador puede borrar producción y también todas tus copias, no tienes tres backups: tienes uno con réplicas. El 3-2-1 no va de contar copias, va de que ningún fallo único —ni humano, ni técnico, ni hostil— pueda alcanzarlas a todas.
No es mala suerte rumana: los registros públicos están en la diana
En enero de 2025, un ransomware tumbó el registro de la propiedad de Eslovaquia (la oficina UGKK). Su Gobierno lo describió como el mayor ciberataque de la historia del país, con un rescate de millones de euros sobre la mesa y una recuperación que se estimaba en semanas o meses, entre otras cosas por las dudas sobre si los backups estaban completos. En mayo de 2026, la fiscalía lituana confirmó que alguien descargó más de 600.000 registros inmobiliarios de su Centro de Registros: sin exploit ninguno, usando credenciales legítimas de otro organismo público con acceso autorizado. Tres países, tres ataques al mismo tipo de sistema en año y medio —dos de ellos sin un solo exploit—. Eso ya no es casualidad, es una categoría de objetivo.
¿Por qué esta fijación con los registros de la propiedad? Porque reúnen las tres propiedades que un extorsionador busca: son el único ejemplar de un dato que no se puede reconstruir desde otra fuente, todo un país depende de ellos cada día, y suelen correr sobre infraestructura pública con menos presupuesto de defensa que un banco. Ahora traduce eso a tu empresa: tu ERP, tus expedientes de cliente, tu histórico de facturación. Para tu negocio, ese sistema del que solo hay un ejemplar y sin el cual no puedes operar es tu registro de la propiedad. La única diferencia es que lo tuyo no saldrá en la prensa internacional.
Credenciales válidas: otra vez la puerta principal
Fíjate en que en Rumanía no hubo zero-day, y en Lituania tampoco: en ambos casos el atacante entró por la puerta con llaves de verdad. Hace una semana contábamos el caso opuesto, los zero-days de SonicWall SMA 1000, y la conclusión era la misma que hoy: la pregunta importante no es «¿pueden entrar?» —a veces la respuesta será sí, por exploit o por credencial robada— sino «¿qué pueden alcanzar una vez dentro?». Cuando la respuesta incluye «los backups», el incidente deja de ser un problema técnico y pasa a ser un problema existencial.
Cómo se construye la copia que sobrevive
En los backups que gestionamos —con Proxmox Backup Server y con Veeam, según la plataforma del cliente— aplicamos una regla que este caso ilustra mejor que cualquier presentación: diseñar el backup asumiendo que el atacante ya tiene las credenciales de administrador. De ahí se deducen las cuatro medidas que de verdad importan:
- 1.Inmutabilidad real. Al menos una copia en almacenamiento donde nadie —ni un administrador legítimo con prisas, ni un atacante con sus credenciales— pueda borrarla o modificarla antes de que venza su retención. Si se puede desactivar con un clic desde la misma consola, no es inmutable: es decorativa.
- 2.Credenciales separadas. El sistema de backup no se une al dominio que protege, y sus credenciales no se comparten con nada más. El día que caiga el Directorio Activo —que es exactamente el día para el que existe el backup— la infraestructura de copias tiene que seguir siendo territorio hostil para el atacante.
- 3.Distancia física o lógica de verdad. La copia de Rumanía que sobrevivió lo hizo por estar fuera del alcance de la red comprometida. Da igual si lo consigues con una ubicación offline, con otro datacenter o con almacenamiento desconectado del dominio: lo que cuenta es que ningún camino de red administrable lleve de producción a esa copia.
- 4.Restaurar se ensaya. Rumanía tenía la copia y aun así lleva más de una semana reconstruyendo. Un backup que nunca has restaurado a lo grande es una hipótesis, no un plan. El tiempo de recuperación se mide ensayando, no se estima en una reunión.
Sobre el último punto, ojo con leer el caso rumano como un éxito redondo: la copia existía, pero el país estuvo una semana sin mercado inmobiliario y la agencia decidió reconstruir su red entera desde cero —decisión sensata cuando el intruso se paseó con credenciales válidas, y carísima en tiempo—. Tener el dato no es tener el servicio. Esa distancia entre «los datos están a salvo» y «volvemos a operar» es exactamente de lo que hablamos cuando hablamos de disaster recovery, y de lo que iba nuestro análisis de la caída de AWS CloudFront la semana pasada.
Las dos preguntas para esta semana
Si de este caso te llevas algo a tu próxima reunión de IT, que sean estas dos preguntas. Una: ¿cuántas de nuestras copias puede borrar alguien que consiga las credenciales de nuestro administrador? Si la respuesta es «todas» —y en más empresas de las que parece lo es—, el resto de tu estrategia de seguridad está construida sobre esa grieta. Y dos: ¿cuándo fue la última vez que restauramos algo grande de verdad, y cuánto tardamos? Si nadie sabe responder, el dato que falta no es técnico: es que nunca se ha hecho. En everyWAN gestionamos backup como servicio precisamente alrededor de estas dos preguntas: copias inmutables con credenciales y ubicación separadas, y restauraciones que se prueban, no que se suponen. Si quieres que revisemos las dos respuestas contigo, hablamos.
En corto
A Rumanía no la salvó un firewall, ni un SOC, ni una caja con luces. La salvó la copia que el atacante no pudo tocar. Todo lo demás —el perímetro, la detección, la respuesta— sirve para que ojalá nunca haga falta; pero el último eslabón de tu continuidad es ese: una copia intacta y la capacidad demostrada de volver desde ella. Un país entero acaba de comprobar cuál de sus inversiones en IT valía de verdad. Mejor comprobarlo en un simulacro que en las noticias.
Fuentes (verificadas): cronología del ataque a la ANCPI, entrada con credenciales válidas, extorsión fallida y borrado de sistemas y backups — Risky Business News; confirmación del ataque (15-jul), reivindicaciones de ByteToBreach, valoración de KELA, comunicados de la ANCPI (backups en varias ubicaciones, reconstrucción de la red, 20-jul) — Help Net Security; ransomware al registro eslovaco (UGKK, enero 2025), declarado el mayor ciberataque de la historia del país — The Record e Infosecurity Magazine; robo de más de 600.000 registros del Centro de Registros lituano con credenciales legítimas (mayo 2026) — The Record.
¿Sobrevivirían tus backups a un administrador hostil?
En everyWAN mantenemos infraestructura de empresas desde 1996, y las copias que gestionamos hoy son inmutables, con credenciales separadas y con restauraciones que se prueban. La pregunta no es si tienes backup; es si quedaría alguno en pie el día que alguien entre con tus llaves.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN