Peakhour.IO - Residential Proxies

Neither Consent Nor an App-Store Ban Makes a Residential IP Direct

2026-08-03T11:00:00+10:00

LG can remove every residential proxy SDK from its television app store. That may protect households and make one source of proxy capacity harder to operate. It will not make the next residential IP arriving at a login page trustworthy.

The distinction is easy to lose in the argument over smart TV apps. Consent governs how a device joins a proxy network. App-store policy governs one way the software reaches that device. Neither tells a website whether the next request from that household connection originated inside the household.

That is the part security and fraud teams have to operate.

The App Store Had a Real Problem

Spur Intelligence Labs downloaded and inspected 6,038 LG webOS and Samsung Tizen app packages. It found confirmed residential proxy SDK fingerprints in 2,058 of them. More than 42% of the LG apps were affected.

The apps included games, screensavers and utilities. Some presented a choice between advertising and sharing the television's connection. Spur also found consent language saying that proxy activity could continue after the app closed.

LG's response was direct. The company told KrebsOnSecurity that developers must remove the residential proxy option from their webOS apps or have those apps suspended. It also said it would strengthen its evaluation of developer submissions.

That is a reasonable platform control. A television is shared household equipment, not a personal phone that one adult necessarily administers. A one-time prompt does not show that the person holding the remote owns the internet connection, understands persistent background operation or still remembers the decision months later.

Removing the SDK reduces that exposure. It does not turn residential traffic back into direct traffic.

Consent Describes Enrolment

A meaningful consent record can establish something important: an authorised person knowingly allowed a particular device and software version to share resources under a stated set of terms.

That is a higher standard than a buried clause or software installed without the device owner's knowledge. It should include a plain explanation, an affirmative choice, a visible participation state and a withdrawal path that actually removes the device from every pool receiving its capacity.

Even strong consent has a boundary. It does not show who later bought access to the connection. It does not prove that customer vetting worked, that destination restrictions held or that the request now reaching a website is harmless.

There are at least three relationships involved:

The device and network owner decides whether the connection may be shared.
The proxy provider decides which customers and uses it will permit.
The destination decides what a relayed request may do to an account, transaction or API.

Consent speaks to the first relationship. Provider controls speak to the second. Neither can make the third decision on the destination's behalf.

Consent can make the supply relationship consensual. It cannot make every request using that supply legitimate.

An App-Store Ban Describes Distribution

App stores can remove applications, reject updates and block known SDKs. Those actions matter because they can reduce supply, protect device owners and raise the cost of enrolling more endpoints.

The policies are not all the same. Amazon's Device and System Abuse Policy prohibits apps that facilitate proxy services to third parties. Google Play permits proxy services only when proxying is the app's primary, user-facing core purpose. LG has chosen to remove residential proxy functionality from webOS apps.

Each rule governs software distributed through that platform. None covers every route by which a household connection can become a proxy exit. Capacity can also come from software on phones and computers, applications obtained elsewhere, compromised routers, infected streaming devices and pre-installed software. Our investigation into how bandwidth sharing feeds residential proxy networks follows those supply paths separately.

A store can close its door. It cannot certify that an address seen by an unrelated website is no longer available through another device, supplier or reseller.

The Provider Can Disappear While the Addresses Remain

The July 2026 action against NetNut makes this distinction measurable. Google, the FBI and industry partners disrupted accounts, applications and domains associated with the network. Google said the action caused significant degradation and reduced the available device pool by millions.

Layer3 Intel then measured what happened to the observed exit inventory. Its NetNut takedown analysis reported a 99.92% fall in unique NetNut exit IPs observed per hour by 5 July. At the branded network layer, the service had collapsed.

The address layer told a less tidy story. Of the IPv4 addresses observed through NetNut in its final one to two days, 78.81% appeared through other proxy networks during the following 14 days.

That result does not prove that the same televisions, routers or other devices moved between providers. Public IP addresses change, multiple devices can share an address through carrier-grade NAT, and several suppliers or resellers may expose overlapping inventory. Layer3 Intel also estimated, after applying its selected June baseline, that about 1.06 million fewer addresses reappeared than ordinary churn predicted. The takedown had a measurable effect.

The bounded conclusion is still useful: a provider name can almost disappear while much of its recently observed public-address inventory remains visible elsewhere. Our analysis of the measurement sets out what that overlap can and cannot establish.

Provider identity is not a stable security boundary. App-store presence is not one either.

The Destination Sees the Last Step

The website receiving the traffic cannot inspect the television, recover the consent screen or ask which app store approved the software. It sees the end of a longer chain:

device -> public IP -> supplier -> proxy pool -> reseller -> buyer -> destination

Most of that history is hidden at request time. The destination can observe the connection, the client and the work being attempted.

A request from an Australian residential ISP may belong to a customer at home. It may also be a request sent from another country and relayed through that connection. The address locates the exit. It does not authenticate the operator.

Peakhour therefore treats residential proxy detection as evidence inside the request decision. It sits beside credentials, account state, network and client fingerprints, route sensitivity, behaviour and recent outcomes.

The same proxy observation can support different actions:

Opening a public, cached page may require no intervention beyond recording the signal.
Trying one password across many accounts may justify a shared rate limit or block.
Changing a recovery email from a first-seen client may require stronger verification.
Repeating expensive API work across rotating addresses may call for a limit keyed on the credential, client and route rather than the IP alone.

The proxy result changes how much evidence the service requires. It does not select the action by itself.

A Compliant Path Still Has Value

The limits of consent do not make consent unimportant. The limits of app-store enforcement do not make enforcement pointless.

If a platform permits bandwidth-sharing software, it should demand more than a provider's assurance that users opted in. A credible path needs authoritative and recurring consent, a persistent participation indicator, effective withdrawal, buyer and use-case controls, private-network protections, supplier and reseller lineage, incident handling and independently testable records.

Those controls can distinguish accountable supply from hidden or compromised enrolment. They can protect households and make abuse harder. They cannot guarantee that no residential connection will carry a proxy request, and they cannot tell a destination what to do with the request already in flight.

The mistake is expecting one control to answer a question it cannot observe.

Consent answers whether a device was knowingly enrolled. An app-store decision answers whether a distribution channel permits the software. The destination still has to decide whether the request may log in, reset an account, buy limited inventory, scrape an API or consume expensive origin work.

That decision belongs on the request path, using current evidence. A residential address tells us where the request left the network. It does not tell us who initiated it or what they intend to do.

For the operating model, read A Proxy Flag Is Not a Security Policy and A Proxy Takedown Is Not a Security Control.

When a Proxy Network Dies but Its IPs Survive

2026-08-03T08:30:00+10:00

A residential proxy network goes dark. Its domains are seized, its control systems are disrupted and its branded pool almost disappears. Two weeks later, many of the same public IP addresses appear through other proxy services.

Did the takedown fail? Did the same devices move? Were several providers selling the same supply all along?

The honest answer is narrower: the address inventory overlapped across time. That is valuable evidence, but it is not device identity, ownership or motive.

This distinction matters to security and fraud teams deciding what to do with traffic. It also matters to buyers, auditors and researchers trying to establish whether a proxy provider controls the supply chain it describes.

One Address Sits Above Several Relationships

The destination website sees the last layer in a longer chain:

device -> public IP -> SDK or supplier -> proxy pool -> reseller -> buyer -> destination

Each arrow represents a separate relationship.

The device may be a phone, laptop, streaming box, household gateway or server. Software on it, or elsewhere on the same network, sends a buyer's traffic out through a public IP assigned by an ISP or mobile carrier.

An SDK or supplier enrols that capacity. A proxy pool makes it selectable. A reseller may buy the service upstream and sell it under another name. A buyer chooses a location or session through an API. The destination sees a request from the exit address, not this commercial history.

Those layers do not map one-to-one. Several devices can share one public address through a household router or carrier-grade NAT. One device can receive different addresses over time. One supplier can feed several pools. A pool can combine direct supply with upstream inventory. A reseller may not know which device, supplier or SDK produced a particular session.

Our article on how bandwidth sharing feeds residential proxy networks covers the ways capacity enters this chain. The question here is different: what can we infer when a named network disappears but addresses associated with it remain visible elsewhere?

What the NetNut Measurement Found

On 2 July 2026, Google, the FBI, Lumen and other partners took action against the NetNut residential proxy network, also known as Popa. Our comparison of the IPIDEA and NetNut actions separates the controls and public claims involved. Google said it disabled accounts and services used for command and control, shared technical intelligence, and updated Play Protect to disable applications known to contain NetNut SDKs. Google estimated that the network included at least two million devices and said it had high confidence that multiple proxy brands white-labelled NetNut capacity.

Layer3 Intel then published a useful post-event measurement. Its NetNut takedown analysis says the number of unique NetNut exit IPs it observed per hour fell by 99.92% by 5 July. At the brand or gateway layer, that is a decisive decline.

The cross-network result was less absolute. Layer3 Intel took IPv4 addresses it had observed through NetNut in the 30 days before the shutdown and checked whether they appeared through other networks during the following 14 days. Among addresses seen through NetNut in the final one to two days, 78.81% reappeared elsewhere.

The researchers also tried to account for ordinary churn. They applied reappearance rates from a 4 June placebo cutoff to the July cohort. On that basis, they expected about 17.96 million recent addresses to reappear and observed 16.90 million. The difference produced a baseline-adjusted estimate of about 1.06 million IP addresses removed from the wider proxy ecosystem beyond normal churn.

These measurements support three bounded findings:

NetNut's branded, observable exit service collapsed.
Much of the recent public-address inventory associated with NetNut was observable through other proxy networks after the disruption.
Reappearance was lower than the selected June baseline, consistent with a real takedown effect beyond ordinary address churn.

That is already operationally important. A provider name can disappear while some of the address inventory remains commercially reachable.

An IP Match Is Not a Device Match

The same measurement does not prove that the same physical device survived, moved between suppliers or carried two SDKs.

Public addresses are assigned to connections, not permanently engraved on devices. DHCP leases expire. Mobile subscribers move between network gateways. Consumer routers reconnect. Carrier-grade NAT lets many subscribers share public addresses from a provider-controlled pool. RFC 6598 documents shared address space used by service providers for CGNAT, but the ambiguity exists outside that range too: the destination only sees the translated public address.

If 203.0.113.x appears through Network A before a cutoff and Network B afterwards, several explanations fit:

the same device was available through both networks;
different devices behind the same household or carrier address were enrolled;
an ISP reassigned the address to a different subscriber;
a shared upstream supplied both pools;
one provider resold another provider's capacity;
the enumeration system attributed one of the observations incorrectly.

IP overlap increases confidence that address inventory is shared or recycled across the market. It does not identify which explanation is correct for any one address.

It also does not prove supplier ownership. A provider may own infrastructure, contract directly with a supplier, buy capacity through an intermediary, or combine all three. Nor does overlap prove that a device owner did not consent. Consent belongs to a specific person, device, software version, disclosure and time. An IP address contains none of those records.

Most importantly, overlap does not prove motive. It can show that a buyer's request travelled through an observed exit. It cannot establish what the supplier, reseller or provider knew, why a buyer selected the route, or whether the destination request was benign or abusive.

Google's earlier IPIDEA investigation reached beyond address overlap. It analysed applications, Windows binaries, SDK code, command infrastructure and shared server pools, and paired that technical work with platform and legal action. Even then, Google noted that overlaps between exit nodes made definitive quantification and attribution difficult. That is the right standard: use IP observations as one part of a multi-layer attribution, not as a shortcut through the layers.

Read the 1.06 Million Estimate as an Estimate

Layer3 Intel's analysis is stronger than a simple before-and-after count because it recognises ordinary churn and uses an age-matched comparison. Its scale and high-frequency observation also give it a useful view of the market.

The public methodology still leaves material uncertainty:

Enumeration is proprietary. The post describes the volume and timing of observations, but does not publish the complete sampling system, provider coverage, request selection, deduplication rules or validation set. Readers cannot independently reproduce the population from the article alone.
An IP is a noisy unit. Dynamic addressing and CGNAT break a stable link between address, subscriber and device. Counting distinct IPv4 addresses can overstate devices and obscure shared use.
The windows choose what can reappear. The source cohort covers 30 days; the follow-up covers 14. Shorter or longer windows would change both the raw overlap and the churn model.
There is one published placebo cutoff. A single June comparison is useful, but it does not show the normal week-to-week distribution, seasonal effects or whether that period was representative.
No confidence intervals are published. The 1.06 million figure is presented as a point estimate. The post does not provide uncertainty bounds, sensitivity analysis or an error rate for network attribution.
The counterfactual is observational. The difference from baseline is consistent with the takedown removing capacity. Other simultaneous supplier, demand, enforcement or measurement changes could contribute.

None of these limits makes the result useless. They set its resolution. “About 1.06 million fewer addresses reappeared than this baseline predicted” is supported by the published method. “Exactly 1.06 million devices were removed” is not.

What a Sourcing Claim Can Responsibly Prove

A vendor can responsibly prove facts about processes and records it controls.

It can show which entity contracted each direct supplier, which software package enrolled a device, what disclosure was presented, how affirmative consent was recorded, how withdrawal works, which versions were active, and whether a buyer's session can be traced to that evidence. It can document reseller dependencies, prohibit undisclosed sub-supply, test compliance and publish exceptions.

A policy page can prove that a policy exists. A contract can prove that parties accepted terms. Neither proves that every active exit followed the policy.

“Ethically sourced” is therefore too broad unless the provider defines the claim and its coverage. Does it apply only to a proprietary pool? To upstream suppliers? To every session sold by resellers? Does consent come from the device user, the account holder, the network owner or all relevant parties? How quickly is an exit removed after withdrawal?

The strongest claim is session-level and time-bound: for this delivered connection, the provider can trace the supply path to a named enrolment mechanism and current evidence, subject to stated audit limitations. Anything less should be described at its actual scope.

What Auditors and Buyers Should Request

Do not ask only whether sourcing is ethical. Ask for evidence that follows the chain:

a current inventory of direct suppliers, upstream pools and white-label dependencies;
the percentage of delivered traffic covered by direct, auditable sourcing rather than policy language alone;
SDK names, package hashes, versions, distribution channels and signed build provenance;
the exact user disclosure and consent event, including timestamp, software version and withdrawal path;
proof that the person giving consent had authority over the device and network connection;
controls for CGNAT, reassigned addresses, duplicate exits and concurrent appearance across providers;
session-level lineage from buyer request to pool, supplier and enrolment record, sampled by an independent auditor;
contractual limits on sub-suppliers, plus evidence that those limits are tested;
complaint, removal and incident records, including time to disable an exit across every downstream reseller;
methodology for advertised pool size, unique-IP counts and active-device counts, with uncertainty and deduplication rules;
independent test results, exceptions and remediation, not only a clean summary statement.

Buyers should also keep their own record: product and upstream named at purchase time, contract revision, stated sourcing basis, session identifiers where available, destination and purpose, and the control used to prevent abuse. A provider's assurance does not transfer accountability for how the buyer uses the route.

Defenders Still Have a Request to Judge

Post-takedown research can improve proxy intelligence. It cannot turn an IP address into a verdict.

An address that reappears across pools may deserve closer observation, especially on login, account recovery, checkout or expensive APIs. The action should still depend on route, account state, client consistency, behaviour and recent outcomes. That is why a proxy flag is not a security policy.

Keep the provenance of the observation as well. Record which network label was seen, when it was observed, which dataset and version supplied it, what other evidence changed the action, and what happened next. Our guide to residential proxy decision logging sets out that operating record.

A takedown can kill a service without retiring every address that passed through it. The surviving IPs tell us that the market has shared, changing inventory. To say who supplied it, whether a device owner consented, or why a request was sent, we have to follow the rest of the chain.

For the destination, the work continues with the request. The final article in this series explains why a proxy takedown is not a security control and what security and fraud teams should rebaseline after a disruption.

IPIDEA and NetNut: What Two Residential Proxy Takedowns Actually Changed

2026-08-03T08:00:00+10:00

Two large residential proxy networks were disrupted within six months. In late January, Google announced action against IPIDEA. In July, Google, the FBI, Lumen and other partners acted against NetNut, also known as Popa.

Both operations interfered with infrastructure that connected home devices to paying proxy customers. Both prompted Android protections and intelligence sharing. Both were expected to affect providers beyond the name on the announcement.

They were not identical operations, and neither removed residential proxy risk from a login page, checkout, advertising campaign or API.

For security and fraud teams, the useful question is narrower than whether a network was “taken down”. Which parts stopped working, which sources of supply became harder to use, and what still reaches the application?

The Actions Hit Different Parts of the System

The IPIDEA action announced in January combined several controls.

Google said it used legal action to take down domains used to control devices and proxy traffic, as well as domains used to market proxy products and software development kits. Google Play Protect was configured to warn users, remove known applications containing IPIDEA SDKs and block future installation attempts on certified Android devices. Google also shared technical intelligence with platform providers, law enforcement and researchers. Cloudflare disrupted domain resolution.

The July action against NetNut had a different public description. Google disabled Google accounts and associated services that it said NetNut used for command and control. It shared intelligence about SDKs and backend infrastructure, while Play Protect warned users and disabled known applications containing NetNut SDKs. Separately, Alarum Technologies, NetNut's parent company, confirmed in an SEC filing that the FBI had seized domains associated with NetNut and that additional domains were later seized.

That distinction matters. A domain seizure, a disabled cloud account and removal of an application are not interchangeable:

C2 and domain disruption can stop enrolled devices finding instructions or carrying proxy traffic through known control paths.
Account and service suspension removes infrastructure hosted on a provider's platform.
Play Protect enforcement reduces active Android supply and makes the same known applications harder to reinstall.
Intelligence sharing lets other platforms and network operators identify related software and infrastructure.

Each action raises operating cost. None proves that every endpoint, reseller account or replacement control path has disappeared.

IPIDEA Exposed a Shared Supply Chain

Google's IPIDEA investigation described more than 600 Android applications across multiple download sources, 3,075 Windows file hashes that contacted its first-tier domains, and a changing pool of roughly 7,400 second-tier servers. Google also connected several proxy, VPN and SDK brands to common operators and infrastructure.

The company said the disruption reduced the available device pool by millions. It also observed more than 550 tracked threat groups using addresses identified as IPIDEA exits during one seven-day period in January 2026. The reported activity included password spraying and access to victim SaaS and on-premises environments.

The overlap is more useful to buyers than the largest headline number. Different product names and SDK labels fed common infrastructure, while reseller and partnership arrangements created overlap between exit pools. A buyer choosing a second brand could still be purchasing access to the same upstream capacity.

That structure is covered in more detail in How Bandwidth Sharing Feeds Residential Proxy Networks. The point for this comparison is that IPIDEA's disruption reached beyond one storefront because control, distribution and supply were shared.

NetNut Showed the Commercial Effect More Clearly

Google estimated that the NetNut network contained at least two million devices. During one week in June, it observed 316 distinct threat clusters using suspected NetNut exits, including cybercrime and espionage groups. Google also said NetNut ran a substantial white-label reseller programme and assessed with high confidence that a number of popular proxy brands were reselling the network.

Those figures should not be placed in a league table against IPIDEA's. “Devices removed” is not the same measure as an estimated network size. “Tracked threat groups” and “distinct threat clusters” may not use the same counting method. The observations came from different weeks and networks. They establish material scale and misuse, not a defensible ranking.

The stronger comparison is operational. Google later reported that some networks affected by the IPIDEA action appeared resilient: operators whose own supply degraded bought capacity from competitors and became resellers. Its NetNut action was designed with that adaptation in mind.

Alarum's disclosures show that the July action did affect the business. On 3 July, the company said the seized domains were disrupting part of its services and could have a material adverse effect if the disruption continued. It subsequently announced a temporary pause of traffic through relevant network services. In its 13 July update, Alarum said the events had materially affected its business and operations, that an external forensic review was continuing, and that an efficiency plan was expected to affect roughly one-third of its workforce. It was still evaluating how to restore service.

That is evidence of business and service disruption. It is not evidence that every NetNut-related device was cleaned, every reseller lost access, or all residential capacity sold under other names stopped.

Accountability Requires Keeping the Claims Separate

This market has competing accounts of the same infrastructure.

In its March 2026 annual report, Alarum described its network as serving business uses including public web-data collection, price comparison, advertising verification and cybersecurity. It said its experience allowed customers to collect data ethically and effectively. These are the provider's descriptions of its products and intended uses.

Google reported different findings from its threat intelligence and technical investigation. It linked NetNut SDK components to home devices and larger botnets, reported suspected exits used by cybercrime and espionage clusters, and said many brands white-labelled NetNut capacity. For IPIDEA, it reported applications with unclear disclosure, common infrastructure behind several brands, and extensive use by tracked threat groups.

Alarum's official response did not address or endorse Google's technical characterisation, and it did not publish a competing completed investigation. It acknowledged the domain seizures and disruption, said it was investigating whether third parties had misused its services or network, promised cooperation with law enforcement and later said its external review had reached no final conclusions.

The evidence therefore supports several restrained conclusions:

Google identified infrastructure and software it attributed to the two proxy networks and observed serious misuse of their exits.
Google reported significant degradation and reduced device availability; Alarum's disclosures independently confirm disruption to NetNut's operations.
Reseller and white-label relationships make a retail provider name weak evidence of independent supply.
Public reporting does not establish that every customer used the services unlawfully, that every enrolled device joined without consent, or that corporate management directed every observed act.

For procurement and accountability teams, that last boundary is not a reason to ignore the findings. It is a reason to ask better questions. A provider should be able to identify its upstream networks, explain how each endpoint was enrolled, show how consent can be withdrawn, disclose white-label dependencies, describe customer controls, and produce evidence when those claims are challenged.

“Ethically sourced” is not useful due diligence unless the buyer can test what it means.

The Destination Risk Continued

A takedown acts upstream. The protected application sits downstream.

When an SDK is removed or a control domain is seized, some devices leave a pool and some routes fail. That reduces available supply and may interrupt active campaigns. It does not reverse requests already made, clean every non-Android device, reveal every replacement domain, or prevent an operator buying another provider's exits.

The destination still receives requests from consumer and small-business IP addresses. Some belong to customers. Some are shared through carrier-grade NAT. Some are privacy services. Some are residential proxy exits that have not yet appeared in a feed. The application cannot infer who controls a request from the address alone.

This is especially important when the household owner may also be a victim. When Home Devices Become Attack Infrastructure explains why application teams should preserve evidence without attributing the request to the subscriber.

What Buyers Can Now Demand

The two operations give procurement, security and fraud buyers better questions to put to a proxy supplier.

Ask the vendor to identify the retail provider, upstream source, reseller relationship, endpoint-enrolment method and removal process. Contract for notification when an upstream source changes. A new brand or ASN is not proof of a new supply chain.

Ask which proportion of delivered sessions can be traced to direct, auditable sourcing. Require the assurance to cover upstream and white-label capacity, not only a proprietary pool. Check whether withdrawal removes an exit from every downstream reseller and how the provider proves that happened.

Ask what the provider knew and when. A policy page states an intention. Session-level supplier, software, consent and removal records provide evidence that can be tested.

The takedowns removed real infrastructure and imposed real costs. They also demonstrated why disruption is a continuing process rather than a permanent state. Shared supply can move and resellers can change upstream providers.

The operational response belongs in the final article in this series, A Proxy Takedown Is Not a Security Control. It covers the live detection, route policy and outcome measures a destination service should rebaseline after enforcement.

The next article in this series, When a Proxy Network Dies but Its IPs Survive, examines what post-takedown address overlap can prove and where the inference stops.

How Bandwidth Sharing Feeds Residential Proxy Networks

2026-08-01T10:00:00+10:00

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.

Why We Can't Trust IP Addresses

2025-03-11T14:00:00+11:00

This article is a dated market snapshot. Product prices, package sizes and vendor quotations reflect what was publicly advertised in March 2025. The enduring security point is that consumer and mobile connectivity can be packaged cheaply enough to weaken IP-only trust.

Blocking bad traffic by checking an IP address used to be a reasonable starting point. It is not enough anymore. The rise of residential proxies, especially mobile proxies like those from Proxidize, has weakened one of the simpler assumptions in web security: that an IP address tells you much about who is behind a request.

Why is this a problem now?

Residential proxies route traffic through real household IP addresses, so requests look as if they come from normal homes rather than data centres. Companies like Proxidize have made mobile proxy setups accessible using Android phones or USB modems.

In my presentations at AISA and other security conferences, I've described these proxies as systems that "masquerade internet usage as originating from residential and office networks," because they sit outside the assumptions used by many security controls.

What has changed recently is access. Proxidize offers kits that let anyone set up a proxy farm - from 5-modem kits at $499 to 80-modem setups for around $6,000. They have turned proxy farming into a plug-and-play system where you can be up and running "in less than 60 seconds."

The scale is large. Proxidize users process an estimated 80 billion records combined every single day: 80B+ Records Scraped Daily.

The model is also being sold as a "passive income opportunity," where people can earn money by setting up proxy farms and selling access to others. In their recent webinar, they announced plans for a "Proxidize Grid" marketplace where users can sell their proxies with "a single click through an automated Marketplace."

The BYOD mobile proxy revolution

Companies like iProxy.online have taken this further with a Bring Your Own Device (BYOD) approach. Rather than requiring specialised hardware, they let customers turn any Android device into a mobile proxy.

As Sabir, the cofounder of iProxy.online, explained in a recent interview, "You can install iProxy app here and in the dashboard you have proxy access like Socks5, HTTP accesses, and traffic goes through your device."

This means anyone with an old Android phone and a SIM card can create their own mobile proxy, lowering the barrier to entry. For around $59 per month (based on Proxidize's pricing), users get access to what Sabir calls "precious" mobile IP addresses.

Why are mobile IPs so valuable? As Sabir explains: "If you have Barcelona, we are here in Barcelona and you have like 2 million people living there and you have like several thousands of IP addresses from your mobile providers. And one IP address is shared by many. By thousands of people... And if you have mobile IP address, this cannot be blocked by Facebook or Instagram or any other services because in this case, like innocent people, like thousands of them will be blocked."

This carrier-grade NAT (CGNAT) technology means mobile IP addresses are shared across thousands of users, making broad IP blocks difficult without affecting legitimate users.

What this enables attackers to do

With residential proxies, attackers can:

Hide behind legitimate IP addresses that security systems trust
Bypass geo-restrictions to attack from what appears to be a local source
Distribute attacks across thousands of residential IPs to avoid detection
Make malicious traffic look like it comes from normal users

In my work at Peakhour.IO, we've seen a rise in attacks originating from these residential proxies. The Chinese state-sponsored group Camaro Dragon showed the potential of the model when they developed custom firmware for TP-Link routers, turning them into residential proxies for their operations. This method let them bypass traditional defences like GeoIP blocking because the traffic appeared to come from normal homes.

The broader trend is commoditisation. You no longer need to be a nation-state actor to use them. Anyone with a few hundred dollars can set up a residential proxy farm or use services like iProxy.online to route their traffic through mobile networks.

How it obscures an operator's infrastructure

State-sponsored actors such as Volt Typhoon have used compromised small-office and home-office network devices to proxy command-and-control traffic. That use maps to MITRE ATT&CK's proxy technique, T1090: the relay conceals the infrastructure behind the operation.

It does not follow that every stage of an intrusion, including data collection or exfiltration, travelled through residential proxies. Keep the claim attached to the observed behaviour: compromised edge devices carried or concealed operational traffic.

For a precise explanation of the mapping, read Where Residential Proxies Fit in MITRE ATT&CK.

How it enables credential stuffing and other attacks

Credential stuffing attacks have hit Australian businesses hard, with companies like The Iconic, Guzman y Gomez, Dan Murphy's, and others falling victim. Residential proxies help these attacks work because attackers can distribute their login attempts across thousands of residential IP addresses.

When an attack comes through residential proxies, each login attempt appears to come from a different legitimate user. IP-based rate limiting fails because no single IP shows suspicious volume. Even when security teams try to block suspicious regions, proxies let attackers appear to be local customers.

According to our research at Peakhour.IO, traditional IP intelligence services are failing to detect these proxies. Tests we conducted showed that top providers like Maxmind detected 0% of residential proxies, while even the best performer, IP Quality Score, only identified 24%.

The traffic share can be significant. We've seen cases where up to 40% of traffic to Australian e-commerce sites consists of bots using residential proxies for credential stuffing, price scraping, and inventory checking. This puts customer accounts at risk, distorts analytics, and wastes marketing budgets on fake traffic.

The TCP/IP fingerprinting challenge

One aspect of mobile proxies that makes them even more effective is the ability to match TCP/IP fingerprints with the purported device. As Sabir from iProxy.online explains:

"In some cases, your fingerprint, TCP fingerprint should match to your user agent. For example, if you like pretending to be a Mac user or iOS user or Windows user, your TCP fingerprint should be matched with your browser fingerprint."

This means detection mechanisms that look for mismatches between TCP/IP fingerprints and browser types can also be bypassed.

Anybody can now set them up

The barrier to entry for setting up residential proxies has fallen sharply. Companies like Proxidize market their products as simple to use, with statements like "Start using Proxidize in less than 60 seconds."

There are YouTube videos showing how to earn "passive income" by setting up proxy farms. One video explains how hosts can earn "$200 a month minimum" by hosting Proxidize hardware in their homes.

With iProxy.online, it's even simpler—just install an app on an Android phone, and you have a mobile proxy. As Sabir explains, "Actually your expenses are like you pay like for the SIM card, you pay a small subscription fee to the service and you just... That's it. It requires like one minute of work just to download an app."

This accessibility means residential proxy use is no longer limited to nation-states and sophisticated cybercriminal organisations. It is now within reach of anyone with basic technical skills.

The solution: per-connection detection

The rise of residential proxies means IP reputation databases are not enough on their own. As I've been explaining in my talks, "Residential proxies pose a significant challenge to traditional defense mechanisms... making malicious traffic appear legitimate."

The practical answer is per-connection detection that looks at network behaviour patterns rather than just IP addresses. At Peakhour.IO, we stack detections across layers to identify and mitigate proxy traffic.

A useful technique is analysing protocol behaviour. When traffic passes through a residential proxy, there are often detectable differences between network signatures (which come from the proxy) and the application behaviour (which comes from the third-party application).

These techniques can identify proxy connections even when they come from legitimate residential IP addresses, giving defenders a way to respond without blocking whole residential or mobile networks.

A call to action for businesses

If you're a business, especially in e-commerce, financial services, or any industry that relies on user accounts, residential proxy traffic needs to be part of your security model.

Traditional security approaches based on IP reputation, geolocation, and rate limiting are no longer sufficient. You need to implement per-connection detection that can identify residential proxy usage regardless of the source IP address.

At Peakhour.IO, we've seen organisations fall victim to attacks that could have been prevented with the right detection mechanisms. Waiting until credential stuffing or data exfiltration becomes visible is the expensive way to learn this lesson.

IP addresses alone can no longer tell us who to trust. We need to look deeper at each connection to protect systems and data now that proxy networks are easy to rent or build.

Did Residential Proxies enable a $600 Billion loss?

2025-01-31T00:00:00+11:00

The DeepSeek story puts residential proxy networks under scrutiny as a possible factor in AI's latest market disruption. In January 2025, the Chinese startup's emergence erased $600 billion from Nvidia's market value by demonstrating AI capabilities that match industry leaders at a fraction of the cost.

The path to this capability raises a practical security question for AI platforms. Leading platforms protect their APIs with multiple security layers - rate limiting to prevent mass data extraction, bot detection to block automated requests, and geoblocking to restrict access from certain regions. These measures are meant to prevent the systematic collection of training data.

Residential proxy networks create a route around those protections. These networks route traffic through household IP addresses, so requests appear to originate from homes in permitted regions. A request from a restricted location could look like legitimate traffic from Sydney, Melbourne, or Perth.

The circumstances suggest this approach is plausible. By distributing requests across millions of residential IPs worldwide, each IP could maintain human-like patterns while staying below rate limits. The aggregate data could form a substantial training set without triggering security alerts.

Meta's lawsuit against Bright Data strengthens this possibility. The case exposed how proxy providers monetise residential IPs, often without homeowners' knowledge. That model creates a global network capable of bypassing traditional security measures - exactly the type of infrastructure needed for large-scale data collection.

The residential proxy industry threatens $600 billion in business value through data theft and security bypasses. DeepSeek's impact on Nvidia's market capitalisation highlights the real-world impact of residential proxies.

For AI platforms, the question is operational. How can platforms distinguish between legitimate users and well-crafted requests through residential proxies? When geographical restrictions lose meaning, what security measures remain effective? Traditional IP Intelligence based proxy detection based on historical usage is no longer effective; per-connection proxy detection is essential.

DeepSeek's emergence suggests AI security teams need to revisit their assumptions. The potential use of residential proxy networks to dissolve digital borders challenges current approaches to platform protection.

Residential Proxies - The Growing Threat to Ad Campaigns

2024-12-30T00:00:00+11:00

Digital advertising fraud costs organisations $42 billion annually through fake clicks and fake impressions. The growth of residential proxy networks has changed how this fraud reaches campaigns: bot traffic can now hide behind legitimate residential IP addresses, putting it outside the reach of many traditional checks.

Hiding in the crowd

Residential proxies make bad traffic harder to separate from real visitors. Unlike data centre IPs that traditional tools can often detect, residential proxies hide behind real households' internet connections. This means the traffic appears to come from genuine users in your target market. When a residential proxy network operates from Sydney suburbs to attack an Australian campaign, existing protection systems can be fooled into treating it as authentic local traffic.

The impact extends beyond direct financial losses. Your analytics may show engagement from what appears to be your target demographic, while the activity is bot traffic masquerading as potential customers. This contaminated data can push marketing strategy in the wrong direction and waste retargeting spend. Competitors can also use fake clicks to drain your budget while gathering intelligence on your campaigns.

Bad data then compounds the spend problem. Once bots are counted as engaged prospects, reporting and optimisation start from the wrong signal. The result is not only wasted media spend, but poorer decisions built on traffic that should never have been treated as customer intent.

A growing threat

The residential proxy industry continues to expand. Services now offer millions of residential IPs with precise geographic targeting capabilities. They rotate IPs automatically and match real browser fingerprints. Without specialised detection methods, the traffic can become indistinguishable from genuine users.

This is a budget problem, not just a technical one. Each day without protection means 30-40% of your ad budget feeds bot networks instead of reaching customers. The corrupted analytics drive decisions that compound these losses. As residential proxy services grow more sophisticated, basic controls fall further behind.

Traditional IP reputation and rate limiting fail against this distributed threat because the IP addresses are not obviously suspicious. Protection requires advanced network fingerprinting that looks beyond IP addresses. Peakhour's Ad Fraud Protection analyses subtle patterns in how residential proxies connect and behave, and detects the signs of proxy traffic that other solutions miss.

Knowledge is power

Peakhour integrates this protection with your existing ad platforms to stop fraud before it affects your campaigns. Our customers have reduced wasted ad spend by 35% while improving campaign performance through cleaner analytics. The system adapts as threat techniques change, so detection keeps pace with new residential proxy methods.

Residential proxies have changed ad fraud because traffic that appears local and legitimate may mask sophisticated bot networks. Protecting your campaigns requires detection that goes beyond IP addresses and treats residential proxy behaviour as its own signal. Contact us to learn how we can help secure your ad spend against residential proxy networks.

Your Anti-Fraud Residential Proxy Detection Sucks

2024-10-04T13:00:00+10:00

Online fraud is big business: account takeovers, chargebacks, scams, even romance scams. It costs businesses billions of dollars every year.

A common way websites fight it is to use an anti-fraud service to calculate the risk of a transaction. Most teams get this intelligence from a third-party service, either through an API or a plugin.

For online stores, ecommerce fraud prevention has to protect checkout and account flows without punishing real customers.

One of the major signals these services use is IP reputation. IP reputation tries to answer questions like:

Is the order coming from a datacentre?
Is it coming from a country other than your target audience?
Is the IP address a known VPN?
Is it a known TOR exit node?
Have lots of fraudulent orders come from this IP address in the past?

Until recently, these services gave teams a useful way to calculate fraud risk from an IP address.

Not anymore.

Fraud traffic has shifted in recent years, away from VPNs and TOR and toward residential proxies. These same anti-fraud services claim they can detect residential proxies, but what if the services many businesses rely on are falling well short?

The results are bad enough that they deserve a blunt look.

The Shocking Truth: Our Results

We took 25 IP addresses that had just been used as residential proxies in an attack on one of our clients, and within 5 minutes of detection ran them through some of the most popular IP intelligence services. The results are not going into anyone's marketing deck.

Here's a summary of our findings:

Service	Detected Proxies	Accuracy
Maxmind	0/25	0%
IP Quality Score	6/25	24%
Seon	1/25	4%
ProxyCheck.io	0/25	0%
ip2proxy	1/25	4%

The best performer in our test, IP Quality Score, detected only 24% of the proxies. The others ranged from 0% to 4%.

Why Your Residential Proxy Detection Service is Failing You

So why are these services performing so poorly? To understand it, we need to look at how proxy usage and detection have changed.

The Good Old Days of Proxy Detection

In the recent past, detecting proxies was much easier. Fraudsters primarily used:

TOR networks
VPN services
Data center proxies

These were relatively static targets. They were tied to a single, stationary IP, or IP ranges. Listing them in IP block lists was straightforward.

The Rise of Residential Proxies: A New Breed of Threat

Now we need to talk about residential proxies, the new go-to tool of fraudsters and scammers. These are not just a new label for old proxies. They behave differently.

What Are Residential Proxies?

Residential proxies come from IP addresses assigned to real residential services by Internet Service Providers (ISPs). These can be:

Home computers
Mobile phones
Tablets
IoT devices

Unlike data center proxies, which use IP addresses from hosting companies, residential proxies use IPs that look just like any other home or mobile user. They have become the tool for avoiding security controls on websites in the last 2-3 years, and they are causing all sorts of headaches for website owners.

How Are Residential Proxy Networks Formed?

This is where the problem starts:

Compromised Devices: Malware can turn innocent devices into proxy endpoints without the owner's knowledge.
Incentivised Programs: Some companies offer users benefits (like free VPN services) in exchange for using their device as a proxy endpoint. Hola VPN and Brightdata are prominent examples.
APP SDKs Quite often, proxy providers will incentivise app developers to include their proxy toolkit in their apps. The user is totally unaware that their device's internet connection is now being resold.

So your personal device, be it a computer or phone, could have its internet connection used to carry out a crime without you knowing. The police could come knocking on YOUR door one day.

Why Are They So Dynamic?

Since the proxy is formed by reusing the internet connection of a device, it is inherently much more dynamic than a proxy formed on a server.

Device Mobility: A mobile phone can connect from home Wi-Fi, then a coffee shop, then a cellular network – all in one day.
ISP IP Rotation: Many ISPs dynamically assign IP addresses, changing them periodically.

Depending on the type of fraud being carried out, the attacker might also rotate the device being used, popping out of a different location. Also, due to the way these proxies are formed, i.e. via an app on a computer or phone, that particular exit point on the proxy network might depend on that app being open.

This dynamic nature is what makes residential proxies so hard to detect using traditional methods.

Shared IPs: The Needle in the Haystack Problem

Residential proxy IPs are not just dynamic. They are typically shared. This means that a single IP address could be used by both legitimate users and proxy traffic:

ISP IP Pools: Internet Service Providers often use large pools of IPs that are dynamically assigned to users. This means that an IP used by a proxy one minute could be assigned to your grandmother's iPad the next.
Carrier-Grade NAT (CGN): Mobile carriers frequently use CGN, which can make hundreds or thousands of users appear to come from the same IP address.
Compromised Routers: A single compromised home router could serve both the legitimate traffic of the homeowner and proxy traffic from the attacker.

If you simply blocked any IP that shows proxy behavior, you would end up blocking legitimate users too.

Why Traditional Methods Are Failing (Revisited)

Now that we understand residential proxies better, let's revisit why old-school detection methods are not enough.

1. Port Scanning

Traditional proxy detection often relies on scanning for open proxy ports. Here's a simple port scanner:

import socket

def port_scan(ip, port):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    result = sock.connect_ex((ip, port))
    sock.close()
    return result == 0

# Example usage
ip = "123.45.67.89"
proxy_ports = [80, 8080, 3128]  # Common proxy ports

for port in proxy_ports:
    if port_scan(ip, port):
        print(f"Port {port} is open - potential proxy detected")

Why it fails: Residential proxies don't typically have these ports open. They route traffic through standard web ports, making them indistinguishable from normal traffic.

2. Honeypots

Honeypots try to lure and identify proxy traffic.

Why it fails: Sophisticated residential proxy networks can identify and avoid known honeypots. Plus, since they're using real residential IPs, even if they do hit a honeypot, the IP itself isn't a reliable indicator of proxy usage.

3. Client-Side Detection

Detection services may also try to detect proxies by executing Javascript in the browser and checking the result for inconsistencies. These are the common techniques.

3.1 WebRTC Leak

WebRTC can sometimes reveal a user's true IP address:

function detectRealIP(callback) {
    var RTCPeerConnection = window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection;
    var pc = new RTCPeerConnection({iceServers:[]}), noop = function(){};
    pc.createDataChannel("");
    pc.createOffer(pc.setLocalDescription.bind(pc), noop);
    pc.onicecandidate = function(ice) {
        if(!ice || !ice.candidate || !ice.candidate.candidate) return;
        var myIP = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/.exec(ice.candidate.candidate)[1];
        pc.onicecandidate = noop;
        callback(myIP);
    };
}

detectRealIP(function(ip) {
    console.log("Your real IP address is: " + ip);
});

3.2 Geolocation Inconsistencies

Comparing IP-based geolocation with browser-reported location.

navigator.geolocation.getCurrentPosition((position) => {
  const browserLat = position.coords.latitude;
  const browserLong = position.coords.longitude;
  // Compare with IP-based geolocation from server
});

3.3 DNS Leaks

Check whether DNS requests are routed through the proxy or are leaking:

const image = new Image();
const uniqueDomain = `test-${Date.now()}.example.com`;
image.src = `http://${uniqueDomain}/pixel.gif`;
// Monitor DNS requests server-side to detect leaks

3.4 Browser Fingerprinting

Check whether there are inconsistencies with the browser, e.g. timezone, and the geolocation of the IP address

const fingerprint = {
userAgent: navigator.userAgent,
screenResolution: `${screen.width}x${screen.height}`,
colorDepth: screen.colorDepth,
timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
plugins: Array.from(navigator.plugins).map(p => p.name),
// ... other characteristics
};
// Analyze fingerprint for proxy indicators

Why these techniques fail

Proxy services can work around all of these methods. Many browsers now allow users to disable WebRTC or use extensions that prevent this leak. Some residential proxy services are sophisticated enough to handle WebRTC requests without leaking the real IP.

Finally, relying on client-side detection means: * Your detection can be reverse engineered and bypassed. * You've already served the content the attacker wants. * It requires Javascript execution, something that won't always be available, for instance on an API.

4. Threat Intelligence

Threat intelligence involves maintaining databases of known proxy IP addresses:

import requests

def check_ip_threat_intel(ip):
    api_key = "your_api_key_here"
    url = f"https://api.threatintelligence.com/v1/ip/{ip}?key={api_key}"
    response = requests.get(url)
    if response.status_code == 200:
        data = response.json()
        return data.get('is_proxy', False)
    return False

# Example usage
ip = "123.45.67.89"
if check_ip_threat_intel(ip):
    print(f"{ip} is a known proxy according to threat intelligence")

Why it fails: As our results show, threat intelligence databases are struggling to keep up with the dynamic nature of residential proxies. By the time an IP is identified and added to a database, it may no longer be in use as a proxy.

Why IP-Based Blocking Is No Longer Enough

Given the shared nature of IPs in the age of residential proxies, simply identifying and blocking "bad" IPs is too blunt. Here's why:

False Positives: Blocking an IP used by a proxy might also block legitimate users sharing that IP.
Ineffectiveness: Proxies can quickly switch to new IPs, so IP-based blocking turns into a chase.
Collateral Damage: You might end up blocking entire ISPs or mobile carriers, cutting off large swaths of legitimate users.

The practical failure is customer friction. A checkout, login, or account recovery flow cannot treat every residential or mobile network as hostile. Teams need enough request context to choose a proportionate response: log the signal on a low-risk page, challenge a suspicious account change, rate limit repeated failures, or block only when proxy evidence lines up with stronger abuse indicators.

The same problem shows up on APIs and partner integrations. A partner batch job, mobile carrier, or shared office network can look noisy without being hostile. A compromised key can look legitimate until it starts hitting expensive routes. Good review paths keep the route, account or API key, request rate, fingerprint, and recent outcomes together so the answer is not just "block the IP" or "allow everything."

This is where proxy detection stops being a lookup problem and becomes an operating problem. The team needs to know which route was hit, what account or session was involved, whether the request matched normal behaviour, and what the enforcement cost would be if the signal was wrong. That is the difference between reducing abuse and quietly pushing good customers into support. For a deeper treatment of that tradeoff, see the guide to customer friction and false-positive measurement.

The Need for Connection-Level Detection

Instead of focusing only on IPs, we need to look at the connections themselves. Here's what this means:

Deep packet inspection: Analyses traffic patterns and characteristics beyond surface-level indicators.
Protocol behaviour analysis: Identifies subtle anomalies in how network protocols are implemented across the proxy chain.
TLS/TCP fingerprinting: Examines characteristics of TLS handshakes to detect proxy usage.
Timing analysis: Measures minute differences in network latency that can indicate the presence of a proxy.

Final Thoughts

Proxy usage has evolved, and detection methods need to keep up. Simple IP-based blocking and static lists of "bad" addresses are no longer enough. They still have a place, but they cannot be the whole answer.

Modern residential proxy detection has to evaluate the live request: IP context, connection behaviour, fingerprints, route, account state, request rate, and recent outcomes. On a low-risk page that may only justify logging. On login, signup, checkout, password reset, API key creation, or account recovery, the same signal may justify a challenge, hold, rate limit, or block.

Peakhour's residential proxy detection is built for that request-path decision. The point is not to label every residential IP as bad. The point is to give operators enough evidence to act when proxy use lines up with account abuse, fraud, scraping, or automated traffic.

If you're still treating IP reputation as the main answer, you're already behind. It's time to stop blocking IPs and start understanding the request.

Want a demo of our residential proxy detection? Contact us for a live demo of our service.

The Challenge of Proxy Detection

2024-07-19T10:00:00+10:00

Our recent survey found that only 15% of Australian organisations use residential proxy detection. That leaves many teams relying on controls that were not built for current proxy traffic, especially where CGNAT and NAT make IP-level decisions unreliable.

The Shortcomings of Traditional Methods

Legacy bot protection providers often combine IP reputation, network characteristics, header analysis, and JavaScript-based checks to identify proxy usage. These methods struggle against well-run residential proxies:

IP and ASN categorisation: Ages quickly as new proxy networks emerge.
Network-level checks: Well-configured proxies can work around them.
Header analysis: Proxies can alter HTTP headers to mimic legitimate traffic.
JavaScript-based detection: Struggles against headless browsers and leaves API endpoints vulnerable.

The CGNAT and NAT Challenge

A practical limit of traditional methods is their inability to distinguish legitimate traffic from proxy traffic when both originate from the same IP address. Carrier-Grade NAT (CGNAT) and Network Address Translation (NAT) make this common:

CGNAT: Used by ISPs to conserve IPv4 addresses, resulting in multiple users sharing a single public IP.
NAT: Commonly used in home and business networks, allowing multiple devices to use one public IP address.

As a result, legitimate users and residential proxy traffic can appear to come from the same IP address. IP reputation and geolocation alone cannot separate these traffic types.

This creates a difficult tradeoff:

Blocking suspicious IPs risks denying service to legitimate users.
Allowing all traffic from these IPs opens the door to potential abuse via residential proxies.

Traditional methods cannot reliably pull apart these different types of traffic, so teams either block too much legitimate traffic or allow too much proxy traffic through.

The Need for Sophisticated Network Fingerprinting

To detect and mitigate residential proxy threats while allowing legitimate traffic from shared IPs, detection needs to move beyond IP identity. Network fingerprinting addresses the limits of traditional methods:

Deep packet inspection: Analyses traffic patterns and characteristics beyond basic IP or header indicators.
Protocol behaviour analysis: Identifies subtle anomalies in how network protocols are implemented across the proxy chain.
TLS fingerprinting: Examines unique characteristics of TLS handshakes to detect proxy usage.
Timing analysis: Measures small differences in network latency that can indicate the presence of a proxy.

Used together, these techniques can detect proxy usage on a per-connection basis for both web traffic and API calls, even when traffic originates from shared IP addresses. This approach provides several advantages:

Improved accuracy: Significantly reduces false positives and negatives compared to traditional methods, including in CGNAT and NAT scenarios.
API protection: Secures API endpoints, which are often overlooked by JavaScript-based solutions.
Real-time detection: Allows for immediate action against detected proxy usage without impacting legitimate users.
Adaptability: Can be updated to detect new proxy technologies as they emerge, regardless of IP sharing.

Implementing Effective Proxy Detection

To implement proxy detection that accounts for modern network complexity, organisations should consider the following:

Deploy solutions that use network fingerprinting techniques capable of distinguishing between different types of traffic from the same IP.
Ensure protection covers both web applications and API endpoints, as both are vulnerable to proxy-based attacks.
Implement real-time mitigation capabilities to respond swiftly to detected threats without impacting legitimate users.
Regularly update and tune detection algorithms to keep pace with evolving proxy technologies and network architectures.

Together, these practices improve an organisation's ability to detect and mitigate residential proxy threats across credential stuffing, account takeover, and related activity, while keeping access available for legitimate users.

Learn more about our proxy detection solution, which uses network fingerprinting to address the challenges posed by CGNAT and NAT.

For more detail, explore our learning resources:

As proxy technologies and network architectures change, detection and mitigation need to change with them. Network fingerprinting gives organisations a more reliable way to identify residential proxy abuse without treating every shared IP as suspicious.

Quantifying The Residential Proxy Threat

2024-07-18T10:00:00+10:00

Our 2024 survey found that only 15% of Australian businesses use residential proxy detection. That leaves a measurable blind spot in many security programmes: traffic routed through real consumer connections is harder to separate from legitimate users. This article looks at why residential proxy detection is difficult and how to quantify the risk before choosing controls.

Understanding the Residential Proxy Threat Landscape

Residential proxies use IP addresses assigned to residential internet connections, so malicious traffic can look legitimate. This weakens controls built around IP reputation, GeoIP, and simple request thresholds, and creates a specific detection problem for security teams.

The effectiveness of residential proxies stems from their ability to:

Use legitimate IP addresses, often from unsuspecting users
Bypass IP-based rate limiting and traditional bot detection methods
Evade geolocation restrictions, making GeoIP filtering less reliable
Support large-scale attacks without triggering typical alarm thresholds
Mimic legitimate user behaviour, which makes detection more difficult

These capabilities make residential proxies useful infrastructure for credential stuffing, data scraping, and attempts to bypass fraud detection systems. Because the traffic is distributed across many residential connections, attacks can stay below the thresholds that conventional controls rely on.

Limitations of Conventional Security Approaches

Conventional controls have clear gaps when they are applied to residential proxy traffic:

IP-based detection misses constantly changing, legitimate-appearing IP addresses.
GeoIP filtering becomes less useful against globally distributed residential IPs.
User agent analysis struggles because proxies can mimic legitimate browsers.
Standard rate limiting falters when attacks appear to originate from many unique IPs.
Behavioural analysis based on known bot patterns may miss more careful proxy-based attacks.

These limitations point to a practical requirement: security teams need controls that assess context, not just static request attributes. Residential proxies make simple rule-based decisions less reliable, especially when attacks are distributed and deliberately low-noise.

Quantifying the Risk

To make a sensible decision about residential proxy controls, organisations need to quantify the risk. This involves:

Assessing the potential financial impact of successful attacks via residential proxies
Evaluating the likelihood of such attacks based on industry trends and organisational attractiveness to attackers
Determining the effectiveness of current security measures against this specific threat
Calculating the return on investment for implementing advanced detection and mitigation strategies

Risk quantification gives businesses a clearer basis for investing in residential proxy detection. It aligns security spending with actual threat levels and potential impacts, rather than broad concern or industry pressure alone.

Reframing Security

The challenge of residential proxy detection is less about one new control and more about how signals are combined. A useful approach includes:

Contextual Analysis: Analyse the full context of each request, not just its origin. This includes examining patterns of behaviour across multiple sessions and users.
Continuous Monitoring and Adaptation: Use real-time monitoring systems that can detect subtle patterns indicative of proxy use. These systems should continuously adapt to new attack vectors.
Risk-Based Authentication: Use dynamic authentication mechanisms that adjust based on the assessed risk of each session or transaction.
Holistic Data Analysis: Correlate data from multiple sources - including login attempts, transaction patterns, and user behaviour - to identify anomalies that may indicate proxy use.
Proactive Threat Hunting: Actively search for indicators of residential proxy use within your network and user base, rather than waiting for attacks to trigger alerts.

This approach moves beyond simple allow/block decisions and gives teams a better view of user and network behaviour.

Implementing Advanced Detection Strategies

Residential proxy threats need detection that looks beyond the source IP:

Machine Learning-Based Behavioural Analysis: Use AI and machine learning to identify patterns consistent with proxy use, even when individual actions appear legitimate.
Device Fingerprinting Beyond IP: Use advanced fingerprinting techniques that identify individual devices based on a combination of factors, making it harder for proxies to mimic legitimate users.
Network Traffic Analysis: Analyse network behaviour at a granular level to identify patterns consistent with proxy network traffic.
Adaptive Challenge Mechanisms: Deploy targeted challenges based on risk assessment, without disrupting legitimate user experiences.
Cross-Organisational Data Sharing: Participate in threat intelligence sharing networks to gain broader insights into residential proxy activities and emerging attack patterns.

When used as part of the broader security stack, these strategies improve defence against residential proxy threats.

Elevating Security Through Risk Quantification

Residential proxies are not only a technical detection problem. They change the risk model for web applications because attacker traffic can borrow the appearance of ordinary residential users. By adopting a risk quantification approach and implementing advanced detection strategies, organisations can:

Align security investments with actual threat levels
Improve detection of sophisticated, proxy-based attacks
Strengthen overall security posture against evolving threats
Make data-driven decisions about security priorities and resource allocation

Organisations that handle this well will be able to quantify their risk, adapt their security strategies, and implement intelligent detection mechanisms. The goal is practical: identify, analyse, and mitigate sophisticated threats before they cause material damage.

Effective protection starts with understanding the risk well enough to measure it.

The Rise of the Dragon

2023-05-17T13:00:00+10:00

Camaro Dragon, a Chinese state-sponsored group, has developed a custom firmware implant for TP-Link routers. Once installed, it can turn compromised routers into residential proxies. That weakens traditional cyber-defences, including GeoIP blocking, because traffic can appear to come from ordinary local connections. This article looks at how the malware works, why residential proxies matter for enterprise security, and where GeoIP security measures fall short.

Understanding the New Malware

Check Point's research describes Camaro Dragon's sophisticated attacks on European foreign affairs entities. The group uses a custom firmware implant, known as 'Horse Shell', designed specifically for TP-Link routers. The malware includes a backdoor that grants the attackers continuous access to compromised networks and allows them to build anonymous infrastructure.

'Horse Shell' can execute arbitrary commands on the infected router, transfer files, and relay communications using SOCKS tunnelling. Its design can be adapted to different vendors' firmware, suggesting the possibility of a wider spread.

The People and Intentions Behind The Malware

Check Point Research attributes the activity to a Chinese state-sponsored group it tracks as Camaro Dragon. The campaign has significant overlaps with activity publicly associated with Mustang Panda, including shared infrastructure and tooling. Check Point was careful not to describe the two labels as an exact match. That distinction matters when a technical finding is used for threat attribution.

The primary function of 'Horse Shell' is to relay traffic between an infected device and the attackers' command and control servers. This method obscures the true source and destination of the communication, making it difficult to trace back to the attackers.

Importantly, Mustang Panda appears to choose router implant targets indiscriminately. The infection of a home router doesn't imply that the homeowner is a direct target. Instead, each infected router becomes a node in a broader chain that connects main infections with command and control operations.

Researchers identified this approach when they found the 'Horse Shell' implant during an investigation of targeted attacks against European foreign affairs entities. The implant allows the attackers to maintain ongoing access, establish anonymous infrastructure, and move laterally within compromised networks.

The Implications of Residential Proxies

Residential proxies serve as intermediaries, using real IP addresses issued by Internet Service Providers (ISPs). They are used across a range of applications, including business web scraping and anonymising user online activity.

Residential proxy infrastructure becomes more serious when malware such as 'Horse Shell' is involved. The implant turns a compromised router into a relay that can carry an operator's traffic. Check Point demonstrated command execution, file transfer and SOCKS tunnelling. Its report did not attribute credential stuffing, data breaches or DDoS attacks to this implant.

Most importantly, this use of residential IP space can make an attack look as if it originates from a domestic source within the target's location. That undermines traditional cyber-defences.

GeoIP Security Measures and Their Limitations

GeoIP blocking, a traditional cyber security tool, works by limiting access from specific geographical regions or networks frequently associated with cyber threats. However, this method is becoming less effective against the rising use of residential proxies.

Residential proxies can disguise the actual origin of a cyber attack, giving the illusion that it's originating from a trusted, usually local, location. This capability allows them to effectively bypass GeoIP blocking measures. Consequently, malicious actors using residential proxies can carry out their activities with less obvious attribution and often go undetected.

The key operational issue is the exploitation of home routers by malware like 'Horse Shell,' which turns these devices into unwitting participants in cyber attacks. This manipulation means an attack could appear to originate from a seemingly trusted domestic source, which can render GeoIP blocking ineffective.

This threat shows why cyber security needs a more layered approach. Sole reliance on GeoIP blocking is no longer enough. As malware evolves to exploit residential proxies, detection and defence strategies need to adapt. Specifically, it's important to recognise that relying solely on GeoIP blocking, or trusting apparently local connections and deny-listing countries like Russia and China, can create a false sense of security.

Detecting Residential Proxies: The Role of Network Fingerprinting

The rise of residential proxy malware makes network fingerprinting important for identifying these threats. Five techniques can help detect residential proxies:

TCP Fingerprinting: Proxied requests may generate TCP fingerprints that don't match the expected device type. For example, a request from a residential IP address that bears the fingerprint of a server OS could be a strong signal of a proxy.
TLS and HTTP/2 Signatures: As with TCP fingerprints, unusual TLS and HTTP/2 signatures could reveal proxies. An incoming request using a version of TLS or HTTP/2 not commonly used in residential networks might indicate a proxy.
JavaScript-based Fingerprinting: This method identifies the specific browser in use. Discrepancies in JavaScript fingerprints, or the absence of a fingerprint, could suggest the presence of a residential proxy.
Timing Analysis: The timing of requests can also be a signal. Proxied requests might exhibit longer or inconsistent intervals between requests, indicating a residential proxy.
Behaviour and route context: At the application, the strongest decision comes from combining proxy evidence with the route, account state, request sequence and recent outcomes. Scanning the public exit for an open proxy port does not reliably detect an outbound tunnel established by a compromised router.

While residential proxies have legitimate uses, such as web scraping, those applications sit beside a more serious risk: compromised trusted or local networks can be turned into proxy infrastructure at scale. Cyber threats like 'Horse Shell' use residential proxies to undermine traditional GeoIP security measures, which means defence strategies need to keep evolving.

In Part 1 of our series on residential proxies, we provide an overview of this topic and why it matters to security teams. From basic uses to their role in complicated cyber attacks, we cover the key points.

Learn how Peakhour's Application Security Platform protects against account takeovers and credential stuffing. Contact our team to secure your user accounts.

Cohen, I., Madej, R., & Threat Intelligence Team (2023). The Dragon Who Sold His Camaro: Analyzing Custom Router Implant. Check Point Research. Retrieved from https://research.checkpoint.com/2023/the-dragon-who-sold-his-camaro-analyzing-custom-router-implant/ ↩
Goodin, D. (2023, May 17). Malware turns home routers into proxies for Chinese state-sponsored hackers. Ars Technica. Retrieved from https://arstechnica.com/information-technology/2023/05/malware-turns-home-routers-into-proxies-for-chinese-state-sponsored-hackers/ ↩

Where Residential Proxies Fit in MITRE ATT&CK

2023-05-17T13:00:00+10:00

MITRE ATT&CK gives defenders a precise way to describe how an adversary uses a proxy inside an intrusion. That precision is useful. It is also easy to lose when every login attempt, scrape or fraudulent checkout routed through a residential IP is labelled T1090.

ATT&CK technique T1090 belongs to the Command and Control tactic. It describes adversaries directing network traffic through an intermediary to avoid a direct connection to their infrastructure, maintain resilient communications or use a trusted path between systems.

That scope includes compromised routers acting as relays. It does not make T1090 a general classification for residential proxy traffic on the public web.

What T1090 Actually Covers

MITRE divides T1090 into four sub-techniques:

T1090.001 Internal Proxy: traffic is relayed through a system inside the target environment.
T1090.002 External Proxy: an external intermediary, such as a VPN or other proxy service, conceals the adversary's connection.
T1090.003 Multi-hop Proxy: several intermediaries are chained together.
T1090.004 Domain Fronting: a content delivery or hosting route is used to disguise the intended command-and-control destination.

The common thread is adversary communications. A proxy helps the operator reach a command-and-control server, route into another system or hide the infrastructure behind the operation.

A residential exit may be one of those intermediaries. The address type is not what creates the ATT&CK mapping. The proxy's role in the intrusion does.

Horse Shell Is a Relevant Example

In 2023, Check Point Research analysed Horse Shell, a custom implant found in modified TP-Link router firmware associated with activity it tracks as Camaro Dragon.

Horse Shell could execute commands, transfer files and create a SOCKS5 tunnel through the compromised router. That last capability let an operator relay traffic through the victim's connection and use the router as anonymous infrastructure. This is the kind of behaviour T1090 is designed to describe.

Attribution needs the same care as technique mapping. Check Point found significant overlaps between Camaro Dragon and activity publicly associated with Mustang Panda. Its report explicitly stopped short of saying the two labels represented exactly the same group.

The research also did not establish that Horse Shell was used for credential stuffing, account takeover or DDoS. Those are plausible uses for proxy infrastructure in general, but they are not findings from this incident.

Volt Typhoon Shows the Wider Infrastructure Model

MITRE lists Volt Typhoon as a T1090 procedure example. Joint government reporting says the group used compromised small-office and home-office routers, virtual private servers and multi-hop proxies to conceal command-and-control traffic.

Several ATT&CK concepts can describe different parts of that operation:

T1090 Proxy describes the relaying of command-and-control traffic.
T1583.003 Acquire Infrastructure: Botnet can describe obtaining access to botnet capacity.
T1584.005 Compromise Infrastructure: Botnet can describe compromising devices that are then used as operational infrastructure.

These mappings should not be collapsed into “residential proxies were used for data exfiltration”. An intrusion may include collection and exfiltration as separate behaviours, while the proxy infrastructure conceals or carries command-and-control traffic. ATT&CK works because those actions remain separate.

Public-Web Abuse Is a Different Defensive Problem

Residential proxies are also used for credential stuffing, fake account creation, scraping, ad fraud, checkout abuse and other activity directed at public applications. The operator buys or controls an exit, then sends an otherwise ordinary web request through it.

That request may not be part of an enterprise intrusion or command-and-control channel. ATT&CK is therefore not the right taxonomy for every part of the event.

For an application team, the useful questions are closer to the request:

Which route is being used?
Is the client testing credentials, creating accounts or extracting data?
Does the behaviour continue across changing IP addresses?
Do the network, browser and session observations agree?
What action can reduce the harm without blocking unrelated users on the same ISP or carrier address?

Residential proxy detection supplies one part of that evidence. The policy still needs route, account, fingerprint, behaviour and outcome context.

Defend the Two Surfaces Separately

An enterprise network and a public application observe different sides of proxy use.

Endpoint and network teams looking for T1090 should investigate unauthorised tunnelling and traffic bridging: unexpected proxy processes, port-forwarding changes, compromised routers, unusual outbound destinations and connections that let an external operator reach internal systems. MITRE's current detection guidance focuses on that setup and relay behaviour.

Application and fraud teams see requests after the relay has already done its job. They should correlate the proxy signal with the protected route and the work being attempted. A public article request may be logged. A login sequence testing exposed credentials may be challenged or rate limited across account and client cohorts. A high-risk account change may require stronger verification.

IP reputation remains useful in both cases, but it is not identity. A household address can carry legitimate traffic and relayed traffic at the same time. A fresh exit can also be active before a static feed records it.

Use ATT&CK at Its Actual Resolution

T1090 is a sound description when a proxy carries or conceals adversary command-and-control communications. Horse Shell and Volt Typhoon show why compromised edge devices matter in that context.

The framework does not say that every residential proxy request is command and control, nor that proxy detection alone establishes malicious intent. Keep the mapping attached to the observed behaviour. Use application controls for the public request, and ATT&CK techniques for the intrusion activity they actually describe.

For the sourcing side of the problem, read How Residential Proxy Networks Are Formed. For application policy, continue with Proxy Signals and Security Decisions.