Comprehensive data protection for all workloads
Post Reply
dsc
Lurker
Posts: 1
Liked: never
Joined: Aug 14, 2020 9:18 am
Full Name: Daniel Cuper
Contact:

A well-known list of veeam file extensions as additional ransomware protection for your repository

Post by dsc »

Hi,
I have an idea for additional ransomware protection for my Veeam NAS repository.
Of course, apart from enabling snapshots, blocking traffic only from the Veeam server, etc.
My NAS allows me to specify a list of files with allowed extensions.
As far as I know, ransomware creates files with its unusual extension.

So I added this list of known Veeam extensions per resource from documentation https://helpcenter.veeam.com/docs/backu ... ml?ver=120
These extensions are: *.vbk, *.vib, *.vrb, *, vbm, *.vsb, *.vlb, *.vsm, *.vlm, *.vom, *.vpm, *.bco

Unfortunately, I got an error on the first backup. It seems that veeam creates some temporary files with strange names and extensions.
Maybe it is described somewhere or someone know all the extensions used by Veeam (even temporary ones)?

I think this very simple method could protect many organizations from having their backups encrypted.
Maybe someone from Veeam support can help? :)

Regards
Daniel
Mildur
Product Manager
Posts: 9830
Liked: 2599 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: A well-known list of veeam file extensions as additional ransomware protection for your repository

Post by Mildur »

Hi Daniel

Welcome to the forum.
If I already have write access to the NAS to encrypt backup files, who stops me to just delete them? Why should I only encrypt such files?

A policy which only allows writing specific file types won‘t protect against attackers.

Best,
Fabian
Product Management Analyst @ Veeam Software
Regnor
VeeaMVP
Posts: 1006
Liked: 314 times
Joined: Jan 31, 2011 11:17 am
Full Name: Max
Contact:

Re: A well-known list of veeam file extensions as additional ransomware protection for your repository

Post by Regnor »

Fabian is right, this will only provide little benefit for security. It might prevent some attack or be useful for monitoring to detect an attack. But at least some of the ransomwares encrypt their files first encrypt and then change the extension afterwards. So in your case the files would still be encrypted.
david.domask
Veeam Software
Posts: 2123
Liked: 513 times
Joined: Jun 28, 2016 12:12 pm
Contact:

Re: A well-known list of veeam file extensions as additional ransomware protection for your repository

Post by david.domask »

Have to agree with Fabian and Max.

I'd like to share what we usually see on the Support side when we get cases after customers have been hit by a Ransomware attack; ransomware attackers have pretty "good" playbooks for getting in, encrypting the production data, and getting out fast, and from what we've seen, the focus usually goes like the below.

Complete disclosure, of course Veeam Support are _not_ security researchers, so take this with a grain of salt, but this is just what we've seen:

1. The attackers usually have already gotten privileged credentials to the entire environment before reaching the backup environment
2. The attackers seems to segregate data into two categories:

- Production Data to encrypt
- Backup data to destroy

The Production data is what ends up with the goofy extensions; I assume this is to give you incentive to pay the attackers for something, and they're pretty good it seems at figuring out where your important data is, since databases, file shares, etc, are usually pretty easy to spot once an attacker is on the system (presumably)

All other data is instead intended to be made unusable (see point 3) so your only option is paying the ransom.

3. Attackers know the file extensions and formats of the most popular backup applications, and also typically just look for "big" files (bigger than a few gig); any file that meets one or both of these conditions typically are treated in then following way:

- encrypt/destroy the first 10-20 MB of data
- encrypt/destroy random portions of the file
- delete the data entirely
- Some combination of the above three points

4. Any removable/remote storages (read: Public Clouds, S3, etc) are attempted to be accessed and messed with as well, depending on the access the attacker has. This is why it's important to heavily lock down access to secondary backup locations and use things like Veeam's Hardened repository to set immutability, or tape-out or use S3 storage. Rotated/air-gapped drives are also pretty fine, but they don't scale very well for larger environments.

Most of the success stories we have from Support with regards to ransomware attacks include either tape, S3, Cloud Connect, or rotated drives. While the data is sometimes a bit older, it's often better than nothing. While we have some potential options for recovery even if such data is damaged, it's never a guarantee and needs to be accommodated for; the more redundant copies you have, the more chances you have to recover from it, assuming the secondary copies are protected appropriately.

My personal take is that Tape has some of the best success rates we've seen; the restores do take some time because of the nature of the medium, but it's still pretty fast. I've also seen quite a few rather impressive restores of a few hundred TB from Capacity Tier; this was mostly "slow" due to download speeds, but such environments were back up and running in full after a few weeks, with the most critical servers being brought up typically within a few hours.

In my opinion, it's best to assume your on-disk backups _will be corrupted_ somehow; they're great for your non-emergency restores for usual outages/data loss you might experience in a modern workplace (server just goes down for some reason, user accidentally deletes some files, admin accidentally types a > instead of a . during an rm -rf, etc), but for proper protection, you must have a locked down and immutable off-site backup, or have proper air-gapped backups or backups on a locked down and immutable device. NAS Devices are great for cheap primary storage, but they lack the protection and security to act as "good" secondary backup locations; iscsi targets are easy to punk (even accidentally!), network shares are not easy to properly secure, and so on.

So this isn't just to dump on your idea Daniel, but more just to be aware that it's not really how the attackers usually work when it comes to backup data. For your production data, file restrictions aren't a bad idea though, and likely can help :)
David Domask | Product Management: Principal Analyst
Post Reply

Who is online

Users browsing this forum: Amazon [Bot], Bing [Bot], foggy, Google [Bot], Mildur, tyler.jurgens and 114 guests