oalabs
patreon
Safe Malware Handling and Windows File Associations
🕑 Added 2022-01-18 03:56:53 +0000 UTCIn this tutorial we are going to discuss simple ways to stay safe while handling malware in non-safe environments.
Malware Analysis Environment
The first step is to setup a safe analysis environment using a virtual machine set up with the FLARE-VM tools. Our full Dynamic Malware Analysis Lab Setup tutorial is available here on Patreon.
Make sure to disabled shared folders and disable network on the VM, before analyzing any malware. That's the first step to staying safe.
Safe Option 1 - Isolate Malware In VM
Once you have your VM set up and you want to start actually analyzing malware you will need to be able to get malware onto your VM. When you are first starting out as an analyst the safest way to do this is to download the malware onto the VM directly so that it is never in contact with any environment outside of the VM.
Obviously in your VM, you don't want network access enabled because this could lead to all kinds of problems where malware might escape the VM and make malicious traffic calls outside to your computer and to the internet. We don't want that.
Use the following steps to download malware safely onto your VM.
- Restore a clean snapshot of your VM. Make sure the VM snapshot was taken before any malware was introduced to the VM.
- Temporarily enable your network settings on your VM.
- Use your VM to browse to a sample repository like MalwareBazaar, or Malshare, where it is free to download malware samples.
- Download the samples directly onto your VM.
- Disable networking again.
Safe Option 2 - Safe Malware Handling (Defang The Sample)
Once your analysis skills are more advanced and you are more comfortable looking at malware, it is not practical to only be downloading samples into your debugging VM. Most likely you'll want to have access to those malicious samples in other virtual machines, and hosts like your static analysis virtual machine, or maybe a host where you're writing automation tools. These are hosts that you do not want to have infected by the malware however, you need to analyze malware on them.
In these cases, you will need to understand how to safely handle a malware sample in a non-protected environment. The simplest approach is to take steps to ensure the sample cannot execute in that environment.
If you are working in a non-Windows environment then the OS itself will ensure the sample cannot execute. This is one of the advantages of using a MacOS or Linux host when analyzing Windows malware. However, there may be cases where you need to analyze Windows malware on a Windows host.
In these cases the simplest approach is to remove or change the malware file extension. You could change this to something like .bin. If you've watched a lot of our tutorial videos, you'll notice that we use the .bin extension. But how does this keep us safe?
File Types and File Associations
Start, we need to understand what the file extension actually does. The concept behind this is called a windows file association. Windows has a special way to associate the file extension with a way to execute or open the file. The way this works is a mapping in the registry.
Luckily, the mapping is very easy to understand. If we open up registry editor and go to the HKEY_CLASSES_ROOT key. We can see all of these file extensions listed in the registry. Each one of the file extensions either has a file type associated with it, or no file type.
In the same registry key there are also keys for the file types. Each file type may have a shell open command associated with it which tells the Windows shell how to launch the file if it is double clicked.
If there is no file extension on the file windows will not know what to do with the file when it is double clicked. This is one way that a lot of malware analysts defang file samples when they're moving the files through an environment where they do not want the file to execute.
Another way to keep the file safe from execution is to use a file extension that does not have a mapping in windows. This is why we use the .bin extension. In our environments .bin has no file type association so if it is clicked Windows doesn't know how to execute it.
We use .bin specifically because it is also a default file type for IDA. It's just a quick hack that so that IDA can see the file without having to change the file extension types that IDA is looking for, and at the same time, there's no file mapping for .bin, so it cannot be accidentally executed.
If you want to learn more about file types and associations MSDN has thorough documentation starting with their File Types and File Associations index.
Comments
Karsten Hahn
A very common thing that happens to me: You drag a malware file from explorer to the cmd prompt so you get the path as argument for some command line tool. Then you press enter to execute your tool on the malware and whops, the focus was still on your file in explorer and you would've executed it if you had not disabled that in ACL.
