Testing Detection of K-Ary Code Obfuscated by Metamorphic and Polymorphic Techniques
1 U.S. Naval Postgraduate School, Monterey, CA
93943, USA
george.t.harter@outlook.com, ncrowe@nps.edu
Abstract. K-ary codes are a form of obfuscation used by malware in which the code is distributed across K distinct files. Detecting them is difficult because recognizing the pieces that belong together is hard and provably impossible in general, and the techniques of encryption, metamorphism, and steganography can further obfuscate the code. We built a proof-of-concept K-ary program to test its detectability. It simulated a "keylogger", malware that records keystrokes. We distributed it into parallel obfuscated processes run by a central controller process. We ran both static and dynamic tests to try to detect the keylogger using a variety of parameters. These tests used cosine similarity and clustering methods to correlate pieces of the malware, assuming that using a controller process meant the pieces would have similar code for communications, and that similarity could still be recognized even if obfuscated. Results showed moderate but not perfect success at recognizing our simulated malware. This should provide new tools to detect malware camouflage and evasion.
Keywords: Metamorphic, Polymorphic, Malware, Obfuscation, Evasion, K-Ary, Distributed, Malicious, Codes
This paper appeared in the Proceedings of the National Cyber Summit, Huntsville, Alabama, September 2021.
Malware (malicious code) is widespread and pervasive. Its goals range from petty crime to espionage and warfare, and some malware attacks have caused billions in damages. For instance, the ILOVEYOU worm has caused over $10 billion in damage [1], and the MyDoom worm is estimated to have caused over $38 billion in damage worldwide [2]. More menacing malware such as the Triton malware, which targets industrial safety-control systems, can endanger human lives [3]. Similarly, the Stuxnet worm sabotaged industrial uranium-enrichment facilities [4].
Anti-malware vendors [5] provide useful defensive tools, but they are inevitably imperfect. An early paper argued that a perfect malware detector cannot be implemented [6], and others have shown a virus can be created for which no automated detector can be implemented without producing false positives [7]. In part this is due to subjectivity in what defines malware; effective malware can be designed to use only components of a benign program. Furthermore, some programs may be considered either malicious or benign depending on their context. Such ambiguity permits malware authors to make their products more resilient to countermeasures.
Malware can evade detection in many ways. Examples are encryption or steganography to hide their malicious payloads, disguising the malware as legitimate programs, and detecting the presence of analysis programs so as to switch evasion tactics. One method of reducing detectability is to split malware across multiple files, a K-ary design [8]. This aids code obfuscation in that the pieces are less likely to show suspicious features than the whole. The detection of malicious features of K-ary code has been proven to be NP-complete which means it is computationally very difficult [9]. K-ary code can also be enhanced with other stealthy techniques.
Little research has been done on K-ary program designs and few examples have been found outside of laboratory environments. The development of this technique may be like that of ransomware, where early work analyzed asymmetric encryption in a malicious tool [10], but it was not until 2009 that the Archievus ransomware implemented the design in real malware [11]. Today ransomware attacks using asymmetric encryption are common. Similarly, significant K-ary malware might not be seen for many years. If K-ary malware design does prove to be advantageous, defenders should be prepared for its use.
Section 2 gives an overview of malware detection and anti-malware evasion techniques. Section 3 outlines the methods of the experiments, and section 4 describes the results. Section 5 gives concluding remarks and suggestions for future research. More details of our work are in [12].
2.1 Malware Detection Methods
Malware detection can be either signature-based or anomaly-based [13]. Signature-based detection is the primary method of anti-malware tools [14]. It recognizes specific artifacts of a file or process which uniquely identify it as malware. The benefits of signature-based detection are efficiency and a low false-positive rate. Its weaknesses are that it cannot detect new malware and it may not recognize malware that has been obfuscated using polymorphic and metamorphic techniques [15, 16]. Executable files with encrypted or compressed bodies offer few signatures because their static code is hidden. The experiments we will describe used novel obfuscated executables, so signature-based techniques for detecting them would have great difficulty.
Anomaly-detection classifies files as malware by recognizing statistical features of known malware [17, 18]. It can use methods such as data mining, machine learning, and statistical analysis to recognize suspicious features. Its main weakness is that it produces more false positives than signature-based methods [19], but these can be reduced by using the consensus of features [13] and a weight-based or rule-based method for combining them [17]. In a weight-based system, indicators of malware are given weights proportional to their strength as indicators, and weighted indicators are summed; if the sum exceeds a defined threshold, the file or process is labeled as malware. A rule-based system uses if-then rules on a file or process [20]; if enough instances of particular patterns found by rules apply, then the file or process is classified as malware. Common clues for anomaly detection are:
· System-call sequences: Application-programmer interface (API) calls used by a program to interact with its host system. These calls may read, create, delete, or modify files on a system, or access a network. Malicious files often exploit these calls for their purposes [18].
· Control flow and call graphs: Although some aspects of a malware may change between instances, most execution flow remains the same [21] and can be recognized [22]. Graph-based detection uses call graphs or flow graphs, and usually parses the executable code after disassembly. It can be quite accurate, but it can be slow and computationally expensive.
· Other clues to malware are code sections marked as writable but not readable, control-flow redirection to a section that does not contain code, gaps between sections of a program, multiple file headers in a single file, and signs of a patched import address table [23].
2.2 Techniques of Malware to Avoid Detection
Metamorphism, Monomorphism, Oligomorphism, and Polymorphism
Metamorphic malware applies code-transformation techniques to the malware body to create versions with identical functionality that are hard to recognize. Metamorphic techniques include [13, 16]:
· Dead-code insertion: Code which does not affect the results is inserted between instructions.
· Independent-code permutation: Instructions are permuted when it does not affect the results.
· Code transposition using added control flow: Segments of code are moved within the file, and control flow is rerouted to jump to them.
· Register renaming: Registers used in instructions are changed consistently.
· Equivalent-code substitution: Blocks of code are replaced by different blocks that do the same thing.
· Subroutine permutation: The locations of subroutines in a file are changed.
· Subroutine inlining: A call to a subroutine is replaced by that subroutine's code.
· Subroutine outlining: Portions of code are made into subroutines and replaced by calls to those subroutines.
Metamorphic malware can be vulnerable to static analysis using graph-based detection and Markov models [24, 22]. It can also be vulnerable to dynamic analysis that examine its behavior when the obfuscation does not change that behavior.
Monomorphic malware usually contains a payload of encrypted malicious code and a built-in decryptor. The decryption key can be changed between instances to make it harder to detect. However, the decryptor itself must remain unencrypted and may be a detectable signature. Furthermore, emulation can see the malware decrypt itself, exposing the malware's payload for analysis.
Oligomorphic malware changes its decryption code between instances or carries code for multiple decryptors [25]. Although oligomorphic is more challenging to detect than monomorphic malware, its decryptors still can be detected.
Polymorphism improves on oligomorphism by using many more decryptors. One study found it in 93% of the malware it examined [26]. It often uses metamorphic code-transformation techniques that permit many versions of the decryption code itself. However, under emulation, polymorphic malware will still decrypt its body, revealing signatures for possible detection, though "on-demand" polymorphism tries to reveal pieces of its code one at a time to reduce signatures [27].
Emulator Fingerprinting and Anti-Debugging
Many malware detection and analysis techniques use emulators and virtual machines for dynamic analysis. Malware can possibly recognize them with emulator fingerprinting, and can route execution to non-malicious code or end execution. Fingerprinting clues include [28]:
· Environmental artifacts: User names, files, environment-variable values, and others.
· Timing: Inconsistencies or skews which indicate a process is virtualized.
· Process introspection: Recognition of libraries or hooks that have been injected into the malware code, indicating potential analysis.
· Processor anomalies: Discrepancies in execution that indicate emulation, since it is difficult for an emulator to perfectly imitate a processor or operating system.
· Reverse Turing tests: Lack of signs of human use of a system in such things as the Web-browser history, login times, and the presence of input devices.
· Network artifacts: Discrepancies in what would typically be seen in a network.
Anti-malware tools can use debugging techniques to monitor running processes. On Windows hosts, the functions IsDebuggerPresent and CheckRemoteDebuggerPresent indicate a process being debugged [29], and on Windows NT, flags stored in the NtGlobalFlag variable in the system registry do the same [30]. However, references in the malware code itself to these things themselves are good signatures for anti-malware tools [31].
Anti-Disassembly Techniques
Disassembly means reconstructing source code from executable code, and is used by many malware analyzers. It is difficult and even the best disassemblers only correctly reconstruct 40–60% of some programs' executable code when anti-disassembly is used [32]. Malware can exacerbate the difficulty of disassembly by using indirect jumps, exception handling, and other anti-emulation techniques like those mentioned previously. It can also use "flower instructions" that point to sections of valid code at incorrect offsets, but which the malware does not actually execute. Operations can also be obfuscated with exception handling that uses custom signal handlers to redirect execution. These techniques may make disassembly harder, but it still remains possible.
Malware can use steganography (covert channels) to hide code or data [33]. Examples are AdGholas, which embeds malicious JavaScript code in images and other files [34], and ZeroT, which embeds its payload in a set of images [35]. Many anti-malware tools only check specific files like executables for malware, overlooking most steganographic embedding techniques [36].
Packers are file compressors that encode data to reduce its size [37]. Packers can obfuscate since packing eliminates signatures. An estimated 80% of malware uses some form of packer [38]. Because packers often use well-known methods, anti-malware tools and malware analysts often have unpacker programs for them. If no unpacker is available, emulation can wait for the program to unpack itself before analysis.
K-ary Malware
Another obfuscation technique is dividing malicious code into separate files [39] ("K-ary malware" where K is the number of files) which makes it harder for any subfile to offer a recognizable malware signature [36]. Three methods of execution of such files are:
· Centralized: A single process locates the subfiles, assembles them in its own memory, and executes them [36].
· Sequential actors: The K processes are executed in sequence [9].
· Parallel actors: The K separate processes execute simultaneously.
All three designs can obfuscate against static signature-based detection without needing encryption, steganography, or metamorphism. Covert channels can coordinate processes [39]. A parallel design can also maintain persistence as the malware's multiple processes can restore files or processes that are removed by anti-malware [9]. The most important advantage of all three designs, however, is that it is difficult for analysis to recognize and assemble the pieces of the code even without obfuscation because of all the possible combinations to check.
Nonetheless, signatures are still present with a K-ary design. A centralized design in particular still exposes its full code in memory at times. The sequential and parallel-actor designs require code to coordinate with other processes, and it may be difficult to hide it since a useful signature may be as little as 16 bytes [23]. Statistical analysis may be especially useful for correlating K-ary files or processes. Pieces of executables that have related functionality likely will have related features, as does code written by the same author or using the same tools.
Previous work showed that K-ary malware program designs can evade both static and dynamic detection by anti-malware software [36, 39]. Our experiments tested possibly better techniques to detect K-ary malware programs by correlating their pieces. We created an example parallel K-ary program "ManyEyes" to test, simulating a keylogger program that monitors and records the keystrokes made by a user. The program was designed for a Windows operating system. Similar programs have been used by criminal hackers to steal passwords and other sensitive information [40]. To test how traditional obfuscation techniques might be used in K-ary programs, ManyEyes used steganography, encryption, and metamorphism.
We first did static statistical analyses to the program pieces to try to correlate them, using bigram histograms, cosine similarity, and a clustering algorithm. Although the files tested were static, they were processed to simulate being loaded into memory by adjusting their addresses. Experiments were done 1000 times with a variety of malware and benignware combinations. A second set of experiments correlated K-ary memory contents during program execution. Memory dumps of a running instances of ManyEyes were compared statistically to those of other processes.
3.1 Implementation of Our K-ary Program
Program Design
ManyEyes had subprograms for code gathering, key monitoring, and log aggregation. The code-gathering subprograms took parts of a partitioned executable from secondary storage and executed them in memory. These programs were written in C++ and compiled for x86 architecture systems using the Microsoft C/C++ compiler. In this partly centralized design, a separate code-gathering program was run for each key-monitoring subprogram. The key-monitoring subprograms were Windows executables that monitored key presses and logged them. These were written in C and compiled for a 32-bit x86 architecture using the Microsoft C/C++ compiler. The log aggregators were Python scripts to concatenate log files of around 5KB.
The code-gathering subprograms were 23KB. The size of the key-monitoring programs varied because they were generated by a metamorphic engine which increased them from 12KB to around 45KB. ManyEyes may be configured with a specified number of key-monitoring subprograms and processing resources. Experiments used a delay of 10ms between each set of queries, which caused the Windows Task Manager to classify the power use of these programs as "very low".
ManyEyes had five stages: metamorphic code generation, steganographic storage, in-memory execution, keylogging, and log aggregation. Although log aggregation and keylogging may occur simultaneously, each keylogger process hands logs off to an aggregator. The in-memory execution and keylogging used parallel K-ary code design, and the gathering of code portions from steganographic storage emulates the centralized design. Thus ManyEyes uses aspects of all three of the K-ary malware designs, although it is primarily a parallel design.
Obfuscation Techniques
Before executable code pieces were deployed, ManyEyes applied metamorphic transformations to them. For key-monitoring code, we used subroutine reordering and dead-code insertion, and we randomized strings and symbols that could be modified without changing the functionality of the program. These transformations were done at the assembly level before compilation, and the amount of dead code inserted was random.
A design goal of ManyEyes was to prevent unobfuscated key-monitoring code from appearing in storage since anti-malware tools recognize many keylogging methods. To do this, we also used steganography and encryption to obfuscate the code. We hid the code within 24-bit bitmap pictures in the least significant bit of each red, green, and blue value for each pixel in the pictures, and further encoded it with an exclusive-or using a key of 4 to 29 bytes. Each bit of the key was sequentially applied to the least significant bits of each pixel and the key was repeated until exhausted.
The obfuscated key-monitoring programs were 45 kilobytes and the entire keylogger payload could be stored in five bitmap files in our experiments. Three of these images were 128 by 209 pixels and approximately 80 kilobytes in storage, and the other two were 148 by 197 pixels and about 86 kilobytes in storage. The key-monitoring programs used approximately one-ninth of the data in the pictures.
Execution
The key-monitoring subprograms were invoked by the code-gathering subprograms. The latter extracted the former from the picture files, decrypted them, and executed them in memory so they never appeared unobfuscated in secondary storage. This required workarounds in the Windows operating system. We used a method RunPE which spawned a child process in a suspended state, and then wrote code in the Windows Portable Executable format to the child-process memory before releasing its suspension, an implementation was modified from [41]. Cross-process memory writing was done with the Windows applications programming interface with calls to WriteProcessMemory and VirtualAllocEx. It would have been simpler to concatenate the pieces, write them to a file, and then execute the file from static memory, but that would have revealed the unobfuscated key-monitoring programs in secondary storage.
In the third stage, the key-monitoring programs put into memory were executed to monitor keystrokes and write them to log files. The GetAsyncKeyState function in the Windows applications programming interface was queried repeatedly for each key being monitored. Anti-malware tools could detect this keylogging by looking for frequent calls to the GetAsyncKeyState, but this was obfuscated by splitting the calls over parallel programs with a reduced the number of calls by each process.
In the fourth stage of log aggregation, each aggregator process monitored multiple logs, which it concatenated and wrote to a new location. A hierarchy of log aggregators was used with some working on the aggregations of others, to lower the chances of discovery of their purposes by analyzing their output. To aid this, each log aggregator program also read several random files.
3.2 Implementation of Anomaly-Based Malware Detection
Getting and Preparing Malware Files
Our static-analysis experiments counted bigrams (2-byte sequences) in 1665 benign and 1235 malicious PE executable-file samples. The benign samples were collected from a Windows computer with the permission of the owner. The malicious samples were taken from a corpus of representative files found on real systems [42] by running five anti-malware products (Bit9, Symantec, ClamAV, OpenMalware, and VirusShare) [43] and taking a random sample of the files they identified as malicious. The benign samples had 32,4252,414 bigrams (two-byte sequences) and the malicious samples had 139,696,687 bigrams. Both sets of data contained every possible bigram of the 65,536 possible. The average benignware file was 407 KB and the average malicious file was 218 KB.
To test our detectability of our split code by anomaly-detection methods, 1,235 malware samples were used and their executable code was split into five parts for the first 1,000 runs of this experiment, and into fifteen parts for the second 1,000 runs of this experiment. In each experiment run, a single sample of the malware was selected. We also selected some benignware samples from the same corpus.
Most modern operating systems use the security technique of address-space layout randomization, which causes memory references and virtual-memory placements to differ between instances of a program. To simulate it, we added a random integer to memory references marked for modification in the relocation table for each malware part. For consistency, the benign programs in our experiments also used this simulated memory mapping.
Clustering of N-Grams
Our static-analysis experiments correlated our K-ary code pieces by clustering them based on their similarity. The metric was the cosine similarity (normalized inner product) of their histograms of byte sequences of length N (N-grams). N-gram statistical analyses are often used in deep packet inspection for cybersecurity. We clustered all the malware and benignware pieces and measured how often malware pieces were placed in the same cluster. Clustering was done by HDBSCAN, a hierarchical density-based clustering algorithm based on DBSCAN [44]. HDBSCAN can discover clusters of varying densities and requires less prior knowledge about the nature of the clusters than related algorithms.
For each of 1,000 runs of each experiment, a malware program and 200 benign programs were randomly selected. This simulated the proportion of malware to benignware that is likely to run simultaneously. For each run, the histograms for each of the K pieces of the malware being tested and the 200 benign samples were paired and their cosine similarity was calculated. The benignware were not split, as we expect they would not be split on a real system.
Success of K-ary malware partitioning was measured by the number of malware pieces in the cluster with the most malware pieces. True positives were malware pieces in that cluster, false positives were benignware in that cluster, and false negatives were malware pieces in another cluster. Using these measures, we calculated accuracy, precision, recall, and the F-score for the identification of malware pieces in each experiment. Accuracy measures how many benign programs are not placed into clusters with malware parts and how many malware parts are. Recall measures how many malware parts are in clusters with other malware parts. Precision measures how many few benign programs are clustered with malware parts. The F-score is the geometric mean of recall and precision.
Correlating Live Processes
A second set of dynamic-analysis experiments correlated the running processes of ManyEyes on a Windows system. In these we captured 120 memory dumps of benign processes and two of ManyEyes. The dumps captured were only of memory regions marked as executable. One ManyEyes version was composed of five code-gathering subprograms, five key-monitoring programs, and a single log aggregator. Since this configuration resulted in six parallel processes, we call it the 6-piece ManyEyes instance. The second version was composed of fifteen code-gathering subprograms, fifteen key-monitoring subprograms, and five log-aggregators. Because this resulted in twenty parallel processes, we call it the twenty-piece ManyEyes instance. Experiments were repeated without entropy analysis, without metamorphism, and without both.
Collecting data from live processes was challenging. Data can represent uninitialized portions of the memory with zeros or data from previous processes. Some of it can be ignored in analysis by examining its entropy and excluding sequences with very low or very high entropy. We examined sixteen-byte chunks of data and removed portions that had entropies higher than 0.7 or lower than 0.3 of the maximum value. To produce the memory dumps, we created a tool named "MemoryScanner" to capture executable regions of memory on a Windows system. We chose to build our own tool to get greater control of what data it accessed. The tool uses the Windows ReadProcessMemory applications programing interface and avoids memory regions protected by PAGE_NOACCESS and PAGE_GUARD permissions. The tool does not address potential image "smear" from reading memory while it is changing.
Table 1 shows the average results of our static analysis experiments with malware split into five or fifteen parts. High values of the statistics of cluster accuracy, precision, recall, and the F-score indicate clusters had more malware parts. We see that about half of malware pieces when five parts were used were put in a single cluster, which indicates that clues to malware occur even after splitting and obfuscation. For splitting into fifteen pieces, the precision increased significantly, but the recall decreased. This suggests that both positive and negative clues decrease as sizes become smaller.
Table 1. Statistics for the split-malware experiments.
|
Number of Parts into Which the Malware Was Split |
Average Accuracy |
Average Precision |
Average Recall |
Average F-Score |
|
5 |
0.9827 |
0.6927 |
0.5192 |
0.5935 |
|
15 |
0.9488 |
0.7935 |
0.3593 |
0.4946 |
Fig. 1 compares accuracy, precision, recall, and F-score for memory dumps of processes using a 20-piece instance of ManyEyes malware with fifteen key-monitoring processes and five log aggregators. When metamorphism was enabled and extreme-entropy code was not considered, the recall was much higher than in the other runs. This is surprising because the metamorphic engine tries to make correlation harder, and may be due to the limited variety of its dead-code instructions. When metamorphism was disabled so identical code occurred in the parallel key-monitoring subprograms, the recall increased when extreme entropy was removed.
Fig. 1. Performance of Clustering of 20-Piece ManyEyes Processes
Fig. 2 shows corresponding statistics for 6-piece ManyEyes experiments. Precision was much higher than in the 20-piece experiments when metamorphism was disabled. The F-score was highest when metamorphism was disabled and extreme entropy was not removed. The recall was highest when metamorphism was disabled regardless of whether extreme entropy was removed. These tests gave expected results when disabling metamorphism and removing extreme entropy, resulting in better correlation of ManyEyes' processes. The precision of each experiment was perfect except when metamorphism was disabled and extreme entropy was removed, which was the worst-performing of the 6-piece tests. Unlike with the 20-piece tests, removing extreme entropy did not improve performance. Uninitialized memory can contain code from other processes, which means that entropy analysis alone may not suffice to isolate a live process' executable code. These tests show that the correlating K-ary processes using statistics is possible but not guaranteed.
Fig. 2. Statistics of Clustering of 6-Piece ManyEyes Processes
This work explored the potential stealth of K-ary malicious code combined with traditional code-obfuscation techniques. In our implementation we saw that steganography, encryption, and metamorphism can increase K-ary malware stealth. Our results showed that they can protect malware by reducing its signatures and preventing correlation of its pieces when partitioned, but that such concealment was not perfect.
This work used a statistical method for correlating pieces of executables using cosine-similarity comparison of bigram histograms on running processes. Our experiments showed that it was an effective metric. Memory dumps of ManyEyes during execution were also compared to memory dumps of other benign programs and showed some ability to correlate K-ary malware processes, but the correlation was lower than with the static images.
One possible direction for K-ary malware design is for parts of the malware to monitor the others and restore any pieces that are removed by a system administrator or anti-malware program [9]. Shifting or permuting code across files could also protect K-ary files against signature-based detection. Grammars can automatically generate K-ary codes [45]. Techniques that would allow K-ary code to collaborate stealthily are another possibility.
The degree to which K-ary code will be used by malware authors to obfuscate their malware remains to be seen. Our results suggest that statistical analysis can however decrease the threat of K-ary code.
1. Ingram, M.: "Love-bug" virus damage estimated at $10 billion. World Socialist website. https://www.wsws.org/en/articles/2000/05/bug-m10.html (2000).
2. Palmer, D.: MyDoom: The 15-year-old malware that's still being used in phishing attacks in 2019. Zdnet. https://www.zdnet.com/article/mydoom-the-15-year-old-malware-thats-still-being-used-in-phishing-attacks-in-2019 (June 26, 2019).
3. Giles, M.: Triton is the world's most murderous malware, and it's spreading. Technology Review. https://www.technologyreview.com/2019/ 03/05/103328/cybersecurity-critical-infrastructure-triton-malware (March 9, 2019).
4. Zeter, K.: An unprecedented look at Stuxnet, the world's first digital weapon. Wired. https://www.wired.com/2014/11/countdown-to-zero-day-stuxnet (November 2014).
5. Liu, S.: Security software – statistics & facts. https://www.statista.com/topics/2208/security-software (January 9, 2020).
6. Cohen, F.: Computer viruses: theory and experiments. Computers & Security, 6(1), 22–35 (1987).
7. Chess, D., White, S.: An undetectable computer virus. In: Proc. Virus Bulletin Conference, Vol. 5, pp. 1–4 (September 2000).
8. Moubarak, J., Chamoun, M., Filiol, E.: Developing a Κ-ary malware using blockchain. In: Proc. NOMS 2018–2018 IEEE/IFIP Network Operations and Management Symposium, pp. 1–4 (April 2018).
9. Filiol, E.: Formalisation and implementation aspects of k-ary (malicious) codes. Journal in Computer Virology, 3(2), 75–86 (2007).
10. Young, A., Yung, M.: Cryptovirology: Extortion-based security threats and countermeasures. In: Proc. 1996 IEEE Symposium on Security and Privacy, pp. 129–140 (May 1996).
11. O'Kane, P., Sezer, S., Carlin, D.: Evolution of ransomware. IET Networks, 7(5), 321–327 (2018).
12. Harter, G.: Metamorphic and polymorphic techniques for obfuscation of k-ary malicious codes. M.S. thesis, U.S. Naval Postgraduate School, http://calhoun.nps.edu (March 2020).
13. Desai, P., Stamp, M.: A highly metamorphic virus generator. International Journal of Multimedia Intelligence and Security, 1(4), 402–427 (2010).
14. Dalla Preda, M., Di Giusto, C.: Hunting distributed malware with the κ-calculus. In: International Symposium on Fundamentals of Computation Theory, pp. 102–113 (August 2011).
15. Saeed, I., Selamat, A., Abuagoub, A.: A survey on malware and malware detection systems. International Journal of Computer Applications, 67(16) (2013).
16. You, I., Yim, K.: Malware obfuscation techniques: A brief survey. In: Proc. of the 2010 IEEE International Conference on Broadband, Wireless Computing, Communication, and Applications, pp. 297–300 (November 2010).
17. Gaikwad, P., Motwani, D., Shinde, V.: Survey on malware detection techniques. International Journal of Modern Trends in Engineering and Research, 21(7), 1–25 (2015).
18. Bazrafshan, Z., Hashemi, H., Fard, S. M. H., Hamzeh, A.: A survey on heuristic malware detection techniques. In: Proc. 5th IEEE Conference on Information and Knowledge Technology, pp. 113–120 (May 2013).
19. Wong, W., Stamp, M.: Hunting for metamorphic engines. Journal in Computer Virology, 2(3), 211–229 (2006).
20. Schmall, M.: Heuristic techniques in AV solutions: An overview. https://www.symantec.com/connect/articles/heuristic-techniques-av-solutions-overview (2002).
21. Bachaalany, E., Koret, J.: The antivirus hacker's handbook. Wiley, New York (2015).
22. Eskandari, M., Hashemi, S.: Metamorphic malware detection using control flow graph mining. Int. J. Computers and Scientific Network Security, 11(12), 1–6 (2011).
23. Szor, P.: The art of computer virus research and defense. Addison-Wesley Reading, MA, US (2005).
24. Lee, J., Jeong, K., Lee, H.: Detecting metamorphic malwares using code graphs. In: Proc. 2010 ACM Symposium on Applied Computing, pp. 1970–1977 (March 2010).
25. Schiffman, M.: A brief history of malware obfuscation: Part 1 of 2. Cisco. https://blogs.cisco.com/security/a_brief_history_of_malware_obfuscation_part_1_of_2 (2010).
26. Webroot: Webroot threat report. https://www-cdn.webroot.com/9315/ 5113/6179/2019_ Webroot_Threat_Report_US_Online.pdf (2019).
27. Alvarez, R.: Dissecting a metamorphic file-infecting ransomware. https://www.youtube.com/watch?v=vJ08_6CCd6g (March 26, 2018).
28. Bulazel, A., Yener, B.: A survey on automated dynamic malware analysis evasion and counter-evasion: PC, mobile, and web. In: Proc. of the 1st ACM Reversing and Offensive-oriented Trends Symposium, p. 2 (November 2017).
29. Gao, Y., Lu, Z., Luo, Y.: Survey on malware anti-analysis. In: Fifth IEEE International Conference on Intelligent Control and Information Processing, pp. 270–275 (August 2014).
30. Kulchytskyy, O. Kukoba, A.: Anti debugging protection techniques with examples. https://www.apriorit.com/dev-blog/367-anti-reverse-engineering-protection-techniques-to-use-before-releasing-software (May 23, 2019).
31. Chen, W.: Encapsulating antivirus (AV) evasion techniques in the Metasploit framework. https://www.rapid7.com/globalassets/_pdfs/whitepaperguide/rapid7-whitepaper-metasploit-framework-encapsulating-av-techniques.pdf (October 9, 2018).
32. Popov, I., Debray, S., Andrews, G.: Binary obfuscation using signals. In: Proc. USENIX Security Symposium, pp. 275–290 (August 2007).
33. Rowe, N. C., Rrushi, J.: Introduction to cyberdeception. Springer, Chaum SU (2016).
34. SentinelOne: Hiding code inside images: How malware uses steganography. https://www.sentinelone.com/blog/hiding-code-inside-images-malware-steganography (July 4, 2019).
35. Yoon, S.: Steganography in the modern attack landscape. https://www.carbonblack.com/ 2019/04/09/steganography-in-the-modern-attack-landscape (April 9, 2019).
36. Ramilli, M., Bishop, M.: Multi-stage delivery of malware. In: Proc. 5th IEEE International Conference on Malicious and Unwanted Software, pp. 91–97 (October 2010).
37. Arntz, P.: Explained: Packer, cryptor, and protector. https://blog.malwarebytes.com/cybercrime/malware/2017/03/explained-packer-crypter-and-protector (2017).
38. Guo, F., Ferrie, P., Chiueh, T: A study of the packer problem and its solutions. In: Proc. International Workshop on Recent Advances in Intrusion Detection, pp. 98–115 (September 2008).
39. Ramilli, M., Bishop, M., & Sun, S.: Multiprocess malware. In: Proc. 6th IEEE International Conference on Malicious and Unwanted Software, pp. 8–13 (October 2011).
40. Solairaj, A., Prabanand, S., Mathalairaj, J., Prathap, C., & Vignesh, L.: Keylogger software detection techniques. In: Proc. 10th IEEE International Conference on Intelligent Systems and Control (ISCO), pp. 1–6 (January 2016).
41. Zer0Mem0ry: RunPE. https://github.com/Zer0Mem0ry/RunPE/blob/master/RunPE.cpp (2016).
42. Garfinkel, S., Farrell, P., Roussev, V., Dinolt, G.: Bringing science to digital forensics with standardized forensic corpora. Digital Investigation, 6, S2-S11 (August 2009).
43. Rowe, N.: Finding contextual clues to malware using a large corpus. In: Proc. ISCC-SFCS Third International Workshop on Security and Forensics in Communications Systems, Larnaca, Cyprus (July 2015).
44. McInnes, L., Healy, J.: Accelerated hierarchical density clustering. Proc. Workshop of the IEEE Intl. Conf. on Data Mining, pp. 33-42 (May 2017).
45. Gueguen, G.: Van Wijngaarden grammars and metamorphism. Proc. Sixth Intl. Conf. on Availability, Reliability, and Security, Vienna, AT, pp. 466-472 (2011).