Intro to Malware Analysis
It's what I do, mang
Salutations fellow degenerates!
Welcome to this nice introduction to what I (want to) do, malware analysis. I like it. It’s fun. But, it’s not for everyone. If you like this post and think that you may want to pursue malware analysis as a career choice, you should definitely subscribe. My subscriber-only posts are much more in-depth in terms of malware analysis techniques and mannerisms. This post is just a small glimpse into malware analysis: what it entails and how you, as an analyst, would operate.
Let’s define it.
Wikipedia defines malware analysis as “the study or process of determining the functionality, origin and potential impact of a given malware sample such as a virus, worm, trojan horse, rootkit, or backdoor”.
This is pretty straightforward. To break malware analysis down into terms, you are analyzing malicious software. Analyzing it for what, exactly? That depends on what your employer wants.
Let’s say, for example, you work for Mandiant (previously FireEye) on their FLARE team. As federal contractors, you would most likely be tasked with reverse engineering new samples of malware that were found “in the wild”. The term “in the wild” means that the sample is new and not previously inspected. This will be figured out through OSINT/CYBINT. You would first reverse engineer the malware to understand how it works and what/who it would affect, then you would update what needs to be updated, which could range from detection tools (e.g. YARA) to infosec databases. This is known as “threat intelligence”.
Mandiant is a cybersecurity firm under federal contract with the US. They are one of the leading companies in malware analysis and reverse engineering, developing new tools and methods for combating modern malware.
Another, perhaps more common scenario is an instance where you wake up to 500 slack messages. Turns out your company’s network was hit by some kind of malware, and you, as “the IT guy”, have been tasked with dealing with it. You need to quickly figure out what happened, when it happened, and how it happened while simultaneously answering a million slack messages and phone calls about the parts of the network that have been smoked. This is called “incident response”, and it is for people who are on crack.
There is one more, slightly obscure analysis situation is “threat discovery”. You are to reverse engineer a software program or set of software programs in an attempt to break it. Think of this as “bug bounties” such as HackerOne. Many companies will shovel all kinds of money at you if you manage to find bugs and exploits within their programs. You are essentially discovering zero-day exploits that no one else has and claiming a prize for doing so. This is also called “white hat” hacking, but is more related to exploit development. A friend of mine made $10,000 from Valve since he discovered an RCE on the popular FPS Counter Strike: Global Offensive. There is money to be made here if you have the free time!
“What do you do, Brother Crawfish?”
I don’t do any of what I just mentioned. I just like reverse engineering things. I’m still a college student, so don’t think of me as some sort of all-knowing malware analyzing machine. I think I’m pretty badass at it, but please, I don’t know everything. (But I know a lot!)
Toolset
“A poor craftsman blames his tools.” Everyone has heard this quote.
It’s quite accurate in terms of malware analysis as well. You could have all the $$$ tools on the planet, but if you don’t know how to use them, they’re as good as useless.
Virtual Machine (VM)
Every good malware analyst has their toolset. The first thing you obviously need is a VM. The majority of the time when analyzing malware you will be manually detonating it an inspecting its behavior. Malware is a caged animal. Releasing it in an uncontrolled environment is just asking for chaos. A VM environment in which you analyze and inspect malware is called a sandbox.
You should also either turn off the network adapter or set it to host-only so that your network is not affected by malware detonation.
You will obviously need a Windows VM since, as mentioned in the Characteristics of Malware post, the majority of malware that you will come across will be written for Windows. If you have the drive space, multiple different versions of Windows (and different patch versions) are better since you will need to reconstruct the environment in which the malware executed and affected the systems. Mandiant has produced the FLARE VM which automatically deploys several tools into your Windows VM.
Linux VMs are also useful for analysis due to FOSS tools that are written explicitly for Linux. I prefer Remnux since it can be deployed with most of the tools that you would need for quick analysis. However, most any Linux distro will suffice if you’re a Kali maxi.
Popular VM software is VirtualBox and VMWare Workstation.
VirtualBox is FOSS and is pretty simple to use. VMWare Workstation Pro costs $200 is the industry standard, and I prefer it due to it’s “snapshot” ability where you can take a snapshot of your VM, detonate malware, and reload the VM back to when you took the snapshot.
Note that if you use Windows Subsystem for Linux (WSL), you won’t be able to use VirtualBox alongside it as Windows’ Hypervisor has a stroke and won’t work with VirtualBox. VMWare works around this issue.
Disassemblers/Decompilers
Inspecting malware without running it is called static analysis. You do this analyzation with what is called a disassembler. These programs “disassemble” executables and produce assembly code which can be inspected to discover malware/program behavior. Decompilers are capable of converting this assembly into a higher level language such as C/C++. My first paid post goes over disassemblers and decompilers more in-depth.
Popular disassemblers:
IDA Pro ($$$)
Hands down the greatest disassembler and decompiler on the market. It is ungodly expensive (plus they just shifted to a subscription model). If you try hard enough, you might be able to “find” it for free.
They do provide a freeware program, but you are very limited in what you can do with it.
Ghidra (free)
The NSA’s open source disassembler. It is the second greatest gift the NSA has given us, just behind the EternalBlue exploit. It uses the Snowman decompiler for built-in decompilation.
Binary Ninja ($$)
Binja is a popular and quickly improving disassembler. It costs a fair amount of money for commercial use. There’s also a 75% student discount. The Binja team is very involved with the community and responds well to feedback. I’ve never used it, but a friend of mine says it’s worth the money.
Radare2 (free)
For you vim maxis out there. Radare is a terminal-based disassembler. It’s open source and extremely lightweight, but it has a large learning curve since it uses a bunch of keyboard shortcuts (just like vim).
Cutter (free)
Cutter is the GUI version of Radare2. It’s more sleek and nicer on the eyes than Ghidra IMHO.
Decompilers:
Snowman (free)
Open source and embedded into many different disassemblers. It usually provides decent output and is constantly improving.
JD-GUI (free)
Used for decompiling Java programs. Java programs are special as they use a virtual machine (JVM) to run, thus this decompiler is used for them.
Hex-Rays ($$$)
Decompiler optionally included with IDA Pro. Provides incredibly accurate and optimized outputs, but it is extremely expensive.
Debuggers
Debuggers are what are used during dynamic analysis which is the inspection of a program while it is currently running. Debuggers allow an analyst to inspect instructions and the values of memory locations during program runtime. Debuggers also allow features such as “stepping” which has the program perform one instruction at a time. Lastly, debuggers have what are called breakpoints which are memory locations where the program will halt entirely and allow the analyst to inspect behaviors.
There are some instances where malware can circumvent debugging features. This is known as “anti-debugger” malware. A future paid post will go over features of anti-debugger malware more in-depth.
Popular debuggers:
WinDbg (called “Wind-Bag”) is a popular Windows debugger. It is shipped with the Windows SDK.
Another Windows debugger. I prefer Olly due to its built-in scripting engine.
GDB is a Linux debugger. I’ve rarely ever used it as most of my debugging is done on Windows. It is the standard for Linux debugging.
IDA Pro Debugger
IDA has a built-in debugger and can remotely access server debuggers. I once used IDA on Windows to debug a Linux program which I was debugging with GDB under WSL. It worked!
FOSS Windows debugger. I’ve never used it but it seems legit.
Other tools
Other tools that you will probably need:
Your favorite packet sniffer. Will capture inbound and outbound traffic which can be used to inspect how malware communicates externally.
Process monitors to detect if any new processes were created by a malware sample.
Executable header inspector. A lot of information is stored in the portable executable header (called the PE header). I prefer PEStudio.
Used to handle those pesky packed executables. A future paid post will discuss packed malware more in-depth.
A hex editor is a friend to any analyst. You never know what could be hidden in the hex values of a program. WinHex for Windows and GHex for Linux.
Thus concludes this post. I wasn’t about to discuss as much as I wanted to as I ran out of time while writing this. If you have questions or concerns about anything, my DMs are open on Twitter.
The post above is my opinion. Please treat it as such.