1. Introduction
In the interest of time, a malware analyst will usually perform the more straightforward and faster stages of malware analysis to gain a picture of what they're dealing with. Then, if it looks like there's enough reason to dig deeper, the analyst will make use of the more time-intensive techniques to gain a better understanding of the malware sample.
Moving from least complex to most complex, the four stages are:
Fully Automated Analysis
Static Properties Analysis
Interactive Behavior Analysis
Manual Code Reversing
Fully Automated Analysis
A quick and easy way to assess a malware sample is to scan it using an automated malware analysis tool. These tools run the malware in a sandbox and log everything the malware does. Once the analysis is complete, the tool will produce a report that tells you:
which files were accessed.
which registry keys were modified.
which other processes were spawned by the malware.
whether the malware produced any network traffic.
and so on.
Fully automated scanning tools can significantly aid in the incident response process because they can rapidly handle vast amounts of malware. This allows an analyst to focus their attention on cases that require human attention.
Fully automated scanning tools aren't without drawbacks, however. They aren't as thorough and don't provide as much insight as a human analyst can. Moreover, some malware samples wait for human interaction before they do anything malicious or attempt to detect when they are in a sandbox. In those cases, only a human analyst may be able to analyze the malware.
Both commercial and free automated malware analysis products exist. The most well-known is a free tool called Cuckoo Sandbox.
Static Properties Analysis
The second stage of malware analysis is analyzing the static properties of a malware sample. In this stage, malware isn't executed. Instead, the analyst looks at the contents of the malicious file and attempts to find useful information that way.
When analyzing an executable file, the following properties are of great interest:
Strings embedded in the file
Imported libraries and used APIs
Packer signatures to identify common packers
Hashes that can be used for identification
Header details
Metadata, such as the creation time
Malware can come packed in many different file formats. Aside from just looking at executable files, threat indicators can also be found in other file formats, such as:
VBA code in Microsoft Office documents
Invalid cross-reference tables in PDFs
Suspicious EXIF metadata in images
and so on.
When an analyst decides to look at a malware sample, then static properties analysis is a good starting point. It is a relatively quick process, and it may be enough to gain significant insight into the malicious software. The information you find might be enough to define basic indicators of compromise (IOCs), which you can hand off to the SOC to help them detect compromised machines. Any insight you gain will also help you in the later stages since you'll know what to look for.
Pestudio is a widely used tool for analyzing the static properties of Windows executables. There is also VirusTotal, which is an online service. When you upload a file to VirusTotal, any found static threat indicators will be listed in the analysis report. There are also specialized tools for specific file formats, such as oletools for analyzing OLE2 files, such as Microsoft Office documents.
Interactive Behavior Analysis
The third stage of malware analysis involves running malware and monitoring what it does. The malware is run in an isolated lab environment, usually in a virtual machine. Among other things, behavior analysis monitors:
Filesystem changes
Registry changes
Spawned processes
Network traffic
Called APIs
When responding to a malware infection, the actions mentioned above by the malware can serve as IOCs, which you can hand off to the SOC. The IOC could be, for example, a registry mutex, a particular filename, or a network request to a certain IP address.
To reveal as much of the malware's functionality as possible, the analyst will interact with the malware and the system it's running on. This is useful if the malware is keylogging, capturing screenshots, or performing other actions that depend on user input.
Malware often tries to access certain resources, such as local files, services running in the local network, or a C2 server. In that case, it's a good idea to fake these resources to provoke the malware into performing additional actions. Local files can be added to the machine, but for services and C2 servers, an accompanying lab machine is often used, which fakes these resources and responds to the malware's requests.
It is also possible to let the malware communicate with its C2 server to see what kind of messages are sent, but great care and attention must be taken. The malware must not be allowed to escape or harm anything outside the lab environment.
Standard monitoring tools used in this stage include Process Monitor (Procmon), Process Hacker, and Regshot on the infected machine. If services need to be faked, then an accompanying REMnux machine is often used. Wireshark is often used for capturing network traffic to and from the infected machine.
Manual Code Reversing
The final stage of malware analysis involves reverse-engineering the malicious executable's code. In this stage, you must run the malware sample and step through the disassembled code to understand what it does. This process is made especially difficult because you must circumvent everything the malware does to prevent you from understanding it — code packing, code obfuscation, anti-debugging techniques, and so on.
Reverse engineering is time-consuming, complex, and requires a specialized skillset. For that reason, many malware investigations won't delve into code analysis. However, it is the only way to have complete insight into a piece of malware.
Through reverse-engineering the code, you can gain insight into the additional capabilities that the malware possesses and didn't reveal during behavior analysis. Moreover, some aspects of malware can only be understood by reverse-engineering the code. For example, if malware stores or transfers encrypted data or has a domain generation algorithm, then reverse engineering is the only practical way to gain insight into that.
The main tools for reverse engineering are a debugger and a disassembler/decompiler. On top of that, other specialized tools and plugins can aid in the reverse engineering process. Memory forensics may also be a useful addition to help you reverse engineer the code.
A popular debugger for debugging Windows executables is x64dbg, while either IDA Pro or Ghidra are commonly used to decompile the malware's code.
Last updated