CryptoLocker

In 2014 when CryptoLocker was first launched, we had a healthcare client get infected. The infection took one of their offices offline for several hours while we located the infected machine, restored files from snapshots and backups, and restarted services.

We performed an after-action review and came up with an initial plan for rapid identification and response to the virus. Our support staff used the new plan a few weeks later when the client was infected again. We were able to bring the office back online in about an hour, but we still weren't happy.

Our engineering team was brought in to come up with a solution to provide better detection and response, reduce downtime, and prevent data-loss.

Engineering identified several important targets: detection, isolation, and remediation. We needed a way to detect the presense of an active virus on the network first and foremost. Once that is accomplished we can take steps to isolate it. Isolation is achieved by removing the infected computer from the network and re-imaging it--a process that takes about 30 minutes. Once the virus has been isolated, any 'damage' must be cleaned up--restoring encrypted files for example.

Human identification of the virus was easy. The virus would attack a fileshare and leave behind any number of files containing strings like 'DECRYPT_INSTRUCT' or 'README_TO_DECRYPT'. We could easily automate that, but in Windows 2008 our options were limited and time consuming. The engineering team recommended and migrated the corporate-wide fileshare containing hundreds of thousands of files from Windows to a Linux Samba server. Linux also had to take over the duties of file replication between the sites since Microsoft's Distributed File System Replication only works under Windows.

Once the migration was complete, the engineering team turned on several of the auditing features in Samba as well as using features of the kernel to detect file read and writes. The team came up with a simple and automated script to detect variants of CryptoLocker as well as 'suspicious' file access and identify which user and IP address was attempting to infect the server. When the script detected these conditions, it would immediately notify IT staff.

After coming up with an automated process for identifying an active virus, engineers set about isolating infected devices. The identification scripts could identify the IP address, user, and MAC address associated with the infection. That made the next several steps very easy. We automatically lock out the user account and then locate 'walk' the switches at the affected site to locate the MAC address of the machine involved. We then disable the port, kicking the workstation offline. A technician is alerted so they can call the customer and inform them of the problem as well as schedule swapping the PC out with a fresh one from our provisioning network.

Now that the virus has been isolated and identified, we needed to focus on repairing the damage. Thanks to the previous solution of migrating to Linux, the solution was already there. The detection and isolation scripts worked so well that the virus never managed to encrypt more than one directory of files before we caught and stopped it. And in any case where the virus might go undetected, we have the amazing snapshot, cloning, and recovery tools available in several Linux filesystems to quickly restore the data.

Due to the success of our solution, we were able to detect and isolate most infections within a minute of the customer downloading and launching an infected attachment. This allowed us to stop being reactive to CryptoLocker and become proactive.

In the past, customers would call us in a panic that their files were encrypted, they were down, and they were losing money.

Now our teams are already starting to analyze, react, and recover from an infection by the time a customer calls.

Our healthcare customer was repeatedly attacked over the several years, but they rarely have downtime and have yet to lose data.

While Microsoft has been improving the 'File Screening' in Windows, we already have the solution deployed under Linux and FreeBSD and have not found a compelling reason to switch back.