IMPORTANT: this is based on data I got from your link, but the server might implement some protection. For example, once it has sent its "silver bullet" against a victim, it might answer with a faked "silver bullet" to the same request, so that anyone investigating is led astray. I have tried sending a fake parameter of cHVwcGFtZWxv to see whether it triggered any different behaviour, and it did not. Still, that's no great guarantee.
UPDATE - the above still holds, but I've been making tests from random IPs not traceable to my main session - the attacking server does not discriminate, and will blithely answer to a query regardless of browser, referer, and JS/Flash/Java support.
The link you received contained, already embedded in the URL, the following parameters - I have slightly changed them so the correct form won't appear in Google searches of Stack Exchange (I swapped the first letters).
jebe1shebe@hotmail.co.uk
hunalx@googlemail.com
The link injects a Javascript that first of all retrieves your location through a Geotrack API call, then loads another script. (I had initially mistaken this for a GMail command; my bad).
The second script loads a web page, but also presents several replicas of Login pages of popular accounts (Hotmail, GMail and so on) depending on the incoming email: GMail accounts get a fake GMail page, and so on, all of these pages saying what amounts to "Oooh, session expired! Would you mind logging in again?".
For example, clicking here (do not do so while logged in GMail, just in case)
hxxp://23.88.82.8/d/?p=puppa@gmail.com&jq=SVQ7RmxvcmVuY2U=
will display a fake Google account login (for a nonexisting user 'puppa').
The real login pages come from
http://ww168.scvctlogin.com/login.srf?w...
http://ww837.https2-fb757a431bea02d1bef1fd12d814248dsessiongo4182-en.msgsecure128.com
which are fire-and-forget domains.
The server that receives the stolen usernames and passwords is apparently always the same, a ShineServers machine on 31.204.154.125, a busy little beaver. Most of these URLs have been submitted to various services and were seen as far back as January.
Phishing and Two-Factor authentication
I'm of two minds about the usefulness of TFA in this scenario. As I see it, and I may well be mistaken or overlooking something,
- the victim clicks on the link
- gets "disconnected" and prompted to "reconnect" by a phishing screen
- enters [username and] password
- attacker attempts login and gets redirected to "Enter Secure Code"
- a secure code is sent to the victim
- attacker sends to victim an "Enter Secure Code" screen
- (most?) victims enter secure code too
- victim account is compromised
What could one do
- Check out the URL appearing on the address bar. Verify SSL certificates.
- Never login to anything unless it comes from a bookmark or a manually typed link, paying attention to common misspellings. If a login screen appears during navigation, just close the browser and reopen it.
- Enter into the paranoid habit of always inserting a wrong password first, one you would never use, then the correct one on the "Login failed" screen. If the wrong password gets accepted... (of course, the attacker might always reply WRONG! to the first attempt. He has to balance the cost of scaring some victims against the benefit potential of capturing some others. As long as the number of two-attempters is negligible, two-attempting is a winning strategy for them. If everybody does it, it won't work).
- There are services, such as OpenDNS as pointed out by @Subin, or embedded in the browser itself, that verify the incoming site against a distributed list and refuse to connect to a known phishing site.
What could a developer do
Maybe, just maybe, it would be possible to develop a "This page looks like this other page" application. Probably it would be terribly heavy on the system. In its most basic and thwartable form, if the HTML code contains 'Enter Google password' and the URL is not gmail, then a large blood-red banner appears saying JUST DON'T.
Another (thwartable again) possibility is to employ a honey-token approach and deny form submissions that contain a password.
What could Google do
This is a bit of a pet peeve of mine. The phishing screen uses data on Google servers, for Pete's sake, so that those servers clearly see a login logo being requested by your mom with a referer of phishers'r'us dot com. What do those servers do? They blithely serve the logo as is! If I were to manage such a server, a request for your avatar image (or any image) from any page not on my site would, yes, indeed get an image. I would probably get in no end of trouble for the image I'd choose. But it would be very unlikely that someone would willingly enter his/her password on such a screen.
Of course, the attackers would just mirror the images on their websites. But I can think of many other tricks. For example, if a browser on 1.2.3.4 asked me for a login avatar, I might be wary of a password confirmation coming from address 9.8.7.6 a few seconds later, especially if other passwords for other accounts had come in similar circumstances from the same address in the last few minutes.
A twist: as suggested by a commenter (which I still have to thank for the insight), Google has actually oversight on the incoming requests as well as GMail displayed messages. With a bit of data analysis, it can then know with good certainty phishing sites almost in real time, and phishers mirroring sites doesn't thwart this kind of analysis very much (it is mostly based on data garnered from the victim). Then Google can supply the addresses of known sites to a browser extension (e.g. Chrome site protection).
I still think that they could do both - defend the login screen and use data mining to find out who the phishers are - but I'll accept that I am not justified in saying that Google is actually doing nothing.
More complicated tricks
Also, I might complicate the login screen with challenge/responses invisible to the user that the attacker would have to match, and based on browser fingerprinting. You want to log in, you send the password from the same login screen that prompted you. This too can be thwarted, quite easily.
But having to do twenty easy things to compromise an account is difficult. Also because if you do seventeen right, I (the server) mark your address, and maybe redirect you to a fake sandbox account if you do succeed to log in in the next hours. And then I just look at what you do. You do little, I replicate on the real account and if you're honest, you'll never even know. More than X too-similar emails, or sent too fast, and I'll know. Of course the account will remain open and blithely accept all your spam. Why not. Send it? Well... that's another matter, now, isn't it?