1. In Dire Straits: Straight Talk on Dyre
August 2015
Eric R. Jenko, Senior Security Researcher, CTU

2. Dyre :: Overview Dyre - a.k.a. “Dyreza”, “Dyzap”, “Dyranges”
Emerged early June 2014 after Operation Tovar
Evolved to be one of the most prominent banking trojans in circulation
Commonly referred to as a “banking trojan”
Primarily targets online banking websites to harvest credentials to commit Automated Clearing House (ACH) and wire fraud
May be more appropriate to consider it like a web proxy
It has the capability to “target” any website
At its core, it monitors traffic looking for specific targets
When a target is encountered, Dyre intercepts and manipulates the requests and responses

3. Dyre :: Distribution Vectors
UPATRE
CUTWAIL SPAM
Primarily distributed by spam from the Cutwail botnet
Initially via links to Dropbox or Cubby file storage services
Later leveraging Lerspeng and, most prominently, Upatre
Recent campaigns have used two other downloaders
Pony (a.k.a., “Fareit”) and Ruckguv (new)
Dyre (similar to Bugat v5) leverages private spam mailers

4. Dyre :: Architecture and Operation
Dyre consists of two modules
A dropper and the main DLL (both 32-bit and 64-bit versions)
Critical data is stored in the DLL’s resource section
Initial config, RSA key, Botnet ID, C2 servers
Modified copy is saved to and launched from C:\Windows
Registers “Google Update Service” system service for persistence
Newer versions are VM-aware – Checks available CPUs
Dyre’s persistence mechanism and drop location

5. Dyre :: Operation :: Connect and Register
Dyre checks Google for network connectivity
Dyre obtains its external IP address
STUN requests to hard-coded servers (Session Traversal Utilities for NAT)
Fallback method via icanhazip.com
Dyre registers with the C2 and pulls configs/plugins (using SSL)
Register the Bot: GET /CAMP_ID/BOT_ID/5/cert/EXT_IP/
Register the OS of the Bot: GET /CAMP_ID/BOT_ID/0/Win_XP_32bit/1023/EXT_IP/
Send “alive” signal: GET /CAMP_ID/BOT_ID/1/FcJgUwyCWvgLPymGiJGwUkwCVcBMmiD/EXT_IP/
Send NAT status: GET /CAMP_ID/BOT_ID/14/NAT/Port%20restricted%20NAT/0/EXT_IP/
CAMP_ID : Campaign ID | BOT_ID : Individual Bot identifier | EXT_IP : External IP Address

6. Dyre :: Operation :: Config and Plugin Retrieval
Web Injects config: GET /CAMP_ID/BOT_ID/5/respparser/EXT_IP/
Web Fakes config: GET /CAMP_ID/BOT_ID/5/httprdc/EXT_IP/
Grabber plugin: GET /CAMP_ID/BOT_ID/5/twgARCH/EXT_IP/
VNC plugin: GET /CAMP_ID/BOT_ID/5/n_vncARCH/EXT_IP/
TV plugin: GET /CAMP_ID/BOT_ID/5/n_tvARCH/EXT_IP/
Back Connect plugin: GET /CAMP_ID/BOT_ID/5/cfg_bc/EXT_IP/
I2P plugin: GET /CAMP_ID/BOT_ID/5/i2pARCH/EXT_IP/
CAMP_ID : Campaign ID | BOT_ID : Individual Bot identifier | EXT_IP : External IP Address | ARCH : Architecture

7. Dyre :: Operation :: Web Injects
Server Injects Bank Page
Web Inject Server
Config Match Acme Bank
Injected Web Page
user:eric pw:password123
Acme Bank
HTTP POST: user & pw, browser info, cookies
Exfil Server
Dyre’s injects happen dynamically at the C2
Allows for greater flexibility and less maintenance
Complicates analysis and investigation

8. Dyre :: Operation :: Web Fakes
Web Fake Server
Fake Acme Bank Page
Config Match Acme Bank
Fake Web Page
user: eric pw: password123
Acme Bank
Subsequent requests go to Web Fake Server
Target site is mimicked and hosted by the threat actors
Allows actors to dynamically change site pages and content
Complicates analysis and investigation

9. Dyre :: Command & Control Infrastructure
Geographic distribution of Dyre C2 servers (proxy layer) as of December 2014
Dyre uses a proxy layer to hide its backend (true) C2 infrastructure
Dyre can fall back on two additional control mechanisms:
Domain Generation Algorithm (DGA)
1, char domains daily for 1 of 8 ccTLDs in Asia & Pac. Islands
Invisible Internet Project (I2P) plugin (limited usage)

10. Dyre :: Best Practices
To reduce the risk and impact of compromises:
Staff Education/Training:
Ensure your organization’s security awareness and training program includes the dangers of and social engineering and utilizes up-to-date threat intelligence
Filtering:
Where feasible, employ filters and scan the contents of attachments
It’s also advisable to consider blocking with executable attachments, including those found in archives (ZIP, RAR, etc.)
Malware Sandbox Analysis:
Such inline technology should conduct automated analysis of hyperlinks and/or attachments within incoming to gauge potential maliciousness
Endpoint System Controls:
Endpoint controls should limit users’ ability to open malicious attachments and prevent malware installation and execution.
Keep end-user antivirus, operating system, browser, and other third-party software up to date.
Ensure an appropriate level of logging is enabled on hosts and the logs are routinely reviewed for anomalous/malicious activity
Network-based Controls:
Block I2P traffic at corporate firewalls
Apply post-infection controls such as firewall policies, web proxies
For additional information on Dyre, please read our Threat Analysis publication:

11. Questions?
Eric R. Jenko