Exfiltration Over Alternative Protocol

This technique covers exfiltrating data over a protocol other than the attacker's primary command-and-control channel: sending stolen data out via FTP, SMTP, a separate encrypted channel, or any protocol distinct from however the attacker is otherwise controlling the compromised host.

The idea is separation: keeping exfiltration traffic on a different channel than C2 traffic can evade detections built around monitoring one specific channel closely, and can blend into protocols that already carry high volumes of legitimate traffic.

Once an attacker has staged the data they want (a payroll export, a customer database dump, source code), they need it off the network. Rather than pushing it back over the same channel they're using for commands, which may be closely watched or bandwidth-limited, they use a separate protocol, sometimes one already permitted by network policy for entirely different reasons (a mail relay, an FTP server used for vendor data exchange).

This is typically a late-stage action. It happens after reconnaissance, credential access, and lateral movement have already located and staged the target data.

Data source: host network-connection telemetry naming the sending process (Sysmon Event ID 3) and the bytes sent each way, plus the TLS or DNS record naming the destination

{
  "host": {
    "name": "WKSTN01"
  },
  "event": {
    "action": "network_flow",
    "category": "network"
  },
  "network": {
    "protocol": "ftp"
  },
  "destination": {
    "ip": "203.0.113.44",
    "port": 21,
    "bytes": 48302911
  }
}

Prebuilt Elastic rule: Potential Data Exfiltration Activity to an Unusual Destination Port

Because there's no single "exfiltration protocol" to filter for, the hunt is about volume and novelty: a host sending an unusually large amount of data (relative to its own baseline) to a destination port or IP it hasn't talked to before is the core pattern, regardless of which specific protocol carries it.

Hunting manually: sort outbound network events by destination.bytes descending, then cross-reference against each source host's normal traffic profile. A workstation that typically only talks to internal file shares and web proxies, suddenly sending a large payload to an external IP on an unusual port, is the thing worth chasing.

Large or unusual-protocol transfers happen for entirely benign reasons constantly: backup jobs, software updates, legitimate vendor data exchanges over FTP, cloud sync tools.

The distinguishing signal is whether the transfer matches an established, expected pattern for that host and account. A backup server sending large transfers on a nightly schedule to a known destination is normal; the same volume from a single user workstation, to a destination it's never contacted before, outside of any known business process, is what warrants escalation. Maintain a baseline of which hosts are expected to move large volumes of data and to where, so genuine anomalies stand out against it.

• MITRE ATT&CK T1048: Exfiltration Over Alternative Protocol
• Elastic Security: Data Exfiltration Detection integration

1 scenario in this catalog covers T1048. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →