Protocol Tunneling

Tunnelling is carrying one protocol inside another. The outer protocol is the one the network sees and the one the policy evaluates; the inner protocol is what is actually being run. This is not an exploit and not a defect. It is how remote access, site to site connectivity and a great deal of ordinary administration have always worked, and the same mechanisms are available to anyone on the host with the rights to use them.

What makes it a technique is the purpose. An attacker tunnels so that the traffic a control would stop travels inside traffic that control permits. The outer protocol is chosen for being allowed to leave; the inner one is whatever the attacker actually wants, which is frequently an interactive session, a file transfer, or a route into the internal network from outside it.

The straightforward use is to wrap a single session. An attacker with a foothold establishes an outbound connection using a protocol the estate permits, and runs their real session inside it. Every control applied to the outer protocol sees exactly what it expects to see, and the inner traffic is not examined because nothing is looking inside.

The more consequential use is to tunnel a ROUTE rather than a session, turning a compromised host into a way in. A tunnel established outbound, from inside the estate, produces inbound access without anything having to be permitted inbound, which is why an estate with a strict inbound policy and a permissive outbound one is more exposed than it looks.

Two things are commonly assumed about this technique and neither holds. Tunnelling does not require attacker tooling: the widely deployed remote access clients already present on most estates do it as a documented feature, which is both how it is done and why it is hard to rule out. And encryption is not what hides it. A tunnel hides because the outer protocol is EXPECTED, not because the payload is unreadable. Traffic nobody was going to inspect is not made more hidden by encrypting it.

Data source: Network flow records carrying per connection byte counts in each direction, connection duration and the initiating host, read together with endpoint process telemetry for the tool that established the connection where the estate collects it

Prebuilt Elastic rule: Potential Linux Tunneling and/or Port Forwarding

A tunnel is usually isolated by SEVERAL independent properties at once, and it is worth knowing which of them do the work, because the one most people reach for first is the weakest of them.

DURATION IS THE WEAK ONE. Long running connections are ordinary: scheduled synchronisation, replication, backups, streaming clients and persistent management sessions all hold connections open, and an attacker who wants to stay hidden picks a duration that sits inside whatever the estate's ordinary long connections look like. A long connection is not a finding, and a hunt built on sorting by duration will find whatever is longest rather than whatever is wrong.

THE DIRECTION OF THE BYTE RATIO IS THE STRONG ONE. An outbound dominant connection is doing something different from a download, and ordinary bulk traffic is either inbound dominant or roughly balanced, because most of what an estate does over a long connection is fetch things or exchange them evenly. Whatever the volume involved, the direction of the imbalance is the property an attacker cannot avoid while still moving data outward.

OUTBOUND VOLUME AND ORIGINATING HOST ARE TWO MORE, and they are independent of the ratio rather than restatements of it: a connection whose outbound volume resembles nothing else leaving that host, or which originates from a host that has no business initiating that kind of outbound connection in the first place, is isolated on each of those grounds by itself. A tunnel is typically abnormal on every axis EXCEPT duration, which is the one it was built to share.

So the method is: build an expectation of what long outbound connections look like on the estate, by host and by destination, then look for the connection that matches that expectation in duration while departing from it in direction, in volume, or in where it came from. Where endpoint telemetry exists, confirm on the host, because the command line of the process that opened the connection is frequently unambiguous where the flow record is only suggestive.

Legitimate tunnelling is everywhere and looks the same. Remote access clients, administrative sessions, cloud connectors, build agents and developer tooling all establish long lived outbound connections carrying something inside something else, and the technique is defined by purpose rather than by mechanism, so observing the mechanism rules nothing in.

The questions that actually resolve it are about expectation rather than about the traffic. Is the tunnelling tool one the estate deploys, and is this a host it is deployed on. Was the connection opened by a process and an account that ordinarily opens connections of this kind. Does the destination belong to a service the organisation uses and can name. A tunnel from a developer's workstation to a service the team is known to use is a different proposition from the identical shape on a server whose entire role is to answer inbound requests, reaching an address nobody can account for.

Because the mechanism is so common, the strongest position is an inventory rather than a rule: which hosts are expected to hold long outbound connections, to where, and established by what. Anything outside that is worth a look even when it is individually unremarkable, and the ratio direction is what turns a look into a finding.

• MITRE ATT&CK: T1572 Protocol Tunneling
• Elastic Security: Potential Linux Tunneling and/or Port Forwarding

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.