Residential Proxy Due Diligence: Is Your Provider's Pool a Botnet?

You can't prove a residential proxy pool is clean from the outside. What you can do is make a provider show you where its IPs come from, test a sample of exit IPs against public threat intelligence, and read the contract for who carries the risk. This residential proxy due diligence checklist is built from what investigators found inside IPIDEA (disrupted in January 2026) and NetNut, which was seized in July 2026 and linked to the "Popa" botnet. If a provider can't get through most of it, assume some of its supply is not consensual.

This piece complements three we've already published: what happened in the NetNut seizure, why consent matters after the Popa botnet, and the mechanics of how proxy pools are built. Those cover the why. This one is the worksheet you take into a vendor call.

Why residential proxy due diligence changed in 2026

Two takedowns showed that "residential" and "botnet" can be the same infrastructure sold under a normal brand, and that the buyer is the one left with the outage. A pool could look perfectly legitimate on the front end and still be built on devices whose owners never agreed to anything.

IPIDEA, January 2026

Google Threat Intelligence Group (GTIG) described IPIDEA as one of the largest residential proxy networks. GTIG tied four SDKs (Castar, Earn, Hex and Packet SDK) and 13 proxy and VPN brands to the same operators, found more than 600 Android apps and 3,075 Windows binaries carrying the code, and saw over 550 threat groups using IPIDEA exit nodes in a single seven-day period. Working with Spur, Lumen's Black Lotus Labs and Cloudflare, Google says the disruption cut the pool by millions of devices (The Register's write-up has the background).

NetNut / Popa, July 2026

On July 2, 2026, visitors to NetNut domains saw a seizure notice from the FBI and IRS Criminal Investigation (KrebsOnSecurity). NetNut is run by Nasdaq-listed Alarum Technologies. In its follow-up post, GTIG estimated the network, also tracked as Popa, at no fewer than 2 million devices, many of them smart TVs and streaming boxes. It observed 316 distinct threat clusters using suspected NetNut exit nodes in one week of June 2026, and said it had "high confidence" that many popular residential proxy brands were white-labelling the NetNut network. Alarum told investors on July 3 that it was "experiencing disruptions to a portion of its services". It also said that neither it nor NetNut had been formally contacted by any authority. Earlier, in a statement quoted in Krebs's June reporting, Alarum had rejected the description of its SDKs as a "botnet".

Krebs's June investigation describes how the devices were enrolled. Popa is a plugin component associated with the Vo1d malware family on unofficial Android TV boxes. The boxes ship with, or quickly install, software that turns them into proxy nodes. Popa domains were found in pirated-streaming apps, and Spur measured proxy SDKs in more than 42% of apps on LG's webOS and more than a quarter of Samsung Tizen apps.

Where residential IPs actually come from

A residential IP is supplied by one of four channels, and only the first two can be consensual. Most large pools blend several, and they often buy capacity from each other too, so "our pool" may really be a mix of upstreams.

The economics push the whole market toward the bottom row. Buyers pay per gigabyte and want lots of countries, high uptime and low prices. Supply that's always on and costs nothing per device wins on all three. A TV box plugged in around the clock is a better exit node than a phone that sleeps. A Cloud Security Alliance research note (August 2026) describes Android TV boxes that switch between proxy work and ad fraud. It also warns that consent mechanisms look technically identical whether the operator is legitimate or criminal. GTIG adds that when one operator's botnet shrinks, it buys capacity from competitors. That's why your supplier's sourcing story only matters if it covers its upstreams as well.

Why it is the buyer's problem

You carry four risks if your provider's pool is a botnet. Your traffic is mixed in with criminal traffic, your service can vanish overnight, the IPs you pay for are already burned, and you may have to explain the vendor to a regulator or auditor.

• Legal exposure. Routing traffic through devices whose owners didn't consent is a problem for the operator first. But you're the one paying for that access, and your requests are what come out of a stranger's living room. How much exposure that creates depends on your jurisdiction and contract. Your lawyers will want to know you asked.
• Sudden pool collapse. A seizure takes down domains, dashboards and gateways at once. NetNut's customers, and the customers of brands reselling it, found that out on July 2. If one provider handles all your proxy traffic, you have a single point of failure.
• Pre-burned IPs. When hundreds of threat groups share the exits you use for price monitoring, defenders block those IPs and ASNs for reasons that have nothing to do with you. That shows up as worse success rates and more challenges. You can't fix it by tuning your scraper.
• Compliance and reputation. The CSA note recommends that organisations factor residential-proxy exposure into vendor risk assessments and treat undisclosed proxy functionality "as a material finding rather than a boilerplate EULA disclosure".

The checklist: 12 questions, good answers and red flags

GTIG's own recommendation after IPIDEA was that providers claiming ethical sourcing should offer "transparent, auditable proof of user consent". This checklist turns that into specific requests. Ask every question in writing and keep the answers. A good provider answers most of these quickly. Evasion on the first three is enough to walk away. These are the questions to ask of any vendor, including us.

1. What share of the pool comes from each sourcing channel?

• Ask: a percentage breakdown across SDK, bandwidth-sharing app, ISP/hosting partnership and resold third-party capacity.
• Good answer: rough numbers per channel, plus what they do and don't control.
• Red flag: "100% ethically sourced" with no breakdown, or a refusal because sourcing is "proprietary".

2. Which apps or SDK partners supply the nodes, and can I see the consent flow?

• Ask: the names of the SDK, at least a few host apps, and screenshots or a test build showing the consent screen as a user sees it.
• Good answer: a named SDK with a public page, a separate opt-in screen (not just a EULA line), a plain-language explanation that other companies' traffic will use the connection, and an in-app way to turn it off.
• Red flag: unnamed partners. Also any SDK name that appears in published threat research: check GTIG's IPIDEA list (Castar, Earn, Hex, Packet SDK) and the app names in the Krebs Popa reporting.

3. Do you resell anyone else's pool?

• Ask: whether any capacity comes from upstream providers, which ones, and whether you'll be told if that changes.
• Good answer: yes or no. If yes, the upstreams are named and covered by the same sourcing warranties.
• Red flag: evasion. GTIG said it had high confidence that many popular brands were white-labelling NetNut. Their customers didn't know whose IPs they were really using until the seizure.

4. Is the pool size claim plausible?

• Ask: how "pool size" is counted (unique IPs over 30 days, or concurrently online devices) and how many are online per country right now.
• Good answer: a defined metric that separates monthly unique IPs from devices online now. Dynamic ISP addressing inflates unique-IP counts, and an honest vendor will say so.
• Red flag: headline numbers in the tens of millions with no definition, from a vendor whose named SDK partners couldn't plausibly have that many installs. For scale: Lumen measured Popa alone at 1.5–2.5 million distinct IPs per day.

5. What kinds of devices are the nodes?

• Ask: the device-type split (phones, desktops, smart TVs, set-top boxes) and Android TV share in particular.
• Good answer: a split that matches the stated channels. A phone-app SDK should produce mostly phones.
• Red flag: a large share of TV boxes or streaming sticks, or a vendor that doesn't know. Uncertified Android TV boxes are the common thread in Vo1d, BadBox 2.0 and Popa.

6. Does the geography look like real users or like infected hardware?

• Ask: online-node counts by country. Then compare them with what you see in your own exit sample.
• Good answer: a distribution roughly in line with where the partner apps are popular.
• Red flag: heavy over-representation of the markets where infected boxes cluster. XLab put Vo1d's infections at about 25% Brazil, 13.6% South Africa and 10.5% Indonesia. HUMAN's BADBOX 2.0 research, as reported, put 37.6% in Brazil. Those countries have plenty of legitimate users. What you're looking for is disproportion, not presence.

7. Do sample exit IPs show up in threat intelligence?

• Ask: nothing. Test it yourself (procedure below).
• Good answer: some reports are normal on shared residential IPs. Most of the sample should be unreported, and very few should show scanning behaviour.
• Red flag: a meaningful share of exits seen scanning the internet, listed on Spamhaus's exploits list, or tagged by IP-intelligence vendors under another proxy brand's name.

8. What KYC do you run on buyers?

• Ask: what verification happens before a new account gets residential traffic, and what triggers a review.
• Good answer: identity or business verification proportionate to the risk, plus questions about your use case. Mildly annoying is a good sign.
• Red flag: pay in crypto, get credentials instantly, no questions. Whoever can sign up anonymously shares your exits with you.

9. How do you handle abuse reports?

• Ask: a published abuse contact, a typical response time, and what happens to a customer whose traffic draws a complaint.
• Good answer: a named process, blocks on high-risk targets, and evidence that accounts actually get suspended.
• Red flag: no abuse address, or "we don't log anything, so we can't act". That might sell well, but it means nobody can enforce anything.

10. Is there a published acceptable-use policy, and is it enforced technically?

• Ask: the AUP URL and which parts are enforced in the gateway (blocked domains or ports, rate limits on login endpoints) rather than only on paper.
• Good answer: a public AUP that bans credential stuffing, fraud and spam, backed by technical controls they'll describe.
• Red flag: marketing that hints at uses the AUP bans, such as "undetectable" account farming.

11. What does the contract promise?

• Ask: for a warranty that nodes are sourced with the device owner's informed consent, an indemnity if that turns out to be false, notice of material sourcing or upstream changes, and data-processing terms.
• Good answer: the clauses exist, or the vendor will negotiate them at your volume.
• Red flag: terms that put all sourcing risk on you, or that let the vendor change suppliers silently.

12. Which independent memberships or audits do you hold, and what do they actually cover?

• Ask: for the certificate or membership, and its scope.
• Good answer: an accurate description of scope. The industry-specific badge is the Ethical Web Data Collection Initiative (EWDCI), an industry consortium run under the i2Coalition. Members pledge to its principles. It's a code of conduct, not a technical audit of each node's consent, and NetNut was listed as a member from April 2024. General certifications such as SOC 2 or ISO 27001 cover the company's security controls, not where its IPs come from.
• Red flag: treating a badge as the answer to questions 1–3. A badge is no substitute for evidence.

How to test a sample of exit IPs yourself

Pull 100–200 exit IPs from the provider's trial, then run them through two or three free reputation sources. You're looking at the distribution across the whole sample. A single bad IP proves nothing on its own.

First, collect exits. Most gateways rotate per request or per session. With any provider that supports sticky sessions, request a new session ID each time. On our gateway the session goes in the username:

for i in $(seq 1 150); do
  curl -s --max-time 20 \
    -x "http://USERNAME-sid-audit$i-ttl-10m:PASSWORD@gate.proxyhat.com:8080" \
    https://api.ipify.org
  echo
done | sort -u > exits.txt
wc -l exits.txt

If you just want to confirm that a proxy is reachable and see its exit IP, our free proxy checker will test one for you. Then check reputation:

• AbuseIPDB. Crowd-sourced abuse reports. The free plan allows 1,000 checks a day. The check endpoint returns abuseConfidenceScore, totalReports and usageType.
• Spamhaus. The IP and Domain Reputation Checker is free for low-volume manual use. An XBL listing (exploited hosts, open proxies, infected machines) is the signal you care about. A PBL listing just means "end-user range that shouldn't send mail directly", which is normal for a real home IP. Don't script DNSBL queries through a public resolver: Spamhaus answers those with the error code 127.255.255.254, not data.
• GreyNoise. The Community API (https://api.greynoise.io/v3/community/{ip}) tells you whether an IP was seen scanning the internet in the last 90 days (noise) and how it's classified. It allows 10 lookups a day without a key, or 50 a week with a free account on a business email. A residential exit that mass-scans is either infected or rented by someone who scans.
• Proxy-attribution vendors. Spur (credited in the IPIDEA disruption) and IPinfo's residential proxy API (service, last_seen, percent_days_seen; paid tiers) name the proxy service an IP has been seen in. If your vendor's exits are tagged with a different brand, that's direct evidence of reselling. Attribution can be wrong, though, and one device can sit in several pools.

while read ip; do
  curl -sG https://api.abuseipdb.com/api/v2/check \
    --data-urlencode "ipAddress=$ip" -d maxAgeInDays=90 \
    -H "Key: $ABUSEIPDB_KEY" -H "Accept: application/json" |
  jq -r '[.data.ipAddress, .data.abuseConfidenceScore, .data.totalReports, .data.usageType] | @tsv'
done < exits.txt > abuseipdb.tsv

To read the results, compare two candidate providers' samples side by side rather than against an absolute threshold. Carrier-grade NAT means one mobile IP can carry reports from thousands of unrelated users. For the networks behind each IP and why some read as hosting, see our guide to IP reputation and fraud scoring.

What this test does not prove: a clean sample doesn't prove consent. A freshly infected TV box has no abuse history. A dirty sample may only mean the pool is shared with careless customers. The test catches pools that are already burned. It can't certify sourcing. Only questions 1–3, backed by contract terms, get close to that.

What to do if your provider is taken down

Assume it can happen, and design so that switching providers is a config change, not a rewrite. A seizure gives you no notice. The gateway, the dashboard and often the vendor's support channels go dark at the same moment.

1. Keep the proxy endpoint out of your code. Route every request through one config value or a small proxy middleware layer, so a change of provider is one deploy.
2. Pre-qualify a second provider with this checklist, and keep a small active balance so the credentials still work when you need them.
3. Stop sending traffic to seized domains. Once a domain carries a seizure notice, it's out of the operator's control. Remove stored credentials and don't keep retrying.
4. Write down what you used and when (account, dates, use case), in case questions come later from your own compliance team or anyone else.
5. Re-run the exit sample on the replacement before moving production traffic. White-label brands sometimes share an upstream, and you don't want to migrate onto the same pool under a new name.