What algorithm should we use:
To prevent users from sharing decryptors, each user's system should be encrypted with a unique password. Asymmetric encryption is very slow, despite offering a good way to confirm each user has the right key when decrypting, so we need something else that’s speed focused. To accomplish this, I would suggest using a Rivest cipher. This is a symmetric cipher and as such is most suited to encrypting large amounts of data with very little overhead. The most recent cipher that is still standing strong and is based on Rivest is AES. It beat out RC6 in the AES competition, so stands to reason that this is the best encryption option currently available. I would generate a new public/private key pair on the C2 server and set the key for the AES encrypted files to be the user's public key and keep the private key safe on the C2 server with a unique ID for the user attached that only their combo can decrypt just as an extra way of verifying. This way, the only thing the attacker has to keep track of is the private key and ID combination. They don’t need to track the public key match up as it would be the only one that could decrypt the users ID. It is imperative that the public/private keys are not generated on the victims machine, as other ransomware has in the past, as this leads to people being able to find these and decrypt without paying. Importantly though, the malware should not touch things in the Windows, Program Files, or AppData folders so as to continue to allow the computer to operate normally aside from personal files being encrypted. Essentially, only non system related files in the users folder and Program Files x86 should be encrypted. We want to leave at least one internet browser safe from the encryption process, something like IE. I would possibly consider just making a white list of known Windows system files and standard folders and encrypting everything else, but that could change system to system and version to version.
Below is a diagram illustrating the victim/C2 communication.
Preventing decryption without paying:
To prevent the user from decrypting without paying, the malware should shutdown the computer so as to prevent the keys used from being extracted from memory. That’s one of the most common ways that forensics experts are able to help victims recover. Additionally, the communication with the C2 server should also be encrypted/verified so as to prevent network logs from capturing the key used for encryption while in flight. Encrypting communication with the C2 has the advantage of also ensuring that we’re talking with the real C2 server and not someone masquerading as it.
The advantage here is the overall simplicity of the design. There’s 3 elements, but really only 2 the attacker needs to know. The attacker has a DB with the encrypted user ID, the public key, and the private key. The public key was used as the key for the AES encryption and then was removed from the clients machine when the PC shutdown after the process completed so as to prevent people from decrypting without paying. When a client has paid, they will submit their user ID online along with the payment details. We’re taking the loss at face value of using one C2/IP with nothing in front of it right now, with the assumption being that we’re in and out in one or two days. This banks on it taking a little while for mainstream vendors to pick up on the IP we chose and flag it as malicious. One disadvantage would be needing to generate an asymmetric key for each client. This could cause issues with scaling. An additional risk is that network logs would show communication with the C2 server, thus giving the victim information on where we would be based out of and law enforcement a lead on how to bring down the network.
Why explore this?
Ransomware is absolutely terrible. Innocent people get affected by this every day and it shuts down critical institutions. It's important to understand though what effective ransomware leverages at a high level so that we as defenders are better prepared. Some readers may recognize elements of this from the original CryptoLocker and, credit where it's due, CryptoLocker was incredibly effective. I think we're lucky that more ransomware hasn't followed in the steps of this, and I think this is partly because it takes a lot of knowledge and organization to effectively implement this at scale.