Ransomware & Mitigation

Execution Prevention

The MITRE ATT&CK framework was a great place to start to figure out basic ways to try and block this Python script from running. T1059.006 is the technique of using Python in the Command and Scripting Interpreter with recommended mitigations by MITRE that include: Antivirus/Antimalware, Auditing, Execution Prevention, and Limiting Software Installation.

For ease, Execution Prevention was chosen as a first step to mitigation. It would be easy to just disable Python, however, this can impact normal system processes or other applications on the system. Python is an extremely common language used by all different applications and restricting Python completely would not be realistic in an enterprise environment running all different software.

AppArmor is a Linux kernel security module that allows for system administrators to restrict program capabilities with "per-program" profiles. This allows for profiles to be set with different permissions depending on the program. When aa-status was ran on xubuntu, it was found that xubuntu shipped with AppArmor, which meant installation was not needed.

To enable and start AppArmor, the following is executed:

sudo systemctl enable AppArmor

sudo systemctl start AppArmor

We want to create a profile for the ransomware, which in practice would be hard with file names always changing, but in this case, we know its a static file path that the ransomware is dropped into with a static name.

We are going to execute in the command prompt: aa-genproof /home/champuser/Desktop/Ransomware/ransom.py

After this, you actually need to execute the Python script in another terminal. This can be pretty daunting, but AppArmor will use this information to determine what to do.

You will be prompted with the ability to press S to scan for events which will determine what to do, or Finish. In this case, you'd want to choose deny by typing D. However, I accidentally denied the creation of the ransom note with Libre Office instead of the executable by typing too fast which I was not able to figure out how to reverse.

Data Encrypted for Impact is another MITRE technique; however, it only recommends data backups. The recommendation for these backups is to store them off system to prevent adversary access. To accomplish this, pCloud was used as Cloud backup solution for targeted files of interest. In the case of a ransomware attack, preventing client data and organization data from being accessed or manipulated is of upmost importance. It is easy to redeploy systems with their current configurations, but client data being destroyed is not only detrimental for those who own that data, but for the company's reputation. Preventing a PR nightmare is why a cloud storage solution was chosen.

pCloud offers 10GB of storage free and is based in Switzerland, which is also home to many privacy-focused services like ProtonMail. In this case, we are protecting Social Security Numbers which are of interest to our attacker. pCloud was chosen due to its compatibility with Linux and ability to selectively choose what is being backed up. Since our ransomware is modular and allows one to encrypt a directory or file, we can utilize being able to selectively back up directories and files.

Ransomware Overview

The proof-of-concept ransomware we created is made in python. It uses python 3 and the Cryptography library. The ransom.py file is used to encrypt the targeted data and drop a ransom note, while the decrypt.py file is used to decrypt the targeted data.

The ransom.py code accepts a target directory to be encrypted. This location was hardcoded for testing purposes and as it is only a proof-of-concept. The code pulls down a public key from a GitHub repository that is used to be used for encrypting the symmetric key. Then the code generates a symmetric key using the fernet module from the Cryptography library. This is the key that is used to encrypt all the target data. Once the data is encrypted, the public key is used to encrypt the symmetric key in memory, writing its encrypted data to the disk. This keeps the symmetric key used to encrypt the files persistent, but not allowing the victim to decrypt it without the private key.

With both the encrypted symmetric key and the private key, the decrypt.py code can be used to decrypt the encrypted data. This code works reversing the functions in the code of ransom.py. The private key location is also hardcoded into this code, again for testing purposes and as it is only a proof-of-concept. The encrypted symmetric key file has to be passed on the command line with the code. The private key is first used to decrypt the encrypted symmetric key. Once this is done, the decrypted symmetric key is then used to decrypt the files and restore the original content.

The code could be more user friendly, accepting user input either on the command line or as the code runs, making the code more flexible. However, as this is only proof of concept and for testing, we did not find it neccesary to do this.

Reflection - Caitlin

Overall, I found it really interesting to learn about built-in Linux mitigations. When we chose to target a Linux host, I was actually concerned since I wasn’t sure other than backing up what could be done. Python could be used on both Windows and Linux, and it would be easy to just disable Python, but this is also something I did not want to do. Disabling Python can impact other software that depends on Python to run, which is not something that would likely be done in an actual working environment. There may have been others who chose to disable Python, but I did not feel that would be the proper mitigation needed as the first line of defense. AppArmor is also built into XUbuntu I learned and is compatible with CentOS according to their documentation. I chose to add backups as well in case my mitigation ended up failing and as a second line of defense. In the case that we cannot afford to pay the ransom, we need a way to protect client data. Trying to research the best free back-up solution was actually the most challenging for me. Many had space limitations which pigeon-holed me into using one host. This overall was actually pretty challenging since I have never from scratch had to figure out a ransomware mitigation and I know that this is far from perfect. I think this made us have a more practical approach that you would find in the actual industry which made this a really good lab and I wish we had more time to research since it was interesting to apply what I have learned from my internship into my coursework.