# Investigating Anti-Evasion Malware Triggers Using Automated Sandbox Reconfiguration Techniques
## 7 Discussion
Clearly, the presence of \"Guest Additions\" is the most noticeable indicator that the environment is virtualised and could be a analysis sandbox, and so removal of this software as well as references to \"VirtualBox\", \"VBox\" or \"VMware\" in the registry would be a suitable first step for most investigations (11 samples triggered follow removal of guest additions). Table 1 shows that many of the Banking Trojans were triggered by the Reverse Turing Test, although not exclusively. IcedID required the RTT in conjunction with the Registry Edit, while the Tinba variants all required different evasion methods, including registry edits and common artefacts creation. The Time Jump method was required to provoke the Qakbot Infostealer to trigger, as well as the Nymaim Ransomware. Four of the samples (Adposhel, IcedID, Lokibot and Pushdo) required multiple evasion methods to be deployed, while all five evasion methods were observed within the dataset. Despite what is a seemingly low number of cases, this again highlights an important point: there are malware variants that will deploy multiple evasion methods. Even if this number is currently low (based on our current dataset), the reality is that more samples will adopt this approach in future. Much like a game of hide and seek, for the malware developer to hide this functionality in software is relatively trivial, yet for the malware analyst it is much more difficult to find, simply because there may be many possibilities of how the original developer specified the trigger. Adding multiple evasion methods would make a sample increasingly more successful at avoiding detection in a sandbox environment as the complexity of search by the analyst would increase exponentially. At the very minimum, our research would suggest that all five of the anti-evasion checks performed in MORRIGU should be tested in practice, as we have identified active threats in the wild that have triggered based on each of these. Importantly to reiterate, at the time of data collection the researchers had no knowledge of which anti-evasion methods would work for the different malware variants, and the malware was gathered based on the classification type of the malware rather than because of having evasive characteristics. In practice, an analyst may primarily want to study whether a sample will trigger or not, rather than the specific combination of anti-evasion methods that caused it to trigger. Therefore, one could perform a test using many anti-evasion checks, and then if a trigger is identified, work backwards to identify which checks caused the reaction to occur. We have illustrated how these checks could be performed, with relatively simple parameter selection. The five methods were adopted due to being common methods of malware evasion [2]. If we omit \"Guest Additions\", as this could be considered as initial configuration for most investigations, the remaining anti-evasion methods are complimentary as they examine different attributes about the system and its user (system time, system applications and parameters, user files and folder, and user interactions). While in theory there are further anti-evasion methods that could be imagined, they would typically fall within the scope of these four areas. Further research would, therefore, aim to explore more extensive parameter selection and modification for the anti-evasion checks. Evasive malware detection shares a number of commonalities with insider threat detection [38, 39]. In the case of insider threat detection, an adversary will have privileged access and knowledge about the organisation, and will want to perform some malicious act whilst concealing their behaviour. Likewise, malware developers will understand how analysts may utilise a sandbox environment to study malware samples, and will again aim to conceal their behaviours.