What happened
Layer3 Intel reports 236 residential proxy exits through AS2650, which it says is registered to the Executive Office of the President, from six addresses on 26 of 30 days between 5 October and 3 November (vendor, Layer3 Intel). Twenty-eight public proxy services could exit there. "This is public access," Layer3 writes. "Anybody can obtain it by signing up to a public residential proxy service."
Founder Sergiy Usatyuk told The Register the most recent activity came hours after the post went live and then stopped, and that the State Department asked for his logs (independent, The Register). The White House did not respond to The Register, or to Krebs.
What is known, and what is not
| Claim | Status | Source |
|---|---|---|
| Exit counts, addresses, dates | Measured by Layer3. Spur and Synthient identify the same addresses as proxy exits | vendor, Layer3 |
| A person's device, not guest Wi-Fi | Inference from timing: about half the activity falls between 5 p.m. and midnight Eastern. Layer3 says its data "shows the exits, not the device or the person behind them" | vendor, Layer3 |
| Infatica SDK on staff Windows machines | Attributed by Synthient, relayed. Reports differ on Windows 10 and 11 or 11 alone. Usatyuk says attributing it to one provider is difficult | independent, Krebs, The Register, BankInfoSecurity, This Week in Security |
| Reach into internal systems | Conditional. Layer3 says that if an SDK there has a flaw like past ones, "anyone buying proxy access could use it to reach internal systems". Nothing we read shows anyone did | vendor, Layer3 |
| Number of devices | Unknown. The Register reports Layer3's data cannot show it | independent, The Register |
Layer3, Spur, and Synthient all sell or run proxy detection. That does not make the counts wrong. It is worth knowing when one of them tells you to look.
Why this is your problem
Spur found residential proxies in nearly 300 government-owned networks, 318 utilities, 166 healthcare companies or hospitals, and 141 banking and finance companies, and Infoblox says 65% of its customers queried a proxy-related domain (independent, Krebs). A DNS query is not an exit, so do not read those as one number.
Krebs describes the route in: free apps and embedded SDKs paying small amounts per install, on employee devices brought into the workplace. Your firewall allows all of that as ordinary outbound traffic. The buyer of the proxy gets your IP reputation, and possibly a foothold on your network.
Six steps
Prerequisites: a list of owned public ranges, and NAT, DHCP, and Wi-Fi logs with enough retention to go back.
- Step 1. List every egress. Corporate NAT, guest Wi-Fi, VPN concentrators, branch links, and cloud NAT gateways. Guest and BYOD egress is the likeliest place to find this. Owner: network lead.
- Step 2. Check the ranges, not one laptop. Layer3's free check tests the visitor's own connection (vendor). For a range, run it from each egress or query a commercial proxy data feed. Pool membership changes, so repeat it. Owner: SecOps lead.
- Step 3. Check log retention first. An exit is a timestamp on a public IP. Finding the device needs NAT, DHCP, Wi-Fi association, and endpoint records for that moment (independent, RuntimeWire). If those roll off in days, extend them before you look. Owner: SecOps lead.
- Step 4. Trace a hit to a device. Match the time to the internal host, then look at installed apps, free VPNs, and browser extensions. Do not assume malware until you have looked. Owner: incident response lead.
- Step 5. Test what that device could reach. Treat it as if an outsider sat on that segment. Check access to internal services, admin panels, and metadata endpoints. Owner: incident response lead.
- Step 6. Separate BYOD from anything that matters. Guest and personal devices get their own egress and no route to internal systems. Add unapproved proxy SDKs and free VPNs to your MDM and EDR rules. Owner: network lead with IT.
Trade-offs
- One-off check or a feed. A one-off check is cheap and goes stale, because pools change. A feed costs money and gives you a trend. Start with one check per egress.
- Block proxy domains in DNS. Useful and incomplete. Personal devices on their own resolvers will not see the block.
- Lock down BYOD. Removes the path and costs convenience. Separate egress gets you most of the benefit for less friction.
Missing
- How many devices were involved, and whose.
- Any evidence of internal access, either way.
- A response from the White House or from Infatica.
- Spur's and Synthient's own pages. We read their findings as relayed by Layer3 and the press.
- A test by Prestanda. We have not run this check on a client network; the steps are our reading of the sources above.
Frequently asked questions
Was the White House hacked?
Nothing we read establishes that. Layer3 measured proxy exits from six addresses, and says its data shows the exits, not the device or the person behind them. Internal access is a conditional risk it raises, not something it reports.
How do we check our own network?
List every public egress, then test each one, because Layer3's free tool checks only the connection you run it from. A commercial proxy data feed can check whole ranges. Repeat it, because pool membership changes.
What do we do if we find one?
Keep the logs, match the timestamp to a device through NAT, DHCP, and Wi-Fi records, inspect that device, and test what it could reach. Treat it as an incident until you know what the device could touch.
Living page. Last updated 6 Nov 2026. We update this note when device counts, a response, or evidence of internal access appear.