Why T1572 protocol tunneling hides inside allowed traffic
Protocol tunneling under ATT&CK technique T1572 is the case where traffic that looks permitted is carrying hidden command and control. As a SOC lead, your working question is simple: which of the flows that cross your boundary today are actually carrying something other than the protocol they claim to be. T1572 describes an adversary carrying traffic inside another protocol to reach systems or control them, so the outer protocol (often one your firewall already allows) becomes the envelope for a channel the defender did not approve. The technique sits under the Command and Control tactic, TA0011, which MITRE describes as the point where the adversary communicates with compromised systems to control them. This page maps detection guidance to Enterprise ATT&CK version 20.0, so any rule or analytic you write should name that version explicitly.
In intrusions, the tunnel is usually a means to an end rather than the goal itself. An adversary who already has a foothold may use it to reach hosts that are not directly routable from its entry point, to move through segmentation boundaries, or to keep a control channel alive when direct egress is blocked. Because the carrier protocol is familiar, a tunnel can pass through allow rules written for legitimate business use. That is why the detection question is less often "is this protocol allowed?" and more often "does this flow's payload, timing, endpoints and volume match what this protocol is for?" Your first decision is therefore which outbound and east-west paths are most sensitive, because those are where a tunnel would have the most value to an adversary.
Before you plan detections, confirm three things with your own team: which protocols your environment permits across each trust zone, which hosts are expected to originate or accept that traffic, and whether your current telemetry records connection and flow metadata at the boundaries you care about. If any of those answers is unknown, that gap is the first finding to close. The later sections on data sources, detection logic and mitigations depend on those answers, and the ATT&CK technique page for T1572 is the reference to check against the version you are targeting.
How protocol tunneling shows up across ESXi, Linux, macOS and Windows
Protocol tunneling hides one protocol inside another, so the host usually shows a normal-looking process or service with an unusual network pattern. The four platforms differ in where that pattern appears, but each card below points to the telemetry a defender should check first for T1572 Protocol tunneling.
ESXi hosts and management traffic
On ESXi, the concern is tunneled traffic leaving management interfaces or service consoles where outbound connections are rare. Network Connection Creation records can show a management-side process opening sessions to destinations it does not normally reach. Compare those connections with the expected management baseline and the firewall rules that govern it. Review any outbound session from a management interface that falls outside documented administrative paths. Confirm with your hypervisor vendor which logs are available on your version.
Linux servers and long-lived sessions
On Linux, tunneling often appears as a service or interpreter that opens a single long-lived outbound connection and carries many small exchanges through it. Process Creation events identify which binary started the connection, while Network Connection Creation shows the destination and timing. Check for processes whose parent does not match their usual role, and for sessions that persist far longer than the application they belong to. Process and network telemetry together are more useful here than either source alone.
macOS endpoints and user-level processes
On macOS, tunneling tends to run as a user-level process launched from an application bundle or a login item rather than as a system service. Network Connection Creation and Process Creation events can reveal an unexpected helper that holds an outbound session open. Look at whether the process was started by a user session and whether its destination matches any sanctioned tool on the fleet. Ask your endpoint team which macOS unified log and endpoint agent fields are captured before you write detections against them.
Windows hosts and network flow records
On Windows, tunneling commonly uses an existing signed application or a service that already holds network permissions, so process identity alone may not be enough. Network Traffic Flow records help here because they show byte volumes, session duration and the ratio of inbound to outbound data across a host. Correlate those flows with Process Creation events to see which program owns each session. A session that moves steady traffic for hours from a process that normally makes brief requests is worth a closer look.
Which telemetry reveals T1572 and which open-source tool collects it
This table maps each data component ATT&CK links to detection of protocol tunneling to the signal it gives defenders and the open-source collector that gathers it. Read each row as a question: can this source show the tunnel, and what does it miss? The main takeaway is that connection and process telemetry gives the earliest signal, while content-level visibility depends on decryption and sensor placement that you must confirm in your own environment.
| Data component | Signal for T1572 | Open-source collector | Coverage caveat |
|---|---|---|---|
| Network Connection Creation (DC0082) | Long-lived or unexpected outbound sessions on non-standard ports or from hosts that do not normally talk to that destination | Wazuh agents, Zeek connection logs, Suricata flow records | Shows that a session exists, not what it carries inside |
| Process Creation (DC0032) | Tunneling utilities or unexpected binaries starting outbound listeners or forwarding sessions on a host | Wazuh agents with auditd or Sysmon-equivalent logging, Velociraptor hunts | Depends on process auditing being enabled on each endpoint and on ESXi or network device coverage being limited |
| Network Traffic Flow (DC0078) | Byte volume, duration and directionality patterns that differ from the host baseline, such as steady small packets over a long session | Zeek conn.log, Suricata flow events, Security Onion dashboards | Flow metadata alone can be ambiguous, so pair it with a baseline per host and segment |
| Network Traffic Content (DC0085) | Protocol mismatches, such as a non-web protocol carried over a web port, or payload structure that does not match the declared protocol | Zeek protocol analyzers, Suricata application-layer parsers | Encrypted payloads are opaque without SSL/TLS Inspection or key access; confirm decryption coverage and sensor placement in your own environment |
Detection logic for T1572 described in words
Protocol tunneling hides one protocol inside another, so the signals sit in the mismatch between what a port or process is expected to carry and what the traffic actually looks like. The cards below describe four detection ideas that cover network flows, endpoint process behavior and the ESXi management plane, each with the tuning and false positive sources to review before alerts reach an analyst.
Unexpected protocol on a known port
This logic flags a session on a port whose usual service is different from the protocol observed, for example encrypted or tunneled payloads on ports normally used for plain web or DNS traffic. Build the baseline from Network Traffic Flow and Network Traffic Content for your own segments, then tune per port and per zone rather than globally. The key check is whether the protocol identified by inspection matches the registered service for that port. Expect false positives from VPN clients, backup agents and remote support tools that legitimately use unusual ports. Write the rule in Sigma where your SIEM supports it, and confirm the field names your log source provides.
Encapsulated traffic patterns in flows
Tunnels often produce steady, low-variance session timing, long-lived sessions with small packets, or a high ratio of outbound to inbound bytes that does not match the application. This logic scores flow records against a per-host baseline and raises alerts when several of these traits appear together. Set thresholds from observed traffic over a representative period, and review each threshold after every change to the network. Common false positives include VPN concentrators, replication jobs, monitoring agents and remote support sessions, so maintain an allow list tied to owners and change tickets.
Tunnel-capable processes opening sessions
Some tunneling is performed by ordinary utilities or interpreters that open outbound sessions on behalf of a user or service. Process Creation and Network Connection Creation events can be correlated so that a process outside its approved software inventory, or a known administrative tool running from an unusual path, is flagged when it opens a network connection. Confirm which binaries are approved on each host class before tuning. The main false positive sources are software deployment tools, VPN clients and remote support agents, which should be matched by signed publisher and install path rather than by name alone.
ESXi management plane anomalies
On ESXi hosts, tunneling is most visible when management interfaces accept sessions from unexpected sources or carry traffic volumes that do not match administrative work. Review network connection events for the management network and compare sources against the documented administrator jump hosts and monitoring systems. Flag new source addresses, off-hours sessions and sustained outbound volume from the hypervisor itself. Backup appliances, hardware monitoring and vendor remote support are the usual false positive sources, so list each approved source with its owner and review the list whenever the management network changes.
How to validate that a T1572 detection actually fires
This sequence proves, in a lab or private cyber range, that the T1572 Protocol Tunneling detections fire on the telemetry they depend on, reach the right responders, and leave a documented record of any gaps. It is the evidence a CISO or compliance lead can review before trusting the rule set in production.
Agree scope and the emulation plan
The detection owner, the red team lead and the range operator agree in writing which hosts, platforms and network segments are in scope (ESXi, Linux, macOS and Windows as applicable), which tunneling behaviors will be emulated, and which systems are off limits. The plan names the ATT&CK version the mapping targets, for example Enterprise ATT&CK 20.0, so the results can be tied to the exact technique and sub-technique definitions. The step is done when the signed plan lists the expected detections and the owner of each one.
Use a sanctioned emulation source
The team selects an emulation approach from a documented, sanctioned source rather than improvising behavior on the spot, and records its name, version and author. Where possible, the emulation is mapped to the T1572 sub-techniques the team intends to test, so each action has a traceable reference. Commands and payloads are kept in the change record inside the range and are not copied into production. The step is done when every emulated action has a sanctioned source and an identifier in the test log.
Confirm the baseline telemetry is present
Before the emulation starts, the telemetry engineer checks that the required data components are arriving in the SIEM or Wazuh indexer for each in-scope platform: Network Connection Creation, Process Creation and Network Traffic Flow, plus Network Traffic Content where the team relies on it. The check confirms field names, timestamps and host identifiers, and notes any log source that is delayed or dropped. The step is done when a written baseline lists each source as present, partial or missing.
Run the emulation and log every action
The red team or range operator runs the agreed emulation in the isolated range, with a timestamped log of each action, the host it ran on and the expected detection. The blue team does not see the plan details during this step if the exercise is meant to test detection independently, and the range observer records any deviations. The step is done when the action log and the scenario record match, with no unlogged activity on in-scope systems.
Record which telemetry appeared
After the run, the telemetry engineer compares the action log with the events actually collected, one row per action. For each row, the team records whether the expected data component appeared, whether its fields were complete and whether the event reached the correct index or data stream. Gaps in Network Connection Creation, Process Creation or Network Traffic Flow are marked separately from gaps in alert logic. The step is done when every action has a telemetry result, even if that result is no telemetry.
Measure alert firing and routing
The detection engineer checks whether each expected rule or analytic produced an alert, how long it took to appear, and whether the alert reached the intended queue, ticket or on-call route. Alerts that fired on unrelated activity during the run are noted as noise, and expected alerts that did not fire are investigated for logic, threshold or enrichment problems. The output is a table of expected versus observed alerts with routing outcomes. The step is done when each detection has a result of fired and routed, fired and misrouted, or did not fire.
Document gaps and retest after fixes
The team writes a gap register that names each missed or misrouted detection, its probable cause (missing telemetry, rule logic, suppression, routing) and an owner for the fix. Changes to rules, mappings or log collection are tested again in the range against the same emulation so the before and after results can be compared. The register, the test logs and the ATT&CK version reference form the evidence set for internal review or for an independent assessor. The step is done when every gap is closed, accepted with a documented risk decision, or scheduled with a named owner.
Tuning T1572 alerts so analysts keep trusting them
Tuning for T1572 starts with a baseline, not a suppression list. Before any tunneling alert is allowed to page someone, record what encapsulated traffic normally looks like on each network segment: which hosts open tunnels, which destination networks they reach, at what hours, and over which ports and protocols. Build this baseline from Network Connection Creation and Network Traffic Flow records over a period long enough to include month-end batch jobs and maintenance windows, and store it per segment so that a tunnel that is normal in the data center zone does not hide an unusual one in the user zone. Ask your SOC and network team to confirm which segments carry the most legitimate encapsulation, since those are where false positives will concentrate.
Sanctioned tunnels should be recorded as known, not silently ignored. Keep an allowlist with one entry per tunnel or tunnel class, and require each entry to name a technical owner, the business purpose, the source and destination systems, and the change record that approved it, such as a ticket or change request number. Typical examples include VPN concentrators, vendor remote support sessions and backup replication links, and each class should expire or be reviewed on a schedule the owner agrees to. An allowlist entry without a live owner is a blind spot, so review ownership whenever staff or vendors change. Confirm with the owners what their tunnels look like in your telemetry before writing the entries, because an allowlist built from assumptions usually misses the second tunnel a team quietly added.
After every tuning cycle, measure alert volume and compare it with the previous period, then sample a set of suppressed and retained alerts to confirm the decisions still hold. Record what changed, who approved it and which ATT&CK version the detection maps to, so that a later reviewer can trace why a rule behaves as it does. Treat a sudden drop in volume as a question to answer, not a success, because it may mean a tunnel was allowlisted too broadly or that telemetry stopped arriving. Analysts keep trusting alerts when they see that each suppression has a reason, an owner and a review date, and when the next tuning cycle is planned rather than improvised.
Mitigations for T1572: Network Intrusion Prevention and Filter Network Traffic
T1572 Protocol tunneling works by wrapping one protocol inside another so that traffic passes controls that only inspect the outer protocol. The two mitigations below act at different points: intrusion prevention looks at what the traffic contains, while filtering decides which paths exist at all. Used together, they reduce both the number of tunnels that can form and the number that go unnoticed.
Network intrusion prevention coverage
M1031 Network Intrusion Prevention describes inline inspection that can block traffic matching known or behavioral patterns. For T1572, the useful question is whether the sensor parses the inner protocol, not only the outer one. Confirm with your vendor or the open-source ruleset maintainers whether signatures and decoders exist for the tunneling protocols in your environment, such as DNS, ICMP, or SSH-based forwarding. Also confirm the sensor sees traffic on the egress path, not just on internal segments. Blind spots here are the most common gap.
Egress allow-listing by destination
M1037 Filter Network Traffic is the control that limits which hosts, ports and protocols may leave the network. Default-deny outbound rules for servers and privileged workstations remove many tunneling options before any inspection is needed. Document which destinations each workload legitimately reaches, then review exceptions on a fixed schedule. Ask your firewall or cloud network team to confirm that rules apply to both outbound and east-west flows, and that changes are logged.
Segmentation to limit tunnel reach
Network segmentation, mapped to M1030 in ATT&CK, does not stop a tunnel from forming, but it limits what a tunnel can reach. A compromised host in a restricted zone should not have a direct path to the internet or to management networks. Test segmentation by attempting cross-zone connections from a non-production host in your cyber range and recording which ones succeed. Each unexpected success is a finding to remediate.
Egress visibility for tuning rules
Filtering and prevention rules are only as good as the telemetry that shows whether they fire. Keep logs of blocked and allowed outbound sessions with source, destination, port and protocol, and retain them long enough to review trends. Ask whether DNS queries and proxy logs are forwarded to the same platform as firewall logs, since tunnels often surface first as unusual DNS or long-lived sessions to rarely seen domains. Review rule hit counts monthly to find dead rules and unexpected exceptions.
Triage and response when a tunneling alert fires
This sequence turns a protocol tunneling alert into a confirmed, scoped and contained incident with preserved evidence and a recorded lesson, so the team can decide quickly whether the tunnel is an approved administrative path or an adversary channel. It is designed to be rehearsed in a private cyber range before it is needed in production.
Confirm the alert against flow and host telemetry
The on-call analyst pulls the network flow records and the host telemetry for the source and destination around the alert time, using Network Traffic Flow and Network Connection Creation as the primary evidence. The analyst checks whether the traffic really is a tunnel, for example an encapsulated protocol carried over a port or service it does not normally use, and whether the Process Creation record shows which binary opened the connection. The step is complete when the analyst records either a confirmed tunnel with its endpoints and owning process, or a false positive with the reason written in the ticket.
Determine whether the tunnel is sanctioned
The analyst compares the confirmed endpoints, process and user against the change records, approved administrative tools and any documented VPN or bastion paths for that environment. The owner of the affected system or the network team confirms in writing whether the tunnel was authorized, and for how long. The step is complete when the ticket states one of two outcomes: sanctioned, with the approving record referenced, or unsanctioned and handed to the incident lead.
Scope affected hosts and network segments
The team identifies every host that has connected to the same external or internal endpoint, uses the same process, or shows similar encapsulated traffic over the lookback period the logging platform retains. They also map which network segments those hosts sit in and whether the tunnel crosses a zone boundary. The step is complete when the incident lead has a written list of hosts, segments and first-seen times, with any gaps in telemetry noted as open questions.
Contain at the filter layer or isolate the host
For an unsanctioned tunnel, the network team blocks the destination or the tunneling traffic at the firewall or intrusion prevention layer, and the endpoint team isolates the affected hosts only where the business owner agrees and the risk of isolation is understood. Containment actions are chosen to stop the channel while keeping enough visibility to observe any attempt to reconnect. The step is complete when the block or isolation is confirmed by a follow-up flow query showing the traffic no longer succeeds.
Preserve evidence before any clean-up
Before the process is stopped or the host is rebuilt, the forensic lead collects volatile and log evidence, including the flow records, the connection and process history, relevant file creation events and a memory or disk capture if the playbook calls for one. Each item is hashed and stored in a case repository with a chain-of-custody note. The step is complete when the case file lists every artifact, its collection time and its hash, and a second analyst has verified the list.
Eradicate the tunnel and its footholds
The response team removes the tunneling tool or service, reviews the persistence points that could recreate it, and rotates any credentials that the tunnel or the owning process could have exposed. For systems that cannot be cleaned with confidence, the team rebuilds them from a trusted image. The step is complete when a follow-up scan and telemetry review show no recurrence of the tunnel on the scoped hosts for the agreed monitoring window.
Record lessons and update detection and controls
The incident lead writes a short review covering how the alert fired, what the triage found, which detection thresholds or allow lists were wrong, and which mitigations such as Network Intrusion Prevention or Filter Network Traffic need tuning. Detection logic is versioned against the ATT&CK release in use, and the change is replayed in the cyber range before it reaches production. The step is complete when the review is filed, the tuning tickets are assigned, and the range replay has passed.
Rehearsing T1572 detection in a private cyber range
The virtualization lane checks whether hypervisor and management-plane activity is visible when tunneling originates from or moves through virtual machines. Build an isolated cluster or nested hypervisor lab that mirrors your management network, with host logging forwarded to a central collector and a Wazuh or similar agent or syslog path confirmed in advance. Injects should be described to the blue team only as scenario events, such as unexpected outbound sessions from a management-adjacent VM or a service account opening connections it has never used before. Good detection means the team can tie a Network Connection Creation record to a host, a VM and an owning account within minutes, and can state which logs were missing. Good response means isolating the affected VM without breaking the hypervisor management path. Confirm with your vendor which ESXi log categories are available in your version and whether they include connection-level detail.
- Management network baseline: Record which hosts should ever reach the hypervisor management interfaces before the exercise begins.
- Log forwarding check: Verify that host and vCenter logs reach the collector and that timestamps match across sources.
- Scenario injects: Use illustrative events, such as a VM talking to an unfamiliar external endpoint, and log the expected alert text.
- Response drill: Practice isolating a VM through a documented change path, not ad hoc console access.
- Gap register: Record any ESXi event that never reached the SIEM and assign an owner to close it.
Check that every injected event produced a searchable record with host, time and account fields populated.
The endpoint lane tests whether Linux and macOS hosts report process and connection context for tunneling activity. Prepare a small fleet of test hosts with an agent that reports process creation and outbound connections, and confirm that the agent's local retention meets the exercise window. Injects should be described as scenario events, for example a utility process that begins relaying traffic to an external address outside the approved list, or a user session that opens an unusual outbound channel on a non-standard port. Good detection links the Process Creation record to the Network Connection Creation record for the same process ID, so analysts see the parent process, user and destination together. Good response means preserving volatile evidence with an agreed collection tool before the process is stopped. Keep the lane away from production hosts and use snapshots so each run starts from the same state.
- Telemetry parity: Confirm that Linux and macOS agents report the same fields for process and connection events, or document the differences.
- Process-to-connection pivot: Test whether analysts can move from an alert to the owning process and its parent in one search.
- Scenario injects: Use illustrative relay-style activity and record the expected detection rule name and severity.
- Evidence capture: Practice collecting process and network state with Velociraptor or a comparable approved tool, and verify chain of custody notes.
- Containment: Rehearse network isolation of a single host and confirm it can be reversed.
Check that the team can explain, from the logs alone, which process opened the tunnel and why.
The Windows lane focuses on whether process and connection events are collected at the level needed to attribute tunneling activity. Build a domain-joined test set with Sysmon or an equivalent event source configured by the security team, and confirm which network and process event IDs reach the collector. Injects should be scenario events only, such as a signed binary that starts a session to an external host outside business hours, or a service that begins relaying data after a configuration change. Good detection ties the process creation event to the network connection event, then adds parent process, command context and user, all visible in the SIEM. Good response covers scoping other hosts that share the same parent process or destination, and resetting any affected account through the normal identity workflow. Document which event categories were disabled for performance reasons, because those gaps decide what the team can prove later.
- Event source configuration: Record the Sysmon or native audit policy version and the exact event categories enabled.
- Correlation test: Confirm that process and network events from the same host can be joined by process identifier and time.
- Scenario injects: Use illustrative tunneling-like activity and track whether the expected detection fires.
- Scoping drill: Practice finding other hosts with the same process name or destination within a defined look-back period.
- Account response: Rehearse credential reset and session revocation without disrupting unrelated services.
Check whether each injected event produced a single, attributable chain from process to destination.
The network lane tests whether sensors see tunneling as a flow or content pattern, even when the endpoint telemetry is incomplete. Place Zeek or Suricata sensors on a mirrored segment in the range, and confirm that Network Traffic Flow records are written and retained for the planned exercise window. Injects should describe the traffic pattern in words only, such as long-lived sessions to one external endpoint, or encapsulated traffic that does not match the expected protocol for its port. Good detection means the team can see sessions that persist unusually long, carry an unexpected volume profile, or conflict with the approved egress list, and can correlate those flows with the endpoint records. Good response includes blocking the destination at the egress control and confirming the block took effect with a follow-up flow record. Test the Network Intrusion Prevention and Filter Network Traffic controls in monitor mode first, so that the rehearsal does not disrupt the range.
- Sensor coverage: Confirm which segments are mirrored and whether the range's east-west traffic is visible.
- Flow retention: Verify the retention period for flow and content records against the exercise plan.
- Scenario injects: Describe unusual session duration and destination patterns, and record the expected rule or alert.
- Enforcement check: Move from monitor to block mode only after the team has confirmed the rule's false positive profile.
- Correlation with endpoints: Test whether a flow record can be tied to a host and process.
Check that the team can confirm the block at the egress point with evidence from the sensor, not only from the firewall console.
Questions SOC leads and detection engineers ask about T1572
How is T1572 Protocol Tunneling different from T1090 Proxy and T1095 Non-application layer protocol?
T1572 covers adversaries wrapping one protocol inside another to move traffic through a channel that the network is expected to allow, such as carrying command traffic inside a permitted protocol or a tunnel built with an existing service. T1090 Proxy focuses on relaying traffic through an intermediate system to hide the true origin or to reach other targets. T1095 Non-application layer protocol covers traffic sent over protocols without an application layer, such as raw TCP, UDP or ICMP, to carry commands. The three overlap in practice, so detections should be mapped to the technique that describes the observed behavior, and analysts should record which sub-technique they believe applies. Confirm the current descriptions and sub-techniques for the ATT&CK version you target in the ATT&CK tactic page for Command and Control.
Do Zeek and Suricata see enough traffic to detect protocol tunneling?
They see a lot, but not always the right fields. Zeek produces connection, DNS, HTTP, SSL and other protocol logs, and its connection records help spot long-lived sessions, unusual byte ratios and protocol mismatches, such as an application protocol running on a port it does not normally use. Suricata adds signature and protocol-anomaly alerts that are useful when rules match known tunnel patterns. Neither tool sees traffic that never crosses a monitored segment, so check sensor placement on east-west paths, cloud virtual networks and egress points. Also confirm whether encrypted payloads are visible at all, because that changes which detections are possible. Ask your team to document the sensor coverage map before writing rules.
How should we handle tunnels that run over encrypted channels?
Encrypted tunnels hide payload content, so detection shifts to metadata: who connects, to where, how often, how much data moves, and whether the session pattern matches the business purpose of the host. Useful signals include connections from servers that do not normally make outbound sessions, long idle sessions with steady small packets, and TLS sessions to destinations outside an approved list. Process Creation and Network Connection Creation telemetry from endpoints can link the network session to the process that opened it, which often gives more context than the traffic alone. Where policy allows, SSL/TLS inspection is a mitigation to evaluate, but it carries privacy, legal and performance trade-offs that should be decided before deployment.
How do we map detections to ATT&CK 20.0 and keep them current after new releases?
Name the ATT&CK version in every detection record, for example ATT&CK 20.0, and store the technique and sub-technique IDs alongside the rule. MITRE publishes ATT&CK content as STIX 2.1 bundles in the attack-stix-data repository, so a script can compare the technique list between versions and flag renamed, deprecated or revoked entries. ATT&CK releases can change detection strategies and data components, so review the release notes each time a new version ships, then re-test affected rules. Ask your engineering lead to assign an owner for this review so that mapping drift does not accumulate silently.
How do we measure whether our T1572 detection coverage is working?
Start by defining coverage as a set of test cases, not a percentage. Each case should name the operating system, the telemetry source, the expected log fields and the response that should follow. Validate detections in a private cyber range by replaying approved test behavior and confirming that the expected alerts fire with the right fields and reach the right queue. Track false positives and missed cases over time, and record the results against the ATT&CK version used. A coverage claim is only as strong as the test evidence behind it, so keep those records for review by internal audit or an assessor.
What telemetry should we collect on ESXi, Linux, macOS and Windows for T1572?
The ATT&CK data components referenced by Command and Control detection strategies include Network Connection Creation, Process Creation and Network Traffic Flow, and for some detections Network Traffic Content. On Linux and macOS, process and network connection events tie sessions to the responsible binary. On Windows, process creation and network connection events serve the same purpose, provided auditing is enabled and forwarded. On ESXi, confirm which host logs and network flow records your platform can export, because coverage varies by version and configuration. Check the ATT&CK updates page for changes to data components before finalizing your collection list.
Where to confirm the current T1572 mapping
Before you build or audit a detection for T1572 Protocol tunneling, confirm which ATT&CK version your program targets and check the detection strategies and mitigations for that version, not for whichever version a blog post or vendor sheet quotes. The technique page on the MITRE ATT&CK site is the starting point for the human-readable view, and the tactic context is on the Command and Control tactic page. Record the version number next to every detection in your register, because the detection strategy IDs and data component IDs used in ATT&CK v18 and later can change between releases.
Use the ATT&CK updates page to see whether T1572 or its mappings were renamed, deprecated or revoked in a release after the one your detections were written against. Each release note lists what changed, so a short review of the notes for every version you have adopted tells you whether your Network Connection Creation, Process Creation and Network Traffic Flow coverage still points at the right technique. Ask your detection engineering lead to confirm this review is part of the change process for your SIEM or Wazuh rule set.
For a machine-readable check, download the enterprise-attack bundle for your target version from the attack-stix-data repository and query it for T1572 to pull its relationships to detection strategies and mitigations, including Network Intrusion Prevention and Filter Network Traffic. Confirm the bundle's version matches your target before you trust the output, and keep the exported results with your rule documentation so auditors can see how the mapping was verified.
How DeployOpen builds T1572 detections and range exercises
DeployOpen approaches T1572 Protocol tunneling as a fixed-scope engagement inside the client's own infrastructure, with detection logic tied to the telemetry the client already collects. Each step is agreed in writing, from the first scope review through to documentation and optional ongoing support.
How we scope
- Confirm which platforms in scope run T1572 telemetry: ESXi, Linux, macOS and Windows hosts.
- Inventory existing Network Connection Creation, Process Creation and Network Traffic Flow sources in your SIEM.
- Agree the ATT&CK version the detection mapping targets before any rule work starts.
How we build
- Write detection logic in Sigma and map it to Wazuh or Security Onion rule formats in your environment.
- Tune tunneling alerts against your normal VPN, backup and remote management traffic baselines.
- Document how Network Intrusion Prevention and Filter Network Traffic controls are configured for tunneling paths.
How we hand over
- Deliver rule packs, data source mappings and validation results for each in-scope platform.
- Run a rehearsal in a private cyber range so your analysts practice T1572 detection and response.
- Provide runbooks that name the ATT&CK version, owners, escalation steps and evidence to keep.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Review detections when ATT&CK releases rename, deprecate or revoke related techniques.
- Confirm with your team which changes need a new scope and written change request before work proceeds.
