I recall when I first read HD Moore’s writeup about the DNS Cache Poisoning that had happened to his upstream, I though that it was somewhat shortsighted that the attacker chose google.com to cache poison since that was so obvious. Firstly, HD and the others at his company probably actually use Google very frequently, they had already cached the real IP address in their browser so it would take a while to take effect, and most obviously there was the visual cues that tipped him and probably everyone else off since the website didn’t act like Google.
But let’s pretend for a moment the attacker were interested only in credentials, and they knew the website in question set global cookies for the whole domain. Even in the case of SSL this might be a problem if they don’t use the secure flag within the cookie. So the attacker can then use the Kaminsky DNS cache poisoning attack against a non-existant subdomain. So instead of secure.bank.com they cache poison hacker.bank.com, and they point it to their own server.
The attacker then simply gets the user to click on a link or visit the page through a dozen different possible ways, and poof, the credentials for the bank are sent to a subdomain of the bank that the bank doesn’t even own. Setting the secure flag on cookies helps, and making sure your cookies aren’t global in scope is also a good idea. The best part is that it doesn’t have to have any visual cues. A <img src="http://hacker.bank.com/"> is enough to force the credentials to be sent to the fake subdomain. Once the credentials are stolen, the DNS entry gets dumped because the machine goes offline, the cache in the browser can be set to expire immediately, and ultimately no one is the wiser and there is very little forensic evidence that it ever happened.