Present and future phishing techniques

2006-09-01

Sorin Mustaca

Avira, Germany
Editor: Helen Martin

Abstract

Sorin Mustaca takes a look at distributed phishing attacks.


Introduction

In recent months, the number of phishing attacks has risen at a worrying pace. Between August 2005 and January 2006 phishing sites hosted between 70 (August 2005) and 120 (January 2006) attacks against company brands. Unfortunately, the prevalence of phishing sites is still rising at the time of writing this article (June 2006).

In April 2006 the Anti-Phishing Working Group [1] detected the highest number of phishing sites in its history. Whereas in April 2005 there were only 2,854 unique detections, by April 2006 there were over 11,000. There are many reasons for the significant increase, but the most important is the fact that phishing is profitable for the infractors. The laws are still not clear in this area; in some cases they do not even exist, and in countries where they do exist, their application is limited or simply too slow. Another very important aspect of the phishing 'industry' is the complexity of the attacked sites. The simpler the website, the easier it is to duplicate and, of course, the more copies there are in the wild.

A phishing attack has, in general, three parts: bait distribution through email, a fake website which collects data, and the manipulation and use of this information by the infractors. We can analyse, detect and even stop the first two parts because we can see them, but we are unable to do anything about the third part, because it takes place in the criminal underground.

Some phishing attacks are so alike that they seem to have been produced with email and/or website generators. Others are so badly constructed that you ask yourself how they could ever fool anyone. However, the attacks that give us the worst headaches are distributed phishing attacks.

In this article I will describe how these attacks are constructed, why they are so hard to detect, and what I think will follow soon.

The phishnet

A distributed application has a client–server architecture with two, three or n tiers. Distributed implementations are based on multiple levels of complexity, all of which are characterized by the distribution of processing logic. In the case of phishing, the bait emails represent the clients and the fake website represents the server. As can be seen in Figure 1, the phishnet is a three-tier distributed application. In such an architecture, the third component – the one that resides in the middle – is used to accept, process and distribute requests from various clients to the server.

The Phishnet today.

Figure 1. The Phishnet today.

The middle layer is implemented by the phishers in a clever way. The bait email comes with a link to a website that has (almost) nothing to do with the phishing attack. It seems that some known vulnerabilities of Apache 1.3.3x are being used [2] to gain partial control over legitimate sites – enough control to allow phishers to place some files on the site. These files (which may be PHP or HTML) perform a redirection from the legitimate site to the phishing site. The phishing site hosts all of the files required by the fake site. Both sites use Apache 1.3.3x.

I have seen a couple of variations on this theme, where www.google.com or www.yahoo.com have been used to redirect to the fake website. In these cases the graphical elements of the fake site were taken from the legitimate website.

Phishers are becoming increasingly skilled, and they seem to know about all the things that anti-phishing products search for – such as double links. This is why we very seldom see double links like this any more:

<a href=“http://fake_site.com”>https://www.paypal.com</a>

and more often see links like this:

<a href=“http://fake_site.com”>Verify</a>

as well as numerous variations on this method (using images, tables, map areas etc.).

Of course, it is pretty easy to filter IP addresses or domains such as http://fake_site.com directly from the email client or from the proxy server, which is the reason why the redirect feature is so popular with the phishers.

Since mid-June this year, a new trend has emerged in the bait emails. Instead of simple links in the email, there is a form with a button that redirects the recipient's browser to the target website:

<form name=”form1" action=”http://fake_site.com”>
<input action=”http://” method=”post” type=”submit” name=”Submit” value=”Remove Limitations”>

Or

<font size=”2" face=”Arial, Verdana”>
<INPUT style=”BORDER-RIGHT: 0pt; BORDER-TOP: 0pt; FONT-SIZE: 10pt; BORDER-LEFT: 0pt; CURSOR: 
hand; COLOR: blue; BORDER-BOTTOM: 0pt; BACKGROUND-COLOR: transparent; TEXT-DECORATION: 
underline” type=”submit” value=”https://www.paypal.com/cgi-bin/webscr?cmd=_login-run”
tabindex=”2"></font></a>

The result is a button with the value 'Remove Limitations' in the first example (where the body text of such a bait email may try to persuade the recipient that they need to take certain action in order to restore full access to their account), or with the official paypal.com website in the second example. Note that in both cases the button is barely visible, thus making the second version look exactly like a valid link. The interesting thing is that this trick works with all browsers except those that are Mozilla-based.

The future starts now

From what we've seen so far, the success of phishing activity appears to depend on a number of factors:

  1. How 'real' the email looks.

  2. How quickly the bait email is distributed, how many recipients read the email, and how many recipients click on the links inside before the mail is blocked and the site is shut down.

  3. How quickly the fake site can be activated.

  4. How 'real' the fake site looks.

  5. How hard it is to detect the emails, and maybe the fake sites automatically (note that the fact that they 'look' real can be seen easily by a human and not so easily by a machine).

Factor number 2 is mainly a matter of luck and of the number of targets available. This in itself has created another industry; that of email addresses harvesting in order to provide the phishers with fresh email addresses. Phishers demand fresh email addresses because, presumably, they assume that someone who has been fooled once will not be fooled again, and someone who receives a lot of phishing emails will not be fooled either. Of course, most of us receive hundreds of identical spams and phishing emails every day. So, in fact this part has more to do with human nature than with phishing techniques.

The facts

Figure 2 shows a bait email for a PayPal phishing scam. Some bait emails can look even more convincing than the genuine emails from the company in question. Combining this genuine-looking message with links that go over HTTPS protocol provides even more credibility to such an email [3].

PayPal phishing email as real as the original.

Figure 2. PayPal phishing email as real as the original.

I mentioned above that a website needs to be sent online quickly, and that it must be made to look realistic (points 3 and 4 above). This is where the saying 'a picture is worth a thousand words' really does ring true. The web page shown in Figure 3 is, in fact, an image of the real PayPal web page created as a Macromedia Flash program.

Website written entirely in Flash.

Figure 3. Website written entirely in Flash.

When I 'browsed' the fake website, none of the links worked – presumably because they were part of a screenshot taken from the real PayPal website. The only part of the page that 'worked' was the 'Log In' button once an email address and password had been entered. No validation was performed of the email address and password, so after the user has entered any string into the these fields, he can 'log in' and enter his credit card information – during this process, all the fields are validated (credit card number and type, ZIP code, etc.).

Imagine how quickly such a website can be published on a new URL. It probably has only one or two files: the Flash program and the database containing credit card information. There is no need to worry about pictures, Java Script files or CSS files.

Finally, in relation to point 5, there is one obvious way to stop a phishing attack: block the phishy website.

We all know of the anti-phishing toolbars marketed by various vendors (Netcraft [4], Microsoft's IE7 toolbar [5], Google's Firefox extension [6], etc.) which use blacklists of URLs to prevent the user's browser from loading anything from the blacklisted location.

Imagine a phishing attack like the one described in Figure 4, where the bait email doesn't contain a link to the real and/or fake website but instead uses a URL rewriter. This technique will not be detected by the anti-phishing toolbars and it might bypass some anti-phishing mail filters as well (since the email contains no double links). This technique, which allows one to visit a website anonymously, is not new and it is available today on the Internet. Just google for 'anonymous surfing'. Fortunately, I have not seen any phishing attacks that use this method so far - currently it exists only for search engine redirects.

The future of phishnet

Figure 4. The future of phishnet

Such an attack might even contain unique links for every email sent, because the URL rewriter is based on a session ID. So, the email would contain links like 'http://url_rewriter/<unique id>/<file>', making it seem more legitimate than the official emails. The only issue here is that the bait emails will continue to come from [email protected] and targets will not go to site.com.

Conclusion

As proven continuously by statistics, phishing is a very profitable (illegal) business, and one in which we see a lot of effort being invested every month. Phishing attacks are becoming more dangerous than ever because they have started to become very hard to detect automatically. We can analyse the emails and categorize them as good or phishy, but the major problem here is where to draw the border between them. Nowadays, official emails often point to external information, meaning that they contain a lot of external links – which makes them look very similar to the phishy ones.

What can be done? For a start, we can ask those companies that are attacked to change some of their practices to make sure that they are not an easy target for the phishers. This means that they have to change the way they make newsletters, to be careful about what kind of information is contained in them, and maybe even to change some parts of their websites. In time, if applied correctly, this might make phishing attempts useless, but I doubt it.

Acknowledgements

Beside the references below, I would like to thank Oliver Auerbach and Cosmin Luta for their valuable suggestions.

Bibliography

[1] Anti-Phishing Working Group, APWG, http://www.apwg.com/.

[4] Netcraft Toolbar, http://toolbar.netcraft.com/.

[5] Microsoft IE7 with anti-phishing toolbar, http://www.microsoft.com/windows/ie/ie7/about/features/default.mspx.

[6] Google's Firefox Toolbar with anti-phishing extension, http://www.google.com/support/toolbar/bin/answer.py?answer=34798&hl=en.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.