Monthly Archive for October, 2010

Phishing eBanking Credentials Using Web-Proxies

Everybody is talking about banking Trojans like Mebroot, Gozi, ZeuS and SpyEye and how sophisticated they are. But in this post I would like to show you a different and very simple way that cybercriminals can get your banking credentials without using sophisticated Trojans.

While taking a look at the latest malware binaries on AMaDa I came across a sample which have made a suspicious GET request to a .CH website. The HTTP GET request made by the infected machine looks like this:

GET /pages/dyn/dyn/logs HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Win32)
Host: www.*hidden*.ch

The request was made to a hijacked website, therefore I’ve disclosed the address. But what I can say is that the website happens to belong to a Swiss party of the right wing.

The content the infected machine got back from the site looks very suspicious:

<script type='text/javascript'>
function FindProxyForURL(url, host) {
var d = new Array("","","",
for(var i =0;i<d.length;i++) { if (shExpMatch(host, d[i])) {
return "PROXY"; } }

var n = new Array("","","",
for(var i =0;i<n.length;i++) { if (shExpMatch(host, n[i])) {
return "PROXY"; } }

var c = new Array("","","",
for(var i =0;i<c.length;i++) { if (shExpMatch(host, c[i])) {
return "PROXY"; } }

return "DIRECT"; }

Hum… JavaScript code. Does it ring a bell? That’s a PAC file! For those who are not familiar with PAC files: A PAC file is a so called Proxy Auto-Config file which is supported by various web browser to automatically configure the proxy settings of the browser. PAC files are most often used in cooperate networks to tell the web browser to automatically choose the appropriate proxy server (see Wikipedia).

But one question remains: What’s the intend of this PAC file? Well as you probably noticed there are some interesting domain names defined in the PAC file for example If you visit the domains listed above you will notice that all of them are websites of Brazilian Banks.

In fact this means: Whenever a victim visits a website listed in the PAC file using a infected computer, the request will be routed thorught the following web proxy which is located in the USA:

Proxy Host:
Proxy Port: 80
AS number: AS26277
AS name: PREMIANET – Las Vegas NV Datacenter
Country: US

OK, let’s summarize: The victims browser is now using a web proxy which is obviously managed by cybercriminals and used to steal credentials of online banking accounts. But how do the cybercriminals manage to get the credentials? Remember that you can not easily do a man in the middle (MITM) attack on an ebanking session due to the fact that you are using SSL to communicate with your online bank. So if they would do a MITM between your computer and your online bank you would get a certificate warning from your web browser, right?

I was very curious as to how the cybercriminals solved this problem, so I decided to infect a VM with the Trojan and take a closer look at it.

After infecting the computer with the Trojan I tried to open in the web browser:

GET / HTTP/1.1
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Connection: Keep-Alive

Let’s do a short crosscheck on this:

$ dig +short

Looks good: The web browser communicated directly to ( without using the cybercriminal’s proxy.

Let’s do another test and this time we use which is listed in the PAC-file. This means that for this URL the web browser should use the web proxy instead of going to the website directly:

Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Proxy-Connection: Keep-Alive

A short crosscheck:

$ dig +short

As expected the web browser uses the cybercriminal’s web proxy ( instead of connecting to the banks website directly – that’s bad. What is interesting is the content which we get back from the cybercriminal’s web proxy:

HTTP/1.1 200 OK
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
Content-Length: 302
Connection: close
Content-Type: text/html; charset=UTF-8

<title>Portal Internet Banrisul  | Banco do Estado do Rio Grande do Sul, S.A. </title>
<LINK REL="SHORTCUT ICON" href="banrisul.ico" type="image/x-icon">
<frameset rows="100%" border="0" frameborder="0" framespacing="0"><br /><br />
<frame name=top src=></frameset>

That’s not what I’ve expect: This is not the website of the bank we wanted to visit! It’s simple HTML code with a frameset pointing to a different website:

It’s seems to be a legitimate website running Joomla CMS. So most probably this website is hijacked because if we take a look at the “banrisul” directory we will see a replica of the Bank’s website we originally wanted to visit. In the victims web browser it will look like this:

Please notice that the address bar still displays the website of the banking site which we originally wanted to visit. But if we move the cursor over a hyper link on the website we will see the website it is really pointing to. If the victim now want to login to his online bank he will get a web form which animates the victim to enter his account number, password and PIN/TAN:

Of course the credentials won’t be submitted to his online bank rather then to the cybercriminals.

This is a pretty interesting example which shows how easy it can be for cybercriminals to obtain credentials for online banking accounts. If we summarize this simple phishing we are able to make the following conclusions:

  • The cybercriminals does not need to do a MITM, they just fake the website of your online bank. Pretty simple but very effective!
  • Everything that the cybercriminal needs do to on the victims side (client) is to change the address of the PAC-file in the web browser
  • To change the that PAC-files address, the cybercriminals doesn’t even need to install a Trojan horse: They just need a small script which changes a registry key
  • Therefore there is no Trojan horse which can be detected by the AV vendors because changing the address of the PAC file don’t have to be a malicious activity
  • The only chance to mitigate the threat is to detect the malicious script/binaries which change the address of the PAC file before the infection

If the AV-vendors are not able to detect the malicious file before the infection happens, the last line of defense is the network by detecting and mitigating the malicious traffic to the cybercriminal’s web proxy on the network layer. And at least in this case it is another example how poor the AV detection rate can be:

File name: foto.exe
File size: 372224 bytes
MD5: 91a42b9bdca567c31fe1692c13a9de1d
SHA1: 79497ebc0372c8c5352b2f30f9ddb2d0965de3fa
VT Result: 1 /42 (2.4%)

Are the cybercriminals going away from classic eBanking Trojans like ZeuS & Co and go over to the scheme described above? We will see what the future brings…

You can also follow on Twitter:

Microsoft Adds ZeuS Detection To MSRT

As of October 12th 2010, the MSRT Team added detection for the ZeuS crimeware (also known as Zbot and WSNPoem) on Microsoft’s Malicious Software Removal Tool (MSRT):

For those who don’t know: MSRT is being distributed to WinXP, WinVista and Win7 automaticly using Windows Update Service. Of course these are really great news but the thing which worries me a little bit is the fact that Microsoft waited years until they finally added detection for the ZeuS Crimeware. ZeuS has been a big threat in the cyberspace for years and has already managed to steal millions of dollars.

MSRT’s ZeuS detection rate

I thought it would be a good idea to test MSRT’s detection for ZeuS by running some quick tests. I’ve tested 20 ZeuS infection binaries (v2) by infecting a VM with the following test conditions:

MSRT Version: Kb890830 (2010-10-12)

Below are the results of my tests:

Infection binary (MD5) ZeuS Version MSRT Result Virustotal
a7d9996744d7129dc6af94d5827006e0 missed 4/43 (9.30%)
4e6114b5cbfbd5eeb0cea380c3416b2a detected 32/43 (74.40%)
20d1b5c8b868ecf314d5b7d50188f55f - detected 38/41 (92.70%)
70bda659bf0852c1ce96532df3b57021 detected 20/43 (46.50%)
a2ba908c3fe7f2bd99ad0c6e31c24995 detected 6/43 (14.00%)
e206407083a772a015a21f0398f0fbf0 missed 8/43 (18.60%)
ace6aec48663a0179af2e60cceb2ebb4 missed 10/43 (23.30%)
92b58d067b13f47d14a4747af07b2d10 detected 6/41 (14.60%)
6250a5c48f5aff26474e9eaff4d0520c missed 6/41 (14.60%)
d6c169be176e60a67780feb48327b2ab detected 12/43 (27.90%)
21102185c207602505d45019f5d782b9 missed 10/43 (23.30%)
fc797f7b8a20ab4e6ce2df39ae41069f - missed 20/42 (47.60%)
e8f83eefe8069c360c73bf7127426155 detected 33/43 (76.70%)
cf11173481abb10e92246be92d8304dc detected 17/42 (40.50%)
b64b598e6b5106d770f94c659bc994d5 missed 0/43 (0.00%)
359316aa5901613a3ad4f9265a93c600 detected 13/42 (31.00%)
2c9702bf84a7c9a094109ff2fe0a7910 - missed 3/42 (7.10%)
b0fe715bce28f9c3e48520f23c7cf8fe - detected 10/43 (23.30%)
d52d8bea0bd22be5382e05b9e787ff5d missed 3/43 (7.00%)
78edc0048427103a3f785fe8ac453d30 missed 1/43 (2.30%)
Total   Detected: 10, Missed: 10  

Microsoft’s Malicious Software Removal Tool was able to identify 10 out of 20 infected systems which is a detection rate of 50%.


During the tests I noticed that in most of the cases you need to run a fullscan with MSRT to detect a ZeuS infection. Please also note that these are some quick tests from my side and don’t necessarily represent the real detection rate of MSRT on ZeuS.

I’m really curious about the number of infections detected by MSRT world wide. Hopefully Microsoft will publish some data in the next few days.

PS: You can also follow on Twitter: