Please note we have recently updated our Privacy Policy, effective May 24, 2018. You may view the updated Privacy Policy here.
By using this website, you consent to the use of information that you provide us in accordance with the Privacy Policy.


Screenshot Demo: Detecting Banking Trojan “Dyre/Dyreza” with Bit9 + Carbon Black

detecting banking trojan dyre/dyrenza with bit9 carbon black horse knight
February 9, 2015 / Rob Eberhardt

Within the last year, a new banking trojan has begun targeting large enterprises and major financial institutions. The malware, called “Dyre” or “Dyreza,” is typically spread through spam or phishing emails.

If Dyre evades detection, the malware grabs sensitive user information such as credentials, certificates, and session information, using a browser man-in-the-middle attack. There are many variants of Dyre in the wild, and they typically target very specific activities, such as banking websites and even data-storing sites like

Dyre and its ever-changing list of variants have proven difficult or even impossible to detect by antivirus, memory-based scanning products, and next-gen perimeter defenses. In this screenshot tutorial, we will dissect a basic Dyre infection to show some simple methods of detection and prevention using Bit9 + Carbon Black.


As with most malware, there are many variants and behavioral differences between samples. Testing for this tutorial was done on a Windows 7 Virtual Machine with both Carbon Black 5.0 and Bit9 7.2 agents loaded (Bit9 in medium enforcement mode Bit9)

Two Dyre samples were tested:

SHA-256: 05edcc3e5679ee254c78058c4f446e195544d3ff3374bd141c1895e7ed6a410b

  • Tested as Dyre_Unpacked.exe

SHA-256: 523b9e8057ef0905e2c7d51b742d4be9374cf2eee5a810f05d987604847c549d

  • Tested as Document-772976_829712.scr

We created a firewall rule to disallow ANY Internet connectivity from this particular VM and I highly recommend isolating this host on an alternate VM network, as well.

Upon execution, Bit9 in medium enforcement prompted for execution. I clicked “Allow” to allow execution. The root executable immediately disappeared (deleted itself) and the machine seemed otherwise unaffected.

I then opened the Carbon Black console and searched for the root executable:


Process Analysis shows root executable and child process of “Googleupdaterr.exe”


Some items of interest to consider:

  • The Creation/execution of “Googleupdaterr.exe” or “exe:zone.identifier”
  • Location of file creation “C:\users\CURRENTUSER\appdata\local”


The second stage payload items of interest below:

  • First stage payload deleted itself
  • Resulting executable “Googleupdaterr.exe” makes itself resident in the registry
  • exe creates a mutex/process injected into explorer.exe


Opening a new view of Explorer.exe during the same time frame gets interesting:


Checking network connections of Explorer.exe shows some interesting behavior as well:


  • Connection to (Checking to see if it has internet)
  • Connection to a STUN (session traversal utilities for NAT) server to create an SSL-encrypted session
  • Connections to other IPs that happen to be on some RBLs (real-time blacklists)
  • Second tested Sample showed different connections, albeit similar behavior


Detection via Watchlist

Dyre/Dyreza has plenty of variants and behaviors. The list below may not be 100 percent comprehensive for your sample. Below are some of the recurring patterns that should make detection via watchlist very easy.

Carbon Black watchlist query strings to get you started:

Windows Explorer.exe is making multiple network connections (UNC and other connections typically come from ntoskrnl.exe, svchost.exe, etc. Explorer tends to make domain-local connections on rare occasions for local-network discovery. 1 might be a bit noisy, 2-3 might be a good starting point):

  • netconn_count:[1 TO *] process_name:explorer.exe

Typical Dyre/Dyreza registry modification to maintain persistence:

  • regmod:software\microsoft\windows\currentversion\run

Other Dyre/Dyreza earmarks:

  • path:c:\windows\*.exe -path:c:\windows\*\* -process_name:explorer.exe
    -process_name:regedit.exe -process_name:splwow64.exe

Execution directly from Users Application Data folders:

  • path:c:\users\*\appdata\local\* -path:c:\users\*\appdata\local\*\*

iSCSI client loading a child process of cmd.exe:

  • parent_name:iscsicli.exe modload: cmd.exe

Unsigned processes with cross-process activity into explorer.exe:

  • crossproc_name: “explorer.exe” digsig_result: “Unsigned”

Binaries of a malicious nature attempting to make network connections (low hit count, as Dyre seems to make connections from legitimate processes):

  • alliance_score_virustotal:[10 TO *] netconn_count:[1 TO *]

Use DNS RBLs (real-time blacklists) to fortify Carbon Black and alert on connections to known-bad IPs/DNS entries

Bit9 rules and suggestions:

  • Autoruns (at least alert – will block legitimate modifications)
    • Registry rule
    • Write action: prompt or alert
    • Registry path: *\software\microsoft\windows\currentversion\run\*
    • Process: any process
  • Alternative autoruns method
    • Registry rule
    • Write action: block
    • Registry path: *\software\microsoft\windows\currentversion\run\*
    • Process: googleupdaterr.exe or iscsicli.exe
  • Block batch files from executing inside of AppData (You can get less specific on the Path, but risk blocking custom apps)
    • Custom rule
    • Rule type: execution control
    • Execution action: block
    • Path or file: C:\Users\*\AppData\Local\Temp\*
  • Block (and alert) on creation of the typical Dyre/Dyreza configuration file
    • Custom rule
    • Rule type: file creation control
    • Write action: block
    • Path or file: C:\users\appdata\local\userdata.dat
    • Process: any process
  • Move machines to high-enforcement mode

**A special thanks to a Carbon Black customer who contributed some content ideas for this blog**