|
|
|
# Malware Analysis
|
|
|
|
The tools in this article are primarily geared toward analysis of Windows malware, but many of the concepts should apply to malware analysis in general.
|
|
|
|
### Contents
|
|
|
|
* Triage
|
|
|
|
* Static analysis
|
|
|
|
* Dynamic analysis
|
|
|
|
# Triage
|
|
|
|
There is not enough time nor malware analysts to perform an in-depth analysis of every unknown software sample. For this reason, the first job of many malware analysis teams is triage: determining the basic functionality of the software, so it can be decided if the software is malicious.
|
|
|
|
When triaging a sample, the specific indicators depend on the language of the program, but there are certain behavior patterns and artifacts that raise suspicion or warrant further investigation.
|
|
|
|
* Network access / URLs - hard-coded URLs can help identify the target of the malware
|
|
|
|
* File access - does it read to files? does it write to files?
|
|
|
|
* Obfuscation - while obfuscation does not inherently make the program "bad", it is common for malware authors to obfuscate the functionality of the code in some way.
|
|
|
|
* Windows API calls - Calling the Windows API isn't particularly unusual, but certain call patterns can indicate that the program is searching for an antivirus, trying to escalate its privileges, etc.
|
|
|
|
* Packers - some are easier to deal with than others, but static analysis is very difficult to perform on a packed program!
|
|
|
|
|
|
|
|
Oftentimes, evidence of these can be found simply by running `strings` on a file. This can reveal URLs, IP addresses, system APIs used, and other interesting strings that reveal some part of the functionality.
|
|
|
|
### Tools
|
|
|
|
* `file`
|
|
|
|
* `strings`
|
|
|
|
* hex editor
|
|
|
|
* CFF Explorer / PE Explorer
|
|
|
|
# Static Analysis
|
|
|
|
Static analysis can be performed, like any other reverse engineering task, with the help of disassemblers and decompilers. Some of the strings found in the triage stage may assist in identifying the functionality of the program during this stage.
|
|
|
|
### Tools
|
|
|
|
* Disassembler (`objdump`)
|
|
|
|
* Decompiler (IDA Pro, Ghidra)
|
|
|
|
# Dynamic Analysis
|
|
|
|
If the binary is difficult to reverse engineer, the easiest way to uncover the functionality of the malware is to execute it. However, running malware on a system has inherent risks, so certain precautions should be taken.
|
|
|
|
### Precautions
|
|
|
|
* Virtual Machines
|
|
|
|
* Malware analysis workstation
|
|
|
|
* Networking
|
|
|
|
|
|
|
|
Virtual machines are one method of running live malware samples. It is fairly simple to create snapshots before the malware is run, and revert back to it after the desired information has been collected by running the malware sample. The downside to this is that some malware samples will check if they are in a VM and, if they are, refuse to execute. Furthermore, it should be kept in mind that the malicious code is still running on your physical machine. If the malware somehow escaped the VM, it could infect the host.
|
|
|
|
|
|
|
|
For this reason, some analysts opt to dedicate an entire workstation or even network to the purpose of malware analysis. Malware is run directly in a host operating system, and a backup drive is kept which restores the computer to its initial state between malware runs. Of course, this limits the computer from being used for any purpose other than malware analysis, or else risk compromising the integrity of any user accounts logged into the device.
|
|
|
|
|
|
|
|
Network precautions should be taken, too, as some pieces of malware attempt to infect other hosts on the network. If using Virtual Machines, host-only networking should be used so outside devices are not visible. For physical analysis workstations, an isolated network should be used which cannot contact the internet. Tools like inetsim can be used to send fake responses to the malware if it does attempt to contact other devices.
|
|
|
|
|
|
|
|
### Analysis
|
|
|
|
Once the environment is set up, there are a number of useful tools to log the behavior of the malware. A snapshot of the registry should be taken in regshot before and after the malware is run. Comparing these allows you to see what registry entries the malware added, and may help uncover how the malware maintains persistence.
|
|
|
|
|
|
|
|
Process Monitor logs
|
|
|
|
|
|
|
|
Running wireshark, in combination with inetsim on another device, will allow capture of any communication the malware attempts to perform with the outside world. This can enable reverse engineering of the malware's command protocol, or identify if any files were exfiltrated from the infected machine.
|
|
|
|
|
|
|
|
Finally, dynamic analysis can be performed in debuggers such as IDA and OllyDbg, by stepping through the malware code and observing its behavior. However, once again, some malware samples will refuse to execute if they identify that they are in a debugger, so anti-debugger-evasion techniques may need to be performed to combat this.
|
|
|
|
|
|
|
|
### Tools
|
|
|
|
* [Procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) - logs process information and activity
|
|
|
|
* [regshot](https://sourceforge.net/projects/regshot/) - snapshots and compares changes in registry before/after the malware is run
|
|
|
|
* RegFsNotify - more logs
|
|
|
|
* [wireshark](https://www.wireshark.org/) - analyze network traffic generated by the malware
|
|
|
|
* OllyDbg/IDA/`gdb` - debug the malware
|
|
|
|
* [inetsim](https://www.inetsim.org/index.html) - simulate network traffic |
|
|
|
\ No newline at end of file |
