Recently I was targeted by an extremely sophisticated phishing attack, and I want to highlight it here. It exploits a vulnerability in Google's infrastructure, and given their refusal to fix it, we're likely to see it a lot more. Here's the email I got: 
The first thing to note is that this is a valid, signed email - it really was sent from no-reply@google.com. It passes the DKIM signature check, and GMail displays it without any warnings - it even puts it in the same conversation as other, legitimate security alerts. 
The Sites link takes you to a very convincing "support portal" page. They've cleverly used sites.google.com because they know people will see the domain is google.com and assume it's legit. 
Clicking on "Upload additional documents" or "View case" takes you to a signin page - again an exact duplicate of the real thing; the only hint it's a phish is that it's hosted on sites.google.com instead of accounts.google.com. 
From there, presumably, they harvest your login credentials and use them to compromise your account; I haven't gone further to check.
So how did they do it - especially the valid email? This is due to two vulnerabilities in Google's infra that they have declined to fix.
The fake portal is fairly straightforward. sites.google.com is a legacy product from before Google got serious about security; it allows users to host content on a google.com subdomain, and crucially it supports arbitrary scrips and embeds.
Obviously this makes building a credential harvesting site trivial; they simply have to be prepared to upload new versions as old ones get taken down by Google's abuse team. It helps the attackers that there's no way to report abuse from the Sites interface, too.
Google long ago realised that hosting public, user-specified content on is a bad idea, but Google Sites has stuck around. IMO they need to disable scrips and arbitrary embeds in Sites; this is too powerful a phishing vector.google.com
The email is much more sophisticated, and in my opinion much more obviously a security issue on Google's part. The first clues are in the email header: although it was signed by accounts.google.com, it was emailed by privateemail.com, and sent to 'me@blah' 
The second clue is here: below the phishing message is a lot of whitespace (mostly not shown) followed by "Google Legal Support was granted access to your Google Account" and the odd me@... email address again. 
Here's how it works: First, they register a domain and create a Google account for 'me@domain'. The domain isn't that important but it helps if looks like some kind of infra. The choice of 'me' for the username is clever, as you'll see in a minute.
Next, they create a Google OAuth application. For the name of the application, they enter *the entire text of the Phishing message* - newlines and all - followed by a lot of whitespace, and "Google Legal Support".
Now they grant their OAuth app access to their 'me@...' Google account. This generates a 'Security Alert' message from Google, sent to their 'me@...' email address. Since Google generated the email, it's signed with a valid DKIM key and passes all the checks.
Finally, they forward the message to their victims. Because DKIM only verifies the message and its headers and not the envelope, the message passes signature validation and shows up as a legitimate message in the user's inbox - even in the same thread as legit security alerts.
Because they named their Google account 'me@', GMail shows the message was sent to 'me' at the top, which is the shorthand it uses when a message is addressed to your email address - avoiding another indication that might send up red flags.
I've submitted a bug report to Google about this; unfortunately they closed it as 'Working as Intended' and explained that they don't consider it a security bug. Obviously I disagree - but until they change their mind, be on the lookout for deceptive security alerts from Google. 
Absolutely loving the 5% of replies to this that are straight out of r/iamverysmart. Keep them coming!
Turns out easydmarc have a good writeup on this attack too: easydmarc.com/blog/google-sp…
Outstanding news: Google has reconsidered and will be fixing the oauth bug!
@MosheMalawach It would also make sense to title the email something less generic, like "Security Alert: A new OAuth application was added to your account" and include some text before the user-provided content.
• • •
Missing some Tweet in this thread? You can try to force a refresh