According to the FBI, ransomware — the strain of malware whereby files and folders are locked down by criminals and not released until a ransom is paid — is a growing concern. This, coupled with the mass access alerts with FileAudit, has triggered many questions from both customers and prospects on how to detect these attacks with FileAudit.

Given the surge in interest, I wanted to answer some of those questions.

FileAudit plays a strong role in protecting a network against these kinds of attacks, so the following provides an overview of best practice in usage as well as a practical test encryption, including the results. So if you’re interested in using FileAudit to protect against ransomware, read on!

Let’s start by explaining how exactly ransomware works.

An encrypting ransomware will typically come via an email attachment, which is opened by the victim — an unwitting company employee. Through a security exploit or flaw, malicious code is then launched which allows to download and install a program on the victim’s machine.

The program will then contact a remote server owned by the attackers where an asymmetric encryption key pair is generated. The private key is kept on the attacker server while the public key is stored on the victim’s computer. The program can then start encrypting all documents the user has access to by generating a random symmetric encryption key for each file, encrypt the file with this key and add at the end of the file the encryption key encrypted with the public asymmetric key.

It is done this way because encrypting data directly with an asymmetric key is 1000 times slower than with a symmetric key, but in both cases the result is the same. Without the private key it is not possible to decrypt the files.

What this means is that if the victim doesn’t have a backup of all the encrypted files, the attacker will be able to force him to pay a ransom to get the private key.

So how can we protect against such a threat? There are a number of practical measures:

1. Clearly, you should educate your users to not open strange email attachments!

2. You can disallow files with certain extensions in mail attachments (e.g. executable files, type of files unneeded in your business).

3. You should ensure that the programs which are allowed to open attachments are up to date, e.g. if run the latest versions of Microsoft Word or Acrobat Reader.

4. Normal users should be disallowed from being able to execute programs from locations they are allowed to write to (e.g. their document folders). They should only be able to launch programs approved by the administrator. In Windows, this can be implemented with AppLocker.

5. An administrator account should never be used to do basic user tasks such as read email, surf on the internet or do normal office work.

6. Users should only be able to modify files needed to do their work. Files they have no reason to modify should be restricted to ‘read only’ access for them.

7. You should have up to date anti-virus software running on your mail server and on workstations to detect infections and protect against them.

8. You should have a way to detect massive file encryption on your file servers. The sooner you detect an attack the sooner you will be able to stop it, which means less data loss and less work to clear up the mess! This is where FileAudit can help you, in configuring mass alerts.

9. You should have a backup of all your files in a secure place.

(More measures can be found here)

AppLocker is an excellent line of defence, because most malware will not be able to infect a computer if the user is only allowed to run programs, and not write, from the designated folders such as “c:\Program files” and “c:\Windows”.

The difficulty however, is that more and more cloud-based applications run from the user profile in order to be able to automatically update. So the administrator may need to handle many exceptions in the AppLocker rules, depending on what kind of applications users are allowed. The second difficulty is that AppLocker is only available in Enterprise and Ultimate editions of Windows.

So now that we have a good idea where FileAudit can play a role in our defence, how do we configure it?

If ransomware is encrypting files in a folder or share audited by FileAudit, this will trigger a lot of access events in FileAudit and we can use mass access alerts to detect it.

But what kinds of file accesses are generated by the encryption of a file? Firstly, the file content needs to be read in order to be loaded in the memory. Then, the data is encrypted in memory, the encrypted data is written into a new file and lastly the original file is deleted.

In consequence, we should see three consecutive file operations in FileAudit: a read, a write, and a delete. So in order to detect a massive encryption attack on a file server, we should set three mass alerts: one for massive read, one for massive write and one for massive deletion. If we get the three alerts simultaneously we most probably face an encryption attack.

To test this, I developed a small tool to encrypt all files in a specific folder.

Download a tool to test FileAudit's mass alerts. This tool allows you to simulate a ransomware attack.

The tool allows the generation of a folder tree with many files in it. The names of the files in the folder will all match the pattern EncryptMe*.* to avoid any mistake later when I run the encryption task. Files that don’t match the pattern will not be encrypted. There are about 8000 files in the folder.

Once the folder tree has been generated we need to configure the folder to be audited in FileAudit.

Then we can create the three mass alerts in FileAudit filtered by Access Type; respectively Read, Write and Delete.

We keep the default thresholds for now. We will see later if we need to tweak them.

In the alerts added to FileAudit’s monitored paths we specify the star (*), to monitor all audited paths.

When done we save the alert and make sure SMTP settings have been correctly set up in the FileAudit settings.

Note: You can also configure a “single access alert” for file extensions that can be generated from ransomware, such as .cryptolocker. The screenshot below shows a list of common ransomware extensions.

Now everything is ready in FileAudit. We open a session on a workstation with the account Bob, start the encryption tool and specify the folder previously created with an UNC path. Then we hit the Encrypt button.

Immediately we check the root folder and we see that the extensions of the files have been changed, and that if we try to display the content of a file there is only random data.

Then we check the mailbox of the administrator and we see the three alerts as expected. But we also get successive alerts every minute, because the encryption took more time than the latency period (more than one minute in this case).

In FileAudit’s File Access Viewer we see the confirmation of what we suspected. For every file, the file is read, a new file is written and the original file is deleted.

If we take a look at the statistics in FileAudit, the user responsible for the massive encryption is in the Top 5 users and the IP address from where the encryption was done is in the Top 5 sources.

Now that we’ve seen how to detect the attack, let’s see how to stop it. With the release of FileAudit 6, you can now react to attacks to avoid significant damage, using a script that can be created and executed each time a specific alert is triggered.

In this case, you can therefore execute a script to log out the user automatically when the three read, write and delete alerts are triggered. That way, you stop the attack immediately, not just when the IT department intervenes.

We therefore go back to the configuration of our alerts. For each alert, in the execution tab, we configure the script to detect the three alerts like this:

In details, the argument(s) field is:

-UserName {UserName} -AccessTypes {DisplayAccessTypes} -ServerName ‘{ServerName}’ -ComputerName ‘{ClientNames}’

All three alerts must have the same script configured.

Note 1: To download the script, click here.

Note 2: The user account that runs the script must be a domain administrator account because the script closes the user session that triggered the alerts (which is the account running the ransomware process).

The test was successful, but was this simulation similar to a real life attack from an encrypting ransomware?

Some attack descriptions indicate that CryptoWall, which is common and dangerous ransomware, is able to encrypt 230 GB of data in two hours, equating to 30 MB/s.

For example with an average file size of 200 KB, if I encrypt a folder of 7,810 files for a total size of 1.6 GB with the simulation tool, it takes 40 seconds. This equates to an encryption speed of 40 MB/s or 200 files per second (or 12,000 files per minute). Which suggests our tool emulates a similar encryption speed to real world ransomware.

Additionally, ransomware programs are known to use AES 256 bit encryption to encrypt files, as does our simulation tool. So there is no reason why we should get a difference in speed.

The default threshold in FileAudit of 100 accesses per minute will trigger the alert. Of course the average file size may differ, affecting the speed of files per minute that can be changed, but ransomware is known to only encrypt the first MB of big files. As the threshold is 100 times smaller than what we can expect during an attack there is margin to deal with this.

There is also a small detail to mention about the simulation tool. Encrypted files are created with the same file name but the extension .crypt is added. This is specific to our simulation. Encrypting ransomware may have a different behavior. The new file extension may be different and sometimes the names of the encrypted files are also encrypted. This makes it very hard to locate a specific file within all the encrypted files. In any case, this has no effect in the detection by FileAudit.

As a final point here, in the simulation the encryption took place in a single folder audited by FileAudit. But in real life you will need to configure the audit on all folders shared by your file servers, because the encryption of files not audited by FileAudit will remain undetected.