FBI Seizes NetNut: When 'Residential Proxies' Are Just Botnets in Disguise
Just caught the breaking news regarding the FBI seizing NetNut and the associated Popa botnet. It’s fascinating—and a bit terrifying—that a residential proxy service operated by a publicly-traded firm (Alarum Technologies) was allegedly sitting on top of a 2-million-device botnet.
This highlights a massive blind spot for many of us. We often allow 'residential' IP ranges because we don't want to block legitimate remote users or VPNs, but this case proves that 'residential' traffic is often the preferred vector for sophisticated obfuscation. The Popa botnet wasn't just for DDoS; it was likely selling 'clean' IP access to the highest bidder to bypass fraud detection.
If you want to verify if these seized domains are now sinkholed (and potentially check historical hits in your logs), you can run this quick check:
dig netnut.io +short
You should see the sinkhole IP rather than their original infrastructure. For those with SIEM access, I recommend hunting for any historical connections to these domains or their known subnets over the last 90 days:
DeviceNetworkEvents
| where RemoteUrl has "netnut" or RemoteUrl contains "alarum"
| summarize Count=count() by DeviceName, RemoteUrl
| order by Count desc
Given the scale of the Popa botnet, I suspect a lot of 'low and slow' brute force or credential stuffing attempts in our logs are actually coming from these 'legitimate' proxies.
Discussion: How is everyone handling residential proxy traffic in 2026? Are you flat-out blocking known commercial proxy providers (NetNut, Luminati, etc.), or are you relying purely on behavioral analysis to catch the abuse?
Blocking them outright is becoming a necessity for us. We tried the behavioral approach last year, but the noise was too high. We maintain a dynamic blocklist of known data center and residential proxy exit nodes. It broke a few marketing scrapers internally, but security-wise, it dropped our credential stuffing attempts significantly. It's a pain to manage, but better than explaining a breach.
From a pentester's perspective, this is a double-edged sword. We use residential proxies to simulate realistic user traffic during authorization testing without getting WAF-banned instantly. However, seeing how Popa was essentially malware repurposed as a service is wild. If you're looking for internal IoCs, check your firewall logs for high connection counts to non-standard ports from consumer ISP blocks—that was a signature of the older Popa variants.
The sinkhole response is interesting. I just checked, and the domains are indeed resolving to the FBI sinkhole IP. I've pushed a quick Python script to our fleet to check for any lingering processes trying to reach the old IPs, just in case we have infected IoT devices phoning home.
import socket
# Example check for known bad IP segments
bad_ranges = ['192.0.2.0/24']
# ... scanning logic ...
Since the domains are sinkholed, it’s the perfect time to hunt for infected internal nodes. We’re pivoting our egress monitoring to flag connections to the sinkhole IPs immediately. For those using Azure Monitor or Sentinel, this quick KQL query helps identify potential compromise sources:
kusto
CommonSecurityLog
| where DestinationIP in ("", "")
| summarize count() by SourceIP, DeviceAction
Catching this egress traffic is often faster than waiting for IDS signatures to update.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access