White House Network Used as Proxy Exit
Layer3 Intel logged 236 residential proxy exits through White House addresses over 30 days, though no compromise is reported.
Twenty-eight separate residential proxy services routed traffic through six internet addresses registered to the Executive Office of the President, according to research from a New York-based detection firm. The finding, published on November 4, describes a pattern of exits rather than an intrusion — but it places the addresses of a federal network on a list that anyone with a few dollars can buy into.
The firm, Layer3 Intel, said the exits were recorded in its Residential Proxy Observatory and cross-checked against public lookup pages from proxy detection services Spur and Synthient, which independently identified the addresses as residential proxy exits.
Six addresses, 236 exits
The addresses sit in AS2650, the block of internet addresses — an autonomous system — registered to the Executive Office of the President, the federal agency that hosts the White House network. Layer3 said traffic left through those addresses 236 times over a 30-day period.
The exits were recorded on 26 of the 30 days between October 5 and November 3, according to the firm. That leaves only four days in the window without a recorded exit through the six addresses.
Layer3 said it found the activity by chance, while requesting ordinary global rotating access through residential proxy services. Residential proxies are services that sell access to everyday devices, letting customers send traffic through them so it appears to come from each device's network.
What a residential proxy exit means
A residential proxy exit is the point at which traffic leaves a device and enters the wider internet. The service routes a customer's requests through a real device on a real network, so the destination sees the device's address rather than the customer's.
Layer3 was careful about what its data shows. The firm said the logs record the exits, not the device or the person behind them. Its observatory captures traffic leaving through the addresses; it does not identify which machine generated it or who was operating it.
The addresses were flagged by two other detection services. Layer3 said it cross-checked against public lookup pages from Spur and Synthient, both of which independently identified them as residential proxy exits. That cross-check matters because it moves the finding beyond a single firm's telemetry.
Evening-heavy traffic pattern
About half of the activity fell between 5pm and midnight Eastern Time, with almost none in the early morning, Layer3 said. The concentration of exits in the evening hours is the detail the firm used to reason about who or what might be behind the traffic.
Layer3 said that pattern suggested a person rather than a public guest Wi-Fi network: someone regularly on the White House network late into the evening, whose device was infected with a proxy software development kit (SDK).
In its research, the firm drew a clear line around what it could and could not conclude. “Our data shows the exits, not the device or the person behind them,” it wrote.
“The most recent activity was recorded in the evening of November 4; hopefully, it stops soon!”
— Sergiy Usatyuk, founder of Layer3, speaking to Infosecurity.
No compromise reported
Layer3 did not report any compromise of White House systems. The firm said it has backed up the raw logs of the activity and has shared its findings with a US federal agency.
Infosecurity has contacted the White House for comment. The source article does not include a response from the White House.
The distinction between an exit and a breach is central to how the finding should be read. Traffic leaving through an address does not by itself demonstrate that anyone accessed internal systems, and the firm's public statements do not claim that it did.
Why proxy SDKs carry risk
Past research has shown that poorly secured proxy SDKs can allow access to internal networks and lateral movement, which is how past botnets have spread. The risk sits in the SDK — the software component that turns a device into a proxy node — rather than in the proxy service itself.
Layer3 cited Synthient research showing the Kimwolf botnet reached at least two million devices, mostly Android devices with an exposed Android Debug Bridge (ADB) service, through residential proxy networks. That example describes how a large population of devices can be pulled into proxy networks when a service is left exposed.
If an SDK on the White House network had the same kind of flaw, Layer3 said, anyone buying proxy access could use it to reach internal systems. The firm framed this as a conditional risk rather than an observed one.
The numbers behind the finding
- 236 residential proxy exits through White House network addresses over a 30-day period
- 28 separate residential proxy services able to route traffic through the addresses
- Six addresses in AS2650 registered to the Executive Office of the President
- 26 of 30 days between October 5 and November 3 recorded an exit
- About half of the activity fell between 5pm and midnight Eastern Time
- Two million devices reached by the Kimwolf botnet, per Synthient research cited by Layer3
Anyone could sign up
Layer3 said anyone could route traffic out through the same addresses by signing up to a public residential proxy service and paying a few dollars. The barrier to entry is a subscription, not an exploit.
That detail shapes the finding's significance. The addresses are not hidden behind an attack technique; they are reachable through commercial services that sell access to devices. Layer3's own route to the discovery was a routine request for global rotating access.
The firm's observatory is where the exits were logged. Layer3 said it spotted the exits, recorded on 26 of the 30 days, in the newly launched Residential Proxy Observatory.
What the finding does not establish
The research does not identify a device, a user, or an intruder. It does not report unauthorized access to White House systems. It does not establish that the addresses were used for any purpose beyond routing traffic.
What it does establish, per Layer3, is that residential proxy traffic exited through six addresses in AS2650 on 26 days, that 28 services could route through them, and that the timing clustered in the evening. The firm said it has retained the raw logs and passed the findings to a federal agency.
Infosecurity reported that Layer3 shared its findings with a US federal agency, and that the publication had contacted the White House for comment. No compromise has been reported.
What this means for networks that host devices
For organizations, the finding points to a question that does not require an intrusion to be worth asking: which devices on a network are running software that can turn them into proxy nodes? Layer3's account of proxy SDK risk — that poorly secured SDKs can allow access to internal networks and lateral movement — describes a hazard that begins with an installed component, not with a breach.
The White House case also shows how a network's public addresses can appear in commercial proxy infrastructure without any reported compromise. Detection firms cross-check addresses against public lookup pages, and those pages are what Layer3 used to confirm the exits with Spur and Synthient. For any organization, that means its address space may be described in third-party datasets before it knows why.
The conditional risk Layer3 raised is the one to watch: if an SDK on a sensitive network carried the same kind of flaw seen in past botnet research, proxy access bought for a few dollars could become a path toward internal systems. That is a hypothetical in this case, and the firm presents it as one. But it is the reason a pattern of evening exits, logged and shared with a federal agency, is being treated as worth documenting rather than dismissed. Readers running networks with unknown or unmanaged software on endpoints may find the same question applies to them — not because an intrusion has been shown, but because the exit data, on its own, is enough to prompt a check.
Sources
- Infosecurity Magazine Original source
Continue Reading
Musl password flaw hands over root access
A decade-old OpenSSH quirk in musl-based Linux systems lets long passwords bypass asterisk-locked accounts, and a fix is out.
Asterisk bypass in musl OpenSSH
A flaw in OpenSSH on musl-based Linux lets attackers log into password-disabled accounts with an oversized password, researcher says.
APT Retry Path Opens Root-Level Package Swap
A flaw in Debian and Ubuntu's package manager lets anyone who can tamper with downloads swap a verified package for one that runs as root.