The ANCPI Ransomware Attack: A Technical Breakdown

On 14 July 2026, every information system belonging to Romania's National Agency for Cadastre and Real Estate Advertising went dark. Property transactions across the country stopped. Notaries, banks, surveyors and citizens lost access to the national land registry for weeks.

Romania's national cyber security authority, DNSC, published an unclassified interim technical analysis eight days later. It is one of the most detailed public post-incident documents ever released about a European public-sector ransomware case, and it deserves to be read by anyone responsible for a mid-sized network — because nothing in it is exotic.

This is a defender's reading of that report: what happened, in what order, and which control would have broken the chain at each step.

Who attacked

DNSC attributed the incident to ByteToBreach (also seen as ByteToBreach33), based on tooling and the ransom note recovered from an ESXi host.

ByteToBreach is a financially motivated actor that operates simultaneously as an access broker and a trader in stolen data. Open-source analysis cited in the report suggests a single technically capable operator or a very small team, outsourcing certain tasks such as password cracking. Activity dates back to mid-2025 across dark web forums, with claimed victims spanning finance, telecoms, aviation, data centres, payment processors, healthcare, education, logistics and public administration.

The selection logic matters more than the name: targets are chosen by exposure and data value, not by geography or politics. An opportunistic actor scanning for unpatched internet-facing applications does not care whether you are a national agency or a 90-person manufacturer.

We also published an interview with the actor, in which he describes his motivation as purely financial. Read alongside this analysis, the two documents describe the same event from opposite sides.

The attack chain, stage by stage

Stage 1 — Initial access: an unpatched authentication server (10 July)

The entry point was openam.ancpi.ro, an OpenAM/ForgeRock authentication server exposed directly to the internet, serving the agency's online payments platform.

The attacker exploited publicly known vulnerabilities in that component (CVE-2021-35464 / CVE-2024-36401) — the older of which had been public for years. A JSP web shell was written into the Tomcat web application directory, then used to invoke OpenAM's own encryption class and decrypt the application's encryption key. That yielded the administrative credentials OpenAM stored in encrypted form in its configuration.

With those credentials the attacker bound to the OpenDJ LDAP directory behind the platform and queried it, extracting an estimated two million user records — names, email addresses, unique identifiers and password hashes. The identifier format indicated these were external users of the payment service rather than staff accounts.

What would have stopped it: patching, or simply not exposing a legacy authentication stack directly to the internet. This stage is the entire attack in miniature — one unpatched public-facing application, one credential store reachable behind it.

Stage 2 — Expanding on the same host (11 July)

A port scan of the internal segment revealed an unauthenticated Java JMX/RMI management interface on an IBM WebSphere Application Server. A standard Metasploit module against that interface loaded an arbitrary class and produced remote code execution, giving the attacker a Meterpreter session running as the WebSphere service account.

What would have stopped it: management interfaces bound to loopback or a management VLAN, authentication enforced on JMX, and internal service scanning that would have flagged the exposure long before an attacker found it.

Stage 3 — GitLab, and the password that unlocked everything (12 July)

An unpatched GitLab instance was exploited through the well-known ExifTool image-processing flaw (CVE-2021-22205) — a file upload with a malicious EXIF payload, again via an off-the-shelf module — yielding a reverse shell as the git service account.

The attacker then queried GitLab's production database directly and dumped the users table, including bcrypt password hashes. At least one of those hashes was cracked offline, and the recovered password turned out to be valid against the organisation's Kerberos realm.

That is the hinge of the entire incident. One reused administrator password converted a compromised developer platform into credentialed access to the wider environment.

The same access exposed the source code repositories behind the agency's core proprietary systems, including the land registry platform and the national street-naming registry.

What would have stopped it: unique credentials per system, enforced by a password manager and privileged access management; MFA on Kerberos-backed administrative authentication; patching of internal developer platforms, which are routinely treated as lower priority than internet-facing systems and routinely hold the keys to everything.

Stage 4 — Monitoring turned into an attack tool

The attacker reached the administrative interface of the organisation's Zabbix monitoring platform and used its built-in Scripts feature — designed for administrators to run commands on monitored hosts — to open a reverse shell back to attacker-controlled infrastructure. A monitoring system with agents everywhere is, by design, a remote execution framework. It was used as backup persistence.

Separately, the attacker accessed the database behind a FortiSIEM appliance that had been installed for a proof of concept and was retaining no logs. That database stored credentials for a large part of the organisation's network equipment — encrypted reversibly, which meant they could simply be decrypted to plaintext. The extracted passwords revealed the same handful of administrative credentials reused across Juniper devices in entirely different locations and subnets.

What would have stopped it: treating monitoring, backup and security tooling as tier-0 assets — the same protection class as domain controllers. These systems hold universal credentials and universal reach. In this incident they were, in practice, the softest targets in the environment.

Stage 5 — The management plane (13 July)

From the compromised payments virtual machine, the attacker authenticated to VMware vCenter using a domain administrator account. DNSC's logs show repeated attempts starting in the afternoon and a successful login that evening.

The vCenter instance was running version 6.0.0 — years past end of general support. That allowed enumeration through legacy vSphere API techniques, direct browsing of datastores through the web interface, and use of the native Managed Object Browser, all without specialised tooling.

The attacker queried vCenter's own PostgreSQL database and enumerated 1,083 virtual machines with their IP addresses, DNS names and host assignments. BloodHound was run against Active Directory to map the Domain Admins group and privilege paths. The virtual disk of a domain controller was copied out to attacker infrastructure — a standard route to offline extraction of the entire AD credential database.

Critically, DNSC noted that a production virtual machine could initiate sessions directly against the virtualisation management plane at all. In a correctly segmented architecture, that connection is simply not possible.

What would have stopped it: strict separation of the management plane from production networks; a supported hypervisor with modern authentication; MFA on vCenter; alerting on any authentication into the management plane from a production segment.

Stage 6 — Destruction (13–14 July)

The final stage was fast: a ransomware binary deployed to ESXi hosts and executed, encrypting virtual machine disks as they powered down; roughly 100 of the 1,083 virtual machines deleted outright; backups destroyed, including copies of the GitLab server, the accounting system and domain controllers.

The attacker also used the Sliver command-and-control framework — the binary saved under the name auditd to imitate the legitimate Linux audit daemon — and Ligolo-ng for encrypted tunnelling into network segments that were not reachable from outside.

Staff noticed at 05:45 on 14 July.

The number that matters: 3 days, 14 hours

DNSC calculated a mean time to detect of approximately 86 hours between confirmed initial access and the organisation noticing.

The attacker was inside for more than three and a half days, exploiting four separate systems, dumping two databases, mapping Active Directory and staging destruction — and nothing raised an alarm until the encryption itself became impossible to ignore.

The report is blunt about why detection was impossible:

• No antivirus on servers. A Bitdefender deployment existed, but only on employee workstations. The servers running the agency's core applications had no endpoint protection at all.
• Web application firewall logs retained for seven minutes. Not seven days. The WAF sat in front of the compromised payments application and kept almost nothing, which crippled the retrospective investigation.
• No centralised log management. With no central collection, evidence lived on the very machines the attacker deleted.
• The SIEM was a proof of concept holding no logs at all.

Detection is not a product you buy. It is retention, centralisation, coverage and someone watching.

Root causes, in DNSC's own assessment

The report's conclusion is that no single point of compromise explains the outcome. Five structural weaknesses compounded:

1. End-of-life perimeter components. Firewall and WAF running unsupported versions, receiving no security updates.
2. End-of-life virtualisation management. A vCenter release long out of support, enabling legacy enumeration paths.
3. Almost no network segmentation. Production could reach management directly.
4. Systematic credential reuse. The same administrative passwords across applications, virtualisation and network devices, in different sites — so one cracked hash cascaded.
5. No application security testing. Known-vulnerable public-facing applications, unassessed.

Their combined effect: a single initial compromise became a total organisational compromise.

What this means if you are not a national agency

Read the five root causes again and ask honestly how many are absent from your own environment. In our experience the answer is rarely zero — and the four most common are an out-of-support appliance nobody wants to touch, a flat network, shared administrative passwords, and log retention set by whatever the box defaulted to.

Three specifics are worth pulling out because they are near-universal:

Your backups are a target, not a safety net. The attacker deleted backups deliberately, as a step before encryption. DNSC's guidance calls for a three-tier model: operational backup for fast restores; immutable backup using WORM or object-lock storage with a locked retention period of 14–30 days that cannot be deleted early even by an administrator; and offsite backup with 60–180 day retention. Untested backups do not count.

Your security and monitoring tools are among your most dangerous assets. SIEM, monitoring and backup platforms concentrate credentials and reach. Here they stored network device passwords in reversibly encrypted form and offered a scripting engine as a lateral movement path.

Legacy authentication exposed to the internet is the single highest-value target you own. It sits at the perimeter, it holds credentials, and when it is unpatched it hands over both at once.

Mapping the failures to NIS2

If your organisation falls under NIS2, this incident is a preview of what an inspection looks like after something goes wrong. Nearly every root cause maps directly onto a binding obligation under Article 21(2):

Under Article 20, management bodies must approve and oversee these measures, and may be held liable under the applicable national law for failing to. Article 23 would have required an early warning to the national authority within 24 hours of becoming aware of a significant incident, a full notification within 72 hours, and a final report within one month. Given a detection gap of nearly four days, that clock is worth thinking about carefully.

Indicators of compromise

Published by DNSC for defensive use:

Attacker infrastructure

• 194.102.105.193 (Moldova) — exploitation source
• 66.163.118.52, 66.163.118.234 (Spain) — payload staging, reverse shell handlers, exfiltration target
• 104.194.140.38 (United Kingdom)

Tooling

• Sliver implant, saved as auditd — SHA256 3f661a590790cb90966dd89803bfa662abd8aa67bbf4d90e44888a48399597f9
• Ligolo-ng tunnelling agent — SHA256 21ee713585ed802b675b7144f7ebd875573e09809c2dff21e65da3d127fdca71
• Ransomware binary bytetocrypt, found in /tmp/ on ESXi hosts — SHA256 14ed580291658fa6410f4cbb18d9a2f979b93f4ce640c7445d999bcf440492e8

Editorial note on the hashes: the report's summary IOC table lists an identical hash for the Sliver implant and for the ransomware binary, while the body of the analysis gives the distinct value shown above for bytetocrypt. Treat the mapping with care, prefer the body reference, and re-check against any future DNSC revision.

Exploited vulnerabilities: CVE-2021-35464 / CVE-2024-36401 (OpenAM/ForgeRock), CVE-2021-22205 (GitLab ExifTool). FortiSIEM 7.2 in the environment was also affected by publicly documented command-injection flaws.

Frequently asked

How did the attackers get into ANCPI?

Through a publicly exposed OpenAM/ForgeRock authentication server affected by publicly known vulnerabilities (CVE-2021-35464 / CVE-2024-36401). No phishing, no zero-day — an unpatched application reachable from the internet.

Was the national cadastre database stolen?

According to the DNSC technical analysis, no. Investigators found no evidence of access to the Oracle Exadata database holding the core cadastre records, and assessed it as very unlikely that the attacker holds data from it. What was taken included application source code and roughly two million user records from the payments platform directory.

Could this attack have been prevented?

Yes. DNSC concluded the attack succeeded not because of one failure but because of a chain of structural weaknesses: end-of-support perimeter and virtualisation components, almost no network segmentation, password reuse across systems, and no meaningful logging or monitoring.

Does this matter to private companies, or only public institutions?

The failure modes are the same ones found in mid-sized private companies every week. ByteToBreach is opportunistic and financially motivated — it targets exposure, not flags. Under NIS2, most of the controls that failed here are now legal obligations for in-scope entities.

The uncomfortable summary

There was no zero-day. No sophisticated tradecraft. No insider. The attacker used publicly known vulnerabilities, off-the-shelf exploit modules, open-source tooling and one cracked password — against an environment where nothing was watching.

That is what most ransomware looks like. It is also why most ransomware is preventable.

Under NIS2? The free NIS2 Gap Assessment maps your environment against all ten Article 21 measures and gives you a readiness score and a prioritised roadmap.

This analysis is based on the unclassified interim technical report published by DNSC and on open-source reporting about the actor. It is an interim document: findings may be revised as the investigation continues. Technical details and indicators are reproduced for defensive use. This article reflects the information available on the last-reviewed date.