Cryptovirus attacking backup files

[frankive]

We have been helping a customer which has been attacked by the cryptovirus on a standalone hyper-v server. They used a local mapped NAS for lokal backup. It has also been decrypted. Luckily they was a customer in Cloud Connect so that did rescue them.

Is it possible that in the future the cryptvirus will be able to also connect to the Cloud repository or is this unlikely? Could a solution be to disable the backup copy job while the job doesn't have to run?

[ortoscale]

Damn, that's for sure a good reason for doing offsite copies. Added to why section

[dellock6]

Hi Frank,
never say never when it comes to Security, but remember credentials for Cloud Connect are stored into Veeam itself, while the repository is not visible in any other place in the Veeam console and it doesn't show up as a reachable resource in the local network. So chances to get infected are reduced to a virus able to grab credentials from Veeam server, and also it should be designed to specifically resemble the connection that Veeam does towards cloud connect. It's not a simple RPC/SMB connection over the network.

Also for local connections, a good solution is to have the NAS not being registered over the network via Active Directory or Workgroup, but have a dedicated user/password that is NOT used anywhere else. When you register this device in Veeam by using this user/pwd combination, you know that only Veeam software can access this device.

Luca

[frankive]

Is the credentials in Veeam encrypted? Hopefully it will

[veremin]

Yes, they are. Thanks.

[larry]

This is why our veeam servers are not on the domain, we have standalone accounts to do backups. This way even domain admins can't read, write, delete, encrypt the files. Also that's why a off line copy is always needed, yes tapes sucks but... The offline copy also protects data from the admin if they went off the deep end. An offsite copy could just as easily of been encrypted if the same user has the rights.

[erth111]

larry, you kind of opened my eyes now. I never thought of this and always added backup server to the domain. I just talked to my colleague and he implemented secondary domain and one direction trust relationship to secure the backup environment. Would really like to get some recommendations on this topic.

[frankive]

Yes, this is pretty intereseting. Would be glad to hear a relally best practice solution from Veean. Maybve there will be a 2-factor autentication to access the repositories somehow at the end? I don't know

[dellock6]

I had this very topic in my pipeline for quite some time, seems it's indeed the right time to start actually working on this one.
But just be advice, there are no "ultimate" practices, security is made usually with "defence in depth" approach, by adding layers of protection solutions at every possible compoents, so anything works actually: 2-factor authentication to veeam server, separated domain, encryption, one-way trusts, and most important as you are learning from this and other topic, offline/offsite copies. All the suggested are good solutions.
The final result is about summing many of them together, and at the same time not creating a frankenstein that is a pain to manage and makes operations impossible.

[y1008946]

Hi, in the recent Veeam newsletter, there was some advice that backup repositories should be isolated.

As there have been cases where the backup repositories have also been infected with the crypto locker virus

How could I isolate our backup locations?

We have a dedicated physical veeam server where the backups are run from and stored, and an off site host with a VM where back copies are stored.

Many thanks

[dellock6]

If the local Veeam server is a single system, you should keep it separated from the AD domain for example, and have tight access controls to the server itself (strong passwords, audit). As the machine is not joined to the domain, infected computers could not open c$ or other disk shares and encrypt the backup files.

For the offsite location, if it's another windows server, you can again keep it as a standalone machine, and simply when you deploy the veeam transport agent, you set username and password to connect to it directly inside Veeam. In this way, basically the only place where login informations are stored is the Veeam server itself.

You can also think about encrypting the configuration backup, so credentials stored in Veeam are not readable without the encryption password.

[y1008946]

Ok thanks Luca.

The offsite server, it is a VM which is a Win 2008 Server. At the moment, the server name is listed in AD.

So I need to log onto the VM, and unjoin it from the domain.

I then need to change the local administrator account password for that server so that it is strong.

In Veeam and under managed servers, find the server and input the new local admin credentials for the server.

Is that server then isolated?

Many Thanks

[dellock6]

It's a start
Then you look for windows firewall configurations, be sure to be up to date with patches, disable and remove unneeded software and services, audit the access to the system, and so on. As said, There are layers of operations you can apply to be secure.

[y1008946]

Ok thanks Luca.

So unjoining the server which stores the backups from the domain, is one level of protection?

Should our DNS server still have an entry pointing the server name to the ip? And should is it ok to point the offsite server to our DNS servers?

One other thing that I thought of was, if we bought a NAS drive, and backed up to it through the NFS protocol, is that an isolated area from a crypto locker?

Many Thanks

[dellock6]

To be honest I'm not a real fan of "security through obscurity", hiding the server just removing the dns entry is useless, as an attacker I just need to test the IP to find the server anyway, and I'd probably scan the ip even before looking at dns entries.

For the NFS, cryptolocker searches for SMB share, but you don't know if in the future there will be other viruses targeting NFS.
My suggestion for any share is to create a dedicated user as the only one authorized to read/write the share, set a complex password to it, don't use any common name for the username, and register this user inside Veeam to access the smb share. No other system in the network will know the credentials, not even the windows system where Veeam is running.

[y1008946]

ok, so just removing the server from the domain wont help much.

Other than the things that I already do like making sure the antivirus is upto date and the windows server is upto date with security patches.

Is there anything I should be doing?

Many Thanks

[guitarfish]

The latest incarnations of ransomware target online backups as well as host systems. This got me thinking about my Veeam backups. I have standard Backup jobs which live on a NAS, and these would probably be susceptible to such an attach. But I'm unsure about my Backup Copy jobs which are hosted on a cloud repository, from a Veeam service provider. Would these be susceptible to being encrypted by ransomware as we know it nowadays?

I'm curious how others are dealing with these threats.

[larry]

I am hoping that the new Veeam B&R standalone console coming in v9 will allow only the Veeam service to have rights to the backup files themselves. The Veeam admins having rights to use Veeam but no file rights. Have not seen 9 but I did think the standalone client should allow this. I see the standalone client connecting though the management network and Veeam and the backups on the isolated network. Should know in a few week when 9 comes out

[dellock6]

Even now in v8, if you do not setup the repository to be accessed by any domain account but just a dedicated account you create locally, and then registered only inside the veeam software, it's a good starting point.
Indeed if the repository is a windows machine it can be still infected and the files encrypted by the ransomware, but this can be prevented by keeping the machine up to date with patches (99% of the infections use already known and fixed vulnerabilities), with a good antivirus on board, and firewall enabled to allow connections coming only from the veeam proxies and server.

In security guys the only safe machine is the one shut down or disconnected from any network, in any other situation you need to accept a percentage of remaining risk, and work to mitigate it and plan for recovery scenarios. That's why tapes and cloud connect are great solutions, they are not in the same domain (meant as failure domain, not AD domain) of the other machines.

[ekisner]

I believe that a group-managed service account would solve a lot of the local B&R repository problems mentioned in this thread.

A domain-joined SMB share could be set up to only allow access via the GMSA; at this point, the attacker must not only use the GMSA credentials (frequently changed, high complexity) but they must use them from a pre-approved location (a B&R server in this case) which means they must have either credentials to an approved server or some form of code execution exploit against said server. The SMB share becomes inaccessible from any other source.

A local resource (we use a collection of iSCSI LUNs) could be set up with NTFS permissions prohibiting all but the GMSA from accessing them. You'd lose the ability to access the drive yourself (because that's kind of the point, in case your credentials get lifted from something like an Exchange server) so you'd suffer some peace-of-mind issues if you like to see your backups, but they'd be more secure. Even the kernel couldn't encrypt the files, with proper permissions.

[TitaniumCoder477]

Perhaps I am missing it... What is the security risk of having the backups accessible only to a specific domain account? For instance, if the SMB share is only accessible to XYZ\backupadmin? In this instance, CryptoWall running under workstation user XYZ\jdoe can't infect \\NAS\backupRepo\ because it is only accessible to XYZ\backupadmin. And techs login to XYZ-VEEAM-SRV to under XYZ\backupadmin to configure Veeam jobs to deposit on SMB repo \\NAS\backupRepo\

Am I missing something?

[ekisner]

Well, the one thing I'll point out is that LSA secrets are incredibly easy to crack. Like... 2 seconds easy. Reversible encryption with a known key. What this ultimately means is that if they gain access to your B&R server through some form of worm, they can grab the credentials that way.

But other than that, no you aren't missing anything. It's a reasonably secure approach. Once they've got access to your B&R server to harvest said LSA secrets it's game over anyways (thanks for playing, hope you had some tape backups kind of game over).

One other thing that you can also do to harden it however is disable interactive logons for your service accounts. Makes it a touch more difficult to abuse harvested credentials. Still easy to do lots of things, but if they are dumb enough to try and log onto an interactive session for something you can nail them there.

[NightBird]

I think with a dedupe appliance repository like datadomain and proprietary protocol ddboost you are safe
I don't think a cryptovirus will "talk ddboost"

But if you need to restore from them... you just have to learn patience !!!

[ita-tomi]

I've dealed couple crypto cases, Cryptowall and Teslacrypt. So far the process has been
a) user click malicious link or email attachment, AV does not react, cryptovirus activates
b) virus crypts files on users computer
c) virus crypts shared folders mapped to users computer, accessible with users credentials
d) admin panics and starts to look virus on server while its really active on users computer

I would start with putting really tight ACL on Veeam SMB share, if the share is on non-domain joined NAS it most likely would have anonymous access etc. Only account Veeam uses should have access and this account shouldn't be used to anything else. Another would be use Windows firewall to limit network access or segment veeam servers into dedicated network segment.

Also admins shouldn't surf on servers and use separate non-admin account on their computers. If admin sufns internet with domain admin account he/she should be slapped really hard.

[lowlander]

Hi,

What are the best practices for protecting repositories against crypto locker ?

Thanks

[mcrape]

Hi lowlander - review the rest of the thread, but one of the big things is to make sure you aren't backing up to a mounted network drive. Veeam can store credentials and mounts the repository as needed, thus not leaving it exposed to Cryptolocker.

If you are using Endpoint, there is also a feature to eject USB media after the job is done.

[rreed]

BTT, please. This came up in conversation at our company as well.