Why Static Analysis Struggles Against Modern Malware

Table of Links

Abstract and 1 Introduction

2 Related work

2.1 Malware analysis and countermeasures

2.2 LLMs in cybersecurity

3 Problem setting

4 Setting up the experiment and the dataset

5 Experimental results and discussion

6 Integration with existing pipelines

7 Conclusions, Acknowledgements, and References

2.1 Malware analysis and countermeasures

Malware analysis can be classified into static and dynamic analysis based on whether the malware is executed. As a result, in static analysis, the goal is to extract as many artefacts from the file as possible to classify it (benign/malicious), determine the malware family (multiclass classification), and determine its functionality. To achieve this, one may use byte streams, imported libraries and used functions, or even byte-level similarity. On the other hand, the malware analyst may execute the file in a sandbox, bare metal, or even use emulation and symbolic execution to record what the file under investigation does, e.g., network connections, file-system and registry changes, and memory dumps.

The above is well-known to malware authors who try to evade detections or at least impede the work of malware analysts. The first countermeasures target the static analysis which is the most cheap one, in terms of resources. Therefore, malware tries to hide the underlying functionality and break the byte-level patterns. This is currently achieved by packers, obfuscators, and cryptors.

Packers are software tools that compress or pack an executable file. This compression is not only for reducing size but also for obfuscating the code. When packed, the executable’s original code and data are transformed into a compressed format and then appended with a decompression stub, a small piece of code responsible for unpacking or decompressing the executable in memory when it is executed, so actual code is not revealed until executed. The latter hinders static analysis, which entails examining the malware without running it. Packers are not inherently malicious; legitimate software often uses them to reduce the size of executables and protect intellectual property. However, in a malware context, packers are used to hide malicious code from antimalware scanners, which often struggle to analyse the packed content effectively. Some packers also provide additional features like anti-debugging, anti-emulation, and anti-virtualisation to further hinder malware analysts’ work.

Cryptors, on the other hand, take obfuscation further by encrypting the executable’s content, not just compressing it. They encrypt the malware’s code and data, rendering it unreadable to humans and antivirus software without the proper decryption key or algorithm. Like packers, cryptors append a decryption stub to the encrypted executable. Once executed, this stub decrypts the malware in memory, allowing it to run as intended while remaining undetectable from static analysis tools. Cryptors are more sophisticated than packers and are specifically designed to evade detection by antivirus software. They can employ complex encryption algorithms and frequently change keys to avoid signature-based detection. Some advanced cryptors also use techniques like polymorphism; changing the encryption with every iteration, or metamorphism; changing the underlying code with each iteration, to create unique malware variants in each iteration, further complicating detection and analysis. While theoretically, packers and cryptors are different, most modern packers come with some encryption scheme.

For more information on malware evasion and anti-analysis methods, the interested reader may refer to [3, 1, 11, 12].