January 17, 2012 By Amit Klein 3 min read

A recent FBI warning on the Zeus variant called Gameover reveals that high detection accuracy of fraudulent transactions is not enough to prevent cyber crime. This new attack is specifically designed to circumvent post-transaction fraud prevention measures. Here’s an excerpt from the FBI statement:

“The campaign involves a variant of the ‘Zeus’ malware called ‘Gameover.’ The spam campaign is pretending to be legitimate emails from the National Automated Clearing House Association (NACHA) advising the user there was problem with the ACH transaction at their bank and it was not processed. Once they click on the link, they are infected with the Zeus or Gameover malware, which is able to keylog as well as steal their online banking credentials, defeating several forms of two-factor authentication. After the accounts are compromised, the perpetrators conduct a distributed denial-of-service (DDoS) attack on the financial institution. The belief is the DDoS is used to deflect attention from the wire transfers as well to make them unable to reverse the transactions (if found).”


Gameover belongs to a set of attacks performed after the transaction is submitted. We refer to these attacks as post-transaction attacks. Some post-transaction attacks are not targeted at the bank, but rather at the user. One example uses SpyEye to execute man-in-the-browser (MitB) attacks that hide confirmation emails in Web email services or fraudulent transactions on the online banking site. Last year, the FBI publicized another attack during which fraudsters inundated victims with automated calls to tie up their phone line, preventing the bank from contacting them to validate suspicious transactions.

When banks and security experts evaluate the effectiveness of cyber crime detection solutions, they typically focus on the following two metrics:

  1. Detection Rate: How much fraud is detected versus how much evades detection?
  2. False-Positive Rate: How many genuine transactions will be flagged as fraud and blocked?

Ideally, banks look for malware prevention solutions that provide high detection and low false-positive rates.

Post-Transaction Attacks and Fraud Prevention

So how does the introduction of post-transaction attacks affect existing malware detection approaches? Let’s examine the three primary malware detection approaches: deterministic detection, statistical in-transaction detection and statistical post-transaction detection.

  • Deterministic detection searches for specific malware crime logic footprints before transactions are submitted and allows the online banking application to stop fraud by changing business flows (blocking money transfers, declining add payee requests, limiting amounts, etc.).
  • Statistical in-transactio detection identifies suspicious out-of-profile behaviors and determines the probability that they are malware-generated fraud. In cases where there is a high probability of malware fraud, the transaction is blocked immediately. Meanwhile, other risky transactions are sent to be reviewed manually, typically by a bank’s fraud team. Reviewers first look for obvious signs of fraud, such as a known mule account, and if they cannot determine its authenticity, they flag the transaction for validation by the customer.
  • Statistical post-transaction detectio extracts submitted transaction information (typically from logs), identifies suspicious out-of-profile behaviors and determines the probability of malware fraud. As with statistical in-transaction detection, transactions with high risk scores or that exhibit obvious signs of fraud are stopped (reversed), while the remaining risky transactions require customer validation.

Post-transaction attacks that hide fraudulent activity from the end user and block email and phone communication from the bank to the end user are aimed at defeating statistical post-transaction detection approaches. Other post-transaction attacks flood the bank’s fraud team and their support systems with both DDoS attacks and fraudulent transactions. These attacks can bring the entire fraud assessment process to a grinding halt.

Deterministic detection is not vulnerable to post-transaction attacks since all processing and subsequent blocking is done prior to the transaction being submitted to the banking system.

Fraudsters will continue to introduce new threats at all stages of the transaction life cycle (pre, post and during), requiring banks to continually reassess the effectiveness of their fraud prevention controls.

More from Fraud Protection

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

New Fakext malware targets Latin American banks

6 min read - This article was made possible thanks to contributions from Itzhak Chimino, Michael Gal and Liran Tiebloom. Browser extensions have become integral to our online experience. From productivity tools to entertainment add-ons, these small software modules offer customized features to suit individual preferences. Unfortunately, extensions can prove useful to malicious actors as well. Capitalizing on the favorable characteristics of an add-on, an attacker can leverage attributes like persistence, seamless installation, elevated privileges and unencrypted data exposure to distribute and operate banking…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today