Google Disrupts the NetNut Residential Proxy Network

Google Threat Intelligence Group announced on July 3, 2026 that Google, the FBI, Lumen, and other participants had taken coordinated action against the NetNut residential proxy network, also known as Popa. Google said it disabled accounts and services used for command-and-control activity, shared technical intelligence with other organizations, and used Google Play Protect to warn users and disable known applications containing NetNut software development kits.

What Google reported

Google estimated that the NetNut network contained at least two million devices worldwide. It said the coordinated actions significantly degraded the available device pool by millions and affected business operations. Google also reported observing 316 distinct threat clusters using suspected NetNut exit nodes during one week in June 2026, including cybercrime and espionage activity.

• Google disabled accounts and services it said were used for malware command and control.
• Technical information about SDKs and backend infrastructure was shared with platforms, researchers, and law enforcement.
• Google Play Protect was configured to warn users and disable applications known to incorporate the identified SDKs.
• Google warned that proxy operators can buy capacity from competing networks after a disruption, so a single intervention may not permanently remove the underlying market.

What the company disclosed

In a filing published by the US Securities and Exchange Commission, Alarum said that it and NetNut became aware on July 2 of the seizure of certain NetNut-associated domains by the FBI. The company said it would cooperate with law enforcement and investigate misuse of its infrastructure. That response is important context: a disruption announcement does not by itself resolve every question about which devices, customers, or traffic were involved.

Why residential proxies complicate bot detection

A residential proxy routes traffic through an address assigned by an internet service provider to a household or consumer connection. That can make an automated request resemble ordinary residential traffic even when the operator is elsewhere. It also means an innocent subscriber's address can become associated with password spraying, scraping, fraud, or other abuse that the subscriber did not initiate.

The practical lesson is not that every residential address is suspicious. It is that network type is only one signal. A policy that automatically trusts residential IPs can be evaded, while a policy that automatically blocks them can harm real users. Request behavior, user-agent consistency, URL and action sensitivity, authentication history, reputation, and customer policy need to contribute to the final decision.

Defensive actions for web and API operators

1. Treat IP classification as context, not identity. Do not allow a sensitive action solely because an address appears residential.
2. Apply action-specific controls to login, password reset, account creation, checkout, coupon, and high-cost API routes.
3. Correlate repeated failures across accounts, sessions, networks, devices, and time windows instead of relying on one IP threshold.
4. Verify known crawlers and trusted integrations through documented identity mechanisms rather than a claimed user agent.
5. Use temporary, reviewable mitigation for network indicators that can be reassigned or shared with legitimate users.
6. Monitor false positives after threat-feed or reputation updates because an affected household address may later return to normal use.

What consumers can do

Google advised consumers to be cautious with applications that offer payment for sharing unused bandwidth, to install software from reputable sources, review VPN and proxy permissions, keep built-in device protections active, and verify that connected devices use certified software. Unexpected bandwidth use, unfamiliar applications, or unexplained reputation blocks are reasons to inspect a device and home network rather than simply change a browser.