The alert fires on the login endpoint, but the traffic behind it looks clean. Each attempt comes from a different home broadband connection, so no single IP gets near the lockout threshold. Every address passes the reputation checks the security stack runs. Signups show the same pattern, with a burst of new accounts that each appear to come from a separate household.
Both point to residential proxy abuse. Attackers rent or hijack exit IPs on consumer ISP networks and route requests through them, so each request inherits the good standing of a real subscriber’s address. Blocking those IPs would also lock out the households that use them. Catching the abuse means looking past the IP to the device and client software behind each session.
- IP reputation misses residential proxies, whose addresses carry real household traffic and rotate before blocklists catch up.
- Device fingerprint reuse and TLS hashes that contradict the claimed browser still expose proxied sessions.
- MFA and rate limits keyed to accounts and devices contain the damage without blocking real households.
Where residential proxy IPs come from
Consent-based sourcing
Consent-based proxy pools grow through bandwidth-sharing apps whose users opt in and let other people’s traffic exit through their home connection for a small payment or in-app rewards. Static residential IPs come from ISP-assigned ranges that a provider hosts on its own servers.
Malware and bundled apps
Abusive networks skip consent and enroll devices through malware or “free VPN” apps with a hidden proxy component. The US Department of Justice announced the 911 S5 takedown on May 29, 2024. That botnet involved about 19 million unique IP addresses worldwide, more than 613,000 of them in the US.
Its malware spread through MaskVPN and DewVPN, VPN apps the administrator ran, and through torrents and pay-per-install services bundled with pirated software. Buyers used the hijacked IPs for financial fraud and identity theft, among other crimes. Losses from 560,000 fraudulent unemployment claims alone reached $5.9 billion, and the indictment says the administrator made about $99 million selling that access.
How attackers use residential IPs
Account takeover and credential stuffing
Credential stuffing drives failed logins well above baseline, many of them for usernames that never existed on the site, since the lists come from other breaches. Successful logins are often followed within minutes by a change to the recovery email or payment method.
Fake accounts and promotion abuse
Promotion abuse depends on accounts that look unrelated, and residential IPs handle that at the network layer. In the logs, the accounts still cluster by email naming pattern or bunched creation times, and many go dormant after claiming a welcome credit.
Ad fraud and scalping
In ad fraud, residential IPs give fake clicks a consumer origin that slips past datacenter filters. Campaign reports show click-through rates rising while conversions stay flat.
Scalping hits retailers during limited releases. Carts fill from many residential IPs within seconds of a drop, and the orders converge on a few delivery addresses.
Why IP reputation alone fails
IP reputation works when one operator controls an address, such as a hosting server or a VPN exit. When the exit is a home connection, the household’s own traffic uses the same IP, and carrier-grade NAT can put many subscribers behind it.
Residential pools also rotate quickly, so an address usually reaches a blocklist after the attacker has moved on. Teams that try to detect residential proxies with reputation feeds alone end up blocking the households behind those addresses. Those false positives reach the support queue as locked-out customers.
Residential proxy detection signals that still work
| Signal | What it catches | False-positive risk |
|---|---|---|
| Request velocity per account and device | Credential stuffing and checkout bots | Low |
| One device fingerprint reused across many IPs | One machine cycling through exits | Medium (same-model phones) |
| TLS or HTTP client fingerprints (such as JA3 or JA4) that do not match the claimed browser | Scripts posing as browsers | Low (higher behind TLS inspection) |
| Timezone and language that do not match IP geolocation | Operators far from the exit | Medium (travelers, VPN users) |
| Round-trip latency inconsistent with the claimed location | An extra relay hop | Medium (mobile, satellite) |
| ASN changes within one session | Exit rotation | Medium (Wi-Fi to cellular) |
Behavioral signals
Velocity counters per account and per device catch a stuffing run that no per-IP counter would flag. A daily count of distinct IPs per device fingerprint separates proxy rotation from a laptop moving between home and office. Automated sessions tend to call the login API without loading the page.
Network and client signals
A JA4 hash from a scripting library, sent with a Chrome User-Agent, points to automation, however clean the IP looks. The browser’s timezone and language can be checked against IP geolocation in the same request.
When a round trip timed inside the page runs well above the TCP round trip the server sees, the gap indicates a relay hop. Mid-session, a jump between two fixed broadband ISPs suggests a rotated exit, while a Wi-Fi to cellular switch is normal.
Combining signals into a risk score
Proxy fraud detection holds up best when no single signal can block a session, since each one misfires on some legitimate traffic. IP reputation stays in the model as one weighted input alongside context such as account age. Thresholds vary by endpoint, because a password reset deserves more scrutiny than a product search.
Controls that limit the damage
Stronger authentication
With a second factor in place, a stuffed password alone no longer opens the account, whatever IP the login comes from. Accounts that use passkeys have no password to stuff. Where MFA on every login is too much friction, a high risk score can trigger a step-up challenge instead.
Rate limits and session checks
Rate limits keyed to the account and device instead of the IP keep working when every request arrives from a new exit. Session-level impossible-travel checks force a new login when a session jumps far from where it started, so stolen cookies are harder to reuse. Device fingerprints and JA4 hashes from confirmed attacks are worth sharing with peers through an ISAC, since they outlast rotating IPs.
Questions to ask any proxy provider
- How are the IPs sourced, and with what consent?
- Are customers verified before getting access?
- Is there an abuse reporting channel?
- What is logged, and for how long?
- How is the acceptable-use policy enforced?
An abuse report usually holds just an IP and a timestamp, which only help if they point to one customer. Unlike shared residential exit pools, where one address carries many users’ traffic, SOCKS5 IPs tied to a single customer account let the provider trace each report to one buyer. SOCKS5 carries both TCP and UDP traffic, so a proxy using it can relay more than web requests, and the same lookup covers complaints from mail or game servers.
Starting with the logs
A security team can start by logging the device fingerprint and JA4 hash on every login and signup. After a few weeks, a query for devices that touched many accounts through many residential IPs shows how much residential proxy abuse gets through and yields labeled cases for the risk score.