Why do phishing links use Google, Microsoft and other trusted cloud services?

Most phishing advice says "check the link before you click." That advice struggles when the link really does point to docs.google.com, sharepoint.com or a big cloud provider's storage. Attackers know this, and increasingly host the dangerous part of a phishing attack on trusted platforms. This guide explains why it works, how to judge a link on a trusted domain, and how admins can block one page without blocking a whole service.

What are phishing links on trusted cloud services?

Phishing links on trusted cloud services are links in phishing emails that point to a page, form, file or redirect hosted on a well-known, legitimate platform rather than on a domain the attacker registered. Some security writers informally call this "living off trusted sites"; it isn't a formal category, and MITRE ATT&CK covers it under the technique below. The platform is real and so is its domain; the content was put there by the attacker using an ordinary account.

MITRE ATT&CK, the public catalog of attacker techniques, describes this under "Link Target": adversaries may "use free or paid accounts on link shortening services and Platform-as-a-Service providers to host link targets," "taking advantage of the widely trusted domains of those providers to avoid being blocked."

This guide covers links in ordinary phishing emails. If the email is a "someone shared a file with you" notification from OneDrive, SharePoint, Google Drive or Dropbox, read file-sharing notification phishing, which explains how to check a share notification safely. For comment mentions in Google Docs, see Google Docs comment phishing.

Which trusted services do attackers abuse?

Attackers abuse almost any service that lets a free or compromised account publish a public page, form or file. The common categories look like this:

Microsoft has documented several of these in its own threat reporting. Its October 2024 report covers campaigns misusing SharePoint, OneDrive and Dropbox. Its January 2026 report on a campaign against energy-sector organizations says "threat actors continue to leverage trusted cloud collaboration platforms." In that campaign, a phishing email came from a trusted organization's likely compromised address, the SharePoint link led to a credential prompt, and the attacker then sent over 600 phishing emails from the hijacked mailbox to the victim's contacts.

Why do filters let links to trusted domains through?

Filters let these links through because most link checks start with the reputation of the domain, and trusted platforms have excellent reputations. Several factors stack up:

• The domain can't be blocked. A business can't block docs.google.com or sharepoint.com without breaking real work. Filters have to judge the individual page, which is harder.
• The page may look harmless to a scanner. A one-page document with a button, or a form with two text fields, has no malware and no obvious lookalike domain. The harmful step is a click or two further on.
• Sign-in walls hide the payload. Microsoft's 2024 report says attackers made files available only to the intended recipient, after re-authentication and for a limited time, which made "detonation and analysis of the sample with the malicious link almost impossible."
• Real senders pass authentication. When the email comes from a compromised supplier, SPF, DKIM and DMARC pass because it really is that supplier's mail. Microsoft's January 2026 report says these lures "frequently evade traditional email-centric detection mechanisms."
• Allow lists widen the gap. Microsoft notes that in many organizations "users from trusted vendors are added to allow lists," so mail from them gets fewer checks.

Open redirects add a twist. In Microsoft's 2021 write-up, attackers used redirect links on legitimate domains so that a user hovering over the link "may still see a domain they trust and thus click it." The redirect led to a reCAPTCHA page, which Microsoft says was used "to possibly evade attempts at dynamically scanning and checking the contents of the page," and then to a fake sign-in page.

How do I tell if a link on a trusted domain is phishing?

You tell by judging what the page asks you to do, not where it's hosted. A trusted domain means the hosting is genuine; it says nothing about the author. Work through this checklist:

1. Did you expect it? An unexpected "invoice", "contract", "secure message" or "voicemail" is the usual lure, even from a known contact.
2. Read the whole link, not just the start. A link that begins with a well-known domain but contains a second address after ?url=, ?redirect= or &dest= is probably a redirect. Our guide on how to check if a link is safe shows how to read the real destination.
3. Look at what kind of page it is. A form, a one-page document with a single big button, or a "portal" on a site builder is a doorway, not a document.
4. Does it ask for a password? Real Microsoft 365 or Google sign-in happens on their sign-in pages, never inside a form, document or storage page. Microsoft's advice for Forms is "never providing personal information, such as passwords, in any form or survey" (Microsoft Support).
5. Does the next step leave the platform? A Google document whose button leads to an unrelated domain, or a SharePoint file that links to a sign-in page elsewhere, is the classic chain.
6. Confirm with the sender another way. Call them on a number you already have. If their account was hijacked, they need to know anyway.

Here's an invented example of a lure that uses a trusted form:

Example of a lure (not a real message): From: "IT Service Desk" <servicedesk@northwind-support.example> Subject: Mailbox verification required by 5 PM

We are upgrading mailbox storage. To keep your account active, complete the verification form below. https://docs.google.com/forms/d/e/1FAIpQ-EXAMPLE/viewform

The form is hosted on a genuine Google domain. It still asks for your work email and password, which no real IT team collects through a survey. The same lure appears in our guide to mailbox full and account suspended phishing.

What should I do if I entered my password on a trusted-looking page?

If you entered your password on a form, document or page reached from an email, treat the account as compromised, even though the page was on a Google or Microsoft domain.

1. Change the password from a device you trust, by typing the service's address yourself.
2. Tell your IT team so they can revoke your sessions and check for new MFA methods, inbox rules and forwarding. After this kind of compromise, Microsoft's January 2026 report recommends revoking session cookies and reversing attacker-made MFA changes as well as resetting the password.
3. Report the page so it can be taken down (see the next section).
4. Warn your contacts if anything was sent from your account afterwards.

The full checklist is in what to do after clicking a phishing link.

How do I report a phishing page on Google or Microsoft services?

Report the page to the platform that hosts it, and report the email to your own admin. Doing both gets the page taken down for everyone and the email removed from your colleagues' inboxes.

• Google Docs, Sheets, Slides and Drive files: open the file, select Help > Report, choose the type of abuse and submit. Google Forms respondents select Help > Report at the bottom left, then Submit Abuse Report (Google Docs Editors Help). Google says a report doesn't guarantee any action.
• Microsoft Forms: "Below the Submit button at the bottom of the suspected form, click Report abuse." Microsoft also says Forms uses "automated machine reviews to proactively detect malicious password collection."
• Other hosting and storage: use the provider's abuse reporting form. Include the full URL and say it's phishing.
• The email: use the report button in Outlook or Gmail. See how to report a phishing email.

How can admins block a phishing page without blocking the whole service?

Admins should block the specific hostname or path, never the whole platform, and avoid allow-listing platforms in the first place. At the time of writing (November 2026), these are the main controls.

Microsoft 365

1. Block the exact URL. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Tenant Allow/Block Lists, select the URLs tab, then Add > Block. Microsoft says messages containing blocked URLs are "blocked as high confidence phishing" and quarantined. The default Remove block entry after value is 30 days (Microsoft Learn).

2. Use path syntax, not the platform domain. A right wildcard after a slash matches a path, so an entry like contoso.com/a/* covers that folder only. For a storage account, block the account's own hostname, not the provider's whole domain. In PowerShell:

   # Example values: block one storage account host and one form path for 30 days (the default)
   New-TenantAllowBlockListItems -ListType Url -Block -Entries "badaccount.blob.core.windows.net","docs.google.com/forms/d/e/1FAIpQ-EXAMPLE/*"
   

3. Keep time-of-click checks on. With Defender for Office 365, Safe Links scans links before delivery and again on click. Microsoft notes Safe Links "no longer wraps URLs pointing to SharePoint or OneDrive sites, but the URLs are still processed by the Safe Links service" (Microsoft Learn). See our Safe Links guide.

4. Purge the copies. Find and remove every delivered copy; see remove a phishing email from all mailboxes.

Google Workspace

1. Turn on link protections under Apps > Google Workspace > Gmail > Safety, including Identify links behind shortened URLs and Show warning prompt for any click on links to untrusted domains. See advanced phishing and malware protection.
2. Act on a specific URL with a content compliance rule that matches the URL pattern and quarantines the message. See Google Workspace content compliance rules.
3. Remove delivered copies with the security investigation tool, where your edition includes it.

Don't allow-list platforms

The fastest way to make this attack worse is to add a cloud platform, or a vendor's whole domain, to an allow list because it was flagged once. Allow entries skip checks for everything that matches. Our guide to whitelisting senders explains narrower alternatives. A filter in front of your mailboxes adds another set of checks on links and senders before mail is delivered; see how iBlockSpam works with Microsoft 365.

Next steps

• Teach one rule: a trusted domain tells you who hosts a page, not who wrote it, and passwords never go into forms or documents.
• Check your allow lists for whole platforms or vendor domains, and narrow or remove them.
• Practice blocking one URL path in the Tenant Allow/Block List or with a Gmail content compliance rule, so you can do it quickly during an incident.
• Cut down the lures that reach inboxes. iBlockSpam filters phishing and spoofing at the MX before mail reaches Microsoft 365 or Google Workspace, and the free Email Header Analyzer shows where a suspicious message really came from.

Browse our other phishing and threat guides.