Reputation Radar #1: The Week Attackers Rented Trust

Upfront disclosure: This is written by the small team building Reput.io, not a marketing department. We don't have paying customers yet. Reputation Radar is 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.

The theme almost picked itself this week. It wasn't a single big breach. It was a run of stories where the attacker didn't stand up their own suspicious infrastructure at all, they borrowed someone else's good name: a trusted AI service, a clean residential ISP, a familiar installer, a Google or Cloudflare page, a Microsoft login surface, a GitHub agent, a package registry. For a SOC, that's the hard case, because the network layer and the reputation lookups all come back reassuring.

Here's the week through that lens, and then a quick pass on the active-exploit news you'll want on your patch radar regardless.

Trust borrowed from AI and dev platforms

Botnets assembled from the AI tools you already trust. Researchers showed nine of the most popular AI tools can be chained into scalable "agentic" botnets, where the malicious activity rides out through the providers' own legitimate endpoints (Ars Technica). The same week, Sysdig documented what it calls the first fully agentic ransomware, JadePuffer, which used an AI agent to drive an attack end to end (CyberScoop). When outbound traffic goes to a mainstream AI provider's domain, the destination is genuinely legitimate, so the provider's reputation isn't the deciding signal.

A GitHub AI agent tricked into leaking private repos. Attackers got GitHub's AI agent to exfiltrate private repository data, and a related technique used a crafted public GitHub issue to steer agentic workflows into unintended actions (Hackread, The Hacker News). The abused surface is GitHub itself, about as trusted as developer infrastructure gets.

North Korea's PolinRider supply-chain campaign. The Famous Chollima / Lazarus-linked operation expanded to 108 unique repositories, planting malicious packages that ride the reputation of the registries that host them (Socket). This is the classic borrowed-reputation move: registry.npmjs.org is real, so a dependency pulled from it looks routine. Run the registry through our API and it comes back whitelisted but verdict: investigate, not benign, precisely because the platform is trustworthy while the individual package is not:

{ "indicator": "registry.npmjs.org",
  "status": "whitelisted",
  "verdict": "investigate" }

Trust borrowed from clean IPs and residential networks

NetNut: residential proxies get a takedown, but the model isn't going away. The FBI seized the NetNut proxy platform and the associated Popa botnet, cutting off around 2 million infected consumer devices (Krebs on Security). Residential proxies are the sharpest version of borrowed reputation: traffic exits through real home-broadband IPs, so it inherits the clean reputation of an ordinary consumer connection. There's no datacenter ASN to tip you off. What's left to triage is behavior, volume and timing that no real household produces.

Proxyware hiding in fake installers. Infoblox tracked a proxyware operation pushing fake installers, including a bogus 7-Zip, that quietly enrol victims' machines as proxy exit nodes (Infoblox). This is the supply side of the story above: it's how the clean residential IPs in a proxy network get recruited. The reputation being borrowed here is the software's, a familiar tool name is enough to get the install.

Trust borrowed from brands users click without thinking

Fake Google and Cloudflare verification pages. A ClickFix campaign abused Google and Cloudflare verification/check pages to deliver seven different malware families (Hackread). The lure impersonates the two brands a user is most conditioned to trust and click through without thinking. It's worth seeing how the real thing reads in a reputation check, our API returns the genuine Cloudflare Turnstile host as whitelisted but verdict: investigate, not benign:

{ "indicator": "challenges.cloudflare.com",
  "status": "whitelisted",
  "verdict": "investigate" }

That's deliberate. The domain is real Cloudflare, so we won't call it malicious, but "trusted brand" is not a free pass, because those very pages are what this campaign imitates.

81 million login attempts against Microsoft 365. Attackers hammered M365 accounts with roughly 81 million login attempts (BleepingComputer). The identity surface being attacked is first-party Microsoft, login.microsoftonline.com is legitimately benign, so the destination reputation tells you nothing. The signal here is entirely in the pattern: attempt volume, source spread, and impossible-travel, not the address.

Also on the radar

Not everything this week was a reputation story, but a few items belong on any SOC's patch radar:

• CitrixBleed-like NetScaler flaw, exploited in the wild. A memory-disclosure bug in Citrix NetScaler is seeing active exploit attempts (CSO Online, Field Effect).
• SharePoint RCE (CVE-2026-45659) added to CISA KEV. Now confirmed actively exploited, tied to Storm-2603 (BleepingComputer).
• ColdFusion max-severity flaw, CISA patch-by-Friday order. Federal agencies were ordered to patch a maximum-severity Adobe ColdFusion flaw (BleepingComputer).
• FortiBleed credential theft linked to INC and Lynx ransomware deployments (The Hacker News).

The through-line for a SOC

Seven different stories, one triage problem: the attacker's traffic is wearing someone else's reputation. When that happens, "is the destination reputable?" stops being a useful question. The useful questions move down a layer, to behavior and context: does this volume and timing make sense for a home connection, did the user actually intend to grant this consent, is this package really what it claims, is this login pattern plausible.

That's the whole reason we keep CDN, cloud, registries, and other customer-controllable infrastructure at investigate rather than benign, even when the brand is impeccable. If you want the longer version of that argument, we wrote it up in why clearing the known-good first is the right triage order.

See you next week.

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