Lots of children break things not because they are little evil creatures but because they are curious about “how it’s made.” Eventually, some of those children grow up and become Cybersecurity Analysts. They do basically the same but in an adult world.
Malware analysis is the process of studying a malware sample to understand what it’s made of and how it works. Sometimes you never know unless you try, so you need to actually run the malware. And sometimes, it’s necessary to thoroughly examine the code line by line without triggering the execution.
Of course, learning what is malware analysis brings many benefits. Knowing the enemy means knowing the ways of winning over. It means that Malware Researchers help their SOC teams to come up with more targeted detection algorithms, as well as improve their incident response.
The exciting part is that modern malware is getting more and more sophisticated. Often Security Analysts have to study something that they don’t have access to. If ten years ago malware could be defined by one executable file, right now, one file is only a beginning of a journey. Let’s dive a bit deeper into malware analysis and see how to do it.
It’s easy – you can start malware analysis after you obtain a malware sample. Organizations that employ a Defense in Depth approach have multiple tools and processes in place to regularly find new samples. Some analysts will tell you that they haven’t seen anything conceptually new for years, while others will admit that they have new malware samples approximately every month. It all greatly depends on the research depth.
Analyzing malware might consume a lot of time; that’s why many SOC teams prefer not to go that deep. However, the time spent on research definitely pays off because it’s never too late to improve the security posture.
Malware analysis can be conducted in different ways and with the use of various tools. There are three major analysis types:
To figure out how to analyze malware that you have at hand, try to answer a few questions first:
If you’ve got a sample of a malicious file, you can perform static analysis. However, if this file is designed only to launch further stages of a kill chain, the static analysis won’t show how the main payload executes. And sometimes, the only way to find this out is to run the malware in a safe environment. So, let’s see how to perform different types of malware analysis and how they might be useful for a Cybersecurity Analyst.
Dynamic malware analysis can be performed either in an automated sandbox or on a VM where you can test the sample manually. Keep in mind that sophisticated malware will look for signs of being in an emulated environment, and automated malware analysis is not the best option in this case.
Just like any other software, malware can be programmed to do practically anything that a code can do. So you want to understand what the code (as a set of instructions) does and what’s the logic behind it.
For example, some security tools inject their DLLs into local processes. The malware will scan the environment, and if it finds these files – it will terminate itself. Other than this, malware scanners will look for:
As the name suggests, dynamic malware analysis is all about observing the malware in action. You want to interact with it in as many ways as possible and create a full picture of its functionality. To do that, make sure that you use a fully isolated environment; it should be disconnected from the Internet, run on a host-only network, and the VM must not share any folders with the host.
Even though debugger evasion scanners are present in many malware samples, Security Researchers do use debuggers in dynamic malware analysis. These tools are good for identifying risky API calls and memory allocations. If the malware actively uses fileless techniques, it won’t be visible in the static analysis since it works through legitimate processes – no exploit needed.
For example, a code injected into PowerShell allocates memory in powershell.exe and executes an obfuscated code in a new thread (which spawns a trusted process via Process Hollowing):
Inside the debugger, you will be able to see how the code runs through all the instructions that it’s programmed to execute. Don’t forget to check strings in memory and compare them with the code that’s responsible for these memory interactions. Look for injection APIs, such as VirtualAlloc, VirtualAllocEx, WriteProcessMemory, CreateRemoteThread, etc. Also, examine NTFS transactions for Process Doppelgänging injections.
Use debugger-hiding tools to make sure you can analyze detection-evading malware. We’ll talk more about tools a bit later. Now, let’s see how to perform static malware analysis.
Static malware analysis is the type of analysis that is possible to perform without running a code. This type of analysis might require advanced knowledge of low-level software languages, processor instructions, and the principles of memory management.
However, beginner-level analysts have their ways of statically analyzing files, too. For example, a single look at a file extension can tell you what kind of file is that, which allows you to suggest whether it’s suspicious to have this file in the place where you found it or not. Next, you can search for its hash or fuzzy hash in threat intelligence resources like VirusTotal. Be careful when making assumptions, though, because even if the hash is not on VirusTotal, the file can be malicious anyway. Don’t forget to analyze other static properties, such as header information.
Static analysis can be performed through automatic tools for initial triage, as well as tools for manual analysis for a more granular look. Security Analysts study code instructions, dependencies, and what they mean.
If you open an executable file in a Notepad, here’s what you’ll see:
It is a code compiled into a machine-readable format. Processors know what to do, but humans are unlikely to understand anything here. So you need to run this code through a disassembler or decompiler to put it back into a format that you can read and analyze. After doing that, the code will look something like this:
Understanding assembly instructions is necessary for arriving at insightful conclusions. Check out this quick guide for refreshing your knowledge, or dive deeper with this reference manual from Oracle.
You can also use Microsoft’s Sysinternals suite to analyze strings. Its tools can also help to identify which executable is associated with certain Windows API calls and even determine IOCs. Scroll down to the last section of this blog post to discover more about tools for malware analysis. And now, let’s talk about the pros and cons of static and dynamic malware analysis.
Obviously, employing more than one type of malware analysis would be the best option. Static analysis will show how a particular executable file operates. Meanwhile, a standard kill chain nowadays often includes more than one executable. Instead, it can be a collection of scripts and files that trigger one another. If that’s the case, static analysis of one of the files won’t be sufficient for understanding how the whole payload works.
Depending on the goals and objectives of the SOC team, some resources can be spent on studying malware samples. And it’s a very individual choice of whether to go for static or dynamic analysis. Most often, there is a need to maintain a fine balance between the two, which is often called a hybrid malware analysis.
Hybrid malware analysis is a combination of static and dynamic malware analysis.
When it comes to complex samples, it’s best to analyze malware in stages. For example, first, you do static analysis and identify which API calls might be evading detection. Then, in an emulated environment, you perform dynamic analysis to see the sample in action and check if it downloads other binaries. And if you obtain the latter, you can perform a static analysis of their internals again.
Every SOC team is unique, and cybersecurity processes might be organized differently, depending on the business context, the scale of the organization, and risk factors. Below we gathered some of the use cases in which malware analysis is applicable.
IOCs and behavioral patterns are common inputs for various kinds of threat detection activities in specific software programs (SIEM, SOAR, EDR/XDR). Obtaining important malware data during an analysis helps to detect the latest threats.
Getting accurate alerts is a vital part of any cybersecurity pipeline. Malware analysis helps to reduce the number of false positives and false negatives, thus ensuring a higher level of cyber protection.
New and sophisticated strains of malware are not that easy to catch. That’s when threat hunting comes into play. Having malware samples and understanding how they work is the best way to hunt down more threats that are lurking in the wild.
Obviously, there’s no good cybersecurity posture without the incident response. A proper response can be crafted and executed when Security Engineers possess detailed information on what malware looks like, which systems it affects, and what processes it tries to run.
An analytical job is not the easiest one. What’s easy is to get stuck in piles of data or misinterpret the code. For cyber defense to be successful, researchers divide their activities into a few malware analysis steps.
The initial stage of a malware analysis can be performed with the help of automation tools. For static analysis, some preparation steps are required, such as decompiling the code. Anyway, in the first stage of malware analysis, it’s necessary to sort out parts of the code that require close attention. They might also be divided into levels of difficulty and priority. After the scope of the malicious code to review is defined and prioritized, it’s time to move on to the next stage.
Next, Security Analysts get to examine specific malware samples. As I mentioned before, it can be done by analyzing the static properties or by running malware in a safe, isolated environment. When the Malware Analyst obtains all the data that can be exposed during static and dynamic analysis, they try to interpret what they see. They can further test the samples by renaming variables, running the code, and making comments about execution patterns.
This is the most challenging part, especially if there’s an encrypted sample, and it’s unclear what it does and why. What’s more, the code might have multiple dependencies which are also not that obvious. Trying to reverse-engineer malware is an advanced task. Yet, it’s key to a Defense In Depth approach.
When the analysis findings are formulated, it’s time to document them and take further action. The Analyst writes a malware report where they describe a malware sample, stages of analysis that were taken, and conclusions. They can also give some remediation recommendations.
There’s quite a wide selection of tools for malware analysis that Security Engineers use daily. Let’s start with static analysis tools:
When it comes to analyzing malware in sandboxes, you might have already tried Cuckoo, yet I’d recommend checking out ANY.RUN and Joe Sandbox Cloud. They both have MITRE ATT&CK® mapping, use rules, and give a very detailed view of behaviors.
Of course, Wireshark needs no introduction as it’s still one of the most widely used tools for real-time network analysis. INetSim realistically simulates internet services in a lab environment (the samples are highly unlikely to recognize the simulation). Then, there’s the Microsoft Sysinternals suite that I already mentioned above. You’ll find there a whole range of tools for dynamic malware analysis. ScyllaHide is another interesting tool that will let you hide a debugger from malware that you want to run. And if you feel like doing a serious reverse-engineering project, check out Ghidra – a suite of tools developed by NSA’s Research Directorate.
Learning how to do malware analysis might seem boring at the start, but stay patient and dig deeper to find real treasures. Once you feel comfortable with low-level data, you’ll be able to see what not so many people would see. So, instead of thinking that malware engineers are the smartest guys in the world, you’ll be able to prove that even the most advanced malware doesn’t do magic – it’s just another piece of software that can be decomposed and neutralized.
Finally, for quick and efficient Threat Detection and Threat Hunting, subscribe to SOC Prime Detection as Code Platform – here, you’ll find thousands of Sigma-based rules for spotting the latest cyber-attacks. And if you are ready to share your own expertise and monetize on your knowledge, join our global crowdsourcing initiative, Threat Bounty, which helps to make the cyber world a safer place.