[elsombrero]

Hijacking dns means that when you connected to the bank's website you would connect to their servers first and then they could have just proxied your connection to the real servers, that image->username check wouldn't have saved you from it since the bank's servers still operated normally

[tyingq]

Nginx, in proxy mode, even has a nice sub_filter where you can rewrite the response body. Pick a tag that generally occurs once, like </head>, and replace it with arbitary text. Like maybe "</head><script src="whatever"></script>".

That would be perfect...no need to recreate the target site's look and feel. Just whatever js you need to scrape the credentials.

[gcb0]

and now the bank just have to block Google's cloud ip range.

[tyingq]

The idea is the bank may not notice, since the site would be functional and serving customers.

Certainly, there's ways to see this is going on, but you could, for example, round robin the DNS and only attack a percentage of traffic.

[bhtp]

Although, if the bank realized what was happening, they could shutdown their servers immediately instead of needing to regain control of their DNS.

[pfg]

The bank's servers were unlikely to be involved at all. If the compromise happened at the registrar level - as the article indicates - the attackers could use their own DNS and web servers.

[DennisP]

But then the attackers wouldn't know what icon to show each customer (if the bank were using the system described above by emondi).

[pfg]

That's right. Ah, the dangers of replying to new comments without re-reading their parent. :-)