Experiencing a Security Breach?

24 Hour Hotline: +1 (866) 659-9097 Option 5

General

+1 (312) 873-7500

Monday - Friday 8:00 AM - 6:00 PM CT (UTC -6)

Sales

Contact a Trustwave solution specialist.

+1 (888) 878-7817

Monday - Friday 8:30 AM - 5:30 PM CT (UTC -6)

Loading...

Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

Banking Trojans (Man-in-the-Browser)

Banking Trojan software such as Zeus and SpyEye have becomeextremely sophisticated and can manipulate a wide range of user interactionswith the web application. One of thetechniques used by the banking trojans is to attempt to phish extra user dataduring login. The banking trojan willmonitor HTTP stream data via the wininet.dll library and will modify content onthe fly. The data modificationcapability within Zeus is controlled by a file called webinjects.txt.

This section of code will add in a new login form element whichattempts to obtain the user's debit card ATM PIN information. Here is an example screenshot of the updated HTML form data -

If the target victim fills in thisinformation, then Zeus will send this information off to it's command andcontrol host. This is but one smallexample of the power of banking trojans. Newer versions are also able to passively conduct form grabbing. This means that they can monitor for when the client submits their actual credentials and then it can send that information off to the criminals. In a previous SpiderLabs Research blog posts series entitled "Catch Me If You Can: Trojan Bankder Zeus Strikes Again" we highlighted how Zeus can inject JS code calls to remote files they control -

This technique is useful to attackers as they no longer have to update their webinjects code if the target webpage HTML changes.

Identifying Banking Trojan Page Manipulations

The key defensive capability we need to identify if a banking trojan hasmanipulated the HTML data that left the web application is to be able tovalidate the data once it reaches the browser. With this concept in mind, we can leverage the work done by theUniversity of Washington Computer Science and Engineering team on a projectcalled "Detecting In-flight Page Changes with Web Tripwires."

The concept is that we can create an md5 hash of the responsebody content as it is leaving the web application and then validate it withinthe web browser to ensure its integrity.

Step 1: Injecting Initial Web Tripwire Hooks

The first step is to use ModSecurity to dynamically add inJavaScript calls in the HTML header tag to include our web tripwire code. Here are some example rules that will add thecode to the login page URL.

These rules will not inject any of the web tripwire JavaScriptcode into the HTML body but instead will calculate an md5 hash of the response body data. This data is then saved as a new response header called WebTripwireHash:

Step 4: Compare Local and Server-side Webtripwire Hashes

Once the response body data is received by the browser, the webtripwire JavaScript code will then calculate an md5 hash and compare it with the hashvalue in the WebTripwireHash response header. Here is the example JavaScript code:

// See if the actual HTML is the same as the expected HTML. var tripwireHash = req.getResponseHeader("WebTripwireHash"); var responsetextHash = hex_md5(req.responseText); if (responsetextHash != tripwireHash) { // Detected modification alert("WARNING - This web page has been modified since leaving the web server. Your system may be infected with a Banking Trojan."); // for debugging

Step 5: Generate Alerts for Page Modifications

If the hashes do not match then the data was modified sinceleaving the web application. In thiscase, if the Zeus banking trojan modifies the HTML, it will be caught and analert popup will be issued for the user as shown below:

Additionally, when the webtripwire code identifies a modified page, it willalso send a POST request back to the web application to report the issue. Here is an example request:

By monitoring for these POST violation requests with ModSecurity, we can identify banking customers who may have banking trojan malware installed on their systems andrequire clean up assistance.

Deployment Considerations

As with most defensive techniques, they have an rather short half-life. Once the bad guys identify defensive mechanisms, they could then turn around and instruct the banking trojan to strip out our defensive code. To combat this scenario, we could d a few modifications:

Generate rules that will flag clients that do not initiate the tripwire sub-requests. These clients should be placed on an increased fraud watch list.

Hide where we are adding in our defensive tripwire code. For example, instead of injecting directly into the main HTML page context, we could instead modify the contents of valid JS calls to external files.

Obfuscate our defensive code contents. We could take a page of Exploit Kit authors and optionally obfuscate our JS code to make it more challanging for Banking Trojan operators to identify our code.

Banking/Fraud Detection Assistance

If this blog post has piqued your interest into different methods of utilizing WAFs to help identify potential Banking Fraud/Trojan activity on your site, feel free to contact us at security at modsecurity dot org. We have professional services offerings to aid in advanced usage scenarios such as this.