When Home Isn't Safe: Detecting Malicious Networks Hidden Behind Residential Proxies

When Home Isn't Safe: Detecting Malicious Networks Hidden Behind Residential Proxies

Speakers: Unknown (SaaS operator and software engineer)

Conference: BSides Seattle 2026

YouTube: https://www.youtube.com/watch?v=HBntpbam0SQ

Overview

A software engineer who runs a small SaaS company delivered a practitioner-focused talk on the challenge of detecting malicious traffic originating from residential proxy networks. The talk was motivated by firsthand experience: the speaker discovered a threat actor performing credit card shuffling against his subscription service, using the same email across dozens of stolen credit cards but routing traffic through residential IPs to avoid detection.

Residential proxies have grown significantly since approximately 2014 and represent one of the hardest detection challenges in web security. Unlike datacenter IPs or well-known VPN endpoints, residential proxy traffic originates from legitimate home IP addresses, making it nearly indistinguishable from normal user traffic at the network layer. The speaker walked through multiple detection approaches — TTL analysis, reverse DNS fingerprinting, JA3/JA4+ TLS fingerprinting, TCP SYN packet analysis, and eBPF-based kernel-level packet inspection — while honestly acknowledging that none provide definitive detection on their own.

This talk stands out for its raw, experience-driven honesty about the limitations of each technique. The speaker is actively researching eBPF-based detection and admitted to bricking his own routing table during demo preparation, preventing a full live demonstration.

Background

▶ Watch: Credit card shuffling attack via residential proxies (0:00)

Residential proxy networks operate by routing traffic through real residential IP addresses, making the traffic appear to originate from legitimate home internet connections. These networks source their IPs primarily through free VPN applications and bandwidth-sharing programs that offer users incentives (sometimes cryptocurrency) in exchange for allowing their internet connection to be used as an exit node. Some residential proxy IPs may also come from compromised IoT devices and hacked systems, though the speaker assessed that incentivized sharing programs are far more prevalent than direct hacking.

The residential proxy market has exploded, with companies claiming millions of available IPs. A simple Google search reveals numerous commercial services offering residential proxy subscriptions for any purpose. The core problem is lack of transparency: these companies do not disclose their exit nodes or how they acquire IP addresses.

For attackers, residential proxies solve a fundamental problem. Datacenter IPs and well-known VPN exit nodes are easily flagged by web application firewalls and bot detection systems. Residential IPs bypass these controls because the server cannot easily distinguish between a legitimate user on their home network and an attacker routing through that same network. The speaker's direct experience with credit card shuffling attacks against his SaaS platform motivated the research.

Key Findings

▶ Watch: TTL analysis for anomalous routing path detection (4:00)

The speaker evaluated five detection approaches, each with significant limitations:

TTL (Time to Live) Analysis: Different operating systems use different starting TTLs (64 for Linux, 128 for Windows, etc.). By observing the TTL of incoming packets and comparing against expected hop counts for a given geographic region, anomalous routing paths can be detected. For example, a packet arriving with TTL 52 likely started at 64 with 12 hops. A stateful baseline of normal TTL values per IP or region can flag deviations. However, BGP and ECMP load balancing cause path variability, and mobile networks have unpredictable hop patterns, severely limiting reliability.

Reverse DNS (RDNS) Fingerprinting: Checking whether incoming IPs have reverse DNS records consistent with residential ISPs can identify some proxies. However, this is a weak signal because residential proxies are specifically designed to bypass this check, and attackers often mix residential proxies with VPNs, making the fingerprint inconsistent.

JA3/JA4+ TLS Fingerprinting: JA3 generates an MD5 hash of the TLS ClientHello parameters, identifying what kind of TLS client is connecting. Bots, proxies, and tools like curl, Python, and headless browsers produce distinctive JA3 fingerprints. JA4+ extends this across multiple network layers (layer 3 through layer 7), making it harder for proxies to spoof because spoofing would require kernel-level modifications. Research cited showed JA4+ TCP-based detection is approximately 60% effective at identifying residential proxy traffic.

TCP SYN Packet Analysis (JA4T): The SYN packet is the only moment where the client reveals its true TCP configuration. Analyzing the MSS (Maximum Segment Size), window scale, and TCP option ordering can reveal proxy encapsulation overhead. Normal MSS is approximately 1460 bytes; proxy/VPN traffic typically shows MSS of 1380-1400 bytes due to encapsulation reducing effective MTU. TCP option ordering is not standardized and is difficult to fake without kernel-level changes.

eBPF-Based Inspection: Since JA4 and TLS fingerprints rely on TCP/IP packet fields not visible at the application layer (Node.js, Nginx), kernel-level packet inspection is required. eBPF (extended Berkeley Packet Filter) allows safe, high-performance programs to run in the kernel, hooking into packet processing before HTTP handling. This enables real-time analysis of SYN packets, TTL, MSS, and TCP options without kernel module modifications.

Technical Deep Dive

▶ Watch: JA4+ multi-layer fingerprinting across OSI layers 3-7 (8:00)

The most technically substantial portion of the talk focused on JA4+ fingerprinting and the MSS analysis technique. The JA4T fingerprint specifically targets the TCP SYN packet because it is the only point in the connection where the client must reveal its true TCP stack configuration. The IP header (20 bytes) and TCP header (20-60 bytes including options) contain MSS, window scale, SACK, and timestamps that form a fingerprint.

The key insight is that proxies and VPNs introduce encapsulation overhead that reduces the effective MTU, which in turn reduces the MSS. The equation is: observed MSS = path MTU - encapsulation overhead. Normal direct connections show MSS around 1460 (standard 1500 MTU minus headers), while proxied connections consistently show 1380-1400 due to the additional encapsulation layer. This 60-80 byte delta is a reliable indicator, though not conclusive proof.

eBPF is positioned as the enabling technology for implementing these detection techniques at scale. Unlike kernel modules, eBPF programs run in a sandboxed environment within the kernel, providing access to raw packet data before HTTP processing while maintaining system stability. The speaker noted this is an active area of his research and that he doesn't fully understand eBPF's capabilities yet, demonstrating intellectual honesty that lent credibility to the talk.

The speaker's practical approach to mitigation was pragmatic: rather than trying to block residential proxies definitively, the goal is to increase the cost for attackers. He cited DuckDuckGo's approach of returning HTTP 202 (Accepted, processing) responses that force bots to wait and re-request, making automated scraping more expensive. He also noted that CAPTCHAs are increasingly ineffective since Google Gemini can solve them easily, but they still add friction and cost.

Demo / Proof of Concept

▶ Watch: MSS analysis: 1460 vs 1380-1400 byte proxy signature (10:00)

The speaker attempted to prepare a live demo showing how installing a VPN allows the provider to use the host machine as an exit node. He showed redacted terminal output demonstrating that curling through his VPN returned the VPN's IP address, and that another machine could route through the first machine's connection. However, the full demo was curtailed because the speaker accidentally linked a critical IP address from his infrastructure to his VPN during preparation, which compromised his routing table and prevented his system from connecting to the general internet. He showed his SaaS /24 public IP block colocated in a Chicago data center, used as his research infrastructure. The routing table corruption required manual route additions for each destination, which he showed as evidence of the demo preparation mishap.

Defensive Implications

▶ Watch: Session-level mitigation vs IP blocking tradeoffs (16:00)

The core defensive message is that no single detection method reliably identifies residential proxy traffic. Effective detection requires a multi-layer approach combining TTL analysis, JA3/JA4+ fingerprinting, MSS analysis, and behavioral signals. Each technique should contribute to a scoring system where violations incrementally increase suspicion rather than triggering binary blocks.

The speaker recommended session-level mitigation rather than IP-level blocking to avoid collateral damage to legitimate users sharing an IP with a compromised or proxied device. Terminating suspicious sessions rather than blocking IPs is more surgical and less likely to affect innocent users.

For organizations running web services, the goal should be to increase attacker costs rather than achieve perfect detection. Rate limiting, delayed responses (HTTP 202 patterns), and multi-layer fingerprinting all add friction that makes automated abuse more expensive without significantly impacting legitimate users.

Human intuition remains essential. The speaker argued from experience that while AI can assist with anomaly detection, human judgment in reviewing logs and patterns is still superior for making final determinations about whether traffic is malicious.

Key Takeaways

• Residential proxy networks route malicious traffic through legitimate home IPs, bypassing datacenter and VPN detection heuristics
• No single detection method is reliable: TTL analysis, RDNS, JA3/JA4+, and MSS analysis each capture approximately 60% or less of proxy traffic
• JA4+ TCP fingerprinting is the most promising approach, analyzing SYN packet MSS (1380-1400 bytes vs normal 1460) and TCP options that require kernel-level changes to spoof
• eBPF enables kernel-level packet inspection without modifying kernel modules, providing access to raw TCP/IP fields invisible at the application layer
• Session-level mitigation (not IP blocking) prevents collateral damage to legitimate users behind the same residential IP
• Increasing attacker costs through friction (delayed responses, CAPTCHAs, multi-layer fingerprinting) is more practical than achieving perfect detection

About the Speaker(s)

The speaker is a software engineer who runs a small SaaS company and operates networking research infrastructure including a /24 public IP block colocated in a Chicago data center. His interest in residential proxy detection stems from direct experience defending his own services against credit card shuffling and bot attacks. He described himself as primarily a software engineer who got deeper into networking through practical necessity, and is actively researching eBPF-based detection approaches. His name was not clearly stated in the transcript.