Bank Customers Redirected to Phony Site Following ISP Hack

I was checking my bank account online when I got alarmed by my browser prompting me that the site’s certificate was invalid as shown below:

Figure 1: Invalid website certificate prompt

I usually don’t get this prompt since I regularly check my accounts online, so out of concern and curiosity, I clicked on the “Continue to this website” link and started an investigation.

Being taken to a legit-looking but unfamiliar login page as shown below, I called up my friend from another city to give me a screenshot of the bank’s real web site.

Definitely not the same as the legitimate login page screenshot sent by my colleague.

Figure 4: Legitimate login page

Moving on, I tried to enter dummy credentials of my own into this fake login page and see how it would interact.

Figure 5: Dummy credentials for fake login page

Low and behold, the web page accepts the credentials I entered and guides me through the following pages:

As I have entered dummy credentials in the login page, I also entered dummy values in the above pages only to be taken to a page saying that the site is undergoing maintenance.

Figure 8: Site maintenance page

Going deeper into my investigation, I opened the page properties to check the invalid certificate, which definitely seems invalid seeing the Issued to and by fields as shown below.

Figure 9: Invalid certificate details

We’re definitely onto something here, so let’s pull out our guns and get ourselves busy. Doing a route trace on the web site server we get the following results:

Figure 10: Traceroute from Fing

Checking the whois information of the culprit’s server IP we get the following info.

Figure 11: WhoIs Info Details

I know for a fact that I didn’t receive any spear-phishing emails nor got my devices infected by banking malware so how did this phishing attack happen?

To verify if my devices are compromised or not, I disconnect from my DSL network and try to access the bank’s website via mobile data connection, and as I suspected, the redirection to the fraudulent page did not reoccur. Running a route trace gives me the following results:

Figure 12: Traceroute from Fing

I reconnect to my DSL network to check if the fraudulent page, which still does show up using in my DSL network. So I call up my ISP to report this incident, got issued a support case ticket and ensured that they will look into it immediately. Also contacted the bank’s call center to report the incident just to give them a head’s up.

Thinking back to what I have done so far, I realized one thing. Why did the URL resolve to the correct IP when I connected to my mobile data connection?

Let’s go back to our first question, how did the phishing attack happen? If the attack was not delivered via email nor was delivered through malware, the attack reoccurs only in my DSL network and route trace to the bank’s domain server resolves to different IPs can mean that there could be a problem with my DNS settings. This brings us to think about the possibility of DNS poisoning as the root of the attack.

DNS spoofing (or DNS cache poisoning) is a computer hacking attack, whereby data is introduced into a Domain Name System (DNS) name server’s cache database, causing the name server to return an incorrect IP address, diverting traffic to another computer (often the attacker’s).

(From Wikipedia) Normally, a networked computer uses a DNS server provided by the computer user’s organization or an Internet service provider (ISP). DNS servers are generally deployed in an organization’s network to improve resolution response performance by caching previously obtained query results. Poisoning attacks on a single DNS server can affect the users serviced directly by the compromised server or indirectly by its downstream server(s) if applicable.

To perform a cache poisoning attack, the attacker exploits a flaw in the DNS software. If the server does not correctly validate DNS responses to ensure that they are from an authoritative source (for example by using DNSSEC) the server will end up caching the incorrect entries locally and serve them to other users that make the same request.”

So how do we resolve the issue while we wait for the ISP to solve the issue on their end?

Well, one thing we can do is modify our network configuration and change the DNS server settings. For this case, I tried to use OpenDNS servers. Voila! The phishing page is gone and my online banking access is back to normal.

Malicious attackers and cybercriminals out there have a lot of tricks up their sleeves but it does not mean that we don’t have tricks of our own. So you don’t fall as victims to these types of attacks, it would be very helpful for you to be vigilant enough to read through all of the warnings that you may see when you are doing online transactions. Make your that you are only allowing valid and verified web site certificates in your browsers. Banking web sites will surely have authentication policies in place which we can put also into use as to what I have done by using dummy credentials first. You can even max out the password retry limit and then just request to change your password later on to ensure that you are accessing the valid banking website.

You can verify the validity of suspicious URL’s or IPs using our reputations services such as CYREN’s IP reputation and URL category checker.

Lastly, we always recommend users to practice safe browsing habits to thwart off attacks like phishing and scams.