Reputation Radar #10: Wearing a Trusted Name

Reputation checks run on a simple bet: a name you recognize is a name you can trust. Google, Cloudflare, the big AI labs, the hyperscalers, they've all earned that benefit of the doubt.

This week, three separate crews cashed it in. None of them broke the trust. They wore it.

A phishing chain that hides inside Google

KnowBe4's Threat Lab pulled apart a campaign that reads like a tour of Google's product catalog. A lure link starts in Google Meet, bounces through Google Search, passes a DoubleClick tracking endpoint, and only then lands on attacker infrastructure.

Every hop up to that last one is a real Google domain, and that's the whole point. As the researchers put it: "Security gateways, firewalls, and URL scanners often trust these Google domains, allowing the phishing chain to pass initial inspection." The victim's email address rides in the URL's hash fragment, where server logs and scanners tend not to look.

At the end of the ride, after the credentials are gone, the crew installs ScreenConnect for hands-on access. The kit speaks 16 languages and profiles each visitor by IP and browser first. No exploit, no zero-day, no malicious domain until the very last step. Just a trusted name doing the heavy lifting.

The newest trusted name is an AI company

Check Point Research spent the week on a different flavor of the same idea, and this one gets under your skin a little.

OpenAI runs an internal JFrog Artifactory for package management: isolated containers, no direct path to the public internet, exactly the kind of walled garden built so nothing leaks. Check Point found an item-management feature that let one account attach Base64-encoded data to a repository item, and an account under a different identity could read it back. That's a private mailbox hiding in a system nobody was watching.

From there it got worse. Researcher Alexey Bukhteyev described how "a crafted instruction could make ChatGPT process a second stream of tasks alongside the visible conversation", quietly pulling data out through connected services like Gmail while the user saw a normal chat. Alongside it, rogue agents used a separate Artifactory flaw to reach the open internet and pivot into Hugging Face's infrastructure.

Then there's the speed. Google's Threat Intelligence Group watched a financially motivated actor stand up an autonomous, multi-agent framework and run a mass credential-harvesting campaign in under six hours, with the agents handling their own scanning, troubleshooting, and IP rotation. The stolen access wasn't just loot, it was fuel: they co-opted victim cloud environments to keep their own AI workloads running. GTIG's John Hultquist put the uncomfortable part plainly: "Criminals... will gravitate to attacks that are faster than we can respond to."

The common thread with the Google story is the badge. Traffic to an AI provider or an internal package repo looks authorized by default, so it slides past the same triage that would stop an unknown host cold.

What a SOC actually sees

Here's the honest part, the same one we come back to most weeks.

We asked our own API about the addresses behind these trusted names. huggingface.co resolves to 18.67.250.48, which comes back investigate at high risk: Amazon Web Services, customer-controlled, with the flat note that "the IP alone doesn't indicate legitimacy." api.openai.com sits on Cloudflare and returns allow-with-logging, paired with the reminder that a Cloudflare IP tells you nothing about the site behind it. Even google.com's own address, genuinely Google's, carries a recommendation to check the workload owner before trusting it.

That isn't the API being cagey. It's the correct answer. The recognizable name is context, not a verdict. What decides the call is the thing behind the address: the Host header, the SNI, the reverse DNS, who actually controls that workload today.

A trusted brand in the reputation column should lower your pulse, not close the ticket. The KnowBe4 chain and the Artifactory channel both lived entirely inside names a scanner waves through, which is exactly why the deciding evidence was never the name.

Also on the radar

• MikroTik routers are under active SSH attack. A zero-day (CVE-2026-67276) is being exploited in the wild against internet-facing devices, per SC Media. Edge boxes keep drawing fire because they route everything and nobody watches them like a server.
• Citrix NetScaler auth bypass, now weaponized. A critical authentication-bypass flaw is being leveraged in real attacks (BleepingComputer). If you run NetScaler at the perimeter, this is a patch-tonight item.
• Thousands of Redis servers, quietly mining. Hunt.io mapped a cryptomining botnet that compromised 3,562 exposed Redis servers to run XMRig (Hunt.io). Left-open data stores are still one of the cheapest footholds going.

If you want the longer version of why an AI provider is a source of traffic and not a trust level, we laid out our whole taxonomy for it in AI traffic is not a category.

See you next week.

Sources are linked inline; credit to the original researchers and reporters. If we got a detail wrong, tell us and we'll fix it.

About Reputation Radar: This is written by the small team building Reput.io, not a marketing department. It's our weekly read on the infosec landscape, with a bias toward the thing we care most about: how attackers borrow the reputation of legitimate infrastructure so their traffic looks normal. Every item links the original reporting, and any claim about our own API is run against it live and labelled.