# Investigating Anti-Evasion Malware Triggers Using Automated Sandbox Reconfiguration Techniques
## 2 Related Works
### Evasion and Anti-Evasion Methods  
Context-aware malware will use numerous evasion techniques to avoid detection, with a technical report by LastLine reporting over 500 evasion techniques [18]. For example, a malware sample may wait for a specific time before executing, or for a specific number of keyboard or mouse events to have occurred. While seemingly trivial, these evasion techniques are increasingly used to determine whether the environment is a genuine target (i.e., a real system with a real user). Common evasion techniques may include system artefact checks, including the use of registry edits and virtual environment processes [2; 4; 19; 20; 21; 22; 23; 24; 25; 26], trigger-based behaviour [4; 19; 20; 26; 27; 28] and checks for human interaction [4; 19; 20; 26; 29; 30; 31].  
Anti-evasion methods are how the test environment can force, break or otherwise counter the evasion method. For example, the test environment may alter the system time to defeat a wait period, may install particular software to create a realistic system environment, or may simulate keyboard and mouse events to impersonate end user interaction. Our proposed system allows the user to examine the characteristics of malware when deploying different anti-evasion methods.  
In evasion detection, a system will attempt to identify the use of evasive malware behaviours in the program execution. This can be accomplished through the use of debugging tools or other execution tracers, such as DSD-Tracer [21], or multi-system analysis. Debugging tools (or execution tracers) monitor malware behaviour and look for suspicious instructions or known detection techniques, such as checks against system artefacts. However, such methods can be targeted using tools such as RDG Tejon Crypter, which offers analysis environment detection, with specific options for anti-debugging [32], through the use of opcodes such as _PUSHF_[2] or API calls [25]. [PERSON] et al. [33] found that 40% of malware samples tested exhibited less malicious behaviour within a debugging environment.  
[PERSON] et al. [27] investigate automated malware trigger analysis that aims to identify all possible trigger conditions so that an input can be given that will cause malware to execute as intended. However, one limitation to this approach is that it is unfeasible to follow all possible execution paths and so potentially some triggers are likely be missed. Similarly, [PERSON] and [PERSON] [24] use a pin tool that attaches to a process to intercept system calls to mislead malware, to check whether the malware is executed within a virtualised environment. For example, if the response to a check contains the string \"VMware\" then a replacement can be substituted instead (i.e., \"Microsoft\"). In this approach, it may be possible for the malware to identify the pin tool and therefore trigger a context-aware malware sample to act in a benign fashion [32]. [PERSON] et al. [34] adopt a multi-system approach for analysing malware with evasion detection by using four sandbox environments, each with a different system setup (three Windows XP virtual machines and one Anubis sandbox). Behavioural comparisons are made across all four environments when executing the malware sample to identify any significantly different behavioural patterns that may indicate particular configuration triggers. However, this is a computational expensive approach and is still susceptible to samples that could potential evade analysis under all environments, for example using network environment checks.