This week we had an interesting experience and I thought it may help others to share our findings.
Background
We were contacted by a small company (approx 40 staff) who were using Google Workspace quite heavily for file storage. They had a large number of Windows desktop machines using Google Drive to stream/sync files to the cloud. They were using about 15 Shared Drives to manage all the files.
On Monday, they came into the office and discovered that all their files were encrypted by the Venus Ransomware. We are not sure when it arrived in their office but it was smart enough to commence its encryption at 11:50 pm on Friday evening and work through the weekend. Presumably, it was downloaded earlier that week and probably spread silently to all the machines in the office and waited for Friday night to do its dirty work.
Because Google Drive sync was enabled on all machines, it automatically detected the file changes and synchronised them up to the cloud. So not only were all the files on the local PCs encrypted but so were the files in the cloud.
Solution
After a bit of checking, there was good and not-so-good news. The good news is that Google Drive keeps historical versions of files. So all the files that had been encrypted still had unencrypted versions associated with them. The not-so-good news was that you can’t batch restore these older versions, it has to be done manually file by file. And with well over 100,000 files, this was not going to be a simple task.
The solution was to make use of the Google Drive API and a relatively simple 150-line Python script. We were able to create the script in a few hours and test it carefully, and after a few revisions, we were able to set it running on the Drives. It took 5 days to restore all the old versions but ultimately we had a 99% success rate of recovering old files.
Some technical detail
We noticed a few things along the way. Firstly it seems that the virus modifies the files in 2 steps – first, it renames the file with the .venus extension and then it comes back and encrypts it. This resulted in a delay between these 2 steps of up to 5 hours depending on the size of the file. And in fact, it meant that when the attack was discovered and systems were shut down, there were still quite a few files that had been renamed but not encrypted.
Our script required the Drive (https://www.googleapis.com/auth/drive) scope and we needed to enable the Drive API on your account. The approach was to actually delete the latest revision (if it contains an encrypted version) and this will effectively revert the previous revision to be the latest, followed by fixing the file name. In the image above you can see all of the events in the Google Drive activity log.
The other interesting discovery is that Google’s File API is somewhat unstable. It was not uncommon to get “Server 500 Errors” on random files. No matter how many times we tried, the restore just failed with unspecified errors. I would have expected better from Google but that’s what we saw. So it did mean that in the end there was a small number of files that failed the automated solution but were able to be recovered manually.
We can help
If you are in a similar position then reach out to us. We can give you some tips or even help you restore your files.