Non-Standard Port (T1571) is a command and control technique. The adversary talks over a protocol and port pairing that normally do not go together. MITRE gives two examples: HTTPS over port 8088, or over port 587, instead of the usual 443. It applies to ESXi, Linux, macOS and Windows.
The idea is simple. A filter that only knows "web traffic goes to 80 and 443" can miss web traffic on port 8088. A parser that expects mail on 587 may choke on something else riding there.
How attackers use it
MITRE describes two angles.
First, the adversary changes the port a protocol uses so the traffic bypasses filtering or muddles analysis and parsing of network data. The protocol is real. The port is not where defenders expect it.
Second, the adversary changes the victim system itself to abuse non-standard ports. MITRE notes that Registry keys and other configuration settings can be used to modify protocol and port pairings. So the change can live on the host, not just in the malware.
How to detect it
MITRE's detection strategy for this technique is built around the relationship between a process and its connections. The analytics describe:
- Processes initiating outbound connections on uncommon ports, or using a protocol that does not match the assigned port. Correlating process creation with the network connection that follows is what reveals it. MITRE's example is svchost.exe or an Office application using a high, atypical port.
- On Linux, unusual daemons or user processes listening on ports outside standard ranges, or making client connections with mismatched protocol and port pairs.
- On macOS, applications connecting out on non-standard ports, or launchd services bound to ports that do not fit the system baseline.
- On ESXi, VM services or management daemons talking on ports that are not VMware defaults, such as vpxa or hostd starting traffic on high-numbered or unexpected ports.
The practical takeaway: you need process-level network telemetry (which executable opened the socket), not just firewall logs. Firewall logs tell you a port was used. Endpoint telemetry tells you who used it.
How to reduce the risk
MITRE lists two mitigations.
- Network segmentation. Configure firewalls and proxies so outgoing traffic is limited to the ports that segment actually needs. A server segment that only needs 443 to a patch mirror should not be able to reach arbitrary high ports on the internet.
- Network intrusion prevention. Use signature-based detection and prevention to identify traffic for specific adversary malware at the network level.
Default-deny egress is the single control that makes this technique expensive. If only approved ports leave the segment, a port change by the attacker simply fails.
Check your own environment
Read-only checks to see what is talking where:
# Linux: established connections with owning process
ss -tupn state established
# macOS: network connections with process names
lsof -i -P -n | grep ESTABLISHED
# Windows PowerShell: established connections and the owning process id
Get-NetTCPConnection -State Established | Select-Object LocalPort,RemoteAddress,RemotePort,OwningProcess
Then ask:
- Which processes hold connections to remote ports other than the ones you expect for their role?
- Does any server segment allow outbound traffic on every port?
- Do you log process-to-network relationships on endpoints, or only at the perimeter?
Quick check
Why is a firewall log alone weak evidence for this technique?
It shows the port, but not which process opened the connection. MITRE's analytics rely on correlating process creation with the outbound connection that follows.
Which mitigation limits the damage even if you never spot the traffic?
Network segmentation with egress limited to only the ports a segment needs, so a protocol moved to an odd port is simply blocked.
