A compromised television under a customer's desk is not an endpoint your application team can patch.
It can still send traffic to your login page.
Residential proxy and botnet supply increasingly includes ordinary connected devices: streaming boxes, routers, phones, PCs, projectors, and other hardware that stays online behind a consumer connection. Some owners knowingly share bandwidth. Some accept a vague disclosure inside an app. Others never consent because the device or software was compromised.
The sourcing problem matters to platforms, app stores, vendors, ISPs, and law enforcement. The destination service has a more immediate job. It must decide what the request is allowed to do.
The Exit Looks Like a Customer Network
When third-party traffic leaves through a household device, the destination sees the household's public IP. The address may belong to a well-known Australian ISP. It may have no negative reputation. It may also be shared with legitimate activity from the same home or carrier network.
This is why an IP allow-list, deny-list, or country rule cannot establish who controls the request. The source is real. The relationship between that source and the operator is hidden.
Our earlier article, How Bandwidth Sharing Feeds Residential Proxy Networks, explains the supply chain. The defensive consequence is that trust has to move up from the address to the request, session, route, and behaviour.
Quiet Monetisation Changes the Compromise
In 2025, Palo Alto Networks Unit 42 documented attackers exploiting vulnerable GeoServer instances and deploying a legitimate passive-income application and SDK. The code matched the vendor's official version; the installation and use were unauthorised. Unit 42's proxyware campaign report explains why legitimate binaries can still be part of a compromise.
That payload can be quieter than ransomware or cryptomining. It produces recurring value without making the device's failure obvious. For a destination application, quieter supply means a proxy exit can remain useful for longer.
The FBI's 2025 BADBOX 2.0 alert described Android-based streaming devices, projectors, tablets, digital picture frames, and aftermarket vehicle systems affected before purchase or during setup. The FBI said compromised devices could become part of residential proxy services and botnets used for criminal activity.
These reports do not mean every inexpensive smart device is compromised. They show why household provenance is not a security verdict.
What the Application Can Observe
The destination cannot inspect the television or router. It can observe the work attempted through it:
- route and operation;
- authentication and account state;
- residential proxy and broader IP context;
- TLS, HTTP, and browser fingerprint cohorts;
- device and session history where available;
- request timing and sequence;
- credential exposure;
- failures, retries, and response-code loops;
- application and origin cost.
Several devices may also share the public address. A permanent household ban can punish the subscriber whose device was compromised. Correlate the behaviour using keys that fit the route.
Control the Sensitive Journey
The action should follow what the request can change or consume.
For public cached content, proxy use may need no intervention. For login, count failures across account and client cohorts rather than relying on the exit. For password reset, keep responses consistent and limit repeated recovery attempts. For checkout or account changes, carry the earlier session risk forward and request stronger verification when the consequence rises. For expensive APIs, use identity- and cost-aware budgets.
Peakhour Bot Management combines proxy, fingerprint, route, rate, credential, API, WAAP, DDoS, and behaviour context in the request path. Residential Proxy Detection contributes a live signal for browsers and direct API traffic. The objective is not to identify the appliance. It is to stop relayed traffic from inheriting unconditional trust from the household address.
Platform Enforcement Reduces Supply, Not Every Request
Google Play now requires an app facilitating proxy service to third parties to make proxying its primary, user-facing core purpose. The Google Play proxy-service policy gives the platform a clearer basis for removing unrelated apps that hide proxy functionality.
That policy can reduce deceptive supply. Device takedowns and legal action can disrupt infrastructure. Google's IPIDEA operation combined legal action, platform enforcement, and industry coordination.
Application controls are still required. Existing exits do not disappear at once, private pools remain, and new supply can emerge before datasets identify it.
Preserve Evidence Without Blaming the Customer
When an event is challenged or blocked, record the route, proxy and network evidence, client cohort, account or token context, policy revision, selected action, and outcome. Avoid language that says the household owner attacked the service. The evidence usually supports a narrower statement: traffic reached the application through this connection and matched this behaviour.
That distinction matters for support, fraud review, and incident response. The subscriber may be a victim too.
Application teams cannot repair every compromised box on the internet. They can refuse to let a residential address stand in for identity, intent, or permission.
