Blocking residential proxy traffic with stateful firewall rules

AVRecon sat on home routers for years because the default answer to outbound traffic is usually “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 running since summer 2020.

Six years is a long time for anything to sit on a router unnoticed. The reason was simple: most home and small office routers block inbound connections and allow everything outbound. AVRecon used that. Once installed, it ran SOCKS5 relay sessions that looked like ordinary outbound traffic, connecting to unfamiliar autonomous systems in short bursts that blended into streaming, updates, and cloud sync. Residential IP addresses are trusted by fraud-detection systems in ways datacentre IPs are not, which is why SocksEscort existed at all. The infected router’s IP address was the product.

Why the default outbound posture is the problem

The common mistake across infected devices was not a firewall bypass. It was no outbound filtering at all. A deny-by-default inbound rule with a permit-all outbound rule is not much of a firewall policy. It is a one-way door. AVRecon did not need an inbound exploit to stay active; it only needed the compromised router to start connections to its command-and-control infrastructure, which the firewall allowed.

Stateful connection tracking records the state of each session: SYN, established, FIN. A stateful firewall can tell the difference between a session your device started and one started on its behalf by a process you did not authorise. That only helps if the outbound ACL is not 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 allow only the ports and protocols your devices actually use and drop 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 vanish 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 built around service-specific port ranges and destination CIDRs removes the space those relay sessions need. 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 like this. 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 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, 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 lateral traffic and only permits specific services you have opened. The same 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 common factor across infected devices in the SocksEscort investigation. Segmentation does not stop the initial compromise of a device, but it does stop that device becoming a useful relay node, which is where 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 build 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 deserves a look.

Set a threshold alert. Graylog, Grafana Loki, or even a cron job running awk against your syslog file will do it. The exact tool matters less 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 used regular keepalive traffic to maintain the SOCKS5 relay state. That leaves a familiar 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 hold a permanent 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 already had updates available and were never updated. 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.

Apply the outbound ACL, segment the network, enable connection logging, and baseline normal traffic. None of these steps are complicated. AVRecon persisted for six years because there was no outbound policy at all.