Non-Application Layer Protocol (T1095) is command and control that never touches HTTP, DNS or any other application protocol your proxy and DNS logs were built to inspect. Instead the implant talks over ICMP, raw TCP or UDP sockets, custom binary protocols, tunnelling encapsulations such as GRE, or local channels such as the VMware Virtual Machine Communication Interface (VMCI) between a guest and its ESXi host. MITRE ATT&CK v20 lists the technique under Command and Control for ESXi, Linux, macOS, Network Devices and Windows. This guide is for detection engineers, network security teams and threat hunters: how the variants differ, which telemetry actually sees them, how to build and tune detections, and how to shrink the paths they use. For application layer C2 see the MITRE ATT&CK T1071 Application Layer Protocol guide, and for the wider picture the Command and Control (C2) Guide.
Key takeaways
- The gap is in your telemetry, not your rules. Proxy, web gateway and DNS logs never see ICMP, raw TCP or GRE traffic, so T1095 needs flow, packet metadata and host network events.
- Process context is the strongest signal. ATT&CK's v20 analytics key on ICMP or UDP traffic from processes that have no reason to send it, such as a script interpreter or an unsigned binary.
- Asymmetry and duration beat signatures. Long ICMP sessions, fixed size echo requests with steady timing and hosts that send far more than they receive are the patterns that survive payload encryption.
- Network devices and hypervisors are the blind spot. ATT&CK records backdoors on network appliances and VMCI channels to ESXi hosts, where no endpoint agent runs.
- Egress filtering removes most of the attack surface. Deny outbound ICMP payloads, raw ports and tunnelling protocols by default at the boundary and the technique has very little left to ride on.
What T1095 covers in ATT&CK v20
ATT&CK defines T1095 as an adversary using an OSI non-application layer protocol for communication between a host and its C2 server, or among infected hosts inside a network. The description names network layer protocols such as ICMP, transport layer protocols such as UDP, session layer protocols such as Socket Secure (SOCKS), and redirected or tunnelled protocols such as Serial over LAN (SOL). It notes that ICMP must be implemented by every IP-compatible host, yet it is monitored far less than TCP or UDP. The technique absorbed the older Custom Command and Control Protocol technique, which ATT&CK revoked in its favour, so a custom binary protocol on a raw socket now belongs here.
T1095 has no sub-techniques. It sits beside several neighbours that are easy to confuse, and the split decides which telemetry you need.
| Technique | What the adversary relies on | Example | Where you see it |
|---|---|---|---|
| T1095 Non-Application Layer Protocol | ICMP, raw TCP or UDP, SOCKS, GRE or IPsec tunnels, VMCI, custom binary protocols | An implant hiding commands in ICMP echo payloads | Flow records, packet metadata, host network events |
| T1071 Application Layer Protocol | HTTP(S), DNS, mail and file transfer protocols | Beacons over HTTPS to a cloud host | Proxy, DNS and TLS metadata |
| T1571 Non-Standard Port | A protocol on a port it does not normally use | HTTPS on TCP 8443 to an unknown host | Port and protocol mismatch in flow or NDR data |
| T1572 Protocol Tunneling | One protocol carried inside another to evade controls | SSH or RDP tunnelled inside DNS or HTTPS | Protocol anomalies inside an allowed protocol |
| T1048 Exfiltration Over Alternative Protocol | A non-C2 protocol used to move data out | Bulk upload over raw UDP | Volume and destination anomalies |
In practice one implant can map to several of these. Treat them as overlapping lenses, and make sure at least one detection exists that does not depend on an application protocol being present. See the MITRE ATT&CK T1571 Non-Standard Port and T1572 Protocol Tunnelling Defensive Guide for those techniques.
The variants defenders actually meet
ATT&CK v20 lists more than 80 malware families, 13 groups and 8 campaigns as procedure examples for T1095. They fall into five practical patterns.
- ICMP channels: data carried in echo request and reply payloads. ATT&CK records this for Anchor, Winnti for Linux and Uroburos, and records COATHANGER, a backdoor found on network security appliances, using ICMP to move configuration to and from its C2 server.
- Raw TCP and UDP with custom framing: the most common form. ATT&CK records PlugX configurable for raw TCP or UDP, WINDSHIELD using TCP raw sockets, ZIPLINE using a custom binary protocol, and ToddyCat (G1022) running a passive backdoor that takes commands in UDP packets.
- Passive listeners on edge devices: cd00r and J-magic monitor inbound TCP for a trigger rather than calling out. These overlap with T1205 Traffic Signaling, and they matter because outbound-only monitoring never fires.
- Tunnels and proxies below the application layer: Salt Typhoon (G1045) used GRE and IPsec tunnels to reach C2; Gamaredon Group (G0047) and APT3 (G0022) used SOCKS5; Ember Bear (G1003) used socket-based tunnelling utilities; FRP supports TCP, KCP, QUIC and UDP.
- Hypervisor-local channels: UNC3886 (G1048) deployed backdoors that talk over VMCI to ESXi hosts. ATT&CK notes VMCI traffic stays on the physical host and never crosses routers or switches, so network sensors cannot see it at all.
The KV Botnet campaign (C0035) is a reminder that compromised small office routers can carry custom protocol C2, and the 2024 zero-day exploitation campaign against an SD-WAN management platform (C0039) used a non-standard TCP session before switching to HTTPS. Both make the same point: the first and most distinctive packets often arrive before any application protocol.
Telemetry that sees T1095
MITRE's v20 detection strategy for T1095 (DET0457) defines per-platform analytics. The table maps them to the log sources you need and the gaps to plan for.
| Platform | ATT&CK analytic focus | Log sources | Watch out for |
|---|---|---|---|
| Windows | ICMP or UDP from non-network-service processes, especially bypassing the proxy | Sysmon Event ID 3 (network connection) and 22 (DNS query), flow data | Sysmon Event ID 3 is disabled by default and needs a NetworkConnect rule; it logs TCP and UDP only, so ICMP needs other host telemetry |
| Linux | ICMP or raw socket traffic from user-mode processes such as shells, Python or netcat | auditd syscall records for sendto and connect, Zeek icmp and weird logs | Audit rules on networking syscalls are noisy; scope them to interpreters and unusual paths |
| macOS | Unsigned binaries or scripts using ICMP, UDP or SOCKS outside the baseline | Unified log network subsystem, packet capture metadata | Signing status must be joined to the network event |
| ESXi | VMCI traffic from non-management tools or unauthorised binaries | vmkernel syslog entries, host process audits | No network sensor can see VMCI; logs must be forwarded off the host |
| Network devices | Non-standard protocol and port pairings, low entropy or fixed-size ICMP, long sessions | Firewall protocol anomaly logs, NetFlow or IPFIX, Zeek conn and icmp logs | Traffic originating from the device itself is often not flow-exported |
Two telemetry details make a large difference. First, Zeek's conn.log carries an ip_proto field (added in Zeek 7.1) that is present even for flows Zeek cannot parse as a transport protocol, so GRE (IP protocol 47), ESP (50) and other non-TCP and non-UDP flows remain visible; its orig_bytes and resp_bytes fields give the asymmetry ATT&CK's analytics rely on. Second, Sysmon Event ID 3 links each TCP or UDP connection to a process GUID, which is what turns "a host sent UDP" into "powershell.exe sent UDP". Microsoft documents it as covering TCP and UDP connections only, so attributing ICMP to a process needs EDR or other host telemetry. See the Zeek Network Monitoring Guide, the NetFlow and IPFIX Flow Telemetry Guide and the Sysmon Guide for deployment detail.
Building and tuning detections
ATT&CK's analytics expose tunable values (mutable elements) rather than fixed thresholds. Treat the starting values below as ours to tune against your own baseline, not as MITRE figures, except where stated.
| Detection | Logic | Starting tuning value | Main false positives |
|---|---|---|---|
| Unexpected ICMP sender | Process other than an allowlisted set (ping, tracert, monitoring agents) sending ICMP | Allowlist per host role (ATT&CK: ProcessContextAllowList) | Network monitoring and asset discovery tools |
| ICMP payload anomaly | Echo requests with payload sizes or content outside the operating system default, or high entropy payloads | Baseline default sizes per OS family; alert on deviation (ours) | Path MTU testing, some load balancers |
| Long-lived ICMP or UDP session | Same pair exchanging ICMP or UDP well beyond normal duration | ATT&CK gives more than five minutes as an example | VoIP, VPN keepalives, streaming |
| Upload asymmetry | Client sends far more than it receives over ICMP or UDP | ATT&CK gives more than 90 per cent outbound as an example | Syslog and telemetry senders |
| Raw TCP to rare destination | TCP session with no recognised application protocol to a destination seen by very few hosts | Fewer than three internal hosts in 30 days (ours) | New SaaS, developer tooling |
| Unapproved tunnel protocol | GRE, ESP or other IP protocol numbers to destinations outside the approved peer list | Approved peer list only | Site-to-site VPN changes not recorded |
| Non-vSphere VMCI use | VMCI sockets opened by processes outside VMware's own services | Baseline per host build | Third-party guest tooling |
Combine host and network signals wherever possible. A UDP flow to a rare destination is weak on its own; the same flow from a script interpreter launched by an Office process is strong. Beacon timing analysis also works on ICMP and raw TCP, and the scoring methods in the Beaconing and C2 Detection Guide apply without change once the flows are in the same pipeline.
Prevention and hardening
ATT&CK maps four mitigations to T1095. Each translates into concrete settings.
- M1037 Filter Network Traffic: deny outbound ICMP at the internet boundary except the types needed for path MTU discovery and error reporting, and allow echo only from named monitoring hosts. Block IP protocols other than TCP, UDP and approved VPN protocols outbound. ATT&CK also advises restricting guest virtual machines from VMCI services where VMCI is not required.
- M1030 Network Segmentation: force workstation and server egress through proxies, so direct outbound TCP and UDP from user segments is the exception. Allow only the ports and destinations each segment needs, deny by default (NIST SP 800-53 SC-7(5)).
- M1031 Network Intrusion Prevention: use signatures for known malware protocols as a backstop, accepting that custom and encrypted protocols will not match.
- M1047 Audit: periodically review ESXi hosts for processes with open VMCI sockets, and review network device configurations and running processes against vendor baselines.
Network devices deserve their own hardening track because many of the ICMP and passive-listener backdoors above ran on appliances. Restrict management planes to a dedicated network, keep vendor images current and verify image integrity using the vendor's published method. See the Network Device Management Plane Hardening Guide.
Choosing an approach
- Small organisations: start with egress filtering. A default deny outbound policy with a short allow list removes raw TCP, UDP and ICMP C2 paths at low cost, and firewall deny logs become a free detection source.
- Mid-sized estates: add Sysmon Event ID 3 with a scoped NetworkConnect rule on servers and high-value workstations, and flow export at the internet edge. That covers process context and asymmetry.
- Large or high-threat environments: add packet metadata sensors (Zeek or an NDR platform) at internal choke points, ESXi log forwarding and network device integrity checks, because the groups using hypervisor and appliance channels target exactly these organisations. See the NDR Guide.
The trade-off is cost against blind spots. Host telemetry gives process context but misses appliances and hypervisors; network telemetry sees appliances but misses VMCI and local traffic. Mature programmes need both.
How to implement
- Inventory legitimate non-application traffic. List every system that sends ICMP, raw TCP, UDP or tunnel protocols across a boundary, with owner and purpose. This becomes the allowlist.
- Turn on the telemetry. Enable flow export at the internet edge and core, deploy a Sysmon NetworkConnect rule on a pilot group, forward ESXi and network device syslog to the SIEM.
- Run detections in alert-only mode for two to four weeks (our recommendation). Record each false positive with the process, destination and business reason, and tune by host role rather than by global exclusion.
- Tighten egress in stages. Apply the new outbound policy to one segment at a time, log denies for a week before enforcing, and keep a documented rollback (restore the previous rule set) for each change window.
- Promote stable detections to production with triage notes: which process, which destination, which host owner to contact.
- Hunt quarterly for long ICMP sessions, rare IP protocol numbers and unexplained VMCI sockets, and feed findings back into the allowlist.
Responding to a T1095 finding
Confirm the process and binary first: path, signer, hash, parent and when it arrived. Capture packets for the flow before blocking, because the payload format may reveal other infected hosts using the same protocol. Then block the destination and protocol at the boundary, isolate the host if the process is confirmed malicious, and sweep flow data for the same destination, packet size pattern or IP protocol number across the estate. On a network device or ESXi host, treat the platform as untrusted: collect logs and configuration off-box, follow the vendor's integrity verification procedure and plan a rebuild from known-good images. Where the implant ran under a service account or stored credentials, rotate them, since C2 access usually precedes credential theft. See the ESXi Logs Detection Guide for hypervisor evidence sources.
Detection and measurement
- Egress coverage: percentage of network segments where outbound ICMP, raw ports and tunnel protocols are default deny.
- Process attribution rate: percentage of outbound ICMP and UDP flows from monitored hosts that can be tied to a process.
- Allowlist freshness: percentage of approved non-application flows with an owner reviewed in the last 12 months.
- Blind spot count: number of network devices and ESXi hosts not forwarding logs to the SIEM.
- Detection fidelity: true positive rate of T1095 detections over a quarter, tracked per rule.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK v20 | T1095; mitigations M1037, M1030, M1031, M1047; detection strategy DET0457 | Technique definition, mitigations and per-platform analytics |
| MITRE D3FEND | D3-NTA Network Traffic Analysis, D3-PMAD Protocol Metadata Anomaly Detection, D3-OTF Outbound Traffic Filtering, D3-CAA Connection Attempt Analysis | Defensive techniques for flow analysis and egress control |
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection, SC-7(5) Deny by Default, AC-4 Information Flow Enforcement, CM-7 Least Functionality, SI-4 System Monitoring | Egress policy, protocol restriction and monitoring |
| NIST CSF 2.0 | DE.CM-01, DE.CM-09, DE.AE-02 | Network and host monitoring, analysis of adverse events |
Common failure patterns
- Allowing all outbound ICMP "for troubleshooting": it is the oldest covert channel in the book, and blocking echo payloads outbound from user and server segments rarely breaks anything.
- Relying on the proxy as the C2 control: a proxy only governs traffic that is sent to it; a raw TCP connection that the firewall allows directly bypasses it entirely.
- Collecting flows without the IP protocol number: exporters or parsers that keep only TCP and UDP drop GRE and other tunnels from view.
- Sysmon deployed without a network rule: Event ID 3 is disabled by default, so many estates believe they have process network context when they do not.
- No logs from appliances and hypervisors: the devices where ATT&CK records ICMP and VMCI backdoors are often the ones with no forwarding at all.
Practitioner checklist
- Set outbound ICMP, raw ports and non-TCP and non-UDP IP protocols to default deny at the internet boundary, with a documented allow list.
- Force user and server egress through proxies and alert on direct outbound sessions that bypass them.
- Enable Sysmon Event ID 3 with a scoped NetworkConnect rule, or equivalent EDR network telemetry, on servers and privileged workstations.
- Export flow records that keep the IP protocol number and byte counts in each direction.
- Deploy the DET0457 analytics per platform, starting in alert-only mode, and tune by host role.
- Forward ESXi and network device logs off-box and review VMCI and device processes against a baseline.
- Hunt quarterly for long ICMP sessions, upload asymmetry and rare IP protocol numbers.
- Write a response runbook that captures packets before blocking and treats compromised appliances as untrusted.
Standards and references
- MITRE ATT&CK: Non-Application Layer Protocol (T1095)
- MITRE ATT&CK: Detection of Non-Application Layer Protocols for C2 (DET0457)
- MITRE D3FEND: Network Traffic Analysis
- NIST: SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- Microsoft Sysinternals: Sysmon
- Zeek: conn.log documentation
Related NHI Mgmt Group resources: Command and Control (C2) Guide · Beaconing and C2 Detection Guide · MITRE ATT&CK T1071 Application Layer Protocol · Zeek Network Monitoring Guide · Network Device Management Plane Hardening Guide