- Layer3 Intel says its own proxy test traffic exited through six White House network addresses 236 times in 30 days, across 28 proxy services.
- Layer3 infers from timing alone that a device on that network may carry a proxy SDK. It has not identified any device or person, and it reported no compromise.
- Check which of your rules trust an address alone, what leaves your network, and which apps on devices that join it bundle proxy code.
An address is a claim, not an identity
In our view, many security rules still lean on a quiet assumption: traffic from a familiar address comes from a familiar organisation. A finding from Layer3 Intel tests that assumption. The lesson here is that an address is a claim. It is not proof of who is behind a connection.
Layer3 is a New York-based firm that detects residential proxies, according to Infosecurity Magazine. It says its own test traffic left the internet from White House network addresses. It says anyone could have done the same by paying a few dollars to a public proxy service. These are Layer3's findings. Layer3 reported no compromise of White House systems.
What Layer3 measured
Layer3 spotted the activity in a block of internet addresses called AS2650. The Executive Office of the President is the registered holder of that block. Layer3 noticed it while exploring its new Residential Proxy Observatory, launched earlier that week.
Layer3 says its own probes came out of those addresses on 236 occasions. Six addresses were involved, active on 26 of 30 days. Infosecurity Magazine reports that the window ran from October 5 to November 3. Layer3 counts 28 different proxy services that could route traffic out this way.
Layer3 says it did not aim at this network. It found the exits by chance, while asking services for rotating access from anywhere in the world. It then checked the addresses with Spur and Synthient. Their public lookup pages also list them as residential proxy exits.
How one device can speak for a whole network
Residential proxy services sell access to ordinary devices. Here is how that typically works, in plain words. Neither source describes these steps for this network. It is general background.
An app on a phone or computer includes a proxy SDK, a bundled piece of code. The code opens a connection outward to the proxy provider. A paying customer's request goes to the provider, then down that connection to the device. The device sends it on to the destination.
Most offices share one public address across all their devices. So the destination sees the organisation's shared address, not the single device. One device running such code can therefore lend a whole organisation's address to a stranger.
What Layer3 infers, and what nobody knows
Layer3 says about half the activity fell between 5 p.m. and midnight Eastern time. Almost none came in the early morning. From that timing alone, Layer3 infers a person who is regularly on the network in the evening. It argues this looks less like public guest Wi-Fi. Its inference is that the person's device carries a proxy SDK.
That is an inference, not an observation. Layer3 itself says: "Our data shows the exits, not the device or the person behind them." No device or person has been identified.
Layer3 says it backed up the raw logs and shared its findings with a US federal agency. Infosecurity says it contacted the White House for comment. The sources include no reply.
Why the SDK matters
Layer3 points to earlier research from Synthient on the Kimwolf botnet, which spread through residential proxy networks. In that research, the botnet reached two million devices or more. Most were Android phones and similar devices with a remote-control feature left open, called ADB. ADB is a developer feature for controlling a phone remotely.
Layer3 says earlier research shows that weakly secured proxy SDKs can let outsiders reach internal networks and move sideways between devices. If an SDK on this network had such a weakness, Layer3 says, a proxy customer could reach internal systems. That is a conditional. Neither source says such a flaw exists here.
Layer3 also logged traces in remote places. On Saint Helena, Ascension and Tristan da Cunha it counted 413 addresses behind more than 32,000 sightings. It saw three in Antarctica, tied to a Cloudflare WARP address pointing to McMurdo Station. This shows how far proxy networks reach. It does not show that other sensitive networks are affected.
Questions to put to your team
This is one network, so it shows no trend. It does expose a gap any organisation can test. Each question below follows from the mechanism above.
First, which of our rules trust traffic because of its source address? In our view, allow-lists and "internal network" exceptions often do. If one app lends out the shared address, those rules end up trusting whoever rents it.
Second, what leaves our network? The proxy connection starts from inside and goes outward, so it can look like ordinary outgoing traffic. Ask whether anyone watches connections to proxy providers.
Third, which apps on devices that join our network, including personal phones, bundle proxy code? Ask for an inventory, and ask who approves it.
Fourth, could a device carrying such code reach internal systems? Layer3 argued against guest Wi-Fi in this case, so do not assume the guest network is the only risk. Staff devices matter as much.
A trusted address tells you where traffic left. It does not tell you who sent it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Layer3 Intel.
