Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0457: Detection of Non-Application Layer Protocols for C2

DET0457 is a MITRE ATT&CK detection strategy for identifying command-and-control that uses non-application-layer protocols, via its relationship to techniq...

EnterpriseDET0457Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0457 is a MITRE ATT&CK detection strategy for identifying command-and-control that uses non-application-layer protocols, via its relationship to technique T1095. The business value is that this behavior can sit outside the web, email, and DNS monitoring many organizations prioritize, so leaders should verify whether network monitoring actually covers ICMP, UDP, SOCKS, and tunneled or redirected protocol activity across relevant infrastructure.

Executive priority

Prioritize this as a coverage-validation question for SOC, incident response, and network security programs: can the organization see and investigate C2-like traffic that does not look like normal application-layer web traffic? This matters for operational resilience because gaps in lower-layer protocol monitoring can delay containment decisions, weaken audit evidence, and leave ESXi, Linux, macOS, and network-device environments harder to defend when they are in scope.

Technical view

The supplied ATT&CK object has no official description, platforms, tactics, or detection text of its own. Its relationship states that it detects T1095, Non-Application Layer Protocol, under command-and-control, with related platforms of ESXi, Linux, macOS, and Network Devices. SOC and detection engineering teams should therefore validate visibility and analytic logic for unusual or policy-violating ICMP, UDP, SOCKS, and tunneled or redirected protocol communications between hosts and external destinations or among internal hosts.

Likely telemetry

  • Network flow records showing protocol, source, destination, port where applicable, byte counts, packet counts, and timing
  • Packet or protocol metadata for ICMP, UDP, SOCKS, and tunneled or redirected traffic where available
  • Firewall, router, proxy, VPN, and network device logs that record allowed and denied non-application-layer traffic
  • Endpoint network connection telemetry from ESXi, Linux, and macOS systems where available
  • Network segmentation and egress control logs showing unexpected host-to-host or outbound paths

Detection direction

  • Confirm whether the SOC collects telemetry for protocols that may not appear in HTTP, TLS, DNS, or email-centric detections.
  • Baseline expected ICMP, UDP, SOCKS, and infrastructure management traffic before alerting aggressively, because legitimate monitoring, troubleshooting, VPN, and network services can create false positives.
  • Look for unusual external destinations, uncommon internal peer communication, abnormal volumes, periodic beacon-like timing, or protocol use inconsistent with the asset role.
  • Validate coverage on the related ATT&CK platforms: ESXi, Linux, macOS, and network devices, especially where endpoint telemetry is limited.
  • Use the T1095 relationship as context; the detection strategy object itself does not provide official analytic logic, thresholds, or data source requirements.

Mitigation priorities

  • First, define which non-application-layer protocols are allowed by business function and asset role.
  • Next, enforce egress and segmentation policies so servers, hypervisors, endpoints, and network devices cannot freely communicate over unnecessary protocols.
  • Then, ensure logging is retained and searchable for allowed and denied traffic, including lower-layer or non-web protocols.
  • Finally, test incident response workflows for investigating suspicious ICMP, UDP, SOCKS, and tunneled traffic without assuming web proxy logs will be sufficient.
Analyst notes and limits

This take is based on DET0457 and its relationship to T1095. The main defensive decision is not that a specific analytic is prescribed, but that teams should verify visibility and policy enforcement for C2 channels that may bypass application-layer monitoring assumptions.

MITRE supplied no official description or detection text for DET0457, and the detection strategy itself lists no platforms or tactics. Platform and tactic context comes only from the related T1095 technique. Local network architecture, allowed protocol policy, and telemetry availability are required to determine actual coverage.

Official MITRE ATT&CK definition

Detection of Non-Application Layer Protocols for C2

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1095 Non-Application Layer Protocol This object detects Non-Application Layer Protocol.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
3afcbc27d1f723d8...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 3afcbc27d1f7…
Raw source

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 references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0457
    Open source URL
Source and licensing

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.