Popa Botnet & NetNut: When Residential Proxies Go Rogue
Just finished reading the KrebsOnSecurity deep dive into the Popa botnet. The alleged connection to NetNut (Alarum Technologies) is absolutely wild. For four years, millions of Android TV boxes have been hijacked to facilitate ad fraud and account takeovers, all under the guise of 'residential proxy' services.
It highlights a massive blind spot in many networks: IoT segmentation. These aren't sophisticated zero-days; they often leverage misconfigurations or older Android vulnerabilities on cheap consumer hardware. Once compromised, the device acts as a relay, masking malicious traffic as legitimate residential user activity.
From a detection standpoint, identifying a compromised TV box behind a NAT is tricky. However, the volume of traffic is usually a dead giveaway. A TV shouldn't be making thousands of outbound connections per hour to random endpoints on port 80/443.
Here is a basic KQL query I’m testing to flag high-egress devices that might be acting as proxies:
DeviceNetworkEvents
| where ActionType == "ConnectionAllowed"
| where OSType == "Android"
| summarize TotalConnections=count(), DistinctIPs=dcount(RemoteIP) by DeviceName, bin(Timestamp, 1h)
| where TotalConnections > 2000 or DistinctIPs > 500
| project-away TotalConnections, DistinctIPs
Has anyone else started blocking residential proxy CIDR ranges (like those associated with NetNut) at their perimeter? I'm worried about false positives, but the risk of credential stuffing coming from 'clean' IPs seems to be outweighing that.
Blocking residential proxy ranges is a game of whack-a-mole, but necessary for high-value login endpoints. We've had success using IPQualityScore and similar APIs in our auth pipeline to flag 'hosting' or 'proxy' traffic that resolves to an ISP ASN but behaves like a server.
Also, check your firewall logs for consistent TTLs or keep-alives. Residential proxies often use keep-alive to maintain the tunnel, which looks different from standard video streaming traffic.
This reinforces why we put every 'non-corporate' device into a dedicated 'IoT VLAN' that can only talk to the internet via DNS (filtered) and HTTP/HTTPS, but cannot talk to the internal LAN.
If a TV box gets pwned, it becomes an exit node, but it stays inside its sandbox. The pain point is when executives bring these smart devices in and demand they work with Chromecast/AirPlay without configuring VLANs correctly.
From a pentester's perspective, these residential proxy networks are a nightmare for blue teams. When we run external brute-force campaigns, traffic originating from NetNut or similar providers bypasses standard GEO-blocking and 'bad IP' reputation lists because they look like legitimate home users.
If you aren't doing behavioral analysis on user login patterns (e.g., impossible travel velocity, user-agent consistency), this traffic will look completely valid to your logs.
Solid points on VLAN isolation. Even with segmentation, we need better visibility into what these "dumb" devices are actually doing. I recommend hunting for anomalies in outbound traffic from specific user agents. A quick query against your firewall or proxy logs can reveal if a device is phoning home to non-standard ports, signaling proxy activity.
DeviceNetworkEvents
| where ActionType == "ConnectionAccepted"
| where RemotePort !in (80, 443)
| where DeviceOS contains "Android" and DeviceOS contains "TV"
| summarize count() by DeviceId, RemoteIP
Has anyone correlated this traffic against the specific NetNut IP ranges yet?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access