The most uncomfortable sentence in Google's July 2026 threat-intelligence post isn't about NetNut at all. It's this: Google said it has high confidence that many popular residential proxy brands are in fact white-labeling the NetNut botnet. Sit with that for a second. The brand on your invoice may not be the operator of the network your traffic runs through.
Disclosure: BestProxyReviews is reader-supported. This page contains affiliate links and compensated placements, and we may earn a commission when you buy through them, at no extra cost to you. See our disclaimer for details.
What Google actually said about white-labeling
On July 2, 2026, Google Threat Intelligence Group published its post on the continued disruption of malicious residential proxy networks, describing coordinated action with the FBI and Lumen against the NetNut residential proxy network, also known as Popa.
The headline numbers were serious enough on their own. At least 2 million devices worldwide, by Google's estimate. In one week of June 2026, 316 distinct threat clusters observed using suspected NetNut exit nodes — cybercriminal and espionage groups included. Botnet plugin components tied to large-scale operations like Badbox 2.0. And this wasn't Google's first swing: the post frames it as a follow-up to January 2026's disruption of the IPIDEA proxy network.
But if you buy proxies for a living, the sentence that should keep you up at night is the supply-chain one: Google said it has high confidence that many popular residential proxy brands are in fact white-labeling the NetNut botnet. Google named no brands. I won't guess at any either, and I'd urge you not to. The point isn't gossip about which logo is dirty. It's structural: in this market, reselling and white-labeling are common enough that brand reputation and network operation are two separate questions — and most vendor reviews only ever ask the first one.
What happened after the post, precisely
Precision matters here, because the sloppy version of this story (“the FBI shut down NetNut”) is not what the sources say. Here's the actual record:
- On July 3, 2026, BleepingComputer reported the coordinated operation involved Google, the FBI, Lumen, Shadowserver and partners, with the FBI seizing netnut.com while Google disabled command-and-control accounts and Play Protect flagged apps carrying NetNut SDKs.
- The same day, The Register noted that netnut.com showed a seizure notice while netnut.io was still operational at publication time.
- Proxyway reported the FBI and IRS seized netnut.com, proxyjet.io, and divinetworks.com, and later updated that netnut.io and alarum.io had also been taken down.
NetNut's parent company didn't stay silent, either. Alarum Technologies (NASDAQ: ALAR) acknowledged the domain seizures on July 2, said it would fully cooperate with law enforcement, and framed the event as third-party misuse of its infrastructure. In a July 3 update, Alarum confirmed additional seizures, said parts of its proxy network were paused, warned of a likely material adverse effect on its business if disruptions persist — and stated that as of that date, neither Alarum nor NetNut had been formally contacted by the FBI or any other authority.
So where does that leave things? A Google-led disruption in coordination with law enforcement. A degraded, partially paused commercial network. Seized domains. A parent company disputing the framing while cooperating. Google's own words: “significant degradation” — not shutdown. I'd keep that same precision in your internal vendor memos, by the way. It's exactly the discipline you're about to demand from your suppliers.
Why white-labeling breaks the usual vendor review
A standard proxy vendor review evaluates the brand — website, pricing, pool size, support quality. A supply-chain audit evaluates the network behind the brand. I used to treat the difference as academic. After July 2026, it isn't, for three reasons:
- Your risk exposure is set by the operator, not the reseller. If the network under your brand is enrolled through hidden SDKs or unclear consent, that's your supply chain now — no matter what the reseller's marketing says.
- Disruption propagates instantly. Google said its actions cut the available device pool by millions. Every brand quietly reselling affected capacity inherited that loss overnight. So did their customers.
- You can't explain what you can't trace. When procurement, legal, or a customer asks how your data was collected, “our vendor's vendor handles that” is not an answer that survives review. I've watched it not survive.
The Alliance for Responsible Data Collection's July 7 statement drew the right line: residential proxy technology is not the problem; irresponsible operation is. Fine — but when the operator hides behind a brand, how do you tell the two apart? That's what this audit is for.
A reseller can still pass this audit
Let me be fair to resellers for a moment, because reselling is not automatically a fail. Opacity is.
- A transparent reseller can still be a viable supplier. It should state which pools are first-party, which are partner-supplied, who operates each layer, and how customer traffic is routed.
- The contract should acknowledge upstream dependencies. If capacity, pricing, or sourcing depends on another network, you should get notice rights, provenance language, and a clear statement of what happens if that upstream is disrupted.
- The weak pattern is brand-only transparency. A polished website, big pool numbers, and generic “ethically sourced” copy answer none of the questions that matter: who controls the endpoints, the consent flow, the enforcement decisions?
So no, this article isn't anti-reseller. It's anti-uninspectable-reseller-risk. A reseller that can fully disclose its operator chain and stand behind it contractually can pass. One that can't has handed you a supply-chain finding, and you should file it as one — not as a difference of marketing opinion.
The supply-chain audit: eight questions with verifiable answers
Send these to every residential proxy vendor in writing. And remember: a vague answer is an answer.
| Audit question | What a strong answer looks like | Red flag |
|---|---|---|
| 1. Do you operate your own peer network, or resell? | A direct statement of which pools are first-party and which are sourced from named partners | “We have multiple premium upstream partners” with no names or terms |
| 2. Which apps or SDKs supply your residential IPs? | A published sourcing policy with example supply apps and SDK documentation | Sourcing described only as “ethically sourced” with no inspectable detail |
| 3. How do device owners opt in and out? | Visible consent screens, value exchange, and a working opt-out path | No user-facing surface you can actually look at |
| 4. What did you do the last time a supply partner failed your standards? | A documented enforcement example, even at revenue cost | No enforcement history at all — policies with no casualties are usually decorative |
| 5. What happens to my capacity if an upstream network is disrupted? | A continuity answer: pool diversification, failover, contractual notice | “That won't happen to us” |
| 6. Will you warrant IP provenance in the contract? | Written provenance and consent warranties, plus audit or termination rights | Refusal to put sourcing language into the agreement |
| 7. Who reviews your controls externally? | Current certifications and independent assurance reports procurement can read | Self-declared compliance only |
| 8. What gets blocked before KYC? | Concrete pre-KYC restrictions and named risky-use gating | Full anonymous access to everything on day one |
Treat the table as a gate, not a conversation starter. Evasive answers on questions 1, 2, 3, 6, or 8? I'd pause the vendor review right there. And if you need a broader screen before going this deep, start with the proxy compliance checklist hub.
Question 4 is the one I lean on hardest. The industry conversation about ethical sourcing — including a June 2026 TNW partner-content piece (disclosed as written outside TNW's newsroom, so weigh it accordingly) — keeps converging on the same gold standard: the device owner knows, consents, and gets something in return. That piece also names BADBOX, Aisuru, and ASOCKS as examples of what the unethical version looks like at millions-of-devices scale. Here's the thing though: every vendor now claims the ethical version. Every single one. Enforcement history is how you find out whether the claim has ever cost them anything.
What to request in the first supplier email
Don't save the evidence request for the third call. Put it in the first email:
- A sourcing policy or supply-chain diagram that distinguishes first-party pools from partner-supplied or reseller-supplied capacity.
- A sample consent surface — screenshots, video, or documentation showing user notice, opt-in, value exchange, and opt-out.
- A current assurance packet with the certifications or assurance reports the vendor expects procurement to rely on.
- Sample contract language covering IP provenance, sourcing changes, audit rights, and disruption notice obligations.
- A continuity answer describing what happens to your capacity if an upstream network, SDK source, or partner pool is suspended.
The point isn't to bury anyone in paperwork. It's to force the move from adjectives to artifacts. In my experience, serious suppliers produce some version of this fast — sometimes same-day. Weak suppliers try to keep the whole conversation at the slogan level, and the stalling itself is your data point.
What a documented enforcement example looks like
Bright Data is currently the most useful reference point here, for one concrete reason: it has actually published one. In a first-party post, Bright Data has said it terminated two SDK partner app developers that together provided over 10% of its residential peer network — one for refusing to sign its app with a verified digital signature, the other for refusing to drop an ad network that sometimes led users to unverified websites. And, per the same post, the terminations hurt Bright Data's own revenue. They did it anyway.
Now, the post is Bright Data's own and it's undated, so I file it as an attributed claim, not an audited fact. But look at the shape of the claim. It names the control (digital signatures, a zero-malicious-advertising policy, opt-out at any time). It names the enforcement (termination). It names the price (over 10% of peer supply). That's specific, costly, and checkable in structure — a different species entirely from “we take ethical sourcing seriously.” Bright Data also says its EarnApp consent flow was certified by AppEsteem, with a redesigned consent screen, EV code-signing, and a visible tray icon while the SDK runs. Those are user-facing surfaces you can go inspect yourself, which is literally what audit question 3 asks for.
Stack that alongside Bright Data's Trust Center (KYC, abuse prevention, usage monitoring, plus certification signals including ISO 27001:2022, ISO 27018, SOC 2 and SOC 3) and its PwC ISAE 3000 assurance page, and you get the contrast this whole article is really about. Not “Bright Data is safe and everyone else is dangerous” — I'm not saying that. It's “this is what reviewable supply-chain evidence looks like; now hold every vendor on your shortlist to it.”
Read our full Bright Data review for the broader buyer view, or start with the residential proxy buying guide if you're earlier in the process.
A simple pass/fail scorecard for procurement
No vendor-risk platform required. A red-yellow-green scorecard on a single page does the job:
- Red: the vendor won't name its operator model, won't show consent surfaces, or refuses provenance language in the contract.
- Yellow: the vendor answers the questions but can't yet produce external assurance, disruption planning, or a concrete enforcement example.
- Green: the vendor can map its supply chain, show consent and opt-out evidence, explain pre-KYC restrictions, and hand procurement reviewable artifacts.
One rule I'd hold firm on: red on questions 1, 2, 3, 6, or 8 can't be bought back with a lower price, a bigger pool, or a charming sales engineer. Those are hard gates because they decide whether the network can be explained at all. Everything else is negotiation; those five aren't.
How to run the audit in practice
You don't need a security team for this. A procurement owner with a checklist can finish it inside a week:
- Send the eight questions in writing and require written answers. Sales-call reassurances are not evidence.
- Inspect the user-facing surfaces yourself. Find the supply app or SDK consent screen. Can't find any user-facing surface at all? That's a finding — write it down.
- Read the assurance artifacts, not just the badges. A certification logo on a homepage is not the same as a current report someone on your team has actually opened.
- Put provenance in the contract. Consent-based sourcing warranties, disruption notice obligations, and exit rights if the supply chain changes.
- Re-run the audit annually and after any enforcement event. July 2026 was the second network disruption this year, after IPIDEA in January. This is a recurring risk category now, not a one-off news story.
What not to conclude
Don't conclude that residential proxies are finished — that's not what Google said, and it's not ARDC's position either. Don't conclude that any specific brand is a NetNut white-label; Google named none, and guessing creates legal risk for you, not just for them. And please don't conclude that a big brand is automatically a safe brand. If the white-label warning teaches anything, it's that brand size and network hygiene are independent variables. You have to check both.
Final verdict
The NetNut disruption turned an inconvenient truth into a procurement requirement: knowing who actually operates the network behind your proxy brand is now your job. Run the eight questions, demand written answers, request the evidence packet in the first email, inspect the consent surfaces, put provenance in the contract. Vendors with real first-party supply chains and reviewable evidence will pass quickly — they've done this dance before. Vendors reselling capacity they can't explain will go vague at question 1 or quietly vanish at the evidence-request stage. Either way, you'll know in a week, and that's the cheapest possible time to find out.
For the event background, read our NetNut disruption compliance breakdown. For the broader vendor-ethics framework, use the web scraping ethics checklist and the proxy compliance checklist hub.
