How to reduce Google Drive share phishing in Google Workspace

There is no setting that safely eliminates Drive-share phishing for every district without also affecting legitimate external collaboration.

That sentence is the honest starting point, and it is why this guide is about reducing the attack rather than stopping it. The attack rides on one Google feature: an outside account can share a file with your users and Google will tell them about it. The only complete block is to refuse every inbound external share, which also refuses the college admissions office, the textbook vendor, the parent returning a form, and the presenter sending slides. Some parts of a district can live with that. Most cannot, and the controls below exist to let you draw the line in different places for different people.

How the attack works, and why the notification itself is genuine, is covered in Google Drive share phishing: why the email is real and the document is malicious.

The short answer

Leave Google's automatic protections on. They reduce the volume that reaches inboxes. They do not reduce it to zero, and nothing here changes that.

The control that matches the attack is who can receive external shares, not who can share externally. These are separate options in the same settings page, and a district that has turned off sharing out while leaving receiving on is fully exposed.

Tighten receiving where it costs little and keep it open where jobs need it, using the allowlist on any edition, or trust rules on Education Standard and Plus, to say which people can receive from whom.

2-Step Verification reduces the chance that your accounts become the sharer in somebody else's incident. It does nothing to make a share you receive trustworthy.

Training comes down to one sentence about what a Google notification proves and what it does not.

What Google does on its own

Google states that Drive "tries to detect and block spam and phishing sharing from external users", and Drive Help describes the mechanism: files shared from outside your organization are evaluated for phishing or malware, access is blocked if something is detected, and likely spam is "either blocked or redirected to spam view." Suspicious files open with a warning banner. Docs, Sheets and Slides files owned by or shared with someone outside your domain carry an External badge with a pop-up that offers to report the file; administrators control that badge under Drive sharing settings as Highlight external files, and it is on by default. Google documents one gap in the badge: it is not shown when an internal Google Group has access to the file, even if that group has external members.

Keep all of it on. Then plan for what gets through, because the campaign that reaches your inboxes is the one Google's classifier did not recognize yet.

Drive's external sharing settings answer two different questions, and the one most districts have thought about is the wrong one for this attack.

Sharing outside your organization governs files owned by your users: whether they can share them with people outside the domain, and with whom. Its options are on, off, or allowlisted domains only. Turning it off protects your data from leaving. It has no effect on a stranger sharing a file to your users.

Receiving files from outside is the option that governs the attack. Google's own guidance for Drive spam and phishing describes the setting and the recommended posture:

Allowlist: First, create a list of trusted domains. Then choose which internal users are limited to getting file shares only from users in those domains. Then allow sharing only with allowlisted domains and uncheck the option to allow users to receive files from outside of allowlisted domains. This approach is supported for all Google Workspace editions.

CISA's published baseline for Google Workspace quotes the checkbox itself as Allow users to receive files from users or shared drives outside of allowlisted domains, and its instruction is to deselect it. With that box unchecked for a set of users, an account outside the allowlist cannot share a file to them at all, and the notification is never generated.

The cost is exactly what it sounds like. Those users can no longer receive a Drive share from any domain not on the list: not from a college, not from a vendor, not from a parent's Gmail account, not from the neighboring district you have not added yet. That is why the setting is applied per organizational unit or group rather than flipped for the whole domain, and why the next two sections are about drawing the line. Allow for propagation as well: Google notes that it can take up to 24 hours to see changes to sharing settings, and that a trust rule whose scope names no organizational unit can take up to 24 hours to apply.

The allowlist

An allowlist of trusted domains works on every Google Workspace edition. The pattern Google describes is: build the list, set external sharing to allowlisted domains, and turn off receiving from outside the list, for the organizational units where that is acceptable.

Two things about allowlists that experience with them teaches.

The list needs an owner. Domains get added during a crisis and never reviewed. A list nobody owns grows until it stops meaning anything.

An allowlisted domain is trusted, including its compromised accounts. If you allowlist a partner district, a compromised account at that district can share into yours freely. Google's guidance addresses this directly: "Ensure that all domains on your allowlist require 2-Factor Authentication or use other account security practices. These authentication measures limit the likelihood of compromised accounts being used to send spam." That is a conversation to have with each partner before you add them, not after.

Trust rules, on Education Standard and Plus

Trust rules are Google's more granular version of the same idea, and Google lists the editions: "Frontline Plus; Enterprise Standard and Enterprise Plus; Education Standard and Education Plus; Enterprise Essentials Plus." Education Fundamentals does not have them; it has the allowlist above.

A trust rule has a scope, a trigger, a condition and an action. The trigger is the part that matters here, and Google defines both:

If a rule's trigger is Sharing files, the scope is the user who owns the file for which you want to control sharing.
If a rule's trigger is Receiving files, the scope is the intended recipient of the file.

Receiving files is the trigger that governs Drive-share phishing. Its scope is your users, chosen by organizational unit or group, and its condition is who the file's owner may be: your organization, specific groups, allowlisted domains, "external domains not on your allowlist", or anyone with a Google Account. Google ships two default rules that allow sharing and receiving within the organization and sharing with anyone who has a Google Account; you cannot edit them, but you can deactivate them and replace them with your own.

What trust rules buy over the allowlist is different answers for different people in one policy. Students can be limited to receiving from your own organization and a short list of testing and college domains. General staff can receive from anyone with a Google Account. The business office and HR can be limited to allowlisted vendors and the organization itself. All three are receiving rules, and none of them touches what anyone can share out.

A K-12 approach

This is an example, not a prescription. Every district's external relationships are different, and the point of the exercise is to find where restriction costs nothing.

Who	Receive external shares from	Why
Students	Your organization; allowlisted testing and college domains	Students rarely have a legitimate reason to receive an unsolicited Drive share from an arbitrary outside account, and they are a large, inexperienced target population
Business office, HR, payroll	Your organization; allowlisted vendors and agencies	These are the roles impersonated and the roles targeted, and their legitimate external partners are a known, short list
Teachers and general staff	Anyone with a Google Account, or a broad allowlist	Their jobs genuinely involve outside collaborators, and a blanket restriction here is where districts lose the argument
Administrators	Your organization; allowlisted domains	Small group, high value, and their external contacts are known

Before restricting any group, measure what they legitimately receive. Your Drive log does not record inbound external shares (Google logs those on the owner's side), but the files themselves are visible in each user's Drive. If you use GAM, this lists everything in one organizational unit's Drives that its users do not own, with the owner's address and when it arrived; filter the owners to addresses outside your domain to see the real inbound traffic before you cut it off:

gam ou "/Students" print filelist showownedby others fields id,name,owners.emailaddress,sharinguser.emailaddress,sharedwithmetime

showownedby others selects files the user does not own; without it GAM lists only the user's own files. The command reads and changes nothing, and it runs one Drive query per user, so start with a small unit.

Whatever line you draw, keep the External badge on for everyone, publish one reporting path, and tell people what changed and why. A restriction nobody understands gets worked around.

A reference point: the federal baseline

CISA's Secure Cloud Business Applications baseline for Google Workspace Drive and Docs states its own scope: it was "tailored to the federal government's threats and risk tolerance", and "organizations outside of the federal government may also find these baselines to be useful references to help reduce risks even if such organizations have different risk tolerances or face different threats." Its Drive policies say that external sharing "SHALL be restricted to allowlisted domains", that "receiving files from non-allowlisted domains SHOULD be disabled", and that warnings "SHALL be enabled when a user is attempting to share with someone in a non-allowlisted domain."

Read it as a picture of what tight looks like, from a source with no product to sell. A district that adopts it wholesale will also discover what it costs; the value is in knowing where the strict end of the range is.

2-Step Verification

A phishing share that arrives from a legitimate school-domain account should raise immediate concern that the account is compromised, and Google's own Drive spam guidance ties the two together by asking you to confirm your allowlisted partners require 2-Factor Authentication. Enforce it on your own staff for the same reason: it reduces the chance that one of your accounts becomes the sharer in the next district's incident.

Google's deployment page describes the mechanics. Enforcement can be turned on immediately or from a chosen date, and a New user enrollment period of "1 day to 6 months" can be set so that new employees have time to enroll; Google notes that "during this period, users can sign in with just their passwords." Enforce it by organizational unit, staff first.

Be precise with staff about what it does. 2-Step Verification makes a stolen password alone insufficient in many attacks; it protects their account, and not all methods equally. Google calls security keys "the most secure form of 2SV" and says they "protect against phishing threats", so administrators and other high-value accounts are where a key earns its place. None of it makes a document shared to them any safer, and a district that presents it as phishing protection will find people treating received shares as vetted.

Gmail settings that help at the edges

Gmail's advanced phishing and malware protection settings are available on Education Fundamentals, Standard and Plus, and they are worth turning on. Their reach into this particular attack is limited, and it helps to know exactly where.

Protect against spoofing of employee names covers "messages where the sender's name is a name in your Google Workspace directory, but the email isn't from your company domain." That catches the classic variant, an outside address wearing the superintendent's name. In a Drive notification the sender is Google's service, and Google does not document whether the check applies to its own notification mail. The lookalike-domain and unauthenticated-mail settings are aimed at spoofing too, and a Drive notification is not spoofed.

Show warning prompt for any click on links to untrusted domains is described by Google as displaying "a warning when you click a link to untrusted domains in any email message." The link in a Drive notification points to docs.google.com. The hostile link is inside the document, one click further on, where Gmail's setting does not reach. Drive's own warning banners and the External badge are the controls that apply there.

What to tell staff

One sentence carries the whole training: a Google notification proves that Google sent an email; it does not prove that the person who shared the file is who they appear to be, or that anything inside the file is safe.

Then two habits. Look at the account that shared it, not the name. Report it in Drive (Block or report under Shared with me) or Gmail (Report phishing) and tell IT, rather than forwarding it to colleagues to ask. And one policy decision that makes both habits easier: leadership and the business office never send pay, HR or evaluation documents by unsolicited Drive share, so that any such share is suspect on sight.

What not to do

Do not block Google's notification address. The reasons are their own guide.

Do not turn off receiving for the whole domain in the middle of an incident. Measure first, restrict by unit, and tell people. The helpdesk load from a district-wide cutoff arrives the same afternoon.

Do not treat an allowlisted domain as safe. You have trusted its compromised accounts as well as its real ones.

Do not present 2-Step Verification as protection against received shares. It protects the account, not the inbox.

Do not turn off the External badge because it is noisy. It is the one indicator that answers the right question on the file itself.

Sources

Help prevent Drive spam and phishing — Google Workspace Admin Help. The allowlist and trust-rule measures, and the 2-Factor Authentication advice for allowlisted domains.
Manage external sharing for your organization — Google Workspace Admin Help. Sharing options, allowlisted domains, and the Highlight external files indicator.
Create and manage trust rules for Drive sharing — Google Workspace Admin Help. Supported editions, the Sharing files and Receiving files triggers, conditions, and the default rules.
Learn how we help keep Google Drive secure — Google Drive Help. Automatic evaluation of external shares.
Mark or unmark spam in Drive — Google Drive Help. The spam view and Block or report.
Enhance Your Organization's Security with Out-of-Domain File Warnings — Google Workspace Updates. The External badge.
Deploy 2-Step Verification — Google Workspace Admin Help. Enforcement options and the new user enrollment period.
Protect your business with 2-Step Verification — Google Workspace Admin Help. "Security keys are the most secure form of 2SV and protect against phishing threats."
Advanced phishing and malware protection — Google Workspace Admin Help. The spoofing and link-warning settings quoted above.
SCuBA Secure Configuration Baseline: Google Workspace Drive and Docs — CISA, via the ScubaGoggles repository. The external sharing and receiving policies and the scope statement.
GAM wiki: Users - Drive - Files - Display — GAM7 documentation. print filelist, showownedby others, and the sharinguser fields.

None of these controls is a product feature, and none of them needs one. Where ORINEX Workspace Compliance enters is after the fact: finding every mailbox a notification reached and removing it after review, and the containment steps on any account that took the bait. What ORINEX Workspace does.