# Your Firewall Trusts Comcast. So Do the Attackers.
The IP address looks fine. It resolves to a residential ISP in Ohio. No prior malicious activity. Clean reputation score. Your WAF waves it through.
What you just let in was a credential stuffing bot routing through someone's hacked home router — part of a rented proxy pool that an attacker paid $50 for on a Telegram channel. The session looks legitimate because the underlying infrastructure *is* legitimate. That's the whole point.
This is the problem that edge security solved for and then partially un-solved: the moment defenders got good at blocking datacenter IPs and known bad actors, attackers moved upmarket into residential proxy networks. The game of "trust this IP or not" was always somewhat fragile. Now it's being played against you at scale by people who understand its assumptions better than most defenders do.
## The Infrastructure Attackers Actually Use
Residential proxies are not exotic. The market for them — legal, commercial, openly advertised — is massive. Companies like Bright Data (formerly Luminati), Oxylabs, and Smartproxy sell access to pools of millions of real residential IPs, often sourced from users who installed an app and agreed to share their bandwidth in exchange for some service. The legitimate use cases exist: ad verification, price comparison, localized content testing. The illegitimate uses ride on the same infrastructure.
What makes this particularly uncomfortable for defenders is that the IPs themselves have done nothing wrong. A Comcast subscriber in Cleveland didn't attack anyone. Their router just happens to be in a proxy pool. When your threat intelligence feeds score IP reputation, that IP scores clean — because it is clean, in isolation.
The attacker's session is the malicious artifact, not the endpoint it's routing through. And most edge security is architected to evaluate endpoints.
VPNs create a related but slightly different problem. Consumer and commercial VPN exit nodes rotate rapidly and are used by legitimate users constantly. Blocking them aggressively means blocking a significant chunk of real user traffic — security researchers, privacy-conscious users, remote workers behind corporate VPNs, travelers. The false-positive cost is real. Attackers know this. They park in VPN infrastructure specifically because they know defenders won't nuke it wholesale.
## What "Session Enrichment" Actually Means in Practice
The defensive answer is to stop treating the IP as the unit of analysis and start treating the session. Session enrichment is the practice of layering additional signals onto a live request — not just "where is this traffic coming from" but "what does this session *look like* in aggregate?"
The signals worth enriching against include behavioral patterns (timing between requests, navigation paths, interaction cadence), device fingerprinting (canvas rendering, WebGL characteristics, font enumeration, battery API behavior), TLS fingerprint analysis (JA3/JA4 hashes that identify the underlying client, regardless of what it claims to be), and proxy/VPN detection that goes deeper than IP reputation — specifically looking at whether the network path characteristics match what the claimed IP type would produce.
None of these alone is deterministic. A sophisticated attacker using a headless browser that mimics Chrome's TLS fingerprint and paces requests to match human timing patterns will beat most individual signals. The value of enrichment is in correlation: a session that passes the IP check but fails the TLS fingerprint check, shows no mouse movement variance, and matches timing patterns seen in known stuffing campaigns starts to look very different from the sum of its parts.
Spur's work in this space focuses specifically on proxy detection — their intelligence is structured around identifying IP addresses that are functioning as proxies even when they don't look like it. That's useful infrastructure, but it's worth understanding what it is: a specialized feed, not a complete picture. The enrichment approach works best when it's multi-vendor and multi-signal, because no single data source covers the full surface.
## The Enforcement Problem Nobody Talks About
Detecting a risky session is one thing. Doing something useful with that detection is harder than it sounds.
The naive response — block anything that looks suspicious — generates false positives that cost real money. If your WAF starts throwing challenges at sessions that happen to share characteristics with bot traffic, you will challenge real users, frustrate legitimate conversions, and generate support tickets. Risk-based enforcement that works in production requires tuning that takes time and data, and it requires accepting some rate of both false positives and false negatives.
The more mature approach treats risky sessions as a spectrum rather than a binary. A session with moderate proxy signals gets a step-up authentication challenge. A session with strong signals on multiple indicators gets harder friction or a soft block. A session that's almost certainly automated gets dropped. The gradient matters because the population of "risky-looking" traffic is not homogeneous — it includes fraud attempts, yes, but also security researchers, penetration testers, and users on shared networks.
That tuning work is ongoing and never finished. Attackers adapt to detection methods. The residential proxy ecosystem evolves. Session enrichment is not a solution you deploy and walk away from; it's a capability you maintain.
---
## HackWire Analysis
The framing of "edge security misses high-risk sessions" understates what's actually happening. Edge security was never designed to solve the problem being described here. WAFs were built to block known-bad payloads and exploit patterns. Bot detection evolved to catch datacenter-origin automation. Neither was architected around an adversary who is deliberately, commercially, at scale, purchasing access to infrastructure that looks indistinguishable from legitimate traffic.
What's missing from most coverage of this space is the supply chain angle on residential proxies. The millions of IPs in commercial proxy pools didn't all get there consensually. Research has consistently found that proxy providers often source IPs from SDK integrations embedded in mobile apps — apps whose users had no meaningful understanding that their device bandwidth would be resold. Some of that infrastructure overlaps directly with botnet activity. The line between "commercial residential proxy" and "bot network" is less clear than the proxy industry's marketing suggests.
That matters for defenders because it means IP reputation scores are structurally underinformative at the residential end. The signal you're trying to extract — "has this IP been involved in malicious activity" — is corrupted by the fact that the IP owner may be completely unaware of the malicious use of their connection.
The practical implication: organizations running high-value login flows, checkout pages, or API endpoints with access to sensitive data should treat session enrichment not as a vendor add-on but as a first-class detection capability. The credential stuffing and account takeover cases where attackers pay for residential proxies are precisely the cases where the losses justify the investment. Banks, retailers, and healthcare platforms with member portals are the primary targets — and the ones most exposed when their edge security stops at IP reputation.
The defenders who will fare best are the ones who've already accepted that the network perimeter is not where this fight gets won.
— HackWire Editorial
---
## Related Coverage