What happens when attackers use common network protocols for data exfiltration?

Attackers can hide stolen data inside traffic that defenders already allow, such as DNS queries, HTTP requests, file transfer sessions, or Git traffic. That makes the exfiltration harder to distinguish from legitimate operations and reduces the chance of immediate blocking. In practice, the abuse succeeds because trusted protocols often pass firewalls and are not monitored with enough detail.

How Common Protocol Abuse Changes the Exfiltration Problem

When attackers piggyback on allowed protocols, the main shift is not the destination of the data but the trust context it travels in. DNS, HTTP, file transfer sessions, and Git traffic are often already permitted, so the exfiltration blends into routine business traffic and can slip past coarse controls that only block obvious outbound channels.

That matters because defenders rarely see protocol abuse as a single event. The attack usually succeeds by shaping the payload, request size, timing, and destination so the traffic looks operational rather than malicious. The protocol is the delivery vehicle, but the real issue is that monitoring and policy enforcement are often tuned to the protocol name, not to abnormal usage of that protocol.

For a practitioner, the key distinction is between “allowed protocol” and “allowed use.” The former is a network rule; the latter is a behavioural judgment that requires visibility into patterns such as repeated lookups, unusual POST bodies, abnormal repository activity, or transfers that do not match the host’s normal role. A well-formed exfiltration stream can still be suspicious if it does not fit the asset’s expected communication profile.

One useful internal reference is The 52 NHI breaches Report, which shows how stolen credentials and compromised access paths repeatedly enable lateral movement and data theft once an attacker is inside a trusted trust boundary.

For protocol behaviour itself, the best external baseline is the protocol standards and registries maintained by the IETF and IANA, because they define what “normal” protocol structure and assigned parameters look like before defenders add their own monitoring rules.

Why DNS, HTTP, Git, and File Transfer Are Popular Exfiltration Paths

Attackers favor these protocols because they are common, widely routed, and often essential to business operations. DNS is especially attractive when the goal is low-volume, hard-to-notice leakage, while HTTP can carry larger payloads and blend with browser-like traffic. File transfer sessions and Git traffic are appealing because many environments already permit them for collaboration, deployment, or software delivery.

The choice of protocol also affects how much data can be moved, how quickly it can be moved, and how easy it is to detect. High-chatter protocols can support many small chunks of exfiltrated data, while richer application protocols can hide data in headers, URLs, request bodies, or repository activity. That means defenders need protocol-specific detection logic instead of assuming one outbound filter covers every path.

This is where network inspection should focus on context, not just port numbers. A Git push from a build server may be normal, but Git-like traffic from a workstation with no development role is a different signal. Likewise, DNS requests that are unusually long, highly repetitive, or encoded in a pattern can indicate data movement rather than name resolution.

An internal example of the same trust problem is Sisense breach, where unauthorized access led to theft of access tokens, API keys, and certificates, illustrating how trusted access paths can become channels for downstream data loss.

For defenders who want a broader threat framing, CISA cyber threat advisories remain useful for tracking current abuse patterns and deciding which protocol anomalies deserve escalation.

Risk and Threat Considerations

Common-protocol exfiltration is risky because it exploits the same pathways used for legitimate business traffic. If those pathways are not strongly baselined, an attacker can move data out with low friction and low visibility, especially where egress filtering is broad and inspection is shallow.

Failure mechanism: The defender trusts the protocol category instead of the traffic behaviour, so malicious content is permitted as long as it appears inside an approved session or approved destination pattern.

Impact: Data theft can continue for longer, alerts arrive late or not at all, and the organisation may only detect the loss after the exfiltrated data is already outside the environment.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address 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	Models attacker use of allowed protocols to move data out covertly.
	T1071 — Application Layer Protocol	Covers hiding command or data in legitimate application protocol traffic.
Recommendation — Detect and constrain outbound data movement that uses nonstandard or approved protocols. Inspect application-layer traffic for protocol abuse and abnormal payload patterns.
CIS Controls v8	CIS 13 — Network Monitoring and Defense	Directly supports detecting abnormal outbound traffic and protocol misuse.
Recommendation — Monitor outbound protocol usage and alert on unexpected volume, destinations, or encoding.
NIST CSF 2.0	DE.CM — Continuous Monitoring	Supports ongoing visibility into outbound traffic patterns and anomalies.
	PR.AC — Identity Management, Authentication, and Access Control	Relevant because exfiltration often follows abuse of trusted access paths and permissions.
	DE.AE — Anomalies and Events	Maps to spotting unusual protocol behavior that signals covert exfiltration.
Recommendation — Continuously monitor network behavior to identify anomalous exfiltration patterns. Restrict who and what can initiate data transfer paths that reach external networks. Flag protocol anomalies that indicate disguised outbound data movement.

Practitioner Guidance

What to verify: Baseline the assets that should be using DNS, HTTP, Git, or file transfer, then compare actual volume, frequency, destination, and payload structure against that expected role. A protocol is only benign when its use matches the host’s function and history.

What good looks like: You can distinguish normal and abnormal use of an allowed protocol without relying solely on blocklists. That usually means combining egress policy, content inspection where appropriate, and detection rules for unusual repetition, encoding, transfer timing, and destination entropy.

Practitioner takeaway: The practical defence is to treat protocol allowance as a starting point, not a trust decision, because exfiltration often succeeds by remaining inside the shape of ordinary traffic.