Analysis of a phish targeting Australian Banks

Despite the publicity that online scams receive, a significant number of people are still falling for these attacks. We are constantly amazed at the sheer number and diversity of banks, credit unions and online payment schemes (such as Paypal and Western Union) these attacks cater for.

In this article I will examine the operations of one of the many phishes I encountered today, targeting the customers of an Australian bank.

This phish begins like almost all others: an email in the inbox of the victim stating that their account will suspended if they do not log in (or some variation of this theme). Conveniently, the email provides a link the victim can follow to log in to their account:

The irony of claiming to prevent “Internet Banking Theft” is hard to miss. Here is what happens when the link is followed:

As we see above, once the user connects to the first link (a compromised mail server hosted in the UK), they are immediately redirected to another site (hosted in Italy). Why this redirect occurs (rather than simply hosting the whole phish on the first site) is uncertain, but could be to increase reliability: if the second site is shut down, the phisher can simply change the first site to point somewhere else.

The URL of the second site contains the hexadecimal representation of its IP address, which comes in a form like http://0x7f000001/. A URL in this format (which obfuscates the destination of the link) would arouse less suspicion than one that references a hostname that is not the bank, or a normal IP address.

The URL is an exact replica of the real bank website, including links to a fundraising appeal the bank was supporting at the time the phish was set up:

Interestingly, the web-server allowed us to view a listing of its contents, so we can examine the individual components that make up this attack:

The structure is surprisingly simple. The login.htm file contains the replica website, with all its images stored in the login_data directory. Submission of the victim’s credentials are handled by the login.php script. This tiny script simply takes the account number and password, and logs them to the database.txt file, along with the IP address of the victim:

The majority of the credentials in the file are completely bogus (eg User: “thisisascam”), and possibly from tech-savvy users curious at what happens after they press the submit button. However, there are at least 5 that appear to be valid logins.

After the details are logged, the victim is sent for one final redirect:

This page is not the initial login screen, but the page a user would receive had they simply entered their credentials incorrectly. This is a clever choice of destination: the victim will probably believe they simply mistyped their password and type their credentials again to access the real site, with little skepticism that their details were skimmed off along the way.

Luckily for the victims of this attack, the bank now has their credentials and so have changed their accounts to prevent any fraud. However, in many other cases people are not so fortunate, with absolutely no knowledge that anything dodgy occurred until their life savings disappear overnight.