Handling Malware Samples
When you are first starting out in malware analysis or reverse engineering it can be a very nerve racking experience to deal with malware samples. You might always have that little voice in your head thinking…
What if I double click by accident?
What if I press ENTER when I was not supposed to?
What if the malware breaks out of the VM?
Malware is bad
You don’t want to be infected do you?
If you have these little voices in your head, you are not alone. Almost everyone who has worked in the industry has this little voice bugging them everyday.
This guide will cover the absolute basics on handling malware samples, as well as, how to silence that little voice in your head you hear everytime you start a new analysis.
Making it more “Safe”
The industry will generally use two terms to describe making samples or indicators safe. These terms are neutered and defanged.
The process of doing this is different for samples and indicators.
To make samples safe we will typically store them in a ZIP encrypted archive with the password infected.
mkdir samples mv sample.bin samples/ zip -P infected -e -r samples.zip samples/ rm -rf samples/
For URLs we will typically show them as follows.
This will ensure that the URL cannot be easliy clicked by an unsupecting user.
You will notice that http is replaced with hxxp and . is replaced with [.].
For IP addresses we will typically show them as follows.
Similar to the URLs we simply replace the . with [.].
Now that we have a general understanding on how samples and indicators are made “safe”. We can now discuss how to handle the samples as part of our analysis process.
Typically, when we download samples they will be in a ZIP encrypted format, with the password infected. This version we can download on our host machine as there is nothing inherently malicious about it, it’s encrypted. If you wish to reduce risk even further, you can use another VM to download the malware instead of using your host machine.
Once we have the encrypted version downloaded, we can move the sample to the VM we wish to perform the analysis on.
Now that the encrypted version of the malware is in the VM, we can extract it there by entering the password infected.
Now we are ready to perform our analysis as the malicious unencrypted sample has not touched our host machine.
Understanding the Risk
Just like workers who accept risk as part of their jobs in other industries, there are hazards and risks we all accept as part of our jobs in malware analysis and reverse engineering.
It is up to us to understand that these are risks of this job and do our best to mitigate what is under our control.
Just like anyone on jobs that involve risk, we accept a certain amount of it when we signup to be a malware analyst or reverse engineer.
These risks include but are not limited to.
- Infecting yourself
- VM escaping malware
- Becoming a High Value Target (HVT) for nation-state or criminal groups
You can think of malware breaking out of VMs much like getting struck by lightening, it can happen but it is a very rare occurance.
The possibility of becoming a High Value Target (HVT) for criminal or nation-state groups is why I do my best to separate my personal identity from my independant research. There are times I let people in but it is usually based on a need. Some people may laugh at your hacker handle or alias but in my opinion it is nessassary.
We all accept a certain amount of risk in this industry, other industries also have risk they must accept. Accepting risk as part of a profession is not uncommon. However, the risk we take on in malware analysis and reverse engineering is quite different. If we want to work in this field we must learn to accept a reasonable amount of risk that comes with the job. Again, it is okay to be a little frightened as a reality check is often good for us. At the same time, understand that occurances are usually rare.