Detect it by watching for netsh interface portproxy changes and then confirming whether the new listener forwards to an internal or remote address. Correlate that with command-line activity, unexpected listening ports, and outbound connections from the host. Alert when port forwarding appears on servers or workstations that do not normally act as relays.
What to look for in netsh portproxy abuse
Windows port forwarding with netsh interface portproxy is usually visible as a configuration change plus a new listener on the host. The useful detection question is not just “was netsh run?” but “did the host start accepting traffic on a port it normally should not expose, and is that traffic being relayed to another system?” That distinction separates benign admin work from pivoting.
Focus on the portproxy state itself, because the forwarding rule is the durable indicator. A change that maps a local listener to an internal server, another workstation, or a remote host can turn an ordinary Windows machine into an ad hoc relay point. That is especially suspicious when the target is inside a private range or when the source system is not designed to broker connections.
Correlate the portproxy entry with process creation and network activity. A legitimate change should line up with an administrative workflow, while pivoting often shows a short chain of command-line use, a new listener, and outbound connections that do not match the host’s normal role. On Windows estates, pair this with a solid Windows Event Log Guide baseline so you can tie the rule change to the account, session, and timing that created it.
Why portproxy forwarding is a pivoting signal
Port forwarding is useful to attackers because it lets them bridge network segments without deploying a full toolset on every hop. Once the host forwards traffic, it can hide the real destination behind a normal-looking local port, making lateral access appear to terminate on the intermediate machine. That is why the control surface matters: the listener, the destination, and the traffic pattern together reveal whether the host is acting as a relay.
The strongest indicator is context. A server that suddenly forwards traffic may be doing a maintenance task, but a workstation or user endpoint almost never should. If the new listener points to an internal service that the host would not normally reach, or if the destination changes during an incident, treat the rule as a likely pivot path rather than a convenience setting. For broader lateral-movement patterns that often accompany this behavior, NHIMG’s Lateral Movement Guide is a useful companion reference.
Remote connections matter too. Portproxy forwarding can be used to bounce traffic toward a second stage, a management interface, or a previously inaccessible network zone. That is why outbound sessions from the relay host deserve the same attention as the listening port itself. If the host begins talking to systems it normally never contacts, the forwarding rule is part of the access path, not just a configuration artifact.
Practical detection workflow for defenders
Start with configuration telemetry, then verify behavior. In practice that means identifying netsh interface portproxy additions, deletions, and edits, then checking whether the host now has an unexpected open port that accepts remote connections. The next step is to inspect the destination address, because the forwarding rule is only meaningful once you know where the traffic is going.
Process and command-line visibility should support the same conclusion. A suspicious change often appears alongside an administrative shell, remote management session, or scripted execution that created the rule and then disappeared. If you have Sysmon, it is especially helpful for linking process creation and network connection telemetry, and for showing whether the host started forwarding traffic immediately after the command ran. The Sysmon Guide provides the event and filtering context needed to tune that view.
Network analytics should then answer whether the listener behaves like a relay. Watch for inbound connections to the forwarded port followed by outbound connections from the same host to an internal or external destination that matches the portproxy mapping. If you see that pattern on systems that should not broker traffic, especially in conjunction with unusual remote access or other post-compromise activity, escalate quickly. For command-and-control style egress patterns that can overlap with pivoting and relay abuse, the Command and Control (C2) Guide can help shape your hunt logic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1090 — Proxy | Port forwarding through an intermediate host is a proxy/pivot pattern. |
| T1021 — Remote Services | Portproxy pivoting often supports remote access to internal services over relayed paths. | |
| T1049 — System Network Connections Discovery | Detecting pivoting relies on observing the host's inbound and outbound network relationships. | |
| Recommendation — Map the listener and relay behavior to T1090 and hunt for intermediary hosts bridging traffic. Correlate the forwarded port with remote-service access patterns and unusual internal reachability. Review host network connections to identify unexpected relay destinations and traffic paths. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on retaining command, event, and network telemetry for the portproxy change. |
| Recommendation — Centralize and retain logs needed to reconstruct the portproxy change and resulting traffic. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Investigating portproxy pivoting requires review and correlation of audit evidence. |
| Recommendation — Correlate process, configuration, and network telemetry to validate suspicious forwarding activity. | ||
Practitioner Guidance
What to verify: Confirm both the rule and the runtime effect. A lone command-line event is weaker evidence than a persistent forwarding entry plus matching inbound and outbound traffic on the same host.
Decision rule: If the host is not meant to act as a relay, treat any new portproxy mapping as suspicious until you can explain the business purpose and the destination system.
Common mistake: Teams often alert on the command alone and miss the forwarded traffic that proves pivoting, or they see the listening port and never inspect the target address.
Practitioner takeaway: The decisive evidence is the combination of configuration change, unexpected listener, and relay-like network behavior, because netsh port forwarding becomes a pivot only when the host is actually brokering traffic.