Blocking Residential Proxy Traffic with Stateful Firewall Rules for Reliable Residential Proxy Detection

AVRecon ran undetected on home routers for years because the default answer to outbound traffic is “allow.” The malware, written in C and compiled for MIPS and ARM architectures, targeted roughly 1,200 device models from Cisco, D-Link, Hikvision, MikroTik, Netgear, TP-Link, and Zyxel. SocksEscort sold access to those compromised devices as residential proxies, eventually accumulating 369,000 IP addresses across 163 countries. The FBI and Europol dismantled the network in March 2026 under Operation Lightning, seizing domains, servers, and $3.5 million in cryptocurrency. The network had been operating since summer 2020.

Six years is a long time for something to sit on your router unnoticed. The reason it persisted is not complicated: most home and small office routers ship with a firewall that blocks inbound connections and approves everything outbound. AVRecon exploited that entirely. Once installed, it ran SOCKS5 relay sessions that looked like ordinary outbound traffic, connecting to unfamiliar autonomous systems in short bursts that blended into background noise from streaming, updates, and cloud sync. Residential IP addresses are trusted by fraud-detection systems in ways that datacenter IPs are not, which is the commercial reason SocksEscort existed. The infected router’s IP address was the product.

Why the default outbound posture is the actual problem

The common configuration failure across infected devices was not a firewall bypass. It was the absence of any outbound filtering at all. A deny-by-default inbound rule with a permit-all outbound rule is not a firewall policy; it is a one-sided door. AVRecon needed no inbound exploit to stay active; it only needed the compromised router to initiate connections outbound to its command-and-control infrastructure, which the firewall politely allowed.

Stateful connection tracking records the state of each session: SYN, established, FIN. A stateful firewall can distinguish a session your device initiated from one that was initiated on its behalf by a process you did not authorise. What it cannot do is make that distinction useful if your outbound ACL rule is permit ip any any. The stateful engine tracks the session; the ACL decides whether it should have started.

Writing ACL rules that block proxy enrolment without breaking legitimate traffic

Start with a named outbound ACL applied to the WAN-facing interface in the egress direction. The goal is to permit only the ports and protocols your devices actually use and deny everything else.

A minimal permit list for a home network looks like this:

TCP 80, 443 (HTTP/HTTPS)
UDP 53 (DNS, locked to your resolver, not any destination)
UDP 123 (NTP)
TCP 587, 993 (mail submission and IMAP over TLS, only if needed)
TCP 22 (SSH, destination-restricted if you manage remote hosts)

Everything not in that list gets an explicit deny ip any any log. The log keyword matters. Without it, dropped packets disappear silently and you have no signal for compromised device detection.

SOCKS5 relays operate over TCP and can run on almost any port, but SocksEscort traffic was observed using non-standard high ports to avoid obvious detection. An outbound permit list structured around service-specific port ranges and destination CIDRs eliminates the space those relay sessions need to operate. They cannot enrol a new proxy node if the outbound TCP connection to the enrolment server is dropped at the ACL.

For router-level implementation: OpenWrt supports nftables and iptables. A deny-by-default outbound chain on the wan interface in OpenWrt’s firewall.d configuration works as follows. Set the forward policy to DROP on the wan zone, then define explicit rules for each permitted service. On pfSense or OPNsense, create a floating outbound rule set with deny as the final catch-all and log the matches to syslog.

Network segmentation to contain a compromised device

A flat home network means a compromised router or IoT device can relay traffic freely because everything shares the same broadcast domain and the same default gateway. Put IoT devices, smart home kit, and anything with a consumer firmware on a separate VLAN with its own firewall policy. Inter-VLAN routing should be denied by default; the IoT VLAN needs internet access on specific ports and nothing else.

In a homelab context, the segmentation boundary sits between the lab VLAN and the primary LAN. A compromised device in the lab VLAN cannot pivot to the primary network if the inter-VLAN ACL denies all lateral traffic and only permits specific services you have explicitly opened. The same principle applies to guest Wi-Fi: isolate it, deny inter-VLAN routing, restrict outbound to TCP 443 and UDP 53 only.

The Shadowserver Foundation and the FBI’s IC3 both identified flat network configurations as a consistent factor across infected devices in the SocksEscort investigation. Segmentation does not prevent the initial compromise of a device, but it does prevent that device from becoming a useful relay node, which is the point at which it has commercial value to a proxy operator.

Detecting relay activity through traffic baselining and log analysis

Residential proxy detection at the router level depends on knowing what normal looks like. Pull 30 days of outbound connection logs and establish a baseline: number of unique destination autonomous systems per device, connection frequency, session duration, and bytes transferred per session. A typical home device connects to a handful of ASNs repeatedly. A relay node connects to dozens of unfamiliar ASNs in short, high-frequency bursts.

In practice, enable conntrack logging on OpenWrt or enable the traffic graph and syslog forwarding on pfSense. Forward logs to a local syslog instance (rsyslog or syslog-ng) and query them. A simple approach: count distinct destination /24 prefixes per source MAC address over a 24-hour window. A device that contacted 80 distinct /24 prefixes overnight when it normally contacts 12 warrants inspection.

Set a threshold alert. Graylog, Grafana Loki, or even a cron job running awk against your syslog file will do it. The exact tool is less relevant than actually running the query. Most routers log nothing by default and most people never change that.

Check for persistent low-volume connections to the same external IP on a non-standard port. AVRecon’s C2 communication pattern involved regular keepalive traffic to maintain the SOCKS5 relay state. That produces a characteristic signature in connection logs: a recurring established session to the same destination, every few minutes, around the clock, from a device that should have no reason to maintain a persistent external connection.

The configuration changes that close the door

Patch the firmware. SocksEscort relied on known unpatched vulnerabilities across 1,200 device models; a significant number of infected devices were running firmware that had available updates which were never applied. Enable automatic firmware updates if the device supports them, or set a calendar reminder to check quarterly.

Disable remote management interfaces on the WAN side. UPnP should be off. Any service that listens on the WAN interface and is not explicitly required should be disabled. Check what ports your router is advertising with a port scan from an external host, or use your ISP’s tool if one is available.