T1095: Non-Application Layer Protocol
Adversaries may use an OSI non-application layer protocol for communication between host and C2 server or among infected hosts within a network. The list of possible protocols is extensive.CitationWikipedia OSI Specific examples include use of network layer protocols, such as the Internet Control Message Protocol (ICMP), transport layer protocols, such as the User Datagram Protocol (UDP), session layer protocols, such as Socket Secure (SOCKS), as well as redirected/tunneled protocols, such as Serial over LAN (SOL).
ICMP communication between hosts is one example.CitationCisco Synful Knock Evolution Because ICMP is part of the Internet Protocol Suite, it is required to be implemented by all IP-compatible hosts.CitationMicrosoft ICMP However, it is not as commonly monitored as other Internet Protocols such as TCP or UDP and may be used by adversaries to hide communications.
In ESXi environments, adversaries may leverage the Virtual Machine Communication Interface (VMCI) for communication between guest virtual machines and the ESXi host. This traffic is similar to client-server communications on traditional network sockets but is localized to the physical machine running the ESXi host, meaning it does not traverse external networks (routers, switches). This results in communications that are invisible to external monitoring and standard networking tools like tcpdump, netstat, nmap, and Wireshark. By adding a VMCI backdoor to a compromised ESXi host, adversaries may persistently regain access from any guest VM to the compromised ESXi host’s backdoor, regardless of network segmentation or firewall rules in place.CitationGoogle Cloud Threat Intelligence VMWare ESXi Zero-Day 2023
Security context for executives and security teams
T1095 matters because command-and-control traffic may avoid the web, DNS, email, and other application-layer channels that many security programs monitor most heavily. Adversaries can use lower-layer or non-standard protocol paths such as ICMP, UDP, SOCKS, tunneled protocols, or ESXi VMCI communications to keep control of compromised systems while blending into network behavior that may be under-instrumented. For leaders, the key issue is not the protocol name; it is whether the organization can see, restrict, and investigate communications that do not look like ordinary application traffic.
Executive priority
Prioritize this where business operations depend on network devices, virtualized ESXi infrastructure, critical infrastructure systems, MSP/ISP connectivity, or segmented environments assumed to be protected by firewalls. ATT&CK relationships show this technique is associated with multiple campaigns and groups, including activity involving network devices, SD-WAN, SOHO equipment, and electric utility operations. Executives should ask whether segmentation, network filtering, intrusion prevention, and audit evidence actually cover non-application-layer traffic, including host-local ESXi VMCI paths that may not cross normal network monitoring points.
Technical view
This is a command-and-control technique across ESXi, Linux, macOS, network devices, and Windows. SOC and IR teams should validate visibility for ICMP, UDP, SOCKS/session-layer use, redirected or tunneled protocols such as Serial over LAN, and ESXi VMCI communications. The supplied ATT&CK object has no official detection text, but relationship DET0457 indicates a detection strategy for non-application-layer protocols for C2. Detection engineering should focus on protocol baselining, unexpected ingress/egress or lateral traffic, unusual peer relationships, and gaps where external packet capture, netstat, tcpdump, nmap, or Wireshark may not observe localized hypervisor/guest VMCI communications.
Likely telemetry
- Network flow records showing protocol, source, destination, volume, timing, and directionality
- Packet metadata or packet capture for ICMP, UDP, SOCKS-like, and tunneled protocol activity where lawful and feasible
- Firewall, router, switch, SD-WAN, and network device logs for allowed and denied non-standard traffic
- Network intrusion detection/prevention alerts and signature matches at ingress, egress, and internal boundaries
- Endpoint network connection telemetry from Windows, Linux, and macOS systems
Detection direction
- Do not assume web proxy, DNS, or EDR network views are sufficient; validate collection for ICMP, UDP, SOCKS/session-layer, redirected, and tunneled traffic.
- Build environment-specific baselines for legitimate non-application-layer protocols, then alert on unusual destinations, new peer-to-peer patterns, abnormal beacon timing, or protocol use by systems that rarely need it.
- Tune carefully for false positives because ICMP, UDP, and infrastructure protocols can be normal for diagnostics, monitoring, routing, and operations.
- For ESXi, explicitly assess VMCI visibility because ATT&CK notes this communication can be localized to the physical host and invisible to external monitoring and standard networking tools.
- Use campaign and group relationships as threat-intelligence context for prioritization, not as proof of attribution in local incidents.
Mitigation priorities
- Start with audit: inventory where non-application-layer protocols are required, who owns the exceptions, and whether logs are retained for investigation and compliance evidence.
- Apply network segmentation to reduce unnecessary lateral and cross-zone communication, while recognizing that segmentation alone may not address ESXi VMCI guest-to-host paths.
- Filter ingress, egress, and lateral traffic by protocol and approved business need; remove broad allowances for ICMP, UDP, SOCKS, or tunneled protocols where not required.
- Use network intrusion prevention or detection signatures at boundaries and key internal choke points, with tuning for operational protocols.
- For ESXi and network-device environments, include management-plane and virtualization-layer controls in reviews rather than relying only on traditional endpoint and perimeter monitoring.
Additional notes and limits
The object is especially relevant to organizations with heterogeneous infrastructure: endpoints, network devices, and ESXi hosts. The relationship set indicates broad use by campaigns and groups, but local defensive value comes from validating protocol visibility, segmentation assumptions, and hypervisor monitoring. The revoked T1094 relationship is useful for content mapping because older references to custom C2 protocols may now align to T1095.
MITRE provides no official detection text for this object in the supplied fields. The external references and relationships support defensive concern, but they do not prove current exploitation against any specific organization. Detection feasibility depends heavily on local network architecture, telemetry retention, encrypted or tunneled traffic visibility, ESXi logging, and the accuracy of asset and protocol baselines.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Non-Application Layer Protocol
Adversaries may use an OSI non-application layer protocol for communication between host and C2 server or among infected hosts within a network. The list of possible protocols is extensive.CitationWikipedia OSI Specific examples include use of network layer protocols, such as the Internet Control Message Protocol (ICMP), transport layer protocols, such as the User Datagram Protocol (UDP), session layer protocols, such as Socket Secure (SOCKS), as well as redirected/tunneled protocols, such as Serial over LAN (SOL).
ICMP communication between hosts is one example.CitationCisco Synful Knock Evolution Because ICMP is part of the Internet Protocol Suite, it is required to be implemented by all IP-compatible hosts.CitationMicrosoft ICMP However, it is not as commonly monitored as other Internet Protocols such as TCP or UDP and may be used by adversaries to hide communications.
In ESXi environments, adversaries may leverage the Virtual Machine Communication Interface (VMCI) for communication between guest virtual machines and the ESXi host. This traffic is similar to client-server communications on traditional network sockets but is localized to the physical machine running the ESXi host, meaning it does not traverse external networks (routers, switches). This results in communications that are invisible to external monitoring and standard networking tools like tcpdump, netstat, nmap, and Wireshark. By adding a VMCI backdoor to a compromised ESXi host, adversaries may persistently regain access from any guest VM to the compromised ESXi host’s backdoor, regardless of network segmentation or firewall rules in place.CitationGoogle Cloud Threat Intelligence VMWare ESXi Zero-Day 2023
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.