This week, Google—working closely with industry and law-enforcement partners—took coordinated action to disrupt what we assess to be one of the largest residential proxy networks operating today: the IPIDEA proxy network. Although largely unknown outside security research circles, IPIDEA represents a critical layer of infrastructure quietly abused by a wide range of cybercriminal, espionage, and information-operations actors.
The operation was led by the Google Threat Intelligence Group (GTIG) and involved legal, technical, and ecosystem-wide enforcement actions designed to degrade IPIDEA’s ability to operate, expand, and monetize its network.
Overview of Google’s Disruption Efforts
The disruption focused on three primary actions:
- Legal takedowns of command infrastructure
Google pursued legal action to dismantle domains used to control infected devices and route proxy traffic through them. These domains formed the backbone of IPIDEA’s command-and-control (C2) infrastructure. - Sharing technical intelligence across the ecosystem
GTIG shared detailed intelligence on IPIDEA software development kits (SDKs) and proxy software with platform providers, law enforcement agencies, and security research organizations. These SDKs—distributed across Android, Windows, iOS, and other platforms—surreptitiously enroll user devices into the IPIDEA network. Coordinated enforcement against these SDKs helps protect users and limits the network’s ability to grow. - Strengthening Android user protections
On certified Android devices, Google Play Protect now automatically warns users, removes applications known to embed IPIDEA SDKs, and blocks future installation attempts. These actions supplement existing protections designed to safeguard Android users at scale.
We believe these measures significantly degraded IPIDEA’s infrastructure and business operations, removing millions of devices from the available proxy pool. Because residential proxy operators often share access to devices via reseller agreements, these actions likely had cascading effects across affiliated networks.
Why Residential Proxies Are So Dangerous
Residential proxy networks differ from traditional proxies because they route traffic through IP addresses assigned by internet service providers (ISPs) to real homes and small businesses. By hijacking consumer IP addresses worldwide, attackers can mask malicious activity behind otherwise legitimate-looking traffic.
This makes detection and blocking extremely difficult for defenders.
To function at scale, residential proxy networks require millions of enrolled devices, particularly in high-value regions such as the United States, Canada, and Europe. Devices become part of these networks in several ways:
- Pre-installed proxy software on consumer devices
- Trojanized applications that embed proxy SDKs
- Voluntary installations, where users are misled by promises of monetizing “unused bandwidth”
Once enrolled, a device becomes an exit node, and the proxy operator sells access to that device’s bandwidth and IP address to third parties.
Abuse at Scale: How IPIDEA Was Used
Despite marketing claims about privacy or freedom of expression, GTIG’s research shows that residential proxies are overwhelmingly abused.
IPIDEA has played a central role in multiple botnets. Its SDKs were used to enroll devices, while its proxy infrastructure enabled botnet control and obfuscation. Notable examples include:
- BadBox 2.0, targeted in legal action last year
- Aisuru and Kimwolf botnets identified more recently
Beyond botnets, IPIDEA infrastructure has been heavily leveraged by threat actors involved in espionage, cybercrime, and influence operations. In a single seven-day period in January 2026, GTIG observed over 550 distinct threat groups using IPIDEA exit nodes. These groups—linked to China, North Korea (DPRK), Iran, and Russia—conducted activities including:
- Unauthorized access to SaaS environments
- Intrusions into on-premises infrastructure
- Password spraying and credential abuse
Significant overlap exists between residential proxy exit nodes due to reseller and partnership agreements, making attribution and precise quantification challenging.
Risks to Consumers
Residential proxies also pose serious risks to the users whose devices are unknowingly enrolled.
When a device becomes an exit node, third-party traffic passes directly through the user’s network, creating several dangers:
- Users’ IP addresses may be flagged or blocked due to criminal activity
- Proxy software introduces new attack surfaces on home networks
- Threat actors can potentially access other devices on the same network
GTIG analysis confirmed that IPIDEA proxy software did not merely forward traffic—it also sent traffic back to the device, enabling compromise. While proxy providers may claim ignorance or attempt fixes when notified, enforcement is complicated by opaque ownership structures and reseller ecosystems.
The IPIDEA Proxy Brand Ecosystem
Our investigation revealed that many well-known proxy and VPN brands are controlled by the same actors behind IPIDEA. These include:
- 360 Proxy
- 922 Proxy
- ABC Proxy
- Cherry Proxy
- Door VPN
- Galleon VPN
- IP2World
- Luna Proxy
- PIA S5 Proxy
- PY Proxy
- Radish VPN
- Tab Proxy
Although presented as independent services, these brands rely on shared infrastructure and management.
Monetization SDKs: The Core of the Network
The same operators also control several SDK brands marketed to developers as monetization tools. These SDKs are embedded into applications rather than installed standalone and support Android, Windows, iOS, and WebOS.
Developers are typically paid per install.
Once embedded, the SDK silently converts the device into a proxy exit node while allowing the host application to function normally. These SDKs are the foundation of IPIDEA’s ability to scale.
Identified SDKs include:
- Castar SDK
- Earn SDK
- Hex SDK
- Packet SDK
Many analyzed applications failed to disclose proxy enrollment. Prior research also identified uncertified Android devices, such as off-brand set-top boxes, shipping with hidden proxy payloads.
Command-and-Control Infrastructure
Two-Tier Architecture
IPIDEA SDKs operate using a two-tier C2 model:
Tier One
On startup, the device contacts one of several domains and sends diagnostic data, including a key that likely identifies the enrolling customer. The server responds with configuration details and Tier Two node information.
Tier Two
The device polls a Tier Two IP address for proxy tasks. When assigned, it establishes a dedicated connection and begins proxying traffic.
Tier One Communication
Device metadata is transmitted via HTTP GET or POST and includes OS version, device identifiers, and customer keys. Responses specify scheduling parameters and Tier Two IP:port pairs.
Tier Two Communication
Tier Two nodes use IP addresses rather than domains. The device periodically polls a “connect” port with encoded JSON. When proxy traffic is available, the server returns a destination FQDN and connection ID. The device then opens a new connection to the proxy port and relays traffic unmodified.
Shared Infrastructure Across SDKs
Analysis revealed substantial overlap across SDK brands:
- PacketSDK uses randomized subdomains across multiple TLDs
- CastarSDK and HexSDK share identical code and infrastructure
- EarnSDK overlaps with domains previously used by BadBox 2.0
Despite different branding, all SDKs rely on a shared pool of Tier Two servers, estimated at approximately 7,400 nodes worldwide, with daily churn consistent with demand-based scaling.
Distribution Channels for Exit Nodes
Trojanized VPN Applications
Several “free” VPN services provide legitimate VPN functionality while silently enrolling devices as proxy exit nodes. Examples include Galleon VPN and Radish VPN.
Trojanized Windows Software
Over 3,000 Windows binaries were identified that contacted Tier One domains. Some impersonated legitimate software such as OneDrive Sync or Windows Update.
Android Applications
More than 600 Android applications across multiple marketplaces contained IPIDEA SDK code. Most appeared benign—games, utilities, or content apps—but enabled proxy behavior via monetization SDKs.
Actions Taken to Disrupt IPIDEA
Google’s response focused on three goals:
- Protecting consumer devices by dismantling C2 infrastructure
- Limiting IPIDEA’s ability to distribute SDKs and proxy services through legal takedowns
- Coordinating with industry partners, including Cloudflare, Spur, and Lumen’s Black Lotus Labs, to disrupt DNS resolution, intelligence sharing, and enforcement
A Call to Action
Residential proxies now operate in a gray market built on deception. While some providers may claim ethical sourcing, any such claims must be backed by transparent, auditable proof of informed user consent.
Consumers should be wary of applications that promise payment for sharing bandwidth, stick to official app stores, review permissions carefully, and ensure security protections like Play Protect remain enabled.
Platforms, ISPs, and security firms must continue collaborating to expose and dismantle illicit proxy networks before they further entrench themselves in the global threat landscape.
