Credit Union Thwarts Cryptolocker Attack With Smart Backup Policy

One of the most pernicious malware threats is the cryptolocker type of ransomware. Organizations infected with this malware suddenly find their critical files encrypted. Rather than give in to demands for payment in exchange for decrypting the files, they may try to restore the files from backups taken prior to encryption. This will result in a loss of any changes since the last backup and possibly lead to delays as the backups are restored.

One victim of this ransomware was a credit union. Their main line-of-business application was taken offline by a single unpatched workstation—a Windows XP machine that was overdue to be decommissioned. Once infected with a cryptolocker, it began encrypting data files on network shares.

The first symptom of a problem was when their primary banking application stopped accepting transactions—for a credit union, the inability to take deposits or give withdrawals isn't exactly a good thing. The application uses a database on a file share. After a little troubleshooting, it became clear that the database had been encrypted. The credit union’s initial plan was to restore the single file by copying it from another machine. The copy was due to complete in two to three hours, prolonging the system outage, so they decided to enact Plan B.

Fortunately, the file server was a VM residing on a SimpliVity OmniCube system. As a critical system, the VM has a SimpliVity backup policy to take full backups every hour. Since it was easy to pinpoint the time of the encryption, it was also easy to identify a backup that was not encrypted. It took only a few minutes to disconnect the partially encrypted VM from the network and then restore a copy of the VM from a SimpliVity backup taken prior to infection. The VM was restored in a few seconds, ready to be powered on. The service was operational within minutes. The transactions that took place after the backup was completed were recovered from their source files on the offline VM and loaded into the restored VM. No transactions were lost and no ransom had to be paid. The IT team even got to go home at the normal time, rather than working through the night to restore from backup servers or tapes.

One key lesson is that frequent backups are important. It’s not practical to perform a “bulk copy backup” during the work day. Copying the whole VM to a backup store would take a significant amount of time and would require a VMware snapshot on the VM for the duration. In addition, each backup requires a significant amount of storage capacity. Restoring the encrypted VM to the previous day’s backup would have made recovering the full transaction history more time consuming.

Using a SimpliVity backup policy, it is possible to take a full copy of each VM every 15 minutes if required. There is no performance or availability impact on the VM while the backup is in progress, and each backup requires only a tiny amount of storage capacity. Another key lesson is that while backups are necessary, it is restoring that really counts. Being able to revert the VM to a known-good state in a few seconds enables very fast return to operation.