When Anonymized Traffic Becomes the Attack Surface
In late 2022, the 0ktapus campaign compromised over 130 organizations through a methodical combination of smishing, credential harvesting, and lateral movement. Post-incident analysis revealed that a significant portion of the attacker infrastructure routed through residential proxies and commercial VPN exit nodes, which allowed malicious authentication attempts to blend into legitimate remote access traffic. Security teams watching for geographic anomalies were effectively blinded because the source IPs resolved to the same countries as the victims' own workforce.
This is the scenario that exposes the gap between having proxy detection on paper and actually acting on it operationally. The problem is architectural before it is technical. Most organizations deploy VPN abuse and proxy detection as a bolt-on layer rather than integrating it into authentication pipelines, session management, and threat response workflows. The result is detection that fires after the breach rather than before it.
This article works through how proxy and VPN abuse actually operates in enterprise environments, how to build detection that influences real-time access decisions, and where the tradeoffs land when you tighten controls.
What Attackers Actually Do with Proxies and VPNs
There is a spectrum of anonymization infrastructure in active use, and understanding where each sits helps prioritize detection effort.
Residential proxies are the hardest to detect because they route traffic through consumer IP addresses, often obtained through browser extensions or mobile apps that users install without understanding the data-sharing agreement. These IPs carry no datacenter ASN signatures, pass basic IP reputation checks, and appear geographically consistent. Services like 911.re (seized in 2022) and successors continue to operate residential proxy pools that sell access by the gigabyte. When the ShinyHunters group claimed its second attack against Instructure in 2025, initial access patterns showed source diversity consistent with residential proxy rotation, making velocity-based blocking ineffective against any single IP.
Commercial VPNs present a different problem. Services like Mullvad, ProtonVPN, and NordVPN serve millions of legitimate users including security researchers, privacy-conscious employees, and remote workers. Blocking all commercial VPN exit nodes creates friction for legitimate users, especially in organizations with distributed workforces. The detection challenge is identifying when a VPN is used as an attack enabler versus a privacy tool, which requires behavioral context rather than a blocklist.
Datacenter proxies are the easiest to detect because they originate from cloud and hosting ASNs like AS14061 (DigitalOcean), AS16509 (Amazon AWS), and AS15169 (Google Cloud). Legitimate end users almost never authenticate from these ranges, so blocking or step-up authenticating traffic from datacenter ASNs catches a meaningful percentage of credential stuffing and account takeover attempts with low false positive rates.
Tor exit nodes form a publicly enumerated list that should be blocked or flagged at authentication endpoints for any application handling sensitive data. The Tor Project publishes the exit node list and several threat intelligence feeds maintain it with updates. Traffic from Tor exit nodes to administrative interfaces warrants immediate investigation regardless of whether credentials are valid.
Detection Signals That Actually Work at Scale
Effective proxy detection in production environments combines multiple signal types rather than relying on a single method. Each signal has limitations, and combinations reduce both false positives and false negatives.
ASN and Hosting Provider Classification
The first filter to apply is ASN classification. Map every inbound source IP to its ASN and classify it as residential ISP, mobile carrier, commercial VPN provider, datacenter/hosting, or university/research. This classification informs risk scoring rather than driving binary block decisions.
Traffic from datacenter ASNs hitting authentication endpoints is high-confidence suspicious. Apply mandatory multi-factor authentication challenges or block entirely. Traffic from known commercial VPN ASNs warrants moderate suspicion, which might trigger step-up authentication or session monitoring. Traffic from residential ISPs passes with normal controls unless other signals fire.
Tools for ASN enrichment include MaxMind GeoIP2, IP2Location, and purpose-built threat intelligence APIs that include hosting classification flags. Maintain local caches to avoid per-request latency and refresh them at least daily since ASN assignments shift.
IP Reputation Feeds and Cross-Correlation
Commercial threat intelligence feeds provide scored reputation data for IP addresses based on observed behavior across networks. Sources include Spamhaus, Emerging Threats, AlienVault OTX, and commercial platforms like Recorded Future and Crowdstrike Falcon Intelligence.
The practical challenge with reputation feeds is staleness. An IP used in an attack today may not appear in reputation databases for hours or days. Feeds with higher update frequency cost more but provide meaningful value at authentication checkpoints. Pair reputation feeds with behavioral signals so that clean-reputation IPs from residential proxies still trigger scrutiny when behavioral patterns look wrong.
The Canvas breach that disrupted schools and colleges in 2025 illustrates how access through reputation-clean residential proxies can persist for extended periods without triggering blocklist-based controls. The attacker infrastructure rotated IPs frequently enough to stay below reputation thresholds, but behavioral signals like unusual access times, atypical user-agent strings, and session anomalies were present and went uninvestigated.
Behavioral and Session-Layer Signals
Beyond IP-level signals, session behavior provides detection opportunities that are much harder to spoof at scale.
Mouse movement entropy and browser fingerprinting can distinguish automated credential stuffing from human authentication. Libraries like FingerprintJS (server-side) and custom canvas fingerprinting detect headless browsers and automation frameworks. The fake OpenAI repository attack on Hugging Face that distributed infostealer malware demonstrated how attackers are increasingly using victim machines as proxy endpoints themselves, which makes behavioral device-level signals more valuable because the IP looks entirely legitimate.
TLS fingerprinting, specifically JA3 and JA4+ fingerprints, identifies the TLS client library being used. Automated tools tend to produce consistent JA3 hashes that differ from typical browser fingerprints. A login request with an IP from a residential ISP but a JA3 hash consistent with Python's requests library warrants investigation. JA4+ improves on JA3 by being more stable across TLS library versions and capturing more client characteristics.
Time-zone and language inconsistency detection compares the Accept-Language header, browser time zone reported via JavaScript, and the geolocation of the source IP. A user whose IP geolocates to Seattle but whose browser reports UTC+8 and whose Accept-Language is zh-CN may be routing through a US exit node. This signal is imperfect since VPN users intentionally route through foreign countries, but the combination with other signals raises confidence.
Velocity and Pattern Analysis
Proxy-assisted attacks often show velocity patterns that distinguish them from organic user behavior. Credential stuffing tools cycle through username-password combinations at rates no human matches. Even when distributed across large proxy pools, per-account attempt velocity, per-session failure rates, and cross-account pattern similarities remain detectable.
Implement per-IP, per-account, and per-session failure counters with sliding windows of 5 minutes, 1 hour, and 24 hours. Alert on thresholds appropriate to your application's normal traffic. Authentication attempts showing a failure rate above 40% across more than 10 unique accounts from IPs in the same /24 subnet suggest proxy pool usage even when each individual IP appears clean.
Integrating Detection into the Authentication Pipeline
Detection that produces alerts after the fact has limited operational value. The goal is integrating proxy and VPN detection signals into real-time authentication decisions.
Risk-Based Authentication Architecture
Build a risk scoring function that runs at authentication time and returns a score influencing the authentication flow. The score aggregates signals: ASN classification, IP reputation, behavioral anomalies, session fingerprint, and velocity indicators. Based on the score, route the user to one of three outcomes: allow normally, require step-up authentication (push notification, TOTP, or security key), or block and alert.
This architecture avoids the binary block problem where legitimate VPN users get locked out. A remote worker connecting through ProtonVPN from a known home geography may score a moderate risk that triggers a TOTP challenge rather than an outright block. An authentication attempt from a datacenter IP with a Python JA3 fingerprint and three failed attempts in the past minute scores high risk and gets blocked.
Implement this as middleware in your identity provider or application layer. Modern identity platforms like Okta, Auth0, and Azure AD support custom risk policies through their adaptive authentication features, but the signals they consume must often be enriched externally before the policy evaluates them.
Feeding Signals into Identity Providers
For Okta and similar platforms, use the Inline Hook capability or the ThreatInsight feature to push enriched risk context. For Azure AD (now Entra ID), Conditional Access Policies consume Named Locations and risk signals from Microsoft Defender for Identity and third-party integrations. Configure these to require MFA when the source IP classifies as a hosting ASN or falls within a known commercial VPN range.
For custom applications, implement a lightweight IP intelligence microservice that your authentication controller calls synchronously at login. Keep the service response time under 50ms by maintaining local caches of frequently seen IPs and only making external API calls for uncached addresses. Use circuit breakers so that a failure in the intelligence service fails open with a moderate risk score rather than blocking all authentication.
Session Monitoring After Authentication
Proxy detection at login time addresses initial access but misses session hijacking scenarios where an attacker intercepts a session token and replays it from a proxy. Implement continuous IP affinity checks that flag sessions where the source IP changes significantly during a session lifetime.
Define IP change policies based on application risk. A financial application might invalidate a session any time the ASN changes during the session. A content application might only flag transitions from residential to datacenter ASNs. Log all IP transitions with session metadata for forensic use even when you do not terminate the session.
Handling False Positives Without Alienating Legitimate Users
Over-tuned proxy detection creates support burden and user friction. Privacy-conscious users, security researchers, and workers in countries with restrictive internet access legitimately use VPNs for non-malicious purposes. The tradeoffs are real and deserve explicit policy decisions.
Graduated Response Strategies
Rather than blocking VPN traffic outright, implement graduated responses keyed to the risk level of the resource being accessed. Administrative consoles and sensitive data APIs warrant stricter controls than public-facing content. A user accessing a read-only dashboard through a commercial VPN may face only an MFA challenge. The same user accessing the account deletion endpoint through the same VPN may face a mandatory re-authentication with a hardware key.
Communicate clearly to users when proxy detection has influenced their experience. A message explaining that the login was flagged for unusual network characteristics and asking the user to complete an additional verification step is far less frustrating than an opaque denial. Users who consistently work through VPNs can be offered the ability to register trusted exit nodes or to use a corporate VPN that your controls already trust.
Building an Allowlist Process
Establish a documented process for adding IP ranges to an allowlist for legitimate business purposes. Security researchers, third-party auditors, and partner organizations may connect from IP ranges that would otherwise trigger detection. Require business justification, time-limit the allowlist entry, and log all traffic from allowed ranges with elevated scrutiny rather than treating them as fully trusted.
Review allowlists quarterly. Ranges added for a penetration test or a vendor engagement that has since concluded create unnecessary exposure. Automated expiry on allowlist entries forces periodic review and prevents accumulation of permanently trusted ranges that no longer serve a business purpose.
Proxy Detection in Threat Hunting
Beyond real-time enforcement, proxy and VPN detection signals provide value in retrospective threat hunting. Analysts investigating incidents can correlate access events from known proxy ranges with downstream activity to reconstruct attacker timelines.
After the 0ktapus campaign, teams that had preserved enriched authentication logs were able to identify the initial access points by filtering for authentication events from datacenter ASNs and known proxy providers in the 30 days before the breach was detected. Teams that had only stored raw authentication logs without IP enrichment had to reconstruct ASN context retrospectively, which added days to the investigation timeline.
Enrich your authentication logs at write time, not query time. Add ASN name, ASN number, IP classification (datacenter, residential, VPN, Tor), and reputation score to every authentication event as it is logged. This adds modest storage overhead but eliminates the need to call enrichment services during high-urgency investigation windows when those services may be under load.
Build hunting queries that surface patterns consistent with proxy-assisted attacks: authentication events spanning multiple ASN classifications for the same account in a short window, accounts with high per-session IP diversity, accounts where session IPs never match the user's historical geolocation pattern. These queries run well as scheduled detection rules in your SIEM and as manual hunting starting points during incident response.
Infrastructure and Tooling Recommendations
Operationalizing proxy detection requires infrastructure decisions that balance coverage, cost, and latency.
IP Intelligence Data Sources
For organizations building detection in-house, layer multiple data sources. MaxMind GeoIP2 Enterprise provides ASN and connection type data with reasonable accuracy. IPinfo.io offers carrier and hosting detection with an API that supports high-throughput lookups. Spur.us specializes in VPN and proxy detection and maintains one of the most comprehensive datasets for residential proxy identification, which makes it particularly valuable for authentication fraud prevention.
Commercial platforms like Cloudflare Bot Management, Akamai Bot Manager, and Imperva Advanced Bot Protection bundle many of these signals with their CDN and WAF products. If your application already sits behind one of these platforms, enabling their bot and proxy detection features is often the fastest path to coverage.
Open Source Options
For teams with budget constraints, the combination of free MaxMind GeoLite2 databases, Emerging Threats open ruleset, and Spamhaus DROP and EDROP lists covers a meaningful portion of the threat surface at no cost. The tradeoff is update frequency and completeness compared to commercial feeds. GeoLite2 updates weekly; commercial databases update daily or more frequently. For high-risk applications, the update frequency difference matters.
Build a local enrichment service using these free sources rather than making per-event external API calls. Store the databases locally, refresh them on a schedule, and serve enrichment requests from memory. This approach scales to high authentication volumes without incurring per-lookup costs and avoids latency from external API round trips.
Detection-as-Code and Version Control
Treat proxy detection rules, risk score configurations, and allowlists as code. Version control them in a repository with change history, peer review requirements, and automated testing. When the npm threat landscape evolves and new malicious package distribution patterns emerge using proxy infrastructure, you need the ability to deploy updated detection logic quickly and with confidence that the change will not introduce regressions.
Write unit tests for your risk scoring logic that cover edge cases: IPs exactly on the boundary of score thresholds, IPs that appear in multiple reputation feeds with conflicting scores, and ASNs that reclassify between residential and hosting. Automated tests catch logic errors before they affect production authentication flows.
Regulatory and Privacy Considerations
Collecting and processing IP intelligence data intersects with privacy regulations in several jurisdictions. GDPR treats IP addresses as personal data, which affects how you may store, retain, and use IP enrichment data associated with EU residents. CCPA has analogous implications for California residents.
Ensure your data retention policies for enriched authentication logs are documented and defensible. Most security use cases support retention of 12 to 24 months under legitimate interest grounds, but longer retention requires stronger justification. Do not store raw IP-to-identity mappings longer than operationally necessary, and implement access controls on authentication logs so that only authorized security personnel can query them.
When using third-party IP intelligence services, review their data processing agreements to confirm they meet your compliance requirements. Services that store queried IPs or correlate them across customers may create data sharing implications under your privacy framework.
Building a Sustainable Detection Program
Proxy detection is an ongoing program, not a one-time deployment. Attacker infrastructure evolves, new proxy providers emerge, and residential proxy pools rotate through fresh IP space continuously. Sustainable detection requires regular review cycles.
Conduct quarterly reviews of your detection signal effectiveness. Measure false positive rates by sampling flagged sessions and reviewing whether they represented legitimate user behavior. Measure false negative rates through periodic red team exercises where your own team authenticates through proxy infrastructure and assesses whether detection fires. Track the ratio of proxy-sourced authentication attempts over time to identify trends that may indicate targeting.
Stay current with threat intelligence reporting. The monthly threat intelligence reports published by Check Point and other vendors track infrastructure patterns used in active campaigns. When a report notes increased use of a specific residential proxy network or a new commercial VPN provider popular with threat actors, that is an actionable signal to update your detection configuration.
The attacks on Instructure and the broader pattern of 0ktapus-style campaigns demonstrate that proxy-assisted access is a durable attacker technique. Organizations that build detection depth, integrate signals into real-time decisions, and maintain their detection program operationally will be consistently better positioned than those relying on static blocklists and periodic reviews.
