Is Your Network a Residential Proxy Exit? How to Check

Layer3 Intel runs a measurement project it calls the Residential Proxy Observatory. It subscribes to public residential proxy services as an ordinary customer, asks for globally rotating exits, and records the address every request leaves from. Between October 5 and November 3, 2026, its probes exited through AS2650, the autonomous system registered to the Executive Office of the President, 236 times. That happened on 26 of the 30 days, through six public addresses, and 28 different proxy brands could route traffic there.

Nobody targeted the White House. The exits turned up in routine rotating traffic, the same traffic anyone can buy for a few dollars. Spur and Synthient, two other proxy-intelligence firms, independently flagged the same addresses.

What the data does not show matters just as much. In Layer3's words, "Our data shows the exits, not the device or the person behind them." Synthient said it had traced some of the activity to Windows 11 machines running the Infatica SDK, without publishing how. Other coverage pointed at a streaming app said to bundle 12 proxy SDKs. Neither attribution has been confirmed, and Layer3's founder later said the activity had stopped. The White House did not comment.

The lesson for everyone else is simple: an office network with a security team was an exit for a month, and outsiders noticed before insiders did.

Residential proxy networks need real consumer and office IP addresses, and the cheapest way to get them is software running on other people's devices. The proxy SDK is a library that an app developer embeds in exchange for payment per active user. The app might be a free VPN, a streaming app, a screensaver, a "productivity" utility or the firmware on a cheap TV box. Infoblox's June 2026 research lists exactly those entry points.

The mechanics explain why your firewall never complained:

1. The SDK opens an outbound TLS connection to the proxy operator's gateway. No inbound port is opened, so perimeter scans and firewall rules that block inbound traffic see nothing unusual.
2. A paying customer sends a request to the operator. The operator pushes it down that tunnel to the device.
3. The device fetches the target site itself. Your NAT rewrites the source address to your public IP, so the target sees your office.

One laptop is enough. Every device behind the same NAT shares the public address, so the reputation damage lands on everyone. If the SDK is poorly built, the risk goes further: researchers covering the AS2650 case warned that a flawed SDK can let proxy buyers reach other devices on the local network. For background on exits in general, see what an exit node is in a proxy network. For the supply side, see where residential proxy IPs come from.

This is not rare. Infoblox, working with Synthient, analysed billions of DNS resolutions and found that more than 65% of its enterprise customers queried domains used to run residential proxy networks during 2026. Every industry it examined was at 40% or higher.

You usually find out sideways, from users complaining about things that look unrelated. These are the signals worth taking seriously:

If "proxy detected" errors are your entry point, our guide on the anonymous proxy detected error covers the user-facing side. The steps below cover the network side.

Start from the outside, because that's what the rest of the internet sees. First, list every public address your traffic can leave from: each office, each ISP link, each guest network and VPN concentrator. Run this from a machine behind each one:

# Two independent answers; they should match
curl -s https://api.ipify.org; echo
dig +short myip.opendns.com @resolver1.opendns.com

Then check each address against the people who actually measure proxy exits. Layer3, Spur and Synthient all have public lookup pages; paste the address in and read the verdict. For anything repeatable, use an IP-intelligence API. This example uses Ipregistry's documented security object and prints every flag that is set to true:

IP=203.0.113.24          # replace with your egress IP
KEY=your_api_key
curl -s "https://api.ipregistry.co/${IP}?key=${KEY}&fields=security" \
  | jq -r '.security | to_entries[] | select(.value == true) | .key'

Empty output means no flags are set right now. Any of is_proxy, is_anonymous, is_vpn or is_relay on an office address you don't run as a VPN deserves a closer look. Some vendors also expose a dedicated residential-proxy flag; Ipregistry's own write-up on the AS2650 case refers to one.

Read the result as a dated sighting, not a verdict. Proxy flags come from observed exits plus inference. On an office NAT address they can appear and disappear within hours. Ipregistry scanned all 256 addresses in the White House /24 on November 5, the day after the news broke, and found no proxy flags set: by then the sightings had aged out. One clean lookup proves little. Track it over time:

# egress_watch.py: log proxy flags for your egress IPs every hour
import json, time, datetime, urllib.request

KEY = "your_api_key"
EGRESS = ["203.0.113.24", "198.51.100.7"]          # your public IPs
WATCH = {"is_proxy", "is_anonymous", "is_vpn", "is_relay", "is_residential_proxy"}

def flags(ip):
    url = f"https://api.ipregistry.co/{ip}?key={KEY}&fields=security"
    with urllib.request.urlopen(url, timeout=15) as r:
        sec = json.load(r).get("security", {})
    return sorted(k for k, v in sec.items() if v is True and k in WATCH)

while True:
    now = datetime.datetime.now().isoformat(timespec="minutes")
    for ip in EGRESS:
        try:
            hit = flags(ip)
        except Exception as e:
            hit = [f"lookup-error:{e.__class__.__name__}"]
        print(json.dumps({"ts": now, "ip": ip, "flags": hit}), flush=True)
    time.sleep(3600)

Run it for a week and redirect the output to a file. The timestamps matter for Step 4.

The SDK has to find its gateway, and that almost always starts with a DNS lookup. This is where Infoblox's 65% number came from, and it's the cheapest internal check you have. You need two things: DNS query logs with client IPs, and a current list of domains used by proxy SDKs. Get the list from a threat-intelligence feed or your protective-DNS vendor rather than a blog post, because operators rotate domains. Save it one domain per line as proxy-sdk-domains.txt.

If you run Zeek on a span port or tap:

# Which internal clients resolved a known proxy SDK domain, and how often
zeek-cut ts id.orig_h query < dns.log \
  | grep -F -f proxy-sdk-domains.txt \
  | awk '{print $2, $3}' | sort | uniq -c | sort -rn | head -20

If your DNS goes through Pi-hole, its long-term database already holds what you need:

sudo sqlite3 /etc/pihole/pihole-FTL.db \
  "SELECT datetime(timestamp,'unixepoch','localtime'), client, domain
     FROM queries WHERE timestamp > strftime('%s','now','-7 days')" \
  | grep -F -f proxy-sdk-domains.txt | sort | uniq -c | sort -rn | head -20

On a single Windows machine you suspect, the resolver cache is a quick look without any infrastructure:

$list = Get-Content .\proxy-sdk-domains.txt
Get-DnsClientCache | Where-Object { $e = $_.Entry; $list | Where-Object { $e -like "*$_" } } |
  Select-Object Entry, Data

A hit tells you which internal IP to look at. No hit is weaker evidence than it looks: an SDK can use DNS over HTTPS, a hardcoded IP, or a domain your list doesn't have yet. That's why Step 3 looks at connections rather than names.

Normal browsing opens and closes HTTPS connections constantly. A proxy SDK holds one open for hours, because the gateway needs a standing path to push requests down. That makes "outbound TLS connection older than an hour, owned by an app that has no business holding one" a useful filter.

On Windows, Get-NetTCPConnection records when each connection was created:

$cut = (Get-Date).AddHours(-1)
Get-NetTCPConnection -State Established -RemotePort 443 |
  Where-Object { $_.CreationTime -lt $cut } |
  Group-Object OwningProcess | ForEach-Object {
    $p = Get-Process -Id $_.Name -ErrorAction SilentlyContinue
    [pscustomobject]@{ Process = $p.ProcessName; Path = $p.Path; Conns = $_.Count;
                       Remote = ($_.Group.RemoteAddress | Select-Object -Unique) -join ', ' }
  } | Sort-Object Conns -Descending | Format-Table -AutoSize

Expect some legitimate long-lived connections: chat clients, sync tools, endpoint security agents, push services. What you're looking for is the odd one out, such as a free VPN, a media app or a utility nobody remembers installing, holding a connection to an address that isn't its own vendor. When we ran the snippet on one of our own Windows Server build machines, it returned three processes: two developer tools and a remote-desktop client. All three were expected, and that's the normal result. You're reading the list for the entry you can't explain.

On Linux, ss doesn't show connection age, so take two snapshots and keep what survived:

snap() { ss -tnpH state established '( dport = :443 )' | awk '{print $4, $5, $6}' | sort; }
snap > /tmp/a; sleep 1800; snap > /tmp/b
comm -12 /tmp/a /tmp/b     # connections alive for the whole 30 minutes

For a whole network, your firewall or NetFlow data answers the same question at scale: sort flows by duration, filter to TCP 443 outbound, and look at the internal clients with the longest single sessions. Pair that with the DNS hits from Step 2 and you usually have one or two candidate machines.

Layer3's data had a detail that's easy to skip: about half of the White House exits happened between 5 p.m. and midnight Eastern, with almost none in the early morning. That pattern is why Layer3 suspected one person's device rather than an always-on server or the guest Wi-Fi.

You can use the same reasoning on your own sightings from Step 1 and your flow data from Step 3:

Timing won't name the machine, but it rules out whole classes of hardware and tells you whose desk to walk to first.

Not every exit comes from an app someone chose to install. Synthient tied the Kimwolf botnet to at least two million devices, mostly Android hardware with the Android Debug Bridge (ADB) left reachable on the network. Cheap Android TV boxes and digital signage are common offenders, because ADB over TCP is sometimes enabled out of the box.

Scan your own ranges for it:

# Only scan networks you own or are authorised to test
nmap -Pn -p 5555 --open 10.0.0.0/24 -oG - | awk '/5555\/open/{print $2}'

Anything that answers on 5555 should be identified and either have network debugging disabled or be moved to an isolated VLAN with no route to the rest of the office. Better still, replace it. A box shipped with ADB open is a box you can't trust.

Once you've found the device:

1. Uninstall the app that carries the SDK. If you can't tell which app it is, reimage the machine. Removing one binary can leave a second app with the same SDK behind.
2. Block the operator domains at your resolver or protective-DNS service, using the same feed you hunted with. Infoblox recommends protective DNS as one layer of a multipronged response, and it stops the SDK from reaching its gateway again.
3. Restrict outbound DNS and DoH so clients must use your resolvers. Otherwise a smarter SDK simply routes around step 2.
4. Tighten app installs on managed devices with an allow-list. Free VPNs and "bandwidth sharing" apps are the usual culprits.
5. Keep Step 1 running. Your IP reputation will recover as sightings age out, and the egress monitor tells you if it comes back.

One mistake to avoid is fixing the symptom at the wrong layer. Asking an IP-intelligence vendor to delist your address while the device is still active just restarts the cycle.

If your company buys residential proxy traffic for scraping, ad verification or testing, the AS2650 story is a supply-chain question too. The 28 services that routed through the White House were ordinary commercial brands. Their customers had no way of knowing whose network they were exiting from.

Before you buy, ask the provider how its IPs are sourced, whether every peer opts in knowingly, which SDKs or apps supply the pool, and whether it excludes government, corporate and education networks. If the answers are vague, treat that as the answer. Many jobs don't need residential IPs at all: validating IP geolocation and fraud scores is a good way to test what a target actually checks before paying for a residential pool. When a datacenter IP passes, use it: you know exactly whose network your traffic leaves from.