---
{
  "title": "Protocol Tunneling",
  "summary": "Protocol tunneling carries one communications stream inside another protocol.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1572"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1572: Protocol Tunneling",
      "url": "https://attack.mitre.org/techniques/T1572"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Protocol tunneling carries one communications stream inside another protocol. It can bridge restrictions or make the inner traffic harder to inspect.


## An investigation example

An accessed host establishes a long-lived connection that relays traffic to destinations not ordinarily reachable from it.

## Evidence to examine

Review tunneling configuration, process identity, traffic relationships, timing, and permitted business uses.

## A common analytical pitfall

Encryption or a long-lived connection alone does not establish tunneling or malicious intent.

## Response considerations

Preserve relay context, investigate the responsible process, and contain confirmed unauthorized paths while respecting legitimate remote connectivity.


## One protocol can carry another conversation

Tunneling encapsulates communication inside another protocol or channel. Legitimate VPNs and administrative tools use this approach, while an intruder may use it to cross an intended monitoring or access boundary. The outer protocol describes the carrier; the inner communication may have a different purpose. Investigators need to understand both where evidence permits.

A permitted carrier does not automatically authorize everything inside it. Conversely, encapsulation is not inherently malicious. Review the responsible client, destination, account, approved use, and the boundary the tunnel crosses. Port-based rules alone may provide an incomplete picture because many applications can share the same outer transport.

## A fictional unexpected relay

An academy identifies a workstation process maintaining a connection to an unapproved relay while another local application sends traffic through it. Analysts correlate process configuration, listening endpoints, network events, and approved remote-access arrangements. They distinguish the observed relay relationship from unsupported claims about every inner message.

Encryption or incomplete capture may prevent inspection of the inner protocol. State that limit and use endpoint or service records for complementary context. Do not weaken real protective controls or run an unknown tunnel client merely to observe more traffic. Analysis should follow an authorized environment and handling procedure.

## Draw the carrier and payload

Create a fictional diagram with an application, tunnel client, relay, and destination. Label the inner and outer communication and mark the evidence available at each point. Explain why a firewall observing only the outer connection may not establish the inner application's purpose. Use a paper model or harmless approved lab.

Containment should address the actual unauthorized path and its authority, while accounting for legitimate dependencies. Blocking a carrier used by many services can have broad operational effects. A proportionate decision identifies the concerning client or destination where possible and verifies that the intended boundary is restored.

## Related concepts

- [[packet-analysis]]
- [[exfiltration]]
- [[network-segmentation]]
- [[dynamic-resolution]]
- [[proxy]]
- [[data-obfuscation]]