how did ransomware delete shadowcopies on file server

Question

We had a PC infected with a Ransomware Trojan RANSOM_CRYPTESLA.AC that encrypted a bunch of files on a network drive. We isolated the PC and just restored from backup.

One of the things that happened at the same time was all our shadow copies from the file server were deleted too. This server was not infected - scanned with AV and the special ransomware tool from Trend. The server is Windows 2008R2 with the File services Role and CIFs shares.

According to TrendMicro this trojan apparently runs the following command to delete shadow copies:

 vssadmin.exe delete shadows /all /Quiet

I cant find a way to run this command from the PC and have the shadowcopies deleted from the server.

If i run:

vssadmin list shadows /for=p:

it returns:

Error: Either the specified volume was not found or it is not a local volume.

I cant find any articles/forums to say vssadmin can run across the network to manage a network share.

How could our shadows have been deleted from the File server?

Do you need more information?

Thanks

Answer 1

First it is important to note that you do not know for sure that the event on the client machine is linked to the removal of shadow copies on the server. I would suggest looking in to your event viewer logs for more clues.

With that said; the question remains

How could our shadows have been deleted from the File server?

If you are specifically curious about how it can be done from a remote machine such as the infected client, then here are a couple ways it could have been done:

1) an equivalent of PSexec to remotely execute the vssadmin command on the server.

2) using a powershell script such as this one to remotely execute commands.

3) using the Get-WMIObject cmdlet as described here

Answer 2

After going though the event logs on the File server I found 10 events in a row in the space of an hour saying the following:

Log Name: System Source: volsnap Event ID: 33 The oldest shadow copy of volume G: was deleted to keep disk space usage for shadow copies of volume G: below the user defined limit.

But the next event in the list was the following:

Log Name: System Source: volsnap Event ID: 36 The shadow copies of volume G: were aborted because the shadow copy storage could not grow due to a user imposed limit.

With some more investigation of checking newly written files and asking the other admins, we found that a user had copied a large PST to the drive. There is also a limit for the shadow copies of 9GB. The PST was 8GB and the usual rate of change on the drive is 1GB/day.

Because all the changes were greater than the 9GB limit, the shadow service decided to delete all shadows to make space for the new one. Then the shadow size limit for that drive didn't allow it to make the new shadow. So we ended up with no shadows on that drive.

This happened about an hour before we needed to use the shadows to restore infected/encrypted files. So it wasn't the Trojan that deleted the shadows, it was just an unlucky coincidence. We are now going to do a full review of our backup infrastructure.