What happened to your files?
Recently, a new ransomeware named CryptoWall (a variant of CryptoDefense) is making it to the news. This evil piece of malware encrypts a wide variety of file types using a 2048 bit key. After it is done, the victim is reassured that his files “were protected by a strong encryption with RSA-2048” (taken from the malware’s payment “manual”) and is asked to pay a bitcoin ransom of 300$ to 600$ if he wants to see his files in plain text again (what, unprotected!?).
What does this mean?
Like showing to work sick, CryptoWall is a perfect example of when your personal problems become an enterprise problem.
Besides jeopardizing the data of the infected individual, this malware could also hold hostage enterprise data. An infected machine has the potential of encrypting not just local files, but also those stored on remote file servers. Intentionally or not, when this malware goes to work on a victim’s machine, it also reaches mapped network drives. Because mapped drives are a not an uncommon practice, this scenario has serious implications. This is what probably happened in the reported virtual “stick-up” in the New Hampshire Police Department, where an officer unknowingly downloaded the malware. By the next day “there were widespread challenges to the department’s ability to access files” (well it is challenging to read an encrypted file).The malware, using standard file access interfaces is able to obliterate any enterprise file for which the victim has “write access” privileges. While this is bad enough for normal employees, imagine the catastrophic effect of such malware if it infects the machine of a network administrator.
How did this happen?
In order to better understand how this malware interacts with a file share, we ran a sample of CryptoWall (making sure we had a mapped drive on the victim’s machine). We noticed a few interesting behaviors:
First, we noticed is that the malware checks to see if the folder already has a file named “DECRYPT_INSTRUCTION.HTML” – this is the file that is generated in each folder after its files were encrypted. It contains information for the victim on how to pay the ransom.
If the file already exists, the malware skips the entire folder – whew!
If the file does not exist, the malware reads each file and creates a temporary file as buffer. The temporary file has the same name as the original one, with an extension of random 3 letters. The malware than reads a chunk of data from the original file, encrypts it and writes it to the temporary file. The malware then reads encrypted data from the temporary file and writes it back to the original file.
This behavior, when inspected as individual events may be considered ok. The files are being accessed using legitimately granted privileges and in reality many software tools save temporary files before overwriting the original one. But when reviewed in a larger context – the same overwrite patterns repeats for more than a few files it is highly indicative of malicious activity.
What do I do?
Apart from protecting your employers with up-to-date Anti-Virus, a few simple monitoring rules on your file share may prevent this malware from encrypting your data:
- Look for the DECRYPT_INSTRUCTION.HTML file – if it’s being queried or written to then something is probably wrong
- Look for temporary files that are being created & deleted repetitively in a short time frame from a certain machine. One or two is reasonable, but more than that requires immediate intervention
Note: These steps could be automated using technologies such as File Activity Monitoring.
Also, it is always a good idea to back up your data periodically. However, this does not completely mitigate the threat; as you still have to make sure that the data you back up was not already encrypted!