Non-Standard Port

Protocols have conventional ports, and nearly all software follows the convention. The convention is only a convention: any protocol can be carried on any port, and nothing enforces the pairing except the agreement of the two programs at either end.

Non-standard port is the technique of deliberately not following it. An attacker running command and control over a port the protocol does not normally use is doing something that is technically unremarkable, entirely supported, and invisible to any control whose logic is written in terms of which ports mean which protocols.

There are two motives and they pull in opposite directions, which is worth holding onto because they leave different evidence.

The first is evasion of a port-based control. Where inspection, proxying or alerting is applied to the conventional ports of a protocol, moving the same traffic to an unconventional port steps outside all of it. Nothing about the traffic changes except the number in the header, and the control simply does not apply.

The second is the opposite: not avoiding what is watched, but finding what is allowed. An attacker on a restrictive estate wants a route OUT, and takes whatever the egress policy permits. That frequently means an entirely ordinary port carrying something it was never intended to carry. Here the unusual property is not the port in isolation, which may be among the most common ports in use anywhere, but the pairing of that port with the host using it and the destination it is reaching.

The technique also appears as the second half of a fallback: an implant blocked on its preferred route retries on an unconventional one, and the port change is the visible trace of the route change.

Data source: Network flow records for the connections themselves, read together with the egress policy telemetry from the control point that permitted them

Scope to traffic that actually LEAVES the estate before anything else, because internal and egress traffic are different questions with different answers and only the second one is this technique. Internal application traffic uses arbitrary ports constantly and legitimately, and a query run against everything will be dominated by it.

Within egress traffic, the productive form of the question is specific rather than general. Not "which ports are unusual", which on any busy estate is answered by a great many of them, nearly all benign, but: for THIS source, reaching OUTSIDE the estate, is this port one it has any reason to be using. The destination scope and the port together are the identification. They are not a means of assembling traffic for someone to judge afterwards.

Build the inventory that makes this answerable: what leaves the estate, from which hosts, on what. That inventory is generally small and stable even where internal traffic is neither, and it is what turns a port into a finding rather than an observation. Where a server's role is to ANSWER inbound requests, outbound connections from it are worth reading closely on any port at all, conventional or not.

Where the estate does identify protocols, run the pairing directly and look for a protocol on a port that does not belong to it, in either direction: a known protocol on an unexpected port, and an unexpected protocol on a known one. Where it does not, say so explicitly when handing the work on, because an analyst who assumes protocol identification exists will otherwise spend their time looking for a field that is not there.

Unusual ports are ordinary. Management interfaces, databases, message brokers, monitoring agents, build systems and application tiers talking to each other all use ports that are not the conventional web ports, entirely routinely. Alerting on unusual ports as such produces a volume nobody can work through.

Direction and destination are what make the difference. A host reaching an internal service on an unconventional port is unremarkable. The same host reaching an address outside the estate, on a port that nothing else on the estate uses to leave, is not, and that remains true when the port itself is a thoroughly conventional one belonging to a protocol which has no business leaving from that host.

Legitimate egress on unconventional ports does exist, so it needs to be known rather than assumed away: software update mechanisms, vendor telemetry, remote support tooling and cloud service endpoints are the usual sources. Each is identifiable by its destination and by which hosts do it, and each belongs in the inventory. A connection that is not in that inventory is a finding and not a candidate for one.

• MITRE ATT&CK: T1571 Non-Standard Port

No range covers this technique yet; the write-up above landed first. Ranges are added continuously; the ones live today are on the training ladder.