The Operational Reality Most Teams Skip Over
Security teams spend considerable time configuring IP blocklists, subscribing to threat feeds, and tuning firewall rules around known VPN exit nodes and proxy addresses. The operational assumption embedded in this approach is that bad traffic arrives from identifiable sources. Increasingly, that assumption costs organizations their first detection opportunity.
Attackers running credential abuse campaigns, application-layer fraud, and reconnaissance operations against enterprise targets understand exactly how proxy detection is typically deployed. They route sessions through residential proxies, cycle exit nodes faster than blocklists refresh, and chain anonymization layers specifically to defeat the controls defenders have invested in. The result is that organizations see clean-looking traffic right up until the moment they see a breach.
This article is aimed at cybersecurity professionals and IT administrators who already have proxy detection in some form and need to understand where it structurally breaks down, and how to rebuild detection around the behaviors that cannot be easily spoofed.
What Attackers Are Actually Routing Through Proxies in 2026
The Unit 42 2026 Global Incident Response Report makes clear that attacker infrastructure sophistication has accelerated significantly. Threat actors are not just using commercial VPN services or Tor exit nodes. They are leasing access to residential proxy pools, compromising edge devices to use as relay points, and deploying modular command-and-control frameworks that blend into legitimate traffic patterns.
The Cavern Manticore disclosure from earlier this year exposed exactly this kind of infrastructure. The Iran-linked C2 framework used modular relay architecture specifically designed to make traffic origin attribution difficult. Sessions traversing that infrastructure would appear to originate from geographically plausible locations, from ISP ranges associated with legitimate residential users, and from IP addresses with no prior reputation history.
The 911 S5 botnet, despite its dismantling, left a digital legacy that matters here. The residential proxy pool it operated at scale demonstrated that millions of compromised residential IPs could be made available to paying customers for session-level anonymization. Successor infrastructure built on similar principles continues to operate. When traffic hits your application layer from a residential cable ISP address in a country your organization serves, your blocklist-based controls have no signal to work with.
Mirage Kitten's recent targeting of organizations across the Middle East and Africa region involved precisely this kind of layered obfuscation. The group used multiple proxy hops to make attribution difficult and to defeat controls that relied on geographic or ASN-based filtering. Recorded Future's reporting on modern attack vectors echoes this pattern across multiple threat actor clusters: proxy infrastructure is now considered table stakes for any sustained campaign.
Where Standard Detection Breaks Down
Understanding the specific failure points in conventional proxy detection helps security teams prioritize where to invest detection effort.
Commercial VPN Blocklists Age Faster Than They Are Updated
Most threat intelligence vendors maintain lists of known VPN service exit nodes. These lists are useful for flagging obvious consumer VPN usage but carry two structural weaknesses. First, commercial VPN providers rotate their exit node pools regularly, meaning any blocklist has a freshness problem measured in hours to days. Second, sophisticated attackers do not use commercial VPN services for operations that require sustained access or high confidence of anonymity. The actors who matter most to your threat model are not using NordVPN.
Residential Proxies Carry No Reputation Signal
A session originating from a residential broadband address assigned to a household in your target geography looks identical to a legitimate user session at the IP reputation layer. The address has never appeared in a threat feed. The ASN is a consumer ISP. The geolocation is plausible. Standard IP reputation scoring assigns it a clean bill of health, and your detection stack waves it through.
Header-Based Detection Is Actively Evaded
Many proxy detection implementations rely on HTTP header inspection. They look for X-Forwarded-For headers, Via headers, or other indicators that a session was routed through an intermediary. Purpose-built proxy infrastructure and modern residential proxy networks are explicitly configured to strip these headers before the request reaches its destination. The ESET Threat Report for H1 2026 notes that evasion technique sophistication in commercial crimeware kits has increased, and header stripping is a standard feature in proxy tools available to low-sophistication actors.
TLS Fingerprinting Is Helpful But Circumventable
JA3 and JA4 fingerprinting of TLS client hello messages can surface anomalies where the client fingerprint does not match what the claimed user agent or platform would produce. This catches some proxy configurations. Attackers running browser-in-the-browser infrastructure or using instrumented real browsers as proxy endpoints produce TLS fingerprints that match exactly what a real browser session would produce, because the traffic is literally originating from a real browser.
Building Detection Around Behavior, Not Origin
The detection surface that attackers cannot easily fake is behavioral. Sessions routed through proxy infrastructure for abuse purposes behave differently from legitimate user sessions in ways that accumulate into detectable signal even when the IP address carries no reputation history.
Velocity and Session Geometry
A single IP address completing authentication attempts across multiple accounts within a compressed time window is a signal regardless of whether that IP is a known proxy. Credential stuffing campaigns routed through residential proxy pools cycle source addresses, but the campaign-level velocity signature survives: a large number of authentication attempts across many accounts, distributed across many source IPs, arriving within a bounded time window, targeting the same endpoints.
Detection logic should aggregate at the campaign level, not just the per-source-IP level. When 400 authentication attempts arrive from 400 different IP addresses across a 10-minute window, and each attempt targets a different username, that pattern is detectable even though no individual source IP triggers a per-IP threshold.
Session Fingerprint Consistency
Legitimate users exhibit consistency across sessions over time. Their device fingerprint, timezone, language settings, screen resolution, and behavioral biometrics cluster around stable values. Sessions arriving through proxy infrastructure for abuse purposes frequently exhibit inconsistencies: the claimed user agent says Windows but the canvas fingerprint suggests a Linux host, the timezone does not match the claimed geolocation, or the session exhibits mouse movement patterns characteristic of automation.
Browser fingerprinting at the application layer, combined with consistency checking against historical session data for returning users, surfaces these mismatches. First-time sessions cannot be checked against history, which is why new account registrations and first-time authentications deserve higher friction by default.
Inter-Session Behavioral Patterns
Application usage behavior differs between legitimate users and automated or semi-automated sessions. Legitimate users navigate non-linearly, spend variable amounts of time on pages, follow paths that reflect actual intent, and generate incidental activity like hover events, scroll behavior, and abandoned form interactions. Automated sessions traversing proxy infrastructure tend toward direct API call patterns, consistent request timing, and navigation paths that reflect scraping or credential testing logic rather than user intent.
Web application firewalls and bot management platforms that operate at the behavior layer rather than the IP reputation layer detect these patterns. Deploying this capability in front of authentication endpoints, account creation flows, and high-value API paths creates a detection surface that proxy rotation cannot easily defeat.
What to Do Today, This Week, and This Quarter
Today
Pull the last 72 hours of authentication logs and run a query for source IP diversity per username and per endpoint. Look for any endpoint that received authentication attempts from more than 20 distinct source IPs in a six-hour window. That pattern is worth investigating regardless of whether any individual IP appears in a threat feed. Document what you find and compare it to your existing alert rules to identify whether that pattern would have fired any existing detection.
Check whether your web application firewall or load balancer is configured to pass X-Forwarded-For and similar proxy header values into your logging pipeline. If those headers are being stripped upstream, you have a visibility gap into sessions that are being relayed through intermediate infrastructure. This is a five-minute log format audit that frequently surfaces missing telemetry.
This Week
Implement or review your campaign-level aggregation rules in your SIEM. The goal is detection logic that fires on distributed patterns: many authentication attempts across many source IPs targeting the same application within a bounded time window. Set thresholds based on your application's normal traffic profile, not on arbitrary round numbers. A threshold of 50 distinct source IPs hitting your authentication endpoint in 10 minutes may be appropriate for a small SaaS application and completely inappropriate for a large consumer-facing platform.
Evaluate your current proxy detection data sources. If you are exclusively relying on IP reputation feeds and blocklists, identify at least one additional signal layer: TLS fingerprinting via JA4, datacenter ASN detection for traffic claiming to be consumer residential, or HTTP/2 frame header analysis that surfaces mismatches between claimed client type and actual protocol behavior. None of these is individually sufficient, but each narrows the gap.
Review your response playbook for detected proxy abuse. A common gap is that detection fires but the response action is limited to blocking the triggering IP, which is irrelevant when the campaign cycles through thousands of addresses. The response to a distributed credential stuffing campaign should include mandatory MFA step-up for affected accounts, temporary rate limiting on the targeted endpoint, and notification to account owners who received authentication attempts they did not initiate.
This Quarter
Invest in behavioral signal at the application layer. This means deploying a bot management or device intelligence solution that operates on session behavior rather than IP reputation. Evaluate vendors on their ability to detect proxy-routed sessions by behavioral fingerprinting rather than by checking a blocklist. Request demonstration data on detection rates specifically for residential proxy traffic, since this is where most blocklist-based solutions have their largest gap.
Build a detection use case that specifically targets datacenter IP ranges presenting as consumer traffic. Many proxy networks use datacenter infrastructure to host the proxy software while advertising residential IP addresses as the exit points. This creates a mismatch detectable through ASN analysis of the actual connecting IP versus the forwarded IP. When the connecting IP resolves to a hosting provider ASN but the X-Forwarded-For header claims a residential ISP address, that inconsistency is a detection opportunity.
Run a tabletop exercise that simulates a credential abuse campaign routed through a residential proxy pool. Give the red team realistic proxy infrastructure and task the blue team with detecting and responding. The exercise will surface specific gaps in your current detection stack and provide concrete requirements for capability investment. Given the AI-driven automation described in the Unit 42 2026 report, where attack campaigns are increasingly orchestrated rather than manually operated, simulating an automated, high-velocity campaign is more representative of your actual threat environment than a manually paced exercise.
The Infrastructure Intelligence Layer
One detection approach that receives less attention than it deserves is hosting infrastructure analysis conducted at investigation time rather than as a real-time blocklist check.
When an IP address appears suspicious based on behavioral signals, an analyst can query its hosting history, co-hosted domains, SSL certificate history, and ASN trajectory. Legitimate residential IP addresses have clean histories with no hosting infrastructure associations. IP addresses used in proxy networks, even residential-appearing ones, frequently show up in passive DNS data co-located with domains associated with proxy services, or hosted on ASNs that have appeared in previous abuse investigations.
This analysis does not work as a real-time gate. It works as an investigation accelerator. When behavioral detection fires on a session, the analyst investigating it can use infrastructure intelligence to determine within minutes whether the source IP has characteristics consistent with proxy infrastructure, even without it appearing in any threat feed. Services like those built on BGP routing history, passive DNS, and SSL certificate transparency logs provide this data.
The AI-driven extortion campaigns and automated attack infrastructure described across the 2026 threat reporting from ESET, Unit 42, and Recorded Future all rely on proxy and relay infrastructure that leaves traces in these data sources. Building investigative workflows that query this data during triage makes your team faster at confirming or ruling out proxy abuse as a contributing factor.
Applying This to Non-Web Attack Surfaces
Most proxy detection discussion focuses on HTTP traffic and web application security. Proxy and anonymization infrastructure also appears in attacks against SSH, RDP, SMTP, and API endpoints that operate over non-HTTP protocols.
The same behavioral principles apply. Velocity patterns across many source IPs, timing inconsistencies inconsistent with legitimate usage, and geographic implausibility all surface as signals against non-web targets. For SSH specifically, honeypot data consistently shows that brute force campaigns routed through proxy infrastructure exhibit session setup and teardown timing patterns that differ from interactive human sessions. For SMTP, bulk outbound scanning or abuse campaigns routed through compromised infrastructure show sender pattern clustering that survives IP rotation.
Configuring detection rules in your SIEM that aggregate connection attempts by target service and time window, rather than by source IP, applies the same campaign-level logic to these protocols that behavioral bot detection applies to web sessions.
Where the Detection Gap Actually Closes
The fundamental point is that proxy infrastructure defeats origin-based detection but cannot defeat pattern-based detection. Attackers can change where traffic appears to come from. They cannot easily change what they are doing, because what they are doing is determined by their objective.
A credential stuffing campaign must attempt authentication against many accounts. A web scraping operation must request content at a rate that reflects its collection objective. An application-layer reconnaissance operation must probe endpoints systematically. These objectives produce behavioral signatures that survive proxy rotation, VPN service changes, and Tor circuit cycling.
Security teams that build detection around these behavioral signatures, and that treat IP reputation as one supporting signal among several rather than as a primary gate, are building detection that is structurally harder for attackers to defeat. The investment required is not primarily in more threat intelligence subscriptions. It is in detection logic that aggregates behavior at the campaign and session level, and in analytical workflows that can distinguish automated or proxy-routed traffic from legitimate user sessions without relying on the source IP to carry the full detection burden.
