Exfiltration Over Unencrypted Non-C2 Protocol is ATT&CK T1048.003, a sub-technique of exfiltration over an alternative protocol. It applies to ESXi, Linux, macOS, Network Devices and Windows.
How attackers use it
MITRE explains that adversaries may steal data over an unencrypted network protocol other than the command and control channel, and may send it to a different location than the main command server. Adversaries may obfuscate the data, without encrypting it, inside protocols that are natively unencrypted, such as HTTP, FTP or DNS. That can include custom or public encoding and compression, such as base64, and embedding data inside protocol headers and fields.
The procedure examples are varied: HTTP POST requests to attacker infrastructure, malware with routines for SMTP, FTP and HTTP, a backdoor that encoded data in the subdomain field of DNS packets, FTP used to send files separately from the command channel, BITS jobs used to upload files, and exfiltration through DNS lookups in one campaign. A short list of protocols is enough to cover most of it.
How to detect it
The MITRE analytics describe data access or staging followed by an outbound flow over an unencrypted protocol:
- Unexpected processes, or rare destinations, sending data over FTP or HTTP right after file access or staging.
- File access or compression tools followed by outbound connections made with curl, wget, ftp or custom binaries.
- Abnormal outbound HTTP or FTP connections from local scripts or binaries rather than a browser, after access to local documents.
- On ESXi, shell scripts that read configuration files or snapshots and send them over FTP or HTTP to non-management addresses.
- On network devices, unencrypted protocols such as TFTP, FTP or HTTP used to move configuration files, routing tables or logs to untrusted addresses, for example with a copy running-config to FTP style command.
Because the protocol is plain, you can do more here than with encrypted channels. Network monitoring can inspect payloads, flag base64 blobs in HTTP, and flag DNS queries that are very long or have an unusual volume to a single domain. DNS logs are the data source to start with.
How to reduce the risk
MITRE lists four mitigations:
- Network intrusion prevention. Signature-based tools can identify traffic for specific adversary infrastructure and malware.
- Data loss prevention. It can detect and block sensitive data sent over unencrypted protocols.
- Filter network traffic. Enforce proxies and dedicated servers for services such as DNS, and let only those systems use those ports and protocols.
- Network segmentation. Allow only the ports and traffic that are necessary.
The simplest win is to block outbound FTP, TFTP and unproxied HTTP from servers, and to let only your resolvers talk DNS to the internet.
Check your own environment
Linux, see which hosts and processes are using plain FTP or HTTP right now:
sudo lsof -i :21 -i :80 -nP
A checklist:
- Is outbound FTP and TFTP blocked at your egress?
- Can any internal host query an external DNS server directly?
- Do your network devices send configuration to FTP or TFTP servers, and are those servers yours?
Quick check
How can data hide inside DNS?
MITRE describes encoding data into protocol fields, and a procedure example puts it in the subdomain field of DNS packets. Long or high-volume queries to one domain are the typical sign.
