A request arrives at your login page from a normal Australian broadband connection. The IP belongs to a consumer ISP. The location is plausible. It is not on a data centre list or a public proxy feed.
What the request does not tell you is who controls it.
The connection may belong to a real customer. It may also be the exit point for somebody on the other side of the world who bought access to it by the gigabyte. The device supplying that access could be running a bandwidth-sharing app, carrying a monetisation SDK inside an unrelated utility, compromised by malware, or sold with unwanted software already installed.
That supply chain is why residential proxy traffic is difficult to handle. The IP address is real. The trust attached to it is not.
Bandwidth Sharing Turns Connectivity Into Inventory
Bandwidth-sharing software lets a third party route traffic through someone else's internet connection. At the destination, the traffic leaves through the participant's residential or mobile IP address rather than the operator's original network.
The commercial pitch is usually simple: share unused bandwidth and earn a little money, or let an app developer earn revenue without showing more advertising. There are legitimate and clearly disclosed versions of that arrangement. The problem is that the same machinery also works when the disclosure is vague, the SDK is hidden inside an unrelated app, or the device owner never agreed at all.
Once enrolled, the device becomes supply. A proxy provider or reseller can package that supply by country, city, ISP, session duration, or available capacity. A buyer does not need to know whether the exit came from an informed participant, an obscure clause in an app's terms, or a compromised device. They pay for the route.
For the website receiving the request, those sourcing distinctions are mostly invisible. It sees a consumer IP address and has to decide whether the request belongs to a customer.
There Is More Than One Way Into the Pool
Residential proxy networks are not built from a single source. Their capacity can come from several different arrangements:
- Explicit bandwidth-sharing apps. The user installs software whose stated purpose is to sell or share some of their connection.
- Monetisation SDKs. A developer embeds third-party code in a game, utility, browser extension, VPN, or desktop application and is paid for active devices or transferred data.
- Trojanised applications. A useful-looking app performs its advertised function while quietly enrolling the device as a proxy exit.
- Preloaded or setup-time software. Cheap streaming boxes and other connected devices can arrive compromised or download a backdoor when first configured.
- Post-compromise installation. An attacker exploits a server or endpoint, then installs otherwise legitimate bandwidth-monetisation software to generate recurring income.
These paths sit on a spectrum from deliberate participation to outright compromise. They produce a similar result for the destination service: third-party traffic exits through an address that looks residential.
The Quiet Payload Is Often the Point
The most revealing development is not a new proxy protocol. It is the use of legitimate proxyware as a payload.
In 2025, Palo Alto Networks Unit 42 documented a campaign that exploited vulnerable GeoServer instances and deployed a legitimate passive-income app and SDK. The SDK used by the attacker was identical to the vendor's official version. Instead of encrypting files or consuming enough CPU to announce itself like a cryptominer, the software quietly monetised the victim's bandwidth.
That changes the economics of a compromise. The attacker does not need to sell access once or deploy noisy malware immediately. A compromised machine can produce a smaller recurring return while its connection is resold. Legitimate code also gives endpoint security a harder judgement to make: the binary may be real, while the installation and use are unauthorised.
This is not only a server problem. In 2025, the FBI warned about BADBOX 2.0, which affected Android-based TV boxes, projectors, digital picture frames, aftermarket vehicle systems, and other connected devices. Some were compromised before purchase; others downloaded backdoored applications during setup. Once connected to a home network, those devices could become part of botnet and residential proxy activity.
An inexpensive box under a television is attractive infrastructure. It stays powered on, sits behind a real household connection, and rarely receives the scrutiny given to a laptop or phone.
2026 Made the Scale Harder to Dismiss
In January 2026, Google said it had disrupted the IPIDEA residential proxy network through legal action, platform enforcement, and industry coordination.
Google's investigation found more than 600 Android applications across multiple download sources connecting to the network's command infrastructure. It also identified 3,075 Windows binaries and described millions of devices being removed from the available proxy pool. During one seven-day period, Google observed more than 550 tracked threat groups using IPIDEA exit nodes to obscure activity including password spraying and access to SaaS and on-premises systems.
Those numbers matter, but the structure matters more. Google found different SDK brands feeding shared infrastructure, along with overlaps between proxy exit pools created by reseller and partnership arrangements. A provider name is therefore not a reliable boundary. The device supplying an exit, the company marketing the SDK, the reseller selling access, and the operator using the connection may all be different parties.
Taking down one set of domains can disrupt a network. It does not remove the incentive to rebuild the supply somewhere else.
Consent Is Not a Security Verdict
Proxy providers often frame sourcing as a consent question: did the device user agree to share bandwidth? That is important, but it is not enough.
There are at least three separate parties whose interests matter:
- The device user, who should understand that strangers can send traffic through their device and IP address.
- The network owner or ISP, whose service terms and security controls may not allow resale or third-party routing.
- The destination service, which never agreed to treat paid proxy traffic as a normal local customer.
A tick buried in a long terms-of-service document is weak evidence that the first party understood the arrangement. It says nothing about the other two. Even genuinely informed consent only explains how an exit joined the pool. It does not make the buyer's login attempt, checkout request, scrape, or password reset benign.
Google Play has drawn this boundary since August 2019, when it added proxy services as an example under its Device and Network Abuse policy. Apps may facilitate proxy services to third parties only when proxying is their primary, user-facing core purpose. Consent does not turn a hidden proxy SDK inside an unrelated game or utility into the app's core purpose.
The rule is not new, and it did not eliminate SDK-sourced proxy capacity. More recent Android controls make persistent background activity easier to scrutinise, while operations such as Google's 2026 IPIDEA disruption show what stronger enforcement can remove from a pool. Platform action can reduce supply. It still cannot establish the intent behind every request that has already reached a website.
Google's later NetNut action made the same limitation easier to measure. Our comparison of the IPIDEA and NetNut residential proxy takedowns follows what happened to the infrastructure, the suppliers and the destination risk.
Why IP Reputation Arrives Late
An IP reputation database can identify known proxy exits. It cannot reliably answer who is controlling a connection right now.
Residential pools change quickly as phones move between networks, apps open and close, devices reconnect, and operators shift infrastructure. One public IP can also represent many unrelated people behind carrier-grade NAT. A clean label may mean the exit is new. A bad label may describe one abusive session while legitimate users share the same address.
This creates two predictable errors:
- Trusting a residential address because it is absent from a proxy list.
- Blocking an address so broadly that ordinary users sharing the connection are caught with it.
The answer is not to discard IP intelligence. It is to stop treating it as identity.
Detect the Relay, Then Judge the Request
The sourcing story explains why a request may be suspicious. It does not decide what your application should do.
Useful detection combines several kinds of evidence:
- Per-connection network and protocol fingerprints that can reveal a relay even when the IP looks ordinary.
- Browser, device, TLS, and HTTP characteristics that do not agree with one another.
- Repeated behaviour that survives IP rotation, such as credential testing across many accounts or identical request timing.
- Route and account context, including whether the request is browsing a public page, attempting login, resetting a password, changing payment details, or calling an API directly.
- Recent outcomes such as failed authentication, challenge failure, unusual token use, or high-risk account changes.
This is where residential proxy detection belongs: inside the request decision, beside IP intelligence, fingerprints, behaviour, credentials, and account state.
A proxy signal on a public article may only be worth recording. The same signal on a login attempt with a first-seen client and failures across several accounts may justify a challenge or tighter rate limit. On a password reset or payment change, it may support step-up authentication or a block.
The action should follow the evidence and the cost of being wrong.
What Security Teams Should Change
For application and fraud teams, the practical response is straightforward:
- Map the sensitive web and API routes where proxy use should change a decision.
- Measure residential proxy traffic before enabling broad enforcement.
- Key rate limits on accounts, tokens, fingerprints, routes, and outcomes as well as IP addresses.
- Keep allow, monitor, rate-limit, challenge, and block as separate actions.
- Preserve a decision record so security, fraud, and support teams can explain why a request was handled differently.
- Review false positives by network type, especially mobile carriers and CGNAT-heavy ISPs.
Endpoint and network teams have a related job. They should inventory bandwidth-sharing and proxy software, review monetisation SDKs, monitor unusual long-lived outbound connections, restrict unapproved software on managed devices, and treat cheap connected hardware as part of the network attack surface rather than as an appliance that can be forgotten after setup.
The Address Is Real. The Assumption Is Not.
Bandwidth sharing has made an old security shortcut less defensible. Residential no longer means local, human, or trustworthy. It describes where traffic leaves the internet connection, not who initiated it or what they intend to do.
Some proxy exits are knowingly shared. Some are poorly disclosed. Some are compromised. A destination service usually cannot see that history, and it should not need to settle the sourcing dispute before protecting an account or API.
Detect the relay where you can. Combine that signal with what the request is doing. Then apply only the friction the evidence supports.
For more background, read How Residential Proxy Networks Are Formed and How Residential Proxies Changed API and Account Abuse.
