The 'Popa' Botnet Supply Chain: Tracing Android TV Proxies to NASDAQ:ALAR
Just caught the KrebsOnSecurity report regarding the 'Popa' botnet, and it’s a textbook example of how 'residential proxy' services operate in a legal gray area. Researchers have linked four years of malicious traffic relayed through millions of Android TV boxes back to NetNut, operated by Alarum Technologies (NASDAQ: ALAR).
While the business side is shocking, the technical angle involves these cheap TV boxes running outdated Android versions (often Android 7/8/9) riddled with unpatched vulnerabilities like CVE-2019-9435 (framework). Once infected, the devices churn traffic for ad fraud and credential stuffing.
If you're managing IoT or guest networks, you might want to hunt for devices engaging in high-volume proxy behavior. Since these devices often leave ADB open or use specific payload structures, you can use this simple Python snippet to check for known malicious package signatures found on the compromised boxes:
import subprocess
# Check for suspicious processes often associated with Popa/Android proxy trojans
def check_proxy_processes():
try:
# Assumes ADB access or shell environment on the device
result = subprocess.run(['pm', 'list', 'packages'], capture_output=True, text=True)
packages = result.stdout
suspicious = ['com.system.update', 'com.android.rock', 'com.silent.service']
found = [pkg for pkg in suspicious if pkg in packages]
return found
except Exception as e:
return str(e)
print(f"Suspicious packages found: {check_proxy_processes()}")
From a defensive perspective, detecting the *traffic* is tricky because it looks like legitimate residential ISP traffic. However, you can correlate high-frequency connection attempts from Consumer-grade ISPs hitting your auth endpoints using this KQL snippet:
SigninLogs
| extend ISP = tostring(parse_(DeviceDetail).trustProviderType)
| where Result == "Failure"
| summarize Count = count() by IPAddress, ISP
| where Count > 50 and ISP contains "Consumer"
How is everyone handling the reputational risk of 'residential proxies' in their allowlists? Are you blocking all datacenter IPs, or have you started geo-blocking entire consumer ASN ranges linked to these TV box manufacturers?
It's a nightmare for e-commerce fraud prevention. We use a residential proxy provider for our own QA testing to simulate real users, and the line between 'legit' proxy services and botnets like Popa is vanishing. We've started relying more on device fingerprinting (Canvas/WebGL) rather than just IP reputation. If the request is coming from an Android TV box but the User-Agent claims to be a Windows Chrome browser, we block it immediately.
From a blue team perspective, the KQL query is solid, but I'd add a check for time-based anomalies. These TV boxes often churn traffic at weird hours when the 'owner' is likely asleep. We implemented a rule that flags 'residential' IPs making more than 100 requests per minute between 1 AM and 5 AM local time. It caught a bunch of these relay nodes almost instantly.
We manage a few small hospitality clients, and these cheap TV boxes are everywhere in hotel lobbies and executive lounges. I ran a scan on a client's subnet after reading this and found three devices with open ADB ports (port 5555). We've blocked inbound/outbound traffic on port 5555 at the firewall level for now. It’s a band-aid, but it stops the C2 servers from pushing new payloads.
Segmentation is the only real fix here since patching cheap Android boxes is rarely an option. We force these devices into a dedicated IoT VLAN that only allows outbound traffic on necessary ports like 80/443, blocking the high-numbered ports often used by proxy trojans. If you're using OpenWrt or a similar edge router, this rule helps contain potential C2 traffic:
iptables -A FORWARD -i br-iot -o eth0 -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -i br-iot -o eth0 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i br-iot -o eth0 -j DROP
Does anyone else enforce strict egress filtering on their media devices?
Excellent point on segmentation, Mei. If isolation isn't immediately feasible, monitoring for high-entropy traffic to specific residential proxy IPs is a solid stopgap. You can often identify the proxy agents by checking for connections to known NetNut ASN ranges. If you have access to raw logs, this quick grep helps identify potential compromised endpoints communicating with the proxy infrastructure:
grep -E "NetNut|alarum" /var/log/nginx/access.log
It won't catch everything if they rotate fast, but it provides immediate triage evidence.
From an attribution perspective, checking the ASN ownership often exposes the proxy operator behind the 'residential' mask. You can trace the outbound IP blocks to see if they belong to Alarum Technologies or NetNut.
whois -h whois.cymru.com
Team Cymru is great for this. If the IP belongs to a known hosting provider rather than a local ISP, you've likely found the proxy exit node.
ZeroDayHunter is right; these devices are ticking time bombs. Since they often have ADB exposed, I recommend scanning your subnets to identify open debugging ports before attackers do. This is crucial to prevent lateral movement toward your backup servers or NAS.
nmap -p 5555 --open 192.168.1.0/24
Great discussion on the network side. Don't forget to check the host level; many of these boxes run the proxy binary with root privileges, often masquerading as a system service. If you have shell access, check for unusual processes listening on non-standard ports using netstat:
netstat -tulpn | grep LISTEN
Identifying the parent process usually reveals the hidden APK responsible for the persistence mechanism.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access