How do attackers use Exfiltration Over Alternative Protocol?

How attackers abuse alternative protocols to move data out

Exfiltration over alternative protocol is rarely about inventing a new channel from scratch. Attackers usually hide stolen data inside traffic that defenders already allow, because normal egress rules are often looser for DNS, email, web requests, collaboration services, or cloud APIs than for obvious file transfer paths.

The practical advantage is blend-in. If the protocol is common in the environment, the exfiltration may look like routine business traffic unless defenders compare destination patterns, payload size, timing, and frequency against a real baseline. That is why this technique often succeeds in networks where outbound traffic is inspected only for known-malicious domains or blocked file transfer tools.

Attackers also choose the channel to fit the environment they already control. DNS tunneling works when outbound name resolution is permitted. Email can be useful when mail services are trusted. Web requests, chat platforms, and webhook-style traffic can help when the environment already relies on those services, especially if the destination is a legitimate provider or a compromised tenant inside a trusted platform. For related collection and exfiltration patterns, see the Data Exfiltration Guide.

What makes this technique effective in real environments?

Attackers prefer alternative protocols because they exploit a control gap rather than a single broken product. Many organisations still focus on preventing direct uploads, removable media transfer, or obvious archive downloads, while leaving broad allowances for standard business services that can also carry data. Once the data is staged and encoded, the attacker only needs a channel that can move small but repeated chunks without triggering obvious thresholds.

Protocol abuse works best when defenders do not model the business context of egress. A large volume of DNS queries, an unusual pattern of web requests to a rarely used endpoint, or repetitive transfers to a cloud service the business does not normally use can all be early indicators. The same is true when traffic volume is modest but highly regular, because many exfiltration tools prioritise reliability over speed to avoid alarm. The threat pattern overlaps with broader compromise and stolen-credential abuse discussed in The State of NHI & AI Agent Breach Report 2026, where attackers repeatedly used legitimate-looking access paths to move data and maintain access.

Alternative protocols also let attackers trade speed for resilience. They may fragment data, compress it, encode it into allowed fields, or schedule transfers during normal business hours. That means detection has to look for anomalies in destination, structure, and cadence, not just for one-off high-volume uploads.

Detection points that matter most

Effective detection starts with understanding which outbound protocols and services are normal for the environment and which are only tolerated by exception. Monitoring should focus on destinations, not just ports, because exfiltration often rides over standard web or mail infrastructure. It also helps to baseline normal payload size, query length, request rate, and the volume of data each service usually carries.

Defenders should correlate egress telemetry with endpoint activity. A host that suddenly compresses archives, stages files, or performs repeated outbound lookups before making many small requests is more suspicious than either signal alone. DNS exfiltration often stands out through long subdomains, high query volume, or a concentration of requests to one domain. Web-based exfiltration often appears as repetitive POSTs, odd user agents, or traffic to services the host has never used before.

Because the channel is usually allowed, blocking alone is rarely enough. Teams need to decide whether the right response is alerting, throttling, inspection, or selective blocking by service, tenant, or domain. That decision depends on whether the protocol is mission-critical or merely convenient.

Practitioner Guidance

What to verify: Confirm which outbound protocols are genuinely required by the business, then compare actual traffic against that list. If a protocol is allowed by policy but not by necessity, it is a candidate for tighter inspection or narrower egress rules.

Decision rule: If the exfiltration path uses a service the organisation actively depends on, prioritise detection and scoped policy changes over blanket blocking. If the protocol is not business-essential, reduce exposure by restricting destinations, tightening content inspection, and alerting on unusual volume or cadence.

What to measure: Track destination rarity, protocol entropy, request frequency, and outbound volume by host and by service. Those measures are usually more useful than a simple count of blocked transfers because this technique is designed to look permitted.

Practitioner takeaway: Treat alternative-protocol exfiltration as an egress-governance problem, not just a malware problem, because the strongest signal is often the mismatch between what the business normally sends and what the attacker is trying to hide.

Related resources from NHI Mgmt Group

• How do attackers use exfiltration over a symmetric encrypted non-C2 protocol?
• How do attackers use exfiltration over other network medium?
• How do attackers use Exfiltration Over Web Service?
• How do attackers use Exfiltration Over Webhook?