Borrowed Reputation: When the Phishing Page Lives on Google's Servers

Another build-in-public post from the team building Reput.io. This time it's about a phishing campaign making the rounds right now, what it taught us about trusting "big brand" infrastructure, and two refinements we shipped after running our own indicators through our own API. If you've ever waved through a googleapis.com URL without a second look, this one's for you.

The trick is almost too simple

Here's a line from recent reporting on Tycoon 2FA, an adversary-in-the-middle phishing kit (tracked as Storm-1747) that steals Microsoft and Google session tokens:

For Google Workspace targets, the initial phishing lures are frequently staged on legitimate Google Cloud storage to abuse built-in reputation trust.

Read that again, because it's the whole game. The attacker doesn't register g00gle-login.xyz and hope nobody notices. They drop the lure on storage.googleapis.com. The domain is Google's. The file on it is theirs.

And it works, because we've all trained ourselves (and our tools) to relax the moment we see a famous hostname. Google owns it, so it must be fine, right? That reflex is exactly what the campaign is built to exploit. There's even a name for it: Living Off Trusted Sites, or LOTS.

There's a nice irony buried in the kit, too. To dodge analysis, it actively blocks connections from cloud-provider IP ranges (the sandboxes and scanners that would unmask the page). So it hides from the cloud while hosting on the cloud. Same infrastructure, two opposite jobs, depending on who's asking.

One more thing worth saying: there's no CVE here. Nothing is being patched. The kit abuses things working exactly as designed, OAuth device codes, Entra device registration, and your instinct to trust a Google URL. You can't patch a reflex. You can only stop scoring the brand as if it were the verdict.

The rule this puts to the test

Reput.io exists to answer one question that most threat feeds skip: is this thing demonstrably known-good? Answer it well and an analyst can clear the huge pile of benign noise (Teams, Windows Update, a CDN edge) and spend their attention where it counts.

But "known-good" has a line we will not cross, and it's the one Tycoon 2FA walks right up to:

• We'll happily fix a wrong label. If a feed calls a Microsoft Teams IP a "Commercial VPN," we'll correct that. (We wrote about that one a few weeks back.)
• We will never call a customer-controlled cloud IP benign. AWS, Azure, GCP, Cloudflare, DigitalOcean: anyone can spin up a box there in minutes, so they stay at investigate. Only first-party infrastructure that doesn't rent out hosting, think Apple, Meta, government registries, public DNS resolvers, gets to be likely_benign.

A Google Cloud Storage URL sits squarely in the first column of cloud. So it should come back as investigate. Always.

So we checked our own work

Before we said any of this out loud, we did the thing we keep telling everyone else to do: we stopped trusting the label and looked at the behavior. We ran storage.googleapis.com through our own API.

It came back exactly as it should:

{
  "indicator": "storage.googleapis.com",
  "status": "whitelisted",
  "verdict": "investigate",
  "risk_description": "Popularity does NOT guarantee legitimacy - attackers frequently abuse popular services (LOTS - Living Off Trusted Sites). Context required.",
  "recommendation": {
    "action": "allow_with_logging",
    "false_positive_likelihood": "medium",
    "investigation_hint": "Popularity alone isn't trust. Check what the domain actually does."
  }
}

investigate, not benign, even though the host is whitelisted as a popular, high-traffic domain. That's the line holding. Getting there, though, made us tighten two things.

Two refinements

1. A whitelist hit can't override "investigate" for cloud. We made the rule explicit: once we identify an indicator as customer-controlled cloud or CDN, that investigate verdict wins. Being present in a popularity or infrastructure list can no longer quietly soften it to benign. The underlying reasons and categories all stay in the response, so you still see the full picture and make the call. This is the safeguard that beats the borrowed-reputation trick head-on.

2. Public resolvers are infrastructure, not just "an IP in a cloud." While we were in there, we sharpened a neighboring case. 8.8.8.8 lives in Google's network and 1.1.1.1 lives in Cloudflare's, but they're public DNS resolvers, critical internet plumbing, not somebody's rented VM. They now correctly come back as likely_benign, while a genuine workload in the very same network still gets investigate. What an indicator is outranks whose address space it happens to sit in.

Both changes shipped with tests pinned to the real indicators that prompted them, plus a short write-up of why each one exists, so a future tweak can't quietly undo the reasoning. We try to treat our own verdict logic the way we ask you to treat your alerts: assume nothing, check, write down why.

The one thing to take away

Forget about us for a second. The takeaway is simple and it'll outlast this particular campaign:

A famous hostname or IP is a clue, not a conclusion.

Attackers know your tools trust Google, Microsoft, and Cloudflare on sight, and they build campaigns on top of that trust. So when storage.googleapis.com or an AWS IP shows up in an alert, the question isn't "is this Google?" It's "what's actually being served here?" Check the path. Check the Host header and the SNI. Look at the file. The brand name on the door tells you nothing about who's inside.

That's the line we hold in every response we send. A phishing kit doing the rounds this month was a good nudge to make sure we hold it everywhere.

---

Reput.io is a whitelist intelligence API for SOC teams, built on 1.4M known-good indicators from 200+ sources. Try the free tier or read the docs.