The attack as it unfolded
On May 3, 2017 a phishing campaign exploited Google's OAuth flow. Users received an invitation to edit a document. The link led to a genuine Google-hosted consent screen that listed a third-party application named "Google Docs." Granting consent gave that application full read access to email and the ability to message every address in the account's contact list. The worm propagated rapidly because each compromised mailbox became a new distribution node.
Why it worked
The consent screen displayed Google branding and a familiar app name. Most users do not inspect the developer metadata link that would have revealed the true publisher. The attack required no credential theft; it abused the legitimate delegation model that lets third-party apps act on a user's behalf.
Containment and cleanup
Google revoked the malicious OAuth tokens and removed the application from its platform within hours of detection. The Twitter account @googledocs confirmed the takedown and advised users not to click unexpected document links. Affected accounts needed only to visit the Google account permissions page, locate the rogue "Google Docs" entry, and revoke access. No password change was required because credentials were never exposed.
What your practice should verify today
Open the Google Workspace security dashboard for each managed account. Confirm that no third-party application named "Google Docs" appears in the authorized apps list. The genuine Google Docs service operates with native access and never appears as a separate OAuth client. Treat any such entry as a compromise indicator and revoke it. Then review the broader OAuth inventory: remove unused or unrecognized applications, and enforce admin approval for new OAuth grants across the organization.