Dridex, also known as Cridex, Bugat, Feodo, Geodo, is a banking trojan that is currently distributed via spam with malicious documents as attachments. The victims are lured into opening the file allowing a malicious macro to launch and download additional payloads. Dridex makes use of ‘httpinjects’ to modify a website of a financial institution within the browser of an infected user in order to steal personal and financial information. Dridex, as with the Dyre banking Trojan, is a currently active malware family comprised of various botnets, each of which has a slightly different geographical focus.
Based on a snapshot of activity in early April 2015, the activity map image (fig 1.), shows the victim distribution of the various Dridex botnets with the coloured lines representing botnet ID and connection between victim and the command and control (C2) server
Analysis of this activity allows victimology and the modus operandi of those behind each campaign to be determined. For example, as indicated by the orange line, Dridex botnet ID 220 showed an increased victim distribution in South Africa. Likely indicative of a successful Dridex spam campaign in that region, this activity appears atypical for a botnet identified as normally targeting UK financial institutions.
Team Cymru has been tracking at least nine different botnet/campaign variants in the last month, and it is observed that some are more active than others. Figure 2 shows the victim distribution of three of the most active botnets.
Dridex cotinues to demonstrate an active development life cycle with the developer(s) frequently updating and changing the way the malware communicates with its command and control infrastructure. Whilst early versions of the malware communicated over port 8080, recent versions show that controllers are now more prevalent on port 80, likely an attempt to hide their activity amongst the ‘noise’ of legitimate traffic.
Communication mechanisms between the victim and controller are also updated regularly, most recently with the introduction of SSL in the first stages of communication. The architecture of Dridex is such that it uses a number of layers/stages, in an attempt to make disruption and detection of the network less successful. The use of obfuscation techniques, such as the use of fake referrer and Host headers, are also employed in an attempt to make the traffic sent by a victim to the controller appear legitimate. However, an oversight by the malware developer within this host field, specifically the omission of a period between the domain and top level domain, served as a useful indicator of compromise until the malware switched to SSL for this stage in the communication.
The Dridex infrastructure can be separated into three or four layers. Typically, the first communication takes place after the victim has been infected via a malicious document macro. This macro will download the dridex ‘loader’, which then connects to the second stage nodes in the infrastructure to download the Dridex DLL. This Dridex DLL will then connect to a list of stage three nodes to report itself to the command and control server and receive a configuration file that includes information about httpinjects to use. Our research indicates Dridex actor use compromised machines in their infrastructure and at times promote infected victims machines to infrastructure nodes should they exhibit suitable traits, for example, high-bandwidth connectivity..
What does Dridex communication look like in the ‘real world’?
The following video visualises victim activity for the first two weeks of April 2015.