T1571 Non-Standard Port: Detection and Defence

A firewall rule that says "allow TCP 8080" says nothing about what actually crosses that port, and attackers rely on that gap. MITRE ATT&CK tracks the behaviour as T1571 Non-Standard Port: adversaries pair a protocol with a port it is not normally associated with, such as HTTPS over 8088 or 587 instead of 443, to slip past filtering or to confuse parsers that decide what a flow is from its port number. This guide is about the one thing that makes T1571 detectable: the mismatch between the port, the protocol really spoken and the process that opened the connection. It covers which telemetry exposes that mismatch, how to tune it, how to shrink the opportunity with egress design, and how to respond to a hit. It is written for detection engineers, SOC analysts and network architects. For C2 as a whole, read the Command and Control (C2) Guide first; this page goes deeper on one technique and does not repeat it.

Key takeaways

The signal is the mismatch, not the number. A high port is not malicious on its own; TLS on 8000, HTTP on 995 or SSH on 6789 is worth a look because the protocol and the port disagree.
Port-independent protocol identification is the core control. Zeek records confirmed protocols per connection and Suricata's pattern-based detection works on any port, so both can flag a protocol on the wrong port.
Attach a process to every connection. ATT&CK v20's analytics for T1571 look for processes such as svchost.exe or Office applications using atypical ports, which needs host telemetry such as Sysmon Event ID 3 (off by default).
Default-deny egress removes most of the room. ATT&CK's mitigation M1030 is to allow outbound traffic only on the ports each segment needs, which turns a quiet bypass into a blocked, logged attempt.
Do not forget ESXi and network devices. T1571 lists ESXi as a platform and its procedure examples include ESXi backdoors and router botnets, where EDR is usually absent.

How T1571 works and where it fits

ATT&CK v20 describes T1571 as communicating with a protocol and port pairing that is not typically associated with that protocol. It covers two cases: the adversary simply runs its channel on an unexpected port, or it changes the victim system's configuration (for example through registry keys or service settings) so that a legitimate protocol listens or connects on a different port. T1571 has no sub-techniques and applies to ESXi, Linux, macOS and Windows.

T1571 is rarely seen alone. The protocol being moved is usually covered by another technique, and the port change is the evasion layer on top.

Pattern	What is on the wire	Related technique	Examples ATT&CK v20 records under T1571
Web protocol on an unusual port	HTTP or HTTPS on a high or unrelated port	T1071.001 Web Protocols	Emotet using HTTP over ports including 7080 and 50000; njRAT using HTTP on 1177; RedLeaves using HTTP on 995; WIRTE using HTTPS on 2083 and 2087
Custom or fake protocol on a well-known port	Non-TLS bytes on 443, or a protocol that only looks like TLS	T1095 Non-Application Layer Protocol; T1001.003 Protocol or Service Impersonation	HOPLIGHT, HARDRAIN and TYPEFRAME using FakeTLS; Derusbi sending unencrypted HTTP over 443; WellMail using port 25 without SMTP
Remote access service moved	RDP or SSH on a non-default port	T1021 Remote Services; T1133 External Remote Services	Campaign C0018 using RDP on ports such as 28035 and 32467; Sandworm Team running an SSH server on 6789
Random or rotating high ports	Listeners or relays on ports chosen per host	T1090 Proxy; T1665 Hide Infrastructure	KV Botnet activity using a random port above 30,000; PlugX using random high ports; Quad7 activity on ports including 7777 and 11288
Virtualisation backdoors	Listeners on ESXi hosts	T1675 ESXi Administration Command	VIRTUALPITA listening on ports including 2233 and 7475; VIRTUALPIE on 546

The port numbers above are taken from the ATT&CK T1571 page as of November 2026 and are illustrations, not indicators to block: ports are trivial to change. See the MITRE ATT&CK T1071 Application Layer Protocol, MITRE ATT&CK T1095 Non-Application Layer Protocol and T1090 Proxy Defensive Guide for the protocols themselves.

Three kinds of mismatch to detect

Every useful T1571 analytic is a comparison between two things that should agree. Thinking in these three pairs keeps the detection logic small and explainable.

Port versus protocol

The flow is on a port registered for one service but carries another, or carries a recognisable protocol on a port with no expected service. Examples: TLS handshakes on 8000, HTTP requests on 995, SSH banners on a high port, or bytes on 443 that no TLS parser accepts. This needs a sensor that identifies protocols by content rather than by port.

Process versus port

The protocol may be ordinary, but the process making the connection has no reason to use that port. ATT&CK v20's Windows analytic gives svchost.exe or Office applications connecting out on high, atypical ports as examples. On macOS it points to launchd services bound to ports that differ from the system baseline, and on Linux to daemons or user processes listening outside standard ranges.

Host versus baseline

The host or segment has a known set of outbound ports, and a new one appears. A database server that suddenly talks out on 4444, or an ESXi host whose vpxa or hostd processes initiate traffic on unexpected ports (ATT&CK's ESXi analytic), is anomalous for that asset even if the same port is normal elsewhere.

Telemetry that exposes the mismatch

Source	What it gives you for T1571	Fields to keep	Limits
Zeek conn.log	The `service` field is a comma-separated list of confirmed protocols for the connection, independent of the port; the optional `failed_service` field lists analysers removed for protocol violations	id.resp_p, proto, service, failed_service, conn_state, history, duration, orig_bytes, resp_bytes	Encrypted payloads still show as TLS or SSH; content beyond the handshake is opaque. `failed_service` needs its policy script loaded
Suricata app-layer detection	Pattern-based protocol detection is port independent; the `app-layer-protocol` keyword matches the detected protocol, including `failed` when detection did not succeed	app_proto, dest_port, flow events such as applayer_mismatch_protocol_both_directions	Probing parsers only run on the ports listed in `detection-ports`, so some protocols need those lists reviewed
Sysmon Event ID 3 (Windows)	Links each TCP or UDP connection to a process through ProcessId and ProcessGuid, with source and destination addresses and ports	Image, ProcessGuid, User, DestinationIp, DestinationPort, Protocol	Disabled by default; needs a configuration that includes the processes and ports you care about
EDR network events	Process-to-connection mapping on Windows, Linux and macOS, often with parent process and signature status	Process path, signer, parent, remote port, first-seen date	Coverage gaps on ESXi, appliances and unmanaged hosts
Firewall and flow logs	Every allowed and denied outbound port per source, the cheapest baseline	Source, destination, destination port, action, bytes, rule ID	No protocol identity and no process; good for baselines and blocked attempts
ESXi and network device logs	Listening sockets, firewall ruleset changes and configuration changes on hosts that cannot run an agent	Service, port, user, change time	Needs log forwarding configured and retained

For deployment detail see the Zeek Network Monitoring Guide, Suricata IDS Guide, NetFlow and IPFIX Flow Telemetry Guide and ESXi Logs Detection Guide.

Detection analytics

The analytics below are expressed as logic, not product queries, so they translate to any SIEM. Each one names the mismatch it relies on.

Analytic	Mismatch	Logic	Tuning
Well-known protocol on an unexpected port	Port versus protocol	Sensor-confirmed HTTP, TLS, SSH, RDP or SMB where the destination port is not in your approved list for that protocol	Build the approved list per protocol from a 30-day baseline; review new entries weekly
Unparseable traffic on a standard port	Port versus protocol	Outbound 443 or 80 sessions with no confirmed service, a failed analyser or Suricata `app-layer-protocol:failed`	Exclude QUIC on UDP 443 and known proprietary update clients by destination, not by port
System or Office process on a high port	Process versus port	Sysmon 3 or EDR connections from svchost.exe, Office binaries, script hosts or rundll32.exe to external ports outside the approved set	Allowlist by signed image plus destination, never by port alone
New outbound port for a server	Host versus baseline	First time in 30 days that a server, ESXi host or appliance connects to an external address on a given port	Rank by asset criticality and rarity across the estate
New listener outside expected ranges	Host versus baseline	A daemon, launchd service or ESXi service binding a port not in the host's baseline	Feed change tickets in so approved changes are suppressed
Port configuration changed on the host	Host versus baseline	Registry or configuration changes that move a service's port, for example the RDP listening port or sshd Port setting	Alert on change outside a change window

T1571 overlaps strongly with beaconing: a connection that is periodic and on a mismatched port is far more interesting than either signal alone. Combine scores rather than alerting on each. The Beaconing and C2 Detection Guide covers interval scoring.

Prevention: shrinking the space to hide in

ATT&CK v20 lists two mitigations for T1571: M1031 Network Intrusion Prevention (signatures for specific malware traffic) and M1030 Network Segmentation (configure firewalls and proxies to allow outgoing traffic only on the ports each segment needs). The second does most of the work.

Default-deny egress per segment: servers, OT, management and user networks each get an explicit outbound port list. Anything else is denied and logged. See the Cloud Egress Filtering guide and the Network Segmentation Guide.
Force web traffic through the proxy: when user devices can reach the internet only through an explicit proxy on fixed ports, a direct connection to 8443 or 2083 fails rather than succeeds quietly.
Enforce protocol, not port, at the boundary: where the firewall or proxy can identify applications, write rules as "TLS to these destinations" rather than "TCP 443", so non-TLS bytes on 443 are dropped.
Keep remote access on governed paths: moving RDP or SSH to a high port does not make them safe; put them behind a VPN, bastion or remote access gateway instead. See the Network Ports and Protocols Security Guide.
Restrict host firewalls on ESXi and appliances: limit which services may listen and which addresses may reach them. See the VMware ESXi Hardening Guide.

Choosing an approach

Situation	Start with	Why
Small organisation, no network sensors	Default-deny egress on the edge firewall plus firewall log review	Lowest cost; turns T1571 into denied connections you can see
Mid-size, EDR deployed	Process-versus-port analytics from EDR or Sysmon, then egress lists for servers	Uses telemetry you already pay for and finds the process to contain
Large estate with NDR or Zeek and Suricata	Port-versus-protocol analytics at internet and data centre boundaries, joined to EDR	Covers unmanaged hosts, ESXi and appliances that have no agent
OT and other locked-down segments	Strict allowlists and passive monitoring; alert on any new port	Baselines are stable, so any deviation is meaningful

Rolling it out

Inventory the egress you have. Export 30 days of firewall and flow logs and list outbound destination ports by segment. This is the baseline and usually surprises people.
Turn on the host telemetry. Enable Sysmon Event ID 3 or the EDR equivalent with a configuration that keeps external connections, and confirm ESXi and network device logs reach the SIEM.
Run the mismatch analytics in alert-only mode. Start with "well-known protocol on an unexpected port" and "system process on a high port". Tune for two to four weeks, documenting every allowlist entry with an owner.
Write per-segment egress lists. Begin with servers and management networks, where needs are narrow. Apply them first as log-only rules, review the hits, then switch to deny.
Enforce in rings. Pilot deny rules on one segment, keep the previous rule set ready, and roll back by re-enabling it if a business service breaks. Move on once the pilot is quiet for two weeks.
Test. Run an authorised exercise that sends benign HTTP and TLS over unusual ports from a test host and confirm each analytic fires and each deny rule logs.

The timings in this list are NHI Mgmt Group recommendations; adjust them to your change process.

Responding to a T1571 alert

Identify the process. Join the network event to EDR or Sysmon data to find the image, its signer, parent and user. A connection with no process attribution (ESXi, appliance) moves straight to host log review.
Classify the mismatch. Is it a sanctioned application on a vendor's documented port, a misconfiguration, or something unexplained? Check change records and the software inventory.
Look wider. Search for the same destination, port and certificate across all hosts, and for the same process hash. One host is an incident; many hosts may be a deployment nobody told you about.
Contain. Block the destination and port at the boundary, isolate the host if the process is unknown, and preserve memory and the binary before reimaging.
Check identity exposure. If the process ran as a service account or the host holds stored credentials, rotate them. See the Command and Control (C2) Guide for the wider response.
Close the gap. Add or tighten the egress rule that would have stopped the connection, and record the case in your detection tuning notes.

Where identity fits

Non-standard ports matter for non-human identities in two ways. First, many implants on servers run as service accounts or under system identities, so a mismatched connection from a service host is a prompt to review what that identity can reach and to rotate its secrets if the host is compromised. Second, legitimate automation (backup agents, monitoring collectors, CI runners) often uses vendor-specific ports; give each a named owner and a documented port list so the allowlist reflects real workloads and an unexpected port from that workload stands out.

Detection and measurement

Egress coverage: percentage of network segments with a default-deny outbound port list enforced.
Attribution rate: percentage of outbound connections to the internet that can be tied to a process.
Protocol identification rate: percentage of outbound sessions with a confirmed protocol in Zeek or Suricata; a falling rate means blind spots or more custom traffic.
Allowlist hygiene: percentage of allowlist entries with an owner and a review date inside 12 months.
Test pass rate: percentage of quarterly mismatch tests that alerted within your target time.

Framework mapping

Framework	Reference	Relevance
ATT&CK v20 mitigations	M1030 Network Segmentation; M1031 Network Intrusion Prevention	Per-segment outbound port lists and malware traffic signatures (the two mitigations ATT&CK maps to T1571)
MITRE D3FEND	D3-OTF Outbound Traffic Filtering; D3-PMAD Protocol Metadata Anomaly Detection; D3-CSPP Client-server Payload Profiling; D3-NTCD Network Traffic Community Deviation	Default-deny egress, outliers in protocol metadata, payload profiles that do not fit the service, hosts behaving unlike their peers
NIST SP 800-53 Rev. 5	SC-7 Boundary Protection; AC-4 Information Flow Enforcement; CM-7 Least Functionality; SI-4(4) Inbound and Outbound Communications Traffic	Boundary rules, flow enforcement between segments, only needed ports and services, monitoring outbound traffic
NIST CSF 2.0	PR.IR-01; DE.CM-01	Protect networks from unauthorised use; monitor networks and network services

Common failure patterns

Allowing "any high port" outbound for convenience: one broad rule for a single application leaves every port above 1024 open for implants too.
Identifying services by port number: dashboards that label 443 as "HTTPS" hide FakeTLS and custom protocols. Use the sensor's confirmed protocol.
Blocking indicator ports: adding 4444 or 1177 to a blocklist feels productive but the next sample uses another port. Allowlist instead.
Network data without process data: analysts see a mismatch but cannot find the program responsible, so alerts age out. Sysmon Event ID 3 or EDR network events close the gap.
Ignoring hosts without agents: ESXi hosts and edge devices appear in T1571 procedure examples precisely because they are watched less.
Moving RDP or SSH to a high port and calling it hardened: it reduces noise from scanners but is not access control.

Practitioner checklist

Baseline outbound destination ports per segment from 30 days of firewall and flow logs.
Enforce default-deny egress with per-segment port lists, servers and management networks first.
Write boundary rules by application where the firewall supports it, not by port alone.
Deploy port-independent protocol identification (Zeek, Suricata or NDR) at internet and data centre boundaries.
Review Suricata detection-ports for protocols you rely on detecting.
Enable Sysmon Event ID 3 or EDR network events and join them to network detections.
Alert on new outbound ports and new listeners for servers, ESXi hosts and appliances.
Give every allowlisted application a named owner and a review date.
Test the mismatch analytics quarterly with an authorised exercise.

MITRE ATT&CK T1571 Non-Standard Port: Detecting Protocol and Port Mismatches