Anatomy of a targeted attack to Veeam server
DISCLAIMER
This analysis is not made with any intent of promoting illegal activity, defamation or any kind of business loss. This analysis is solely made for educational and demonstration purposes, I’m not responsible of any unethical activity performed by any individual or group. By proceeding further to read this analysis you are giving your concern that you are solely responsible for any unethical action that you perform later on and the author has nothing to do with it.
In this light analysis we’re going to look at what are, in a simplistic way, the steps taken by a threat actor in a targeted attack to a Veeam backup server, not for the purpose of replicating it, but to know basics and learn to defend against it. The analysis environment will be equivalent to a small business.
As shared by Madi, you can watch a webinar where a ransomware attack is analyzed:
Step one: target analysis
The first action taken by an attacker is the collection of information about your company. These can be of various types and can be gathered passively through search engines, or actively by directly interrogating the target with scanning techniques. The word "passively" is important: this kind of activity doesn’t lead any alerts in the target's perimeter device logs or SIEM. In essence, you do not know when a threat actor is gathering information about your company.
It can be done through:
Google Dorks (search hacks leveraging the Google engine)
Shodan (search engine for vulnerable devices accessible from the Internet, at the time of writing there are almost 1500 search results with the entry "Veeam". WARNING: any unauthorized interaction with the devices listed by Shodan is ILLEGAL and punishable by law).
LinkedIn (by analyzing job postings or employees it is possible to understand the technologies used)
Enterprise perimeter scanning and DNS queries (active scanning with hacking tools)
Archive.org (temporal analysis of evolution of a site)
Underground forums.
Steps to protect against this are relatively simple:
Don’t share sensitive work material on social media (for example, share photos on LinkedIn from new hires of laptop, backpacks and even, and especially, access badges).
Check from your IT department on a regular basis for sensitive and/or unauthorized information leaked on the Internet.
Do not expose sensitive or unnecessary VMs on the Internet.
Avoid the use of unsecured and uncertified cloud software for file processing.
Do not use work credentials similar or the same as personal credentials.
Second step: contact with the target
After collecting sufficient material on the target, attacker moves to a engage phase where he tries to gain access. It can come from:
a targeted phishing activity, called spear phishing, through social engineering even on non-work platforms
the classic purpose-built spam email, which with the help of AI you can take to incredible levels (have you ever tried to get ChatGPT to write you a dummy email?)
and then move laterally or even deeper until the attacker get access to a WKS.
Or if one of the services VMs is published on the Internet and perhaps not even up to date, it can become a target for attack by exploiting an unpatched CVE. I’m sure this sounds impossible, but at the time of writing with the search keys "RDP" and "3389" on Shodan the results are almost 13000 summed together.
Or again, it’s possible to penetrate inside the network via a vulnerability in the VPN management of the firewall itself, a topic that has been in the news a lot lately.
When the attacker is inside, on a WKS or a VM (for our case let’s says it’s not a Veeam machine yet), thanks to programs like Mimikatz it’s possible to get any activity performed by the user logged in.
It’s also possible to combine all these examples to create a more complex attack: with access to an internal machine, the attacker run a Responder program that will receive NTLMv1/v2 or LMv2 hashes. How? By sending a phishing email with a wrong internal LAN link that will point to a nonexistent resource. There’s, of course, also and advanced version of that with a greater scope of hash management.
And hashes are decryptable by brute force via GPU or by third party services.
Steps to guard against this second step are more challenging:
IT department need to check network status, logs and any generated alarm and take proactive security measures.
Have a strong update policy to solve high-impact vulnerabilities.
Implement a Network Traffic Filtration and SMB signing policy.
Implement current gen endpoint protection current and perimeter protection.
And more…
Step three: lateral moving and server access.
The threat actor is in and with a scan of the network, change to forgotten switches with default credentials, lateral moving and vlan hopping, finds the Veeam server. Then, what happens?
If the server is in the same domain as the production of the credentials obtained through Responder the attacker can do privilege escalation and log in as Administrator to the Veeam server.
If the Veeam Backup and Replication is not updated to the latest release and patch, it may be vulnerable to CVE-2023-27532 and the attacker is able to obtain the encrypted credentials from the configuration database.
If the OS is out of support or out of date, it may be vulnerable to a high-impact CVE and allow access and subsequent privilege escalation.
And when they’re inside the Veeam server, they have keys to the kingdom.
The security measures for the third step require a strong and reliable cybersecurity posture and make planned Vulnerability Assessment or Penetration Test activities critical.
And don’t forget to hardening ALL Veeam servers on your network.
Last updated
