Note: the following examples are real phish attacks and the web addresses shown were real. Although, at the time of writing, these sites had been shut down, do not attempt to visit these sites. They are shown for illustration only.
Example 1: The Fake Address Bar
The following email pretends to be from Citibank:
Upon clicking the link the user is taken to the following authentic-looking page:
How do we know if this is an authentic bank website or a fake? The first indication is the vague, slightly illogical problem they are trying to convince you to solve: “some of our members no longer have access to their email addresses and we must verify it”. Another tip-off is that the address is supposedly secure (using the https:// notation), but there is no padlock icon in the bottom right hand corner of the browser window. And finally, the Address Bar is a fake. The website operator has turned off the address bar. Turning it back on using View, Toolbars, Address Bar reveals the proper address:
Example 2: Another Fake Address Bar
This attack tries to draw a box over the address bar to hide the real address:
Anti-virus systems can sometimes detect this type of exploit as they are well known (eg. JS/Stealus).
Example 2b: Another Fake Address Bar
This attack somewhat more successfully hides the real address:
The fake address is the part that starts https://mysoluti but the real address is the part that includes 26.41. Although this could potentially be very effective, the site does not include a digital certificate icon although it is pretending to use HTTPS.
Example 2c: Yet Another (Very Good) Fake Address Bar
This example very cleverly replaces the address bar with a real URL:
The only tip-off here is that the page is not secure (it is missing the secure padlock icon). This exploits a fault in the web browser to present a fake address in the browser window.
Example 3: Obfuscated URL
This example uses a technique known as URL spoofing. The origin of this technique is that a malformed URL will not be displayed properly by certain web browsers, and this allows the hacker to trick you into thinking you are on a legitimate website.
In this example, the hacker sends an email containing a graphic asking you to click the link:
Despite appearances, the link tries to take you to:
(which can be seen if you hover the mouse over the graphic). The nature of the web browser fault is that everything after the special unprintable characters will not be shown in the address bar, so all you see is http://olb.westpac.com.au, which makes you believe you are on the Westpac website. However, the real page is http://220.127.116.11:8888/asp/index.htm. The significance of “olb.westpac.com.au[special unprintable characters]” is that you are logging in with this username, which is a necessary part of making this attack work.
So now that you have been tricked into visiting http://18.104.22.168:8888/asp/index.htm, two web pages are spawned, one is a legitimate page on Westpac's site (http://www.westpac.com.au/internet/publish.nsf/Content/PBOB+Terms+and+Conditions), and one is a window (without an address bar), that is a fake:
How do we know this is fake? Firstly there is no menu or address bar, which is increasingly being used to hide the location of the page. Secondly, there is no padlock icon in the bottom right-hand side of the window to indicate the presence of a secure connection. Thirdly, you can right-click on a part of the page and choose Properties, and the real location is revealed:
If you happen to be a Westpac customer and you type your online banking details into this page, the hacker will then redirect you to a legitimate Westpac error page, which makes you think you have merely made an error logging in.
This type of attack only runs successfully if you are using a web browser vulnerable to the fault. Microsoft has issued a patch for Internet Explorer which corrects this behaviour, so when you click on a link of this nature you are taken to a harmless error page:
The patch doesn't prevent you from visiting the page if you enter the address manually; it is, after all, a normal web page. The patch merely ensures URLs behave in a predictable way.
Example 4: More Obfuscated URLs
A legitimate way to encode foreign-language or non-standard characters into a URL is to use the % notation. For example, a space in a URL is represented as %20 (20 is the hexadecimal representation of 32 and 32 is the ASCII value of a space).
However, if you see a URL that looks something like this:
… it means someone is trying to hide something from you. This URL decodes to http://dlll.info/ba/index.htm. This type of encoding is perfectly harmless but it is clearly an attempt to obfuscate the true address.
Example 5: Non-Obfuscated URL
A similar technique to URL spoofing is simply not to use any web browser faults and brazenly take you to a fake website. The email arrives looking similar to the example above. Clicking the link takes you to a website which is clearly not the bank in question but immediately forwards you to the actual bank's website, complete with full security. So unless you were watching very carefully you would not notice the redirection. However, a second window is spawned which mimics the real site, but without security and without an address bar or menu. The second window is on the hacker's website. If you enter anything into this page, it is fed back to the hacker and you are then redirected to the legitimate bank's website.
In this scenario your only protection is to be suspicious of such emails and always check for the secure padlock icon.