Detecting Dridex variants using Security Analytics

Blog Post created by ahsonbol on Dec 3, 2015

For the last few weeks, Dridex campaigns have been on the rise. The banking trojan spreads through well-crafted spam e-mails that employ social engineering techniques to trick a user into running a macro in an attached Microsoft Word document or a Microsoft Excel spreadsheet. In this blog post, we will discuss how to detect Dridex network activity using RSA Security Analytics.

When the macro code runs, it downloads Dridex to the infected machine. This is how the download session looks like in RSA Security Analytics:


Downloading executables is not necessarily malicious but it is always worth another look. One way to find this kind of traffic in Security Analytics is to use the following query:

          service = 80 && filetype='windows_executable'

Newer variants of Dridex use SSL to communicate with their C2 servers over non-standard ports. As with other malware families, the servers use self-signed certificates for SSL communication.


Although the SSL network activity shown above is not unique to Dridex, it is safe to say that it is suspicious enough to draw an analyst interest. Assuming the appropriate meta keys are enabled, the following query can be used to detect it:

          risk.suspicious = 'ssl certificate self-signed' && risk.info = 'ssl over non-standard port'

You can find VirusTotal scan results for one Dridex variant here.

All of the IOCs from those sessions were added to the following RSA FirstWatch Live feeds:

  • RSA FirstWatch Command and Control IPs
  • RSA FirstWatch Command and Control Domains

If threat.desc meta key is enabled then you can use the following app rule:
          threat.desc = ' c2-dridex'