---
{
  "title": "Non-Application Layer Protocol",
  "summary": "Lower-layer command traffic uses protocols outside the ordinary application-layer paths a defender may expect.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1095"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1095: Non-Application Layer Protocol",
      "url": "https://attack.mitre.org/techniques/T1095"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Lower-layer command traffic uses protocols outside the ordinary application-layer paths a defender may expect. Monitoring coverage may vary across these protocols.


## An investigation example

A suspicious process exchanges patterned traffic through a protocol rarely used by the host's approved applications.

## Evidence to examine

Review protocol metadata, process or socket ownership, packet timing, and network-device visibility.

## A common analytical pitfall

Unusual protocol traffic can reflect diagnostics or specialized business systems, so establish the expected baseline.

## Response considerations

Investigate the responsible process and allowed communication policy, preserving enough traffic context to justify targeted containment.


## Control traffic can use lower-layer mechanisms

Communication does not always resemble a normal web or messaging application. An intruder may use mechanisms below the application layer to carry coordination or data. Investigators should consider the actual protocol, host behavior, and network context rather than assume that only familiar application requests can support a control channel.

Many lower-layer messages are essential to ordinary connectivity and diagnostics. Their presence is not inherently suspicious. Assess volume, timing, endpoints, message structure where visible, and the initiating process when the platform exposes it. The relevant question is whether the observed use fits the expected network and application behavior.

## A fictional unusual message pattern

An academy's monitoring records show a workstation producing repetitive diagnostic-looking messages to an unexpected destination. Analysts compare the pattern with approved troubleshooting and correlate endpoint execution. They preserve the original packet context and avoid claiming commands or transferred files when only headers and counts are available.

Some security tools focus more heavily on application protocols and may provide less detail for other traffic. Understand sensor coverage and collection placement before treating absent alerts as proof of absence. A firewall or router policy can also affect responses, making one-sided observations difficult to interpret.

## Read a prepared capture

Use an authorized training capture containing ordinary network diagnostic traffic. Identify the fields that describe source, destination, type, and timing. Then create a fictional unusual pattern and list the additional evidence needed to assess it. There is no need to construct a covert protocol or send traffic to real targets.

A strong report separates protocol observation from intent and impact. Describe what was recorded, why it differs from the baseline, and which endpoint or service evidence supports the hypothesis. This helps responders investigate a meaningful anomaly without declaring essential network behavior malicious merely because it lacks an HTTP request.

## Related concepts

- [[packet-analysis]]
- [[exfiltration]]
- [[network-segmentation]]