Hiding in Plain Sight: How Phishers Are Using Google to Launch Their Attacks

Phishers no longer need their own shady servers. They rent Google's reputation instead, and many email and web filters let them straight through.

For years, spotting phishing was fairly simple: look for a strange sender, a misspelled domain or a link that didn't match the brand. That advice is breaking down. Today a phishing email may come from a Google server, carry a link on a Google domain, and open a page protected by a valid Google certificate.

This is not a flaw in Google. It is attackers abusing free and cheap services that millions of businesses rely on every day. This post explains how common the tactic has become, how a typical attack works, and what users and security teams can do about it.

A tactic that has gone mainstream

Abusing trusted cloud platforms is no longer a niche trick. Security researchers now describe it as a core part of how modern phishing works, and 2026 has brought a steady stream of large campaigns built on Google services.

• Emails sent from google.com itself. Early in 2026, researchers uncovered a campaign that abused the "Send Email" feature of Google Cloud Application Integration. The phishing mails came from a genuine Google address, linked to Google Cloud Storage, and ended on a fake Microsoft 365 login page.
• A global operation on Firebase and Google Translate. Another large campaign hosted phishing pages on Firebase and disguised them behind Google Translate links. Stolen credentials were traced to more than 1,000 organisations in over 100 countries, and India was among the five most-affected countries.
• A named trend, not a one-off. Researchers now call this "trusted infrastructure phishing": every stage of the attack, from sending the email to stealing the password, runs through legitimate, business-approved cloud services.

Google is not the only platform being abused. Microsoft Azure, AWS and Cloudflare appear in the same reports. But Google's services are free, fast and trusted almost everywhere, which makes them a favourite.

How a typical attack unfolds

Most of these campaigns follow the same basic pattern, whatever the lure.

1. The lure. An email warns of an unpaid bill, a full mailbox, a shared document, a voicemail or a suspended account. It creates urgency and gives one button to click.
2. A trusted sender or a borrowed identity. The message comes from a Google Cloud server, a Google automation feature, or a spoofed company domain. Basic reputation checks often pass it.
3. A Google-hosted first link. The button points to Cloud Storage, Firebase, Sites, Docs, Forms or a Google Translate URL. To a filter and to a user, it looks safe.
4. A hidden redirect. That first page quietly forwards the victim, sometimes through a CAPTCHA, to the real phishing site. The malicious address appears only after the click.
5. The theft. A convincing copy of a login or payment page collects passwords, one-time codes or card details. Some kits then send the victim to the genuine website, so nothing seems wrong.
6. Rinse and repeat. When one page is reported and removed, the attacker creates another under a new random name within minutes.

Why attackers love Google

Google is not doing anything wrong here. Its services are simply too trusted, too cheap and too widely used to block outright. This technique is often called "living off trusted sites", and it defeats defences in five ways.

• Domain reputation. Most email and web filters score links partly by the reputation of the domain. storage.googleapis.com, docs.google.com and sites.google.com have excellent reputations, so a malicious page hosted there often scores as safe.
• Nobody can block it. Blocking googleapis.com would break thousands of legitimate apps, websites and business tools. Attackers know defenders must allow it.
• Valid HTTPS by default. Every Google-hosted page comes with a valid certificate and a padlock in the browser. Users have been trained to trust the padlock.
• Cheap and disposable. A storage bucket or virtual machine costs almost nothing and takes minutes to create. When one is reported and taken down, the attacker creates another with a new random name.
• Clean sending IPs. Mail from a fresh Google Cloud address does not carry the bad history of known spam networks, so IP-reputation lists may not flag it on day one.

The Google services phishers abuse most

Cloud Storage is only one option. Attackers use a wide range of Google products, often chaining two or three together so that every hop looks legitimate.

The common thread is that the first thing a user or a filter sees is a Google address. The malicious destination only appears after the click.

Red flags anyone can spot

A Google link is not proof that a message is safe. Before clicking, check for these signs.

• The sender and the brand don't match. A storage bill from an unrelated company's domain, or a sender name that differs from the brand in the email, is a warning.
• You don't recognise the service. If you can't name the provider you supposedly pay, you probably don't pay them.
• It arrives at a shared address. Bills and account alerts go to the person who holds the account, not to sales@ or info@.
• It creates urgency. Red banners, "final notice" and threats to delete files or close accounts are designed to stop you thinking.
• The link leads somewhere unexpected. A real billing or login link goes to the provider's own website, not to a storage bucket, a Firebase site or a translation page with a random name.
• The login page lives on the wrong domain. A Microsoft, bank or payment login that is not on that company's own address is fake, however real it looks.
• The details are generic or odd. No name, no account number, a placeholder company address, or awkward wording produced by an automated kit.

The safest habit is simple. Never pay or log in from an email link. Open the provider's app or type its address yourself and check your account there.

What security teams should do

Domain reputation alone cannot stop these attacks. Defenders need to judge what a link does and whether a sender's story holds together.

1. Enforce SPF, DKIM and DMARC checks on inbound mail. A message claiming to be from a company domain but sent from an unrelated cloud server should fail. Quarantine failures instead of just tagging them.
2. Check that the sender's story holds together. When a mail server on a public cloud announces itself as a company domain, or the sender name, address and brand all differ, raise the spam score sharply.
3. Treat links to cloud storage and free hosting as their own category. Links to storage.googleapis.com, web.app, firebaseapp.com, translate.goog and similar hosts in unsolicited mail deserve extra inspection, even though the domains are trusted.
4. Follow the redirect chain. Inspect where a link finally lands, not only its first hop. Sandboxing or time-of-click URL checks catch pages that change after delivery.
5. Inspect page content, not just the URL. A page asking for card details or a password on a domain that does not belong to the brand it shows is phishing, wherever it is hosted.
6. Combine weak signals. A payment lure, a mismatched sender, an HTML-only message and a cloud-hosted link are each weak on their own. Together they are a strong signature.
7. Use phishing-resistant MFA. Hardware keys and passkeys stop a stolen password from being enough, however convincing the fake page was.
8. Train for this specific tactic. Teach staff that a Google, Microsoft or other trusted domain in a link does not make it safe.
9. Report and hunt. Report malicious pages to the hosting provider's abuse team so they are taken down. Then search your mail logs for the same sender, subject or link pattern to find other recipients.

Attackers will keep moving to whichever platforms defenders are least willing to block. The answer is not to block Google. It is to stop treating any domain as automatically safe.