Four Common Scenarios for Dormant Functionality in Malware

Image

Malware is continually evolving to meet the challenges posed by security researchers and antivirus software. Recently, malicious programs have begun to incorporate evasive behaviors, which include four of the most common anti-detection techniques: 1) environmental awareness, 2) confusing automated tools, 3) timing-based evasion, and 4) obfuscating internal data. The way in which malware integrates these tactics differs significantly. Whereas the Rombertik malware emphasizes many of these most common behaviors at once, others, such as Black POS, may demonstrate resilience with regards to one technique--in this case, using timing-based evasion to check the infected system's time with the hardcoded time stamp on the executable--as opposed to others. The tactic used by Black POS in some ways identifies with a phenomenon known as dormant functionality. A persistent problem in the fight against malware, dormant functionality occurs when only a small subset of malicious code that could otherwise be executed under certain conditions is actually initialized, as explained in a paper published by a group of security researchers at the Technical University of Vienna. Dormant code is a known facet of evasive malware, but it is also evident in non-evasive malicious samples, as well. A recent blog post published by advanced persistent threat (APT) defense firm Lastline identifies four common scenarios in which dormant functionality may manifest in malware. These are as follows:

Scenario #1: Dependency on External Infrastructure

Malicious code frequently relies on communicating with some sort of external infrastructure, such as a command-and-control (C&C) server. In some situations, the malware might not be able to contact a particular C&C server; in others, the server might not send the necessary commands that instruct the malware to execute its code. Additionally, depending on the duration of time that elapses between initial infection and execution, the malware's authors may change the address of the C&C, thereby preventing that particular sample from taking any subsequent action. In all of these cases, dormant functionality would be evident.

Scenario #2: Internal Component Dependency

Many large malware families, including APTs, consist of multiple components. Each of these subsections is usually designed to execute a specific task, such as downloading a payload's code from the Internet. However, they commonly rely on other components to work correctly. For instance, in the PlugX malware family, members depend on downloading both an injection and decryption component from the Internet in order to execute a payload. Analyzing the download component may help reveal the payload, but without the injection and decryption tools, the malicious behavior will never execute.

Image

Source: Lastline

Scenario #3: Missing/Expected Input

We now know that malware commonly relies on separate yet interdependent components to execute its payload. These components, in turn, also require a set of arguments to execute a given task or behavior. A common example of this is a remote access Trojan (RAT) that does not execute any of the malicious functionality itself but which is nevertheless used as a utility to inject libraries into existing processes on an infected machine.

Scenario #4: Broken Packer

Most malware use a custom packer to evade signature-based anti-virus software today. However, as many packers break down or lack compatibility with a sample's code, malware commonly terminate all action before they have a chance to reveal their encrypted payload.

Conclusion

Dormant functionality is evident in a variety of malware today, including the Wild Neutron threat actor recently analyzed by Kaspersky Labs. This pervasiveness demands that security researchers adopt new strategies in the fight against malicious software. What is needed are solutions such as those employed by Lastline that can analyze all code within a program--even sections that are not executed--and examine instances of dormant functionality in the context of sandbox runs during which the inactive code may have executed. By incorporating these techniques, researchers can more effectively mitigate the occurrence of dormant functionality. To learn more about dormant functionality and how Lastline's solution can defend against this threat, please click here. _{Title image courtesy of ShutterStock}