Attackers use Non-Application Layer Protocol to move command, control, or stolen data over lower-level or non-standard protocols that may not be inspected like web traffic. This can reduce visibility and bypass content filters. Defenders should monitor unusual protocol use, baseline expected network flows, and inspect egress traffic that does not match business services.
How attackers hide command and control in non-standard protocols
Attackers use non-application layer protocol when they want traffic to look like ordinary network movement instead of obvious web browsing, API calls, or file transfer. The point is not the protocol itself, but the fact that many security stacks inspect application traffic more deeply than lower-level or unusual flows, so the attacker can move instructions, beacons, or exfiltrated data through a channel that gets less scrutiny.
That tactic is especially useful when defenders rely heavily on content inspection, URL filtering, or web proxy controls. If the protocol is uncommon in the environment, or if it is nested inside allowed infrastructure traffic, it can blend into normal noise and make command-and-control signaling harder to spot.
Why protocol choice changes detection
Different protocols give attackers different tradeoffs. Some are noisy but reliable, some are hard to inspect, and some are useful only because defenders are not baselining them carefully. A protocol that is technically legitimate may still be abused if it is rarely used by business services, not normally associated with the host, or allowed outbound without tight inspection.
That is why protocol abuse often succeeds through inconsistency rather than sophistication. A workstation that suddenly emits DNS-like patterns, ICMP, raw sockets, or other unusual egress can be more revealing than a polished malware payload. Command and Control (C2) Guide covers the broader detection patterns that matter here, including beaconing, protocol tunneling, and egress filtering.
From a defender’s perspective, the question is not whether the protocol is allowed in the abstract. It is whether that protocol is expected from that system, at that time, for that business function, and at that volume.
What defenders should baseline and inspect
Start with what your environment actually uses, then compare all outbound traffic to that baseline. Protocols that are legitimate on paper can still be malicious in practice if they originate from hosts that should not be speaking them, or if they appear only after an intrusion.
IANA is useful as a reference point for protocol and port registries, but the operational task is local: identify the specific flows your business depends on, then flag deviations in destination, frequency, size, timing, and transport. Unusual protocol use becomes much more actionable when paired with egress visibility, DNS analytics, and network segmentation.
When the goal is covert command-and-control, low-level or non-standard protocols are often chosen because they pass through places where application-layer security tooling has little context. That means packet metadata, flow logs, and network behavior analysis become especially important, not just payload inspection.
Risk and Threat Considerations
Non-application layer protocols can hide both command traffic and stolen data, which creates an exposure problem even when the payload is partially encrypted or fragmented. The main risk is loss of visibility, because defenders may see “normal” network activity while the attacker is actually maintaining persistence or moving data out of the environment.
Failure mechanism: The attacker abuses a protocol that is allowed, under-monitored, or rarely inspected, then uses that channel for beaconing, tasking, or exfiltration while avoiding application-layer controls.
Impact: Detection is delayed, containment is harder, and the compromise can persist long enough for lateral movement, credential theft, or additional exfiltration to occur.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1095 — Non-Application Layer Protocol | Directly models attacker use of lower-layer protocols for covert C2 and exfiltration. |
| T1071 — Application Layer Protocol | Provides the adjacent C2 pattern used to contrast application-layer inspection with lower-layer abuse. | |
| Recommendation — Map unusual flows to T1095 and hunt for covert C2 or exfiltration patterns. Correlate protocol abuse with C2 behavior and inspect for tunneling or masquerading. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Security Events | Continuous monitoring is needed to spot rare or abnormal protocol use on the network. |
| DE.AE-01 — Anomalies and Events are Analyzed | Anomalous flows must be analyzed to separate business traffic from covert channels. | |
| PR.DS-01 — Data-at-rest is protected | Although the topic is network abuse, exfiltrated data protection is part of the consequence chain. | |
| Recommendation — Monitor network traffic for anomalous protocol use and unexpected egress paths. Analyze protocol anomalies against baselines to distinguish legitimate services from abuse. Protect sensitive data so protocol abuse cannot easily turn into useful exfiltration. | ||
Practitioner Guidance
What to verify: Confirm which protocols are truly required by each subnet, server role, and endpoint class. If a protocol appears only on a few hosts, treat that as a review trigger rather than assuming it is benign.
What to measure: Track outbound protocol diversity, rare destination pairs, and flows that do not match known business services. Sharp changes in timing or packet size are often more useful than a simple allow-or-block view.
Decision rule: If a host uses an unexpected protocol but the business case is unclear, prioritize containment and flow review before assuming the traffic is legitimate. If the traffic is tied to a known service, document the expected pattern so future anomalies stand out.
Practitioner takeaway: The strongest defense is not “block all unusual protocols,” but knowing which protocols are normal, on which systems, and what their legitimate traffic should look like.