Skip to content
RiverCore
NetNut Takedown: Google and FBI Break a 2M-Device Botnet
residential proxy botnetNetNut takedownFBI Google operation2 million device botnet dismantledhijacked smart TV proxy network

NetNut Takedown: Google and FBI Break a 2M-Device Botnet

4 Jul 20267 min readJames O'Brien

Think of residential proxy botnets the way you think of a city's water supply: nobody notices the pipework until something starts leaking sewage into the drinking water. NetNut was one of the fatter mains, over two million hijacked smart TVs, streaming boxes and Android devices pushing attacker traffic through ordinary home broadband connections. On July 2, Google, the FBI and IRS Criminal Investigation took a wrench to it.

The interesting bit isn't the number of devices. It's how the water got dirty in the first place, and why the pipes will keep flowing for whoever plumbs in next.

The Numbers

Start with the device pool. Two million endpoints is not a fringe operation, that's serious infrastructure, and as Latest Hacking News reported, researchers tracked the network as Popa and it sold access commercially under the NetNut brand. Two ingestion paths built that pool: budget hardware that shipped with the proxy code already baked in, and free apps carrying a hidden SDK that turned installation into recruitment.

The SDK penetration figures from Spur are the ones that should give any platform engineer pause. Over 20% of Samsung Tizen apps they examined contained a residential proxy SDK. On LG webOS, that number was 42%. Not one of them properly disclosed it to the user. Anyone who has ever shipped a mobile SDK and had to negotiate a privacy policy through legal knows how far outside the lines that sits.

Then there's the demand side. Google's analysts tracked 316 distinct threat clusters using suspected NetNut exit nodes in a single week in June. Not 316 requests, 316 separate clusters of attacker activity. The dominant use case was password spraying, with content scraping, ad fraud and account takeover filling out the rental catalogue according to Krebs on Security.

The takedown itself came in two prongs. Google's Threat Intelligence Group disabled the accounts and services NetNut used for command and control. The FBI and IRS Criminal Investigation seized hundreds of domains tied to the network, with Lumen Technologies, Shadowserver and other partners providing technical support. Google then pushed detection into Play Protect so Android devices get warned about apps carrying the proxy code, and known offenders get disabled automatically.

One more figure worth sitting with: this is Google's second major residential proxy botnet disruption of the year. IPIDEA went down in January. Two large takedowns in six months tells you something about both the scale of the underlying market and the rate at which it can absorb losses.

What's Actually New

The novel bit here isn't that a botnet got dismantled. Takedowns happen. What's new is the corporate address the water main leads back to.

NetNut traces back to Alarum Technologies, a publicly traded Israeli company listed on Nasdaq. Not a shell, not a Telegram handle, an actual filing entity with public shareholders. Researchers at Qurium, Synthient, Nokia Deepfield and Spur linked the Popa botnet to NetNut through controlled testing in June. Legal counsel for Alarum told Krebs the company "takes this matter seriously and will fully cooperate with law enforcement," while the company itself has previously described its product as consented bandwidth sharing rather than a botnet.

That framing does not survive contact with the SDK numbers. If two in five webOS apps you tested carry a proxy SDK the user was never told about, "consent" is doing a lot of heavy lifting. This is the boring bit that matters: the legal fiction that consumers agreed to route someone else's password-spraying traffic through their smart TV because they clicked an EULA to watch a football stream.

The second genuinely new element is the platform-level response. Play Protect now flags apps carrying NetNut's proxy code and disables known offenders automatically. Google shared the technical fingerprints of the SDKs and backend infrastructure with platform providers, researchers and law enforcement. That's a shift from "we shut down the accounts" to "we're going to keep sniffing for the pattern at endpoint scale." From an engineering standpoint, distributing detection signatures to Play Protect turns every Android device into a sensor. That is a genuinely different posture than domain seizure alone.

The third new-ish thread is the multi-tenant nature of the compromise. Nokia Deepfield, Spur and Synthient documented Mirai DDoS variants riding on NetNut-infected hardware, and a NetNut plugin has been tied to Badbox 2.0, the Android botnet Google sued the operators of in July 2025. One malicious SDK, several parallel criminal businesses stacked on top. The commodity here isn't the botnet, it's root access to the device.

What's Priced In for Engineering Teams

Most senior engineers running fraud, auth or WAF stacks have already accepted that residential IP reputation is a broken signal. That's been priced in for a while. If you're still blocking on datacentre ASN and calling it fraud prevention, you were behind before NetNut had a name.

What's less priced in, and I think worth sitting with, is the depth of the supply chain problem. The mental model most teams carry is "malware infects device, device joins botnet." The reality here is closer to "SDK ships inside an app, app ships through an official store, TV ships from a factory with the code preinstalled." The compromise moves upstream of anything an end user or a corporate IT policy can meaningfully interdict.

For iGaming and fintech platforms, that has a specific implication. Login-attempt monitoring that leans on "diverse IP with normal residential ASN behaviour equals human" needs to keep drifting toward behavioural signals: request cadence, TLS fingerprint variance, keystroke and pointer telemetry, session graph analysis. Password spraying was the top NetNut use case for a reason, it defeats per-IP rate limiting by construction. Anyone who has watched a low-and-slow credential-stuffing wave crawl across a login endpoint at eight requests per hour per IP knows the shape.

What is surprising, and probably not priced in, is how quickly Google is willing to burn its own account infrastructure to disrupt these networks. Disabling the Google accounts NetNut used for command and control is a cheap move in isolation, but it signals that GTIG is treating this class of abuse as strategic rather than reactive. Two takedowns in one year suggests a programme, not a one-off.

Contrarian View

Here's where I'd push back on the celebratory reading. Google itself described the NetNut action as "significant degradation" of the network and its business, not a kill. That phrasing is doing important work.

Individual residential proxy providers are structurally resilient because they lean on each other. When one pool takes a hit, providers buy spare capacity from rival networks and resell it under their own brand. The market for stolen residential bandwidth is fungible in a way the market for, say, ransomware affiliate crews is not. You knock over NetNut, the demand moves to whichever brand is still standing, and the SDKs inside those two million devices don't magically uninstall themselves overnight.

The harder problem is that the economic incentive to embed proxy SDKs in free apps has not changed. The 20% Tizen and 42% webOS figures describe an entire ecosystem, not one bad actor. Until app store review processes on Tizen, webOS and the Android side of things start treating undisclosed proxy SDKs as a policy violation with teeth, the recruitment channel stays open. Consenting bandwidth sharing, as a business model, isn't going anywhere, it's just going to get slightly better lawyers.

Key Takeaways

  • Residential IP reputation is dead as a fraud signal. With SDK penetration hitting 42% in some app ecosystems, treating consumer IP ranges as inherently trustworthy is a losing bet. Shift weight to behavioural and session-graph signals.
  • The supply chain runs upstream of the device. When TVs ship pre-infected and SDKs ride inside official-store apps, endpoint security is not where this gets fixed. Platform review policies are.
  • Assume password spraying at consumer-IP scale. The most common NetNut use case defeats per-IP rate limiting by design. Rate limit on identity and behaviour, not on IP.
  • One compromised device carries multiple criminal tenants. Mirai variants and Badbox 2.0 plugins rode the same hardware. Detection needs to look for the underlying access, not the specific payload.
  • Expect the next brand within months. IPIDEA in January, NetNut in July. The plumbing survives the brand, and Google itself called this a degradation rather than a kill.

Back to the water main. You can shut off one supplier, but if two in five taps in the city are quietly plumbed into the same underground network, the leak is a civic problem, not a plumbing one. NetNut is off the map. The pipes are still there.

Frequently Asked Questions

Q: What is a residential proxy botnet and why is it dangerous?

It's a network of consumer devices, phones, smart TVs, streaming boxes, whose internet connections are used to route someone else's traffic without meaningful user consent. It's dangerous because attacker traffic appears to come from ordinary home IP addresses, defeating fraud systems that rely on IP reputation to spot bots, VPNs or datacentre traffic.

Q: How did NetNut get onto two million devices?

Two routes. Some budget smart TVs and streaming boxes shipped from the factory with the proxy code already installed. Others picked it up when users installed free apps that bundled a hidden SDK, with Spur finding the pattern in over 20% of Samsung Tizen apps and 42% of LG webOS apps they examined, none properly disclosed.

Q: Will the NetNut takedown actually stop residential proxy abuse?

Probably not for long. Google itself described the action as "significant degradation" rather than a kill, and individual proxy providers routinely buy spare capacity from rivals when their own pool takes a hit. It's the second such takedown in 2025 after IPIDEA in January, and the underlying SDK supply chain has not been fixed.

JO
James O'Brien
RiverCore Analyst · Dublin, Ireland
SHARE
// RELATED ARTICLES
HomeSolutionsWorkAboutContact
News06
Dublin, Ireland · EUGMT+1
LinkedIn
🇬🇧EN▾