A customer uses Veeam Backup & Replication as their backup solution and stores password-protected backups within this environment. The setup encompasses over 200 virtual servers running on both Linux and Windows and includes a 24/7 production environment.
The customer fell victim to a successful ransomware attack, and upon subsequent analysis, the attacker’s approach was as follows (simplified for clarity):
- Gathering Information (a standard practice), often through social engineering.
- Collecting technical details about the environment.
- Gathering information about various hardware and software vendors used by the customer.
- Infiltrating the network through open RDP ports (leftovers from the COVID-19 era).
- Remaining undetected within the system with very infrequent „call-home“ connections for approximately 7 months.
- Infiltrating the Veeam Backup Server (Simple Deployment, meaning only one physical server was in use).
- Changing the encryption password for the Veeam backups.
- Remaining within the system for an additional 4 weeks.
- Attacking the systems in reverse order of priority (first „less critical“ application servers, then critical systems like Exchange and Domain Controller).
- Demanding ransom.
The customer already used encrypted backups, which protected them against data theft. Additionally, the backup server was not a member of the domain. As far as known, the attacker gained elevated rights through a vulnerability in either the Windows or iDRAC of the server and was able to take over the non-domain server.
The customer did not notice the password change. Why? Veeam does not generate any error messages in this case since the backups still run smoothly. What is not immediately apparent at first glance is that, with the password change, Veeam starts a new backup chain, creating a new full backup.
How could the customer have mitigated this scenario? Here are some examples:
- Additional hardening of the environment (disabling internet access, network separation, etc.).
- Disabling RDP.
- Monitoring local and remote logins with tools like PRTG.
- Using Veeam ONE or similar solutions for anomaly detection.
An anomaly, such as the significant increase in time needed for backup writes when a new full backup was initiated, could have been detected. This could be legitimate if the customer intentionally triggered a full backup or even changed the password themselves. However, a solution like Veeam ONE would detect this anomaly and prompt for review.
As far as is known, the customer had to pay a six-figure ransom but regained operational status after the attacker provided the decryption key.
As a consequence of the attack, the customer rebuilt their entire infrastructure in parallel and cleanly reinstalled all clients, importing only the old database and data after thorough examination into the new system. This resulted in significant costs, also in the six-figure range, especially considering that the project was only fully completed after approximately two years.