Exfiltration Over Asymmetric Encrypted Non-C2 Protocol (T1048.002)

Exfiltration Over Asymmetric Encrypted Non-C2 Protocol is ATT&CK T1048.002, a sub-technique of exfiltration over an alternative protocol. It applies to ESXi, Linux, macOS and Windows.

How attackers use it

MITRE explains that adversaries may steal data over an asymmetrically encrypted network protocol that is different from the command and control channel, and may send it to a different location than the main command server. Asymmetric encryption, also called public-key cryptography, uses a key pair. Each end holds its own private key and has the other side's public key. Protocols such as HTTPS, TLS and SSL use it, and then often switch to symmetric encryption once the keys are exchanged. The adversary simply uses the encryption that is already built into the protocol.

This is the easiest variant to blend in. Encrypted web and file transfer traffic is normal, so the traffic itself does not look odd.

Procedure examples include archives of collected data sent over HTTPS from a staged location on an Outlook Web Access server, a custom protocol carried over HTTPS, mail sent over SMTPS, SFTP used for file exfiltration, and the Rclone tool, which can send data over SFTP or over HTTPS using WebDAV.

How to detect it

The MITRE analytics focus on the context around the encrypted connection, since the content is not readable:

• Non-browser processes establishing encrypted outbound connections, such as TLS, to unfamiliar or atypical destinations for that host or user, following a data staging or compression event.
• Staged file access, such as archiving or obfuscation, followed by an encrypted outbound connection from unusual processes such as curl, wget, Python scripts or custom binaries.
• On ESXi, unexpected encrypted outbound connections from management components or guest VMs, particularly after data volume spikes.

Useful data: endpoint connection logs that name the process, proxy logs with destination domain and bytes out, TLS metadata such as server name and certificate details, and logs of file access and archive creation on the same host. The chain matters more than any single event: files gathered, archive made, big upload to a rare destination.

How to reduce the risk

MITRE lists four mitigations:

1. Network intrusion prevention. Signature-based tools can identify traffic for specific adversary infrastructure and malware.
2. Network segmentation. Follow firewall best practice to allow only the necessary ports and traffic.
3. Filter network traffic. Enforce proxies and dedicated servers for services such as DNS, and let only those systems use those ports and protocols.
4. Data loss prevention. It can detect and block sensitive data uploaded through web browsers.

Routing outbound web traffic through a proxy, and blocking direct connections from servers to the internet, takes away the easiest paths. Allow lists for the destinations of servers are even stronger.

Check your own environment

Linux or macOS, review established connections on port 443 and 22 with their owning processes:

sudo lsof -i :443 -i :22 -nP | grep ESTABLISHED

Questions to take back:

• Can your servers open arbitrary outbound connections on 443 and 22, or only to listed destinations?
• Do you inspect or at least log the server name in outbound TLS?
• Would you notice a large upload from a host that normally sends little?

Quick check

Sources

• MITRE ATT&CK T1048.002: Exfiltration Over Asymmetric Encrypted Non-C2 Protocol