Cridex, Feodo, Geodo, Dridex, whats next?

In June 2014 I blogged about some new development on the Feodo / Cridex front. While Feodo was pretty active in Germany in January 2014, it suddenly disappeared. In June 2014 Feodo reappeared with a new program code – Geodo was born. For me it was not clear whether the disappearance of Feodo was a direct response to the launch of Feodo Tracker. However, a few days after I announced that I extended Feodo Tracker in order to track Geodo, Geodo suddenly disappeared as well.

Roughly a month later, my friends over S21sec reported the appearance of another new Feodo variant: Dridex.

Together with friends from the infosec community I started to investigate Dridex. One of the most interesting things is that while Feodo and Geodo has been spammed out massively in Germany and were targeting financial institutions there, Dridex obviously has a different focus. Looking into one of the recent Dridex configuration files reveals different botnets that are targeting financial institutions in the US, UK and CH.

While the attackers have abused well known German brands such as Deutsche Telekom, O2 and Vodafone for their spam runs to spread Geodo in Germany, they are now abusing UK based brands such as British Telecommunications (BT) to spread Dridex in the UK.

Overall it seems that the modus operandi didn’t change much with Dridex: The attackers are still using spam emails to spread Dridex, abusing stolen SMTP credentials. Dridex botnet controllers are still hosted on compromised boxes and are running an nginx daemon that is usually listening on port 8080 TCP. What has changed is the URL structure of Dridex botnet C&C communication. The URL structure and code varies between each variant.

Taking a look at one of the recent Dridex configuration files reveals additional botnet C&C IPs used for Dridex backconnect, VNC module and webinjects (“redirects”) that vary for each Dridex botnet:

<bconnect>5.135.28.113:443</bconnect>
    <vncconnect>5.135.28.109:9955</vncconnect>
   <redirects>
      <redirect name="1st" vnc="0" socks="0" uri="http://62.76.44.174:8080/injectgate" timeout="20">twister5.js</redirect>
      <redirect name="2nd" vnc="1" socks="1" uri="http://50.56.34.20:8080/tokengate" timeout="20">mainsc5.js</redirect>
      <redirect name="vbv1" vnc="0" socks="0" uri="http://37.139.47.177:8080/logs/ukvbvg/js.php" timeout="20">/logs/ukvbvg/js.php</redirect>
      <redirect name="vbv2" vnc="0" socks="0" uri="http://37.139.47.177:8080/logs/ukvbvg/in.php" timeout="20">/logs/ukvbvg/in.php</redirect>
      <redirect name="logs1" vnc="0" socks="0" uri="http://37.139.47.177:8080/logs/in.php" timeout="20">/logs/in.php</redirect>
   </redirects>

Like the GameOver ZeuS Botnet (GOZ), it appears that Dridex is based on a Malware-As-Service (MSA) model as well. Different botnets targeting different financial institutions and countries, but using the same malware.

In mid August 2014, I’ve started to list Dridex botnet C&Cs on Feodo Tracker as well. These are labelled as Version D on Feodo Tracker and are getting pushed into the Feodo Tracker Blocklists.

Malware Feodo Tracker naming
Feodo Version A / Version B
Geodo Version C
Dridex Version D

Now, let’s see if this gang abandon Dridex as fast as they abandoned Feodo and Geodo.

Some recent Dridex C&Cs:

108.166.70.44:8080
202.124.205.84:8080
85.214.26.248:8080
178.208.81.204:8080

Some recent Dridex malware samples (MD5):

532e7924f759aab014dedca651398ce6
818bb82d1845eacedabdd5d0a5de310c
fab100a415254de5c8af70eb1c7eb2d0
95d4a587ac1a128db890035793483885
f8edaacbfc88a8f045bf2bbbd75c435b

Follow abuse.ch on Twitter:
https://twitter.com/abuse_ch

Introducing: SSL Blacklist (SSLBL)

In the past year, there was a lot of discussion about Secure Sockets Layer (SSL). More service providers and internet users started using SSL for access to various services. But not only regular internet users and internet services have been using SSL encryption more. Cybercriminals also rely on SSL more often in order to bypass IDS / IPS based detection mechanisms and content scanners.

A while ago I started to play a bit with an open source intrusion detection / prevent system (IDS / IPS) called Suricata, which is being developed and maintained by the Open Information Security Foundation (OISF). A cool feature that Suricata comes with is an SSL/TLS module which is able to fingerprint SSL/TLS certificates. Since some malware families switched from plain HTTP to HTTPS recently, I decided to maintain and publish a collection of SHA1 fingerprint associated with bad SSL certificates.

Introducing: SSL Blacklist (SSLBL)

The goal of SSLBL is to provide a list of bad SHA1 fingerprints of SSL certificates that are associated with malware and botnet activities. Currently, SSLBL provides an IP based and a SHA1 fingerprint based blacklist in CSV and Suricata rule format (see SSLBL for more information). SSLBL helps you in detecting potential botnet C&C traffic that relies on SSL, such as KINS (aka VMZeuS) and Shylock. Happy malware hunting!

Follow abuse.ch on Twitter:
https://twitter.com/abuse_ch




economics-recluse
Scene
Urgent!