Malware Behaves Oddly in Automated Analysis Environment

While testing malware recently, we got some logs from our automated analysis system showing a few samples that are only partially replicated. We have heuristics that predict the behavior of a sample; but if that prediction fails, then the heuristics identify the state of a sample and decide if it is worth sending to our second level of analysis. We took a close look at all the samples that were sent to the second level and found some interesting and strange behavior. We noticed that some samples behave differently when executed by a process that runs in background, without a window, compared with a process that execute samples with a visible window. To demonstrate, let’s take a look at the following example.

We executed the sample manually by double-clicking the executable as well as using the command prompt. Everything worked fine; we can see the running process in Process Explorer.

However, when we ran the same malware sample via a console-based application that started the malware process in suspended mode, it injected a DLL into the malware and terminated itself after resuming the malware process. Although we assume the malware is supposed to do more, it simply terminated without an error.

We further investigated the malware sample and suspect that it may need to check its parent process window before doing further activities. This behavior may not be intentional and seems to be an accidental event.

We ran the same sample again in a console-based application, but this time we made some minor modifications, such as adding sleep for couple of seconds after the ResumeThread. The malware sample ran accordingly:

Looking at the code, we saw a deviation in execution flow when the malware sample was executed by a process with a window or without a window.

The following code is responsible for the deviation. In each case, the sample used different arguments to CallWindowProcA API.

Loop:

RETURN ADDRESS: 0×00431962 CALL FUNCTION: USER32!CallNextHookEx
RETURN ADDRESS: 0x004391e7 CALL FUNCTION: KERNEL32!EnterCriticalSection
RETURN ADDRESS: 0x004391fb CALL FUNCTION: KERNEL32!TlsGetValue
RETURN ADDRESS: 0×00439211 CALL FUNCTION: KERNEL32!LeaveCriticalSection
RETURN ADDRESS: 0x004391e7 CALL FUNCTION: KERNEL32!EnterCriticalSection
RETURN ADDRESS: 0x004391fb CALL FUNCTION: KERNEL32!TlsGetValue
RETURN ADDRESS: 0×00439211 CALL FUNCTION: KERNEL32!LeaveCriticalSection
RETURN ADDRESS: 0x004391e7 CALL FUNCTION: KERNEL32!EnterCriticalSection
RETURN ADDRESS: 0x004391fb CALL FUNCTION: KERNEL32!TlsGetValue
RETURN ADDRESS: 0×00439211 CALL FUNCTION: KERNEL32!LeaveCriticalSection
RETURN ADDRESS: 0x0043a215 CALL FUNCTION: KERNEL32!EnterCriticalSection
RETURN ADDRESS: 0x0043a22b CALL FUNCTION: KERNEL32!InitializeCriticalSection
RETURN ADDRESS: 0x0043a238 CALL FUNCTION: KERNEL32!LeaveCriticalSection
RETURN ADDRESS: 0x0043a244 CALL FUNCTION: KERNEL32!EnterCriticalSection
RETURN ADDRESS: 0x0043a26c CALL FUNCTION: KERNEL32!LeaveCriticalSection
RETURN ADDRESS: 0x0042e009 CALL FUNCTION: USER32!CallWindowProcA

The message argument to CallWindowProcA when the sample was executed by a background process (without a window):

After the foregoing, the sample process terminated itself.

The message argument to CallWindowProcA when the sample was executed by a process with a visible window:

This sample runs nicely, without any problems.

We have not seen this type of behavior in any medium- or high-severity malware. The samples we analyzed showing this behavior are mostly installers for adware or spyware.

I thank my colleagues Benjamin Cruz and Vikas Taneja for their advice and assistance.