Residential Proxy Detection: What the White House Case Shows

Residential proxy detection moved from a niche bot-management topic to front-page news this week. A security firm reported that 28 residential proxy services were exiting through White House network addresses. The Hacker News thread passed 1,200 points within a day. Most developers will never run a government network. But the same technique hits your login form, your pricing pages and your API every day. This post covers what was actually reported, why IP blocklists fail against it, and how I would build detection that holds up.

What did researchers find on the White House network?

Layer3 Intel reported that 28 distinct residential proxy services exited through White House network addresses nearly every day between October 5 and November 3, 2026. The Register counted 236 separate exits in that window.

Layer3 found this by buying access to proxy services and logging the exit IPs its own requests produced. It says it did not target the White House. Per the reporting, the exits clustered between 5 pm and midnight.

The caveats matter. The data shows exits, not the device or person behind them. Nothing public shows that proxy customers reached internal systems. Security firm Synthient suggested Windows machines running the Infatica SDK, but Layer3 says its data cannot confirm how many devices are involved. I would treat the story as a case study, not as a verdict.

The reported activity stopped after the blog post went public. That timing is itself a lesson. The owner of a network is the only party who can find the device, using DHCP, NAT and endpoint logs.

Why does residential proxy detection fail with IP blocklists?

IP blocklists fail because residential proxy addresses rotate faster than any feed can update. In GreyNoise’s 90-day analysis, 78% of residential IPs appeared at most twice. The median IP produced a single session.

That median is the unique insight here. A classic per-IP rate limit of 100 requests per minute never fires when each IP sends one request. Attackers spread 10,000 requests across 10,000 addresses. Every address looks clean.

GreyNoise also reported that residential IPs made up 39% of unique attacking IPs but only 22% of sessions. In other words, there are many addresses and few requests per address. That is exactly the pattern a rotating pool produces.

Why takedowns do not solve it

Google disrupted the IPIDEA network in January 2026. It had 9 to 11 million daily active proxies. The same report says these networks tend to regenerate after a takedown. The US Justice Department earlier dismantled 911 S5, which had 19 million IPs across 190 countries.

My rule is simple. I treat an IP reputation score as one weak input, never as a decision.

How do residential proxies end up on home and office devices?

Most residential proxy nodes are ordinary devices running an app or SDK that sells their bandwidth, often without informed consent. Hacker News commenters named cheap streaming boxes, free VPN apps and SDKs bundled into TV or Windows apps. GreyNoise separately traced exits to SMB worm infections and to IoT devices with default Telnet credentials.

The owner usually sees nothing wrong. The device works. It just forwards traffic for strangers, often in the evening when the owner is online.

This matters for the defender in two ways. First, your legitimate users can be proxy exits without knowing it. A blanket block punishes them. Second, your own office or cloud network can be an exit. The White House report shows how easily that goes unnoticed.

The FBI warned in March 2026 that residential proxies are widely used to hide command-and-control traffic and to run phishing and spam. See my notes on a related supply-chain style flaw in the APT package-swap CVE for how small client-side weaknesses become infrastructure.

How do you build residential proxy detection that works?

Build detection as a score from several independent signals, then pick an action by score. No single signal is reliable. Agreement between signals is. Here is the approach I use.

1. Log a stable client fingerprint per request: TLS fingerprint, HTTP header order and user-agent consistency.
2. Aggregate by account, path and fingerprint instead of by IP, so rotation does not reset your counters.
3. Add a proxy-intelligence lookup as a weak signal, with a short cache lifetime.
4. Weight sensitive paths higher: login, signup, checkout, password reset and search endpoints.
5. Map the total score to allow, log, challenge or block, and record the evidence with each decision.

Here is a minimal PHP version of the scoring step.

<?php
function proxy_risk(array $s): int {
    $score = 0;
    if ($s['ip_is_proxy_listed'])      $score += 2; // weak, rotates fast
    if ($s['tls_ua_mismatch'])         $score += 3; // claims Chrome, TLS says curl
    if ($s['fp_requests_5min'] > 60)   $score += 3; // per fingerprint, not per IP
    if ($s['new_account_burst'])       $score += 2;
    if ($s['sensitive_path'])          $score += 1;
    return $score;
}

$risk = proxy_risk($signals);
$action = match (true) {
    $risk >= 8 => 'block',
    $risk >= 5 => 'challenge',
    $risk >= 3 => 'log',
    default    => 'allow',
};

Tune the thresholds on your own traffic for a week in log-only mode. Never ship a block rule you have not replayed against real logs.

Can you block residential proxies without hurting real users?

You can block them safely only when several independent signals agree and the path is sensitive. Peakhour’s guidance warns that residential proxies share address space with real households and mobile subscribers. Blanket IP blocks therefore deny service to innocent people.

Use a tiered response instead. Block on strong evidence for credential stuffing or refund fraud. Challenge or throttle when the signal is uncertain. Log when the path is low risk. Treat carrier-grade NAT and mobile ranges as shared by default.

Make every block temporary and scoped to a path or time window. Permanent IP denials rot quickly, because the same address may belong to a different household tomorrow.

This is also where a hardened stack helps. If you run PHP, review your session handling and rate limits together, as I covered in the Linux kernel TCP flaw write-up for the network layer view.

How do you check whether your own network is a residential proxy exit?

Check your own egress traffic for unexpected outbound connections, especially large overnight transfers from TVs, IoT devices and unmanaged Windows machines. One Hacker News commenter used per-device bandwidth monitoring and found surprising flows. That is a practical start.

1. Look up your public IP in a proxy-intelligence service such as Spur or IPinfo.
2. Segment IoT and guest devices onto a separate VLAN with no route to internal hosts.
3. Audit installed software for bandwidth-sharing SDKs and free VPN apps.
4. Alert on new long-lived outbound tunnels from endpoints that normally make short requests.

I would run this check on any office network this month. The cost is an hour. The White House case shows the cost of not looking.

Residential proxy detection approaches compared

Approaches to residential proxy detection compared

Option	Performance	Complexity	When to Use
IP blocklist only	Weak: 78% of residential IPs appear at most twice	Low	Never as the only control
Per-IP rate limit	Weak: median residential IP sends 1 session	Low	Basic abuse from single hosts
Per-fingerprint and per-account limits	Strong: survives IP rotation	Medium	Login, signup, search and API
Multi-signal score with tiered actions	Strongest: fewer false blocks	High	Fraud-prone and revenue paths

Key takeaways

• Layer3 Intel reported 236 residential proxy exits through White House network addresses between October 5 and November 3, 2026, across 28 proxy services.
• GreyNoise found 78% of residential attacking IPs appear at most twice, and the median residential IP produces one session.
• Residential IPs were 39% of unique attacking IPs but only 22% of sessions in GreyNoise’s 90-day sample.
• Only 0.1% of residential sessions carried exploitation payloads, versus 1.0% from hosting infrastructure, so most residential traffic is reconnaissance.
• Per-IP rate limits fail against rotating pools, so counters should key on fingerprint, account and path.
• Proxy exit data shows the exit address, not the device behind it, so only the network owner can identify the infected machine.

Frequently Asked Questions

What is a residential proxy?

A residential proxy routes traffic through an IP address assigned to a real home or office internet connection. Websites see an ordinary subscriber instead of a datacenter. That makes the traffic harder to block, which is why scrapers, fraudsters and attackers pay for it.

Are residential proxies legal?

The technology itself is legal and has legitimate uses, such as price research and ad verification. The problem is sourcing. Services that route traffic through devices without informed consent, or through malware, are illegal in many places. US authorities have prosecuted operators of networks such as 911 S5.

How do you detect residential proxies?

Combine several signals: proxy-intelligence lookups, TLS and header fingerprints, request cadence, session history and path sensitivity. No single signal is reliable because addresses rotate quickly. Act on the combined score, and prefer challenges over permanent blocks when the evidence is mixed.

Can you block residential proxies?

You can block some of them, but blanket IP blocks hurt real households that share the same address space. Block only when multiple independent signals agree and the path is sensitive. Otherwise challenge, throttle or log, and keep every decision temporary and scoped.

How do residential proxies get onto devices?

Most arrive through apps or SDKs that sell bandwidth, such as free VPNs, streaming boxes and bundled Windows or TV software. Others come from malware, SMB worms and IoT devices with default credentials. Owners often notice nothing because the device keeps working.

What should you do about residential proxy detection now?

The White House story is a headline, but the engineering lesson is ordinary. Attackers rent clean-looking addresses by the million, and a feed of bad IPs cannot keep up. Residential proxy detection that survives is built on behavior, fingerprints and path risk, with tiered responses that protect real users. Start by logging the signals this week. Then audit your own egress before someone else does it for you. If you run a PHP or Node stack, I will cover rate-limit middleware in a follow-up.