My mum (on Gmail, using Chrome) received an email from a friend's Hotmail address. She opened the email (very obviously a phishing email) and clicked a link in it. This opened a webpage with loads of medical ads on. She closed the page and deleted the email.

She did not notice anything else happen when she clicked the link. For example, she did not see a download start and did not click anything on the page that opened.

The URI of the link she clicked was hxxp://23.88.82.34/d/?sururopo=duti&bugenugamaxo=aGViZTFzaGViZUBob3RtYWlsLmNvLnVr&id=anVuYWx4QGdvb2dsZW1haWwuY29t&dokofeyo=anVuYWx4 [DON'T visit that address!]

Immediately (although she didn't know at the time) about 75 emails were sent from her Gmail address to a selection of her contacts. They are visible in the Sent Mail list in her Gmail account. This happened between 17:08 and 17:10 GMT. Here the source of one:

Note that the IP address in that list, 86.152.149.189, is the same as in the header of that email.

One of my mum's friends reports that she received one of the emails and clicked on the link in it. She says that her email account then sent out a load of emails too.

I don't know what my mum's IP address was at the time this happened. So maybe it was 86.152.149.189.

I don't understand how this happened. She had an impressively strong password (which I've now changed) that she doesn't use for anything else and she didn't type this password into the page that opened.

How on earth could clicking a link in an email allow an attacker authenticate themselves with the Gmail SMTP server as my mum and then to send a load of emails as her to her contacts? And how could it have got the addresses of her contacts?

Update subsequent to Iserni's answer:

My mum confirms that she did indeed enter her Gmail password when "Gmail" asked for it after the page of medical ads closed. Her aunt received one of the emails and was also asked to enter her Gmail login details. She says she did because the original email came from my mum. Clever attack

You will want to change that password everywhere its used. If she shared that password on a banking website, you may want to monitor the activity closely as well. You don't need to download anything for your computer to be comprimised. You just have to visit a malicious website. May this be a lesson to her not to click a link if she doesnt know what it is.
–
n00bFeb 24 '14 at 19:52

7

One rule I live by is Never sign in to an email account unless from a bookmark or if I type the url myself
–
SongoFeb 25 '14 at 14:39

I highly recommend MalwareBytes Anti-Malware. Just £20 for a one computer, lifetime license and it pre-emptively blocks your browser from visiting most malicious sites whilst also being very unobtrusive and easy to use. I have absolutely no affiliation apart from being a happy customer.
–
DomMar 1 '14 at 16:33

1

Would using a password manager assist here, as the gmail settings would not be autofilled by the pwd manager as the domain is not recognized, prompting the user to have to manually log in the pwd manager in order to get the gmail password, instantly raising suspicions?
–
Sam HolderMar 27 '14 at 11:21

3 Answers
3

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)

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?

Nice investigation. Regarding your pet peeve - take a few minutes to think about the implications of this - its not what you think. (if you don't get it - Y29saW4gKGRvdCkgbWNraW5ub24gKGF0KSBnbWFpbCAoZG90KSBjb20K )
–
symcbeanFeb 24 '14 at 10:58

I think the main issue is that SSL secures the connection but not the intend. If there was a way for the server to carry the intend directly to the user where this can be handled in a secure way, the trick of proxying a connection for a non-technical user would disappear. That, unfortunately, would require browser support (and possible an extension of the DNS). Still, it's an interesting subject to think about.
–
StephaneFeb 24 '14 at 15:04

6

What could Google do: As they own gmail the ideal solution would be to find emails which are being sent in bulk from one user to another and contain links to non trusted sites and treat them as spam . So the users never see the email in the first place
–
DaveoFeb 25 '14 at 6:17

@lserni You can use OpenDns for stopping access to phishing sites. Add it in the answer's What could one do section.
–
SubinFeb 27 '14 at 8:36

@Subin yes, that would work against known phishing sites. That's why they skip domains so quickly. It would be probably quicker and just as safe to trust browser site-checking security.
–
lserniFeb 27 '14 at 8:41

I had a customer who was hacked in this exact way (going into the Gmail activity information showed the exact same UK–based IP addresses) a bit after your mother received that.

She had been phished only an hour before seeing me, so after being prompted was able to recall all the steps.

After clicking the phishing link, she was taken to a page full of ads where multiple popup windows opened. She closed one of the popup windows, thinking she was "back" to where she was, only to be taken to a window that looked like a Gmail logon.

It was in here that the credentials were entered, and not long after that the account was used to send phishing e-mails to everyone in her contacts list.

Her Gmail password had been reset, but fortunately using SMS verification was able to use the old password to reset to something new.

Probably what happened is that the web page had an exploit which affects the browser and it simply took control of the browser itself managed to access the GMail session and used to send the e-mail from there.

@lserni you are so right. Great work going on with the investigation. I just trusted the second paragraph on the explanation "she didn't clicked anything, she didn't download anything. So, in fact, the user was misleading (as it usually happens).
–
kiBytesFeb 24 '14 at 6:48

2

It is highly unlikely that this is what happened, given that the access log shows a whole bunch of SMTP connections - and the only way to connect to SMTP is if you have the password (or an "application-specific password" - but same idea).
–
Moshe KatzFeb 25 '14 at 18:24