Skip to main content

I’m really happy to share with the Veeam Community this Open Source Project Called Veeam Decoys. 

 


It is public knowledge that multiple threat actors use various tactics and techniques to identify services when they are already inside the internal networks of the organization they are attacking. In fact, the Mitre ATT&CK Enterprise matrix has two complete tactics, "Discovery" TA0007 and "Lateral Movement" TA0008, which list and explain multiple techniques and tools used by attackers. For example, the most sought-after services within the internal network are Remote Desktop Protocol and SSH. If we review Coveware's reports from this year, in the Q1-2024 report, we can observe that the "Lateral Movement" tactic ranks third among the most used tactics by threat actors according to the percentage of cases:
 

https://www.coveware.com/blog/2024/4/17/raas-devs-hurt-their-credibility-by-cheating-affiliates-in-q1-2024

If we review the same report, but for Q2-2024, we can see a significant rise in the "Lateral Movement" tactic, which moved to second place among the most used tactics by attackers:

https://www.coveware.com/blog/2024/7/29/ransomware-actors-pivot-away-from-major-brands-in-q2-2024

Furthermore, attackers will always try to block or destroy data or service recovery by encrypting all data, including backups. This is why it's always important to follow Veeam implementation best practices as well as apply the 3-2-1-1-0 rule, with a focus on data immutability.

After implementing best practices, we will review the following open-source project that aims to help detect connection attempts, scans, or more specifically, the "Discovery" and "Lateral Movement" tactics used by attackers in different networks or VLANs of the organization. This is to identify early on if attackers are searching for Veeam services with the aim of destroying backup data.

The Open-Source project is called Veeam Decoys and can be found at:

 

https://github.com/VeeamHub/veeam-decoy

 

Which has the following Veeam services configured as decoys:

  • Veeam Backup Server
  • Veeam Hardened Repository
  • Veeam Windows Repository
  • Veeam Backup Enterprise Manager
  • SSH
  • Remote Desktop (RDP)
  • Netbios

These services can be implemented in different networks or VLANs within the organization's internal networks. These decoys are not just open ports but have the unique feature of functioning as if they were productive Veeam services.

Which hardware does it require? Very little, in fact:

OVA:
Processor: 1 vCPU
RAM: 2 GB
Storage: 50 GB
Network: 1 GB / VMXNET 3
Hypervisor: vSphere 8.0 or higher.

Manual Installation:
Operating System: Minimal installation of Rocky Linux 9.4
Processor: 1 CPU
RAM: 2 GB
Storage: 50 GB
Network: 1 GB / 10 GB
Firewall: Disabled
SELinux: Disabled

The OVA Appliance can be downloaded from:

OVA Download: https://dl.24xsiempre.com/DecoyV1.ova

It's worth noting that the OVA supports vSphere 8.0 or higher. In case you have an earlier version of vSphere, it's possible to install manually.

For manual installation and OVA steps, you can find them at:

Documentation Download: https://dl.24xsiempre.com/Decoy_Manual_EN.pdf

Due to its low hardware resource requirements, it's possible to deploy multiple servers or Appliances in different networks with various services.

To perform functionality tests after deploying the OVA or manually installing the decoys on an already installed Rocky Linux 9.4, it's only necessary to run scans against the IP addresses of the configured server. One of the most used tools is Nmap, which can be installed on Microsoft Windows, Linux, and macOS. To download Nmap:

https://nmap.org/download

Choose the version according to the operating system being used and execute the following command:

nmap -p 1-65535 -T4 -A -v -Pn -sS 20.20.20.84

 

You can also use "Zenmap," which is the graphical interface for nmap on Windows:

 

 

What does the nmap command mean?

 

-p: The port range to scan, in this case we're scanning all TCP ports

-T4: To improve scan performance by assuming a fast network is being used

-A: Aggressive scan including OS detection, version detection, etc.

-v: Verbose

-Pn: No Ping

-sS: TCP SYN scan

And of course, the decoys detect the scan:

 

 

So now we know how to scan and that our decoys detect scans or connection attempts. However, in the previous example, it was just one machine with multiple decoys and ports, so it's not very credible for threat actors inside the internal network that this is a real Veeam server.

The recommendation is to always use multiple network interfaces on different VLANs or multiple virtual/physical Appliances, also with multiple network interfaces. This way, we can broadly cover the detection of "Lateral Movements" across the VLANs or networks you have, and not all ports will be associated with just one server. Additionally, to present the decoys as productive services, associate them with the internal DNS to the decoy. For example, if the IP address 20.20.20.84 is associated with the VBR decoy, the internal DNS should be vbr.yourdomain.com or veeam.yourdomain.com.

 

As always, if you want contribute or need to solve doubts, pelase create a issue in Github.

Thanks a lot for this ​@Marco.Escobar

but the email functions didn´t work for me

put the same smtp username and password into a smtp test tool & it works fine!

any recommendations?

thanks

best, Lukas

 

 

Hi Lukas, please update the file TUI/hnp_tui.py from github, recently I added an option to test the smtp config from the terminal interface.


Thanks a lot for this ​@Marco.Escobar

but the email functions didn´t work for me

put the same smtp username and password into a smtp test tool & it works fine!

any recommendations?

thanks

best, Lukas

 

 

Hi Lukas, please update the file TUI/hnp_tui.py from github, recently I added an option to test the smtp config from the terminal interface.

 

Hi ​@Marco.Escobar 

i´ve already done that

i´ve tried it with a smtp tool in the same subnet on a windows vm and it works perfect

did the same on the veeam decoy 

i don´t know where to check why it´s not working

also tried it with different smtp accounts

any recommendations?

best

Lukas

 


Thanks a lot for this ​@Marco.Escobar

but the email functions didn´t work for me

put the same smtp username and password into a smtp test tool & it works fine!

any recommendations?

thanks

best, Lukas

 

 

Hi Lukas, please update the file TUI/hnp_tui.py from github, recently I added an option to test the smtp config from the terminal interface.

 

Hi ​@Marco.Escobar 

i´ve already done that

i´ve tried it with a smtp tool in the same subnet on a windows vm and it works perfect

did the same on the veeam decoy 

i don´t know where to check why it´s not working

also tried it with different smtp accounts

any recommendations?

best

Lukas

 

In /var/log/hnp/ you will find the logs of tui open it and search the smtp error.


Thanks a lot for this ​@Marco.Escobar

but the email functions didn´t work for me

put the same smtp username and password into a smtp test tool & it works fine!

any recommendations?

thanks

best, Lukas

 

 

Hi Lukas, please update the file TUI/hnp_tui.py from github, recently I added an option to test the smtp config from the terminal interface.

 

Hi ​@Marco.Escobar 

i´ve already done that

i´ve tried it with a smtp tool in the same subnet on a windows vm and it works perfect

did the same on the veeam decoy 

i don´t know where to check why it´s not working

also tried it with different smtp accounts

any recommendations?

best

Lukas

 

In /var/log/hnp/ you will find the logs of tui open it and search the smtp error.

got it, cheers


Nice idea. Another piece to improve the overall security.


Very interesting project here and I will be investigating this to see how it can help our company.  Found this via a blog by ​@benharmer which was also great.  Thanks for sharing this one. 👍🏼

 
 
 

I’ll definitely install it to test. Thanks!!


Comment