The first phase of malware testing, basic static testing, is now complete. Basic static testing is studying the malicious program without executing it. That means using specialized tools to investigate the code and structure of the malware to determine its functionalities. We used a FlareVM which is essentially a collection of software installation scripts. When the “install.ps1” script is run, a secure, well-stocked malware analysis environment is created, specifically on a virtual machine (VM). Programs and utilities of all types are installed, including programs that allow for reverse engineering (Ghidra, IDA), utilities that allow for packing (or compressing) and unpacking malware files (UPX), programs that can do a string search (FLOSS), and several other programs that give us better insight into the potential capabilities of the malware sample without having to run it.
My favorite tool was Ghidra. Ghidra is an open-source reverse engineering tool developed by the NSA, yes THAT NSA. It is an easy-to-use tool that analyzes the file and presents the analysis in neatly arranged windows. We are able to disassemble the malware and view the Assembly instructions. The neat thing is that Ghidra also decompiles the byte code into a high-level programming language, in our case C language. This is immensely helpful because we can actually study the code and try to figure out what the malware is coded to do. IDA is also another really cool tool that allows us to analyze the code execution flow. So, we can see the entry point and key routines.
Of course, every defensive technique can be evaded or defeated. Malware creators never rest and are always looking to stay one step ahead of malware detection and analysis techniques, this is called, not surprisingly, “malware anti-analysis”. There are several ways that malware will try to evade our defensive and analytical tools, including packing (or compressing) a malware file, essentially creating a wrapper of innocuous code to avoid basic detection. Obfuscation can also be used to hide malware execution, and can even be used selectively to obfuscate only key files or lines of code. Other behaviors that malware may exhibit is scanning the environment to determine if they are in a virtual machine or in a realistic Windows environment. They will scan for common analysis tools, clipboard content, common programs, and so on in order to determine if this is just a bare-bones testing environment or a PC that is used normally.
There are many more anti-analysis techniques, but of course in response there are anti-anti-analysis techniques designed to counter those. It is a fascinating battle that is constantly evolving alongside the stakes, from infecting an individual home PC to infecting financial institutions and even to sabotaging nuclear power plants, the dangers of malware cannot be overstated. If readers are interested in reading more about this, the paper titled “Analysis, Anti-Analysis,
Anti-Anti-Analysis: An Overview of the Evasive Malware Scenario” is an interesting and accessible read.
https://www.lasca.ic.unicamp.br/paulo/papers/2017-SBSeg-marcus.botacin-anti.anti.analysis.evasive.malware.pdf
Leave a Reply