Reduce the risk of Exfiltration Over Alternative Protocol by restricting non-standard outbound protocols, enforcing egress filtering, and baselining which applications may use them. Inspect unusual DNS, SMB, mail, or other secondary channels for bulk transfer, and investigate protocol tunnelling, abnormal session sizes, or data leaving systems that should not communicate that way.
What to tighten first when protocol abuse is the exfiltration path
The practical starting point is to decide which applications are actually allowed to speak unusual protocols and which are not. Exfiltration over alternative protocol becomes far harder when outbound traffic is constrained to approved ports, protocols, and destinations, and when deviations are treated as suspicious rather than merely uncommon. This matters most where internal tools, admin utilities, or dual-use software can tunnel data through channels that do not normally carry business traffic.
Baselining is the control that makes the rest of the response usable. If you do not know which systems legitimately use DNS, SMB, mail, or another secondary channel for data transfer, it is difficult to separate sanctioned behaviour from covert transfer. A clean baseline lets defenders spot protocol tunnelling, abnormal session sizes, and bulk transfer patterns that do not fit the host’s role or network segment.
Because alternative-protocol exfiltration often blends into ordinary outbound noise, the same control set should answer two questions at once: what can leave the environment, and what looks materially different when it does. That is why egress filtering and application allowlisting should be evaluated together rather than as isolated hardening steps.
How to spot covert transfer without drowning in alerts
Detection should focus on behaviour, not just signatures. Inspect unusual DNS volume, SMB sessions from systems that should not use SMB externally, mail traffic carrying unexpectedly large payloads, and other secondary channels that suddenly become high-volume transport paths. The most useful signals are often the combination of protocol choice, session duration, transfer size, and the workstation or server role generating the traffic.
Protocol tunnelling is especially important to watch because it can hide inside a channel that still looks syntactically valid. A long-lived connection, repeated chunking, or data leaving a host that rarely initiates outbound transfers can indicate that the protocol is being used as a delivery mechanism rather than for its normal business purpose. For teams that need a broader reference on exfiltration patterns and telemetry, the Data Exfiltration Guide is a useful starting point.
Another useful habit is to compare protocol behaviour against the system’s business function. A file server sending a large amount of mail traffic, or an application server producing high-volume DNS, usually deserves investigation even if each individual packet looks valid. The question is not only whether the traffic is allowed by the network stack, but whether it is credible for that asset and that time.
What works when you cannot block the channel immediately
If you cannot disable the channel straight away, reduce the blast radius by narrowing where the channel can go, how much it can carry, and which processes can use it. Temporary exception handling should be explicit, time-bound, and tied to a named owner so that a one-off business dependency does not become a permanent exfiltration path. This is particularly important for legacy applications or integration tooling that rely on non-standard outbound behaviour.
When you are responding to a suspected case, prioritise investigation of the hosts that are both unusual and capable of moving data at volume. Look for recent process changes, new services, script execution, or archive activity that preceded the outbound transfer. If the data source is sensitive, containment should include checking for other channels that may have been used in parallel, not just the one that triggered the alert.
For organisations building a disciplined response workflow, the CISA cyber threat advisories page is a useful authority for tracking current actor tradecraft and response context, while the IANA registry is the right reference when you need to confirm how a protocol or port is officially defined before deciding whether it should be permitted.
Risk and Threat Considerations
Alternative-protocol exfiltration is risky because it turns a legitimate or semi-legitimate channel into a covert transport path. Defenders may be monitoring normal web egress while missing data moving through DNS, SMB, or mail, especially when the transfer is fragmented or tunneled to resemble routine traffic.
Failure mechanism: The environment allows outbound protocol diversity without a tight baseline, so an attacker can move data through a secondary channel that blends into expected network noise and bypasses simple destination or port-based controls.
Impact: Sensitive data can leave the network in small or disguised batches, detection can be delayed, and containment becomes harder because the protocol itself appears operationally normal even while it is being abused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1048 — Exfiltration Over Alternative Protocol | Directly matches the question's exfiltration technique. |
| Recommendation — Hunt for non-standard outbound transfer paths and constrain the protocols that can carry data out. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Egress filtering and approved outbound pathways are network control concerns. |
| CIS-8 — Audit Log Management | Detection depends on telemetry that exposes unusual protocol and transfer behaviour. | |
| Recommendation — Restrict outbound network paths and document approved protocol use for each segment. Centralise logs for outbound sessions and alert on abnormal protocol volume or tunnelling. | ||
| NIST CSF 2.0 | PR.PS-01 — Baseline Configuration | Baseline application protocol behaviour is central to spotting and limiting covert transfer. |
| DE.CM-01 — Network Monitoring | Unusual DNS, SMB, mail, and tunnelling activity require continuous network monitoring. | |
| Recommendation — Establish and maintain approved outbound protocol baselines for each asset class. Monitor outbound traffic for anomalous protocol use, session size, and transfer patterns. | ||
Practitioner Guidance
What to verify: Confirm that every approved non-standard outbound protocol has a named business owner, a known destination pattern, and a measurable reason to exist. If a system cannot explain why it needs the channel, treat that channel as a control exception rather than a standing allowance.
What to measure: Track how often outbound traffic departs from the approved baseline, especially by asset class. A useful signal is not just blocked traffic, but the proportion of protocol use that is attributable to sanctioned applications versus everything else.
Practitioner takeaway: The strongest mitigation is not one more alert rule, but a narrower and better-understood egress model, because covert exfiltration succeeds when the organisation cannot tell normal protocol use from abuse.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org