On July 14, 2026, an attacker deleted Romania's entire land registry. Not only the live database. The backups too. The country's real-estate market froze for a week, notaries could not record transactions, and citizens could not pull proof of ownership. The records exist today for one reason: the agency kept a copy the attacker could not reach.
What happened at ANCPI
An intruder logged in with valid credentials, mapped the network, and demanded payment. When Romania's National Agency for Cadastre and Real Estate Advertising (ANCPI) refused, the attacker wiped systems and backups, then posted stolen employee credentials, internal documents, and source code for sale on a hacking forum. The incident was first detailed by Risky Business and Cybernews.
Security firm KELA attributed the breach to a known data-leak operator, though Reuters noted it could not independently verify the attribution.
The part that matters for everyone else: ANCPI later confirmed, in a statement reported by Help Net Security, that it stored backup copies across several locations. One of those copies gave it a path to rebuild the network from scratch. Without that offline reserve, Romania would have spent the coming months with no authoritative record of who owns what.
Wiping the recovery layer is the playbook, not the exception
The backups were a target, not collateral damage.
Extortion crews treat the recovery layer as the pressure point. If they can reach your backups, refusing to pay no longer costs you a single live copy. It costs you everything. An extortion demand only works when the victim has nowhere clean to fall back to. It is the same logic behind cloud ransomware attacks that go after snapshots and object storage before they touch production.
And the playbook is spreading fast. AI has not invented a new class of wiper attack, but the latest models have lowered the barrier to running this one. They are good at the parts of an intrusion that used to need people: phishing that reads as native in any language, and credential theft at the scale of a script. It’s AI raising the floor rather than the ceiling. Capabilities that once belonged to nation-state programs now reach ordinary criminal crews who only need to know how to prompt a model. More actors can pull off the valid-credential entry that let Romania's attacker in, which means more attempts on the recovery layer, not fewer.
Romania is not an outlier. Its land registry joins Poland, Slovakia, Greece, Morocco, Russia, and Ukraine, all of which had their land registry agencies hit over the past three years. Public data infrastructure is a soft, high-consequence target, and the attack pattern rhymes across every one of them: get in with valid access, find the backups, remove the fallback.
Our own research shows the same blind spot. In the 2026 Cloud Data Infrastructure Report, 77% of cloud IT leaders worried their recovery environment could be targeted in an attack, yet 90% were confident they would recover from one anyway. Romania closed that gap the hard way. The attacker mapped the backup topology before sending a single demand.
Separation is what actually saved the records
ANCPI recovered because one copy sat outside the blast radius. Every reachable system went down. The copy the attacker's credentials could not touch is what survived.
Steve Stone, Chief Customer Officer at SentinelOne, put the failure mode plainly in a recent conversation with our team: organizations rarely test recovery until they are already inside an intrusion, and when they roll back to a recent snapshot they often "recover the attacker" along with the data.
A copy that lives inside the same trust boundary as production is a copy an intruder with working credentials can reach, poison, or delete. Immutability alone does not fix that if the immutable store answers to the same identity plane the attacker already owns.
Separation gets you a copy the attacker cannot reach. The next problem is knowing which version of it to trust. Ransomware crews often sit inside an environment for days before they act, so the most recent backup can already carry their handiwork. Recover blind, and you can hand the environment straight back to them. A safe copy and a clean copy are different questions, and a real recovery needs both.
The question that decides a recovery is simple. When an attacker holds valid credentials and full run of your environment, what can they still not touch?
What good looks like
A recovery copy earns its name when an attacker with working credentials still cannot reach it.
In practice, that means a few things:
- Isolation. Backups held in a logically air-gapped location, in a separate account from the production estate an intruder moves through.
- Immutability. Copies written so they cannot be altered or deleted for their retention window.
- Detection on the backup itself. Continuous scanning of the protected copies, not live production, for the signs of an attack: mass deletion, sudden encryption, or access that does not match normal use. A poisoned restore point gets flagged before anyone recovers to it.
- A clean point to recover to. Attackers dwell for days before they act, so the newest backup can already be tainted. Recovery has to land on a version from before the intrusion, not after.
Eon runs backups this way by default. An isolated vault in a separate Eon account, read-only access into the customer environment, and recovery scoped to the row and file level so teams pull back clean data without dragging in what the attacker left behind.
Eon also scans the copies it holds rather than live production, watching for the traces an attacker leaves: mass deletions and unusual access across object storage, plus high-entropy encryption and behavioral shifts on VMs. It extends the same pattern-change analysis to cloud databases, flagging abnormal behavior like sudden row-count drops or tables that disappear between snapshots. The result is a clean recovery point you can trust, so restoring does not reintroduce the intrusion.
The copy does not sit in the blast radius, because it does not live where the credentials do. The same posture keeps [recovery predictable during a broader cloud outage], not only a targeted wipe.
Romania's hack needed no novel exploit. Valid credentials and a reachable backup were enough.
The uncomfortable part for most teams is that immutability has become the box everyone checks and the wrong finish line. An immutable store still fails you if it answers to the same identity plane the attacker already controls. The real dividing line is not whether a copy can be overwritten. It is whether the copy sits inside the trust boundary an intruder inherits the moment they hold working credentials.
The gap widens from here. Machine identities and AI agents are multiplying the number of valid credentials moving through cloud environments every quarter, which makes valid-credential access the common case rather than the edge case. A recovery plan that assumes the attacker will be an outsider is preparing for the wrong incident.
So the question our team works through with cloud and security leaders is a practical one: when someone holds full credentials to your environment, what can they still not reach? Teams that can name the copy and prove it sits outside that boundary are in good shape. The ones who cannot have found the conversation worth having now, well before an intrusion forces it.
If that question does not have a clean answer for your environment, talk to an Eon expert. We will walk your recovery posture against the exact failure mode Romania hit, map where your recovery copies actually live, and show you who can reach them today. Fifteen minutes now beats finding out during the incident.
FAQ
What happened to Romania's land registry in July 2026?
An attacker breached Romania's cadastre agency, ANCPI, using valid credentials, then deleted the production land registry database and its backups after a failed extortion attempt. Property transactions across the country stalled for about a week.
How did Romania recover its land registry data?
ANCPI kept backup copies in several separate locations. At least one offline copy sat outside the attacker's reach, which let the agency rebuild its network and restore the records despite the wipe.
Why do ransomware and extortion attackers target backups?
Backups are the victim's fallback. Removing the fallback removes the ability to refuse a ransom, since there is no clean copy left to restore from. Reaching the recovery layer is often the attacker's objective, not an afterthought.
Can immutable backups still be compromised?
Immutability prevents a copy from being overwritten during its retention window. A store that answers to the same identity plane an attacker controls can still be reached, disabled, or deleted through that access. Separation from the production trust boundary matters alongside immutability.
How do you protect cloud backups from stolen credentials?
Keep recovery copies in an isolated, logically air-gapped account separate from production, make them immutable for their retention window, and validate them against the protected copy rather than the live environment. The goal is a copy an attacker cannot reach even with full working credentials.
Primary reporting: Risky Business, Help Net Security, Cybernews, and KELA.
