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.
