Dridex is Watching You

The Dridex authors frequently release updates such as new functions obfuscation and new configuration encoding to continue evading detection and mitigation techniques of security vendors. They have shifted the focus of their malware from targeting European financial institutions to new banking institutions in the United States.

Evidently, the developers of the malware display great proficiency in client and server paradigms as well as obfuscation. The following research outlines this skillset. It, along with Dridex authors’ commitment to the constant and frequent updates in the malware’s features, makes Dridex very agile and consequently hard to detect, decrypt, and analyze.

How Does Dridex Watch You?

So, how is it that Dridex is watching you without your permission and you don’t know it?

It connects to the infected user’s machine during banking transactions with a remote session. This session is invisible to the user because it is held in another instance of the desktop that the malware opens using the VNC protocol. This instance is duplicated but not shared, meaning the attacker can’t see the user’s mouse and keyboard movement and vice versa.

After the malware is installed on a victim’s machine, it "phones home" to the Command and Control (C&C) of the botnet in order to get the target list and ask for the following modules: VNC and SOCKS.

The activation process can be triggered in one of two ways:

• By a command received from the C&C
• By the browser function hook after inspecting the VNC flag in the configuration

This research focuses on the injected module approach. (The way that VNC initiation has been triggered inside the Dridex configuration was described in an earlier F5 article.)

VNC Activation Flow

The flow involves interaction between the infected browser and the infected explorer.exe process.

The Browser’s Role

The VNC flag in the configuration is inspected by the malicious code in the network function hook which Dridex injected into the browser.

1. This hook enables Dridex to inspect each request before it is sent over the wire.
   
   

1. If the request url matches a url in the “redirects” configuration, a request for the malicious script is sent to the c&c from the hooked network function.

So a targeted url was accessed and a malicious script was sent to the user. What’s next?

2. When the script is received, the VNC flag is inspected.
   If the VNC flag is on, the malware expects to receive encrypted data. This encrypted data contains information which the malware uses later on:

   • VNC IP and PORT — the remote address to connect to when launching the VNC session
   • SOCKS IP and PORT — the remote address to connect to when launching the SOCKS session
   • The data is encrypted using a XOR (the first 4 bytes are the key)

Below is an example of a simple html response from the server with IP + Port appended (after decrypted routine):

The infected browser stores these encrypted IP records in the registry under the same key as the configuration but under a separate subkey.
 

The infected browser uses Windows’ events objects API in order to inform the infected explorer.exe to start the VNC. From this point, the infected explorer process takes over the activation process.

Explorer’s Role

1. The malicious code in Explorer runs in an endless loop in a dedicated thread that is responsible for the VNC connection and waits for the event signal from browser. Once this signal is received, it extracts the IP + Port records from the registry and decodes them.

1. Explorer loads the vnc_x32.dll using a custom implementation of the Windows API “LoadLibrary”.
   • Before this point, the VNC module resides in Explorer’s memory as raw data.
   • After mapping all the PE sections, it calls DllEntryPoint of the vnc.dll (with DLL_PROCESS_ATTACH flag)
   • This technique obfuscates the point in time where the VNC module is loaded, since it is not possible to follow “LoadLibrary”, making it much harder to analyze.

1. vnc_x32.dll exports two functions to start and stop the server.

 

 

1. Explorer’s worker module calls the VncStartServer function with IP and port as parameters in order to launch the VNC connection.
    

    

 

1. In case an external VNC IP address was received without the SOCKS module involved, the VNC module initiates a connection to the attacker’s VNC server. The infected machine initiates the remote session. This is a unique way of using the protocol since usually the viewee acts as server.
   • If a local VNC address was received, the Dridex module will listen to incoming VNC connection from the attacker.

 

 

2. After establishing a TCP connection to the VNC server, vnc_x32.dll uses the bot_id string – passed as a parameter to VncStartServer routine, in order to generate a challenge. This is used in order to verify the server’s identity before the VNC protocol handshake takes place.

    

 

After this, if all the stages are successful, a VNC remote session is started and the fraudster can perform actions on the victim’s machine without his knowledge.

This feature is usually used as a complementary action after credentials stealing in order to bypass security products within the bank. These products aim to identify the user using the browser’s unique fingerprint.

F5’s Research Team is Watching Dridex

The constant race between security vendors and cybercriminals pushes criminals into creating malware that is more obfuscated and has many different and independent components. These components help the malware authors overcome the obstacles and safeguards that banking institutions and security vendors put in place. These components also add a layer of complexity to the analysis process since it is now necessary to understand the interaction between the modules.

This race also pushes us, as researchers, to monitor and be vigilant regarding Dridex’ campaigns and evolution.