Dridex is Watching You

F5 Ecosystem | June 22, 2016

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.

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?

  1. 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)
Dridex Figure 1: Full decryption routine
Figure 1: Full decryption routine

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

alt="Dridex Figure 2: Decrypted script content; the IP and the PORT are appended"
Figure 2: Decrypted script content; the IP and the PORT are appended

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

Dridex Figure 3: The IP and PORT registry records
Figure 3: The IP and PORT registry records

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.
Dridex Figure 4: The infected browser writes the records before the infected explorer.exe reads them
Figure 4: The infected browser writes the records before the infected explorer.exe reads 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.
Dridex Figure 5: explorer.exe – the original explorer code, worker_x32.dll – the main Dridex module, vnc_x32.dll – the vnc module
Figure 5: explorer.exe – the original explorer code, worker_x32.dll – the main Dridex module, vnc_x32.dll – the vnc module
  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.
     
Dridex Figure 7: The call to VNCStartServer with parameters
Figure 7: The call to VNCStartServer with parameters

  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.

  1. 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.

Dridex Figure 8: Victim and attacker communications scheme
Figure 8: Victim and attacker communications scheme

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.

Share
Tags: 2016

About the Author

Related Blog Posts

F5 accelerates and secures AI inference at scale with NVIDIA Cloud Partner reference architecture
F5 Ecosystem | 10/28/2025

F5 accelerates and secures AI inference at scale with NVIDIA Cloud Partner reference architecture

F5’s inclusion within the NVIDIA Cloud Partner (NCP) reference architecture enables secure, high-performance AI infrastructure that scales efficiently to support advanced AI workloads.

F5 Silverline Mitigates Record-Breaking DDoS Attacks
F5 Ecosystem | 08/26/2021

F5 Silverline Mitigates Record-Breaking DDoS Attacks

Malicious attacks are increasing in scale and complexity, threatening to overwhelm and breach the internal resources of businesses globally. Often, these attacks combine high-volume traffic with stealthy, low-and-slow, application-targeted attack techniques, powered by either automated botnets or human-driven tools.

F5 Silverline: Our Data Centers are your Data Centers
F5 Ecosystem | 06/22/2021

F5 Silverline: Our Data Centers are your Data Centers

Customers count on F5 Silverline Managed Security Services to secure their digital assets, and in order for us to deliver a highly dependable service at global scale we host our infrastructure in the most reliable and well-connected locations in the world. And when F5 needs reliable and well-connected locations, we turn to Equinix, a leading provider of digital infrastructure.

Volterra and the Power of the Distributed Cloud (Video)
F5 Ecosystem | 04/15/2021

Volterra and the Power of the Distributed Cloud (Video)

How can organizations fully harness the power of multi-cloud and edge computing? VPs Mark Weiner and James Feger join the DevCentral team for a video discussion on how F5 and Volterra can help.

Phishing Attacks Soar 220% During COVID-19 Peak as Cybercriminal Opportunism Intensifies
F5 Ecosystem | 12/08/2020

Phishing Attacks Soar 220% During COVID-19 Peak as Cybercriminal Opportunism Intensifies

David Warburton, author of the F5 Labs 2020 Phishing and Fraud Report, describes how fraudsters are adapting to the pandemic and maps out the trends ahead in this video, with summary comments.

The Internet of (Increasingly Scary) Things
F5 Ecosystem | 12/16/2015

The Internet of (Increasingly Scary) Things

There is a lot of FUD (Fear, Uncertainty, and Doubt) that gets attached to any emerging technology trend, particularly when it involves vast legions of consumers eager to participate. And while it’s easy enough to shrug off the paranoia that bots...

Deliver and Secure Every App
F5 application delivery and security solutions are built to ensure that every app and API deployed anywhere is fast, available, and secure. Learn how we can partner to deliver exceptional experiences every time.
Connect With Us
Dridex is Watching You | F5