Google Drive share phishing: why the email is real and the document is malicious

A Google Drive sharing notification can be generated by Google itself, pass every email authentication check, and still hand a staff member a phishing document carrying the superintendent's name. What is actually happening, what Google's own protections do and do not catch, and what to tell staff.

A teacher gets an email before first period: the superintendent has shared a document called Salary Schedule Update. The message is not spoofed. Google sent it, from Google's own servers, and it passes SPF, DKIM and DMARC because Google is exactly who sent it. Gmail shows no warning. The teacher opens the document, which lives on docs.google.com like every other document she opens all day. Inside is a short note in the superintendent's voice and a button: Review your updated schedule. The button leads off Google, to a sign-in page that is not Google's.

Every check the teacher could reasonably have made came back clean, because every one of them answered the wrong question.

Dealing with this right now? Investigate the share or remove the delivered notifications. This page is the explanation; those two are the procedure.

The short answer

The notification is genuine. The document is the attack. Google describes this method in its own administrator documentation, and names the reason it works:

One type of phishing method uses Google Drive's collaboration features to trick people into giving out personal or confidential information. Scammers share Drive documents containing harmful links that ask people to enter information. The links can also appear in Drive's automatic email notifications. Because the email notifications come from Google, users might be tricked into thinking message contents are legitimate.

Three identities are involved, and they are usually three different parties. The system that sent the email (Google's notification service), the Google account that shared the file (the attacker, often a compromised account at another school or business), and the person whose name is on the document (your superintendent, HR director or business office, who did nothing). Most of the confusion around these incidents, including the instinct to block the sender, comes from treating those three as one.

Email authentication cannot catch this, because there is nothing false for it to catch. Authentication tells you which domain sent the message. It says nothing about who shared the file or what is inside it.

Google does scan external shares, and blocks or diverts some of them. The ones that reach an inbox are, by definition, the ones that got past that.

How the attack works

The sequence below is assembled from Google's description of the method and from published reports by university security offices. Steps 2 through 5 are Google's collaboration features working as designed; that is the point.

  1. The attacker controls a Google account. In published examples this is frequently a compromised account at another school or organization, and sometimes a free account created with a display name chosen to match a real person.
  2. They create a document in that account's Drive, or upload a PDF to it. The title and the contents impersonate a trusted role: a superintendent's memo, an HR benefits notice, a staff evaluation, a payment request from the business office.
  3. They share it directly with a list of your staff. Staff email addresses and titles are on most district websites, so the list is not hard to build.
  4. Google sends each recipient a notification that the file was shared. It comes from a Google-controlled notification address; published examples show more than one, including drive-shares-dm-noreply@google.com and drive-shares-noreply@google.com. It looks like every legitimate share notification your staff receive, because it is one.
  5. The recipient opens the document. It is hosted by Google, on a Google page, and in this pattern that step is not the one that does the damage.
  6. The document contains the actual lure: a link or button, a QR code, an embedded form, or an instruction to download a "protected" file.
  7. The recipient leaves Google's surface. What waits on the other side is a credential page that may imitate Google's sign-in, a request to grant an application access to their account, or a download. The compromise happens there, and nothing Google sent was fake.

The Penn State security office published an example years ago in which the shared file was named Evaluation.pdf and the notification named a university leader as the sharer while the sharing account belonged to another organization entirely. Brown University's IT security office published a more recent one, with the same shape. The Center for Internet Security documented the mechanism in an active campaign against state and local governments: notifications "originating from a legitimate Google mail server" that "carry a valid Google Domain Key Identified Mail (DKIM) signature and pass sender policy framework (SPF) and Domain-based Message Authentication, Reporting and Conformance (DMARC) authentication checks." The theme changes; the mechanism has not.

Three identities, not one

IdentityWhere it appearsFictional exampleWho controls it
The mail senderThe From address of the notificationA Google notification address such as drive-shares-dm-noreply@google.comGoogle
The Drive sharerNamed in the notification body, in the file's details in Drive, and in the Drive API's sharingUser fieldathletics@lakeshore-csd.example, a compromised account at another district, or dwhitaker.supt@example.com, a free accountThe attacker
The impersonated personThe document title, the display name, the signature inside the fileDr. Dana Whitaker, SuperintendentNobody involved. She was named, not compromised

The Drive sharer is the only one of the three you can usefully act on, and it is the one recipients look at least. Blocking the mail sender blocks every legitimate Drive notification in your domain and leaves the malicious document exactly where it was. Blocking the sharer works against that one account, and campaigns that run on compromised or disposable accounts simply move to the next one; why blocking the sender doesn't stop Drive share phishing takes each of the three apart. Resetting the impersonated person's password does nothing at all, unless the sharer turns out to be an account in your own domain, in which case you have a different incident: see what to check after a Google Workspace account is compromised.

Why these get through

Authentication passes, correctly. Google sent the message. SPF, DKIM and DMARC all confirm that, and they are right.

Gmail's spoofing protections are aimed at a different problem. The relevant Gmail setting, Protect against spoofing of employee names, is described by Google as protecting "against messages where the sender's name is a name in your Google Workspace directory, but the email isn't from your company domain or domain aliases." That describes an outside sender putting your superintendent's name on a message. In a Drive notification the sender is Google's own service. Google does not document whether that check applies to its notification mail, and it should not be assumed to.

Link scanning sees a Google link. The URL in the email points to docs.google.com. The hostile link is one click further on, inside the document.

Reputation is clean. There is nothing unusual about the origin, the infrastructure, or the format. Your staff receive real notifications of this exact shape every day.

A familiar name attached to a familiar workflow. Recipients read the name in the notification and the title of the document. The sharing account's address is there, but it is the detail people skip, and attackers know that.

What Google already does about it

These protections are real, worth leaving on, and probabilistic. Google's own wording is that Drive "tries to detect and block spam and phishing sharing from external users."

Automatic evaluation of external shares. Google Drive Help states:

If you use Google Drive for work or school, Google will automatically evaluate any files that are shared with you from outside of your organization for phishing or malware. If detected, Google will block your access to the file in order to protect you. When Google identifies a file as likely spam, it's either blocked or redirected to spam view.

A spam view in Drive. Files Drive strongly suspects to be unwanted are moved to Spam automatically. A user can also move a shared file there, or right-click it in Shared with me and choose Block or report to report it and, optionally, block the user who shared it. Google is notified, and a file that sits in Spam for more than 30 days is permanently removed. Two limits matter for this scenario: reporting is per recipient, and Google notes that "you can't report files or folders that you or members of your organization own", so a file shared from a compromised account in your own domain is handled as an account incident, not a report.

Warning banners on suspicious files. Drive, Docs, Sheets, Slides and Drawings show a warning banner when a file Google's scanners consider suspicious is opened.

An External badge on files from outside your domain. Docs, Sheets and Slides files that are owned by or shared with someone outside your organization carry an External badge, with a pop-up that explains it and offers to report the file. Administrators control this under Drive sharing settings as Highlight external files; it is on by default. Google documents one gap: the badge is not shown when an internal Google Group has access to the file, even if that group has external members.

None of these is a control you can point to and say "that will stop it." They reduce volume. Everything below is about what reaches an inbox anyway.

What staff should look for

In order of how much each one is worth:

  1. The address of the account that shared it, not the name. Your superintendent shares files from your domain. A share from gmail.com, from another district's domain, or from a business you have no dealings with is the tell, whatever the display name says.
  2. The External badge on the file, or an "outside your organization" line in the notification. Both exist to answer exactly this question.
  3. What the document wants from them. A real shared document shows its content. One that asks for a click to another site, a sign-in "to view", a QR code, a download, or a form asking for credentials or payroll details is a lure.
  4. The theme. Pay, benefits, evaluations, contracts, and urgent requests from leadership recur in the published examples aimed at school staff.
  5. If in doubt, verify out of band. Call the person on a number already in the directory. Do not reply to the notification, and do not use contact details from inside the document.

What administrators should tell staff

Three sentences, repeated until they stick:

  • A Drive notification from Google proves that Google sent an email. It does not prove who shared the document, and it does not make anything inside the document safe.
  • Look at the account that shared it. If it is not one of ours, and you were not expecting it, treat it as phishing.
  • Report it and stop. In Drive: right-click the file under Shared with me and choose Block or report. In Gmail: open the notification, click More, then Report phishing. Tell IT. Do not forward it to colleagues to ask whether it is real.

One policy change makes the third sentence easier to follow: decide, and announce, that leadership and the business office never distribute pay, HR or evaluation documents by unsolicited Drive share. Anything that arrives that way is then suspect on sight, without anyone having to inspect an address.

When one is reported

The investigation has its own guide: how to investigate a malicious Google Drive share. In outline:

  • Capture the details before anything is deleted: the recipient, the sharing account, the document title and file ID, the notification time, screenshots.
  • Identify the sharing account. Internal means a compromised account in your domain and an immediate pivot to account containment. External means a scoping problem: who else received it?
  • Find every recipient. Your recipient list is in Gmail, not in Drive; your Drive log records very little about a file your organization does not own. Removing the notification from inboxes, and what can and cannot be done about the file itself, is the remediation workflow.
  • Find out whether anyone clicked, signed in, or granted an application access, and treat each one who did as a compromised account.
  • Report the file, and tell the organization whose account was used. They may not know yet.

Why "it came from Google" is not verification

SPF, DKIM and DMARC authenticate the sending domain. Google's own definition is precise: "DMARC tells receiving email servers what action to take on messages sent from your domain that don't pass SPF or DKIM authentication." The domain in a Drive notification is google.com, Google did send it, and a pass is the correct result.

The hostile parts of the incident, the account that made the share, the document, and the link inside it, are not part of the email's authentication at all. Authentication answers "who sent this message." The question staff need answered is "who shared this file, and what does it want", and no header answers that. The longer version, with what DMARC does protect you from, is why SPF, DKIM and DMARC don't stop Google Drive share phishing.

K-12 specifics

Staff directories are target lists. Names, titles and addresses are on the district website, which is why the impersonation is accurate and the recipient list is complete.

Peer-school accounts make convincing senders. A compromised account at a neighboring district reads as trustworthy to your staff, and if your Drive sharing settings allowlist partner districts, it is trusted by your configuration as well. The controls and their trade-offs are in how to reduce Google Drive share phishing.

The themes follow the school calendar. Payroll changes at the start of a term, evaluations, contract renewals and benefits enrollment all arrive on a schedule, and published campaigns frequently use themes that fit it. That is a pattern from published examples, not a measurement; how often it happens in any one district is not known.

The names on the letterhead are the names in the lures. Superintendent, principal, HR, business office. If a role signs district-wide communications, expect it to be borrowed.

What not to do

Do not block Google's Drive notification addresses. Every legitimate Drive share notification in the district stops arriving, and the malicious document is still shared with everyone it was shared with.

Do not treat a DMARC pass as a clean bill. It is correct and irrelevant.

Do not reset the impersonated person's password as a reflex. Check who actually shared the file first. If it was an account in your domain, act on that account.

Do not click the link to see where it goes. Capture it as text or a screenshot if you can; otherwise leave it.

Do not rely on Google's filters as the control. They reduce what reaches inboxes; they do not guarantee that every malicious share is blocked.

Sources

No tool makes a shared document trustworthy, and the investigation is yours to do. What tooling can do is shorten the hour after a report: find every mailbox the notification reached, remove it after review, and get the containment steps right on any account that took the bait. That is the job Message Removal in ORINEX Workspace Compliance was built for. What ORINEX Workspace does.