Exfiltration Over Alternative Protocol is ATT&CK T1048. It belongs to the Exfiltration tactic and applies to ESXi, IaaS, Linux, macOS, Network Devices, Office Suite, SaaS and Windows.
The related technique, exfiltration over the C2 channel, sends data through the same channel an attacker controls the host with. This one does the opposite: data leaves over a different protocol than the command channel, or to a different place than the main server.
How attackers use it
MITRE lists the alternate protocols as FTP, SMTP, HTTP and HTTPS, DNS, SMB, or any other network protocol not used as the main command channel. Adversaries may encrypt or obfuscate those channels too. Common operating system utilities can do the job: net and SMB, FTP, and on macOS and Linux curl, which can use HTTP, HTTPS, FTP or FTPS.
The platform list shows another face of the technique. Many IaaS and SaaS platforms, such as Microsoft Exchange, Microsoft SharePoint, GitHub and AWS S3, support direct download of files, emails, source code and other sensitive data through the web console or the cloud API. In those cases the exfiltration uses a legitimate service interface.
The procedure examples include a tool that downloads cloud user data such as OneDrive files, a macOS adware family that uses the curl command to upload archived data to a URL, point-of-sale malware using DNS tunneling for card data, a backdoor sending credentials over UDP, a group using WinSCP to send data to accounts it controls, and a tool that exfiltrated information through an email account.
Three sub-techniques split this by encryption type: symmetric encrypted, asymmetric encrypted and unencrypted non-C2 protocols. Each has its own post in this series.
How to detect it
The MITRE detection strategy has an analytic per environment:
- Windows: unusual outbound file transfer behavior using protocols such as FTP, SMB, SMTP or DNS, involving non-standard processes, off-hours activity or unusually high volume.
- Linux: file exfiltration with curl, scp or custom binaries over FTP, HTTP or HTTPS or DNS tunneling, especially outside the user's baseline.
- macOS: non-native file transfer with curl, Python scripts or AppleScript, using uncommon protocols such as FTP or SMTP, or DNS exfiltration through mDNSResponder abuse.
- Cloud: cloud APIs or CLI tools used to move or sync files from sensitive buckets to external endpoints over HTTPS or S3 APIs.
- ESXi: outbound traffic from hostd, vpxa or guest VM interfaces using unauthorized protocols such as FTP, bursts of HTTP POST, or long-lived DNS tunnels.
A short list of data sources that make these analytics possible:
- Firewall and proxy logs with destination, port and bytes out.
- DNS query logs, to catch very long names, high query volume to one domain or unusual record types.
- Email gateway logs for outbound mail from hosts that are not mail servers.
- Endpoint network connection logs with the process name.
- Cloud audit logs and storage access logs, with attention to downloads from sensitive buckets by unusual principals or from unusual networks.
The theme is mismatch: a process, protocol or destination that does not fit that host. A database server that suddenly speaks FTP is a finding. So is a workstation sending SMTP directly to the internet.
How to reduce the risk
MITRE lists five mitigations:
- Network segmentation. Follow firewall best practice and allow only the ports and traffic that need to enter and leave.
- Data loss prevention. It can detect and block sensitive data uploaded through web browsers.
- Filter network traffic. Enforce proxies and use dedicated servers for services such as DNS, and let only those systems use those ports and protocols, rather than every system on the network. Cloud providers support IP-based restrictions, so consider an IP allow list together with account management so that data access is limited to valid users from expected networks.
- Network intrusion prevention. Signature-based systems can identify traffic for specific adversary infrastructure and malware.
- Restrict file and directory permissions. Use access control lists on cloud storage systems and objects.
Default deny egress is the central idea. If hosts can only speak to the destinations and protocols they need, most alternate protocols stop working.
Check your own environment
Linux or macOS, list established outbound connections with the owning process, and look for processes you do not expect to talk to the internet:
sudo lsof -i -nP | grep ESTABLISHED
Windows PowerShell, the same view:
Get-NetTCPConnection -State Established |
Select-Object RemoteAddress, RemotePort, @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}}
Policy questions:
- Which of your servers are allowed to reach the internet at all, and on which ports?
- Do only your resolvers send DNS to the outside, or can any host do it?
- Can any host send mail directly instead of through your gateway?
- Do your cloud storage buckets restrict access by network and by identity, and do you log reads?
Quick check
How does this technique differ from exfiltration over the C2 channel?
Here the data goes out over a different protocol than the command channel, or to a different location than the main command server.
Why do cloud platforms appear in the platform list?
Services such as Exchange, SharePoint, GitHub and S3 let users download files, mail and code directly through the console or API, which can be abused to take data out through a legitimate interface.