Scan for malware before / after restore (?)

  • 13 September 2021
  • 4 replies

Userlevel 2
Badge +8

Hi, In case of a ransomware attack (which I hope will never happen), what is the best way to determine what is the last good backup on disk that I have and that is suitable for restore (not encrypted by hackers or contaminated by malware)? Do I need to do a restore in an isolated environment and then run antivirus until I have found the last “good one” :relaxed: ? Or is there a better way? I have heard that malware can already be on servers weeks before the actual attack or whatever. Thanks


Best answer by DMCVault 14 September 2021, 05:18

View original

4 replies

Userlevel 7
Badge +23

I’d love @DMCVault to chime in here as he was working on some interesting tech like live mounting VMs and performing malware checks. You can do that today by stringing a few things together with workflows, but it was being somewhat automated.

File monitoring is a good start for physical clients - it should be enabled by default and places a honeypot file on the client. When it gets modified it will trigger an alert in the CommCell and you know your prior backup should be good.


But a good way is to simply check the size of your backups. When malware encrypts your data, it wont match previous signatures and should result in a much higher backup size, especially on an incremental. That is a good sign that the backup contained changed (presumably encrypted) data. Commvault has built-in size anomaly alerts as well to detect this, but you should also see it in the job history.


Userlevel 5
Badge +8

The unusual file activity dashboard provides insights into anomalous data changes, then allows you to recover pre-anomalous data automatically.  This is available in 1123 and above.    We have big plans to expand on this even further with more workloads, deeper threat analysis capabilities and other monitoring insights.


We do see a common thread with our customers wherein after ransomware containment they would recover to an isolated environment to scan and validate before moving into production.   This is why we are putting focus on data change insights that help drive more efficient recovery scenarios.



Userlevel 7
Badge +19

As @Damian Andre already pointed out one of the observations you would see in case of a ransomware attack is unexpected growth in written data. So upon detection and start of recovery this is something to take into account. 

@Damian Andre you were referring to the honeypot method. Now this is as far as I know "dummy” data located in the software installation folder. Now most of the times this folder is located out-side of for example the reach of the share data of your file servers. Do you happen to know if there are possibilities to configure an alternate location e.g. to dedicate user defined dummy data as sensors. 

Our experience with the recently introduced "Unusual file activity” feature are not that great. It is to trigger happy and we already opened a few ticket related to performance issues. Now I hope this is still work-in-progress and that we can expect enhancements. Instead of monitoring how it is currently done I think really looking at the data would deliver more targeted information e.g. find ways to really identify that ransomware is active, 

Userlevel 7
Badge +19

B.t.w. to test it yourself you could think of writing a script that generates dummy data with know file types followed by a registration of the file checksum. Now create backups continuously and restore the data afterwards and recheck the checksum once more. In case of a change you send out an alert. The script execution can be kicked off using pre/post script execution.