Top Banking Botnets of 2013

• Author: Dell SecureWorks Counter Threat Unit(TM) Threat Intelligence
• Date: 3 March 2014

Overview

Financial institutions have dealt with banking trojans for more than a decade, and the number of trojans targeting online banking transactions has increased dramatically during this span. This increase represents a challenge to financial institutions and their customers. Although banks have evolved their security measures to protect online transactions from fraud, attackers quickly adapt to these countermeasures and respond with sophisticated banking botnets.

Many banking trojans are used for the same purposes, although not all banking trojans are created equal. Some botnets possess sophisticated plugin-based engines, while others are primitive yet effective. Furthermore, the banking botnets' architecture ranges from a single centralized command and control (C2) server to a decentralized peer-to-peer (P2P) network.

Key findings

Analysis by Dell SecureWorks Counter Threat Unit(TM) (CTU) researchers revealed these key findings:

• Banking botnets targeted nearly every type of financial institution in 2013, from commercial banks to credit unions. Most campaigns focused on traditional banking websites, but attackers also targeted websites related to corporate finance and corporate payroll services, stock trading, social networking, email services, mail delivery services, employment portals, entertainment, and dating portals.
• Most of the financial institutions targeted in 2013 are in the U.S. These institutions were targeted by more than 70 percent of all analyzed trojans.
• Attackers used financial trojans to target more than 900 financial institutions in more than 65 countries, and there was an increase in attacks and in the number of targeted organizations located in the Middle East, Africa, and Asia.

Botnet activity for 2013

Most banking trojan activity observed by CTU researchers in 2013 originated from the botnets listed in Figure 1 and Table 1.

Figure 1. Percentage of banking malware by botnet in 2013. (Source: Dell SecureWorks)

Table 1. Comparison of most active botnets observed in 2013.

As shown in Figure 2, attackers preferred to target commercial banks, credit unions, and other financial institutions in developed countries with sizeable populations and wealthy residents in 2013. Attackers tend to avoid countries where international transactions are more difficult and require local intervention to launder the money. Though most campaigns in 2013 focused on traditional banking websites, targets also included institutions that facilitate high-volume, high-value transactions, such as Automated Clearing House (ACH) or Single Euro Payments Area (SEPA) credit transfers. Many campaigns targeted corporate bank accounts and payroll systems.

Figure 2. Countries targeted by banking trojans in 2013. (Source: Dell SecureWorks)

Modern banking botnets are extremely flexible and offer attackers many features. As shown in Table 2, Man-in-the-Browser (MITB) is a common attack technique in banking botnets, and banking botnets often share many of the same characteristics and capabilities.

Table 2. Feature list of banking trojans.

The combination of these characteristics and capabilities determines the success rate of a fraudulent transaction. The choice of banking trojan and its capabilities depends on the financial resources available to the attacker and the level of security implementations an institution adopts. While MITB is a necessity of any banking trojan, features like redirect and backconnect allows them to control fraudulent transactions. Features like screenshots and video captures not only capture important information but enable an attacker to determine victim behavior that can be emulated during a fraudulent transaction.

Zeus

The Zeus banking trojan (originally called PRG or Zbot) was first discovered by the CTU research team in 2007 after it was used in a credential-theft attack targeting the United States Department of Transportation. Since the Zeus 2.0.8.9 source code was stolen and leaked to the underground community in May 2011, nearly every banking trojan contains Zeus features. The relative maturity and broad success of Zeus has provided a model in the weaponization and development of other families of banking trojans.

The Zeus toolkit is made up of three parts: a builder, the actual Trojan horse malware, and a C2 web panel. The builder allows the attacker to edit and compile the configuration file and to build the actual trojan. The trojan is then delivered to the victim's system, where it modifies the compromised computer and steals information. The C2 server monitors and controls the trojan and stores stolen data.

CTU researchers have observed delivery of Zeus via many different infection vectors with emphasis on use of spam campaigns and exploit kits, techniques that leverage email and web browser technology to reach and install malware on end-user systems. Zeus uses port 80 (HTTP) for all of its communication between the victim's system and the C2 server. This port is typically not blocked or monitored for outbound connections. Table 3 lists the statistics for Zeus samples analyzed by CTU researchers in 2013.

Table 3. Zeus samples analyzed in 2013.

Architecture

Zeus's C2 design is simple. Each bot is programmed to connect to a specific C2 server, which can be updated dynamically through a configuration file. Cybercriminals can rent individual servers to orchestrate their own banking campaigns. Zeus has also been observed running from compromised servers.

Webinject module

A webinject module can manipulate and inject arbitrary content into the data transmitted between a server and the web browser. Zeus's webinject engine uses a target list to define how a financial institution's website is modified in a web browser on the victim's system. The webinject uses macros to dynamically modify or add an HTML or JavaScript tag inside the web page of a target website before it is rendered by the web browser.

IceIX (Ice9)

IceIX is a banking trojan focused on credential theft. Its architecture and web inject models mirror Zeus's in most ways, as the original IceIX code is believed to be based on Zeus 2.x source code leaked to the public in 2011. Development of IceIX has not been particularly robust since its introduction as a new malware family. Functionality has been extended beyond Zeus 2.x in three primary areas:

• The crypto module uses custom RC4 algorithm.
• The network module uses HTTP POST requests to download configuration files.
• The versioning scheme is slightly different.

Table 4 lists the statistics for IceIX samples analyzed by CTU researchers in 2013.

Table 4. IceIX samples analyzed in 2013.

Citadel

Citadel is also a banking trojan that is based on the Zeus architecture and operational model. Like IceIX, Citadel is believed to be derived from the Zeus source code leaked to the public in 2011.

Development of Citadel has been robust since its introduction as a distinct malware family. Notable capabilities added include AES encryption of configuration files and communications with C2 servers, an ability to evade tracking sites, the capacity to block access to security sites on victims' systems, and the ability to record videos of victims' activities. Like Zeus and IceIX, the Citadel toolkit is made up of three parts: a builder, the actual trojan, and a C2 web panel. Table 5 lists the statistics for Citadel samples analyzed by CTU researchers in 2013.

Table 5. Citadel samples analyzed in 2013.

Architecture

Citadel's C2 design is simple and is similar to Zeus. Each trojan is programmed to connect to one or more C2 servers. Attackers can dynamically update the C2 server options from a configuration file. Cybercriminals may rent individual servers to orchestrate their banking campaigns.

The Citadel trojan running on an infected system has two primary functions:

• Passive function: automatically executed on the infected system through application programming interface (API) hooking. The hooked code embedded in network and other APIs performs the following tasks:
  • HTTP session redirection
  • Web injections (MITB attack)
  • FTP credential theft
  • POP3 credential theft
  • Flash files control
  • Keystroke logging
  • Screen capture
  • Video recording of activities
• Active function: executed upon receipt of a command from the C2 server. Citadel supports the following commands, organized by category:
  • OS — shutdown, reboot
  • FS — search, download, upload
  • Bot — install, uninstall, add, remove, httpinject enable/disable
  • User — logoff, url_block, certs_get, homepage_set, execute, destroy
  • DDoS — start, stop
  • Module — execute enable/disable, download enable/disable
  • Info — system info

Webinject module

Citadel introduced a new feature called "dynamic webinjection." This feature is implemented through an entry in the configuration file and a command issued to the bot from the C2 server. The new dynamic webinject feature is triggered by a command called "webinjects_update", which takes two arguments. A typical command uses the following syntax:

webinjects_update dual "webinjects/new.js"

The first option can be "dual," "single," or "disabled," and the second option is a file path. "Dual" indicates that this webinject file should be used in conjunction with existing webinjects contained in the configuration file; "single" instructs the bot to use the listed webinject file instead of the data in the configuration file; and "disabled" turns web injection off. The second argument is the full path to the server file that contains the webinject code.

When the bot receives this command, it issues an HTTP POST request for the specified webinject file. The C2 server replies with the relevant file. The request and the reply are formatted and scrambled using an AES+RC4 encryption scheme.

Citadel has emerged as a popular choice in the underground economy for use in financial fraud. Its improved feature list suggests that the Citadel authors continue to innovate and improve the overall quality of their product by adding functionality that their competitors do not offer. Citadel has allowed attackers to expand their reach and target a larger variety of web browsers. It provides a platform for additional criminal revenue opportunities, such as installation of ransomware.

Improvements

The Citadel authors created a crowdsourcing model for feature improvement by allowing customers and prospective users to propose features. Citadel has built upon the base capabilities of Zeus by introducing the following improvements:

• Google Chrome support — Citadel added support for hooking and monitoring Chrome activity.
• Revised cryptography — Citadel's encryption routine changed from standard RC4 to 128-bit AES. Citadel also modified the RC4 implementation slightly by adding an XOR operation with the original seed string. This custom RC4 implementation is also used to encrypt stolen data sent to the C2 server.
• Sandbox detection — Citadel can detect if it is running within a virtualized environment. If it is running in a virtual machine (VM), Citadel alters its behavior, generating a random "decoy" domain name and URL path for the C2 URL rather than connecting to its typical C2 server.
• Video capture — The video capture plugin is typically downloaded from the C2 server when the malware connects for the first time. The ability to capture video allows a threat actor to monitor portions of a victim's entire browsing session.
• Denial of service — Citadel included the capability for infected systems to participate in a distributed denial of service (DDoS) attack against a specified target. The botmaster initiates this command via the Citadel control panel.
• Automated command execution — Citadel improved Zeus's ability to execute an arbitrary command on an infected system by introducing a series of pre-defined commands.
• Aggressive DNS filtering — Citadel introduced a capability to alter the domain name resolution to prevent antivirus (AV) and security companies from resolving domain names, block AV software from receiving updates, and prevent victims from visiting AV or other security sites to download removal tools and obtain mitigation advice.

The Citadel 3.1 variant, first identified in May 2013, introduced the ability to spread via external devices such as USB by taking advantage of the "autorun.inf" functionality. It also introduced a "port scan" command and added a new encryption layer for both communication and the configuration file. Compared to the previous known Citadel version (1.3.5.1), the encryption scheme was modified slightly with an added XOR layer using a fixed constant value included in the binary and 32 random bytes at the beginning of the configuration file.

Gameover Zeus (Zeus P2P)

Gameover is one of the most capable Zeus variants. It appeared in July 2011, shortly after the Zeus 2.x source code was leaked. It is typically distributed through high-volume spam campaigns that infect victims' systems via email attachments and URL redirects to drive-by download exploit kits. Ongoing development and operation of Gameover Zeus has been extremely focused and driven by a small group of threat actors who tightly control the feature set and offer services to a small, tightly controlled segment of the criminal economy. Table 6 lists the statistics for Gameover Zeus samples analyzed by CTU researchers in 2013.

Table 6. Gameover Zeus samples analyzed in 2013.

Architecture

Gameover uses unique encryption and communication methods. It uses a robust network architecture with TCP and UDP peer-to-peer (P2P) communication to hide the location of the criminal infrastructure. TCP is used for transmitting malware-specific data, such as configuration and executable updates. UDP is primarily used for maintaining the P2P infrastructure, such as sharing lists of known peers. Gameover generates a unique BotID to identify itself within the P2P network and uses the P2P architecture to proxy C2 communication. The P2P protocol it uses to receive configuration and binary updates from infected systems is loosely based on the Kademlia P2P protocol. Stolen data and instructions are relayed through a peer using RC4 encryption with an HTTP proxy server included with the malware. Gameover uses a domain generation algorithm (DGA) to dynamically generate a pool of 1,000 domain names each day. The trojan uses these domains when it cannot communicate with the P2P network to refresh its peer list.

Webinject module

Similar to other popular banking trojans, Gameover uses a configuration file to specify its webinjects. The trojan has adopted support for Perl Compatible Regular Expressions (PCRE) to define target URLs and HTML content. Gameover's configuration contains a "pcre_pattern" section that defines the pattern to detect in HTML code for a targeted URL.

Gameover webinjects provide insights into different campaigns and the type of fraud the criminals want to commit. These webinjects are used to steal credit card data, commit ACH and wire fraud against high-value accounts at major banks around the world, and steal other personal information such as Social Security numbers, mothers' maiden names, and ATM pin numbers. To siphon money from compromised accounts, the Gameover Zeus threat actors use spam services to recruit money mules to transfer illegally acquired money electronically or through a courier service. Money mules usually reside within the same area or country as the victim to reduce the risk of detection.

At times, Gameover Zeus criminals use DDoS attacks in conjunction with the high-value frauds to create a diversion and to prevent victims from being able to log into their accounts.

Shylock

Shylock was first discovered in the second half of 2011. It is not as widespread as other popular banking trojans and has never been openly advertised for sale. The Shylock name is coined from references to the fictional character in Shakespeare's play The Merchant of Venice. A custom packer used to obfuscate the binary introduced this name; the trojan does not contain any references to "Shylock." The original project name used internally by Shylock's developers is Hijack. AV vendors also detect Shylock as Caphaw.

In January 2013, Shylock used a plugin to spread via Skype instant messages. In February 2013, Shylock was observed using a special bootkit plugin. Similar to other banking trojans, Shylock is distributed using spam campaigns and drive-by download attacks through different exploit kits. Shylock can also spread through local shares and removable drives. Table 7 lists the statistics for Shylock samples analyzed by CTU researchers in 2013.

Table 7. Shylock samples analyzed in 2013.

Architecture

Shylock includes many of the same features found in popular banking trojans. It hooks into web browser processes and monitors activity for websites of interest. It can inject HTML and JavaScript code into specific web pages, steal or delete HTML and Flash cookies, take screenshots or record videos of specific web pages, and upload stolen information and data about the infected computer and installed software to C2 servers.

Shylock hides its main module and all of its plugins from the file system using a user-mode rootkit. The same rootkit blocks access to its registry and hides network traffic traces associated with Shylock processes.

Shylock uses HTTPS to encrypt C2 communications for receiving instructions and updates, and uploading stolen information. Each Shylock sample's C2 URLs are hard-coded in the binary. Shylock generates and prepends a random subdomain to the C2 host. The domains are likely configured to use wildcard DNS to resolve any subdomain to a core group of IP addresses. Shylock's encryption module uses standard RC4.

Shylock uses the common technique of function hooking (also called API hooking and detour patching) to insert itself into the program flow of a process. Function hooking modifies the virtual memory of a running process to divert execution flow from a legitimate function to the malware. Shylock hooks functions from several APIs to leverage the malware's information stealing and rootkit capabilities. Shylock uses Windows named pipes to send messages between the injected processes ("slave" instances) and a "master" instance that typically runs in explorer.exe. The slave instances use these messages to send stolen data to the master instance to upload to the C2 server, or to retrieve configuration information from the master.

Shylock uses three types of servers to allow attackers to perform transactions: a C2 server to determine targets, a VNC server to remotely log into infected systems, and a backconnect server to tunnel traffic through the compromised systems. It also uses webinject servers to intercept traffic during MITB attacks.

Shylock implements a robust plugin-based architecture that includes the following plugins:

• Archiver — Compress and upload recorded video files to remote servers.
• Backsocks — Fully functional reverse (backconnect) SOCKS proxy server allows external attackers to tunnel traffic through the compromised system into the internal (target) network.
• Vnc — Provides attackers with a remote connection to compromised devices.
• Diskspread — Allows Shylock to spread via removable drives.
• Ftpgrabber — Supports password theft from various applications.
• MsgSpread — Allows Shylock to proliferate through Skype instant messages.
• SpBot — Allows Shylock operators to use victims' systems as a spam bot.

Webinject module

Shylock hooks the following functions to leverage the malware's data stealing and web injection capabilities:

• WinInet for Internet Explorer and other web browsers that use WinInet.
• NSPR and NSS functions for the Netscape and Firefox web browsers.
• The send() Windows Sockets API function to monitor network activity for websites that use HTTP basic authorization.

Bugat

Also known as Cridex and Feodo by AV vendors, Bugat first appeared in January 2010 and was initially positioned as a Zeus alternative. Bugat has an aggressive versioning history. As of this publication, Bugat is fourth-generation malware, with each generation possessing a distinct message data structure and encryption scheme. Bugat can reuse existing libraries and formats for greater flexibility and extensibility.

Bugat has the following capabilities:

• Capture all form data from SSL pages by default.
• Use a downloaded configuration file to obtain targeted and exempted URLs for further manipulation, including HTML injection.
• Archive, search, and execute local files.
• Steal FTP and POP3 credentials from victims' systems.

Table 8 lists the statistics for Bugat samples analyzed by CTU researchers in 2013.

Table 8. Bugat samples analyzed in 2013.

Architecture

The Bugat botnet is centralized, communicating with its C2 server regularly to retrieve the latest configuration files and corresponding binary updates. Bugat uses an inline-hooking technique to redirect the call flow to the malicious routine at the entry point of the hooked API. The trojan checks the injected process and hooks the corresponding API.

When the trojan launches, it first drops itself into the %AppData% folder. The filename starts with the letters 'KB' followed by an eight-digit number derived from the compromised system's volume serial number. After running from the dropped file, the trojan deletes itself using a batch file. Bugat checks the system's OS environment and acts accordingly:

• On 64-bit systems, it executes only the communication module.
• On 32-bit systems, it injects itself into processes that have the correct access and security identifier.

The communication routine is injected into every process that the trojan has the access rights to open. It has mutex and event checks to ensure that only one thread at a time executes the communication routine to avoid data sharing conflicts.

Before the trojan communicates with the C2 server, it gathers the basic system information from the victim's system, including serial number, computer name, version information, and a hash value of the user's security identity. Bugat sends this information to the C2 server, typically using HTTP. Bugat uses a customized cryptographic system that combines public-key cryptography (RSA) with symmetric-key cryptography (RC4), giving it the confidentiality of non-symmetric encryption and the efficiency of symmetric encryption.

Webinject module

Similar to other popular banking trojans, Bugat hooks the WinInet and NSPR functions to leverage the malware's data stealing and web injection capability against web browsers like Internet Explorer and Firefox. Bugat hooks Secure32 crypto and Windows Sockets API functions to monitor network activity to steal usernames and passwords from HTTP, FTP, and POP3 sessions.

Bugat's webinject module uses an XML format configuration file. As shown in Figure 3, Bugat's configuration structure has two main branches: <settings> and <commands>. There are eight types of commands under the <command> branch. Each type is associated with a set of corresponding instructions in the injected code. There are five sub-branches under the <settings> branch:

• <httpshots> — Configures the trojan with a list of URLs to capture screenshots of web activities.
• <redirects> — Configures the infected web browser to redirect to malicious sites.
• <bconnect> — Includes information about the backconnect server, which attackers can use to deliver new commands.
• <formgrabber> — Includes a list of sites from which the trojan steals form data.
• <httpinject> — Includes a list of all target websites and corresponding webinjects.

Figure 3. XML structure of Bugat configuration. (Source: Dell SecureWorks)

If the target URL within <httpshots> or <formgrabber> contains the domain name, then the trojan attempts to match the pattern in the <conditions> tag. If the condition matches, Bugat injects the HTTP code from the <replacement> tag.

Gozi

First discovered in 2007, Gozi (also known as Ursnif, Papras, and Snifula) offers a very powerful capability for an attacker to modify the content of targeted websites. Gozi operators represent a threat similar in magnitude to Zeus operators. Gozi is mainly spread through spam campaigns, redirecting victims to drive-by download exploit kits to eventually install Gozi on the infected system. Table 9 lists the statistics for Gozi samples analyzed by CTU researchers in 2013.

Analysis of malware known as the Neverquest trojan indicates that it is the ongoing evolution of the Gozi malware family. It seems to affect only users browsing with Internet Explorer and Mozilla Firefox, but Neverquest's creators boast that it can be modified to attack "any bank in any country." Neverquest is known to spread via social media, spam emails, and file transfer protocols.

Table 9. Gozi samples analyzed in 2013.

Architecture

Gozi's main module is contained in a dynamic library installed onto a system using an additional program, such as a trojan downloader or a trojan dropper. The dropper loads a DLL on a system that initializes Gozi. If this is a first-time infection, Gozi connects to the attacker's server. The server sends an encrypted configuration file that includes a list of banking websites and corresponding attack scripts for each website. Gozi can recognize hundreds of online banking and financial sites. When a victim attempts to log into one of the targeted sites, the trojan reacts by activating itself and stealing the victim's credentials.

Gozi steals login credentials from FTP applications installed on infected computers. Attackers use these FTP credentials to infect websites with the Neutrino exploit pack, which then exploits vulnerabilities in browser plugins to install Gozi on the computers of users visiting those websites.

The trojan harvests Simple Mail Transfer Protocol (SMTP) and Post Office Protocol (POP) credentials from email clients and sends them to attackers for sending spam emails with malicious attachments. These emails are typically designed to look like official notifications from legitimate services. Gozi also harvests data when an infected system visits websites not related to finance, including Google, Yahoo, Amazon AWS, Facebook, Twitter, and Skype. Attackers could use these accounts to spread links to infected websites, to further spread Gozi and other malware.

Webinject module

Gozi's default configuration defines approximately 30 targeted websites that belong to large international banks and popular online payment services in Germany, Italy, Turkey, and India. In addition to these predefined sites, the malware identifies web pages victims visit that contain specific keywords such as "balance," "checking account," and "account summary" and sends their content to the attackers. This keyword-targeted functionality helps attackers identify new financial websites to target and build scripts for their malware.

After attackers obtain the information to access a victim's account on a website, they use a proxy server to connect to the victim's computer via VNC and access the account directly. VNC bypasses some account protection mechanisms enforced by websites because actions such as transferring money must be performed using the victim's web browser. When attackers have control of a victim's account, they can transfer money into an account under their control. In many cases, the attackers move the stolen money through a series of mule accounts to make their activities difficult to trace.

Torpig

Torpig (also known as Sinowal or Anserin) has consistently been one of the most active banking trojans since 2006. It is built on a much more advanced infrastructure than other banking trojans. Torpig's primary capability is performing post-authentication Man-in-the-Browser (MITB) content manipulation attacks. The trojan can emulate user behavior in the web browser, create delays, or move the cursor between different input fields. Table 10 lists the statistics for Torpig samples analyzed by CTU researchers in 2013.

Table 10. Torpig samples analyzed in 2013.

Architecture

Torpig relies on a complex network infrastructure to infect systems, retrieve payload and configuration updates, perform active MITB attacks, and send the stolen information to its C2 server. The following steps reveal the process of infecting and compromising victims' systems:

1. Victims are tempted with spam emails.
2. Attackers modify HTML tags on vulnerable web pages.
3. A modified web page redirects the victim's web browser to a drive-by download server.
4. The web browser requests JavaScript, which launches exploits against the browser or browser components such as ActiveX controls, Adobe, or Java plugins.
5. If any exploit is successful, the victim's system is forced to download and execute a Torpig payload from the drive-by download server.
6. The payload obtains the Torpig modules and configuration with target list and injection server information.
7. When browsing a targeted site, the victim is redirected to HTML injection server for a MITB attack.
8. Torpig uploads stolen credentials to an attacker-controlled server.

Torpig places all plugins and component DLLs in the system32 directory so every system reboot can restart them immediately without having to download them again from the C2 server. Torpig's core module hooks into explorer.exe and communicates from within the same executable. The trojan has a plugin-based architecture with different plugins for Internet Explorer webinjects, Firefox webinjects, Chrome webinjects, password stealing, certificate stealer, and remote desktop. Torpig uses a DGA to compute a list of domain names and then attempts to contact them until one successfully resolves to an IP address and provides a valid response. Torpig's DGA is completely deterministic; every bot produces the same list of domain names on a given date.

Webinject module

After the injection, Torpig can inspect the data handled by the infected programs and can identify and store information such as stored passwords, credentials for online accounts, and login information in web browsers. It stores data files with pseudorandom hexadecimal names in the %temp% directory.

Torpig communication is based on certificates, using a public/private key combination. Torpig's communication with its webinjects server takes place only while there is traffic from the web browser. Every 20 minutes, Torpig contacts its C2 server to upload stolen data. This communication with the C2 server occurs over HTTP, protected by a custom encryption algorithm with fixed packet structure. The C2 server acknowledges the data or responds with a new configuration file containing further instructions on how and where the malware should contact its C2 server.

The typical Torpig configuration file lists roughly 600-900 domains belonging to banks and financial institutions. Torpig also targets data from the most popular credit card companies. Torpig can perform passive monitoring to collect sensitive information from an infected system. When an infected system visits one of the domains specified in the target list, Torpig issues a request to an injection server. The server responds with a trigger page for the target domain, a URL on the injection server that contains the webinject, and several other necessary parameters to fine-tune the attack. When the infected system visits the trigger page, Torpig requests the injection URL and injects the content into the browser. This content, typically in HTML and JavaScript format, asks the user for sensitive information. The injected content carefully reproduces the target web page's style, look, and feel.

Conclusion

The financial fraud marketplace is an increasingly organized entity. It is a service-based industry in which a wide variety of financial trojans, webinjects, and distribution channels are bought and sold. Attackers are also reaching new markets, constantly expanding their operations to locations where they can apply existing techniques. The Middle East, Africa, and Asia are increasingly targeted. In search of maximum return, attackers are targeting high-volume and high-value transaction services, such as ACH in the U.S. and SEPA credit transfers in Europe, and there is an increased focus on recruiting money mules.

In many situations, financial institutions adopted custom security solutions to protect against threats. However, many of these security implementations are ineffective against the modern banking trojan. Mass-distributed trojans that target large numbers of financial institutions concurrently and that leverage third-party services dedicated to circumventing security measures present a significant security threat.

The CTU research team recommends that clients conduct online banking and financial transactions on isolated workstations that are not used for web browsing, reading email, and other activities that could increase the risk of infection. The best defense for financial institutions is a unified web security solution with real-time content inspection of every piece of incoming and outgoing web content.

Automated attack detection requires collecting, combining, and automatically analyzing data to extract relevant information and apply security countermeasures. Combining this data with intelligence gathered on known botnets will help enlarge the knowledgebase for identifying attacks and selecting appropriate attack mitigation tools.