Safeguard
Application Security•

Exfiltration Over Symmetric Encrypted Non-C2 Protocol (T1048.001)

Attackers can encrypt stolen data with a shared key and send it over a protocol that is not their C2 channel. See what to detect and which network controls help.

Safeguard Security Team
3 min read

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

How attackers use it

MITRE explains that adversaries may steal data over a symmetrically encrypted network protocol other than the one used for command and control. The data may also be sent to a different network location than the main command server.

Symmetric algorithms use the same key or secret at both ends, which needs an exchange or a prior agreement on the key. Protocols that use asymmetric encryption often switch to symmetric encryption after the keys are exchanged. MITRE notes that adversaries may choose instead to share keys by hand and implement symmetric algorithms such as RC4 or AES themselves, rather than relying on what is built into a protocol. This can produce multiple layers of encryption, for example inside HTTPS, or encryption in a protocol that is normally not encrypted, such as HTTP or FTP.

The consequence for defenders is that content inspection on the wire will see only ciphertext. In some cases the outer protocol is plain, but the payload looks like random data.

How to detect it

The MITRE analytics describe:

  • Non-browser processes making outbound encrypted connections that use uncommon symmetric encryption, for example AES through PowerShell or custom scripts, to alternate external destinations.
  • Command line tools or scripts that use encryption libraries or algorithms, such as OpenSSL AES, GPG or Python with a crypto library, together with outbound file transfers.
  • On macOS, symmetric key encryption operations followed by unusual outbound connections from non-browser or scripted tools.
  • On ESXi, unexpected encrypted egress from management services such as hostd or from guest VMs, using symmetric encryption without a traditional protocol.

Combine process creation logs, which show the encryption tool and its arguments, with network connection logs that show the destination. An archive created and encrypted, then followed within minutes by an outbound transfer from the same host, is the sequence to look for. Look also for high-entropy payloads on protocols that are normally plain, such as FTP or HTTP, if your network monitoring measures that.

How to reduce the risk

MITRE lists three mitigations:

  1. Filter network traffic. Enforce proxies and dedicated servers for services such as DNS, and let only those systems use the respective ports and protocols.
  2. Network intrusion prevention. Use signatures for specific adversary infrastructure and malware at the network level.
  3. Network segmentation. Follow firewall best practice to allow only the necessary ports and traffic in and out.

Because the content is hidden, controls on where data can go matter more than controls on what is inside it.

Check your own environment

A quick checklist:

  • Which hosts can make outbound connections on non-standard ports?
  • Do you log which process opened each outbound connection?
  • Do your alerts cover archive or encryption tools run from unusual accounts or paths?

Linux, list outbound connections and their processes for review:

sudo ss -tnp state established

Quick check

Why can symmetric exfiltration produce more than one layer of encryption?

Because an attacker can encrypt the data with their own symmetric algorithm and then send it over a protocol, such as HTTPS, that adds its own encryption.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.