T1095 Non-application layer protocol

Before any T1095 alert is tuned, you need a written inventory of which non-application layer protocols legitimately cross each segment. Start with the segments that matter most: the boundary between user networks and data center zones, the management network that reaches hypervisors and network devices, and any segment carrying storage or cluster traffic. For each segment, record the protocols and ports in use, the source and destination roles, and the owning team. Routing protocols such as those used between core and distribution devices, cluster heartbeats and replication traffic between hypervisor hosts, and out-of-band management sessions to switches and firewalls are the usual sources of legitimate non-standard traffic that looks suspicious in a flow log. Ask each platform owner to confirm these flows in writing, because vendor documentation often lists defaults that a given environment has changed.

Build the baseline from a window long enough to include normal operational cycles, such as backups, patch windows, failover tests and month-end batch jobs. Collect Network Traffic Flow records and Network Connection Creation events for that window, then group them by source role, destination role, protocol and port. Separate expected flows, which map to an inventoried owner and purpose, from unexpected flows, which have no owner or appear only from a single host. Treat unexpected flows as leads for investigation rather than as allow list candidates. The exact retention period and sampling rate depend on your sensors and storage, so confirm them with the platform vendor and your own capacity planning before you commit to a window.

Feed each confirmed exception into your allow list with four fields: the flow definition, the business owner, the justification, and a review date. Review dates matter because a stale exception is a common route for real misuse to go unnoticed. Set the review cadence with the owners and tie it to change control, so that any change to a routing design, cluster configuration or management tool triggers a re-check of the related exceptions. Store the allow list under version control in your Wazuh or SIEM content repository so that every change has an author and a reason, and so that the Sigma or detection rules referencing it can be audited against the ATT&CK version you target.

The first decision on a T1095 alert is whether the flow is an approved service at all. Confirm that the traffic is not a sanctioned protocol before anyone isolates a host. Check the flow against your approved service register, change records and firewall rules for the source and destination pair, and look at whether the protocol is one that the destination is expected to speak on that port. Non-application layer traffic such as raw TCP, UDP or ICMP payloads with no recognizable application framing can come from monitoring agents, time sync, backup or storage replication, so a clean match against an approved service ends triage early. Next, identify the source and destination hosts, the owning team for each, and the service account or process that opened the connection on the Linux, macOS, ESXi or network device side. Record the owner contact details in the case before going further, because the owning team is the fastest way to confirm intent.

Preserve evidence before you change anything. Export the Network Connection Creation events, the Network Traffic Flow records and any Network Traffic Content captures covering the alert window from your Security Onion, Zeek or Suricata sensors and from the Wazuh manager, and hash the exported files. Keep the captures in the case store with their collection times and sensor identifiers. Then check adjacent hosts on the same subnet and VLAN for the same port, protocol and destination pattern, since T1095 activity often appears on more than one system. If the pattern appears on other hosts, treat the alert as a campaign-level signal and widen the scope. Escalate to incident response when the flow goes to an external destination without a known owner, when content captures show encrypted or encoded payloads with no approved reason, when the same pattern appears across several segments, or when the affected system is a hypervisor, identity system or network device. Contain by applying a filter on the segment or isolating the host only after the owning team and incident lead agree, and document the timeline as you go: alert time, triage decisions, who was contacted, each containment step and its time, and the evidence hashes. That record is what an incident review will use.

Before the first production alert, agree these steps with your incident response and network teams and rehearse them in a private cyber range, so the decision to isolate a segment is not made for the first time during a live event. Confirm with your vendors which containment actions your firewalls and hypervisors support without disrupting management traffic. The response plan should also reference the Network Intrusion Prevention and Filter Network Traffic mitigations described for this technique, and it should name the ATT&CK version your detection mappings target, because technique definitions can change between releases. Refer to the MITRE ATT&CK tactic page for Command and Control for the technique context your analysts will cite in the incident record.

Start with the ATT&CK tactic page for Command and Control, TA0011, which describes the adversary goal this technique serves: communicating with compromised systems to control them. Use it to confirm that T1095 Non-Application Layer Protocol sits under this tactic in the version you are working from, and to read the related technique family before you write detection logic. For a T1095 detection, the practical question is which protocols and ports your environment expects to see on each platform, so record that baseline alongside the ATT&CK reference. Your detection notes should name the ATT&CK version they target so that later reviews can tell whether a mapping has changed.

Next, read the MITRE ATT&CK updates page. ATT&CK releases can rename, deprecate or revoke techniques, and a mapping that was correct in one release may need review in the next. Confirm the current status of T1095 and its platform coverage in the release you target, and check whether its detection strategies or data component references have changed since your last review. The release notes linked from that page describe the scope of each update, so read the notes for any release that lands between your baseline and your planned rollout.

The STIX 2.1 bundles in the mitre-attack/attack-stix-data repository are the most reliable way to check mappings programmatically. Pull the bundle for the exact version you target and confirm the technique ID, platforms, tactics, data components and mitigations that your Wazuh, Sigma or Security Onion rules depend on. Store that bundle version in your detection catalog and record who approved any change. Ask your DeployOpen team, or your own threat intelligence owner, to confirm the mapping for your environment before a rule is promoted to production.