UPnP Port-Forward Abuse

UPnP — Universal Plug and Play — is a convenience feature built into almost every home router. It lets a device on your network ask the router, all on its own, to open an inbound port from the public internet straight through to itself. A game console uses it so your friends can join your match; it saves you from setting up port forwards by hand.

The catch is that the router grants these requests to anyone on the LAN, with no password and no confirmation. So can malware. A single infected laptop can quietly ask the router to open a door from the whole internet to a machine inside your house — and the router just says yes.

One device asked the router for a door to the internet. The router didn’t ask why.

The attacker doesn’t need to be near your network — they need one foothold on it, usually malware already running on a PC. From there, opening a public door is a single request to the router’s UPnP gateway (its Internet Gateway Device). Tools like miniupnpc do it in one line:

# malware on the LAN asks the router to open a public door — no password required
upnpc -a 192.168.1.50 3389 3389 TCP
# result: the internet can now reach 192.168.1.50:3389 (Remote Desktop)

With that one mapping, Remote Desktop (3389), file sharing/SMB (445), SSH (22) or WinRM (5985) is suddenly reachable from anywhere on the planet. The attacker then simply connects to your public IP and walks in. Because nothing is spoofed — no forged ARP, no poisoned DNS, no rerouted traffic — this is invisible to every ARP, DNS and traffic detector. It hides in a feature working exactly as designed. It’s a quiet cousin of the rogue device problem: the danger isn’t new hardware, it’s a new door.

WifiThreatWatch asks the router the same question a technician would: what port forwards are you currently advertising? It reads the router’s own UPnP port-map table — the exact list a upnpc -l would print — and flags any enabled mapping that exposes a sensitive service port to the WAN: 445/139/135 (SMB), 3389 (RDP), 22/23 (SSH/Telnet), 5985/5986 (WinRM) or 5900 (VNC).

This is deliberately false-positive-safe. Legitimate UPnP users — game consoles, Tailscale, Plex — map high and ephemeral ports that never match the sensitive set. If your router has no IGD, or UPnP is switched off, there’s simply nothing to read and nothing to flag. You can run the same audit yourself in PowerShell:

# ask the router's UPnP gateway for every port-forward it is advertising
$nat = New-Object -ComObject HNetCfg.NATUPnP
$nat.StaticPortMappingCollection | ForEach-Object {
  '{0}  ->  {1}:{2}  ({3})' -f $_.ExternalPort, $_.InternalClient, $_.InternalPort, $_.Protocol
}
# if it returns nothing, UPnP is off or the router has no IGD — good.

Detection tells you exactly what’s wrong: which internal device the door leads to, which service port is exposed, and whether the mapping is live right now. That’s enough to act — delete the forward from your router’s UPnP / port-forwarding page, then find out what on that machine asked for it in the first place.

The durable fix is to turn UPnP off on your router unless you specifically need it, and to forward ports by hand for the rare service that truly requires one. Honest caveat: our tunnel can’t close a door the router opened — this is a router-configuration problem, and the win is seeing the door before an attacker uses it, then shutting it.