A residential proxy botnet is a proxy network whose exit addresses come from devices whose owners never meaningfully agreed to carry anyone else's traffic: machines infected with malware, routers and connected devices taken over through default credentials, and apps or installers that enrolled users without informed consent. For the buyer, the risk is concrete. Your requests left the internet from those devices, so when the network is exposed, you inherit the disclosure questions, the contractual exposure and the damaged IP reputation that come with it.
This article explains how that supply works in general terms, why the exposure lands on the customer, which signals in a vendor should prompt harder questions, and what to do if you suspect the network you already use.
How compromised-device supply enters a proxy network
Every residential proxy network needs the same raw material: a large number of consumer internet connections willing to relay traffic. A legitimate network obtains it by asking people, telling them what will happen, and paying them. A residential proxy botnet obtains it by skipping the asking. The routes fall into three broad groups.
Malware on end-user devices
Some supply comes from computers and phones infected with software the owner never chose to install. The infection turns the device into a relay that forwards traffic on instruction. The owner sees, at most, a slower connection. They have not been told, have not been paid, and cannot switch it off because they do not know it is there.
Routers and connected devices on default credentials
Home routers, cameras, set-top boxes and similar devices are often left on factory credentials or unpatched firmware. Devices in that state can be taken over at scale and made to relay traffic. They are attractive to operators because they are always on, sit on residential ISP address space, and are rarely inspected by their owners.
SDKs and installers without informed consent
The third route is less obviously criminal and more common. A software development kit that shares bandwidth is embedded in a free app or bundled into an installer, and the "consent" is a clause in a license agreement the user scrolled past. Bandwidth-sharing SDKs are not inherently illegitimate; consented SDK partnerships are a normal acquisition channel. What separates the two is whether the person using the device saw a plain disclosure, took an affirmative step to accept it, received something in return, and can reverse it from inside the app.
Supply from all three routes is frequently laundered through intermediaries. A network may buy capacity from a broker, who aggregates it from other sources, so the vendor you contract with may not know, or may choose not to know, where its addresses originated. That is why "we do not operate botnets" is a much weaker statement than "we can trace every address to a named, consented channel".
Why the buyer inherits the exposure
It is tempting to treat sourcing as the vendor's problem. The mechanics of a residential proxy botnet say otherwise.
Your traffic rode the botnet
Every request you sent through a compromised exit was carried by a victim's device and connection. The target site recorded the victim's address alongside your request. The device's controller, not your vendor, sat on the path, which means anything not protected by end-to-end encryption could have been observed or altered by a party you have no contract with. If your workloads carried authenticated sessions, API keys in headers, or customer data, that is a confidentiality question for your security team, not only a procurement one.
Disclosure events arrive without warning
In July 2026, a top-tier residential provider was seized by federal authorities after its network was found to be built on compromised devices. Its customers learned about it the way everyone else did: the service stopped and the reason was public. When that happens, the provider's records, including customer accounts, billing details and usage, may become part of an investigation. Being named in, or asked about, that material is a disclosure event you did not schedule, and one your legal and communications teams will want to have planned for.
Regulators, auditors and security reviewers ask what you checked
Vendor management controls in most security and privacy frameworks expect you to assess suppliers in proportion to the risk they carry. After a public seizure, the question from an auditor, a regulator, or your own board is simple: what did you do to establish where these addresses came from? "The vendor's website said ethically sourced" is not an answer that survives the follow-up.
Contractual and reputational exposure
If you sell data, insights or monitoring services, your own contracts may warrant that data was collected lawfully, or bind you to a supplier code of conduct. A collection pipeline that ran on hijacked routers can put those warranties in question and give a customer grounds to reopen terms. The reputational version is shorter and worse: a headline that connects your company's name to compromised consumer devices.
IP reputation contamination
Compromised devices rarely do only one job. The same addresses that relayed your requests may also have carried credential stuffing, spam or fraud for other customers of the same operator. Those addresses end up on blocklists and in threat-intelligence feeds, so your success rates fall, and at the target your traffic is indistinguishable from the abuse that shared the address. If you allowlisted exit ranges with partners, you may have allowlisted part of someone else's attack infrastructure.
Warning signs in a vendor
None of these proves a network is a residential proxy botnet. Each is a reason to ask for evidence before you buy, or before you renew.
| Signal | Why it matters | What to ask for |
|---|---|---|
| Implausible pool growth | Consented supply grows at the pace partners can recruit and pay peers. A pool that doubles in weeks suggests supply that was not recruited. | Pool size over time, with the acquisition channels that account for the growth |
| Price below plausible consent-compensated cost | Peers who consent are paid, partners are paid, and the network must be operated. A price under that floor needs an explanation. | How peers are compensated, and by whom |
| No named acquisition channels | A vendor that sources responsibly can say exactly how an address enters its network. Vagueness here is a choice. | The written supply-chain policy, listing permitted and prohibited channels |
| No independent audit | Self-assessment cannot be falsified by the buyer. An independent assessor who samples addresses can. | The most recent attestation, its date, its scope and the exceptions it found |
| Refusal to trace a sample | This is the decisive test. A provider with records can trace an address you choose; one without them cannot. | A chain-of-custody record for an address from your own trial traffic |
| Supply bought from brokers or other networks | Each resale step removes visibility of the original acquisition. | Whether any supply is purchased, and from whom |
Two further signals come from your own traffic rather than the vendor's answers: an unusually high share of exit addresses already listed on threat feeds, and exit devices whose apparent type does not match the channel the vendor claims. Neither is conclusive, and both are worth a written question.
How to test a vendor before you buy
A structured evaluation takes a few days and produces the file you will want if anyone asks later. Verifying a proxy provider's IP sourcing covers the method in detail; the short version is:
- Request the supply-chain policy in writing, and confirm it names both permitted and prohibited channels.
- Request the latest independent sourcing attestation, including the exceptions list, under NDA if necessary.
- Run a trial, log the exit addresses you actually received, and choose several at random.
- Ask the vendor to trace each chosen address to its acquisition record, partner, disclosure and consent timestamp.
- Compare the channel in each record against the written policy, and note any address the vendor could not trace.
- Store the policy version, the attestation reference and the trace results with the purchase decision.
The broader proxy provider due diligence checklist places these steps alongside security, contractual and data protection checks, and the proxy vendor security questionnaire gives you the questions in a form you can send.
What to do if you suspect your current provider
Suspicion is not proof, and a hurried response can create its own problems. A measured sequence:
- Separate sensitive workloads first. Move anything that carries credentials, authenticated sessions or customer data to a provider you have evidence for, or pause it.
- Preserve your records. Keep the contract, invoices, account configuration, usage exports, correspondence and your own logs of exit addresses. If the provider disappears, these are what you will have.
- Ask in writing, with a deadline. Request the supply-chain policy, the latest attestation and a trace for a sample of addresses you have logged. A provider with good records can answer within days.
- Involve legal, security and procurement together. Check whether your own contracts oblige you to notify customers of a supplier concern, and agree who speaks externally.
- Stand up an alternative in parallel. Run a second provider on a share of traffic so that you can move quickly if the answers are poor or service stops. The proxy provider shutdown playbook covers this scenario in full.
- Leave investigation to the authorities. If you hold concrete evidence of criminal activity, report it through counsel. Do not attempt to probe or access the exit devices yourself; they belong to victims.
- Record the decision and the reasons. Whether you stay or leave, the written rationale is what demonstrates diligence later.
How ProxyForge handles botnet risk
ProxyForge's supply-chain policy is public and versioned. It permits consented SDK partners, direct ISP leases, registered ranges we announce ourselves and modems we operate, and it prohibits malware, bundled installers without knowing consent, compromised devices and routers, botnets, brokers who cannot evidence acquisition, supply resold from other networks, and minors' devices. An independent assessor audits our sourcing twice a year by sampling addresses and tracing each one to its acquisition record, and the attestation is available under NDA.
If you are evaluating us, or moving away from a network you no longer trust, send an address from your trial traffic and we will return its chain-of-custody record. The sourcing page sets out the policy and document register, and the migration process lets you run both providers in parallel before you shift anything.