The Attack Pattern Your Logs Are Already Seeing
A financial services company notices a slow trickle of failed authentication attempts against its customer portal. The source IPs rotate every few minutes, span a dozen countries, and each one resolves to a different residential ISP. None of the IPs appear on commercial blocklists. The velocity is low enough to stay below rate-limiting thresholds. The accounts being tested belong to real customers. Six hours later, a small percentage of those accounts have been accessed successfully and the session tokens have been harvested.
This is not a theoretical scenario. It is a compressed version of what credential stuffing operations using residential proxy networks look like in practice, and it represents one of the most persistent detection challenges facing SOC teams today. The 72-minute average attacker dwell time cited in recent threat intelligence reports assumes defenders are working with clean telemetry. When the attacker's traffic is routed through rotating proxies or commercial VPN exit nodes, that telemetry becomes significantly harder to interpret.
Understanding VPN abuse and proxy detection requires separating several distinct threat categories, because the detection logic for each differs substantially. Conflating them leads to alert configurations that miss the actual threat while generating noise around legitimate users.
What Attackers Are Actually Routing Through
The infrastructure attackers use to anonymize their origin traffic falls into four broad categories, each with different detection signatures.
Commercial VPN Services
Commercial VPNs like NordVPN, ExpressVPN, and Mullvad operate large pools of shared exit IP addresses. These IPs are well-documented. Multiple commercial and open-source databases maintain lists of known VPN exit nodes, and ASN lookups for the associated netblocks will typically return the VPN provider's name directly. The challenge is not identification; it is policy. Blocking all commercial VPN traffic creates friction for legitimate remote workers and privacy-conscious users. The detection question becomes one of context: is this VPN traffic arriving at a resource where VPN use is unexpected or where the risk profile of the session justifies additional scrutiny?
Residential Proxy Networks
Residential proxies are a different problem entirely. These are IP addresses assigned by consumer ISPs to real households, often associated with devices that have been enrolled in proxy networks either voluntarily through browser extensions and applications or involuntarily through malware infection. The 'Popa' botnet, recently linked to a publicly-traded Israeli firm, illustrates how commercially-operated residential proxy infrastructure can obscure the line between a managed network service and an abusive botnet. When a credential stuffing attack arrives from what appears to be a residential IP in suburban Ohio, standard IP reputation feeds provide little signal because the IP itself has no history of abuse.
Data Center Proxies and Hosting Providers
Data center proxies route traffic through IPs registered to cloud providers and hosting companies. AWS, DigitalOcean, Vultr, and dozens of smaller providers host infrastructure that attackers use for both direct attacks and as relay points. ASN-based filtering catches a significant portion of this traffic, but attackers aware of this control rotate across hosting providers or use compromised legitimate cloud accounts to blend in with normal outbound traffic from those netblocks.
Tor Exit Nodes
Tor routes traffic through multiple relay nodes before exiting onto the public internet through an exit node. The exit node IP is the only address visible to the destination server. Tor exit node lists are publicly maintained and updated frequently, making detection straightforward at the IP level. The policy question again is the harder one, particularly for services that have legitimate use cases among privacy-conscious users or journalists operating in restrictive environments.
Why Standard Detection Fails Against Modern Proxy Abuse
The Novo Nordisk breach exposed how attackers can move through software development pipelines without triggering conventional detection because the telemetry looked like normal developer activity. Proxy abuse creates a similar problem: the traffic looks like it is coming from diverse, legitimate sources because it is, in a technical sense, originating from those locations.
Several factors degrade detection accuracy specifically in proxy and VPN scenarios.
IP reputation feeds operate on historical data. A residential IP that was never previously used for abuse will have a clean reputation score even if it is currently being used as a proxy relay. By the time abuse is reported and propagated through the feed, the operator has rotated to a different IP. The lag between abuse and reputation update can range from hours to weeks depending on the feed provider and the nature of the abuse.
Geolocation data provides the originating location of the exit node, not the attacker's actual location. An attacker in one country routing through a residential proxy in another country appears to originate from the proxy's location. This creates false confidence in geolocation-based controls and can actively mislead analysts during incident investigation.
Session consistency signals are diluted. Modern proxy networks maintain individual sessions long enough to pass basic behavioral checks. An attacker using a rotating residential proxy pool can sustain a single logical attack campaign across hundreds of distinct IP addresses, each appearing to represent a different user session with consistent session duration and request patterns.
Detection Architecture That Generates Actionable Signal
Effective proxy and VPN detection requires layering signals that no single data source provides alone. The following framework maps detection controls to the specific threat categories described above.
ASN and Hosting Provider Classification
The first layer is classifying inbound IP addresses by their registered ASN and cross-referencing against a taxonomy of provider types: residential ISP, commercial VPN provider, data center or hosting company, mobile carrier, educational institution, and government. This classification does not block traffic automatically but informs risk scoring. An authentication request arriving from a data center ASN on a consumer banking portal is a materially different risk event than the same request arriving from a residential ISP in the account holder's registered city.
Maintaining accurate ASN classification requires either a commercial IP intelligence provider or regular updates from sources like MaxMind, IPinfo, or IPAPI. ASN assignments change, and IP blocks get reallocated between provider types. Stale classification data creates both false positives and false negatives.
Hosting Provider and VPN Database Matching
For commercial VPN and data center proxy detection, the most direct control is matching against current IP lists for known VPN providers and major hosting provider netblocks. Several providers maintain these lists with daily or hourly updates. Integrating them into your WAF, authentication proxy, or SIEM enrichment pipeline allows you to flag or step-up-authenticate sessions originating from these ranges without outright blocking.
The OceanLotus APT group's shift toward domestic targeting, documented in recent threat intelligence, demonstrates that nation-state actors adapt their infrastructure selection based on detection patterns. Groups that previously relied on data center infrastructure have shifted toward residential proxies and VPNs specifically because they know hosting provider netblocks receive heavier scrutiny.
Behavioral Consistency Analysis
IP-level detection alone is insufficient against residential proxy networks. Behavioral analysis at the session and account level provides the complementary signal. Patterns that indicate proxy abuse in authentication contexts include:
- Account access from an IP geolocation inconsistent with the account's historical access pattern, particularly when the new location does not correspond to any registered device
- Rapid sequential access attempts across multiple accounts from the same or adjacent IP ranges
- Session characteristics that do not match the declared user agent, such as a mobile user agent paired with desktop screen resolution parameters or the absence of expected JavaScript execution signals
- Time-of-day patterns inconsistent with the account's historical activity, especially when the anomaly correlates with known threat actor operating hours in a specific timezone
TLS Fingerprinting
JA3 and JA4 TLS fingerprinting captures the characteristics of the TLS client handshake independent of the IP address or user agent string. Automated attack tools, proxy clients, and legitimate browsers produce different TLS fingerprint signatures. A session presenting a Chrome user agent but producing a TLS fingerprint associated with Python's requests library or a specific proxy client implementation is a strong anomaly signal. This technique is particularly effective against credential stuffing tools that rotate IPs but use a consistent underlying HTTP client library.
Integrating TLS fingerprinting into your detection stack requires either a WAF or reverse proxy that supports JA3/JA4 logging, or network tap analysis using tools like Zeek. The raw fingerprint values require a reference database to interpret, but several open-source and commercial databases map known fingerprints to tool families.
HTTP Header Consistency Checks
Proxy traffic frequently introduces anomalies in HTTP header composition. Headers like X-Forwarded-For, Via, X-Real-IP, and Forwarded indicate the presence of intermediate proxy infrastructure. The presence of these headers in requests to an origin server that sits behind a load balancer or CDN warrants scrutiny, particularly when the declared forwarded IP differs from the connecting IP in ways that suggest deliberate obfuscation rather than legitimate CDN forwarding.
Header order and composition also vary by browser and tool. Legitimate Chrome requests include a consistent set of headers in a consistent order. Requests constructed by attack tools or proxy clients frequently omit headers that a genuine browser would send or include headers in an order no real browser produces. Building detection rules around these patterns requires sample collection from legitimate traffic to establish baselines, but once established, the rules generate high-confidence signals with low false positive rates.
Implementing Proxy Detection in Real Environments
Theory differs from implementation. The following describes practical deployment considerations for the detection controls above.
WAF Integration
Most enterprise WAF platforms support IP reputation enrichment through external feed integration or built-in threat intelligence databases. Configuring your WAF to tag requests from known VPN and data center netblocks as a risk attribute, rather than blocking them outright, allows downstream decision logic to incorporate the signal without creating access disruption. The tagged attribute feeds into authentication policy: a login from a known VPN exit node triggers MFA even if the account normally authenticates without it. A login from a known Tor exit node triggers a step-up challenge or temporary block depending on the service's risk tolerance.
SIEM Enrichment Pipeline
IP intelligence enrichment in the SIEM allows analysts to see proxy and VPN indicators inline with other log data without requiring the WAF to make real-time blocking decisions. Every authentication event should carry enriched fields showing the ASN, provider type, VPN flag, and hosting provider flag alongside the raw IP. Correlation rules that look for patterns across multiple authentication events benefit directly from this enrichment because the pattern of a rotating residential proxy campaign becomes visible as a series of events sharing the same behavioral profile despite originating from different IPs.
The cyber-enabled maritime sanctions evasion cases documented in recent enforcement actions relied heavily on IP anonymization through VPNs and proxies to obscure the geographic origin of transactions. The investigators who traced these cases used enriched log data to identify session consistency patterns that persisted across IP rotation, demonstrating that enrichment-based detection works against sophisticated actors, not just opportunistic attackers.
Authentication Policy Integration
Risk-based authentication policies that incorporate proxy and VPN signals are more operationally effective than static IP blocklists. A policy that adjusts authentication requirements based on a computed risk score including IP classification, behavioral history, device fingerprint, and session context scales better and adapts to attacker infrastructure rotation. When an attacker switches from a known VPN provider to a residential proxy network, the IP-level block fails but the behavioral and device fingerprint signals continue to fire.
Implementing this requires an identity platform that supports contextual authentication policies or a custom authentication proxy that evaluates enriched request attributes before passing the authentication decision to the backend identity store.
The Gravity SMTP WordPress Vulnerability and Proxy-Assisted Exploitation
The recently reported information disclosure vulnerability in the Gravity SMTP WordPress plugin illustrates a common proxy abuse scenario in web application contexts. Attackers scanning for vulnerable plugins across large numbers of sites typically use proxy networks to distribute the scan traffic and avoid triggering rate-limiting controls on any individual site. Each request in the scan appears to originate from a different residential IP, the scan velocity per IP stays low, and the aggregate scanning activity only becomes visible when you correlate across a broader IP range or look at the behavioral pattern rather than the per-IP volume.
Detecting this type of distributed scanning requires moving the detection logic from per-IP rate limiting to behavioral fingerprinting at the request level. The scan requests targeting the Gravity SMTP vulnerability produce a consistent URL pattern regardless of the originating IP. A WAF rule or IDS signature matching that URL pattern across all source IPs will catch the distributed scan even when the per-IP rate stays below thresholds. This generalizes to any situation where proxy rotation distributes traffic below per-IP detection thresholds: shift the detection anchor from IP identity to request content, header composition, or behavioral pattern.
Surveillance Camera Infrastructure and Proxy Relay Risk
The recent reporting on cybercriminals selling access to Chinese surveillance cameras connects directly to proxy and VPN abuse in a specific way. Compromised IoT devices, including IP cameras, are frequently enrolled in residential and commercial proxy networks. The IP addresses associated with these devices are registered to legitimate ISPs and businesses, have no abuse history, and appear as clean residential or commercial addresses to standard IP reputation checks.
When attackers use compromised camera infrastructure as proxy relay points, the detection challenge compounds. The traffic exits through an IP associated with a legitimate business at a fixed physical location. The IP passes geolocation checks, ASN classification looks normal, and the reputation score is clean. Detection in this scenario depends on the behavioral and TLS fingerprinting signals described above, because the IP-level signals provide no useful information.
Building Toward Resilient Detection
Sustainable proxy and VPN abuse detection rests on a few architectural principles that apply regardless of which specific tools or platforms you are working with.
Detection logic should degrade gracefully when any single signal source becomes unavailable or stale. IP reputation feeds go stale. VPN provider IP lists change. A detection architecture that depends on any single external data source will have gaps when that source lags. Layering behavioral signals, TLS fingerprinting, and header analysis ensures that when IP-level signals fail, the other layers continue to generate signal.
Analyst workflows should be designed around the enriched data, not the raw logs. An analyst investigating an authentication anomaly should see the ASN classification, VPN flag, TLS fingerprint, and behavioral consistency score in the same view as the authentication event details. Requiring analysts to manually query multiple systems to assemble this context introduces delay and increases the probability that the context is assembled incorrectly or incompletely.
Detection rules require regular calibration against current attacker infrastructure. The residential proxy networks and VPN providers popular with attackers today are different from those used six months ago. Rules calibrated against historical infrastructure patterns will degrade over time as attacker infrastructure evolves. Building a feedback loop from incident findings back into detection rule updates is a structural requirement, not an optional improvement.
Proxy and VPN abuse will remain a persistent challenge because the underlying infrastructure serves legitimate purposes at scale. The goal is not eliminating VPN and proxy traffic from your environment but building detection logic sophisticated enough to distinguish the threat signal from the legitimate noise. The teams that succeed at this are the ones that treat IP identity as one input among many rather than the primary anchor for their detection logic.
