Anatomy of a ransomware attack in Romania: from VPN to ransom

In February 2024 a ransomware attack on the Hipocrate hospital information system, developed by RSC, affected around 100 hospitals in Romania; the attack was attributed to the Backmydata ransomware. In December 2024 Electrica Group disclosed a cyber attack, later claimed by the Lynx group. Both cases were communicated publicly, including by DNSC, Romania's national cybersecurity directorate.

The lesson is not about group names but about the pattern: modern attacks are multi-stage operations, not a virus that spreads on its own. Below we reconstruct a typical attack, composed from patterns described publicly by CISA, ENISA and incident response teams. It does not describe any specific organisation, but every stage occurs in real incidents.

The most common entry points are well known and boringly repetitive:

• Vulnerable edge devices — SSL VPNs, firewalls and gateways with unpatched public vulnerabilities. They are internet-facing by definition and scanned constantly.
• Credentials stolen by infostealers — an infected personal laptop leaks the passwords saved in the browser, including the employee's VPN account.
• Phishing — an attachment or link that installs a remote access tool. See phishing in 2026.
• Exposed RDP directly on the internet, with weak passwords or no attempt limits.

In our scenario the attacker logs into the VPN with a valid password stolen by an infostealer. The account has no MFA. As far as the logs are concerned it is a normal login — only the time and the country of origin are unusual. Without a rule comparing the login with the user's normal history, nobody notices. The same lack of context means that, for edge devices, the gap between a patch being published and mass exploitation is often shorter than many organisations' monthly update cycle.

Once inside, the attacker encrypts nothing. Several days of quiet work follow:

1. Discovery: enumerating the Active Directory domain, file shares, backup servers and installed security tools.
2. Privilege escalation: dumping credentials from memory, exploiting a local vulnerability or finding a service account with an old password and admin rights.
3. Lateral movement: using legitimate admin tools (RDP, PowerShell, remote access software) — the traffic looks like an administrator at work.
4. Persistence: creating new accounts, scheduled tasks or services, so they can come back if partially discovered.

Before the final blow the attacker prepares the ground: disables or uninstalls EDR wherever possible, deletes shadow copies and attacks the backup servers — domain-joined backup consoles are a favourite target. Then they exfiltrate data to an external storage service. This is the double extortion model: even if you restore from backup, the threat of publishing the data remains.

Encryption itself is usually launched outside business hours — at night or over a weekend — simultaneously on as many servers as possible, hypervisors included. In the morning users find renamed files and a ransom note with a link to a negotiation portal.

Hence the practical rule for backups: at least one copy must sit outside the reach of a compromised domain administrator — offline, on disconnected media, or immutable for a set period. The backup console should not use the same accounts as the rest of the infrastructure, and alerts about deleted jobs or shortened retention must reach a person, not just a log nobody reads. A good maturity indicator: how long it takes you to fully restore a critical server, measured rather than estimated.

1. Isolate, do not power off: disconnect affected segments from the network and block VPN access, but avoid abruptly shutting servers down — memory may hold evidence and, sometimes, keys.
2. Preserve evidence: firewall, VPN and Active Directory logs, the ransom note, samples of encrypted files. Record every action chronologically.
3. Activate the response plan and the team: IT, management, legal, communications, possibly a specialised incident response firm.
4. Notify: for NIS2 entities — early warning within 24 hours, incident notification within 72 hours, final report within one month; if personal data is affected, notify the data protection authority within 72 hours under GDPR.
5. Restore from clean copies — offline or immutable — after you understand how the attacker got in, otherwise you risk restoring their access too.

The concrete steps for notifying DNSC are covered in the step-by-step DNSC notification. CISA's #StopRansomware guide contains a full response checklist.

None of these is new or expensive. Do you have them all on paper? Then the right question is: when were they last verified? A backup that has never been restored is a hypothesis, not a control.

Authorities consistently advise against paying. Payment does not guarantee a working key, does not guarantee deletion of the exfiltrated data and funds the next attack. Before any discussion, check No More Ransom for a public decryptor for your variant, consult legal counsel (international sanctions may restrict payments) and inform the authorities. Above all, do not decide in the first hours under pressure: restore options often turn out better than they first seemed.

These decisions are management's responsibility — see management liability under NIS2.