Google vs IPIDEA: Anatomy of a Residential Proxy Takedown
Google Took Down 16 Million Proxy IPs. Here is Why It Will Not Be Enough.
On these pages, we have written several times about how proxy networks work and how they source their IPs. I’m exposing no secret by saying that, in some cases, companies act in a gray area.
Think about it: how would you convince several million people to share their spare internet connection with companies that you don’t know how they will use it?
Not an easy task, and some companies took shortcuts, as the IPIDEA case shows.
Let’s see it in detail: more than the takedown itself, we’ll use it as an opportunity to look under the hood: how do residential proxy networks acquire millions of IP addresses, what keeps them running, and why are they so difficult to shut down permanently? The IPIDEA case provides unusually detailed answers to all these questions.
What happens when Big Tech goes after the infrastructure that powers both scrapers and threat actors
On January 28, 2026, Google Threat Intelligence Group (GTIG) announced what they called the disruption of “one of the largest residential proxy networks in the world.” The target was IPIDEA, a name that most people outside the proxy industry had never heard. Yet according to Google’s analysis, IPIDEA’s infrastructure was being used by over 550 distinct threat groups in a single week, including state-sponsored actors from China, North Korea, Iran, and Russia.
This is not just a story about a takedown. It is a detailed look at how residential proxy networks actually work, how they acquire millions of IP addresses, and why disrupting them is harder than it sounds.
Before proceeding, let me thank NetNut, the platinum partner of the month. They have prepared a juicy offer for you: up to 1 TB of web unblocker for free.
What Google Actually Did
The disruption involved three coordinated actions:
First, Google took legal action to seize the domains used to control enrolled devices and route traffic through them. Without these command-and-control (C2) domains, the SDK code running on millions of devices loses the ability to receive instructions and proxy traffic.
Second, GTIG shared technical intelligence about IPIDEA’s SDKs with platform providers, law enforcement, and research firms. The goal was to trigger ecosystem-wide enforcement, getting these SDKs flagged and removed across multiple app stores and platforms.
Third, Google updated Play Protect to automatically warn users and remove applications known to contain IPIDEA SDKs. This blocks the network’s ability to recruit new devices on certified Android devices.
Google claims these actions reduced IPIDEA’s available device pool by millions. Whether that number holds up over time is a different question, and we will get to that.
Not all residential proxy networks operate in gray zones. Decodo built theirs on user consent, ISO 27001 certification, and co-founded the Ethical Web Data Collection Initiative to prove the model works.
The Anatomy of a Residential Proxy Network
To understand why this matters, we need to understand what a residential proxy network actually is and how it differs from datacenter proxies.
A datacenter proxy routes your traffic through IP addresses belonging to cloud providers or hosting companies. These IPs are easy to identify and block because they belong to known ASNs (Autonomous System Numbers) associated with commercial hosting.
A residential proxy routes traffic through IP addresses assigned by consumer ISPs to regular households. When you connect through a residential proxy, your request appears to come from someone’s home internet connection in Omaha, Tokyo, or Milan. This makes detection and blocking significantly harder because the traffic looks indistinguishable from a regular consumer browsing the web.
The challenge for proxy providers is obvious: they need access to millions of consumer devices to build a usable network. These devices need to be online, geographically distributed, and willing (or unwilling) to forward traffic.
There is an important nuance here. While Google’s report focuses on residential proxies, the same SDK installation on a mobile phone yields two distinct proxy classes. When the phone is connected to home WiFi, traffic exits through a residential IP assigned by the home ISP. When that same phone disconnects from WiFi and switches to 5G or LTE, traffic now exits through a mobile carrier IP. The device has not changed. The SDK has not changed. But the proxy class has shifted from residential to mobile.
This matters because mobile proxies are typically sold at a premium, sometimes 2-3x the price of residential proxies. Mobile carrier IPs are considered even harder to block than residential IPs because they are shared across thousands of legitimate mobile users through carrier-grade NAT. A single SDK deployment on mobile devices effectively generates inventory for two separate product lines.
How Residential Proxy Providers Acquire IP Addresses
The IPIDEA takedown revealed the specific mechanisms used to build and maintain a large-scale residential proxy network. These methods fall into several categories, ranging from semi-legitimate to clearly deceptive.
SDK Integration
The primary method is embedding Software Development Kits into legitimate applications. IPIDEA operated multiple SDK brands: PacketSDK, HexSDK, CastarSDK, and EarnSDK. These SDKs are marketed to app developers as monetization tools. The pitch is simple: integrate our SDK, and we will pay you based on downloads or active users.
Once embedded, the SDK turns the device into an exit node for the proxy network. The device will accept incoming connections from the proxy infrastructure and forward requests to target websites. The app continues to function normally. The user has no obvious indication that their device is being used as a proxy.
Google’s analysis found that many applications containing these SDKs did not disclose this functionality to users. The SDK was hidden, not mentioned in the terms of service, and ran silently in the background.
Trojanized Applications
Beyond SDK integration, IPIDEA directly operated or controlled VPN applications that served as trojan horses. Galleon VPN, Radish VPN, and Aman VPN all provided genuine VPN functionality while simultaneously enrolling devices into the proxy network.
The logic is effective: users who install VPN applications expect their traffic to be routed through external servers. They are primed to accept unusual network behavior. The proxy functionality hides inside this expected behavior.
Google identified over 600 Android applications across multiple download sources with code connecting to IPIDEA’s C2 infrastructure. On Windows, they found 3,075 unique executables making DNS requests to IPIDEA’s Tier One domains, including applications masquerading as OneDriveSync and Windows Update.
Pre-Infected Devices
Researchers have documented cases of uncertified Android devices shipping with residential proxy payloads already installed. Set-top boxes, TV boxes, and other IoT devices from off-brand manufacturers have been found with hidden proxy software baked into the firmware.
This method bypasses the need for user installation entirely. The device arrives compromised.
The Technical Architecture
Google’s reverse engineering of the SDK code revealed a two-tier command-and-control system.
When an infected device starts up, it contacts a Tier One server. The device sends diagnostic information including OS version, device identifier, and a key parameter that appears to be used for affiliate tracking (determining which app developer gets paid for the enrollment). The Tier One server responds with timing configuration and a list of Tier Two server IP addresses.
The device then periodically polls a Tier Two server, checking for proxy tasks. When a task arrives, it contains a target FQDN (like www.google.com:443) and a connection ID. The device establishes a connection to the target, receives data payloads from the Tier Two server, and forwards them unmodified to the destination.
Google found approximately 7,400 Tier Two servers at the time of their analysis, hosted globally including in the United States. The number fluctuated daily, suggesting a demand-based scaling system.
The infrastructure analysis revealed something important: despite different brand names (PacketSDK, HexSDK, CastarSDK, EarnSDK), all the SDKs connected to the same pool of Tier Two servers. The brands were marketing fronts for a single unified network.
The Brand Proliferation Problem
This brings us to one of the most interesting findings. IPIDEA did not operate under a single name. Google identified at least 13 ostensibly independent proxy and VPN brands controlled by the same actors:
360 Proxy
922 Proxy
ABC Proxy
Cherry Proxy
Door VPN
Galleon VPN
IP 2 World
Ipidea
Luna Proxy
PIA S5 Proxy
PY Proxy
Radish VPN
Tab Proxy
These brands operated separate websites, separate marketing, and separate pricing. A customer comparing “922 Proxy” to “Luna Proxy” would have no obvious indication that they were buying access to the same underlying network.
This is not unique to IPIDEA. Industry analysis suggests there are only about 7 truly unique residential proxy networks globally, despite hundreds of brands competing in the market. The rest are resellers, white-labels, or, like IPIDEA, multiple storefronts for the same infrastructure.
Why Residential Proxies Are Hard to Block
The fundamental problem for defenders is that residential proxy traffic looks legitimate. When a request arrives from a Comcast IP in Chicago, there is no technical marker indicating whether it comes from an actual Comcast customer browsing normally or from a proxy network routing traffic through that customer’s compromised device.
The proxy networks exploit this by design. The value proposition they sell is precisely this difficulty of detection.
Security researcher Antoine Vastel published concrete data that illustrates the scale of this problem. By actively testing proxy endpoints, he verified more than 16 million unique IP addresses that were functional and associated with the IPIDEA network during the 30 days preceding the takedown. The breakdown by brand shows the relative sizes within the IPIDEA ecosystem: PY Proxy (PyProxy) accounted for 13.4 million IPs, PIA S5 Proxy for 2.2 million, and Luna Proxy for 549,000.
These are not theoretical numbers from marketing materials. These are IP addresses through which Vastel routed traffic and confirmed as working proxy endpoints. And here is the critical insight from his analysis: even with 16 million identified proxy IPs, defenders cannot simply block them.
The reason is that residential exit nodes mix traffic from automated tools and legitimate human users on the same IP. The device owner browses the web normally, while the SDK, in the background, forwards proxy traffic over the same connection. Blocking these IPs based on proxy activity would inevitably block real users who happen to share an IP or whose IP was previously used as an exit node.
Vastel’s recommendation is telling: use these IoCs for risk scoring, behavioral enrichment, and incident investigation, but not for direct blocking. The data is context, not a verdict. This fundamental asymmetry makes residential proxies valuable to attackers and frustrating for defenders.
His research also confirmed another pattern: IP addresses frequently appear across multiple proxy ecosystems simultaneously. IPIDEA did not rely exclusively on its own residential pool. Requests were routed through or resold from other networks. The same IP might be accessible through IPIDEA, a competitor, and a reseller all at once. This interconnection means that even identifying an IP as “IPIDEA-linked” does not tell you the full story of how it is being used.
Traditional IP reputation systems struggle with this complexity. Blocking known bad IPs works for datacenters where the IP assignments are stable, and the ASNs are identifiable. Residential IP addresses rotate frequently as ISPs reassign addresses, and blocking residential IP ranges blocks legitimate users.
Google’s Approach: Attacking the Infrastructure
Rather than trying to block individual IP addresses, Google attacked the control infrastructure. By taking down the Tier One C2 domains, they severed the connection between infected devices and the proxy operators. Without C2 connectivity, the SDK code on millions of devices becomes inert.
This approach has precedent. It is the same strategy used against botnets: identify the command-and-control infrastructure and take it down. The infected devices remain infected, but they can no longer receive instructions.
Google also partnered with Cloudflare to disrupt IPIDEA’s domain resolution, adding another layer of infrastructure disruption beyond the legal domain seizures.
Will It Work? The Persistence Problem
Here is where we need to be realistic about the limitations of this approach.
The takedown disrupted IPIDEA’s current infrastructure. The domains are gone. The C2 servers are unreachable. Millions of devices are no longer participating in the proxy network. But “no longer participating” is not the same as “cleaned up.”
The fundamental problem is that infected devices remain infected. The SDK code is still installed on millions of phones, tablets, TV boxes, and computers worldwide. Google can take down domains. Google can update Play Protect to block new installations. What Google cannot do is reach into millions of devices and uninstall the malicious code that is already there.
For the SDK to be removed, one of these things needs to happen: the user manually uninstalls the app containing it, the device gets factory reset, or the device gets replaced. None of these happens at scale. Most users are unaware that the SDK exists. The apps that contain it often provide real functionality, games, utilities, and VPNs that users want to keep. There is no mechanism to notify millions of people across dozens of countries that their flashlight app is secretly a proxy node.
This creates an asymmetry that favors the attackers. Google invested significant legal, technical, and coordination resources to take down IPIDEA’s infrastructure. The IPIDEA operators (or anyone who acquires their codebase) can spin up new C2 domains, update their DNS configuration, and potentially reactivate a substantial portion of the dormant network. The SDK code often includes fallback mechanisms and update capabilities precisely for this scenario.
The brand proliferation we discussed earlier is part of this resilience. IPIDEA operated 13+ brands. If some domains get seized, others may survive. If the entire IPIDEA operation is compromised, the operators can rebrand entirely and inherit a pre-installed base of millions of devices waiting for new instructions.
Google acknowledged this reality in its announcement, noting that “this industry appears to be rapidly expanding” and that “there are significant overlaps across providers.” The reseller and partnership agreements that connect different proxy brands mean that disruption propagates unpredictably through the ecosystem, but so does recovery.
This is not a battle that can be won definitively. It is a cost-imposition strategy. The goal is to make operating these networks so expensive and risky that some operators exit the market or shift to more legitimate practices. But as long as the infected device base exists, the infrastructure can be rebuilt. The realistic outcome is degradation, not eradication.
The Economics Behind Residential Proxy Networks
Understanding why these networks exist requires understanding the economics.
Residential proxy bandwidth sells for $4-8 per gigabyte or more to end customers. The cost to acquire that bandwidth through SDK partnerships is measured in cents per gigabyte. The gross margins appear enormous.
But running a proxy operation is not just bandwidth arbitrage. The real costs include:
Engineering and Infrastructure: Maintaining thousands of C2 servers globally, building rotation logic, handling the unreliable nature of consumer devices going online and offline unpredictably.
SDK Distribution: Paying app developers for integration, maintaining relationships with publishers, and navigating app store policies that increasingly scrutinize monetization SDKs. The silver lining is that mobile app SDKs generate dual inventory: residential IPs when devices are on WiFi, mobile IPs when they switch to cellular. This allows providers to sell the same underlying device pool across two product categories at different price points.
Customer Acquisition: Finding buyers for proxy services is expensive. The market is niche, competition is intense, and customers are price-sensitive.
Legal and Compliance: Or in IPIDEA’s case, the lack thereof. Operating in legal gray zones creates ongoing risk. The Google takedown demonstrates what happens when that risk materializes.
Industry estimates suggest customer acquisition costs consume 40-60% of revenue even at scale. The apparent margin compression means that most residential proxy providers operate on thin actual profits despite the high sticker prices.
This economic pressure explains the proliferation of brands. Running multiple storefronts for the same underlying network lets operators segment the market, test different price points, and spread legal risk across multiple corporate entities.
The Bigger Picture
The IPIDEA takedown is part of a larger pattern. Google previously took action against the BadBox2.0 botnet, which shared infrastructure with IPIDEA. Law enforcement agencies worldwide are paying greater attention to residential proxy networks, recognizing the role this infrastructure plays in facilitating activities ranging from credential stuffing to espionage.
The residential proxy industry has partially operated in a legal gray zone for years. The Google action, particularly the legal component, establishes a clearer precedent that enrolling devices without consent and facilitating malicious activity creates meaningful legal exposure.
This does not mean residential proxies are going away. The demand exists, and where demand exists, supply follows. However, the industry may be compelled toward more transparent practices: clearer consent mechanisms, improved disclosure in applications that embed SDKs, and more careful vetting of customers who purchase proxy access.
For those of us who work with web scraping, the takedown is a reminder that the infrastructure we rely on has a supply chain. Understanding the supply chain, including its technical architecture, its business model, and its vulnerabilities, helps us make better decisions about which providers to trust and how to build resilient scraping systems.
The IPIDEA network may be rebuilt, rebranded, or replaced by competitors. However, the detailed technical analysis Google published provides the entire industry with greater visibility into how these networks operate. That visibility, more than the takedown itself, may be the most lasting impact.




How can I tell if any devices on my residential network have been compromised?