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.

A Proxy Takedown Is Not a Security Control

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

A residential proxy network is disrupted on Tuesday. On Wednesday, a password-spraying campaign is still reaching your login route through consumer IP addresses. The takedown changed upstream supply. It did not stop the campaign at your edge.

Legal action, platform enforcement, domain seizures, malware removal, and industry coordination matter. They can protect device owners, remove capacity, raise operating costs, and expose relationships that were previously difficult to see. They do not inspect the request currently approaching your application or decide whether it should be allowed to change an account.

That is the boundary security and fraud teams need to keep clear. A takedown is an ecosystem intervention. A provider label is time-bound intelligence. A request decision is a control in the path of the work being attempted.

The first article in this series compares what the IPIDEA and NetNut actions changed. The second examines why a network can disappear while its former IP inventory remains visible elsewhere. This final article starts after enforcement: when the network has changed, the headlines have moved on, and the application still needs to handle live traffic.

Disruption Changes the Network, Not the Destination's Job

Google's January 2026 IPIDEA disruption combined legal action against control and marketing domains, intelligence sharing, and Google Play Protect enforcement. Google said the action significantly degraded the network and reduced its available device pool by millions. It also warned that reseller agreements created overlap between exit pools and made definitive attribution difficult.

In July, Google took coordinated action against NetNut. Google said it disabled accounts and services used for command and control, shared intelligence, and used Play Protect against applications incorporating known NetNut SDKs. It estimated the network at a minimum of two million devices and reported 316 distinct threat clusters using suspected NetNut exits during one week in June.

Those are Google's findings and estimates, not a claim that every address associated with either provider was malicious. They still show why enforcement deserves support. Reducing compromised supply helps the people whose connections were being used and makes abuse infrastructure more expensive.

The destination's exposure is different. Google also said that operators affected by the earlier IPIDEA disruption began buying capacity from competitors and acting as resellers. A storefront can lose part of its own pool while continuing to sell access sourced elsewhere. Buyers can move as well. Demand, tooling, accounts, target lists, and attack behaviour do not disappear with a control domain.

If your production rule is provider = IPIDEA, the disruption may make that rule less accurate precisely when the incident looks most successful.

Expect Migration Before You Expect Silence

Post-disruption network-layer observations reinforce that warning, but they need careful attribution. Lumen's Black Lotus Labs reported from its own backbone telemetry that IPIDEA lost traffic and victim population after the January action, then rebuilt infrastructure and recovered. The same Black Lotus Labs proxy-ecosystem report describes backend connections and resale relationships across several networks.

That report reflects Lumen's visibility, detection methods, and assessments. It is not a complete census of the internet, and an infrastructure relationship does not prove that every request, exit, or customer belongs to one named operator. Its operational lesson is narrower and useful: supplier and reseller relationships can change faster than a static provider label.

After a disruption, assume four kinds of movement until evidence shows otherwise:

existing exits reconnect through replacement infrastructure;
a provider buys or resells another pool;
customers shift to a different storefront or whitelabel service;
the same operator rotates through new IPs while keeping its browser, credentials, request sequence, and target set.

The defender's task is not to guess the next brand name. It is to keep the intelligence current and preserve enough behavioural continuity to recognise the work after the address changes.

Rebaseline the Intelligence

A disruption date should trigger a data review, not an automatic claim of coverage.

Take a pre-action baseline by route: request volume, proxy prevalence, provider attribution, challenge completion, authentication outcomes, blocks, 429 responses, transaction completion, origin work, analyst review, and support contacts. Then compare the same measures immediately after the action and as the market adapts.

Refresh feeds and internal observations on their own collection cadence. Do not merge a historical provider association into a permanent property of the IP. For each proxy or network result, retain:

observed_at
indicator or network value
provider attribution, if any
attribution source and dataset version
confidence and reason
first_seen and last_seen where available

observed_at matters because a residential address can leave a pool, return to a different subscriber, or appear under another reseller. Confidence matters because “seen as an exit” and “attributed to this provider” are different claims. Provider attribution should be allowed to decay, be superseded, or remain unknown.

This is the provenance contract described in What a Residential Proxy Decision Log Should Contain. Keep the current request, the time-bound observation, the policy revision, the selected action, and the outcome connected. A retrospective feed correction should not silently rewrite what the control knew at decision time.

Correlate the Actor's Work Across IP Rotation

IP rotation is meant to break IP-only memory. Build continuity from the parts of the operation that are harder or more expensive to change together.

Useful correlation keys include:

account, tenant, API credential, session, or target object;
credential reuse and failure outcomes across many accounts;
versioned TLS, HTTP, browser, or device fingerprint cohorts;
route order, timing, retry behaviour, and automation cadence;
checkout, promotion, recovery, or payment-instrument patterns;
request cost and repeated origin or database work.

None of those fields proves identity by itself. A common browser fingerprint can group many legitimate users, and an account can be shared. The value comes from agreement across independent observations and from the route being protected.

Residential Proxy Detection for APIs Without JavaScript applies the same principle to machine traffic: use network and protocol evidence in the request path, then combine it with the API identities and outcomes already available. Do not make browser JavaScript a prerequisite for detecting rotation against an API.

Keep the Action Route-Specific

The takedown does not tell you what to do with a request. Neither does the proxy flag. As A Proxy Flag Is Not a Security Policy explains, the signal should change how much corroboration or friction a request needs, not select one global response.

Use the action that fits the route and the cost of error:

Allow low-risk activity when the session and behaviour are consistent.
Log new or uncertain intelligence while measuring the local population.
Challenge an interactive client when it can provide more evidence and has a safe recovery path.
Rate limit repeated or expensive behaviour across the account, client cohort, route, token, and outcome keys that survive IP rotation.
Step up authentication or transaction verification when the request can transfer account control or value.
Block when evidence is strong, harm is current, and a narrower action cannot protect the route.

Account creation, login, password reset, checkout, and public APIs have different identities and failure modes. Five Routes, Five Residential Proxy Decisions provides a concrete policy split. The important post-disruption change is to tune each contract with current observations rather than adding a site-wide deny rule for yesterday's provider.

Measure Protection and Customer Cost Together

An enforcement event can make a threat-intelligence chart fall without improving an application's outcome. A provider-labelled cohort may shrink because attribution changed. Attackers may reduce request rate, move to a new pool, or switch routes. Legitimate customers may still be caught behind shared networks.

Measure the control where the business feels it:

successful login, recovery, checkout, signup, and API completion;
confirmed abuse, account loss, fraud, scraping, and costly operations;
challenge presentation, completion, failure, and abandonment;
blocks and limits overturned by analysts;
origin work and application cost avoided;
support contacts, time to resolution, and exception volume;
policy changes, rollbacks, and rules past their review date.

Support cost is part of control cost. If a policy creates a queue of customers who cannot recover accounts, the team needs to see that beside the reduction in suspicious requests. Peakhour Residential Proxy Detection keeps the proxy signal in the live web and API decision. Bot Management and Advanced Rate Limiting add behavioural and route-aware controls, while API Security protects machine-facing operations without assuming an interactive browser.

The objective is a measurable change in harmful outcomes without an unacceptable change in legitimate completion.

Questions to Ask a Security or Fraud Vendor

Post-disruption due diligence should test operational evidence, not invite another pool-size claim.

Ask:

Do you retain observed_at, source, dataset or detector version, confidence, and provider-attribution reason separately?
How quickly can a provider label decay or change after infrastructure, reseller, or ownership movement?
Can you show what changed in your coverage after the IPIDEA and NetNut actions, including misses and attribution uncertainty?
Can your controls correlate behaviour across rotating IPs without treating a fingerprint as a person?
Can we set different allow, log, challenge, rate-limit, step-up, and block policies by route and API operation?
Does API detection work in the request path without a JavaScript lookup or a second application call?
Will the decision record show the inputs, policy revision, reason codes, action, and later outcome?
Can we compare security outcomes with customer completion, support cases, analyst overturns, and origin cost?
Who owns an emergency rule, when does it expire, and how quickly can we roll it back?

A credible answer should expose limits. If the vendor cannot distinguish an enforcement event, a provider association, and a request decision, it will be difficult for your team to do so during an incident.

Keep the Boundary Honest

Takedowns are necessary work. They protect consumers and disrupt infrastructure at a scale an individual destination cannot reach. They should continue.

Your application still has to judge the request in front of it.

Refresh the intelligence. Keep its time, source, attribution, and confidence. Follow behaviour across address changes. Apply a route-specific action. Record what happened next, including the customer's cost.

Enforcement can reduce the supply of abusive infrastructure. Only a control on the destination's current request path can protect the account, transaction, or API operation being attempted now.

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.

When Home Devices Become Attack Infrastructure

2026-08-01T12:30:00+10:00

A compromised streaming box under a customer's television is not an endpoint your application team can patch.

It can still send traffic to your login page.

Residential proxy and botnet supply increasingly includes ordinary connected devices: streaming boxes, routers, phones, PCs, projectors, and other hardware that stays online behind a consumer connection. Some owners knowingly share bandwidth. Some accept a vague disclosure inside an app. Others never consent because the device or software was compromised.

The sourcing problem matters to platforms, app stores, vendors, ISPs, and law enforcement. The destination service has a more immediate job. It must decide what the request is allowed to do.

The Exit Looks Like a Customer Network

When third-party traffic leaves through a household device, the destination sees the household's public IP. The address may belong to a well-known Australian ISP. It may have no negative reputation. It may also be shared with legitimate activity from the same home or carrier network.

This is why an IP allow-list, deny-list, or country rule cannot establish who controls the request. The source is real. The relationship between that source and the operator is hidden.

Our earlier article, How Bandwidth Sharing Feeds Residential Proxy Networks, explains the supply chain. The defensive consequence is that trust has to move up from the address to the request, session, route, and behaviour.

Quiet Monetisation Changes the Compromise

In 2025, Palo Alto Networks Unit 42 documented attackers exploiting vulnerable GeoServer instances and deploying a legitimate passive-income application and SDK. The code matched the vendor's official version; the installation and use were unauthorised. Unit 42's proxyware campaign report explains why legitimate binaries can still be part of a compromise.

That payload can be quieter than ransomware or cryptomining. It produces recurring value without making the device's failure obvious. For a destination application, quieter supply means a proxy exit can remain useful for longer.

The FBI's 2025 BADBOX 2.0 alert described Android-based streaming devices, projectors, tablets, digital picture frames, and aftermarket vehicle systems affected before purchase or during setup. The FBI said compromised devices could become part of residential proxy services and botnets used for criminal activity.

These reports do not mean every inexpensive smart device is compromised. They show why household provenance is not a security verdict.

What the Application Can Observe

The destination cannot inspect the television or router. It can observe the work attempted through it:

route and operation;
authentication and account state;
residential proxy and broader IP context;
TLS, HTTP, and browser fingerprint cohorts;
device and session history where available;
request timing and sequence;
credential exposure;
failures, retries, and response-code loops;
application and origin cost.

Several devices may also share the public address. A permanent household ban can punish the subscriber whose device was compromised. Correlate the behaviour using keys that fit the route.

Control the Sensitive Journey

The action should follow what the request can change or consume.

For public cached content, proxy use may need no intervention. For login, count failures across account and client cohorts rather than relying on the exit. For password reset, keep responses consistent and limit repeated recovery attempts. For checkout or account changes, carry the earlier session risk forward and request stronger verification when the consequence rises. For expensive APIs, use identity- and cost-aware budgets.

Peakhour Residential Proxy Detection contributes a live network signal for browser and API traffic. Bot Management combines it with the route, client and behaviour already visible in the request path. The objective is not to identify the appliance. It is to stop relayed traffic from inheriting unconditional trust from the household address.

Platform Enforcement Reduces Supply, Not Every Request

Since August 2019, Google Play has required an app facilitating proxy services to third parties to make proxying its primary, user-facing core purpose. The current Device and Network Abuse policy retains that rule. It gives Google a basis for removing unrelated apps that hide proxy functionality, regardless of whether an SDK vendor describes enrolment as consensual.

That policy can reduce deceptive supply. Device takedowns and legal action can disrupt infrastructure. Google's IPIDEA operation combined legal action, platform enforcement, and industry coordination.

Application controls are still required. Existing exits do not disappear at once, private pools remain, and new supply can emerge before datasets identify it.

The 2026 actions against IPIDEA and NetNut show both sides of that boundary. Our takedown comparison covers the upstream disruption; the follow-up on surviving proxy IP inventory explains why an address seen after a takedown does not, by itself, identify the device or supplier behind it.

Preserve Evidence Without Blaming the Customer

When an event is challenged or blocked, record the route, proxy and network evidence, client cohort, account or token context, policy revision, selected action, and outcome. Avoid language that says the household owner attacked the service. The evidence usually supports a narrower statement: traffic reached the application through this connection and matched this behaviour.

That distinction matters for support, fraud review, and incident response. The subscriber may be a victim too.

Application teams cannot repair every compromised box on the internet. They can refuse to let a residential address stand in for identity, intent, or permission.

Residential Proxies Turn Layer 7 DDoS Into a Route Problem

2026-08-01T12:20:00+10:00

Not every Layer 7 DDoS attack looks large at the edge.

A residential proxy pool can spread requests across thousands of consumer addresses. Each exit sends a modest amount of traffic. Per-IP limits stay quiet. Aggregate bandwidth may look manageable. The application still falls over because the requests concentrate on work that is expensive to perform.

Search, login, checkout, GraphQL, report generation, uncached rendering, and API aggregation can fail long before the network link is full. Residential distribution turns the incident into a route and resource problem.

Count the Work, Not Just the Requests

Two HTTP requests can have radically different cost.

A cached image may be served at the edge with no origin work. A search request may query several indexes. A login can invoke password hashing, credential checks, session state, and downstream identity services. A GraphQL operation can expand into many resolvers. An export can hold database and worker capacity for seconds or minutes.

Cloudflare's explanation of application-layer DDoS attacks describes the core distinction: Layer 7 attacks target the application work involved in processing apparently legitimate requests.

Map the routes before an incident:

which requests are cacheable;
which invoke database, search, identity, payment, or third-party dependencies;
which hold workers, connections, queues, or memory;
which can be assigned a cost class;
which business journeys must remain available under pressure.

Requests per second is still useful. It is not the complete capacity model.

IP Limits See the Distribution, Not the Campaign

A per-IP limit catches simple floods and protects against one noisy client. Keep it as one layer.

Residential proxies are designed to distribute source addresses. A campaign can remain below an IP threshold while one fingerprint cohort, route sequence, query shape, account pattern, or operation class grows rapidly across the fleet.

Useful aggregate keys include:

route + fingerprint cohort
operation + query cost class
login route + account + failed outcome
tenant + API credential + expensive operation
route + proxy state + response outcome

No key is universally safe. A common browser or mobile SDK can create a large legitimate cohort. Observe bucket sizes and successful outcomes before using a grouping key for enforcement.

Proxy Detection Changes Confidence

A residential proxy result does not prove DDoS. It changes how the request is interpreted when other evidence agrees.

For example:

a new residential exit fetching one cached page adds little risk;
many exits sharing a narrow client cohort and repeatedly missing cache on an expensive route add more;
the same pattern causing queue growth, timeouts, and origin errors supports immediate mitigation.

Google's IPIDEA investigation showed how large and commercially interconnected a residential exit pool can become. Application defenders should assume source diversity is purchasable.

Peakhour DDoS Protection combines anomaly detection, route-aware rate limits, bot and WAAP context, cache policy, and origin protection in one request path. RESIP contributes a signal; the action comes from the route, behaviour, and current service pressure.

Preserve a Clean Path

Emergency mitigation often fails by protecting the server from everyone.

Decide in advance which journeys need to survive:

existing authenticated sessions;
account recovery;
checkout or payment confirmation;
status and support information;
partner or operational APIs;
cacheable public content.

Controls can then narrow around the attacked resource. Serve cacheable responses at the edge. Reduce budgets for costly anonymous operations. Apply stricter limits to repeated failures. Challenge interactive browsers where there is a recovery path. Preserve authenticated or known-good traffic when the evidence supports it.

Challenges do not solve every flood. Browser automation can complete them, and challenge generation can itself consume capacity. Machine-to-machine APIs need protocol-appropriate responses. RFC 6585 defines HTTP 429 Too Many Requests and the optional Retry-After header, but clients and operators still need to prevent retries from amplifying pressure.

Watch the Origin Outcome

Mitigation evidence should connect the request to what happened behind it:

cache hit or miss;
origin request avoided;
application latency and response status;
queue, worker, connection, and dependency pressure;
rate-limit, challenge, or block action;
successful user journey completion;
policy revision and activation time.

A rising block count only describes the control. Protection is visible when essential routes remain available, origin pressure falls, and legitimate completion stays within an acceptable range.

Rehearse the Policy Before the Flood

During an incident, teams reach for the keys they already have. If every counter is bound to source IP, residential distribution will force a broad emergency rule.

Choose one expensive route now. Measure normal cost and cohort sizes. Add observation counters for route, identity, fingerprint, proxy state, and outcome. Define the threshold that indicates resource pressure, the first reversible action, the owner, and the rollback condition.

For the first rehearsal, one expensive route is enough. If the team can describe its normal cost, see distributed pressure, apply a bounded action, and preserve legitimate completion, it has a mitigation pattern worth extending. An address ban on its own does not provide that pattern.

Five Routes, Five Residential Proxy Decisions

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

Account creation and password reset may sit under the same /account/ prefix. They are not the same security decision. One creates a new identity; the other can transfer control of an existing one.

The same problem appears when a team applies one residential-proxy action across login, checkout, and public APIs. Low-risk traffic is rejected, shared networks create support cases, and the attacker moves to an unlabelled exit or another route.

Policy has to begin with what each request can do. These five routes have different identities, costs, recovery paths, and abuse patterns, so the proxy result changes each one differently.

1. Account Creation

Signup abuse creates fake accounts for promotion fraud, spam, inventory reservation, scraping, or later account farming. A residential proxy helps the operator distribute registrations and make geography look ordinary.

Useful evidence includes:

registrations across a shared device or fingerprint cohort;
repeated email, phone, payment, referral, or promotion patterns;
verification completion and time to complete;
route sequence before and after signup;
residential proxy and network context;
account creation velocity across IPs and client cohorts.

A first-seen proxy result may only justify logging. Proxy use combined with repeated device evidence and failed verification can justify a shared limit or stronger verification. Preserve legitimate households and mobile networks by avoiding one-account-per-IP assumptions.

2. Login

Login protection has to handle password mistakes, credential stuffing, password spraying, and targeted account takeover without turning the attack into an account lockout service.

The OWASP Credential Stuffing Prevention Cheat Sheet recommends layered controls including MFA, breached-password checks, connection and device fingerprinting, and defence in depth.

For a residential proxy login, look at:

exposed credential state;
failures against this account across all IPs;
accounts attempted by this client cohort;
familiar device and session history;
normal or abnormal route sequence;
success, failure, MFA, and challenge outcomes.

One failure from a new address is weak evidence. Distributed failures across many accounts with a shared cohort are stronger. Rate limit the behaviour, not merely the exit.

3. Password Reset

Password reset is both a recovery mechanism and a route to account control. It also leaks information if response behaviour reveals whether an account exists.

OWASP's Forgot Password Cheat Sheet recommends consistent messages and response timing, side-channel delivery, rate limiting, and protection against excessive reset requests.

Residential proxy use should raise attention when it appears with account enumeration, repeated reset initiation, token guessing, or a new client followed by recovery-factor changes.

The action may be a tighter account-and-cohort limit, delayed processing, step-up verification, or a user notification. A broad IP block can stop legitimate recovery for every person sharing the exit.

4. Checkout and Stored Value

Checkout risk is not limited to card testing. Automated clients can reserve scarce inventory, abuse promotions, drain loyalty balances, test stored payment instruments, or change shipping details after account takeover.

Connect the network signal to the transaction:

established account and device history;
payment, address, basket, and promotion changes;
velocity across accounts and instruments;
prior login or recovery risk in the same session;
repeated declines and response patterns;
inventory or application cost created by the request.

A proxy signal on a normal repeat purchase may add little. The same signal after a breached-credential login and recovery-email change should carry more weight. Step-up verification or a bounded transaction hold can be safer than a network-wide deny.

5. Public and Partner APIs

APIs often lack browser JavaScript and interactive challenge support. They may also expose expensive search, export, GraphQL, or object-access operations.

Use the identities the API already has: tenant, token, API key, client certificate, object, operation, and schema outcome. Add network and fingerprint cohorts where they help group rotation.

The OWASP API Security Top 10 calls out unrestricted resource consumption and unrestricted access to sensitive business flows. Residential proxy rotation can distribute both. Route-aware limits should account for operation cost rather than applying one requests-per-minute value to the whole API.

Machine clients cannot complete a browser challenge. A predictable 429, reduced operation budget, token step-up, or deny response may be the correct protocol action.

One Signal, Five Policies

Peakhour Residential Proxy Detection feeds proxy evidence into the request decision with IP, credentials, device, behaviour, and route context. Advanced Rate Limiting can count using route, ASN, country, IP, TLS fingerprint, response code, and other request attributes.

That allows each route to have its own contract:

Route	Primary concern	Useful action
Account creation	Scaled fake accounts	Verify and limit across client cohorts
Login	Credential reuse and spraying	Count failures across account and cohort
Password reset	Enumeration and account recovery abuse	Consistent responses, account limits, step-up
Checkout	Fraud and stored-value loss	Transaction-aware verification or hold
API	Resource and business-flow abuse	Identity- and cost-aware limits

Run new policies in monitor mode first. Record proxy prevalence, actions, successful completion, false positives, challenge outcomes, and origin cost. Move to enforcement by route, with an owner and rollback condition.

The implementation work is to give each route an explicit contract, then verify that its action protects the journey it was written for. A shared proxy result can feed all five contracts without forcing all five routes into the same response.

Privacy Relay, Corporate VPN, or Residential Proxy?

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

An application sees a login from an address that does not match the user's apparent location. The connection belongs to a relay, VPN, or proxy network.

That is a reason to look closer. It is not a reason to call the user malicious.

Privacy relays, corporate VPNs, consumer VPNs, carrier-grade NAT, and residential proxies all weaken the old assumption that an IP address describes one person in one place. They do it for different reasons and with different operating models. A security policy that reduces them to anonymous=true will either miss abuse or punish legitimate users.

Privacy Services Deliberately Separate Identity from Destination

Apple says iCloud Private Relay uses separate internet relays so no single party can see both who a user is and which sites they visit. It also lets the user preserve a general location or use a broader country-and-time-zone location. Apple's Private Relay overview explains the scope and the role of the relay addresses.

That design changes what a website can infer from the source IP. It does not remove the session, account, route, browser, or request behaviour available to the application.

A corporate VPN creates a different pattern. Many employees may exit through a small set of company gateways. The source can be stable and organisation-owned, but the address still represents a population rather than one device. A consumer VPN may rotate gateways and mix unrelated subscribers. Carrier-grade NAT can make a normal mobile or broadband address shared even when no privacy product is involved; RFC 6598 documents shared address space reserved for carrier deployments.

Residential proxy services are different again. A remote operator deliberately routes through consumer or ISP connectivity so the destination sees the household exit. Mobile proxy services use the same broad model through carrier connectivity, but should remain separately labelled because their sharing and attribution conditions differ. Either form of supply may come from an informed participant, an embedded SDK, compromised software or another path.

The network categories matter. They still do not establish intent.

Define the Expected Population

Policy should reflect the application and route.

A workforce portal may know its corporate VPN ranges and require device or certificate evidence. A consumer service should expect mobile networks, privacy relays, travel, and shared households. A country-restricted service may need stronger location verification than an online catalogue. An API used by fixed partners can enforce network expectations that would be unreasonable on a public login page.

Ask:

Is this network type expected for this user population?
Is the route public, authenticated, sensitive, or expensive?
Does the account have established device and session history?
Is the apparent location material to the transaction?
Can the client provide another form of evidence?
What does a false rejection cost?

The answer determines whether the network signal should be ignored, logged, challenged, or combined with stronger controls.

Use Context to Separate Risk from Privacy

Peakhour IP Intelligence and Residential Proxy Detection place network context beside credentials, device history, fingerprints, behaviour, route, and recent events.

Consider two logins through privacy infrastructure.

The first uses an established session, familiar device history, a normal route sequence, and one successful authentication. The second attempts many accounts, carries an exposed credential, has no normal session history, and repeats the same failure pattern across rotating addresses.

Both hide or replace the direct source address. Only one presents a strong account-abuse pattern.

The policy should be able to express that difference. Blocking every relay or VPN is not contextual security. It is a network-category ban.

Geography Needs the Same Restraint

IP geolocation is an estimate of network presence, not proof of a person's physical location. VPN gateways, relays, mobile routing, satellite networks, corporate egress, and proxy exits can all separate the address from the user.

Use geography as evidence proportionate to the decision. A content preference may tolerate a coarse estimate. A regulated transaction may require account evidence, verified identity, payment context, or an explicit location control beyond an IP lookup.

Avoid impossible-travel rules that treat every IP change as physical movement. A session can switch between mobile, Wi-Fi, VPN, and relay paths without the person travelling at all. Look for continuity in the account, device, session, and behaviour before escalating.

Choose an Action That Can Be Recovered From

The action can then scale with the evidence:

Allow expected privacy or corporate access with consistent session evidence.
Log an unfamiliar network category on low-consequence routes.
Apply tighter rate limits when repeated behaviour spans accounts or rotating exits.
Challenge an interactive client when network change appears beside account risk.
Require step-up verification for recovery, payment, or access-control changes.
Block confirmed automated abuse with bounded route and policy scope.

Challenges are not perfect humanity tests. Automation can complete them, while privacy tools, accessibility software, or broken browser environments can cause legitimate failures. Measure completion and provide a recovery path.

Retain the Reason

When a policy acts, retain the network category, source, route, contributing evidence, action, and outcome. “Anonymous IP” is too vague for support or incident review.

The record should show whether the deciding factor was proxy use, an exposed credential, failure velocity, a new device, a route sequence, or several observations agreeing. That evidence lets the team tune the control without adding broad exceptions that erase protection.

Privacy and security are not opposing verdicts attached to an address. They are requirements the application has to handle at the same time.

What a Residential Proxy Decision Log Should Contain

2026-08-01T11:50:00+10:00

A log line that says proxy=true is intelligence. It is not a decision record.

When a customer asks why a login was challenged, a fraud analyst reviews an account event, or an engineer tunes a rate limit, the team needs to reconstruct what the control knew and what it did. A timestamp, IP address, and final risk score cannot answer that on their own.

Peakhour Residential Proxy Detection keeps the proxy result inside the request decision with IP, credential, device, behaviour, and route context. The record should preserve that connection without becoming an indiscriminate collection of personal data.

Record the Request Being Judged

The event comes first. The detector explains one part of it.

Useful request fields include:

observed_at
request_id and trace_id
service, host and route class
HTTP method
response status
account, tenant, session or API-key reference where permitted
edge location and origin target
cache outcome and whether origin was reached

Avoid logging secrets, complete session tokens, passwords, payment data, or unrestricted request bodies. The OWASP Logging Cheat Sheet recommends excluding or masking access tokens, authentication passwords, sensitive personal data, and other values whose collection creates more risk than operational value.

Use stable references where the investigation needs continuity, and keep their purpose and retention bounded.

Keep Signal Provenance

The value of a signal depends on how it was produced.

For proxy and network evidence, retain:

proxy_result and category
detector or feed name
detector version or dataset time
network type, ASN and country
client IP source and trusted forwarding hop
fingerprint method, version and capture point
browser or device evidence source

A fingerprint without a method and capture point cannot be compared safely. A country value without a source and observation time is difficult to audit after data changes. A forwarded IP taken from an untrusted header should never have reached policy in the first place.

Flattening every input into one number leaves the analyst with a threshold and no explanation. Retain the factors that moved the score.

Record the Policy and the Action

The event should identify the control that made the decision:

policy_id and revision
policy owner
mode: monitor or enforce
matched conditions
threshold and current counter state
selected action
action reason code
expiry or review date

Reason codes should be stable enough to aggregate. Free-text analyst notes can add context, but they should not be the only explanation.

The action field needs more detail than blocked=true. Distinguish allow, log, challenge, rate limit, deny, route, and step-up outcomes. For a limit, keep the key class and interval without exposing sensitive raw values. For a challenge, record whether it was presented, completed, failed, expired, or abandoned.

Connect the Decision to Its Outcome

Security controls are judged by what happened next.

Join the decision to:

successful login, signup, reset, checkout, or API completion;
authentication failure and account lockout;
challenge completion and abandonment;
429, deny, or step-up response;
origin request avoided or origin work created;
support case, analyst disposition, or confirmed incident where available;
policy rollback or exception.

This is how a team distinguishes attack reduction from customer suppression. If challenges rise and successful account recovery falls, the proxy policy may be adding friction in the wrong place.

NIST SP 800-92, the Guide to Computer Security Log Management, treats log management as a lifecycle of generating, transmitting, storing, analysing, and disposing of data. That lifecycle matters here. A detailed event that nobody can query, retain safely, or delete on schedule is not operational evidence.

Metrics Should Lead to a Decision

For an enforcement platform, useful measures should connect signals to route outcomes:

proxy prevalence by route and action;
percentage of proxy-labelled traffic allowed, challenged, limited, and blocked;
challenge completion for proxy and non-proxy cohorts;
legitimate transaction completion after action;
confirmed abuse caught with and without a proxy signal;
false-positive and analyst-overturn rates;
origin requests and application cost avoided;
time from observation to policy change;
rules past their review date.

A count of “risky sessions detected” is hard to act on. A rise in residential-proxy password-reset attempts with low challenge completion and repeated account failures can justify a route-specific change.

A Minimal Event

A compact decision record might resemble:

{
  "request_id": "req_...",
  "route_class": "account_recovery",
  "proxy": {"result": true, "category": "residential", "source": "resip"},
  "fingerprint": {"method": "ja4", "version": "pinned", "capture": "client_edge"},
  "credential_state": "exposed_match",
  "recent_outcome": "repeated_failure",
  "policy": {"id": "recovery-risk", "revision": 7, "mode": "enforce"},
  "action": "step_up",
  "reason_codes": ["residential_proxy", "exposed_credential", "failure_velocity"],
  "outcome": "pending"
}

The exact schema will differ by application. The contract should not: current request, signal provenance, policy revision, selected action, and measurable outcome.

The schema is ready when a support engineer can explain a challenge, an analyst can reconstruct an account event, and the policy owner can measure the result without opening a second system. Anything collected beyond that needs a stated security purpose and retention period.

Keep Your CDN. Add Proxy and Bot Decisions at the Edge.

2026-08-01T11:40:00+10:00

Security projects often begin with a false choice: replace the current CDN or accept the controls it already provides.

Real environments are messier. A business may have a long-term CDN contract, cloud-specific routing, established cache rules, a migration freeze, or applications that cannot all move together. The security problem still exists. Residential proxy traffic, credential stuffing, scraping, API abuse, and Layer 7 floods do not wait for a platform consolidation programme.

Peakhour Bring Your Own Edge supports two first-class paths: Peakhour Edge can be the delivery layer, or Peakhour intelligence can operate alongside the edge provider already in place. The product value is not the diagram. It is retaining one decision model for request context, policy, action, and evidence in either deployment.

Decide Where the Authoritative Observation Happens

An application behind a CDN sees a connection from the CDN, not necessarily the original client-facing connection. That affects IP provenance, TLS fingerprints, geography, and rate counters.

Before adding another control, map the path:

client → existing edge → Peakhour decision point → origin

or:

client → Peakhour Edge → origin

For every field used by policy, record where it was observed and who is allowed to set it. Client-supplied copies of forwarding or fingerprint headers must be removed at the trusted boundary. The authoritative edge can then set the value passed downstream.

This is not bookkeeping. A rate limit built on a spoofable forwarded address is a client-controlled rate limit. A TLS fingerprint calculated at origin may describe the intermediary rather than the browser. Provenance determines whether the signal can safely change an action.

Keep Policy Close to the Consequence

A decision point earns its place only if it can still protect the route. It needs to prevent avoidable origin work, slow repeated behaviour, challenge an interactive browser, block a confirmed attack, or preserve a clean path during a flood.

Peakhour combines IP intelligence, residential proxy detection, fingerprints, credentials, route behaviour, bot state, rate thresholds, and WAAP findings in that request path. The action can be allow, log, challenge, rate limit, or block. The existing CDN can remain responsible for the delivery work it already does well.

This matters because enrichment without enforcement creates a timing and ownership gap. A lookup result delivered after the application has rendered a page, queried a database, or changed account state may still help an investigation. It did not protect that request.

Network intelligence is useful on account creation, login, and password-reset routes when the signal remains connected to the request. Peakhour carries that context through to route-specific action and retains the outcome.

Migrate a Decision, Not the Whole Estate

A staged deployment can begin with one abused route:

Observe the request at the trusted boundary.
Forward or derive the fields required by the policy.
Run the new decision in monitor mode.
Compare it with current CDN and origin outcomes.
Apply one reversible action.
Expand only after false positives and operational ownership are understood.

Login, account creation, search, scraping targets, and expensive API operations are good candidates because their behaviour is measurable and their business consequence is clear.

Duplicating every rule in two systems is not a migration strategy. Decide which layer owns each action, how conflicts are resolved, and which record is authoritative. A request should not be challenged twice because two providers reached the same conclusion independently.

Preserve Cache and Origin Context

Bot and proxy decisions affect more than authentication. Scrapers and Layer 7 floods consume cache, transformation, application, and origin capacity.

A useful decision record can include:

cache status and whether the request reached origin;
route and request cost class;
proxy, IP, fingerprint, credential, and bot evidence;
rate-limit state and selected action;
response status and origin health;
policy revision and enforcement point.

That joined record shows whether a control actually protected capacity. Blocking more requests is not inherently better. Serving clean cache hits while throttling expensive automated misses may produce a stronger outcome than a broad deny rule.

Make the Trust Boundary Explainable

NIST's Zero Trust Architecture frames access around explicit resource decisions rather than implicit trust in network location. The same discipline helps at an application edge: evaluate the request from current evidence, enforce a resource-specific policy, and retain enough information to explain the decision.

An existing CDN is not an obstacle to that model. An undefined trust boundary is.

Use the delivery reality you have. Identify the client-facing observation point, choose the routes where better context can change an outcome, and assign policy ownership. Move delivery layers when the operational case supports it—not because a security feature forced an all-or-nothing migration.

Credential Stuffing Through “Clean” Residential IPs

2026-08-01T11:30:00+10:00

The login came from an Australian consumer ISP. The address had no bad reputation and submitted one password. Viewed alone, the request barely deserved a second look.

Across the account population, the same client pattern was trying credentials against one user after another while the source addresses changed. Residential proxy networks make that distribution cheap: each exit stays below a simple threshold, the geography looks plausible, and the campaign moves before an address develops a history.

That is what the operator is buying when an exit is sold as “clean”: borrowed trust from the network and the people who normally use it. The application has to find continuity somewhere other than the address.

The Credential Is Only the Start

The OWASP Credential Stuffing Prevention Cheat Sheet recommends layered defences because no single control reliably separates every legitimate login from automated reuse. MFA, breached-password checks, device and connection signals, rate limits, and user notifications address different parts of the problem.

At the edge, the request already carries several useful facts:

the login route and response outcome;
the account or username being attempted;
whether the credential is known to be exposed;
residential proxy and broader IP context;
network and browser fingerprint cohorts;
device and session history where available;
recent attempts against this account and from this client pattern;
what the client does before and after the login request.

Peakhour Breached Credential Scanning scores credential exposure beside proxy use, IP reputation, device history, behaviour, and login context. A breached match is not an automatic conviction. People reuse exposed passwords without knowing it. The match becomes urgent when it appears inside an active attack pattern.

Count Across More Than the Address

An IP-only login limit still protects against crude repetition. It sees one slice of the campaign.

Credential stuffing needs counters that see both sides of the distribution:

per account:     failed logins across all network sources
per cohort:      failed logins across rotating IPs
per credential:  exposed match plus repeated failure or success
per campaign:    shared route, timing and client shape across accounts

These counters answer different questions. A per-account limit protects one user even when every attempt comes from a new address. A fingerprint-cohort limit exposes a tool working through many accounts. A breached-credential match raises the cost of accepting an otherwise ordinary-looking login.

Avoid permanent lockouts based only on attack traffic. They can be turned into a denial-of-service mechanism against known users. Throttling, temporary holds, step-up verification, and user alerts usually offer safer recovery paths.

Watch the Whole Account Journey

Stopping at the login form creates a blind spot. A successful credential-stuffing attempt may move immediately to:

token issue and refresh;
email or phone change;
password reset and MFA recovery;
stored payment, wallet, loyalty, or gift-card access;
address changes and checkout;
creation of new API credentials or trusted devices.

Our article Credential Stuffing Does Not Stop at the Login Form covers those post-authentication routes. The important operational point is continuity: the same risk evidence should remain available when the session reaches a high-consequence action.

A login accepted after a breached-credential match and residential proxy signal may still be allowed, but the session should not become fully trusted merely because the password worked. A recovery-email change or stored-value transfer can require stronger evidence.

“Clean” Is a Property of the Dataset

Security teams often say an IP is clean when it is absent from known abuse and proxy lists. That is a statement about current knowledge, not the connection's owner or purpose.

Google's 2026 IPIDEA disruption report described millions of devices being removed from an available proxy pool and many tracked threat groups using the exits. Google also found multiple SDK brands and reseller relationships connected to shared infrastructure.

The lesson is not that every unlabelled residential address is hostile. It is that a negative lookup cannot carry the decision. Freshness, private supply, reseller overlap, and device churn create a period in which the request arrives before the label.

Peakhour's Residential Proxy Detection evaluates the live request and places the result inside the wider account decision. Browser evidence can add context, while login APIs still receive network, credential, route, rate, and outcome controls without depending on JavaScript.

Apply Friction Where the Consequence Changes

For login and account routes, policy might respond like this:

Allow a familiar session with no adverse credential or behaviour evidence.
Log a residential proxy result on a low-risk or first-seen login.
Rate limit distributed failures across the account and client cohort.
Challenge when proxy use, an exposed credential, and unusual device or route behaviour agree.
Require step-up verification for recovery, payment, or account-control changes.
Block a confirmed automated campaign with bounded route and policy scope.

Measure successful login and recovery completion beside attack reduction. A control that suppresses failures by preventing real customers from signing in is not a successful account-protection policy.

Treat “clean” as a statement about the dataset at that moment. Make the account decision from the credential, client, route, and recent outcomes that arrived with the address.

The IP Changed. Did the Actor?

2026-08-01T11:20:00+10:00

An attacker can change an IP address faster than most teams can change a rule.

Residential proxy services make that rotation routine. A client can send one request through a household connection in Sydney, the next through a mobile network in Melbourne, and another through an address that has never appeared in a reputation feed. An IP-only counter sees three quiet sources. The application may still be dealing with one operator and one campaign.

The tempting response is to find a replacement identifier. There is no universal one.

Network fingerprints, browser attributes, cookies, accounts, API keys, timing, and route sequences can all help correlate requests. Each can also be shared, copied, cleared, or changed. The practical goal is not to prove a person. It is to keep enough continuity to control a specific behaviour.

Ask What Stayed the Same

When addresses rotate, look for continuity in the work being attempted:

the same account or set of accounts;
a repeated username or credential corpus;
one API token, tenant, or application identifier;
a stable TLS or HTTP fingerprint cohort;
the same route sequence and parameter shape;
similar timing, retries, and failure outcomes;
a narrow set of ASNs, countries, or network categories;
consistent application cost or object enumeration.

One field may be weak. Several observations agreeing can support a bounded action.

Google's IPIDEA investigation described shared residential proxy infrastructure supplied through multiple SDK brands and reseller arrangements. That is useful context for defenders: provider names and exit addresses can change while the commercial path behind them remains connected.

Fingerprints Group Clients; They Do Not Name Them

A TLS fingerprint can reveal that connections share a normalised handshake shape. It cannot establish that they came from the same person, device, or process.

This distinction matters because popular browsers create large cohorts. Attack tools can also imitate common handshakes. Our article A Network Fingerprint Is a Cohort, Not a Client covers the boundary in detail.

Use a versioned fingerprint as one grouping key:

method + version + value + capture point

Then join it to the route and outcome. A common fingerprint that submits one successful login is uninteresting. The same cohort trying passwords against thousands of accounts through rotating residential networks is operationally useful.

Fingerprint provenance matters as much here as it does in API protection. At an origin behind a CDN, the visible connection may be the CDN hop. Only compare values captured at equivalent, trusted points.

Build Counters Around the Abuse

Peakhour Advanced Rate Limiting can use route, headers, ASN, country, IP, TLS fingerprint, response code, and bot state as concrete inputs. The right key depends on what needs protection.

For credential stuffing:

account + failed outcome
fingerprint cohort + login route + failed outcome

For scraping:

fingerprint cohort + resource family
API credential + operation + cost class

For account creation:

device cohort + signup route + verification outcome

Use more than one counter when the abuse can move between dimensions. A per-account limit protects one user. A cohort-wide limit sees distribution across accounts. A per-IP limit still catches crude bursts. No single key has to solve the campaign.

Avoid the opposite error: a key so broad that it turns a shared mobile SDK or current browser release into one actor. Before enforcement, inspect bucket sizes and successful outcomes. If one cohort contains a material part of normal traffic, it is an observation key, not a direct blocking key.

Route Sequence Can Carry Continuity

Automation often performs the same steps even when its network changes.

A normal account session might load a page, obtain a token, submit one credential, establish a session, and continue to an expected destination. A distributed credential campaign may call the login endpoint directly, repeat a narrow header set, receive the same failure, change the account, and start again.

The individual requests are small. The sequence exposes the job.

Keep this evidence purpose-bound. A security control does not need to build a permanent profile of a person. It needs enough recent history to decide whether a sensitive route is being used as intended. Our Account Security Without Tracking People explains that privacy boundary.

Expect the Actor to Adapt

Once a counter begins to work, the traffic will change. The operator may randomise headers, switch browser versions, slow the cadence, distribute accounts across more cohorts, or move to another route.

That does not make the original control a failure. It means the campaign has paid an adaptation cost. Keep the decision record so the next change is visible:

policy revision and activation time;
key dimensions and thresholds;
allowed, limited, challenged, and blocked counts;
successful business outcomes;
origin and application cost;
new cohorts and routes after enforcement.

Set an expiry or review date. Fingerprint populations and browser versions drift. Emergency rules should not survive their evidence by default.

Continuity Is a Working Hypothesis

The honest question is not “did we identify the actor?” It is “do these requests share enough evidence that one control should count them together?”

That wording leaves room for uncertainty. It also produces a policy an operator can test.

Start with one abused route. Compare IP-only counters with a small number of composite candidates. Observe bucket size, legitimate completion, failed outcomes, and origin cost. Apply a reversible action to the key that separates the behaviour without turning a common client cohort into collateral damage.

The IP will change. A well-built control follows the work, not the address.

Residential Proxy Detection for APIs Without JavaScript

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

A mobile application posts directly to a login API. No page is rendered and no browser script runs. The route still needs to recognise residential proxy use and repeated automation before it accepts a credential or creates expensive origin work.

The same constraint applies to partner integrations, backend services, command-line clients, and machine-to-machine workloads. A detection that begins only after a client-side collector runs leaves those routes with a thinner control.

Peakhour Residential Proxy Detection evaluates the request without making JavaScript a precondition. When a browser is present, browser and device evidence can strengthen the decision. When it is not, the control still has network, protocol, identity, route, rate, and outcome context to work with.

The Route Sets the Policy

An API is not one security surface. A public product query, a login mutation, a password-reset endpoint, a payment instruction, and an administrative export have different costs and different identities.

The OWASP API Security Top 10 separates risks such as broken object authorisation, unrestricted resource consumption, sensitive business flows, and inventory failures because the route's purpose matters. Proxy use does not remove that context. It makes route-aware controls more important.

Before deciding how to use a proxy result, document:

the operation and its business consequence;
whether it is authenticated;
the account, tenant, token, API key, or object identity available;
expected request and response shapes;
the application work created by one call;
normal error and retry behaviour;
whether the client is interactive or machine-to-machine.

A residential exit calling a public, cacheable endpoint may be ordinary. The same exit cycling through reset tokens or forcing expensive GraphQL operations deserves a different response.

What the Server Can Observe

Server-side proxy and automation decisions can use several evidence classes.

Network context

IP intelligence can describe the ASN, network type, geography, known proxy use, hosting status, and recent reputation. These fields are useful, but none proves the original operator's location or intent.

Protocol fingerprints

TLS and HTTP characteristics can group connections that use similar client stacks. JA4 publishes both canonical and raw representations; the JA4 technical specification documents what is selected and normalised. Cisco Mercury's Network Protocol Fingerprint specification provides a structured, versioned representation of protocol observations.

These are cohort keys, not identities. A common mobile SDK may place many legitimate clients in one cohort. An automation framework can copy a popular handshake. The value appears when the fingerprint is combined with the route, identity, outcomes, and recent behaviour.

API identity and state

An API often has stronger keys than an IP address: account, token, tenant, client certificate, API key, device registration, or object identifier. A limit can follow failed behaviour across rotating addresses when one of those keys remains stable.

Request behaviour

Useful patterns include invalid route order, enumeration across objects, repeated authentication failures, token refresh without normal session history, schema deviations, abnormal response-code loops, and requests that create unusual application cost.

Capture Point Matters

Network evidence is only meaningful when its provenance is known.

If an application sits behind a CDN or reverse proxy, the TLS connection visible at origin may belong to that intermediary. A fingerprint calculated there may describe the CDN-to-origin hop, not the client. A forwarded header can carry the client-facing value, but only if the boundary strips untrusted copies, sets the authoritative field, and records the collector and version.

Keep fields such as:

capture:      client-facing edge
method:       ja4
version:      pinned implementation
value:        versioned fingerprint value
source:       trusted edge collector
observed_at:  timestamp

Without that provenance, two equal hashes may describe different capture points. The policy cannot safely compare them.

Use Composite Limits

An IP-only limit is easy to distribute around. A single global fingerprint limit can be just as dangerous because it may group a large legitimate population.

Build the key for the route:

login: fingerprint + account + failed outcome
API:   fingerprint + tenant + operation
reset: account + route + proxy state
query: API credential + cost class

Use only the fields that preserve the behaviour you are trying to count. Too few fields mix unrelated users. Too many divide the campaign into invisible buckets.

When a limit is reached, return a predictable response. RFC 6585 defines HTTP 429 for too many requests and permits a Retry-After header. That does not solve abuse by itself, but it gives legitimate clients a protocol they can handle and gives operators a clear outcome to measure.

JavaScript Is Additional Evidence

A browser that runs JavaScript is not necessarily human. Automation can execute scripts, preserve cookies, complete challenges, and reproduce browser behaviour. Conversely, privacy tools, accessibility software, content blockers, and broken client environments can interfere with collection.

Browser evidence can improve the request decision. Its presence is not proof of legitimacy, and its absence is not proof of abuse.

For Peakhour, the core decision can run for direct API traffic. Optional browser signals add context on interactive routes. Both feed the same action model: allow, log, challenge where appropriate, rate limit, or block, with the reason retained.

Deploy One Route First

Choose one API route with a known abuse problem. Record proxy state, network category, fingerprint method and capture point, API identity, request outcome, response code, and application cost. Observe enough traffic to understand normal clients and shared cohorts.

Then add one reversible policy. For example, rate limit failed logins across account + fingerprint when residential proxy use and abnormal failure velocity occur together. Track successful logins, false positives, 429 responses, origin load, and support cases before expanding it.

This first policy should leave the team with a clear comparison: what the API saw before the new evidence, which requests received a different action, and whether legitimate completion or origin load changed. That result is more useful than trying to recreate a browser check around every API call.

A Proxy Flag Is Not a Security Policy

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

At Peakhour, a residential proxy match changes how much trust we place in a request. It never selects the action on its own.

The match tells us that the network presenting the traffic may not be where the operator is sitting. Whether that matters depends on what the request is trying to do, what else is known about the client, and the cost of getting the action wrong. Treating a proxy label as policy collapses those questions into one bit. The rule becomes easy to configure and hard to operate.

Residential proxy detection therefore sits inside the live request decision beside IP reputation, credentials, device history, network fingerprints, behaviour, route sensitivity, and recent outcomes. It changes the level of evidence we require.

The Same Signal Means Different Things on Different Routes

Consider three requests from the same residential proxy exit:

A visitor opens a cached product page.
A client tries one password against 200 accounts.
An authenticated user changes the recovery email on a high-value account.

The network fact is identical. The consequences are not.

The first request may need no action beyond logging. The second has a pattern consistent with credential stuffing and needs a shared limit or block. The third may justify step-up verification because the action can transfer control of an account. A site-wide proxy deny rule misses those distinctions.

This is also why a global risk score can be frustrating in production. A score can help rank events, but the operator still needs to know what raised it and which action is proportionate. Peakhour's concern is where that context meets enforcement: on the request path, before origin work and account state changes occur.

Residential Does Not Mean One Person

Public IP addresses are weak identity keys even when no proxy is involved. Carrier-grade NAT allows many subscribers to share address space; RFC 6598 reserves a shared range specifically for that purpose. Households, offices, mobile networks, privacy services, and public Wi-Fi also put unrelated users behind common addresses.

A residential proxy complicates the picture further. The address belongs to a real consumer network, but the request may have originated elsewhere. A clean reputation may mean the exit is new. A poor reputation may reflect one abusive user while ordinary subscribers share the same public address.

This cuts both ways:

Absence from a proxy list is not proof that the request is direct.
Presence on a proxy list is not proof that the request is malicious.

Google's 2026 disruption of the IPIDEA network showed the scale of the timing problem. Google identified hundreds of Android applications and thousands of Windows binaries connected with the proxy infrastructure, and observed many tracked threat groups using its exits. The investigation also found multiple SDK brands and reseller relationships feeding shared infrastructure. The details are in Google's IPIDEA disruption report.

A provider label or yesterday's reputation cannot carry the whole decision.

Build the Decision from the Request Outward

A workable policy starts with the route.

For each protected route, record:

what the request can read, change, or spend;
whether it creates expensive application or database work;
which identity is available, such as account, session, API key, or none;
whether an interactive challenge is possible;
what a false block would cost the user and the business;
which recent outcomes make repetition suspicious.

Then add the network and client evidence. A residential proxy result becomes more useful when it agrees with other observations: a breached credential, an unseen device, a fingerprint shared across rotating IPs, failed outcomes across many accounts, an invalid route sequence, or an abnormal request rate.

The policy can then choose among real actions:

Allow when the route is low risk and the session is otherwise consistent.
Log when the signal is new or the cost of intervention is higher than the current evidence supports.
Challenge when the client can provide more evidence and there is a safe recovery path.
Rate limit when repeated behaviour is the problem, especially across accounts, fingerprints, API credentials, or costly operations.
Block when the evidence is strong, harm is current, and narrower controls cannot protect the route.

Peakhour evaluates that context in the request path. Browser signals can add evidence when a browser is present, while API traffic can still be assessed without requiring JavaScript. The selected action and its inputs remain part of the decision record rather than disappearing into a standalone lookup.

Scores Need Reasons and Actions Need Owners

A security team should be able to answer three questions after a request is challenged or blocked:

Which observations changed the decision?
Which policy revision selected the action?
Did the action protect the route without breaking legitimate completion?

If the only retained field is risk_score: 87, review becomes guesswork. Keep the useful components: route, proxy result, IP category, fingerprint provenance, account or token state, recent failures, threshold state, action, policy revision, and origin outcome.

Every enforcement rule also needs an owner and an expiry condition. Proxy networks change. Client populations change. A rule created during an incident should not become permanent merely because nobody knows why it exists.

Start in observation mode on one sensitive route. Measure ordinary variation, proxy prevalence, successful completion, challenge outcomes, and false positives. Move to enforcement when the evidence supports a specific action. Roll back when the customer cost exceeds the risk reduction.

On a sensitive route, the proxy match may justify corroborating evidence or a reversible action. On a low-risk route, logging may be enough. In both cases, the team should be able to show which facts changed the decision and what happened afterwards. That is how proxy intelligence becomes an operable control rather than another label in a feed.

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.

How to Protect APIs From Unwanted Automation

2026-07-29T00:00:00+10:00

APIs are built for automation. That makes “block the bots” a fairly useless brief.

The same inventory endpoint might serve a mobile app, a partner feed and a scraper. All three clients can send valid requests. All three can hold valid credentials. The real question is whether that client is using that route in a way the business intended.

That sounds obvious. In practice, many API controls are still applied across a hostname or an IP range, with little regard for what the route actually does.

Begin with the route that can hurt you

Pick a sensitive operation: login, password reset, account lookup, checkout, reservation, coupon redemption or a costly GraphQL query. Ask its owner three things:

Who is meant to call it?
What does normal use look like?
What should happen when use falls outside that pattern?

The answer will not always be “block”. A public catalogue may tolerate a fair amount of crawling. A reservation endpoint probably should not let one client hold the entire available inventory. A partner export needs a machine-readable error and a phone call to the partner, not a browser challenge.

OWASP describes this problem as API6:2023 Unrestricted Access to Sensitive Business Flows. It includes automated purchasing, reservation abuse and referral fraud: ordinary application functions used for an unwanted purpose. The OWASP Automated Threats project covers the familiar variants, including credential stuffing, scraping, scalping and inventory denial.

Security can help enforce the decision, but it cannot invent the decision. The product or service owner has to say which use is legitimate and what the business is prepared to do about the rest.

Find the API you actually have

Policies written against an architecture diagram miss old mobile versions, forgotten staging hosts and endpoints that never made it into the OpenAPI file. Those routes still reach real systems.

API9:2023 Improper Inventory Management calls for an inventory of hosts, environments, versions, endpoints and data flows. This is not paperwork for its own sake. You need a real route and method before you can attach a useful control to it.

Peakhour API Security discovers REST, GraphQL and WebSocket routes, including shadow and legacy endpoints. Where an OpenAPI or Swagger contract exists, Peakhour can show requests that have drifted from it.

Schema is useful, but it is not intent. A perfectly valid checkout can still be abusive. Schema tells us what arrived and where; the route policy tells us whether to allow it.

Do not make JavaScript a requirement

A partner integration or machine-to-machine service does not need JavaScript to be protected. Peakhour can assess direct API traffic using route, method, schema result, authentication outcome, headers, protocol behaviour, network path, response code and request cadence.

JavaScript is useful when the API call belongs to a browser-backed journey. It can add browser and device consistency signals, or support a challenge before a sensitive account action. That is optional evidence. A direct API client does not need JavaScript, and its absence is not evidence of abuse.

This has an operational consequence: choose an action the intended client can complete. A customer resetting a password in a browser may be able to pass a step-up check. A partner batch cannot.

Count something that survives an IP change

An IP limit is easy to understand and sometimes it is enough. It is a poor fit for distributed credential testing, residential proxy traffic and clients behind carrier-grade NAT.

API4:2023 Unrestricted Resource Consumption recommends limits suited to the operation. Password recovery, one-time-code validation, GraphQL batching and large responses have different costs and should not share one threshold.

Peakhour's Advanced Rate Limiting can count using documented inputs including path, headers, IP, ASN, country, TLS fingerprint, response code and bot-verified status. Each rule has a threshold, interval and action, with counters showing what it allowed, blocked or saw cross the threshold.

The important part is being able to explain the counter. “One hundred requests per minute” is not much of a policy until we know the route, which clients are grouped together, and why one hundred is the point at which use becomes harmful.

Application context can improve that policy. An account, tenant, session or API credential may be a better unit than a network address, provided the integration supplies it safely. Do not casually copy credentials into logs or rule labels.

Treat fingerprints and proxy detection as evidence

Attackers rotate addresses because IP-only controls are easy to distribute around. Legitimate traffic also shares addresses in offices, hotels, universities and mobile carrier networks.

TLS behaviour, HTTP/2 settings, header shape and browser consistency can group requests into a client cohort even as the source IP changes. That can reveal a tool family or a recurring campaign. It does not reveal the person operating it. Fingerprints collide, change and can be copied. They are evidence, not identity.

The same caution applies to residential proxy detection. A proxy signal can justify closer inspection or a tighter limit on a sensitive route. It is not a sound reason to block every request that looks residential.

Expect the first policy to be wrong

A mobile release changes its request shape. A partner runs a larger batch. A sale changes normal checkout traffic. The attacker slows down and moves from login to token refresh.

We start sensitive API controls in monitoring unless the active harm demands an immediate block. Keep the route, evidence, action and response outcome together. Log forwarding sends that record to the customer's existing SIEM or observability platform.

Before tightening a policy, we want two answers:

What unwanted activity did it reduce?
Which intended clients did it inconvenience?

The Gumtree case study is not an API-only case study. It is relevant because it records how this tuning works in production. Gumtree and Peakhour deployed progressively and adjusted controls against live traffic. Gumtree reported a 3.3x cleaner origin mix and an 80% reduction in Gumtree's internal fraud score. Those figures belong to the broader bot-management deployment, not to an isolated API feature.

One request should produce one decision

An automated campaign does not respect product categories. The same traffic can use valid API calls, stolen credentials, residential proxies and changing client fingerprints while also carrying payloads that need WAF inspection.

Peakhour puts API protection, managed WAF/WAAP, bot management, advanced rate limiting, DDoS protection, anomaly detection and origin protection in the same request path. It can run on Peakhour Edge or alongside an existing CDN or edge provider. Operators get one decision to review, with the evidence that produced it, rather than a pile of unrelated scores.

API Bot Protection shows how we apply that model to login, token, checkout and account routes.

The Real Cost of Breached Credentials

2026-06-19T00:00:00+10:00

The cost of breached credentials is usually counted in the wrong place.

When an organisation suffers a data breach, the obvious costs are incident response, legal work, notification, customer support, remediation, and regulatory attention. Those costs matter. IBM's 2025 Cost of a Data Breach Report puts the global average breach cost at about USD 4.4 million. IBM's data breach explainer also says stolen or compromised credentials were one of the top five initial attack vectors in the 2025 report, accounting for 10% of breaches and taking up to 186 days to identify.

But that is only the first bill.

Once usernames and passwords leave the original system, they do not stay attached to the original incident. They are copied, sorted, bundled, tested, resold, and mixed with other personal data. Another company's breach becomes your login problem. A password reused somewhere else becomes your fraud queue, your support call, your chargeback, your locked account, your angry customer, and your next security review.

That is the real cost of breached credentials: not just the breach, but the long tail of account abuse that follows.

The Roundup: Breaches Are Feeding Account Abuse

The numbers are not subtle.

The Identity Theft Resource Center's 2025 Annual Data Breach Report tracked 3,322 data compromises in 2025, a record high and a 79% increase over five years. The same report found that 70% of breach notices did not include attack information, making it harder for consumers and downstream businesses to understand what risk they now carry.

The ITRC also introduced a category it calls Previously Compromised Data: old stolen data that is repackaged and recirculated. In the full report, the ITRC says there were four major PCD releases in 2025, including two incidents involving roughly 16 billion records with no known notices. Its warning is the important part: while this may not be "new" stolen data, aggregation makes it highly effective for credential stuffing and account takeover attacks.

That matches the operational pattern security teams see on login endpoints. OWASP describes credential stuffing as automated testing of stolen username and password pairs against login forms. The reason it works is boring and persistent: people reuse passwords. Attackers do not need to breach your site if a customer has already reused a working credential somewhere else.

For Australian organisations, the local signals are just as relevant. The OAIC received 532 Notifiable Data Breach notifications between January and June 2025, with malicious or criminal attacks remaining the largest source of notifications. ASD's Annual Cyber Threat Report 2024-25 notes that its credential exposure notification process proactively sent 9,587 credential exposure events to about 220 organisations between 19 November 2024 and 30 June 2025.

None of that means every fraud loss starts with a reused password. It does mean credential exposure is part of the operating environment. Attackers have supply, tooling, proxy infrastructure, and plenty of places to turn account access into money.

The FBI's 2025 IC3 report gives useful context for that monetisation path. Cyber-enabled fraud accounted for 452,868 complaints and USD 17.697 billion in reported losses. Those losses include many crime types, not just credential stuffing, but the transaction paths are familiar to anyone dealing with account abuse: wire and ACH transfers, cards, peer-to-peer transfers, prepaid and gift cards, and cryptocurrency.

Where the Cost Actually Lands

A breached credential is cheap for the attacker and expensive for everyone else.

The first cost is detection. A login using the right username and password does not automatically look malicious. If the attacker spreads attempts across residential proxy infrastructure, uses one attempt per account, or targets mobile API endpoints directly, simple IP-based rate limits may not see the pattern. Peakhour has written about this in The Australian epidemic of Account Takeover attacks and in Credential Stuffing Does Not Stop at the Login Form.

The second cost is fraud. Once a credential works, the attacker looks for value: stored cards, gift cards, loyalty points, refunds, store credit, subscription changes, delivery addresses, and saved payment flows. This is why account takeover is not just an authentication problem. The expensive moment may be checkout, not login.

The third cost is support. Customers do not usually know whether the original password leak happened somewhere else. They know their account was used, their card was charged, their loyalty balance disappeared, or their email address changed. The business still has to handle the support ticket, freeze the account, unwind the transaction, review the evidence, and explain what happened.

The fourth cost is trust. We have covered this before in The Cost of Credential Stuffing: the reputational damage is practical. Customers see refunds, account locks, suspicious messages, and public complaints. Even if the business was not the source of the original breach, it becomes the place where the harm is felt.

The fifth cost is friction. If the only response is to challenge everyone, the business pays through abandonment and customer frustration. If the response is too soft, the business pays through fraud. The work is to apply friction where the evidence justifies it.

You Do Not Need Surveillance to Secure Accounts

There is a bad version of account protection that tries to identify people everywhere they go. That is not necessary, and it is not the right model for this problem.

Credential abuse defence should be scoped to the account security decision in front of you. Is this login using a known exposed credential pair? Is the session coming from suspicious infrastructure? Is it a first-seen device for the account? Is it trying to change email, reset the password, add a payout method, redeem stored value, or check out with saved payment details? Did the same client pattern just test many accounts?

Those questions can be answered with security-specific signals, not advertising-style tracking. Hash the credential check. Treat fingerprints as evidence, not identity. Keep the evidence tied to the protected account and request path. Use network, device, route, behaviour, and credential-risk context to decide whether to allow, step up, throttle, block, or review. Do not build a cross-site identity graph when the job is to stop account abuse on your own service.

That distinction matters. Users should not have to trade privacy for basic account security. Businesses also do not need to choose between doing nothing and adding blanket friction. Contextual security is useful because it lets the response match the risk.

What Teams Should Measure

If breached credentials are a business cost, measure them like one.

Useful measures include:

How many login attempts match known breached credential pairs.
How many breached-credential attempts result in a successful login.
Which routes see the risk: login, password reset, email change, stored-card checkout, gift card redemption, account recovery, mobile API, partner API, or admin access.
How often high-risk sessions move from login into sensitive account actions.
Which signals appear together: breached credential, residential proxy, first-seen device, unusual geography, repeated failure, rapid checkout, or recovery-flow pressure.
How many support tickets, refunds, chargebacks, account locks, and fraud reviews are linked to account takeover.
How many controls create customer friction, and whether that friction is landing on risky sessions or ordinary customers.

This does not need to be perfect on day one. The important step is to stop treating credential stuffing as a vague security category and start treating it as an observable account-risk workflow.

The Control Pattern

The control pattern is layered.

Start with breached credential scanning so reused or exposed credentials are visible at login. Feed that signal into account takeover prevention rather than treating it as a standalone report. Add bot management and advanced rate limiting so automation and distributed testing are harder to run at scale. Use residential proxy detection as a risk signal, especially where attackers are trying to make automated traffic look like normal customer traffic.

Then carry the risk forward after login.

A low-risk page view and a saved-card checkout should not inherit the same level of trust just because the password worked. A session that begins with a breached credential match, comes through suspicious infrastructure, and immediately changes the email address or redeems stored value deserves a different response from a known customer browsing order history.

The response can be graduated:

Log low-risk activity for visibility.
Tighten rate limits on suspicious automation.
Require step-up verification before sensitive account changes.
Hold or review risky transactions.
Notify the customer when high-risk account changes are attempted.
Block sessions when the evidence is strong enough.

That is how breached credential data becomes useful. It is not a panic button. It is a signal that helps decide when trust should be earned again.

The Practical Takeaway

Breached credentials are not only a breach-response issue. They are an account protection issue, a fraud issue, a support issue, and a customer trust issue.

The original breach may have happened somewhere else. The cost can still land on your login form, your checkout, your API, and your support team.

The goal is not to make every login difficult. The goal is to make stolen credentials harder to turn into account control, money movement, stored-value abuse, or customer harm.

That starts by making credential risk visible, connecting it to session and route context, and applying proportionate controls where the cost would otherwise show up.

How Residential Proxies Changed API and Account Abuse

2026-06-19T00:00:00+10:00

Residential proxies have changed the shape of API and account abuse. The old picture was easier to reason about: too many failed logins from one IP, a known hosting provider range, an obvious bot user agent, or a burst that crossed a threshold quickly enough to trip a rule.

That still happens, but it is not the harder problem.

The harder problem is the attempt that arrives through ordinary consumer networks, spreads itself across many addresses, and behaves just slowly enough to avoid looking like an incident. One login attempt here. A password reset probe there. A token refresh pattern that is unusual only when it is seen beside the route, the client, the ASN, the credential history, and the account event.

That is why residential proxy detection should be treated as part of the account and API decision path, not as a standalone allow/block list.

The Account Workflow Is Now a Distributed Target

Attackers do not need to break the whole application at once. They can work through the account surface in pieces:

Login attempts against known usernames.
Password reset initiation and verification.
New account registration.
Token issue and refresh routes.
Payment, address, profile, and email changes.
Loyalty, wallet, checkout, or stored-value workflows.
API calls that reveal whether an account or credential is valid.

Each route may look acceptable in isolation. The risk appears when the pattern is joined together.

A residential proxy network helps the attacker keep that pattern quiet. Requests rotate through many residential-looking exits. IP-based rate limits see different sources. A reputation feed may not have labelled a fresh or private proxy network yet. Geo checks can look plausible enough. The traffic does not necessarily arrive as a clean burst.

This is where static thinking breaks down. If the only question is "is this IP bad?", the answer will often arrive too late or be too blunt to use safely.

Fresh and Private Proxy Networks Create a Timing Problem

Many teams think about proxy detection as a database problem: look up the IP, see whether it is a proxy, then block it. That works for some traffic, especially known data centre proxies and commodity infrastructure.

Residential proxy abuse is less tidy. Fresh networks can appear before public datasets have a confident label. Private networks may not show up in broad feeds at all. Some exit points are shared with legitimate users. Some sit behind carrier-grade NAT or normal household connections. Blocking the address outright can create customer pain, while allowing it without context leaves the account flow exposed.

This is the practical reason Peakhour talks about residential proxy use as a signal. The signal matters, but it has to sit beside IP intelligence, connection characteristics, client history, request behaviour, account state, and route sensitivity.

A residential proxy on a marketing page may only need logging. The same proxy signal on a login route with recent failures may justify a challenge. On a password reset or high-value account change, it may justify step-up authentication, throttling, or blocking depending on the rest of the evidence.

The control should match the risk of the action.

Low-and-Slow Behaviour Is Still Automation

Low-and-slow abuse is uncomfortable because it avoids the easy operational story. There is no dramatic spike. There may be no single IP worth banning. The application may not be overloaded. Support may only see a few confused users, a few locked accounts, or a gradual rise in reset attempts.

For API and account workflows, this is still automation. It just looks less like a flood and more like a background process.

Useful signals include:

Repeated failed authentication across a shared fingerprint or client pattern.
Many accounts touched by similar request timing.
Token or reset routes used out of sequence.
Browser characteristics that do not match the claimed client.
Residential proxy use on sensitive account routes.
Fresh IP or ASN patterns appearing around account events.
Similar request shapes distributed across unrelated accounts.

None of these signals has to prove abuse by itself. The point is to combine them early enough that the application does not have to make the decision alone.

Peakhour's view is that proxy detection belongs in the same operating model as bot management, rate limiting, account risk scoring, and event evidence. The useful question is not "can we block every residential proxy?" It is "what should this route do when proxy use appears with this account, this client, this credential pattern, and this recent behaviour?"

API Routes Need the Same Treatment as Browser Flows

A common gap is protecting the visible login page while leaving API routes with weaker controls. Browser-side checks can help on web flows, but many account actions now happen through mobile apps, single-page applications, partner integrations, and backend APIs.

Those routes still need context. They need request-level validation, route-aware thresholds, proxy and IP signals, token checks, and evidence that can be reviewed later. A login API, a reset API, and a profile-change API should not all receive the same action just because the source address has the same reputation.

This is also why rate limiting has to move beyond source IP. A rule can key on a token, header, fingerprint, account identifier, route, response code, or a combination of signals. That makes it possible to slow failed login behaviour without punishing every legitimate user behind the same network.

The background reading on proxy detection challenges and quantifying residential proxy risk covers the broader detection problem. For API and account teams, the immediate step is more operational: find the routes where a residential proxy signal should change the action.

The Right Outcome Is Controlled Friction

Residential proxy detection is not a magic verdict. It is a way to make the account decision more honest.

Some traffic should pass. Some should be logged. Some should be rate limited. Some should be challenged. Some should be blocked. The difference should come from route sensitivity, request context, and observed behaviour, not from a single IP label.

A practical policy might look like this:

Monitor proxy use across all account and API routes.
Apply tighter thresholds on login, reset, token, and account-change routes.
Combine proxy use with credential, client, rate, and behaviour signals.
Preserve decision records so security and support can explain what happened.
Move from monitor to enforce only after reviewing false positives and customer impact.

That model gives teams a way to respond to residential proxy abuse without turning every shared residential network into a casualty.

For a grounding definition, see What is Residential Proxy Detection?. For the product control, see Residential Proxy Detection.

The important shift is simple: residential proxies are not just a network category. In account and API protection, they are context for deciding how much trust a request deserves.

Anatomy of a Credential Stuffing Attack

2025-09-01T00:00:00+10:00

In early 2024, major Australian retailer The Iconic was hit by a widespread account takeover attack. Fraudsters used stolen credentials to log into customer accounts, place orders with stored credit cards, and ship goods to different locations. The incident caused significant reputational damage and financial loss, forcing the company to issue refunds and publicly address the security breach.

This attack wasn't the result of a direct hack on The Iconic's systems. It was a classic case of credential stuffing: an automated attack that works because people reuse passwords across services. This article breaks down how credential stuffing works, the attacker's toolkit, the business impact, and the controls that make it harder to run at scale.

What is Credential Stuffing?

Credential stuffing is an automated attack where malicious actors use lists of stolen usernames and passwords—often obtained from third-party data breaches—to gain unauthorised access to user accounts on other websites. The attack works because many users recycle the same password across multiple online services. If a password for a user's social media account is leaked, attackers will "stuff" that same email and password combination into the login forms of e-commerce sites, banking portals, and other high-value targets.

Because attackers submit valid credentials, even though they are stolen, these login attempts can be difficult to distinguish from genuine user activity. That makes credential stuffing harder for traditional security controls to spot.

The Attacker's Toolkit

Modern credential stuffing is not a manual process. Attackers use a mature set of tools and resources to automate and scale their campaigns:

Automation Software: Tools like OpenBullet are central to these attacks. OpenBullet is a powerful, open-source web testing suite that allows even non-programmers to create complex attack scripts. Attackers can find or create "configs" that tell the software exactly how to interact with a target website's login form.
Breached Credential Lists: Dark web markets carry massive databases of usernames and passwords harvested from data breaches. These "combo lists" are the raw material for credential stuffing attacks and can be purchased for very little cost.
Proxy Networks: To avoid being blocked, attackers distribute their login attempts across thousands or even millions of IP addresses. They often use residential proxy networks, which route traffic through the internet connections of real home users. This can make malicious traffic appear to come from legitimate customers, weakening IP-based blocking and rate limiting.

The Business Impact

The consequences of a successful credential stuffing attack extend beyond the login event:

Direct Financial Loss: As seen with The Iconic, attackers can make fraudulent purchases, drain loyalty points, or transfer funds, leading to direct financial losses and the cost of refunding customers.
Damage to Brand Reputation: Publicly reported breaches erode customer trust. Users who have been defrauded may share their negative experiences on social media, leading to lasting reputational harm.
Loss of Customer Trust: When customers believe their accounts are not secure, they may abandon the platform altogether, leading to customer churn and a decline in lifetime value.
Operational Costs: Responding to an attack involves significant operational overhead, including customer support time, fraud investigation, and new security measures.

Building a Multi-Layered Defense

Stopping automated attacks requires a defence strategy that goes beyond simple password policies. A modern, multi-layered approach should include:

Advanced Bot Protection: The first step is to distinguish bots from humans. Modern bot management uses techniques like network and browser fingerprinting, proxy context, route behaviour, and behavioural analysis to detect automated login attempts, even when they mimic human behaviour.
Check Credentials Against Breach Databases: Proactively check usernames and passwords used in login attempts against comprehensive databases of known breached credentials. If a credential pair is known to be compromised, you can flag the login for additional verification or alert the user to change their password.
Advanced Rate Limiting: Traditional IP-based rate limiting struggles against distributed attacks. Advanced rate limiting groups requests by more stable identifiers, such as a TLS fingerprint, which can remain consistent even as an attacker rotates through thousands of IP addresses. This helps track and block a single malicious actor launching a distributed attack.
Enforce Multi-Factor Authentication (MFA): MFA is not a silver bullet, but it provides a critical layer of security by requiring a second form of verification. Websites should strongly encourage or enforce MFA, especially for sensitive actions like changing account details or making purchases.

For production teams, the useful bot-management view ties those controls together on the login path. Credential exposure, residential proxy evidence, fingerprints, request rate, response codes, and session changes should feed one decision about whether to allow, challenge, rate limit, block, or review the attempt.

By combining these controls, organisations can make credential stuffing harder to scale, protect user accounts, and reduce the business risk when attackers test stolen credentials.

Beyond the IP Address

2025-09-01T00:00:00+10:00

For years, rate limiting has been a standard control for protecting websites and APIs from abuse. The basic model is simple: limit the number of requests a single "user" can make in a given period. If a user exceeds the limit (e.g., 10 login attempts in a minute), they are temporarily blocked.

The hard part has always been identifying that "user". Traditionally, the answer was the IP address. The assumption was that one IP address equaled one user. In the early days of the internet, this was a reasonable approximation. Today, that assumption no longer holds, and it leaves systems exposed to modern attacks.

The IP address is no longer a reliable identifier for a single user or device. There are three common reasons:

Proxy Networks: Attackers don't use a single IP address. They use large residential proxy networks to rotate requests through thousands or even millions of different IP addresses, making each request look like it comes from a new user.
Shared IPs (CGNAT): At the same time, a single IP address can represent thousands of legitimate users. Mobile carriers use Carrier-Grade NAT (CGNAT) to make many mobile devices share the same public IP. Similarly, an entire office building or university campus might appear to the internet as a single IP.
Distributed Attacks: Modern automated attacks, like Layer 7 DDoS or credential stuffing, are inherently distributed. Attackers use botnets or proxy networks to spread their attack across a large number of IPs, so no single IP ever exceeds a traditional rate limit.

Blocking a shared IP because of one bad actor can cause collateral damage, denying access to thousands of legitimate users. On the other side, failing to see that thousands of IPs are part of a single coordinated attack means the attack succeeds. Traditional IP-based rate limiting is no longer enough.

The New Way: Advanced Rate Limiting

Advanced Rate Limiting addresses this by moving beyond the IP address. Instead of grouping requests by a single, unreliable identifier, it lets you count requests using more stable and meaningful characteristics of the connection or the software making it.

This approach groups requests using identifiers like:

TLS/HTTP2 Fingerprints: Every client application (like a browser or a script) has a unique "fingerprint" based on how it initiates a secure connection (TLS) or communicates over HTTP/2. This fingerprint remains consistent even as an attacker rotates through thousands of IP addresses. By rate limiting based on the TLS fingerprint, you can track and block the underlying automation tool itself, not just the IPs it uses.
Device Characteristics: A fingerprint can be constructed from a range of attributes, including the device's operating system, browser version, and more. This allows for the detection of repeated requests coming from the same class of device.
A Combination of Headers: For authenticated APIs, you can group requests by an Authorization header or API key, enforcing fair usage and preventing abuse by a single authenticated client.

Practical Use Cases

The value of advanced rate limiting is clearest when it is applied to real-world threats:

Mitigating Distributed Credential Stuffing: An attacker using a tool like OpenBullet launches a credential stuffing attack against your login page, rotating through thousands of residential proxy IPs. Traditional rate limiting is ineffective here. However, the OpenBullet software has a consistent TLS fingerprint. By setting a rule to limit failed login attempts per TLS fingerprint, you can detect and block the entire distributed attack, regardless of how many IPs are involved.
Protecting APIs from Abuse: A partner is abusing their API key, sending far too many requests and degrading service for other users. By rate limiting based on the Authorization header, you can enforce usage limits on a per-client basis, keeping access fair without affecting other users.
Stopping Content Scrapers: A scraper is hammering your e-commerce site to steal pricing data. They are using a botnet to distribute the requests across hundreds of IPs. However, the scraping script has a unique combination of a user-agent and a TLS fingerprint. Advanced rate limiting can count requests based on this combined signature and block the scraper, protecting your intellectual property.

When attackers are distributed, your defences need to see the single actor behind the many IPs. Advanced rate limiting provides that visibility and should be part of a modern application security strategy.

The Invisibility Cloak

2025-09-01T00:00:00+10:00

A bot can change its IP address without changing the browser behind the request. It can also change its reported browser profile while continuing the same account attack.

Residential proxies and anti-detect browsers cover those two surfaces. The proxy moves traffic through consumer connectivity. The anti-detect browser manages the client properties exposed to the website. Used together, they make simple IP and browser rules less reliable.

They do not make the operator invisible.

The Proxy Changes the Network Path

A residential proxy sends a third party's traffic through a consumer or ISP connection. The destination sees the exit address rather than the operator's original network.

That supply may come from an informed participant, an embedded monetisation SDK or a compromised device. The destination usually cannot see that enrolment history. It sees a request from an address that may also carry legitimate household traffic.

This is why a clean IP reputation result is not enough to establish trust. A fresh exit may not yet appear in a database, while a stale label can remain after the address has returned to ordinary use.

The Browser Changes the Client Presentation

An anti-detect browser lets an operator manage browser profiles at scale. Profiles can vary user agent, operating system claims, screen properties, language, time zone, storage and rendering inputs. The aim is to make separate sessions look plausible and prevent a site grouping them as one client.

That control is not absolute. Some properties can be spoofed cleanly. Others interact with the network stack, rendering environment, request sequence and account history. A profile can look plausible in isolation while disagreeing with evidence elsewhere in the session.

The stable explainer is Residential Proxies and Anti-Detect Browsers. This article focuses on what their combination changes for a live application.

Look for Agreement, Not a Magic Fingerprint

No fingerprint proves that two requests came from one person or one machine. Common browsers create large cohorts, privacy controls remove information, and legitimate devices change across software updates and networks.

The useful question is whether independent observations agree:

Does the TLS and HTTP behaviour fit the claimed browser family?
Does the browser profile remain internally consistent across the journey?
Does the same request sequence continue as the IP rotates?
Are credentials, accounts, carts or API objects reused across supposedly unrelated clients?
Do timing, retries and outcomes match normal use of the protected route?

Each observation has legitimate explanations. Agreement across several layers raises confidence without pretending a fingerprint is identity.

Protect the Work Being Attempted

Credential stuffing, fake registration, scraping and inventory abuse have different failure modes. Their controls should differ too.

On login, correlate failures across account, credential and client cohorts instead of resetting history with every IP change. On signup, measure creation velocity and the quality of later activity. On checkout, carry session risk into promotion, payment and inventory decisions. On APIs, use credentials, operations, protocol evidence and cost; JavaScript is not required.

Residential proxy detection contributes current network evidence. Browser and network fingerprinting contribute cohort and consistency evidence. Behaviour and route context decide whether the application should allow, log, challenge, rate limit, step up or block.

That is the important limitation of the “invisibility cloak” metaphor. These tools can hide one surface at a time. They still have to complete work against an application that can observe the whole request sequence.

Continue with Proxy Signals and Security Decisions or the route-specific guide Five Routes, Five Residential Proxy Decisions.

Key Considerations for Effective Bot Management

2025-09-01T00:00:00+10:00

Introduction

Bots account for a large share of web traffic. Recent studies estimate that nearly 50% of all internet traffic is generated by automated programs. Some bots are necessary for the web to function, such as search engine crawlers, but a significant portion are malicious. These "bad bots" are used for content scraping, credential stuffing, spam, and DDoS attacks.

As bot operators become more sophisticated, bot management needs to cover detection, classification, and response. This article outlines the main considerations for security teams protecting intellectual property, online revenue, and user accounts.

The Goal: Accurate Bot Detection and Classification

The first step in effective bot management is separating legitimate users from automated threats. Identification is not enough on its own. Security teams also need accurate classification across good, bad, and "grey" bots.

Good Bots: Support normal internet operations, such as search engine crawlers (Googlebot, Bingbot) and performance monitoring bots.
Bad Bots: Carry out malicious activity such as content scraping, account takeover, and spamming.
Grey Bots: Serve a legitimate purpose but can cause problems when they crawl too aggressively, such as SEO and marketing bots (Ahrefs, SEMrush).

Effective detection usually needs more than basic signatures. A layered approach commonly includes:

Basic Protection: Targets simple bots using user agent checks and IP reputation databases.
Intermediate Protection: Uses JavaScript-based challenges and basic network fingerprinting, such as JA3/JA4, to detect less sophisticated bots.
Advanced Protection: Combines comprehensive network fingerprinting, behavioural analysis, and machine learning to identify sophisticated bots that mimic human behaviour, use residential proxies, or rely on anti-detect browsers.

Machine learning models help in this context because they can learn from changing bot strategies and inspect incoming traffic for subtle signs of automation.

The Method: Continuously Adaptive Detection and Response

Bot behaviour changes quickly. Threat actors modify tooling, traffic patterns, and infrastructure to avoid detection, so static defence rules degrade over time. Organisations need detection and response that can adapt as the attack changes.

That means correlating metadata with behavioural factors in real time, then applying the right response for the risk. When a bot attempts account takeover or data scraping, an adaptive response can act immediately to reduce the impact.

Effective adaptive responses include:

Advanced Rate Limiting: Goes beyond simple IP-based limits by grouping requests with more stable identifiers, such as TLS/HTTP2 fingerprints or device characteristics. This helps stop distributed attacks from tools like OpenBullet that rotate through thousands of IP addresses.
Web Application Firewalls (WAF): Provide an important first line of defence by filtering harmful Layer 7 traffic based on predefined rules.
Tarpitting: Slows malicious connections to increase cost and resource consumption for attackers.
Challenges: Traditional visible CAPTCHAs can harm user experience and are often solvable by modern bots. Invisible challenges can verify a legitimate browser environment with less friction.
Alternate Content Serving: Misleads scraping bots by serving alternate or cached content with incorrect information (e.g., higher prices), making their scraped data useless.

The same response process should also feed learning loops, building a repository of bot attack patterns that can train machine learning models and improve accuracy over time.

The Expected Outcomes: A Resilient Security Posture

An adaptive bot management strategy should support several practical outcomes:

Risk Mitigation: Reduce potential financial losses, service disruption, and data breaches associated with malicious bot activity such as credential stuffing, ad fraud, and inventory hoarding.
Improved User Experience: Keep disruption low for genuine users by using invisible challenges and behavioural analysis instead of frustrating CAPTCHAs, which can reduce conversions by up to 40%.
Intellectual Property Protection: Protect valuable content, pricing data, and other intellectual property from unauthorised scraping.
Online Revenue Security: Protect online revenue streams by preventing fraud, inventory scalping, and other malicious activity that targets e-commerce platforms.
Regulatory Compliance: Help organisations meet data protection and privacy regulations with a proactive bot management approach.

Conclusion: Fortifying Against Sophisticated Bots

Modern bot defence depends on accurate detection, precise classification, and adaptive response. Machine learning, comprehensive network fingerprinting, and behavioural analysis all contribute, but they work best as part of a layered control set.

With that approach, security teams can better protect intellectual property, online revenue, and user accounts from sophisticated bot activity.

The Bot Spectrum

2025-09-01T00:00:00+10:00

The word "bot" is often used as shorthand for unwanted automation: scripts trying to break into accounts, scrape content, or overwhelm websites. A large share of internet traffic does come from bad bots, but automated traffic is not automatically harmful. Some bots are part of how the web is discovered, monitored, and kept usable.

Effective bot management is not about blocking every automated request. It depends on accurate classification: separating good bots from bad bots, and recognising the "grey" bots that sit between them. That classification lets you apply controls that reduce risk without cutting off traffic that helps your site operate.

Good Bots: The Essential Workers of the Web

Good bots are automated programs that perform useful or necessary tasks. They are usually clear about who they are and respect the rules you set in your robots.txt file. Blocking them can damage search visibility, monitoring, or other business workflows.

Examples of Good Bots:

Search Engine Crawlers: Bots like Googlebot and Bingbot are the best-known good bots. They crawl and index your website's content, which is how your pages appear in search engine results. Blocking them would make your site invisible on Google.
Performance Monitoring Bots: These bots are used by services to check your website's uptime and performance from different locations around the world, and to alert you if your site goes down.
Copyright Bots: These bots scan the web for plagiarised content, helping to protect your intellectual property.

Management Strategy: Good bots should be identified and allowed to access your site freely. Verification techniques, such as reverse DNS lookups, can be used to confirm that a bot claiming to be Googlebot is actually coming from Google.

Bad Bots: The Malicious Actors

Bad bots are designed for malicious activity. They are a major reason bot management exists as a security function. These bots are deceptive, often hiding their identity and purpose, and they can be responsible for a wide range of costly and damaging activity.

Examples of Bad Bots:

Credential Stuffers: These bots use stolen usernames and passwords to carry out account takeover attacks.
Content and Price Scrapers: These bots steal your valuable content, product listings, and pricing data, often for use by competitors.
Spam Bots: These bots flood comment sections, forums, and contact forms with unwanted ads or malicious links.
Denial of Service (DDoS) Bots: These bots are part of a botnet used to overwhelm a website with traffic, causing it to slow down or crash.
Inventory Hoarding Bots: Common in e-commerce, these bots automatically add limited-edition products to shopping carts to prevent legitimate customers from buying them, often for resale at a higher price (scalping).

Management Strategy: Bad bots need to be accurately identified and blocked as quickly as possible, ideally at the network edge before they consume your server resources.

Grey Bots: The Nuanced Category

Grey bots are not inherently malicious, but their behaviour can still cause problems. They often serve a legitimate purpose, but become an issue when they crawl too aggressively, consume excessive bandwidth or server resources, and slow the site down for real users.

Examples of Grey Bots:

Aggressive SEO Tools: Bots from marketing tools like Ahrefs, SEMrush, and Majestic crawl websites to gather data for backlink analysis and competitive research. They can be useful, but their crawling can also be heavy.
Partner and Aggregator Bots: These could be bots from partner companies or price comparison websites that need to access your data. The activity may be legitimate, but it still needs to be managed.
Feed Fetchers: Bots that collect data for news aggregators or other applications fall into this category.

Management Strategy: Grey bots require more than a simple allow or block rule. The best strategy is often to rate-limit or tarpit them.

Rate-Limiting: This allows the bot to continue accessing your site, but slows it to a manageable level so it does not overwhelm your servers.
Tarpitting: This intentionally slows the connection for a specific bot, increasing the cost and time required to crawl your site and discouraging overly aggressive behaviour.

By classifying incoming bot traffic and applying the right control for each category, organisations can block threats, manage resource consumption, and allow the useful automation the modern web depends on.

SMS Pumping Fraud: How Verification Traffic Inflates the Bill

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

The Growth of SMS Fraud

SMS pumping fraud is a costly online abuse pattern, with global losses reaching an estimated $6.7 billion in 2021 alone. It targets companies that rely on SMS for verification or customer communications, leaving them to pay for traffic they did not request.

The scheme relies on malicious actors and dishonest telecom operators working together to generate and monetise large volumes of fraudulent text messages. For businesses caught in these schemes, the financial impact can be severe. Twitter (now X) reportedly lost $60 million to this type of fraud.

This guide explains how SMS pumping works, which businesses face the highest risk, and the controls your organisation can use to reduce exposure.

Understanding SMS Pumping Fraud

SMS pumping (also called SMS toll fraud, SMS spamming, or Artificially Inflated Traffic) involves manipulating mobile networks to inflate charges for text messages. The term "pumping" describes fraudsters forcing high SMS volume through a target's systems.

This fraud exploits how SMS messages travel and get billed across phone networks. Attackers target companies that use SMS codes to verify users. Each time a business sends a verification code, it pays a fee. Fraudsters trigger these systems to send thousands of messages to numbers they control.

These attacks create direct costs for businesses and revenue for the attackers. The fraud works through coordination between criminals and corrupt telecom operators, who charge premium rates for message delivery and share the proceeds.

The fraud has changed as more businesses have adopted SMS verification. Attackers keep developing new methods, and the phone industry has not removed the risk. Many companies still carry the financial exposure.

How SMS Pumping Works

SMS pumping attacks usually exploit message systems through these steps:

Finding Targets: Attackers look for websites or apps that send SMS codes for account verification or password resets.
Creating Fake Requests: Fraudsters use automation to send thousands of code requests to phone numbers they own or control.
Hiding Their Tracks: Attackers change their IP addresses and device information so requests appear to come from real users.
Sharing Profits: Fraudsters work with dishonest phone companies that charge high fees when messages pass through their networks. These companies then share the money with the attackers.
Using Complex Routes: Messages travel through many networks before reaching their destination, making the source of the fraud harder to trace.
Targeting Expensive Routes: Attackers focus on international numbers where sending messages costs more or where rules are weaker.

These attacks look legitimate because each message contains a real code sent to what appears to be a normal phone number. Companies like Twilio or Bird must pay fees to deliver these messages. Most businesses only find out about the fraud when a large bill arrives from their SMS service.

SMS pumping differs from basic spam because the profit-sharing between attackers and phone companies creates a direct cost for the target business.

Businesses at Risk

SMS pumping is most likely to affect these types of businesses:

Financial Institutions

Banks, investment platforms, and cryptocurrency exchanges use SMS codes to protect accounts. These firms send thousands of codes each day, which makes it hard to spot fake requests mixed with real ones.

E-commerce Platforms

Online shops use SMS messages when users create accounts, reset passwords, or make purchases. These businesses often run on small profit margins, so extra SMS costs can hurt their earnings. High volumes of new users make it easier for attackers to hide their activity.

Social Media Companies

Social networks use text messages to check user identity and stop fake accounts. These companies send millions of codes each day to users around the world. Twitter lost $60 million from this type of fraud, showing the scale these bills can reach.

Software-as-a-Service (SaaS) Providers

These companies often offer free trials that require SMS verification. They plan for a set cost to acquire each new user, but fraud can push these costs much higher than expected.

Telecommunications Companies

Phone companies face two problems: their own systems can be attacked, and parts of their network might help fraudsters. They need strong monitoring tools to find unusual patterns in message traffic.

Small Businesses and Startups

While smaller firms send fewer messages, they often lack security teams and fraud detection tools. This makes them easier targets. The cost of an attack can put these businesses at risk of closing down because they have less money in reserve.

Advanced Attack Methods

Attackers now combine SMS pumping with other techniques to avoid detection.

Credential Stuffing

Fraudsters use passwords stolen in data breaches to break into accounts. Once inside, they change phone numbers to ones they control and trigger verification messages. This makes fraud appear to come from real users.

Peakhour's breach database detection identifies when stolen credentials are used to access accounts. The system flags these attempts before phone numbers can be changed, stopping the attack chain.

Residential Proxy Networks

Unlike data centre proxies that security systems can often spot, residential proxies hide attack traffic behind home internet connections. This makes fraud look like it comes from regular users in different locations.

Peakhour specialises in residential proxy detection. Its technology identifies these masked connections and blocks them before verification requests can pass through. The system maps known proxy networks and detects signs of traffic passing through residential IPs.

When combined with device fingerprinting, these protections create a stronger defence. Fingerprinting tracks device characteristics that remain consistent even when attackers change IP addresses or accounts. Peakhour's fingerprinting technology works without cookies, making it effective against attackers who clear browser data.

These methods focus on the techniques fraudsters use to hide their identity. With Peakhour's protection, businesses can detect and block these attacks before they trigger costly SMS verification messages.

Historical Incidents

Reported SMS pumping incidents show how quickly costs can build:

Twitter's $60 Million Loss

In January 2023, Twitter owner Elon Musk said the platform lost more than $60 million to SMS pumping fraud. He named over 390 phone companies that took part in the scheme. While Twitter later questioned some claims, the case brought public attention to this type of fraud.

Industry-Wide Financial Impact

The Communications Fraud Control Association reports that SMS pumping caused global losses of $6.7 billion in 2021. Many companies do not share their fraud losses with the public.

Costs to Individual Businesses

Companies hit by these attacks pay between tens of thousands and millions of dollars each month in fake charges. These costs grow fast because each fake message costs much more than normal text rates.

Verification Policy Changes

Because of these threats, many large platforms have moved away from SMS codes. Twitter removed SMS verification for most users in March 2023, stating fraud as the reason.

Operational Disruptions

Beyond the cost of messages, businesses can face service problems during attacks. Real users may not get their codes on time. This can cause users to abandon transactions, contact support more often, and lose confidence in the company.

Rules and Enforcement

Rules to stop these attacks differ around the world. Some telecoms authorities have strict rules and fines for networks that allow fraud, but enforcement remains hard. Fraudsters use complex message routes that cross many countries to avoid getting caught.

Understanding the Stakeholders

SMS pumping involves these key groups:

Businesses

Companies use SMS to check user identity and send updates. They hire SMS gateway providers to handle their messages. When fraud happens, these businesses pay for the fake messages. Most find out about the attack only when they receive an unexpected bill.

SMS Gateway Providers

Companies like Twilio and MessageBird connect businesses to phone carriers. They give businesses tools to send text messages without working with phone networks directly. When fraud passes through their systems, these providers may try to stop it, but still charge businesses for the messages sent.

Mobile Network Operators (MNOs)

These companies run the networks that deliver messages to phones. Most work honestly, but SMS pumping schemes often include corrupt operators who charge extra fees for messages to numbers they control. These operators then split the money with the attackers who started the fraud.

Content Aggregators

These middlemen combine message traffic and work with many carriers to find the best routes. Most run honest operations, but their position in the message chain creates routing and oversight gaps that attackers can use.

Regulatory Bodies

Groups like the GSM Association create rules and standards for the industry. These rules are hard to enforce because phone networks cross many countries with different laws.

Financial Flow

The payment flow starts when businesses pay gateway providers to send messages. The gateway providers then pay fees to network operators based on where messages go. In fraud schemes, inflated fees go to corrupt operators who share the money with attackers. This creates a system where sending more fake messages makes more money for criminals while costing honest businesses more.

Effective Protection Strategies

Protecting your organisation usually requires several controls:

Basic Protections

Rate Limits: Restrict how many verification attempts a user can make in a set time period.
Traffic Pattern Checks: Track normal SMS message patterns and watch for changes that might indicate attacks.
Provider Protection: Services like Prelude's SMS Pumping Protection find and block messages to fake numbers.
Other Ways to Verify Users: Use app-based verification or push alerts instead of SMS codes.
Control by Country: Limit SMS verification to countries where you do business and add more checks for countries with higher fraud risk.
Work with Trusted Partners: Choose SMS service providers that focus on security and can help stop fraud quickly.

Advanced Protection Methods

Residential Proxy Detection: Find and block users who hide their true location behind home networks used as proxies.
Device Fingerprinting: Collect device signals to track users across sessions and spot when many verification requests come from the same device.
User Behaviour Tracking: Learn how real users act on your site and flag unusual actions that might be bots.
Machine Learning Systems: Use systems that learn from data to find hidden fraud patterns and adapt to new attack types.
Phone Number Checks: Use lists of known bad numbers to decide which phone numbers need more verification steps.
Verify in Multiple Ways: Ask users to prove who they are in different ways, such as email plus SMS, to make attacks harder.
Work with Other Companies: Share information about new attack methods and bad phone numbers with other businesses.
Watch Transactions as They Happen: Use systems that can pause message sending when they spot unusual patterns and learn from both legitimate and abusive traffic.

Measure the request before the message

The 2021 estimate establishes scale, not your current exposure. Start with your own send records: verification route, country and carrier, account or session, messages per destination, completion rate, provider cost and the time between requests. Join that with the edge decision that allowed the request to reach the SMS provider.

Rate limits should follow the business action, not only the source IP. A practical policy can count by route, destination prefix, account, device or network cohort, then step from logging to delay, challenge or block as confidence increases. Residential proxy and fingerprint signals can add context, but neither proves fraud on its own.

The messaging provider sees another part of the chain. Prelude's fraud controls can evaluate number and route risk while Peakhour controls the web request that initiated the send. Keep both outcomes in the same incident record so the team can tell whether it stopped a fraudulent request, suppressed a legitimate customer or merely moved the cost to another route.

Set a spending alert and an emergency send limit before the first incident. During an attack, preserve the requests, destinations, provider decisions and charges. Afterward, replay legitimate verification journeys and remove temporary blocks that no longer have a defined job.

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.

How Bots Are Corrupting Your A/B Testing Data

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

Bot traffic contaminates A/B testing results and can undermine marketing strategy. Your testing programme is exposed when residential proxy networks generate fake interactions (e.g. click fraud) that appear to come from your target market.

These residential proxies hide behind real household internet connections in the targeted geographic areas. When a bot network routes traffic through Sydney IP addresses to masquerade as real Australians, your analytics counts that traffic as legitimate local engagement. Because the traffic matches your demographic and geographic targeting profile, traditional detection methods become less effective.

This contamination affects the accuracy of the marketing strategy. Your A/B tests should show clear winners, but the results are masked by bot behaviour rather than real user preferences. Marketing teams then optimise campaigns from false signals, wasting budget and time on the wrong opportunities. The data starts driving decisions that harm conversion rates and revenue.

The scale of the problem continues to grow. Residential proxy services now offer millions of local IPs in every market. They rotate these IPs automatically and match real browser characteristics. Without specialised detection such as Peakhour A/B Testing Protection, this traffic can appear identical to genuine users in your analytics.

Each day without detection compounds the damage. Tests generate misleading data that guides strategic decisions. Marketing teams spend hours analysing invalid results and implementing changes that reduce performance. Budget allocated to testing delivers diluted ROI as optimisations based on bot data decrease conversion rates.

Traditional bot protection fails against this distributed threat. IP-based detection cannot identify residential proxy traffic that matches your target geography. Rate limiting proves ineffective against attacks spread across thousands of residential IPs. These bots evade basic JavaScript challenges through sophisticated browser emulation.

Peakhour's A/B Testing Protection uses network fingerprinting to detect residential proxy traffic. Our system analyses subtle patterns in how these proxies connect and behave, identifying bot networks that other solutions miss. We maintain a real-time database of residential proxy services to block new threats as they emerge.

Our customers have discovered that 40% of their test traffic came from bots. After implementing protection, they achieved:

Valid test results reflecting real user preferences
Increased conversion rates from accurate optimisation
Reduced waste of marketing team time and resources
Protection of testing budget from invalid traffic
Confidence in strategic decisions based on clean data

The rise of residential proxies has amplified bot threats to A/B testing. Traffic that appears to come from local users may mask sophisticated bot networks. Protecting your testing programme requires detection that goes beyond IP addresses and basic challenges. Contact us to learn how Peakhour can help secure your A/B testing data and keep optimisation decisions grounded in real users.

How MTU Fingerprinting Identifies VPNs and Mobile Users

2025-01-15T14:00:00+11:00

For traffic analysis, it helps to know how a user reached the service. Are they on a home network, a mobile connection, or a VPN? Deep packet inspection is invasive, but TCP handshake metadata can still carry useful context about the Maximum Transmission Unit (MTU) a connection appears to be using. By analysing those inferred MTU values, we can build "fingerprints" that point to the underlying network technology carrying the connection.

This article looks at how common technologies affect MTU values and shows how a SQL query can turn that data into useful network labels.

What is MTU and Why Does it Change?

The Maximum Transmission Unit (MTU) is the largest data packet, or frame, that a network-connected device can transmit. On standard Ethernet networks, this value is typically 1500 bytes. Larger payloads have to be split into chunks that fit that limit.

Encapsulation and Tunneling

The value starts to shift when tunnelling protocols are involved, including those used by VPNs and mobile networks. These protocols wrap the original data packet inside another packet, a process called encapsulation. The outer packet has its own headers for routing and management.

This encapsulation "steals" space from the original 1500 bytes available on the physical network. If a tunnelling protocol adds 60 bytes of headers, for example, the maximum size for the original data packet is now 1440 bytes (1500 - 60).

The Problem with Fragmentation

What happens if a device tries to send a 1500-byte packet through this 1440-byte tunnel? The packet has to be broken into smaller pieces, a process called fragmentation. It works, but it is inefficient. Fragmentation consumes CPU resources on the router performing it, adds header overhead to each fragment, and requires the receiving device to reassemble the pieces. The result is lower speed and higher latency.

To avoid that penalty, operating systems and network devices reduce the MTU of the connection to account for the tunnel's overhead. The amount of the reduction follows from the tunnelling protocol in use. That predictable drop is the basis for MTU fingerprinting.

A Guide to Common MTU Values

Different technologies add different overheads, which produces distinct MTU values.

WireGuard

WireGuard is a modern VPN known for its efficiency, but it still adds overhead.

IPv4 Overhead: 60 bytes (20-byte IPv4 header + 8-byte UDP header + 32-byte WireGuard header).
IPv6 Overhead: 80 bytes (40-byte IPv6 header + 8-byte UDP header + 32-byte WireGuard header).

On a standard 1500-byte network, that produces predictable MTU values:

1500 - 60 = 1440 bytes (WireGuard over IPv4)
1500 - 80 = 1420 bytes (WireGuard over IPv6)

There is a special case with ISPs that use DS-Lite (Dual-Stack Lite) to carry IPv4 traffic over an IPv6 network. This adds another 40-byte IPv6 header, reducing the MTU further.

1420 - 40 = 1380 bytes (WireGuard over DS-Lite)

OpenVPN

OpenVPN is another common VPN solution, but its fingerprint is less tidy. Instead of setting a static interface MTU, OpenVPN often uses a feature called mssfix. This dynamically adjusts the Maximum Segment Size (MSS) value within the TCP headers of encapsulated packets to prevent fragmentation.

The MSS is the MTU minus the IP and TCP header sizes (typically 40 bytes for IPv4). The exact MSS value, and therefore the effective MTU, depends on OpenVPN's configuration, including the transport protocol (UDP or TCP), cipher, MAC algorithm, and compression. As noted by security researcher ValdikSS, these unique MSS values can be used to fingerprint a connection with high precision. For example, a common configuration might result in an MSS of 1369, which corresponds to an effective MTU of 1409 (1369 + 40).

For general analysis, connections with an MTU around 1400 or 1380 bytes often indicate OpenVPN or other VPN usage, especially when seen with other factors.

Mobile Networks (LTE & 5G)

Mobile networks also modify MTU values. When your phone connects to the internet, its data is tunnelled through the carrier's network using the GPRS Tunnelling Protocol (GTP). This encapsulation adds its own layer of headers.

As detailed by Nick vs Networking, the typical overhead for GTP traffic over an Ethernet transport network is 50 bytes:

14 bytes for the Ethernet header
20 bytes for the outer IPv4 header
8 bytes for the UDP header
8 bytes for the GTP header

For a mobile carrier using a standard 1500-byte MTU on its transport network, the maximum MTU available to the user's device is 1450 bytes (1500 - 50).

Mobile devices don't guess this value; they are explicitly told what MTU to use by the network during the connection setup process (via Protocol Configuration Options). Mobile operators have two choices to avoid fragmentation:

Increase Transport MTU: Enable jumbo frames (for example, 1600 bytes or more) on their internal network to accommodate the 50-byte overhead and still provide a full 1500-byte MTU to the user.
Lower Advertised MTU: Advertise a lower MTU to the user's device. This is why values such as 1450 are common. Some operators may configure a more conservative MTU, such as 1300 bytes, to maintain stability across all parts of their network.

Other Common Values

Standard Ethernet: The baseline is 1500 bytes.
PPPoE: Common for DSL connections, adds 8 bytes of overhead, resulting in an MTU of 1492 bytes.
IPv6 Minimum: The IPv6 specification mandates a minimum MTU of 1280 bytes, so this value is also a significant marker.

Analysis with SQL

With this context, we can analyse network logs to classify user connections. The following SQL query buckets and attributes MTU values from a large dataset, turning raw numbers into meaningful labels.

The query works in several stages:

Extract Data: It parses the MTU from a fingerprint string in the logs.
Bucket MTUs: It uses a CASE statement to group MTUs. Specific known values, such as 1500, 1440, 1420, and 1380, go into their own buckets. Jumbo frames (>1500) are grouped into 100-byte buckets, and everything else is grouped into 20-byte buckets.
Attribute Buckets: In the final SELECT, another CASE statement translates those numeric buckets into human-readable descriptions based on the fingerprints we've identified.

The Query

-- Bucketing logic and attribution informed by research from:
-- https://ripx80.de/posts/06-wg-mtu/ (WireGuard)
-- https://medium.com/@ValdikSS/detecting-vpn-and-its-configuration-and-proxy-users-on-the-server-side-1bcc59742413 (OpenVPN)
-- https://nickvsnetworking.com/mtu-in-lte-5g-transmission-networks-part-1/ (Mobile Networks)
WITH base_data AS (
    SELECT
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[1])[4]) AS mtu,
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[1])[5]) AS wsize,
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[2])[1]) AS scale,
        (tls.handshake_rtt_us - tcp.min_rtt_us) >= 65000 AS is_high_latency
    FROM logs.client_logs
    WHERE time >= '2025-07-01' AND shielded = 0
),
main_aggs AS (
    SELECT
        CASE
            WHEN mtu = 1500 THEN 1500
            WHEN mtu = 1440 THEN 1440
            WHEN mtu = 1420 THEN 1420
            WHEN mtu = 1380 THEN 1380
            WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
            ELSE intDiv(mtu, 20) * 20
        END AS mtu_bucket,
        countIf(is_high_latency) AS high_latency_count,
        countIf(not is_high_latency) AS normal_latency_count,
        round(avg(wsize * pow(2, scale))) AS avg_real_wsize
    FROM base_data
    WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
    GROUP BY mtu_bucket
),
top_wsizes AS (
    SELECT
        mtu_bucket,
        groupArray((wsize, cnt)) AS top_wsizes
    FROM
    (
        SELECT
            CASE
                WHEN mtu = 1500 THEN 1500
                WHEN mtu = 1440 THEN 1440
                WHEN mtu = 1420 THEN 1420
                WHEN mtu = 1380 THEN 1380
                WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
                ELSE intDiv(mtu, 20) * 20
            END AS mtu_bucket,
            wsize,
            count() AS cnt,
            row_number() OVER (PARTITION BY mtu_bucket ORDER BY cnt DESC) AS rn
        FROM base_data
        WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
        GROUP BY mtu_bucket, wsize
    )
    WHERE rn <= 5
    GROUP BY mtu_bucket
),
top_scales AS (
    SELECT
        mtu_bucket,
        groupArray((scale, cnt)) AS top_scales
    FROM
    (
        SELECT
            CASE
                WHEN mtu = 1500 THEN 1500
                WHEN mtu = 1440 THEN 1440
                WHEN mtu = 1420 THEN 1420
                WHEN mtu = 1380 THEN 1380
                WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
                ELSE intDiv(mtu, 20) * 20
            END AS mtu_bucket,
            scale,
            count() AS cnt,
            row_number() OVER (PARTITION BY mtu_bucket ORDER BY cnt DESC) AS rn
        FROM base_data
        WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
        GROUP BY mtu_bucket, scale
    )
    WHERE rn <= 5
    GROUP BY mtu_bucket
)
SELECT
    CASE
        WHEN mtu_bucket IN (1500, 1440, 1420, 1380) THEN toString(mtu_bucket)
        WHEN mtu_bucket > 1500 THEN concat(toString(mtu_bucket), '-', toString(mtu_bucket + 99))
        ELSE concat(toString(mtu_bucket), '-', toString(mtu_bucket + 19))
    END AS mtu_range,
    CASE
        WHEN mtu_bucket = 1500 THEN 'Standard Ethernet'
        WHEN mtu_bucket = 1480 THEN 'Likely PPPoE (e.g., 1492)'
        WHEN mtu_bucket = 1460 THEN 'Likely DS-Lite/GRE Tunnel'
        WHEN mtu_bucket = 1440 THEN 'Likely Mobile LTE/5G (e.g., 1450) / WireGuard over IPv4'
        WHEN mtu_bucket = 1420 THEN 'WireGuard over IPv6'
        WHEN mtu_bucket = 1400 THEN 'Likely OpenVPN / Mobile'
        WHEN mtu_bucket = 1380 THEN 'Likely OpenVPN / WireGuard over DS-Lite / Mobile'
        WHEN mtu_bucket = 1300 THEN 'Likely Mobile LTE/5G configured'
        WHEN mtu_bucket = 1280 THEN 'IPv6 Minimum'
        WHEN mtu_bucket > 1500 THEN 'Jumbo Frame'
        ELSE 'Other'
    END AS mtu_attribution,
    high_latency_count,
    normal_latency_count,
    round(high_latency_count / (high_latency_count + normal_latency_count), 2) AS high_latency_ratio,
    top_wsizes,
    top_scales,
    avg_real_wsize
FROM main_aggs
LEFT JOIN top_wsizes USING (mtu_bucket)
LEFT JOIN top_scales USING (mtu_bucket)
WHERE (high_latency_count + normal_latency_count) > 10000
ORDER BY mtu_bucket
LIMIT 50 FORMAT Vertical

Why Jumbo Frames Matter

Jumbo frames (MTU values greater than 1500 bytes) are a useful edge case in MTU fingerprinting. These frames, typically ranging from 9000-9216 bytes, are primarily used in high-performance computing environments, data centres, and enterprise networks where throughput optimisation is important.

When we detect jumbo frame MTUs in our analysis, they often indicate:

Enterprise Users: Corporate networks frequently enable jumbo frames for internal communications
Data Centre Traffic: Cloud services and CDNs often use jumbo frames between their infrastructure
High-Performance Applications: Video streaming, large file transfers, and backup operations can benefit from larger frame sizes
Network Misconfiguration: Jumbo frames sometimes appear because of network equipment misconfiguration

The presence of jumbo frames can help distinguish consumer and enterprise traffic, adding useful context for traffic classification and security analysis.

Practical Use Cases and Applications

MTU fingerprinting is useful across several security and operational domains:

Security Applications

VPN Detection for Compliance: Organisations can identify employees bypassing corporate network policies with personal VPNs, supporting compliance with data governance requirements.

Bot Traffic Classification: Automated traffic from residential proxy networks often shows consistent MTU patterns that differ from genuine residential users, improving bot detection.

Threat Intelligence Enhancement: Correlating MTU patterns with other indicators helps build broader threat profiles and improves attack attribution.

Network Operations

Performance Optimisation: Understanding the MTU distribution of your user base helps optimise content delivery and reduce fragmentation-related performance issues.

Infrastructure Planning: MTU analysis reveals the underlying network technologies your users employ, informing CDN placement and capacity planning decisions.

Quality of Service: Different MTU patterns correlate with connection quality, enabling proactive support for users on constrained networks.

Business Intelligence

Market Analysis: Geographic and demographic patterns in MTU distribution reveal technology adoption trends and market characteristics.

User Experience Optimisation: Identifying users on mobile or constrained networks enables adaptive content delivery and interface optimisation.

Dynamic Analysis vs Static IP Databases

MTU fingerprinting is a dynamic signal, which makes it useful alongside static IP reputation databases. It has several practical advantages:

Real-Time Adaptation

Static IP databases go stale. A residential IP address might be flagged as malicious based on historical activity, but MTU fingerprinting analyses the current network configuration. This dynamic approach captures the infrastructure being used at the moment of connection, providing more accurate and timely intelligence.

Treat the value as path evidence

An inferred MTU can narrow the possible network paths behind a connection. It cannot prove that a user is on a particular VPN, mobile carrier or proxy. Different tunnels can produce the same value, endpoints can set their own MTU, and the capture point may not see the smallest link on the complete path.

That makes MTU useful beside IP, ASN, TLS, HTTP and behavioural evidence. It can help explain why two requests that share an IP look different, or why requests from rotating IPs still appear to use the same tunnel shape. Whether it improves a decision—and whether it changes false positives—has to be measured on local traffic.

Where MTU fits

MTU fingerprinting turns TCP handshake metadata into a supporting signal, not a network identity. Record the observed TCP value, inference method and capture point so an operator can see why a label was suggested.

Start by logging the signal on one route. Compare it with known mobile, residential, corporate and VPN traffic before it affects enforcement. If the cohorts overlap too heavily, keep the value for investigation rather than forcing it into a block rule.

The Hidden Cost of Click Fraud

2025-01-14T13:00:00+11:00

Marketing organisations are losing money to automated clicks and fake impressions. These attacks drain advertising budgets and corrupt the data CMOs rely on for strategic decisions. The lost money cannot be recovered, but understanding the scale and mechanics of click fraud helps marketing teams protect future investment and optimise campaigns.

The Scale of Click Fraud

Click fraud now consumes 40% of digital advertising budgets through fake clicks and impressions that never reach real customers. It affects every digital marketing channel, from pay-per-click and display advertising to social media campaigns, retargeting, and video advertising. The damage goes beyond direct financial loss, because it also corrupts the metrics teams use for decision-making.

Our research on bot traffic shows the percentage of fraudulent clicks continues to rise each quarter. Marketing teams that ignore this threat base their strategies on flawed data, which leads to misallocated resources and weaker campaign performance.

How Bots Generate Fake Clicks

Automated bots generate clicks and impressions at scale across digital advertising platforms. These programs target competitor advertisements to drain marketing budgets through fake clicks. They create artificial impressions that inflate metrics and send false engagement signals. Bots also manipulate bidding algorithms and skew attribution data, leading to misallocated advertising resources.

Modern bots use more advanced techniques to evade standard security controls. They mimic human behaviour patterns and rotate through different IP addresses to avoid detection and blocking.

The Residential Proxy Challenge

Residential proxies create a significant obstacle for click fraud detection systems. These proxy services route bot traffic through IP addresses assigned to real consumers' homes and devices, making fraudulent traffic look legitimate to traditional anti-bot tools.

Residential proxy networks build their IP pools through multiple channels. They partner with consumer VPN services, distribute browser extensions, embed code in mobile applications, and in some cases exploit compromised devices. This mix gives proxy operators access to millions of residential IP addresses.

Traditional IP reputation services fail to identify this proxy traffic. Our research demonstrates these services miss up to 96% of residential proxy traffic, leaving advertising campaigns exposed to fraud through these channels.

Impact on Marketing Strategy

Click fraud undermines three core areas of marketing decision-making. First, it distorts campaign performance metrics through false click-through rates and inflated impression counts. The fraud creates skewed conversion data and engagement metrics that mask true campaign performance.

In budget allocation, click fraud wastes marketing spend on non-existent users while reducing campaign ROI. Artificially inflated acquisition costs lead marketing teams to misallocate resources across channels and campaigns.

Strategic planning suffers when data is contaminated across multiple dimensions. A/B testing results become invalid when bots generate fake interactions. Geographic and demographic data lose accuracy due to proxy traffic. Competitive intelligence becomes unreliable as bot activity masks true market dynamics.

Marketing teams that base decisions on corrupted data take on significant risk. Their optimisation efforts target bot behaviour instead of real users. Campaign budgets flow to channels dominated by fraud. Strategic initiatives fail because decisions are based on artificial metrics rather than genuine customer behaviour.

Protecting Your Marketing Investment

Lost money from click fraud cannot be recovered, so marketing teams need protection measures for future investment. Detection forms the first line of defence through continuous monitoring of traffic patterns and IP reputation analysis. Teams track user behaviour to identify suspicious patterns that indicate fraud.

Prevention requires a multi-layered security approach. Marketing teams need systems that block known bot networks and detect residential proxies attempting to generate fake clicks. These controls validate real user traffic and filter out fraudulent clicks before they affect campaigns.

Campaign optimisation becomes more useful once fraud protection is in place. Teams can adjust targeting parameters based on genuine user data and reallocate budgets to channels with verified traffic. This supports updates to bidding strategies and refinement of audience segments based on real engagement.

Our Ad Fraud Protection solution protects marketing investment by blocking bot traffic, detecting residential proxies, and validating real users. This helps ensure ad spend reaches genuine customers rather than fraudulent clicks.

Making Informed Decisions

Understanding click fraud changes how marketing teams analyse data and plan campaigns. Data analysis starts with identifying corrupted metrics in campaign reports. Teams must filter bot traffic from their analytics to measure real user engagement. This enables tracking of true campaign performance based on human interactions.

Budget planning improves once teams understand the scale of click fraud. Marketing teams can allocate resources to channels with verified human traffic. This focus on real users optimises campaign spend and improves return on investment across marketing initiatives.

Strategy development depends on clean, accurate data. Teams make decisions based on genuine user behaviour rather than bot interactions. Campaign planning targets real audience segments with messages that resonate. Performance measurement reflects actual results rather than artificial engagement.

Taking Action

Marketing teams need protection measures across three key areas to secure their investments. First, bot protection forms the foundation through deployment of bot management systems. These systems block automated traffic while validating real users and monitoring for suspicious patterns.

The second protection layer focuses on residential proxy detection. Teams implement proxy detection to identify and block proxy networks. This helps ensure traffic comes from real IP addresses and prevents fraud through residential proxies.

The third component centres on protecting ad spend through traffic monitoring. Teams implement systems to block fraudulent clicks and validate impressions. This enables tracking of real engagement from genuine users.

Our Traffic Control solution combines these protection measures to help marketing teams secure their investments and base decisions on real user data.

Conclusion

Click fraud threatens marketing budgets and corrupts campaign data. Lost money cannot be recovered, but understanding and preventing fraud helps marketing teams protect future investment and make better decisions.

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 Australian epidemic of Account Takeover attacks

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

In recent months, credential stuffing attacks have hit a number of Australian businesses, leading to compromised accounts, fraudulent purchases, and customer complaints. The pattern is a reminder that account protection cannot stop at password policy or MFA alone.

A Case Study in Credential Stuffing

Security researcher Jacob Larsen has documented a credential stuffing operation targeting Australian businesses. Larsen's research, detailed in his blog post, describes the activity of a threat actor known as "Crabby," who has sold compromised Australian accounts since July 2023.

Larsen's findings show:

The operation began with a threat actor called "Based" selling compromised accounts via Discord and dedicated websites.
In November 2023, the operation was acquired by "Juicy," a notorious account vendor, and rebranded as "Crabby."
As of May 2024, over 19,000 compromised accounts from various Australian brands were offered for sale.
Low-level fraudsters purchasing these accounts have used them to make unauthorised purchases, often targeting high-value items for resale.

The Crabby operation shows how credential stuffing has moved beyond isolated login attempts. It now includes account marketplaces, low-level fraud buyers, and the challenges businesses face once compromised accounts are monetised.

The Difficulty of Defense

Credential stuffing defence is harder when attacks are spread across residential proxies and kept to single attempts per account.

Residential Proxies: The Invisible Threat

Residential proxies weaken traditional IP-based controls. These proxies use IP addresses assigned to real residential internet connections, so malicious traffic can look like normal customer traffic. That helps attackers bypass simple rate limiting and geolocation checks.

That distribution makes login traffic harder to classify. Signals such as a high volume of attempts from one IP address become less useful when attackers can spread requests across a pool of residential IPs.

Single-Hit Attacks: Precision Strikes

Single-hit attacks are another way attackers avoid noisy patterns. In this approach, each stolen credential is used only once per target site, reducing the chance of detection by traditional rate-limiting or anomaly detection systems.

By limiting each credential to one attempt, attackers avoid controls tuned to repeated login failures. A business can have rate limiting in place and still miss credential stuffing that never crosses those thresholds.

The Mobile API Conundrum

As mobile applications become a primary user interface, credential stuffing also moves into mobile API traffic. Traditional bot protection often relies on JavaScript challenges or browser fingerprinting, which does not apply cleanly to attacks against mobile APIs.

Mobile applications typically communicate with backend services via APIs, bypassing the browser environment where many bot detection techniques run. This creates several challenges:

Lack of JavaScript Execution: Mobile APIs don't execute JavaScript, making it impossible to use browser-based bot detection techniques.
Limited Fingerprinting Capabilities: Standardised mobile API requests make it difficult to distinguish between legitimate user activity and automated attacks based on request characteristics.
Increased Attack Surface: More mobile apps means more potential entry points for attackers, making comprehensive protection more complex.
Authentication Simplification: To improve user experience, mobile apps often use simplified authentication flows, which can create weaker controls against automation.

This gap needs API-centred controls that can assess mobile login behaviour without relying on browser-only signals.

Framing Credential Stuffing as a Business Risk

Credential stuffing should be treated as a business risk, not just an authentication issue. The impact can include refunds, chargebacks, customer support load, reputational damage, and regulatory disclosure work.

Risk Quantification and Disclosure

Risk quantification gives security teams a way to explain credential stuffing in business terms. By applying frameworks like FAIR (Factor Analysis of Information Risk), businesses can:

Quantify the potential financial impact of credential stuffing attacks.
Prioritise security investments based on risk reduction potential.
Communicate the importance of cybersecurity measures to non-technical stakeholders.

CPS 234 in Australia adds a disclosure dimension for regulated entities. Businesses need to protect against credential stuffing and be able to explain their exposure, controls, and mitigation strategy.

The State of Credential Stuffing Defense in Australia

Our recent survey of Australian businesses shows uneven adoption of credential stuffing defences:

While 77% of respondents use Multi-Factor Authentication (MFA), only 40% have implemented bot protection measures.
15% of companies chose not to respond to questions about their security measures, suggesting potential gaps in protection.
Just 29% of businesses check credentials against known breaches, leaving a large window of opportunity for attackers using stolen credentials.
Only 15% of organisations use residential proxy detection, a critical component in identifying and mitigating modern credential stuffing attacks.

These results suggest a gap between how credential stuffing is run now and the controls many Australian businesses have in place.

Recommendations for Enhanced Protection

Based on our analysis and survey results, businesses should review the following controls:

Implement Advanced Bot Protection: Deploy controls that detect and mitigate bot attacks, including attacks using residential proxies.
Enhance Mobile API Security: Use mobile API controls that focus on anomaly detection and behavioural analysis rather than browser-based techniques.
Adopt Risk-Based Authentication: Implement dynamic authentication mechanisms that adjust based on the assessed risk of each session or transaction.
Utilise Breached Credential Databases: Check user credentials against known breach databases and enforce password changes for compromised accounts.
Implement Residential Proxy Detection: Use technology that identifies and mitigates traffic from residential proxy networks. This is a key control for modern credential stuffing attacks.
Apply Advanced Rate Limiting: Utilise device fingerprinting and other identifiers beyond IP addresses to implement more effective rate limiting, particularly for single-hit attacks.
Employ Contextual Security: Use signals such as user behaviour patterns, device characteristics, and historical usage to identify anomalies that may indicate credential stuffing attempts.
Quantify and Communicate Risk: Use frameworks like FAIR to quantify the potential impact of credential stuffing attacks and communicate this risk to stakeholders.
Implement Continuous Monitoring: Deploy real-time monitoring that detects patterns indicative of credential stuffing attacks, and update defences as attack methods change.

These controls address the specific problems created by residential proxies, single-hit attempts, mobile API traffic, and weak credential hygiene. They also reflect the limits of IP-only rate limiting and browser-only bot detection.

Credential stuffing defence works best as a layered programme: bot detection, residential proxy detection, breached credential checks, mobile API coverage, and risk reporting. The practical goal is to stop account takeover attempts earlier, reduce fraud exposure, and give security teams evidence they can act on.

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 Cost of Credential Stuffing

2024-07-17T00:00:00+10:00

In recent months, Australian businesses have faced a wave of credential stuffing attacks. These attacks do not require the affected website itself to be breached. They target customer accounts, leading to fraudulent transactions. The damage is practical as well as reputational: disputed purchases, refunds, locked accounts, and customers asking how someone else was able to use their account.

What is Credential Stuffing?

Credential stuffing occurs when attackers use login details obtained from a data breach to access accounts on other sites. Criminals test millions of credentials against a target website to identify working combinations. This attack affects users who reuse passwords across multiple services [1].

The Scale of the Problem

Tens of thousands of Australian online accounts are reported to have been accessed since late November 2023 [2]. The attacks affected major retailers and service providers, including:

The Iconic
Guzman y Gomez
Dan Murphy's
Event Cinemas
Stan

The Impact

While reusing passwords between sites has long been considered poor security practice, users still do it. Blaming the customer, as 23andMe did in its response to an attack, is not a serious account protection strategy. Over 70% of Americans believe that websites have a responsibility to prevent account takeovers via stuffing attacks. Not doing so can negatively impact a business in several ways.

Financial Impact

The cost can fall on either the affected business or the affected customer. Fraudsters made significant purchases using compromised accounts. One scammer claimed to have spent over $800 on high-end alcohol at Dan Murphy's [2]. Others bought iPhones and clothing. Either the customer will be out of pocket, or the business when the customer issues a chargeback on the purchase.

Reputation Damage

The attacks leave businesses dealing with customer complaints, refunds, and visible questions about account security. The Iconic pledged to refund affected customers [1]. Dan Murphy's confirmed that a "small number of user accounts were subject to fraudulent transactions" [3].

Customer Trust

These incidents erode customer trust. Users expect businesses to make account abuse difficult, even when the original password leak happened somewhere else. When accounts are taken over, customers question the security practices of the affected companies.

Business Response

Companies responded by:

Locking compromised accounts
Issuing refunds
Encouraging customers to change passwords
Implementing stronger security measures

Dan Murphy's advised customers to "practise good password hygiene, using a strong password and changing it periodically" [3].

Prevention Strategies

To protect against credential stuffing, businesses should:

Implement multi-factor authentication
Educate customers about password security
Monitor login behaviour on their website
Implement, and regularly update, security measures, including bot management and advanced rate limiting.

Credential stuffing is not just a password reuse problem. It is an account protection problem, and businesses that sell online need controls that make stolen credentials harder to turn into purchases.

Sources:

[^1^] ABC News: "The Iconic was hit by criminals taking money by 'credential stuffing'. How can you stay safe?" [^2^] Cyber Daily: "Guzman y Gomez, Dan Murphy's customers affected in credential stuffing campaign" [^3^] The Sydney Morning Herald: "Thousands of Australians hacked in 'credential stuffing' credit card scam"

2024 Survey Insights

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

Our recent survey of Australian CISOs and CTOs looked at account protection controls, planned security measures, and how teams are responding to credential stuffing and residential proxies. Key findings:

Multi-Factor Authentication (MFA) Adoption: 76.23% of Australian businesses use MFA, showing broad adoption of a baseline account security control.
Bot Protection: Currently implemented by 39.34% of organisations, with an additional 34.65% planning to adopt it.
Bot Management Solutions: Cloudflare is the most common bot management provider in the survey, used by 48.24% of respondents.
Residential Proxy (Resip) Detection: Only 13.11% of organisations currently use this technology, although many plan to implement it to address residential proxy traffic.
Credential Stuffing Concerns: Businesses are planning measures to reduce credential stuffing risk, including bot protection, MFA, and checking credentials against known breaches.
Mobile Security Gap: Low adoption of Web Application and API Protection (WAAP) suggests gaps in mobile application security.
Executive vs. Engineer Priorities: The survey showed different cybersecurity priorities between executives and engineers.

These findings point to the need for account protection strategies that go beyond MFA and address automated traffic, breached credentials, and residential proxies.

2024 Survey Insights

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

Recent customer account takeovers have put account protection back on the agenda for Australian businesses. Our 2024 survey of Australian CISOs and CTOs shows how respondents are using MFA, bot protection, WAAP and residential proxy detection to manage credential stuffing and account takeover risk.

Account Protection: Current State and Future Plans

Our survey found 76.23% of Australian businesses use Multi-Factor Authentication (MFA). MFA is widely adopted, but it is not a complete account protection strategy on its own.

39.34% of organisations currently use bot protection. That matters because credential stuffing is automated by design. Another 34.65% of businesses plan to implement bot protection in the future.

The pattern is clear: many organisations are treating MFA as a baseline and looking at additional controls around it.

Current Bot Management Solutions

The survey also asked which bot management solutions Australian businesses currently use. Cloudflare was the clear leader, with nearly half of respondents using its services.

The breakdown of bot management solutions is as follows:

Cloudflare: 48.24%
AWS WAF Bot Ruleset: 10.59%
Other solutions make up the remaining percentage

This distribution is concentrated around Cloudflare. Outside that, the remaining respondents are spread across other solutions rather than one clear alternative.

Tooling matters here. Residential proxy traffic weakens IP reputation and simple rate limits, so detection capability, request grouping and response controls matter as much as vendor name. If residential proxies continue to feature in credential stuffing tooling, this mix may shift as teams look for more advanced protection measures.

The Rising Threat of Residential Proxies

A key finding from our survey is the low adoption rate of residential proxy (resip) detection, with only 13.11% of organisations currently using this technology. Planned adoption suggests teams are starting to account for the risk, but current coverage is still low.

Resips are difficult for account security teams because malicious traffic can look like normal ISP traffic. They enable attackers to:

Bypass traditional IP-based rate limiting
Evade geolocation-based restrictions
Conduct large-scale credential stuffing attacks
Scrape sensitive data undetected

The planned adoption of resip detection points to a shift in security strategies, away from simple IP-based controls and towards more specific network signals.

Learn more about the threat of residential proxies and how to detect them

Credential Stuffing: A Persistent and Growing Concern

Credential stuffing attacks continue to be a major concern for businesses. These attacks exploit password reuse across multiple sites, allowing attackers to gain unauthorised access to user accounts.

Respondents said they plan to implement several measures to reduce credential stuffing risk:

34.65% plan to implement bot protection
32.67% intend to add multi-factor authentication
31.68% aim to check credentials against known breaches

These plans point to layered account protection rather than reliance on one control.

Mobile Applications: An Emerging Attack Surface

While mobile applications were not directly addressed in our survey, the data suggests a possible gap in mobile security strategies. The low adoption rate of Web Application and API Protection (WAAP) - implemented by only 27.87% of respondents - indicates many businesses may be underprepared to protect their mobile assets.

As mobile apps become primary interfaces for critical operations, this gap leaves businesses exposed to attacks that use the same automation and resip infrastructure seen on web login flows.

Balancing Security and User Experience

The operational problem is familiar: increase assurance without making login unusable. Key considerations for enhancing account protection while preserving usability include:

Expanding beyond MFA
Implementing bot protection
Adopting WAAP solutions
Monitoring credential leaks
Focusing on API security
Implementing residential proxy detection

Explore strategies for balancing security and user experience

Executive vs Engineer Perspectives

Our survey found differences in cybersecurity priorities between executives and engineers:

Figure 3: Comparison of cybersecurity priorities between executives and engineers

The gap matters because budget, architecture, and incident response are often owned by different teams. Account protection plans need to cover both executive risk concerns and engineering realities, including the threat from RESIPs.

Final Thoughts

Our 2024 survey results point to a simple position: MFA is widely used, but it is not the whole account protection strategy. Bot protection, breached credential checks, WAAP and residential proxy detection are still unevenly adopted. That matters because credential stuffing does not depend on one weakness; it combines reused credentials, automation, proxy networks and weak response controls.

Australian businesses do not need every control at once, but they need a layered plan that reflects how account takeover attacks are run now. For teams reviewing their controls, resip detection and mobile/API coverage are worth checking explicitly because both are easy to miss if the programme is still centred on MFA and IP reputation.

Application Security Beyond MFA

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

Multi-factor authentication (MFA) remains a useful defence against account takeovers, but it is not a complete control. Attackers increasingly work around MFA with social engineering, automation, and infrastructure that makes malicious traffic look ordinary.

MFA answers one narrow question: can the user present a second factor at this point in the flow? That is valuable. It does not prove the password was safe, the session will remain safe, the device is trusted, or the person entering the code has not been manipulated. Account protection needs to cover the request path before MFA, around MFA, and after MFA.

OTP Bots Target the Human, Not the Cryptography

A Kaspersky article describes the rise of OTP bots: tools that call or message users and convince them to hand over one-time passwords. The attacker does not need to break the MFA system. They need the victim to read out a fresh code at the same moment the attacker is logging in.

The usual flow is simple. The attacker obtains a working username and password from a breach, phishing kit, or credential stuffing result. They attempt a login, which triggers an OTP. The victim receives a call or message claiming to be from the bank, retailer, courier, or support team. The story is urgent enough to make the code feel like part of protecting the account, not compromising it.

AI phone assistants such as Lucy are built for legitimate business use, but similar conversational technology lowers the effort required to run more convincing criminal call flows. The security issue is not that AI magically defeats MFA. It is that a fluent, responsive call can make social engineering less scripted and harder for a user to dismiss.

This is why "we have MFA" should not end the account protection conversation. MFA can stop many stolen-password logins, but it cannot reliably stop a user from being tricked in real time.

Residential Proxies Weaken the Surrounding Checks

Attackers also work to make the login itself look unremarkable. Residential proxies route traffic through IP addresses assigned to ordinary home or mobile internet connections. That lets malicious traffic borrow the appearance of normal customer traffic.

Traditional controls often lean too heavily on IP address, geolocation, and request volume. Residential proxy networks weaken all three. An attacker can rotate through many IPs, keep each source below a simple rate limit, and choose an exit location that roughly matches the victim's country or city. If the login looks local enough, the MFA challenge may be the only control left.

That is a poor place to put all the risk. A login with a correct password, a plausible IP address, and a successful OTP can still be an account takeover. The system needs to keep evaluating the request: device and browser signals, network fingerprint, known breached credentials, velocity across accounts, and behaviour after login.

Automation Happens Before and After MFA

MFA is usually visible at the point of login, but account takeover campaigns are broader than one prompt. Bots test credential pairs across login forms and APIs. Tools such as OpenBullet and similar automation frameworks can replay login flows at scale. Breached credential lists give attackers a cheap starting point because password reuse remains common.

Once an attacker gets through, the next actions matter. They may change the email address, add a device, disable notifications, alter delivery details, use stored payment methods, transfer value, or test what the account can access. If monitoring treats a successful MFA as the end of risk, those actions can happen inside a trusted session.

The defence needs to be layered around the actual attack path:

Check credential risk before and during login, especially known breached username and password pairs.
Use bot and browser signals to detect automation even when traffic is distributed.
Rate limit on better keys than IP alone, such as TLS or HTTP/2 fingerprints, headers, routes, ASNs, countries, and account behaviour.
Treat residential proxy evidence as a risk input, not just an allow-or-block label.
Monitor session and account changes after MFA, then challenge, hold, revoke, or review when behaviour changes.

This does not mean every login needs more friction. It means the system should have more choices than "ask for MFA" or "allow". A low-risk login from a known device can keep moving. A login using breached credentials through proxy infrastructure can be slowed, challenged, or blocked before the user receives a confusing call. A successful login followed by high-risk account changes can trigger fresh verification or session invalidation.

Controls Around MFA

Peakhour's Advanced Rate Limiting helps reduce reliance on IP address by grouping and limiting requests using signals such as HTTP/2 and TLS fingerprints, ASNs, countries, request headers, and route context. That matters when credential stuffing is spread across residential proxies.

Peakhour's Bot Management adds another layer by looking for automation, browser inconsistency, suspicious device patterns, and residential proxy use. The aim is to identify the machinery behind the attack before it becomes a clean-looking login attempt.

Peakhour's Account Protection brings those signals closer to the account decision. Breached credential checks, bot evidence, rate limits, proxy context, custom rules, and monitoring should all feed the decision to allow, challenge, rate limit, block, log, or review.

User education still has a place, especially around OTP sharing and unexpected calls. It should not be the main control. Users are asked to make security decisions at bad moments, often under pressure, with limited context. Technical controls should reduce the number of times an attacker can create that moment.

MFA Still Belongs in the Stack

The point is not to remove MFA. Strong MFA, especially phishing-resistant methods, raises the cost of account takeover and should remain part of the stack. The mistake is treating MFA as proof that the account is safe.

Account protection works better when MFA is one decision point inside a wider system. The login attempt, credential history, network path, device, session, account changes, and transaction behaviour all carry evidence. MFA is useful evidence. It is not the whole case.

Rate Limiting for API Security

2024-01-24T13:00:00+11:00

Rate limiting prevents servers from being overwhelmed by too many requests in a short period of time. Typically, rate limiting is configured using rules made up of a filter, for example a path like /login, and a limit on the number of requests a user can make in a given time, such as 10 requests in a minute. If a user exceeds this limit, they are usually blocked for a timeout period.

But how do you identify a user? Traditionally rate limiting has used the IP address for grouping requests, assuming that requests from the same IP address will be the same user. That assumption is now weak. IP addresses are rarely static and are often shared. For example, an office network might have hundreds of individual computers in it but present a single IP address for all those computers to the internet. Mobile operators commonly use carrier-grade network address translation (CGNAT) to share the same IP across thousands of devices or users. Bot networks, seeking to avoid security controls like rate limiting, will rotate their requests through thousands of different IP addresses. This makes rate limiting based on IP addresses a poor choice from both a functional and a security perspective.

Introducing Advanced Rate Limiting

Peakhour's Advanced Rate Limiting service lets you create filters using any HTTP request characteristic, for example URI, request method, headers, cookies, country, network fingerprints and more. You can also use response headers and response codes, so a rule can count failed login attempts, repeated 404s from a scraper, or traffic that crosses an API threshold.

For counting requests you can use the following fields for grouping:

IP Address
ASN
Country Code
HTTP/2 Fingerprint
TLS Fingerprint
Any combination of Request Headers

You can use one of those fields, or a combination of them, to identify users with more control than IP address alone.

You can also separate the filter and mitigation expression. For example excessive attempts to /login can be blocked on the entire site.

This matters because rate limiting is not just a request counter. In Peakhour it sits beside bot management, WAF, DDoS protection, traffic controls, and origin shielding on the same managed edge path. That gives operators a practical way to set different thresholds for verified crawlers, suspicious automation, authenticated API clients, and normal visitors without pushing every policy change into the application. It also gives them allowed, blocked, and threshold-hit evidence to tune the rule after it is deployed, whether Peakhour is the active edge or adding controls beside an existing CDN or cloud edge.

Putting it into action

Advanced Rate Limiting can help protect applications from attacks like Layer 7 DDoS, Account Takeovers, Credential Stuffing, and more. Here are some real world examples you can configure using our dashboard and API.

Protect against general site abuse

Our example website is a medium-sized ecommerce store that has page URLs ending in /. It serves Australian clients and typically sees around 100 page requests a minute from non-search-engine traffic during peak traffic times. With that baseline, we can set up rate limiting to prevent general site abuse and protect against layer 7 DDoS attacks.

Peakhour rate limiting starts with zones. You specify your request limits in these zones.

Here we've specified a maximum of 45 requests in 1 minute. We're going to apply this limit to page loads only. Since our typical maximum for all users on this website is 100 in a minute, it seems reasonable that a real user is not going to view 40 pages in 1 minute. We could also specify a value for error responses in a minute. An error could be a 404, which a scraper might typically get when looking for removed URLs.

Now let's define our filter and our counter. For our filter we mentioned that pages end in /, so we'll use that, but exclude verified bots to make sure they're not restricted when crawling the site. A verified bot is a crawler like Google or Bing, that Peakhour has verified as legitimate by using reverse DNS to confirm they are who they say they are.

Attackers, scrapers, and others looking to abuse a site will launch an attack using a particular piece of software. That piece of software will have a TLS fingerprint (like JA3) that remains the same, even as the attacker rotates their user-agent, IP address, and other characteristics, so we'll use the TLS fingerprint as our request counter.

Rate Limit authenticated API Users

It is common for APIs to require an Authorization header as part of the request to authenticate access. By grouping requests on the value of this header, we can rate limit a specific API client even if it uses multiple applications, or if its credentials are stolen.

Protecting from Account Takeovers

Account Takeover attacks have been in the news recently, with several high-profile websites being victims. Credential Stuffing and Brute Force attacks rely on attempting lots of logins to identify valid credentials. Along with lots of attempts come lots of failures. Attackers will rely on software like openbullet to carry out their attacks, using proxy networks to constantly rotate IP addresses and defeat traditional rate limiting.

The program the attacker is using will present a consistent TLS fingerprint. We can make a special rule for our login form that tracks failed login attempts by TLS Fingerprint, effectively tracking the attacker as they rotate IP address.

If the attack is low and slow, we can track failed attempts over a longer timeframe by using the response from the server when adding to our counting zone.

Final Thoughts

Advanced rate limiting is a practical response to the limits of IP-based controls. IP address rotation is the standard amongst attackers and scrapers, rendering the traditional approach obsolete. Useful protection now needs to identify the actor behind the requests, protect the origin before expensive application work is triggered, and give teams enough evidence to adjust the policy without guesswork. Counting requests against a combination of network fingerprints, request fields, response signals, and bot context is how you stop abuse from scrapers, SEO spiders, and layer 7 attackers without treating every visitor the same.

Web scraping another Business' website

2023-10-11T13:00:00+11:00

As businesses continue to build their presence online, screen scraping is becoming more prevalent. Screen scraping is the use of software or code to take data from another website. For example, popular platforms like Skyscanner or booking.com usually take price data on flights and accommodation and display it on their websites. However, Australian copyright laws or the website owner’s terms and conditions may forbid you from screen scraping. This article explains the legal aspects of scraping data from another business’ website and the precautions you should take.

Am I Violating the Law by Screen Scraping?

Australian copyright law safeguards ‘original creative works’, including:

written works;
visual images;
music; and
moving images.

Copyright can also protect documents such as government reports and legal forms. When determining whether copyright protects a creative work, the work does not need to be intricate or of high quality. It only needs to demonstrate originality and not be copied from another source.

Is Data an ‘Original Work’?

Data is usually fact-based and primarily consists of statistics or numbers. As a result, copyright usually does not protect data.

Examples of such data include:

the consumer price index for a particular quarter;
monthly house price increases in a city;
the number of students in a class; or
the count of films released in a year.

Generally, the law does not consider this an original work because it merely represents real-world information.

What Data is an ‘Original Work’?

However, data can be an original work in some circumstances. For example, if you organise data in a unique manner that reflects someone's creativity, the law might consider that data an ‘original work’.

Examples of organised data that copyright protects include;

accounting forms;
sequences of numbers or letters for a bingo game; or
a car parts catalogue.

Consequently, screen scraping data from a website is unlikely to infringe copyright unless it involves protected, creatively organised data. Infringing someone’s copyright means using their copyright-protected material without their permission.

Are There Exceptions to Copyright Law?

In the rare event that your screen scraping infringes copyright, your use could fall under an exception to copyright infringement. Australian copyright law refers to these exceptions as 'fair dealing.'

The four ‘fair dealing’ exceptions include using copyright-protected materials for:

research or study;
review or critique;
parody or satire; and
reporting the news.

For instance, a journalist scraping original data sets to report potential price-gouging among airlines could potentially rely on the exception for reporting the news. However, if you are scraping data for business purposes, the fair dealing exceptions may not apply.

What if a Website Explicitly Bans Screen Scraping?

Even if screen scraping is not always illegal under Australian copyright law, website owners can use their terms of use to prohibit data scraping. These terms of use often appear as website pop-ups. The pop-ups typically state that by continuing to use the website, you accept the terms of use.

These terms can explicitly forbid:

data scraping;
copying;
hacking; or
any form of data extraction.

Violating these terms would result in you breaching the website’s terms of use. As a result, the website owner may take legal action against you. If the data on the website qualifies as original work, copyright infringement claims may also arise.

Therefore, it is advisable not to screen scrape from websites with explicit terms of use against that activity. If you do engage in screen scraping, ensure you only extract factual information.

Key Takeaways

Screen scraping is generally lawful if you extract strictly factual information from other websites. However, if a website's terms of use prohibit screen scraping, even for factual data, it is advisable to avoid data scraping. Otherwise, you could face potential breach of contract and copyright infringement claims.

For assistance with your legal obligations, LegalVision’s experienced IT lawyers can assist as part of their membership. For a low monthly fee, you will have unlimited access to lawyers who can answer your questions and draft and review your documents. Call LegalVision today on 1800 296 912 or visit their membership page.

ZDNS - scan the entire internet

2023-06-20T13:00:00+10:00

The lack of a free Reverse DNS (rDNS) lookup database has made large-scale DNS research harder. To address this, we used ZDNS, an open-source, high-performance DNS toolkit developed by Stanford University, to create our own rDNS database. To reduce UDP timeout issues during rDNS operations, we devised a scan-ordering approach that randomised the IP space and improved the efficiency of the scanning process.

Leveraging ZDNS for rDNS Lookups Across the Internet

Understanding rDNS is useful for internet operations and research. Active DNS measurement helps us inspect how providers advertise the use of their IP address space. One of the components of this ecosystem is Reverse DNS (rDNS), which serves an important role in IP database categorisation and ASN (Autonomous System Number) classification. However, running rDNS across the entire internet is not a trivial task.

Previously, Rapid7 provided a free database for rDNS lookups, but it has discontinued the offering. This situation has prompted the need to create our own database, calling for a robust, efficient, and scalable tool to accomplish the task. ZDNS was the right fit.

Introducing ZDNS

ZDNS, a part of the ZMap.io project, is a capable tool developed by Stanford University to support scalable and reproducible DNS research. ZDNS is an open-source DNS measurement framework specifically optimised for large-scale DNS research on the public internet. It can resolve 50 million domains in 10 minutes and query the PTR records of the complete public IPv4 address space in approximately 12 hours.

This high-performance toolkit offers a modular interface, enabling researchers to safely implement new functionalities. Its architecture is designed to expose DNS lookup chains by performing recursive resolution. ZDNS supports a command-line interface and outputs results in JSON, a machine-parsable format.

Enhancements by ZDNS

ZDNS's architecture and feature set are tailored to the challenges of extensive DNS research. Its guiding principles are that the DNS lookup chain is exposed, and that the tool is safe, easy to use, and extensible.

ZDNS's performance optimisations make it a suitable tool for DNS experiments that require querying a large number of names. Parallelism, UDP socket reuse, and selective caching are some of the critical performance optimisations that enable ZDNS to efficiently handle large volumes of DNS queries.

ZDNS's scalability, execution time, and success rate have been evaluated against several existing tools, showcasing its performance. For instance, when it comes to exposing the DNS lookup chain, ZDNS is 85 times faster than Dig. ZDNS also outperforms other higher-performance tools, achieving 2.6 to 3.6 times more successful queries per second and experiencing about 30% less packet drop than MassDNS.

Our rDNS Journey

When we started scanning the whole internet with rDNS, we hit a practical roadblock: UDP timeouts made the scans slow. The system spent too much time waiting for responses from parts of the internet that were either empty or broken.

We used two changes. Firstly, instead of scanning the internet's addresses in order, we mixed them up and scanned randomly. This spread out our requests and stopped the system from getting stuck on troublesome ranges. Secondly, we checked smaller sections of the internet first, so we did not waste time waiting for big chunks of the internet that weren't responding.

With these changes, we scanned the whole internet in 13 days, finding over a billion addresses. The main lesson was straightforward: scan order matters when timeout behaviour dominates runtime.

The result depended on scan order

ZDNS gave us the throughput and structured output we needed, but the tool alone did not make the scan finish. The decisive change was to stop walking adjacent address ranges in sequence. Randomising the work kept slow or empty ranges from dominating a worker's runtime and brought the full scan down to 13 days.

ZDNS is available on GitHub, and the IMC 2022 paper covers its architecture and benchmark results. If you repeat this kind of measurement, treat target ordering, timeout policy, responsible scan rates, and restartability as part of the design rather than as command-line details.

Izhikevich, L., Akiwate, G., Berger, B., Drakontaidis, S., Ascheman, A., Pearce, P., Adrian, D., & Durumeric, Z. (2022). ZDNS: a fast DNS toolkit for internet measurement. In Proceedings of the 22nd ACM Internet Measurement Conference (pp. 33-43). https://doi.org/10.1145/3517745.3561434 ↩
ZMap Project. (n.d.). ZDNS. GitHub. Retrieved 2023-05-15 13:00, from https://github.com/zmap/zdns. ↩

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.

Residential Proxy Detection

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

A login request arrives from an Australian household connection. The ISP and location look ordinary. The address does not appear on a data-centre list.

The request could belong to a customer. It could also have been sent by someone elsewhere and relayed through that connection. The IP tells you where the traffic exited. It does not tell you who controlled the request.

That is the residential proxy problem in one request.

This article is the blog entry point for Peakhour's residential proxy research. The stable explainers now live in our Residential Proxies learning centre, where definition, supply, detection and policy each have a clear home.

What Counts as a Residential Proxy

A residential proxy routes a third party's traffic through consumer or ISP connectivity. The destination sees the exit address rather than the operator's original connection.

Mobile proxy traffic is closely related and often needs similar controls, but it should remain separately labelled. Carrier routing and CGNAT create different sharing and false-positive conditions. Compromised small-office routers are also important proxy supply without automatically becoming residential simply because they sit at the edge.

The full definition, legitimate uses and abuse patterns are covered in What Is a Residential Proxy?.

How the Networks Get Their Supply

Residential proxy capacity can come from people who knowingly install a bandwidth-sharing product. It can also come from monetisation SDKs inside unrelated applications, unclear disclosures, compromised endpoints and pre-infected connected devices.

Those routes differ legally and ethically. They create the same visibility problem for the destination: the web application usually cannot see how the exit joined the pool.

How Residential Proxy Networks Are Formed owns the stable supply model. Our investigation into bandwidth sharing and residential proxy supply follows the recent evidence from app platforms, malware research and device takedowns.

Why Static IP Classification Misses the Moment

IP intelligence is useful. It can identify hosting networks, known VPNs, Tor exits, prior abuse and addresses previously observed in proxy pools. The limitation is time.

Residential addresses are reassigned. Mobile subscribers move between gateways. Several users may share one public address. Proxy applications start and stop. A new exit can carry traffic before a database labels it, and an old label can outlive the session that created it.

Per-connection detection addresses that gap by evaluating evidence available when the request reaches the protected service. Network and protocol fingerprints, browser consistency, route, account state, behaviour and recent outcomes can show that the connection deserves different treatment even when the address looks ordinary.

The canonical detection guide is What Is Residential Proxy Detection?.

A Signal Is Not the Decision

Detecting a likely residential proxy does not prove that the request is malicious. Privacy tools, monitoring systems, authorised research and shared networks all complicate the result. The action should follow the route and the cost of being wrong.

A proxy signal on a public article may only be worth logging. The same evidence on login, combined with an exposed credential and failures across several accounts, may justify a challenge or tighter rate limit. On account recovery, payment or API token creation, the application may require stronger verification.

Proxy Signals and Security Decisions sets out the allow, log, challenge, rate-limit, step-up, block and review choices without turning the proxy label into a blanket ban.

What Buyers Should Ask a Detection Vendor

Do not stop at whether an API returns proxy=true.

Ask how the provider handles fresh exits, mobile carriers, CGNAT and changing address assignments. Test the result against your own customer traffic and known incidents. Confirm that analysts can see enough evidence to review a decision. Measure missed abuse and legitimate-user impact on the routes that matter to your business.

The Proxy Detection Vendor Evaluation guide provides the full checklist.

What the 2026 Takedowns Added

Google's actions against IPIDEA and NetNut gave defenders a rare view across applications, SDKs, control infrastructure, proxy pools and reseller relationships. The operations removed capacity and imposed material operating costs. They also showed why a provider name is not a stable security boundary.

We cover that evidence in three articles:

IPIDEA and NetNut: What Two Residential Proxy Takedowns Actually Changed examines enforcement and supplier accountability.
When a Proxy Network Dies but Its IPs Survive examines what address overlap proves and where the inference stops.
A Proxy Takedown Is Not a Security Control gives application and fraud teams a post-disruption operating checklist.

The conclusion is practical. Upstream action can reduce supply. The destination still needs to judge the next request using current evidence.

Continue by Job

Start with the Residential Proxies learning hub for the complete topic map.
Read Five Routes, Five Residential Proxy Decisions for concrete login, signup, recovery, checkout and API policies.
Read Residential Proxy Detection for APIs Without JavaScript for machine-facing traffic.
Read What a Residential Proxy Decision Log Should Contain for evidence and review requirements.
See Peakhour Residential Proxy Detection for the production capability.

When Bots Break Bad

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

Bots account for a large share of web traffic. Recent studies put automated traffic at nearly 50% of all internet requests. Some bots are useful, such as search engine crawlers that index your site. Some are clearly harmful, such as scrapers and sneaker bots. Others sit in a grey area, including backlink and marketing bots from services such as Ahrefs and SEMrush. Even useful bots can create problems when they crawl too hard. This article looks at the main bot types and how to manage them with robots.txt and bot management tools.

Understanding the Different Types of Bots

'Good Bots'

Good bots perform legitimate work. Search engine crawlers like Googlebot and Bingbot index webpages so search results can stay current and relevant. Other examples include uptime and performance monitoring bots.

'Bad Bots'

Bad bots harm websites, users, or both. Common examples include:

Scraping content, copying and repurposing data from websites.
Sneaker bots, automatically purchasing limited-edition products (like sneakers) before human users can.
Spam bots, posting unsolicited messages and advertisements in comment sections or forums.
Vulnerability Scanners, trying thousands of website URLs to find security vulnerabilities.
Account Takeover, attempting to gain access to existing user/admin accounts using either credential stuffing or brute-force attacks.

'Grey Bots'

Grey bots sit between good and bad. They often serve a useful purpose and may follow crawling directives in robots.txt, but they can still cause problems when they crawl too aggressively. Common examples include:

AhrefsBot: A backlink analysis bot used by Ahrefs, an SEO tool.
SEMrushBot: A bot used by SEMrush, another popular SEO and digital marketing tool.
MJ12bot: A bot used by Majestic, a service that provides backlink data and analysis.
ScreamingFrog: An SEO analyser run from a local desktop.

When Grey bots (and even Good Bots) go bad.

Left unattended, grey bots can create practical problems:

Slow page loading times, which affect user experience.
Strain on server resources, potentially causing crashes, downtime, and higher costs.
Distorted website analytics, when bot traffic is mistaken for human traffic.

Managing Grey Bots with Robots.txt

The robots.txt file is a simple text file that tells web crawlers which parts of your site they can or cannot access. You can use it to manage bot behaviour and protect your website from aggressive crawling. Useful controls include:

Disallowing specific bots: You can block specific bots from accessing your site by adding a "User-agent" and "Disallow" directive to your robots.txt file. For example:

User-agent: AhrefsBot
Disallow: /

Limiting crawl rate: You can ask bots to slow down their crawling by adding a "Crawl-delay" directive:

User-agent: SEMrushBot
Crawl-delay: 10

Not all bots will follow robots.txt. ScreamingFrog, for example, can be instructed to ignore robots.txt and crawl a site as quickly as possible. You would not want a competitor doing this to your site.

Bot Management Tools

In addition to robots.txt, bot management tools (like those provided by Peakhour) can protect your website from abusive bots. Good bot management tools automatically block most unwanted traffic using a combination of Threat Intelligence, Fingerprinting techniques, Reverse DNS verification, and Header Inspection.

Advanced techniques like rate limiting and machine learning can help identify more sophisticated bad bots.

Search Bots and Double Crawling

Search bots like Bingbot can sometimes blindly follow links and crawl the same page multiple times due to different URL parameters. This double, triple, or worse crawling can increase server load and make indexing less efficient. eCommerce sites are especially exposed because product catalogues often have several filtering paths. We've seen Bing go haywire on a number of sites. Most recently, it was issuing around 50,000 requests per day to the search function of a Magento 2 store while cycling through parameters. This dropped to 2-3k requests per day when fixed. On another store, Bing was responsible for nearly half of all page requests (40k page requests) on a busy OpenCart store. Configuring it to ignore parameters dropped this to around 4k per day.

Control the crawl path that exists now

Google retired Search Console's URL Parameters tool in 2022. Bing removed its equivalent control too. Do not follow old instructions that send you hunting through either webmaster console.

Google says its crawler now learns how URL parameters behave automatically. When that is not enough, use robots.txt rules, canonical URLs and clean internal links to make the intended crawl path clear. Our worked example shows how to exclude query-string combinations with robots.txt. Google's own notice explains why it retired the URL Parameters tool.

Check the result in access logs. The useful measure is not whether a rule exists; it is whether duplicate parameter combinations stop consuming requests while the pages you want indexed remain crawlable.

Watch the request volume

When good or grey bots crawl too aggressively, they can cause the same operational problems as malicious bots: overloaded servers, slower pages, and worse user experience. Monitor crawler request volume and server load, set narrow robots.txt rules, then verify the change in logs rather than assuming the crawler behaved as intended.

Double MAD?

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

This article explores the use of Double Median Absolute Deviation (Double MAD) for [anomaly detection](/learning/threat-detection/what-is-anomaly-detection/) in time series
data, particularly in skewed or non-symmetric distributions. Double MAD, which calculates two median absolute
deviations — one for data below the median and one for data above — provides a more nuanced approach than traditional
MAD, allowing for accurate detection of anomalies even in skewed data distributions. We also delve into its application
in identifying slow abuse, like bots, by catching lower range anomalies. However, it's important to note Double MAD's
limitations such as not capturing seasonal data shape and trends over time. A comparison is also drawn with the Z-score
method, highlighting that the choice between the two depends on the nature of your data. The article provides insights
into the practical implementation of Double MAD and its potential to improve your data analysis toolkit.

Operational systems increasingly rely on time-series data for decisions. Anomaly detection is one practical use: by identifying patterns that deviate from the norm, businesses can investigate potential issues early or understand unexpected opportunities.

One useful technique for anomaly detection is the Median Absolute Deviation (MAD) and, more specifically, its extension, the Double MAD. This article explains where Double MAD fits in time-series anomaly detection and how it can help identify anomalous clients.

Understanding MAD and Double MAD

MAD, a robust measure of variability, is less susceptible to outliers than standard deviation. It calculates the median of absolute deviations from the data's median, often providing a better representation of 'normal' behaviour in datasets with skewed distributions or outliers.

Double MAD is an extension of MAD, where two MADs are calculated — one for the data below the median and another for the data above. This split gives the detection process a better fit for asymmetric data, which is common in real-world time series data.

Why Double MAD?

While MAD provides a robust way to understand the 'normal' range of a dataset, it assumes a symmetric distribution of data around the median, which may not always hold true. Double MAD is useful where that assumption breaks down, offering an improved anomaly detection process for skewed or asymmetric datasets.

In time-series analysis, especially with 24-hour cycles like web traffic or server usage, patterns can exhibit seasonality and trend components. These patterns can often be asymmetric, making Double MAD a valuable tool for capturing the variability in different parts of the data.

Using Double MAD in Anomaly Detection

The Double MAD implementation provided uses Rust, a system programming language known for speed and memory safety. The code calculates the lower and upper MAD values, along with their respective thresholds. Anomalies can then be detected by comparing each data point to these thresholds.

An anomaly is defined as a data point that deviates significantly from the expected range. If a data point falls below the lower MAD threshold or above the upper one, it can be flagged as an anomaly. This approach is especially effective when handling datasets with high variability or extreme values.

Double MAD for Anomalous Client Detection

Beyond time-series data, Double MAD can also be instrumental in identifying anomalous behaviour among clients. By comparing each client's behaviour against the Double MAD of the time-series data, teams can pinpoint clients that deviate from the norm.

For instance, in the context of web service usage, an anomalous client might be one that is sending an unusually high or low number of requests. By using Double MAD, you can flag such outliers and take appropriate action, such as investigating potential misuse or reaching out to understand and address any issues they may be facing.

Detecting Lower-Range Anomalies: A Case of Slow Abuse

An interesting application of Double MAD is in detecting lower-range anomalies, a pattern often associated with slow abuse such as bots or Distributed Denial of Service (DDoS) attacks. These abuses are characterised by an unusually low frequency of activity that is consistent over a prolonged period. This consistent, low-level activity can fly under the radar of typical anomaly detection systems.

By setting a lower MAD threshold, Double MAD can effectively detect these lower-range anomalies, providing early warning of slow abuse. Its ability to detect both high and low anomalies makes Double MAD a flexible tool for anomaly detection.

The Math Behind Double MAD

To illustrate the power of Double MAD, let's consider a dataset from a right-skewed distribution. Applying the conventional MAD approach might lead to false positives where normal data points are marked as outliers. This is because MAD uses a symmetric interval around the median, which doesn't account for the skewed nature of our data.

With Double MAD, we instead calculate two MADs — one for the data below the median (MAD-lower) and another for the data above (MAD-upper). Outlier thresholds are then defined using these two MADs. The lower threshold is calculated as the median minus a multiplier (k) times MAD-lower. The upper threshold is the median plus k times MAD-upper.

This approach takes into account the asymmetric nature of our data, providing more accurate anomaly detection. For example, in a right-skewed distribution, Double MAD would correctly identify only the extreme right tail values as outliers without incorrectly flagging data points on the left tail.

Wrapping Up

Accurate anomaly detection matters when teams rely on time-series data to operate and investigate systems. The Double MAD approach provides a robust method for this, allowing businesses to better understand their data, spot potential issues early, and make more informed decisions.

Whether you're monitoring web traffic, server usage, or client behaviour, leveraging Double MAD can offer valuable insights and help ensure your operations continue to run smoothly. The ability to detect both high and low anomalies makes it especially powerful, providing protection against potential threats like slow abuse.

Understanding and implementing Double MAD gives your data analysis toolkit a more complete view of asymmetric data and helps you detect potential anomalies earlier.

Efficiently Generating and Printing All IPv4 Addresses in a Random Order

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

In this article, we explored an efficient way to generate and print all possible IPv4 addresses in a random order using
a Linear Congruential Generator (LCG). The LCG, a pseudorandom number generator, helps generate the full range of IP
addresses without consuming vast amounts of memory, making this approach suitable for systems with memory constraints.
We also provided a Python script demonstrating the concept, along with a test case to verify its correctness.

We then delved into the importance of randomising IP addresses, highlighting its critical role in areas like security
testing, load balancing, enhancing privacy, and web scraping. However, while using this technique, it's essential to
respect privacy and legality, as misuse can lead to legal repercussions.

In summary, the ability to generate and print all IPv4 addresses in a random order is a powerful tool, especially in the
realm of networking and cybersecurity, and can be achieved efficiently using the LCG approach.

In networking, some tasks require generating and printing every possible IPv4 address. Doing that in random order without a large memory footprint is less straightforward. The IPv4 address space contains 2^32, or 4,294,967,296, values. Storing all of them in memory at once is not feasible for most systems.

This article uses a Linear Congruential Generator (LCG) to generate the full range without holding it in memory.

Linear Congruential Generator

A Linear Congruential Generator is a type of pseudorandom number generator that can run without storing the whole sequence. It generates each next value from a linear equation based on the previous value. The basic form of the LCG is:

X_(n+1) = (a*X_n + c) mod m

Here, a, c, and m are constants, and X_n is the nth number in the sequence. The initial seed or starting point of the sequence is X_0.

If we choose parameters such that the period of the LCG is maximum (equal to the modulus), and the modulus equals the range of numbers we're generating (the number of possible IPv4 addresses in this case), then the LCG should generate each number in the range exactly once before repeating.

Here is that idea in Python:

import ipaddress

def lcg(modulus, a, c, seed):
    """Linear congruential generator."""
    while True:
        seed = (a * seed + c) % modulus
        yield seed

start_ip_str = '0.0.0.0'
end_ip_str = '255.255.255.255'

start_ip = int(ipaddress.IPv4Address(start_ip_str))
end_ip = int(ipaddress.IPv4Address(end_ip_str))

modulus = end_ip - start_ip + 1
a = 1664525
c = 1013904223
seed = 1  # Arbitrary seed

generator = lcg(modulus, a, c, seed)

for _ in range(modulus):
    ip_int = start_ip + next(generator)
    ip = ipaddress.IPv4Address(ip_int)
    print(ip)

The script first defines the parameters of the LCG. a, c, and seed are set to values used in Numerical Recipes' LCG, a well-known and widely used LCG. The modulus is set to the total number of possible IPv4 addresses.

The function lcg() is implemented as a Python generator, yielding the next number in the sequence each time it is called.

The loop then generates and prints each IP address. It adds the output of the LCG to the start IP address, converts it back to an IP address string, and prints it.

This script generates and prints each IP address in random (more precisely, pseudorandom) order using very little memory. Each IP address is printed exactly once, assuming the period of the LCG is maximum.

The point is that a small pseudorandom number generator can walk a large range without materialising the whole list. The code can still be tweaked and optimised for specific requirements and constraints.

The Importance of Randomising IP Addresses

Randomising IP addresses has practical uses in several networking workflows:

1. Security Testing and Penetration Testing

In cybersecurity, randomising IP addresses can help simulate attacks on a network from various sources. By using a range of IP addresses in no particular order, penetration testers can mimic the unpredictable nature of real-world cyber threats and build more robust test scenarios.

2. Load Balancing and Network Traffic Simulation

Randomising IP addresses is also useful in network traffic simulations. Network engineers and administrators can use this approach to test network resilience and capacity. By sending requests to servers from randomised IP addresses, they can evaluate how well their load balancing strategies are functioning and whether the network can handle high traffic loads from various sources.

3. Anonymity and Privacy

In some cases, randomising IP addresses can help with privacy and anonymity. While it is not a foolproof method, using a different IP address for each request can make it more challenging for online trackers to monitor user activity. It is a common practice among privacy-focused internet users and is also used in some VPN (Virtual Private Network) services.

4. Web Scraping

Web scraping is another area where randomising IP addresses is useful. To prevent being blocked by anti-bot measures, web scrapers often need to rotate their IP addresses. By using a different IP address for each request, they can avoid being detected and blocked by the sites they are scraping.

Randomising IP addresses can be useful in these cases, but privacy and legality still matter. Unauthorised network scanning, privacy breaches, and cyberattacks are illegal and punishable under law.

Generating and printing every possible IPv4 address in a random order is a valuable technique with various applications, from network testing to privacy enhancement. With the Linear Congruential Generator approach, we can do it efficiently.

Origin shield

2022-06-10T13:00:00+10:00

CDN providers often promote the size of their network, and how many Points of Presence (POPs) they have. Higher capacity, more resilient networks are useful from a security point of view (think DDoS attacks), but more POPs can also work against what the CDN was designed to do: take load off an origin and improve performance for end users.

The POP Problem

Modern CDNs are what's called 'Pull' CDNs. That means the CDN won't store content/resources until a user requests it. The first time a user requests a resource, it goes to the CDN POP, checks its local cache, gets a miss, and then passes the request through to origin. As the resource is returned, the CDN stores a copy for the next time someone wants it. If your CDN has 100 POPs, then this process has to be repeated 100 times to fully 'warm' the CDN for that specific resource. That's 100 requests to origin. The more POPs your CDN has, the more likely you are to get a miss and hit the origin.

When the caches at POPs are fully populated, the effect on your application can be minimal. During a cache MISS event, typically either due to resource expiration or a manual purge, many requests can be sent to the origin server concurrently while the individual POPs rebuild their caches. The more POPs, the longer the process takes.

This can be a problem, especially when caching dynamic pages that need to be server side rendered, large resources, or transformed resources. For example, take a busy ecommerce store running Magento during a sale, Magento will purge content when sales are made, forcing the cache to rebuild each time. During a busy period it can reduce your cache hit rate and degrade site performance.

Enter Origin Shield

CDN Origin Shield is a feature that lets you nominate the CDN Point of Presence closest to your server as a shield. All requests that hit other POPs and receive a cache miss will then go to the nominated shield before hitting the origin. The shield becomes a 'super cache' and can reduce the amount of requests to your origin in a cache miss.

Peakhour.IO implements origin shield as a simple dropdown on an origin pool where you can select the geographic location that should be used as a shield. Requests to your origin are now routed through this geographic location before reaching your origin in a cache miss scenario.

Clients who use multiple geographic origins can also benefit from Origin shield. Peakhour.IO allows the specification of an origin shield per origin. For geographic load balancing, you will need to contact support for setup.

Seeing is believing

The Peakhour.IO summary now includes your edge CHR, your shield CHR and your overall CHR so that you can see the effect in action.

Some of our clients have seen typical increases of 10-20% of their overall Cache Hit Rate, and greater than 40% when specifically looking at often flushed dynamic content.
Quicker cache convergence
Fewer hits to origin
Better end-user experience
Higher conversions

Final Thoughts

Origin Shield is an important feature for certain types of site, or when you're looking to maximise your cache hit rate. CMSs that offer built in full page caching, like Magento and Drupal, flush content often, and are susceptible to performance degradation as load increases. Minimising hits to the origin in these cases is vital.

If you are interested in getting more out of your CDN, need a bespoke CDN solution, or need a provider that offers performance, optimisation and security services, reach out to discuss the right setup.

Origin shield with request collapsing helps minimise origin hits, improve CHR and maintain user experience for your web application.

Fastly Outage

2021-06-09T13:00:00+10:00

You may have heard that Fastly, one of the world’s largest providers of CDN services, had an outage of about 1 hour on the 8th July. Some of the world's largest websites and services were down, including reddit, CNN, The Guardian, Shopify Stores, Stripe and Spotify, to name a few.

According to Fastly themselves, the outage was caused by a 'service misconfiguration' (Update: Bug triggered by a client changing their configuration), which propagated globally and took websites offline. When users tried to access a website using the Fastly service, they were presented with a Varnish 503 Guru Meditation error (for those of us old enough to remember, Guru Meditation is a geek reference to the Commodore Amiga computer of the late 80s!). This generally occurs when there is an issue contacting the server that the website is actually hosted on. There were also some reports on twitter saying 'unknown domain'.

Essentially, Fastly took down its own network with a bad software update. Similar problems have affected other online platforms in the recent past, including Google, Amazon, and Cloudflare.

Why wasn’t there a Plan B?

Fastly is an excellent service, with an enviable reliability record. There is a reason why they're trusted by some of the world's largest websites to improve reliability and load times. However, the vast majority of Fastly clients still had to sit tight and wait for Fastly to fix the issue. Luckily this was only an hour. It could have been much longer.

Just like death and taxes, software outages are a certainty. The real story is not that Fastly had an outage. It is why didn't these large websites have a contingency plan for a single point of failure. For sites at that scale, this is a major oversight in infrastructure planning.

How to handle a CDN failure

The simple solution is to have a backup CDN provider already configured and tested, ready to switch over to if your primary provider fails. You can then utilise short expiry of DNS records to redirect users when the failure happens. This needn't be very expensive or complicated, although individual circumstances vary.

A Quick Introduction To DNS (Domain Name System)

Modern CDNs, like Fastly, Cloudflare, and Peakhour, operate as ‘reverse proxies’. This means they sit between a website's end users and the website server itself. They achieve this through DNS configuration.

When someone types a domain url into a browser, eg fastly.com, a request is sent to a DNS server with the host name (eg fastly.com) to find the IP address of the server to retrieve the content from. CDNs, like Fastly, get website admins to list the address of the CDN on the DNS server. That means requests for a website go through the CDN first. The process is analogous to listing someone else’s number in the phone book so they take calls for you.

The DNS server has a TTL (Time To Live) associated with its records. This TTL tells whoever asked for an IP address, for a given hostname, to remember the answer and not ask again until after the TTL has passed. Typically DNS record TTLs will be 1 hour, but they can be shorter, eg 1 minute.

Switching providers in case of an outage

By keeping a short TTL in DNS, webmasters can switch the answer for a DNS request to that of another provider, meaning users can quickly be directed to an alternative Cloud Provider. Once service has resumed on the primary provider, DNS can be switched again so normal traffic is resumed. The key is that the alternative provider is configured, tested, and ready to go.

This switch can even be automated to minimise outages. Premium DNS services, like Amazon’s Route 53, have optional health checking of DNS answers. This allows a switch to happen nearly instantly. The only downtime would be for people already on the site who have to wait for the TTL to expire before being directed to the backup Cloud Provider. In fact this is exactly what Peakhour.io does. In the event of a catastrophic outage we use DNS to switch to backup infrastructure so our clients are minimally affected.

Backup provider options

Now we've shown how switching CDN providers can be done, let's compare the major players and how they might serve as a backup CDN for Fastly. The three things we'll look at are Cost, Features, Integration.

Simply route traffic to the origin

This would be the simplest and most cost effective option, Assuming your origin server can handle the increased load that removing its CDN would entail. It also assumes that it's ok to lose any features that you may have been relying on, eg load balancing, WAF, edge scripting, image optimisation etc.

Cloudflare

Many people use Fastly because it uses Varnish, a richly featured, programmable cache with several advanced features. If you rely on those features, eg cache tags, cache on cookie value, custom cache tags, then you have to be on Cloudflare's top plan, which is not cheap.

The other major drawback of Cloudflare is that, unless you are on the most expensive plans, you have to cede control of DNS to them by delegating your domain. Cloudflare DNS is a great service, however it has the major drawback of caching negative DNS requests for an hour. If you were switching from an A record to a CNAME record or vice versa, you could be down for an hour regardless. Not ideal.

Akamai

Akamai has a highly respected, fully featured, and very expensive product. Maintaining a backup option with them will run into the $1000s a month. Only you can decide whether it’s worth it.

Cloudfront

Amazon's CDN offering is the third of the big three alternatives. Since it uses volume based billing, it could be an attractive CDN option as a standby, as long as you don't mind missing out on cache by tag (sorry Magento and Drupal). It is also complicated to configure for dynamic content and could miss features that you need. In fact most people use Cloudfront for static content, eg images, CSS, etc and run a Varnish instance within AWS to provide easier to configure full page caching.

This is what the BBC did with the Fastly outage. They had their backup infrastructure on Cloudfront and, as of time of writing, hadn't switched back to Fastly.

Peakhour.io

Peakhour is also volume based billing with a minimum monthly charge of $20. We provide all the advanced caching features that Fastly does, as well as WAF and image optimisation as standard, all in the one service fee. We don't require you to cede control of DNS to us and we're Australian owned and based.

Final Thoughts

CDNs, no matter how big, can fail. If your website is important then it needs a Plan B. This is how that Plan B works, and it doesn't have to be expensive when using a provider like Peakhour.io.

The important part is having it configured and tested before you need it.

Setting Up A Chia Hobby Farm

2021-04-30T13:00:00+10:00

Here at Peakhour, when we're not making websites faster and more secure, we like new tech and we like a good scheme. We ran Seti@home while at uni, and mined some bitcoin back in its early days (unfortunately we don’t have them anymore). Just recently we decided to set up a Chia farm, not the super-food Chia, but the new crypto coin Chia!

What is Chia?

Chia is not just a cryptocurrency; it is a brand new blockchain and smart transaction platform that implements the first new Nakamoto consensus algorithm since Bitcoin. It was invented by the engineer behind BitTorrent, Bram Cohen, who set out to address the shortcomings of Bitcoin.

The Chia network is set to officially launch on May 3rd, and the crypto world is going crazy getting ready.

I thought Bitcoin was great, what’s wrong with it?

The major flaws that Chia sets out to address are:

The environmental impact

Without getting too technical, Bitcoin relies on very intensive computations to verify transactions (Proof of work). These computations are carried out by 'miners' who are rewarded for their efforts from an ever decreasing pool of possible bitcoin. As the blockchain gets older, the verification gets harder, and as a result the Bitcoin network is now consuming as much electricity as a mid-sized country like Argentina. Huge mining operations have been set up in China, and some even have dedicated power plants. One poster child for the environmental impacts of bitcoin is an Australian startup looking to reopen a decommissioned coal power plant to power its mining operations.

Possibility of manipulation

The huge energy requirements have led to massive server farms in cool regions near cheap electricity, concentrating mining in the hands of a few large players. This centralisation opens up Bitcoin to the possibility of manipulation as anyone with 50% of the network can effectively change the blockchain.

How does Chia address these issues with Bitcoin?

Chia has implemented a new consensus algorithm called proof of space and time. It relies on unused hard disk space, which lots of people have and can use free of charge. Again, without getting too technical, 'Farmers' seed unused space on their hard drive/SSD with 'plots' of cryptographic numbers. When verifying transactions, the network issues a challenge to the farmers, who then scan their plots for the closest answer. The farmer passes this answer back to a server on the network known as a 'timelord'. The farmer with the closest answer is rewarded with a coin.

The more 'plots' a farmer has, the higher the chance of winning a coin.

Setting up the Farm

We got excited about the idea of Chia being the next big thing and decided to hitch a ride on the bandwagon. We had a spare old computer lying around, so we decided to fill it up with as much storage as we could find and farm some Chia!

To set up a farm you need as much space for plots as you can get your hands on. The speed of this space is not critical, so you can use spinning drives. We found 12-terabyte NAS drives to be the sweet spot for bang for buck, and opted for 4x Seagate Ironwolf NAS drives from Scorptec. (Note: they’ve gone up $40 since we bought them!)

Seeding the plots, however, is VERY disk intensive, so you need speedy and reliable SSDs. Since they don't have moving parts you'd think that SSDs would be very reliable, but just like spinning drives, they wear out and eventually die. SSDs come with a TBW (Terabytes Written) rating which estimates the amount of writes you can do before the drive will die. Popular consumer SSDs like a 500GB Samsung EVO 870 have a TBW rating of 300. Chia recommends getting server-grade SSDs that have ratings into the Petabytes, but of course they come with a price to match.

We were limited by the age of our available motherboard, so we could only choose from SATA3-compatible drives. Appropriate enterprise SSDs were also unavailable, so in the end we settled on 500GB Seagate Firecuda 120s that are rated at 700 TBW (also from Scorptec). We decided on two so we could double the plotting rate.

Now we had our hands on the drives, we just had to install everything. Within a few hours of transferring components and wiring it up we were good to go and started plotting.

Our Chia Farm!

Final Thoughts

Our old hardware limits the speed of the SSDs and therefore the number of plots we generate. We're managing around 10 plots a day and will need close to 500 before we’ve filled the available storage.

When we bought our equipment (28th April) the chia calculator showed that we’d be earning around a coin a day when fully plotted. However, with the official launch of Chia imminent, the network has exploded in growth, passing 1 Exabyte (1000 Terabytes) just one day ago. It's now up to 1.68 Exabytes! So unfortunately our estimated time to a coin is down to one every 7 days. That’s still pretty good though, and if Chia does end up supplanting Bitcoin we might just make back the setup costs. It has been a fun exercise, even if we did spend too long on it, and if it does end up being a flash in the pan we can always use the drives for something else….

Why Manage Bots?

2020-11-30T13:00:00+11:00

Modern sophisticated bad bots often work around traditional security controls. They disrupt websites, mobile applications, and APIs. Malicious bot tactics include scraping user and pricing data, creating fake accounts, running advertising click fraud, exhausting online inventories, and taking websites offline with automated DDoS attacks.

About one-quarter of all website traffic in 2019 originated from bad bots, an increase of 18 percent over 2018. Advanced persistent bots (APBs) made up seventy-five percent of that bad bot traffic as they attempted to evade detection by cycling through random IP addresses, using anonymous/residential proxies, and changing their identities (user agent). The industries hit hardest by bad bots in 2019 included financial services, education, ecommerce, and government as well as media and airlines.

“Bot attack campaigns have become big business for threat actors, and major organizations are now fighting to support legitimate users and prospects while keeping attackers out of online applications and services,” says Paula Musich, Research Director, Enterprise Management Associates.

Bots have moved from simple scripts to distributed networks of automated agents that can mimic human interactions with machine learning techniques. They can avoid detection by network security technologies that have not kept pace with the way automated agents now operate.

Reducing the damage from bad bots means using security countermeasures that detect automated traffic and make attacks uneconomic, not just visible.

Bot Countermeasure Best Practices:

The following bad bot countermeasure practices cover network security, machine learning, and behavioural analysis. The aim is to reduce the economic harm that malicious bots inflict on businesses and end-users.

Web Application Firewalls

Web Application Firewalls (WAF) are a common first line of defence that filter out harmful Layer 7 web application (HTTP) traffic using rules or policies that protect organisations against Distributed Denial of Service (DDoS) bot attacks. WAFs also protect against cross-site forgery, cross-site-scripting (XSS), file inclusion, and SQL injection attacks. A WAF is considered a reverse proxy that protects servers and can be deployed as an appliance, server plug‑in, or filter, and customised by application type or use case. WAF rules can be updated or changed based on the type of bot attack.

IP Tracking and Reputation

Sophisticated bots can be detected with network forensics by inspecting web traffic and assessing whether requests come from actual users or bad bots. Requests can be analysed using data sources including Tor/proxy IPs, IP addresses, IP geo-location information, ISP information, and IP owners. Additional sources for real-time and near-time malicious IP threat data can come from network data, CERTs, MITRE and cooperating competitors.

Client/Device Fingerprinting

Fingerprinting attempts to identify devices, including PCs, Internet of Things (IoT) devices, mobile devices and servers, using data attributes that create real-time risk profiles to stop bot attacks. Using web page access data, a bot detection fingerprinting engine generates unique fingerprints for each end-user device and checks them against bad bots that use evasion techniques, including dynamic IP addresses and anonymous web proxies.

Machine Learning

Artificial Intelligence (AI) and machine learning algorithms are increasingly used to analyse malicious bot activity and make mitigation recommendations using data from sources such as user activity history, behavioural patterns and meta-data. Machine learning can use custom-tailored algorithms to target bots and iteratively process user data and identities to discern emerging bot attack patterns from very large amounts of real-time information.

Tarpitting

Tarpitting is a bot countermeasure that delays and slows down incoming malicious traffic from suspect connections. The technique is used to increase the financial and resource costs of bot attacks in an attempt to discourage malicious actors. Bad bot tar pits can delay bot request responses or take the bad bot IP address attack source offline completely. Innovative tarpitting techniques include requiring bad bots to solve computationally complex maths challenges to access resources or websites, thereby slowing down or stopping bot activity.

User Behavior Analysis

User interaction behaviour and identifying characteristics on a web page or mobile app differ from the behaviour of an automated malicious bot. Factors such as number of pages visited per session, time spent on each web page or within a mobile app and repeat visit frequency all help differentiate authentic users from bad bots. Defeating bad bots using Behavior Analysis involves creating a user model for individual sites with historical visitor data, then checking for anomalies that may indicate bad bot activity.

Intent-based Deep Behavior Analysis (IDBA)

Compared with Behavior Analysis, Intent-based Deep Behavior Analysis (IDBA) conducts behavioural analysis at the user intent level rather than the commonly used interaction-based behaviour analysis. IDBA consists of intent encoding, intent analysis, and adaptive learning. It also employs machine learning techniques to detect bad bots emulating on-site human behaviour interactions. Bad bot mitigation techniques include limiting attempts on login pages, web authentication pages and API call authentication pages.

Rate Limiting

Rate Limiting mitigates bad bots and DDoS attacks by restricting the amount of incoming traffic accepted by specific applications and API endpoints using pre-defined bandwidth limitation policies. Web applications, GET versus POST requests, APIs that receive queries, and login credentials can all be blocked if clients, IP addresses or IP and user-agent pairs violate Rate Limiting rules. Intellectual property scraping can also be protected by Rate Limiting policies that restrict repeated image or digital downloads.

Javascript Injection

JavaScript Injection techniques can help mitigate bad bot attacks in several ways. Scripts can be placed into web applications that “fingerprint” a user’s browser to distinguish humans versus bad bots emulating “human-like” mouse movements, keystrokes or clicks. Fingerprinting detection may also involve user agent identification, HTML5 canvas and audio fingerprinting, and protocol-level fingerprinting with TLS and HTTP2. JavaScript combined with browser cookies can also be used to identify anomalous behaviour from unwanted traffic or bad bots trending over time.

ANYCast DDoS Mitigation

Anycast is an IP addressing method that routes incoming traffic requests to the nearest location or “node.” Using ANYCast for selective routing enables network load resilience against DDoS attacks by routing high traffic across multiple servers and data centres. This prevents network resources from becoming overwhelmed with malicious or irrelevant traffic.

Alternative Content Serving

Serving Alternate and Cached Content when a bad bot is detected gives organisations a way to mislead bots without blocking them altogether. For instance, e-commerce sites may fool price scraping bots by serving alternative web pages that look like legitimate pages but with higher prices. Serving Cached Content when a bot is detected also minimises load on servers without affecting site performance.

Challenges

Requests from suspected bots can be redirected to Challenges or puzzles such as a CAPTCHA, also known as a Completely Automated Public Turing test, to help identify a bad bot versus a human. Online puzzles, such as letter matching, are easy for humans to solve but difficult for automated bots. reCAPTCHA, offered free from Google, is an advanced version of CAPTCHA puzzles that require users to identify text from real-world images such as street address signs, printed books or text from paper newspapers.

Final Thoughts

Bad bots hijack user accounts, create fake accounts, scrape websites for data and personal information, flood websites with traffic through automated distributed denial of service attacks and attack public-facing APIs using constantly changing techniques. They hide behind dynamic IP addresses, change their attack signatures, mimic human behaviours, and take over vast networks of hosts and IoT devices, creating zombie machines that distribute malware across the internet. Countermeasures ranging from Web Application Firewalls to sophisticated Machine Learning algorithms form an organisation's primary line of defence against bad bots.

Malicious Bot Threats

2020-08-12T13:00:00+10:00

Bots are software applications that automate repetitive tasks without human interaction. They have become part of the normal infrastructure of the internet. Some bots are useful; others are bad bots. The latter are the concern for application and security teams.

Bad bots keep changing and are increasingly difficult to detect. They can cause significant financial damage to organisations by disrupting online operations, overwhelming websites with traffic, and stealing information such as web content and ecommerce pricing data.

Bad Bot Types

Bad bots span a wide range of attack capabilities and scenarios. The following are the main categories these attacks fall into:

Spam Bots

Spam bots typically target blog comment sections, community portals and lead generation forms with 'garbage' or fake content. They can also insert unwanted ads, malicious phishing links and banners into real-time conversations to disrupt the service and attack users.

Scraping Bots

Price, content and inventory scraping bots steal prices and product listings. This can damage an ecommerce site's revenue stream and harm SEO rankings when duplicate content appears on competitor and bogus sites. These bots also scrape product reviews, news, product catalogues and user-generated content. Scraper bots can harvest email addresses, images and text from victim websites, then repurpose that material to pose as legitimate web pages.

Credential Stuffing Bots

Credential Stuffing Bots attempt to use login details from other sites, or run brute force guessing attacks against customer and admin accounts. If successful, they can make purchases, harvest personal information and purchase histories, make unauthorised cryptocurrency transactions, and transfer reward points and money to gift cards and air miles.

Ad Click Fraud Bots

Ad Click Fraud Bots can sabotage competitors by clicking on their ads to drive costs up and exhaust budget caps. They can also be used to scam advertisers with fake websites and ad clicks that pay the fraudster directly. In both scenarios, bots automatically generate interactions or 'clicks' with ads, promotions and media.

Credit Card Stuffing Bots

Carding bots make repeated attempts to authorise stolen credit card credentials. This can leave merchant payment processors with chargebacks and penalties, and may ultimately result in the victim merchant being prevented from accepting credit cards altogether.

Inventory Denial Bots

Cart Abandonment and Inventory Exhaustion bots automatically add hundreds of products to ecommerce shopping carts, then abandon them. This can block consumers from buying products, reduce sales, manipulate conversion rates and damage a brand’s reputation.

DDoS Bots and Botnets

Distributed Denial of Service (DDoS) attack bots and botnets are made up of thousands of compromised computers or Internet of Things (IoT) devices called "zombies". They can slow down a website or take it offline completely by flooding sites with massive amounts of artificially generated traffic. Researchers have found cybercriminals advertising DDoS services on the dark web with basic fees to attack unprotected sites ranging from $50 to $100, while an attack on a protected site can reach $400 or more.

Ticket Scalping Bots

Ticket scalping bots automatically buy tickets, enabling malicious users to resell them at a higher price. Examples include using a bot to purchase concert tickets for major events the minute they go on sale.

Fake Account Creation Bots

Fake Account Creation bots create fake accounts for criminal activities such as content spam, cryptocurrency laundering and malware distribution. Fake accounts can compromise brands and attack users with malware such as ransomware.

Hacker Bots

Hacker bots can distribute malware, attack websites and compromise entire networks by exploiting security vulnerabilities and injecting code into victim sites. Hacker bots can also perform DDoS attacks across web proxies with browser-like signatures to disrupt business operations.

Impersonator Bots

Impersonator bots copy human computer interactions and behaviours to fool users and bot mitigation defences while they conduct malicious activity. Impersonator bots also include propaganda bots that influence political opinions on platforms such as Facebook and Twitter. According to researchers at the University of Southern California who studied bot use during the 2016 U.S. Presidential election, “the presence of social media bots can indeed negatively affect democratic political discussion rather than improving it, which in turn can potentially alter public opinion.”

The Growing Threat

A report from Imperva found that roughly one-quarter of all website traffic in 2019 originated from bad bots, an increase of 18% over 2018. 75% of that bad bot traffic is made up by Advanced persistent bots (APBs) that attempt to evade detection by cycling through random IP addresses, using anonymous proxies, and changing their identities. The industries hardest hit by bad bots in 2019 included financial services, education, ecommerce and government, as well as media and airlines.

Companies offering "Bad Bots as-a-Service"* are also gaining ground. These data scraping services sell bots as easy-to-use packaged products that provide pricing and competitive intelligence, alternative data for finance, or competitive insights managed by Web Data Extraction Specialists and Data Scraping Specialists.

Malicious bot-for-hire services also offer personal and financial data harvesting, brute-force login services, ad click fraud, spamming services, transaction fraud services, and Distributed Denial of Service (DDoS) attacks.

Final Thoughts

Bad bot activity continues to increase, so websites need security controls that can identify and stop them. Our next article on bots will go over the common countermeasures used to combat bad bots.