The ANCPI attack: what the DNSC technical analysis shows, and what to learn

DNSC has published its intermediate technical analysis of the attack on ANCPI (no. T66/22.07.2026). It confirms a double-extortion ransomware attack attributed to the ByteToBreach group, in which a single entry point turned into the complete compromise of the organisation. Below are the facts from the report and — more importantly — what to learn from them. For the press timeline, see also the incident news article.

What was confirmed, in brief

• Attack type: double-extortion ransomware (encryption + the threat of publishing data), attributed to ByteToBreach.
• Destruction: out of 1,083 virtual machines, the attacker deleted roughly 100.
• Affected applications: e-Terra, ePayment, MyEterra, the Owners’ Register, Property Titles, RENNS, the Agricultural Register, the Geoportal and others — effectively the availability of ANCPI’s whole network.
• Recovery: there is no decryptor (neither at DNSC nor in open sources) — restoring service depends on backups.

The attack chain, step by step

1. Initial access (10 July) — through an internet-exposed authentication application (openam.ancpi.ro) that served the payments platform. This was the initial point of compromise.
2. Reconnaissance and lateral movement (13 July) — from the epay application’s virtual machine, the attacker initiated logins to vCenter (the virtualisation management plane) — a session from the production segment into the management plane, a clear sign of lateral movement.
3. Control over virtualisation — on vCenter the attacker enumerated all 1,083 VMs, downloaded binaries and moved laterally over SSH.
4. Encryption — ran the bytetocrypt ransomware binary on several ESXi servers, first obtaining an interactive shell by exploiting the servers.
5. Destruction and exfiltration — deleted ~100 VMs and exfiltrated the Active Directory domain controller (the DC1 machine, copied via scp to an attacker-controlled server), plus the source code of some applications.

What data was affected

• Availability: heavily affected, through the deletion of virtual machines.
• Confirmed exfiltration: the Active Directory domain controller and the source code of some ANCPI applications.
• The Oracle Exadata database: per DNSC, it is unlikely the attacker holds data from it — the published screenshots don’t indicate access to it.

Why it was possible (the root causes)

This is the part every organisation learns from. Per DNSC, the cumulative factors were:

• An authentication application exposed directly to the internet — the single entry point.
• Insufficient segmentation — it was possible to move directly from a production VM to the management plane (vCenter) and on to the hypervisors.
• No MFA on privileged accounts — compromising a single account opened the whole infrastructure.
• Antivirus only on workstations, not on servers.
• Poor visibility: the WAF in front of epay kept logs for only 7 minutes — far below what’s needed, which hampered reconstructing the attack.
• Recovery tied to backups: without offline/immutable copies, restoring after deletion becomes very hard.

DNSC’s conclusion is blunt: the lack of a coherent infrastructure-management policy, weak segmentation and poor credential handling let a single point of compromise become a total compromise.

What every company should do

DNSC’s recommendations, condensed to what matters most:

• Secure internet-exposed applications and place them in a DMZ, separated from the internal network.
• Segment strictly — especially the management plane (vCenter, domain controllers) — so a compromised VM can’t move laterally at will.
• Mandatory MFA on privileged accounts and remote access; apply least privilege and just-in-time access.
• Centralised monitoring (SIEM/XDR) with logs from the hypervisor, Active Directory, firewall, DNS and servers — and adequate log retention (not 7 minutes).
• EDR on servers, not just antivirus on workstations.
• Immutable and offline backups (the 3-2-1 model), tested regularly — the only real safety net against deletion/encryption.
• Periodic security audits and penetration tests to validate the measures.

The first two are usually where we start with a client: an IT security audit shows where you’re exposed, and a penetration test confirms what is genuinely exploitable — exactly the pattern that was missing here.

The takeaway

The incident wasn’t technically spectacular — it was effective because the defences had basic gaps: an exposed application, weak segmentation, no MFA, insufficient logging and no immutable backups. The difference between “one compromised account” and “the whole organisation down” is made by exactly these controls.

Sources

• DNSC intermediate technical analysis no. T66/22.07.2026 on the incident in the ANCPI infrastructure (official document, unclassified).
• The ANCPI cyberattack: the facts, in brief (the press timeline)
• DNSC — the National Cybersecurity Directorate