When analyzing malware, it is important to consider the following:
- Point of Entry (PoE) I.e. Was it through spam that our e-mail filtering missed and the user opened the attachment? Let’s review our spam filters and train our users better for future prevention!
- What are the indicators that malware has even been executed on a machine? Are there any files, processes, or perhaps any attempt of “un-ordinary” communication?
- How does the malware perform? Does it attempt to infect other devices? Does it encrypt files or install anything like a backdoor / Remote Access Tool (RAT)?
- Most importantly — can we ultimately prevent and/or detect further infection?!
The ultimate process of a malware attack can be broken down into a few broad steps:
- Maintaining persistence (not always the case!)
- Propagation (not always!)
There are two categories used when analysing malware, these are:
1. Static Analysis
2. Dynamic Analysis
For this lab, you will see that some tools will overlap between Static and Dynamic analysis:
Provided Static Analysis Tools:
- Dependency Walker (depends)
- PE Explorer
- IDA Freeware
Malware Windows Environment
Connecting to our Windows VM we begin by analyzing .exe files. The three files given to us include:
Obtaining MD5 Checksums
MD5 Checksums can act as fingerprints in order to verify if the file is legitimate.
We can verify with Virustotal to see if they are legitimate.
Checking all three show that they are the legitimate.
Identifying if executables are obfuscated or packed
Obfuscating/packing is a technique that malware authors employ to prevent the analysis of programs. Preventing analysis of programs makes reversing engineering much more difficult making it harder to prevent or even counter the malware.
We will use PEid to view these “executables”.
Moreover, just because a file doesn’t have the “.exe” extension, doesn’t mean it isn’t an actual executable! For instance, it can have the “.jpg” extension and still be an executable piece of code. Files have identifying attributes within its hex — known as file headers.
Utilizing PEiD, we can see that both files have different packers.
Visualizing the Differences between packed and non-packed code
if an Author has written their own packer — PeID will have no way of identifying the packer used. In cases like this, it’s more about what PeID doesn’t tell us — rather than what it does.
For example, using PEiD to check if this file is packed, we see that it packed with a packer named FSG 1.0 -> dulek/xt
In order to further inspect the file, we open up IDA Freeware. Here we can see the flow of how the program executes — indicated by the arrows. One of the biggest indicators that the program is packed is by the lack of information available. Most likely the malware author packed the file to prevent static analysis tools like IDA to inspect it. Also, checking the imports tab there is only two imports which is not common to see in malware. Further indicators that this file is packed.
Introduction to Strings
Strings are essentially the ASCII / Text contents of a program…this could be anything from passwords for self-extracting zips, to bitcoin addresses in ransomware samples.
We can either run strings command from the terminal (thanks to sysinternal)
To check on our hypothesis of the lack of imports, we can use PE Explorer to view the imports.
We only have 5 imports which could mean the file is packed.
Introduction to Imports
Disassemblers reverse the compiled code of a program from machine code to human-readable instructions (assembly). Debuggers essentially facilitate execution of the program — where the analyser can view the changes made throughout each “step” of the program.
What is the MD5 ?
Does VirusTotal report this file as malicious?
What is the last string outputted?
What is the output of PeID when trying to detect what packer is used by the file?