Google Disrupts NetNut: Analyzing the 'Popa' Residential Proxy Takedown
Google Disrupts NetNut: Analyzing the 'Popa' Residential Proxy Takedown
Just saw the report on Google's Threat Intelligence Group (GTIG) disrupting NetNut (tracked as Popa). It’s wild to think they managed to degrade a network spanning 2 million home devices. Collaborating with the FBI and Lumen, GTIG reportedly slashed the usable pool of compromised relays significantly.
From a blue-team perspective, these residential proxy networks are insidious because they use legitimate home IP addresses, bypassing standard geofencing and reputation blocks. The disruption is great, but I'm curious about the detection logic used. NetNut/Popa often targets unpatched IoT or SOHO routers.
If you are scanning your network for signs of compromise (IOC), look for high outbound connection counts on non-standard ports or persistent SSH tunnels to unknown IPs.
Here’s a quick KQL query to hunt for devices acting as potential relays (high egress connections):
DeviceNetworkEvents
| where ActionType == "ConnectionInitiated"
| where RemotePort in (1080, 8080, 3128, 443) // Common proxy ports
| summarize Count = count() by DeviceName, RemoteIP, bin(Timestamp, 1h)
| where Count > 5000 // Threshold tuning required
| project-away Count
Also, check your firewall logs for devices reaching out to known NetNut infrastructure IPs (check your threat intel feeds).
Has anyone seen a drop in "unknown" traffic volume over the last 24 hours that might correlate with this takedown? Or are we just seeing the traffic shift to alternative proxy providers?
That KQL query is a good start, but 5000 might be too high depending on your environment. We see legit Windows update servers or backend services spiking that high. We prefer adding a filter for InitiatingProcess being 'unknown' or checking for processes running from C:\Users\Public or /tmp to catch the binaries typically used by these proxy agents.
Pentester here. The disruption actually made a noticeable difference in our OSINT automation yesterday—latency on residential IPs shot up. These networks are notoriously hard to attribute because they piggyback on standard protocols. We usually recommend checking HTTP headers for Via or X-Forwarded-For anomalies on your ingress traffic to see if attackers are still using similar nets against you.
I manage a large MSP network. The biggest pain point isn't detecting the proxy; it's the firmware on the routers. Most of these 'Popa' infections rely on unpatched SOHO routers. We've started forcing remote management to be disabled via scripts during onboarding to reduce the attack surface.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access