New ransomware that targets backups. Are we susceptible?

[kjstech]

We are on a security mailing listserv and recieved the following horrible news about a piece of malware that not only encrypts files, but seeks out to encrypt backups as well. Here is the initial copy of the alert:

------

A FBI FLASH Alert related to businesses infected with a ransomware variant known as MSIL/Samas.A has been posted to the InfraGard system.

Summary
The threat of ransomware continues to grow due to the relative availability of necessary tools, as well as the potential for extorting large sums of money. Modern ransomware uses strong encryption to render victims files unreadable until the attackers are paid, often in Bitcoin, and release the encryption keys. In a new scheme, cyber criminals attempt to infect whole networks with ransomware and use persistent access to locate and delete network backups.

------


What are some best air-gapped backup practices to keep our Veeam backups protected from such a dire situation? In the listserv, some people were responding that after they backup to disk, they backup to tape, in which the tape ejects after the backup is written to it. Or another poster copies their backup to external usb storage which is unplugged as soon as the job completes.

We use an Exagrid appliance that takes advantage of the Exagrid accellerated data mover. There is a username and password defined in both the Exagrid and in Veeam. I would imagine that the only way to access the veeam backups would be if Veeam or one of its proxies themselves would become affected. We have two servers that have two nics to access Exagrid. Exagrid is on our 10.250 storage switch (10gbe) along with storage interfaces of VMWare and an NFS backed EMC VNX 5200. These two veeam proxies have a nic in our standard production LAN, and a second nic in this storage lan. Nothing else has access except a physical domain controller that uses this transport (10.250) subnet for "Windows Server Backup" to a utility share on Exagrid.

Is this enough protection? Is my CIO just a little over cautious on this one? I don't think you can be too careful now that the crooks out there are getting tougher. Microsoft states that Ransomware:MSIL/Samas.A is severe. The malware is dropped in the <system folder> as samsam.exe with a key <ComputerName>_PublicKey.xml which is used to encrypt the file in the system. We already blocked exe's by the name of samsam.exe with our AV software, and we created an alert in our ObserveIT application to email an alert if a process runs in this name.

[Gostev]

Well, what is "enough" protection for one company, may not be nearly enough for another... it all depends on the amount of money at stakes behind the data you are protecting. But here are some general recommendations:

1. Any separate storage device that is not directly write-accessible from compromised servers by industry-standard protocols (SMB, NFS) is "good enough" protection from CryptoLocker. But the storage device should use its own set of credentials (not from local directory, and not local accounts of the storage device). Additionally, you want that storage device located off-site. Cloud Connect service provider is ideal for this, and we actually have a recent success story posted on this forum where Cloud Connect saved the user from CryptoLocker.

2. I personally always recommend using tape whenever possible as the last line of defense. Even if it just a monthly export. Tape is true read-only storage that is also much more reliable than disk. I saw tape backups saving companies from worst disasters so many times... and, I also saw every line of comprehensive disk-based protection strategy failing miserably, leaving users with unrecoverable data loss.

[Gostev]

Even more importantly, don't get too obsessed about CryptoLocker specifically. Upset employee deleting all your production data and backups is as likely, really. Storage-level corruption, fire, flood (including beer spill ) are also way more common than most think they are. So, always consider all threats to your data, don't get hung up on specific ones. And looking at the bigger picture, you will see that the only way to truly protect yourself from all threats is to have a read-only backup copy in a secure location off-site. All other solutions are cost/risk compromise.

[dellock6]

Off site AND off line.

[infused]

Off-site is the best bet. For customers not on our infrastructure, we replicate using shadow protect, for this very reason.

[rreed]

2. I personally always recommend using tape whenever possible as the last line of defense. Even if it just a monthly export. Tape is true read-only storage that is also much more reliable than disk. I saw tape backups saving companies from worst disasters so many times... and, I also saw every line of comprehensive disk-based protection strategy failing miserably, leaving users with unrecoverable data loss.

Having walked into a my current position where the company had already invested in dedupe devices and pretty much already abandoned their old tape library, I recommended they buy into a new library to augment their dedupe storage that, at best, had about 30 days' worth of storage, and give us monthly/quarterly/yearly archives, as well as permanent storage for decomissioned VM's. We got into one for relatively cheap and they said why not. One external audit later, the auditors gave us an atta-boy for having the tape storage, sighting things like the crypto-locker that will sit dormant for 3-6 months before waking up and wiping out backups. Well beyond our ~30 days. Having tape backup would get you back to at least *something*, even if it might be a month old, or however depending upon how often you write to tape. So, again, respectfully to all, TAPE IS NOT DEAD. Sorry dedupe sales guys.

[masonit]

Hi Gostev

What are you thoughts about Endpoint backup then? When backup to VBR server you have to open up ports for SMB traffic between EP client and VBR server. Not a ideal solution.

\Masonit

[Gostev]

Hi. That's not entirely correct. Backup from VEB to Veeam backup repository is done through the proprietary protocol. There is no need to open up ports for SMB traffic between EP client and VBR server, as SMB traffic only flows between the gateway server specified in shared folder repository setting, and the share. While source data mover (running on the endpoint) and target data mover (running on the gateway server) chat with each other using the proprietary protocol. So, you're safe until someone builds CryptoLocker that is specifically designed to attack Veeam repositories.

[larry]

Veeam controlling the SAN snapshots would also be safe.

[masonit]

Ok thanks for the info. Seems to be something I have totally missed, my bad. I am trying to find more info about this gateway server thing. Looking at the user guide for VEB but can't find much info about the gateway there. Where to look?

\Masonit

[Gostev]

Veeam Help Center (Technical Documentation) > Veeam Backup & Replication > User Guide for VMware vSphere > Administration > Setting Up Backup Infrastructure > Assigning Roles of Backup Infrastructure Components > Configuring Simple Backup Repositories > Adding Simple Backup Repositories > Step 5. Specify Server or Shared Folder Settings > Shared Folder

[EzE]

Similar to kjstech, I am worried about the affects of a Cryptolocker virus. I'm not as concerned about the machine itself being the source of an infection, but more so an admin getting a cryptolocker that spreads to domain joined machines. Our backup repository is disk on the Veeam server itself. The machine is domain joined, and there is a domain service account used for application aware guest processing. My thought is to remove the machine from the domain and create an isolated admin account, so that regular domain admins don't have access to the backup directory. I would assume my backups would still function since the local veeam install will have access to the machine's directories? I would still use the domain service account for the guest processing. Am I thinking about this correctly? Any more suggestions?

Thanks!

[larry]

I have always used a non domain server for my Veeam servers. Never had an issue besides entering the user name, sometimes you need localservername\localaccount. Sometimes it needs just a localaccout name. I did add the Veeam servers into DNS. I have a Domain Veeam user for the application aware processing but user has no rights to the Veeam backup files or servers. My Domain admins have no rights to the Veeam server, no files shares on Veeam. To restore a file we restore to the desktop and move, lots of files we restore right to the server.

Our iscsi and NFS are one their own subnet with no routing accept to other iscsi and NFS subnets. Veeam has a NIC on this subnet.

Our admins have no internet or email for their domain admin account. All the admin terminals are VMs. They use their non-domain admin account to login to a computer then remote into their admin PC with the Domain Admin account.

[LikenTheVirtual]

We expect to finally get away from tape using this:

https://aws.amazon.com/blogs/aws/glacier-vault-lock

Summary - you can have an AWS vault be a write-once-read-many data store

Was wondering if anyone else has experience with it?

[Gostev]

You're not really getting away from tape by using Glacier, as it is backed by tape as well

[dellock6]

he probably means getting away from having to manage tapes, and let AWS do the management. There are many speculations about what Glacier is using, but as in any cloud service, as long as SLAs are not broken, who cares?

PS: facebook is using blu-ray XL for example, there are some pretty neat technologies available when you reach those sizes...

[Unison]

Hi all,
Wanted to check if this is something that others are doing as an added layer of protection for their ‘online’ veeam backup images….

Do you set the ‘READ ONLY’ permission on your veeam backup files (i.e. right click the folder holding the backup files and tick the ‘read only’ option at the bottom to propagate that to all the backup files within)?
And has anyone tested if this has any impact in stopping ransomware encrypting files – an isolated lab where you have set READ ONLY and then executed some ransomware under a privileged account to see if it gets around the ‘READ ONLY’ permission on the backup files?

We hold our veeam images off site in another location and rotate drives to keep them protected – as well as doing replication to a different host/storage…..but i wanted to see if setting the READ ONLY permission on the veeam backup files is worth doing and adds a road block for ransomware trying to encrypt backup files.

[veremin]

You seem to have implemented already the best protection against ransomware - offsite copies stored on tapes (or sort of tapes in your case). Only such scenarios do guarantee that ransomware would not be able to access backup data anyhow. Thanks.

[ebeltran]

Hello:

In our organization we are concerned about the proliferation of viruses Rasonware, Cryptoware, etc ..

We are concerned that the virus affects repositories Veeam Backup and spoil backups.

At the moment the only solution we are seeing as "definitive" is:
1. Make copies to a device and once the backup is complete put the device OFFLINE.
2. Having multiple devices and do a rotation.

Can anyone recommend brand and model suitable devices to "Media Rotation" and put OFFLINE ?.

Can anyone comment on its strategy to prevent the Rasonware affect repositories Veeam Backup ?.

Thank you very much.
A greeting.

[veremin]

You seem to have followed the general ransomware protection concepts quite well in the described scenario. If possible, we'd recommend usage of tapes (as pure read-only target).

Other considerations are provided above; might be worth reviewing.

Thanks.

[PTide]

Can anyone recommend brand and model suitable devices to "Media Rotation" and put OFFLINE ?.

If you don't want to use tapes you can stick with an RDX storage. Please review this thread for more info on compatibility.

Thank you.

[albertwt]

People,

Does anyone here can share some comments and suggestion that can be used to harden the security of Veeam Backup server, Veeam Repository server and Veeam Proxy server against Cryptolocker

So far in all of my servers I have installed antivirus and not sure what else can I implement to protect against Cryptolocker.

Any help would be greatly appreciated.

Thanks,

[mkretzer]

I wonder the same thing. Especially, can we disable file and printer sharing at least on the central Veeam node? As far as i know Veeam uses that service...

[veremin]

Your post has been merged into existing discussion.

General protection concepts have been provided above.

Thanks.

[meggerz]

1. Any separate storage device that is not directly write-accessible from compromised servers by industry-standard protocols (SMB, NFS) is "good enough" protection from CryptoLocker. But the storage device should use its own set of credentials (not from local directory, and not local accounts of the storage device).

I know this post is a bit dead but hoping to revive it and get some comments on what this actually means It's from post #2 from Gustavo. I don't have my NAS joined to my domain, so why would one "not use local accounts of the storage device"? I have them configured as Veeam credentials for the SMB share I am using as a repository target for backup jobs.

Seems to me my options for authenticating are:
1 - Use local accounts (which I'm doing)
2 - Join my NAS to my AD domain (no thanks!!)
or 3 - Setup a separate LDAP server to authenticate my NAS only

[slos]

He’s attempting to describe an ‘Air Gap’ that Cryptolocker cannot cross. In my experience to date Crypto has the ability only to attack Lettered Drives [Local Disc, Mapped Drive]; a UNC pathed-shared-folder-SMB-Repository would hypothetically be immune to crypto as it is un reachable. As UNC paths can be mapped as a lettered drive [making the files reachable] the second half of the statement is to say that security permissions on the share be provided by a source outside of the local directory a local account perhaps. This is noted as Crypto utilizes the AD/local Credentials of the infected user to read from the drives, write the newly encrypted file, and/or other actions as programmed.

‘Good Enough’ is subjective; although Gostev’s statement to use tape is valid. As I would like to shake the hand of the Crypto Developer who is able to encrypt Read Only tape stored in a safe deposit box a few miles from my production facility.

[zoltank]

What about removing all permissions to the repository expect for the Veeam account?

[WRS2200]

Thanks for the great information! This will help us make sure our clients are protected against this type of threat.

[MOBO]

what is the general thought about configuring FSRM File Screen Manager on the repostitory server to stop ransomware?
i am running all windows server so i have been think about just setup FSRM to only allow VBK,VIB,VRB and VBM on data drive

[Delo123]

Hi Mobo,

This should work on non dedup volumes. Be sure to set to warn first before you really deny access and monitor for a while.
I was thinking Veeam could also keep locking backup files to make sure no other tool can modify the files, but maybe that goes a bit too far...