<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"><title>Peakhour.IO - Supply Chain Security</title><link href="https://www.peakhour.io/" rel="alternate"></link><link href="https://www.peakhour.io/feeds/tag/supply-chain-security.atom.xml" rel="self"></link><id>https://www.peakhour.io/</id><updated>2026-08-03T10:30:00+10:00</updated><entry><title>IPIDEA and NetNut: What Two Residential Proxy Takedowns Actually Changed</title><link href="https://www.peakhour.io/blog/ipidea-netnut-proxy-takedowns/" rel="alternate"></link><published>2026-08-03T08:00:00+10:00</published><updated>2026-08-03T10:30:00+10:00</updated><author><name>AC</name></author><id>tag:www.peakhour.io,2026-08-03:/blog/ipidea-netnut-proxy-takedowns/</id><summary type="html">&lt;p&gt;Google's 2026 actions against IPIDEA and NetNut disrupted control infrastructure, applications and commercial supply. They did not make residential traffic safe by default.&lt;/p&gt;</summary><content type="html">&lt;p&gt;Two large residential proxy networks were disrupted within six months. In late January, Google announced action against IPIDEA. In July, Google, the FBI, Lumen and other partners acted against NetNut, also known as Popa.&lt;/p&gt;
&lt;p&gt;Both operations interfered with infrastructure that connected home devices to paying proxy customers. Both prompted Android protections and intelligence sharing. Both were expected to affect providers beyond the name on the announcement.&lt;/p&gt;
&lt;p&gt;They were not identical operations, and neither removed residential proxy risk from a login page, checkout, advertising campaign or API.&lt;/p&gt;
&lt;p&gt;For security and fraud teams, the useful question is narrower than whether a network was “taken down”. Which parts stopped working, which sources of supply became harder to use, and what still reaches the application?&lt;/p&gt;
&lt;h2&gt;The Actions Hit Different Parts of the System&lt;/h2&gt;
&lt;p&gt;The &lt;a href="https://cloud.google.com/blog/topics/threat-intelligence/disrupting-largest-residential-proxy-network"&gt;IPIDEA action announced in January&lt;/a&gt; combined several controls.&lt;/p&gt;
&lt;p&gt;Google said it used legal action to take down domains used to control devices and proxy traffic, as well as domains used to market proxy products and software development kits. Google Play Protect was configured to warn users, remove known applications containing IPIDEA SDKs and block future installation attempts on certified Android devices. Google also shared technical intelligence with platform providers, law enforcement and researchers. Cloudflare disrupted domain resolution.&lt;/p&gt;
&lt;p&gt;The &lt;a href="https://cloud.google.com/blog/topics/threat-intelligence/google-continued-disruption-residential-proxy-networks"&gt;July action against NetNut&lt;/a&gt; had a different public description. Google disabled Google accounts and associated services that it said NetNut used for command and control. It shared intelligence about SDKs and backend infrastructure, while Play Protect warned users and disabled known applications containing NetNut SDKs. Separately, Alarum Technologies, NetNut's parent company, &lt;a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026075170/ea029706002ex99-2.htm"&gt;confirmed in an SEC filing&lt;/a&gt; that the FBI had seized domains associated with NetNut and that additional domains were later seized.&lt;/p&gt;
&lt;p&gt;That distinction matters. A domain seizure, a disabled cloud account and removal of an application are not interchangeable:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;C2 and domain disruption&lt;/strong&gt; can stop enrolled devices finding instructions or carrying proxy traffic through known control paths.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Account and service suspension&lt;/strong&gt; removes infrastructure hosted on a provider's platform.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Play Protect enforcement&lt;/strong&gt; reduces active Android supply and makes the same known applications harder to reinstall.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Intelligence sharing&lt;/strong&gt; lets other platforms and network operators identify related software and infrastructure.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Each action raises operating cost. None proves that every endpoint, reseller account or replacement control path has disappeared.&lt;/p&gt;
&lt;h2&gt;IPIDEA Exposed a Shared Supply Chain&lt;/h2&gt;
&lt;p&gt;Google's IPIDEA investigation described more than 600 Android applications across multiple download sources, 3,075 Windows file hashes that contacted its first-tier domains, and a changing pool of roughly 7,400 second-tier servers. Google also connected several proxy, VPN and SDK brands to common operators and infrastructure.&lt;/p&gt;
&lt;p&gt;The company said the disruption reduced the available device pool by millions. It also observed more than 550 tracked threat groups using addresses identified as IPIDEA exits during one seven-day period in January 2026. The reported activity included password spraying and access to victim SaaS and on-premises environments.&lt;/p&gt;
&lt;p&gt;The overlap is more useful to buyers than the largest headline number. Different product names and SDK labels fed common infrastructure, while reseller and partnership arrangements created overlap between exit pools. A buyer choosing a second brand could still be purchasing access to the same upstream capacity.&lt;/p&gt;
&lt;p&gt;That structure is covered in more detail in &lt;a href="/blog/bandwidth-sharing-residential-proxy-supply-chain/"&gt;How Bandwidth Sharing Feeds Residential Proxy Networks&lt;/a&gt;. The point for this comparison is that IPIDEA's disruption reached beyond one storefront because control, distribution and supply were shared.&lt;/p&gt;
&lt;h2&gt;NetNut Showed the Commercial Effect More Clearly&lt;/h2&gt;
&lt;p&gt;Google estimated that the NetNut network contained at least two million devices. During one week in June, it observed 316 distinct threat clusters using suspected NetNut exits, including cybercrime and espionage groups. Google also said NetNut ran a substantial white-label reseller programme and assessed with high confidence that a number of popular proxy brands were reselling the network.&lt;/p&gt;
&lt;p&gt;Those figures should not be placed in a league table against IPIDEA's. “Devices removed” is not the same measure as an estimated network size. “Tracked threat groups” and “distinct threat clusters” may not use the same counting method. The observations came from different weeks and networks. They establish material scale and misuse, not a defensible ranking.&lt;/p&gt;
&lt;p&gt;The stronger comparison is operational. Google later reported that some networks affected by the IPIDEA action appeared resilient: operators whose own supply degraded bought capacity from competitors and became resellers. Its NetNut action was designed with that adaptation in mind.&lt;/p&gt;
&lt;p&gt;Alarum's disclosures show that the July action did affect the business. On 3 July, the company said the seized domains were disrupting part of its services and could have a material adverse effect if the disruption continued. It subsequently &lt;a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026075170/ea029706002ex99-3.htm"&gt;announced a temporary pause&lt;/a&gt; of traffic through relevant network services. In its &lt;a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026077383/ea029779901ex99-1.htm"&gt;13 July update&lt;/a&gt;, Alarum said the events had materially affected its business and operations, that an external forensic review was continuing, and that an efficiency plan was expected to affect roughly one-third of its workforce. It was still evaluating how to restore service.&lt;/p&gt;
&lt;p&gt;That is evidence of business and service disruption. It is not evidence that every NetNut-related device was cleaned, every reseller lost access, or all residential capacity sold under other names stopped.&lt;/p&gt;
&lt;h2&gt;Accountability Requires Keeping the Claims Separate&lt;/h2&gt;
&lt;p&gt;This market has competing accounts of the same infrastructure.&lt;/p&gt;
&lt;p&gt;In its March 2026 &lt;a href="https://www.sec.gov/Archives/edgar/data/1725332/000121390026031556/ea0281588-20f_alarum.htm"&gt;annual report&lt;/a&gt;, Alarum described its network as serving business uses including public web-data collection, price comparison, advertising verification and cybersecurity. It said its experience allowed customers to collect data ethically and effectively. These are the provider's descriptions of its products and intended uses.&lt;/p&gt;
&lt;p&gt;Google reported different findings from its threat intelligence and technical investigation. It linked NetNut SDK components to home devices and larger botnets, reported suspected exits used by cybercrime and espionage clusters, and said many brands white-labelled NetNut capacity. For IPIDEA, it reported applications with unclear disclosure, common infrastructure behind several brands, and extensive use by tracked threat groups.&lt;/p&gt;
&lt;p&gt;Alarum's official response did not address or endorse Google's technical characterisation, and it did not publish a competing completed investigation. It acknowledged the domain seizures and disruption, said it was investigating whether third parties had misused its services or network, promised cooperation with law enforcement and later said its external review had reached no final conclusions.&lt;/p&gt;
&lt;p&gt;The evidence therefore supports several restrained conclusions:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Google identified infrastructure and software it attributed to the two proxy networks and observed serious misuse of their exits.&lt;/li&gt;
&lt;li&gt;Google reported significant degradation and reduced device availability; Alarum's disclosures independently confirm disruption to NetNut's operations.&lt;/li&gt;
&lt;li&gt;Reseller and white-label relationships make a retail provider name weak evidence of independent supply.&lt;/li&gt;
&lt;li&gt;Public reporting does not establish that every customer used the services unlawfully, that every enrolled device joined without consent, or that corporate management directed every observed act.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;For procurement and accountability teams, that last boundary is not a reason to ignore the findings. It is a reason to ask better questions. A provider should be able to identify its upstream networks, explain how each endpoint was enrolled, show how consent can be withdrawn, disclose white-label dependencies, describe customer controls, and produce evidence when those claims are challenged.&lt;/p&gt;
&lt;p&gt;“Ethically sourced” is not useful due diligence unless the buyer can test what it means.&lt;/p&gt;
&lt;h2&gt;The Destination Risk Continued&lt;/h2&gt;
&lt;p&gt;A takedown acts upstream. The protected application sits downstream.&lt;/p&gt;
&lt;p&gt;When an SDK is removed or a control domain is seized, some devices leave a pool and some routes fail. That reduces available supply and may interrupt active campaigns. It does not reverse requests already made, clean every non-Android device, reveal every replacement domain, or prevent an operator buying another provider's exits.&lt;/p&gt;
&lt;p&gt;The destination still receives requests from consumer and small-business IP addresses. Some belong to customers. Some are shared through carrier-grade NAT. Some are privacy services. Some are residential proxy exits that have not yet appeared in a feed. The application cannot infer who controls a request from the address alone.&lt;/p&gt;
&lt;p&gt;This is especially important when the household owner may also be a victim. &lt;a href="/blog/application-defence-compromised-home-devices/"&gt;When Home Devices Become Attack Infrastructure&lt;/a&gt; explains why application teams should preserve evidence without attributing the request to the subscriber.&lt;/p&gt;
&lt;h2&gt;What Buyers Can Now Demand&lt;/h2&gt;
&lt;p&gt;The two operations give procurement, security and fraud buyers better questions to put to a proxy supplier.&lt;/p&gt;
&lt;p&gt;Ask the vendor to identify the retail provider, upstream source, reseller relationship, endpoint-enrolment method and removal process. Contract for notification when an upstream source changes. A new brand or ASN is not proof of a new supply chain.&lt;/p&gt;
&lt;p&gt;Ask which proportion of delivered sessions can be traced to direct, auditable sourcing. Require the assurance to cover upstream and white-label capacity, not only a proprietary pool. Check whether withdrawal removes an exit from every downstream reseller and how the provider proves that happened.&lt;/p&gt;
&lt;p&gt;Ask what the provider knew and when. A policy page states an intention. Session-level supplier, software, consent and removal records provide evidence that can be tested.&lt;/p&gt;
&lt;p&gt;The takedowns removed real infrastructure and imposed real costs. They also demonstrated why disruption is a continuing process rather than a permanent state. Shared supply can move and resellers can change upstream providers.&lt;/p&gt;
&lt;p&gt;The operational response belongs in the final article in this series, &lt;a href="/blog/proxy-takedown-is-not-security-control/"&gt;A Proxy Takedown Is Not a Security Control&lt;/a&gt;. It covers the live detection, route policy and outcome measures a destination service should rebaseline after enforcement.&lt;/p&gt;
&lt;p&gt;The next article in this series, &lt;a href="/blog/when-proxy-network-dies-ips-survive/"&gt;When a Proxy Network Dies but Its IPs Survive&lt;/a&gt;, examines what post-takedown address overlap can prove and where the inference stops.&lt;/p&gt;</content><category term="Residential Proxies"></category><category term="Residential Proxies"></category><category term="Bot Management"></category><category term="Fraud Prevention"></category><category term="Threat Detection"></category><category term="Account Protection"></category><category term="Supply Chain Security"></category></entry></feed>