Do the most common ransomware programs delete the original files as they go, or in a big bulk delete at the very end?
In addition to Angel's response, As seen in the popular ransomware variations that you mentioned, the encryption is done on a file by file basis where one file is encrypted and then the plain-text version of the file is removed, then the ransomware moves to the next file. It may start parallel threads to encrypt several files but the outcome is the same for our purpose. Let's see how it's done by eda2, Cryptowall and CTB-Locker.
eda2 (Opensourced ransomware)
Let's start with the opensourced ransomware namely eda2 while the author removed the code from github, what it did was like this:
//Encrypts a file with AES algorithm
public void EncryptFile(string file, string password)
{
byte[] bytesToBeEncrypted = File.ReadAllBytes(file);
byte[] passwordBytes = Encoding.UTF8.GetBytes(password);
// Hash the password with SHA256
passwordBytes = SHA256.Create().ComputeHash(passwordBytes);
byte[] bytesEncrypted = AES_Encrypt(bytesToBeEncrypted, passwordBytes);
File.WriteAllBytes(file, bytesEncrypted);
System.IO.File.Move(file, file + ".locked"); //new file extension
}
It starts checking drives and directories recursively passing each file that matches its criteria (file extension is in its predefined list) to the EncryptFile method and the file is overwritten with encrypted version of it.
Cryptowall 4
Cryptowall 4 is analyzed by Cisco Talos and this diagram shows its encryption process:
There are separate threads run by this ransomware, one of them is "DoFilesEncryption" thread which does the encryption part.
After iterating through the folders and finding the files:
At this point the real file content encryption takes place, the original file is read in blocks that are 512 KByte chunks. Each block is encrypted with the generated key, using an AES-CBC 256 algorithm, and written directly to the new file (together with the block size in the first four bytes).
And the deletion is like this:
// Move the new encrypted file name in the old original position, replacing the old one
bRetVal = MoveFileEx(newEncFileName, lpOrgFileName,
MOVEFILE_WRITE_THROUGH | MOVEFILE_REPLACE_EXISTING);
if (!bRetVal)
// Delete the old file in the standard manner:
DeleteFile(lpOrgFileName);
else {
// Rename the original replaced file in the new random file name
bRetVal = MoveFileEx(lpOrgFileName, newEncFileName, MOVEFILE_REPLACE_EXISTING);
}
CTB-Locker
As analyzed here and kinda same as Cryptowall, there's a thread responsible for encrypting files in which this routine takes place:
- The file is moved to a temporary file (%TEMP%\<name>.tmp where <name> is determined by the corehash) using the MoveFileEx API call
- The temporary file is read into memory
- An asymmetric keypair and symmetric secret key are generated
- The file buffer is compressed using the DEFLATE data compression algorithm from the zlib library (which is statically linked against the executable)
- After compression the file buffer is encrypted using AES-256-ECB
- A header consisting of the public key associated with this file and an encrypted infovector is prepended to the encrypted data
- The header-prepended encrypted buffer is written to the temporary file
- The temporary file is moved to overwrite the original file using the MoveFileEx API call with the original file getting a new extension (derived from the corehash) appended to it
Further Thoughts & Wrap Up
As discussed above, files are encrypted on the go and usually overwritten by their encrypted version. Now let's analyze this design. In my opinion, one by one encryption and replacement of files is a superior option.
- Encrypting files one by one is easy to implement
- If the ransomware is stopped midway through operation there's still a chance that some vital files are encrypted and victim is willing to pay
- Extra disk space & complex file removal is needed for bulk encryption and then bulk deletion of files
Remaining silent and hidden is one of ransomware's concerns, one other concern is that they have to be fast. They also have to be simple so the executable is as small as possible.
They target unprotected systems, exploit kits used by these malwares target vulnerabilities in applications like Flash, they also make profit from victims that don't have a back up of their data so usually they don't have to deal with hardened and super secured systems. They simply target unprotected not backed up users. They don't have to be bullet proof to be profitable, they just have to be good enough so sometimes they don't have the best implementation possible.
Now in order to deal with performance issues when encrypting large files, one technique I've seen ransomwares using is encrypting only the first n-bytes of the files. This is usually enough to corrupt most of the files and is much faster than encrypting the whole file. Unfortunately I couldn't find the name of the specific ransomware which used this technique at this very moment.
Catching a Ransomware Mid-operation
Refer to What should you do if you catch encryption ransomware mid-operation? for a background, catching a ransomware mid-operation doesn't necessarily allow you to fully stop it or get all your files back.
Ransomwares don't encrypt your whole filesystem, they usually leave executables intact, so the victim has to open up an image, a document or something of that kind to notice there's something wrong.
Even for a computer savvy person who hasn't done some research on ransomwares it may not be clear what's going on, there could be a handful of reasons why a document is corrupted or isn't opening up (Some ransomwares don't change the files' extensions). Adding this to the probability of someone actually noticing that a ransomware is encrypting their files this doesn't seem to be a major concern.
Even if it was a major concern, instead of bulk encryption/deletion, the malware could monitor users activity while staying hidden doing no encryption and once it finds out that the user's inactive/afk it can start the encryption process.
They will mostly be file-by-file. Thus, if you are “lucky”, you may find yourself with only some folders infected. There are several reasons for this:
Easy to code. Just iterate through every file repeating an encryption routine.
Suitable for external programs. Sometimes the ransomware is using a third-party program that works on files for performing the encryption.
No full-disk issues. Option B would require at least a 50% free hard-disk. How many of you have that space free?
Even if you spotted the ransomware mid-operation, with option A there's a chance that some very important files were encrypted and you would still pay. If the original files were only deleted at the end, that would never happen.
But perhaps most importantly, it allows them to overwrite in place the files.
Which is important both for anti-forensic and «encryption optimizations».
Instead of copying a 100 MB file, they could eg. open the file, encrypt the first 1 MB and save it to the same location in disk (perhaps appending some ransomware-specific data, too). The user is left with a 100 MB ‘encrypted’ file that the original application is unable to open, but only ~2 MB of I/O transfer were needed.
And when you are attempting to make every document in the disk unavailable, that really matters.