On Friday 10 July 2026 at 15:23, an attacker got a shell on a server belonging to Romania's National Agency for Cadastre and Land Registration. The agency noticed on Tuesday 14 July at 05:45 — more than 86 hours later. By then the backups were gone, around 100 virtual machines had been deleted, and the files on the rest were being encrypted with Black Basta.
The Directorate for National Cyber Security produced a technical report on the incident, reported in detail by the Romanian press. What makes it worth reading is not the drama. It is that the report names the causes, and every one of them is something an organisation decides for itself, long before an attacker shows up.
The chain, one step at a time
The entry point was an extremely outdated installation of OpenAM, the identity and access management platform sitting in front of the agency's applications. The attacker exploited a known critical vulnerability in it, wrote their own commands to the server, and opened a reverse shell from ANCPI's public address to infrastructure of their own — routed over a port chosen to look like ordinary network traffic, so the firewall did not object.
Then the predictable sequence. Password hashes were collected from the compromised system, with a deliberate focus on the development team's accounts, because those carried wider access to applications and infrastructure. From there the attacker looked for a pivot and found the Zabbix network monitoring server — a box that by design talks to everything. Through it they moved across internal network segments that were supposed to restrict exactly that.
By 13 July the entire directory structure had been copied out as JSON files: a 16.4 MB inventory of every workstation and server, a 9.2 MB user database, the security groups, the organisational units, the domains and the group policies. Those files were later posted on cybercrime forums by the actor, who operates under the name ByteToBreach and has been active since June 2025 as an access broker and seller of stolen data.
Only then came the destruction. The attacker located the backup management console and scheduled deletion jobs, removing any route to fast recovery, before taking control of the virtualisation platform, scanning all 1,083 virtual machines, deleting roughly a hundred of them and encrypting the critical servers.
The operational impact was total: eTerra, MyEterra, ePayment, the national agricultural register, the geoportals used by town halls, and the agency's email. Around two million records containing personal data, email addresses and encrypted passwords belonging to external users of the payment platform were exfiltrated, together with network administrative credentials and the source code of internal projects from the agency's own GitLab — including security modules and payment-processing files.
One piece of good news sits in the report: there is no indication that the central Oracle Exadata database was compromised, and the data was being replicated to a second site in Brașov.
The three causes the report names
DNSC's preliminary conclusions are blunt. The scale of the attack was made possible by outdated software, by an internal network with very little segmentation, and by the same administrator passwords being used across multiple systems.
Two further findings explain the 86 hours. The agency's servers had no antivirus installed at all — the Bitdefender licence in use covered employee workstations only. And there was no centralised log collection; the web application firewall retained connection logs for seven minutes. When the response team arrived, part of the evidence had been deleted along with the virtual machines, and part had simply expired.
The report also records that DNSC had been sending ANCPI alerts and recommendations about vulnerabilities in its infrastructure since October 2024. The warnings existed. The remediation did not happen in time.
Where each of these appears in NIS 2
Read the list again and it reads like a compliance checklist written backwards. Article 21 of NIS 2 — transposed in Romania by OUG 155/2024 — requires essential and important entities to take technical and organisational measures proportionate to the risk, and the report's three causes map directly onto four of them: policies on risk analysis and information system security; incident handling; vulnerability handling and disclosure; and policies on the use of cryptography and on access control, including multi-factor authentication for administrative access.
Network segmentation and privileged access management are not optional extras in that text. They are the named measures. An internet-exposed identity platform running a version years out of date is a vulnerability management failure with a documented date and a documented warning. Reused administrator credentials are an access control failure. Seven minutes of firewall logs and no central log server make incident handling impossible, and the 24-hour early warning and 72-hour notification deadlines — Article 23 of the Directive, Article 15 of OUG nr. 155/2024 — are hard to meet when nobody can reconstruct what happened.
What a Romanian public body can check this month
Not a programme. A list of questions someone can answer before the end of October.
- Which services do you publish on the internet, and what version does each actually run? Not the version in the CMDB — the one responding on the port right now. Identity platforms, VPN gateways, mail servers, monitoring consoles and management interfaces first.
- Who holds administrator rights, on which systems, and does any of those passwords repeat anywhere else? Service accounts included: they are the ones that never get rotated because nobody remembers what would break.
- Is multi-factor authentication enforced on administrative access, on the VPN and on remote access to management consoles — with no exception list that has quietly grown?
- Can a workstation reach a production server directly? Can a monitoring server reach every segment? If the answer to either is yes, segmentation exists on the diagram and not on the network.
- Where do logs go, and how long do they stay there? If the answer is "on the machine itself", an attacker who deletes the machine deletes the investigation.
- Where is the backup management console, who can authenticate to it, and is at least one copy of the backups offline or immutable? The ANCPI attacker deleted the backups before encrypting anything, which is standard practice now.
- Do you have a written vulnerability handling process with actual deadlines per severity, and a named person who can authorise an out-of-hours reboot to meet them?
What a test confirms that a questionnaire does not
A self-assessment questionnaire asks whether the network is segmented, and someone answers yes, because the VLANs exist and the firewall rules were written. An internal penetration test answers a different question: starting from one compromised workstation or one over-privileged service account, how far can someone actually get — and does the monitoring server turn out to be the bridge between every segment?
That distinction is the whole difference between the ANCPI network as documented and the ANCPI network as the attacker found it. The same applies to credential reuse, which looks like a policy question until a test demonstrates that one recovered hash opens four systems, and to the exposed-service inventory, which an external attack surface review can build from the outside in an afternoon — the same way the attacker did.
The uncomfortable part of this report is how ordinary the attack was. There was no novel technique and no zero-day. There was an identity platform nobody had updated, a monitoring server that could talk to everything, administrator passwords used twice, and no one watching for three and a half days. Any one of those, closed in advance, would have made the other three harder. For an audit and compliance review under NIS 2, that is the useful lesson: the controls that would have stopped this are the dull ones, and they are already in Article 21.
Sources: G4Media — DNSC report on the ANCPI attack · Go4IT — DNSC interim technical report, 24 July 2026 · Economedia — DNSC director on the attack
The technical details above come from DNSC's report as reported by Romanian press; ClickSecure.AI has not independently verified them. Attribution to ByteToBreach is DNSC's, based on the attacker's own public claims and screenshots. The volume of exfiltrated records and the status of the central database are drawn from the interim report and may be revised in the final version.
This article is general information, not legal or regulatory advice.