Don’t Click the Left Mouse Button: Introducing Trojan UpClicker

In one of the recent posts from Symantec, researchers shared the analysis of a malware that could evade automatic analysis in a sandbox environment. Evasion was done by hooking to the mouse. Per the analysis, SetWindowsHookExA() API installs the _main_routine to monitor messages from the mouse. When the malware receives messages from the mouse—that is, if the mouse is moved or buttons are clicked—the main subroutine executes. Since the automated analysis system does not use the mouse, the code will remain dormant, hence bypassing analysis by a sandbox.

Recently, we came across another sample, called Trojan Upclicker, that went one step further: using a mouse to evade automated analysis. The purpose of this posting is to share some of the finer technical details of using a mouse to evade detection along with the malicious behavior of Trojan Upclicker.

Per the code in Figure 1, the function SetWinodwsHookExA is called with 0Eh as a parameter. Per MSDN, the parameter 0Eh is used to hook a mouse. Pointer fn is the pointer to the hooked procedure in the code.


Figure 1. Code showing hooking to mouse

Per the code pointed by fn shown in Figure 2, the function monitors the mouse movements. It specifically monitors the click and release of the left mouse button.


Figure 2. Code pointed by pointer fn

Per the code shown in Figure 2, only when the left mouse button is released after being clicked is the function UnhookWindowsHookEx() called. The call to function UnhookWindowsHookEx() will unhook the malicious code from the mouse, after which the code makes a call to the function sub_401170(), which then executes the malicious code. Until the left mouse button is released, the code will remain dormant making it immune from automated analysis by a sandbox.

Once the malicious code of Trojan Upclicker is active, it makes a call to the function NtOpenProcess(). As shown in Figure 3, the first argument to the function points to the address 00120024. The value at the address is 0x05B8 which is 1464 in decimal. 1464, shown in Figure 3, is the process ID of Explorer. Once the left mouse button is clicked and released, Trojan Upclicker opens Explorer for code injection.


Figure 3. Trojan Upclicker performing code injection in Explorer

The injected code in Explorer makes a call to the function CreateProcessA. As shown in Figure 4, the argument to the function CreateProcessInternalA() is Opera.exe.


Figure 4. Injected code in Explorer starting Opera

A quick search in memory (as shown in Figure 5) for the created process for the browser Opera reveals the string for domain


Figure 5. Strings search in memory for process Opera.exe

Note that, after performing code injection in Explorer, the malicious code of Trojan Upclicker makes a call to the function ExitProcess(). The ExitProcess() function terminates the process of Trojan Upclicker.

When the malicious sample is executed in a controlled environment, a DNS query is generated for the domain


Figure 6. DNS query for the

When Trojan Upclicker receives the response to its DNS query for the domain, the malicious communication channel is established. The destination ports for the malicious communication channel are 80 and 443.


Figure 7. Malicious communications to

From the analysis it is concluded that the Trojan Upclicker establishes malicious communication only when the left mouse button is clicked and released. Since, in sandboxes, there is no mouse interaction, the malicious behavior of Upclicker remains dormant in a sandbox environment.

In order to process enormous amounts of samples, automated sandbox analysis is commonly being used by the anti-virus industry. To evade automated analysis, we expect to see more such samples that can use a specific aspect like pressing specific keys, specific mouse buttons, or movement of the mouse a certain distance to evade the automated analysis.

The blog was written by FireEye researchers Abhishek Singh and Yasir Khalid.