Google Drive Shared Documents as a Phishing Delivery Channel

[Bill_Gibson]

We've had a series of phishing campaigns where Google Drive files (of note, usually .docx files) are shared directly with a subset of our users. These messages are delivered legitimately using the organic Google Drive share process with a sender of [email protected]. Then within this document, users are directed to a malicious site that attempts to get them to enter their credentials. 

The most recent instance further obfuscated the file hosted in drive by first wrapping it in a https://notifications.googleapis.com/email/redirect?.. . URL legitimately delivered using an organic Google process with a sender of [email protected]. Then, again the shared file links to a malicious website.

In all of these instances the sender is gaining message delivery by utilizing the message generation of authentic Google notification processes, and gaining implied legitimacy by hosting content within the user-trusted Google Drive platform.

To make things worse, when we administratively responded to incidents, deleted messages from end users's  mailboxes, and notified Workspace support of the problematic Drive files by ID; Support had no way to refer the files for review by a security team. Instead they insisted that the only way for the files to be reviewed was to have the files reported using the in-app reporting capability. In some cases this was off-hours response when end users were not reachable. As the files are directly shared with end users and owned by external users, our administrators are unable to access the document directly to report the issue. Lastly, this would involve sending end users TOWARDS the malicious link.

It seems like there is room for improvement in this process.
Some thoughts:

1. Provide the pathway for Workspace support to refer a document for review by a security team when referred by a fully authenticated Worksapce admin
2. Improved on-going scanning of Google Drive files for links to malicious domains. By the time we responded to some of these instances, Chrome had categorized the referenced URLs as malicious.
3. Better spam/phishing scanning of messages that are processed through legitimate Google notification services. These files are being directly shared to hundreds of end users.

[kaned]

We have also seen these and have also removed them administratively.

[elanger]

We’ve run into the exact same vector on our end recently. Fortunately, we caught it quickly, but it highlighted a major gap in administrative visibility and technical controls.

Beyond user awareness training, teaching staff how to spot suspicious Google Drive share notifications and embedded links, there really isn't an effective automated way for admins to detect or intercept these before they land in user inboxes. Because the share notification comes directly from legitimate Google infrastructure, standard email gateway protections let it right through.

Fully agree with your points. Admins need proactive scanning on shared external files and a direct escalation path to report malicious documents without relying on end-user action.

[Kim_Nilsson]

Ability as admin to act on externally owned files which should not be accessible by internal users is a definite good request. I shouldn't have to rely on the individual users (plural) to do this on their own.

A users should be able to report a file to me, and I should be able to find it and block the file and/or the external user and/or the external domain.

So not only should be have a manageable list of Allowed domains/users, but also a list of Blocked domains/users, directly in the admin console.

[alexgrutza]

We've recently observed where thankfully I put in a quarantine compliance rule for any macro filetype names in the subject which stops the email from being delivered (saved 100+ users from that easy vector) BUT the Drive App within Chat still notifies the user and allows them to click the file/link in which it downloads Zoho Assist all precompiled configs and performs IOC/attck vectors.. Plug one hole and another leak springs up.. 

[Kim_Nilsson]

😢whack-a-mole

[CMaciel]

We have been getting hit hard the past few weeks. It is really frustrating. I was able to block the URL the threat actors use to steal credentials. But if they we to ever change that URL, I would be back at square 1. How are you guys dealing with it?

[alexgrutza]

We've noticed the subject for our situations always had a macro enabled document format (primarily docm) so a regex rule to basically just quarantine all those (in addition to exe, zip etc) has  helped us. After the most recent they quickly transitioned a subject to something like "Some_Text_Here_That_Isnt_A_Macro_File" which I may have to figure out a regex for if possible 

Edit: additionaly and i'm not sure it's working but we put a "sender" limit in regex for our student ou (we're higher ed so a single student ou) that limits the amount of "recipient" values to i think 10 (so it would potentially cut down on the 400+ "to" emails from students when they're compromised - all those are quarantined as well (haven't seen any yet so i'm not sure the rule is working..)