Understanding malware analysis and its challenges

Malware analysis is the process of examining malware to determine how it got past defenses and what it was designed to do once inside an environment. Malware analysts are the brains behind the operation. While an interesting and in-demand occupation, it isn't always easy.

To help new and experienced analysts alike, authors Amr Thabet and Alexey Kleymenov wrote Mastering Malware Analysis: A malware analyst's practical guide to combating malicious software, APT, cybercrime, and IoT attacks. Their second edition provides more introductory content to help those starting down a malware analysis career path.

In this interview, Thabet and Kleymenov discuss their favorite malware analysis tools, common types of malware they come across, what they see as the goal of malware analysis and more.

Check out an excerpt from Chapter 1 of Mastering Malware Analysis, which provides context around malware analysis, from the goals to the reasoning for it.

Editor's note: The following interview has been edited for clarity and conciseness.

Learn more about Mastering
Malware Analysis by
clicking here. During 12/9/22
to 1/9/23, use code 20MMATECH,
and receive a discount.

What is the goal of malware analysis?

Amr Thabet: The main goals of malware analysis are to understand what/who the attacker is, how they got into the machine originally, what they are trying to do with this malware and how they can spread through the network.

A lot of accompanying questions follow. The aforementioned are the most important, but those in charge also ask: When and how did the attack happen? Where was the first infiltration? How did it bypass defenses in place? That's where malware analysis comes into play. Malware analysts can answer some of these questions by examining the logs, but real understanding comes by analyzing and reverse-engineering the malware. Malware is often the foundation of the attack. Understanding the malware itself and what it does are at the heart of incident response.

What types of positions are malware analysis important for?

Thabet: Malware analysis is important for a number of positions, including digital forensics, threat intelligence and SOC [security operations center]. If you understand malware, you'll understand every other field involving cybersecurity attacks.

You cover multiple types of malware in your book. What are the most common types you come across?

Alexey Kleymenov: The types of malware you encounter will depend on your position. For example, my job [as a threat intelligence manager at Nozomi Networks] involves receiving a lot of arbitrary files and figuring out what they are. If you're working in the enterprise, the types of files, both malicious and not, will be different from the ones you analyze on the consumer side.

In my early years [as a malware analyst at Kaspersky Lab], I commonly came up against banker and downloader [Trojan] malware. Later, when I shifted to Symantec as a threat analysis engineer, I received more complicated samples written by APT [advanced persistent threat] groups. The malware there often was used for cyber espionage, sabotage and remote control. Now, ransomware has become prevalent.

Thabet: I mostly work with organizations that suffer targeted attacks. I see a lot of PowerShell scripts used. Other common attacks I see include Windows backdoors and Bash scripts -- especially on the cloud side. Android- and iOS-focused attacks are still out there, but I mostly come across attacks targeting Windows devices.

For malware specifically, I see a lot of ransomware and backdoor attacks. For the latter, I see attempted remote control of TeamViewer and ngrok for tunneling. I also see a lot of Mimikatz and Cobalt Strike attacks; everyone just reuses them or tweaks them to appear different.

What tools are commonly used for malware analysis?

Thabet: The most common tool I use is IDA Freeware or IDA Pro -- it's my personal favorite. Another tool I often use is x64 debugger. I also use pestudio from the small startup Winitor. Another tool worth mentioning is OllyDbg. I also use VMware virtual machines to run malware samples in.

Kleymenov: Any programming language can be used to write malware. So, people tend to stick to tools that support multiple formats. I spend 80% to 90% of my time using IDA Pro for executable analysis. It's perfect for my uses, but I wouldn't say that everyone has to use it. A lot of different malware payloads are out there -- you just want to select the tool that will make it readable for you.

In Mastering Malware Analysis, you wrote you often can't research as deep as you'd like due to time and money constraints. With that in mind, how do you choose a malware analysis strategy?

Kleymenov: We would love to have unlimited resources, but that never happens. So, everything starts with your purpose, which depends on how much time you have and the questions you need to answer. When approaching malware, it depends on what answers stakeholders want. Do they want to see a full analysis of the techniques, tactics and procedures of the malware or just the indicators of compromise?

Thabet: I agree with Alexey. I think about what the easiest way to answer the most questions is, even with the lowest accuracy. Then, I go deeper than that in my analysis. A lot of people go straight to code analysis, but this could take weeks, especially if the analyst lacks experience. Instead, laser-focus on getting the easiest answers first. Read the different text used, such as API names and the Windows commands used. This may not get a lot of accurate answers, but it can often answer a lot of questions fast. Then, if there are more questions, conduct behavioral analysis -- this doesn't require diving too deep and can be done quickly. From there, dive deep, and conduct a static or dynamic code analysis. I use that to confirm the information I got from the previous two phases or to answer specific questions.

What is the most difficult part of malware analysis?

Kleymenov: Difficulty often arises due to a mismatch of expectations from stakeholders who want to receive certain results and have a vision in mind for how long that may take. From my colleagues and others in the industry, I commonly see that management doesn't always understand the technical scope of work required. This results in a misunderstanding of how much time and effort malware analysis takes, which can lead to burnout -- analysts could end up working 16-hour days just to meet goals they didn't set. Malware analysis often requires reverse-engineering binary payloads, and depending on the level of obfuscation and how many modules there are, it may take a variable amount of time to get a reasonable result.

Another problem is that many people don't invest in fundamental computing knowledge. They read some manuals and mechanically repeat steps to get some sort of result. They may not understand what they're doing or how the technology works, which makes one ignorant in selecting tools and understanding what the malware sample is.

Thabet: I'll add a few things I see people struggle with. The first is to get from the assembly language to understanding the logic of the whole code. They have trouble getting from the low-level code to seeing the high-level logic and understanding what the program is trying to do.

People also struggle to find evidence when digging through code. This comes with experience; I can understand the behavior of malware without diving deep into the code. It takes time and practice to get good at the art of reverse-engineering.

Another difficult aspect of malware analysis is going from examining the code and translating it into something other stakeholders can understand, whether you're talking to the CISO, incident response team or SOC team. As an analyst, you may understand how the malware functions, but you need to be able to explain that in a way that others can understand.