Skip to content

Residential proxies seen exiting White House network, firm says

Layer3 Intel says residential-proxy traffic left six IPs on AS2650 — the Executive Office of the President's network — 236 times in 30 days. No breach confirmed; likely an infected device.

Published 3 min read

Security firm Layer3 Intel says residential-proxy traffic exited the White House network 236 times in a month, routed through six IP addresses on AS2650 — the autonomous system registered to the Executive Office of the President. The firm is explicit that this is exit traffic, not a breach: no government system is known to be compromised, and the data shows the exits, not the device or person behind them.

What Layer3 found

Per the Layer3 Intel report (November 4):

  • Six addresses on AS2650 were reachable as residential-proxy exit nodes by 28 separate proxy services between October 5 and November 3, with activity on 26 of those 30 days.
  • Layer3's enumeration "exited through the network 236 separate times."
  • The firm found it by accident. "We noticed residential proxy exit activity on AS2650" while buying rotating proxy access for unrelated research, it writes — not by probing the White House.
  • Detections were cross-checked against Spur and Synthient.

Likely cause

Most activity landed in the evening, Eastern time, with almost none overnight — a pattern Layer3 reads as "a person rather than a public guest Wi-Fi network": someone regularly on the network late, on a device infected with a proxy SDK.

SecurityWeek reports that Synthient tied the traffic to Windows 11 machines running InfaticaSDK, proxy code bundled into free apps; some secondary coverage points instead to an app that packs multiple proxy SDKs. The exact application is unconfirmed. Infatica, a Singapore-based proxy vendor, was founded by Vladimir Fomenko, who per reporting by Brian Krebs also ran King Servers, a host linked to infrastructure used in the 2016 US election intrusions.

Why it matters

Proxyware SDKs turn any device into a sellable exit node the moment a bundled app runs. The practical risk is not this specific traffic — Layer3 found no evidence that proxy customers reached internal systems — but the model: a flaw in such an SDK could let paying customers route into whatever the host can reach. On a sensitive network, that is the whole problem.

Action checklist

  1. Inventory managed endpoints for proxyware and SDK-laden "share your bandwidth" apps; these ride in free VPNs, streaming tools and mobile utilities.
  2. Block known residential-proxy SDK domains at the egress proxy, and alert on unexpected outbound connections that look like proxy relays.
  3. Hunt for the InfaticaSDK pattern and for hosts serving as exit nodes — persistent outbound sessions from workstations that should only make client connections.
  4. Set policy: ban passive-income bandwidth-sharing apps on any device that touches corporate or privileged networks.

Context

This is the same failure mode flagged in our earlier coverage of proxyware riding compromised IoT and SAP hosts: residential-proxy code keeps surfacing on networks that should never host it, because the SDK follows the app, not the threat model. The novelty here is only the address block.

Related stories