Join our Newsletter — 33% off our NHI Course

What are the signs that a Google-based phishing campaign is using collaboration features as an attack channel?

Common signs include unexpected file-share emails, comment notifications that contain links, unusual sender names that mimic coworkers, and documents with authentic-looking titles but suspicious destinations. Another warning is multilingual or branded content that still routes through a familiar Google interface. Security teams should investigate any notification where the link context, sender identity, and document purpose do not align.

What collaboration-feature phishing looks like in practice

When attackers use Google collaboration features as the delivery path, the campaign often looks less like a classic “malware attachment” phish and more like routine workspace activity. The abuse pattern matters because the message may arrive through a trusted Google workflow, while the real signal is a mismatch between the notification, the sender, and the destination.

One useful way to read the page is to separate the surface event from the underlying trust abuse. A file-share notice, comment alert, or document invitation is not automatically malicious, but it becomes suspicious when it asks the recipient to follow a link that does not align with the stated business purpose or the expected collaborator.

That pattern is especially common in document-sharing workflows that resemble ordinary business use. Attackers can make a message look familiar by copying coworker names, using branded or multilingual content, and hosting the lure inside an interface users already trust. For background on how attacker tradecraft often blends with legitimate cloud and identity workflows, see The 52 NHI breaches Report and the broader Ultimate Guide to NHIs.

Signals that the notification is being used as the lure

The clearest signs are usually consistency failures. A collaboration notification should match the sender, the content, and the expected workflow. If a document claims to be about a familiar project but the share came from an unexpected account, if the comment trail contains an odd external link, or if the title looks legitimate while the target location is unrelated, the message deserves scrutiny.

Look closely at the language and the routing path. A polished localised message can still be fraudulent if the recipient is redirected into a different tenant, a strange sign-in flow, or a page that asks for credentials unrelated to the original document action. That mismatch is often more important than the wording itself, because the abuse is happening through trust in the collaboration channel rather than through obvious technical indicators.

Teams should also pay attention to repetition and timing. Messages that cluster around busy periods, urgent document reviews, or project handoffs often aim to exploit normal attention shortcuts. Google-style notification design can make these prompts feel routine, which is why reviewers should confirm whether the share, comment, and document context all belong to the same legitimate business event.

For related attack patterns where phishing is used to steal credentials or tokens through trusted business workflows, the CoPhish OAuth Token Theft via Copilot Studio case study and MailChimp Breach are useful reference points.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 DE.CM — Continuous Monitoring Workspace phishing is caught by monitoring anomalous notifications and link destinations.
Recommendation — Monitor collaboration notifications for inconsistent sender, content, and destination patterns.
CIS Controls v8 8 — Audit Log Management Detection depends on reviewing sign-in, sharing, and link-follow events tied to the lure.
14 — Security Awareness and Skills Training Users need to recognize mismatched share/comment cues in collaboration-feature phishing.
Recommendation — Centralize and review collaboration access and link-click telemetry for anomalies. Train users to verify notification context before opening shared documents or links.
MITRE ATT&CK T1566 — Phishing The campaign uses deceptive collaboration notifications as the delivery mechanism.
Recommendation — Map observed collaboration lures to phishing detections and hunt for follow-on credential theft.
NIST SP 800-63 – — Phishing-Resistant Authenticator Guidance These lures often aim to capture credentials after redirecting users to lookalike sign-in flows.
Recommendation — Prefer phishing-resistant authentication where collaboration workflows can lead to sign-in prompts.

Practitioner Guidance

What to verify: Check whether the notification source, the document title, and the link destination all point to the same expected collaboration event. If any one of those elements is inconsistent, treat it as suspicious even if the message renders inside a familiar Google UI.

Common mistake: Defenders often over-weight sender display names and under-weight the link context. In collaboration-feature phishing, the sender can look plausible while the true signal sits in the destination, the sharing relationship, or the request embedded in the comment or file notification.

What practitioners underestimate: User trust in workspace notifications is often stronger than their suspicion of email. That makes these campaigns effective even when the content is not technically sophisticated, because the workflow itself supplies credibility.

Practitioner takeaway: The right test is not “Does this look like Google?” but “Does every part of the collaboration event fit the expected business context?” If the answer is no, investigate before the user follows the link or signs in.