The OWN-CERT has analyzed the exploitation of a vulnerability, identified as CVE-2024-40711 (CVSS v3.1 Score: 9.8), published in September by the watchTowr teams and targeting the Veeam Backup & Replication software.This blogpost aims to understand how the flaw is exploited and which forensic artefact an analyst could leverage during an investigation.
This vulnerability allows unauthorized remote code execution from simple prerequisites:
- Veeam server accessible via the network (communication on port 6170 (TCP) in a system configured by default)
- Vulnerable Veeam Backup & Replication version <= Veeam Backup & Replication 12.1.2.172
The compromise of a backup server represents a major risk for the entire infrastructure:
- may contain critical data backed up from different infrastructures
- located in a subnet with access to backed upservers
- Using a privileged account due toits intrinsic nature
It can therefore be an entry point for pivoting on the production environment and accessing the critical part of the infrastructure.
For the purposes of this blog post, we're looking at an incident response situation in which the backup server used for Veeam Backup & Replication has been compromised.
The aim is to understand how the attacker was able to take control of Veeam by exploiting the CVE-2024-40711 vulnerability: does the attack leave any traces? Are there any malicious network flows to identify?
The LAB consists of:
- Windows 10 workstation already controlled by the attacker inside the infrastructure, with local admin account.
- Windows 2019 server where the vulnerable Veeam Backup & Replication instance is installed : only logging of connection successes and failures, as well as power shelllogs, have been enabled compared to the default logging policy. (to represent a real environment ;))
- Open Veeam business ports, including port 6170 (TCP)
- Local network enabling machines to communicate with each other
Application logs
By default, Veeam Backup & Replication logs are in two directories:
- C:\ProgramData\Veeam\Backup
- C:\Users\USERNAME\AppDataLocalVeeam
Svc.VeeamMount.log file
The file contains detailed information on the operations involved in mounting backups. These logs are enabled by default in Veeam configuration.
It logs binary deserialization errors, which is the method used by the insecure deserialization exploit.
In this screenshot, we see the logging of a request where the exploit did not work correctly (payload KO...) with the error message:
If the attacker fails in executing the exploit on the first try, it is possible to identify traces of attempts in this log. However, no further information is available: no origin of the query, the content of the command...
Only the date is available, which may indicate a time range that corresponds to the date of the compromise.
Unfortunately, the rest of the application logs do not provide any interesting information for detection.
System logs
The Windows system logs provide us with new information
EVTX files
When the vulnerability is exploited, we see a Windows event associated with a successful connection of type event ID 4264, which tells us something interesting:
During exploitation, a connection is automatically initiated by the attacker, corresponding to a connection without authentication: “Anonymous logon”. Note that the logon type is “3”, meaning a connection from the network.
The “WorkstationName” field contains the value“DESKTOP-E5V3BCH”: this is the machine controlled by the attacker from which he launched the exploitation of the Veeam vulnerability.
Network logs
The vulnerability exploits the endpoint available at the URI /PermanentSessionService, via TCP port 6170 (default) used for communications with a local or remote mount service (MountService). The backup server will exchange data and instructions with the mount server used for restores.
The Veeam.Backup.MountService.exe process is listened to on port 6170 (TCP) via the Windows monitoring tool (real-time).
If we look at the network activity of the process, we can see that during the period of compromise, the network flow was sending and receiving data.
Also, in the “TCP connections” section is an outgoing flow, generated by the Windows server where the Veeam instance is installed (.150), to the attacker's machine (.140) on port 80, confirming successful execution of the payload.
Looking at the network activity, we find two processes that have in common the name of the attacker's machine,DESKTOP-E5V3BCH, in the “Address” column, thus confirming a link with an external machine.
As the MountService.exe service has no direct link to a workstation, this interaction immediately appears abnormal. The legitimate “System” process launched at machine startup also has a flow with the attacker's machine. This seems to be linked to the generation of the4624-connection observed above.
This kind of trace, or consumption of network resources, can be found in the SRUM database (C:\Windows\System32\sru\SRUM.dat) available under WindowsServer 2019, which identifies the resources consumed by the machine's various processes.
Sysmon service or EDR network connection telemetry canal so be a source of data to consult. In our LAB, where an EDR agent is installed on the server, we found two suspicious connections in the server telemetry, filtered over the period of the incident:
Process
When the payload is launched, the subcommand included is executed as a child process of the service being used, Veeam.Backup.MountService.exe,with “NT Authority” rights. In our example, the payload corresponded to the launch of a Powershell command:
The appearance of a “cmd.exe” or“powershell.exe” process as a child of the Veeam process suggests malicious action on the system.
Detection methods
As we have seen from the traces collected, several methods can be used to hypothesize an exploitation of CVE-2024-40711:
Forensic investigation
It is possible to find traces of execution errors in Veeam application logs, if the attacker fails on the first attempt.
The search can be carried out on the “Binary deserialization failed” pattern of the file linked to the affected service “SVC.VEEAMMOUNT.LOG”.
Within Windows events, it is possible to identify successful 4624 anonymous logon connections . Next, look at the hostname field, which may give an indication of the machine used by the attacker. It’s recommended to disabled anonymous logon on the domain to avoid un authenticated access or information disclosure.
The SRUM database is also a resource that can be used to indicate whether streams have been sent to the attacker's IP address via the Veeam.Backup.MountService.exe process.
Real-time (SOC)
One possible method is to identify suspicious child process launches to the Veeam.Backup.MountService.exe process. If“suspicious” processes are detected (i.e. those that can execute or download with), a rule can be lifted:
Using this rule within our LAB, we attempted todetect the exploitation via the use of an EDR installed on the server which sends telemetry back to the Sekoia XDR for centralized logging. The rule set up at XDR level has been correctly applied:
