My Malware Analysis Methodology
Malware is any program that is written to cause a kind of harm to a person’s computer, or the person in particular by stealing login credentials, spying, refusing access to, destroying, stealing funds or trade secrets …. Malware is written with the agenda of evil in mind and there is no friendly malware. There are different kinds of malware and they are differentiated by either their method of entry, propagation, or activity. Viruses, ransomwares, trojan horses, worms, rootkits, and bootkits… are different examples of malware.
Step 1: Environment Check
Before working with malware, I make sure I am working in a secure environment where my malware samples can run freely without heartbreaks. In my environment, I make use of VirtualBox for virtualization so I can run multiple operating systems conveniently, and take multiple snapshots and it is free for download. Virtualization also gives me the ability to work in an isolated network. I use a Windows operating system running Flare and REMnux — a reverse engineering vm based on Linux. These operating systems were built for malware analysis and therefore have all the tools needed for me to analyze malware.
Step 2: Staying out of danger — Defang
The purpose of a snapshot is for me to have a clean and safe operating system to fall back on in case of errors or reworking those samples. This is where defanging comes into play. Malware comes loose so handling it should be done tightly. Malware carrying files with a .exe, .jpg, .pdf, or .vbs would be renamed by adding another extension to it making the file .exe, .danger or .jpg, .malz… This way mistakenly opening the malware would be reduced because it won’t open. Care should be taken to not use a known extension to your computer. It is the same thing I do with malicious URLs when reporting, I change https to hxxps and .com to [.]com.
Step 3: Basic static analysis — A glimpse of hope
In basic analysis, I look forward to getting an outward look at the malware. Malicious actors are very skillful in crafting their malware samples and still sometimes leave behind breadcrumbs for security researchers so basic analysis helps me to find these breadcrumbs if any. When malware authors pack their binary, finding these breadcrumbs or taking this outward look becomes blurry. In basic analysis, I use floss to find useful strings in the binary. For ease, when using command-line tools, I output my results to a text file so I search through them.
Basic analysis is very important because it gives you an idea of what kind of malware you might be dealing with. When searching through my floss output containing strings found in the malware file, I like to look for a couple of things like extensions (exe, html, vbs, c, go…), file directories, websites, etc. The result of this phase is what I take into dynamic analysis. I also use tools like Capa for matching the malware with the mitre framework and using Capa’s built-in malware behaviour mapping. Pestudio is another tool worth mentioning.
Step 4: Advanced static analysis — A peep into the author’s mind
Performing only basic static analysis would sometimes not be enough to get a feel of the malware. For performing advanced static analysis, I use cutter. This is a disassembler and it provides me closer to the author’s original code. With this, I get to see the flow of the code and the control statements used in the code. Advanced static analysis gives me a better understanding of the malicious file, what it will be doing and what it will be looking for.
Step 5: Dynamic analysis — Big bang
I perform dynamic analysis several times but before going into dynamic analysis, I take a snapshot of my machine. This allows me to keep my notes and text files intact. Here I harm my malware file by removing the extension I added to it earlier and then I run the malware without an internet connection and then check to see what happens after running the malware. Did my desktop background change? Are there new processes associated with this malware? While doing dynamic analysis, I have procmon running with a filter set to the malicious file, tcpview to see network connections from my host, process hacker to see running processes, and Wireshark listening on REMnux to monitor network traffic. After this, I return to my previous snapshot and I run the malware sample again but this time with an internet connection using the fake internet of REMnux. I test everything from processes to connections again.
Step 6: Dynamic analysis — Navigating through abstraction
Clever malware authors like to be thorough in their evil deeds by using process injection and obfuscating different stages of their malware in dlls written for their malware. I use x64dbg or x32dbg for this purpose as they give you more freedom over the running of the malicious file. x64dbg and x32dbg are both debuggers. x64dbg is used for 64-bit files while 32-bit files.
Step 7: Rule writing — Expose the bad guys
After carefully going through these steps, I then use Yara to create a ruleset to identify this malware sample. In creating my ruleset, I like to use things I know that hardly would change in the malware if the authors decide to create another variant. You can take a look at the rule I wrote to identify wannacry ransomware.
