Encrypted Channel (T1573) is a command and control technique. The adversary uses an encryption algorithm to hide C2 traffic rather than relying on whatever protection the protocol already offers. MITRE lists ESXi, Linux, macOS, network devices and Windows.
MITRE adds one point worth remembering: even with a strong algorithm, the implementation may be vulnerable to reverse engineering if secret keys are encoded or generated inside malware samples or configuration files. Encryption hides content from you, but it can leave other clues.
How attackers use it
The technique has two sub-techniques, covered in their own posts: Symmetric Cryptography (T1573.001) and Asymmetric Cryptography (T1573.002). At the parent level, the point is that the adversary picks the cipher and the channel, so inspection of the payload tells you nothing without extra tooling.
How to detect it
MITRE's detection strategy focuses on who is talking and how the traffic looks, since content is hidden.
- Windows: processes that normally do not make network connections setting up outbound TLS or SSL sessions, especially with asymmetric volumes (the client sends more than it receives) or non-standard certificate chains. Correlate process creation with network encryption libraries loaded unexpectedly.
- Linux: curl, wget, python, socat or custom binaries starting TLS sessions to non-standard destinations. Look at connect system calls, loading of libssl, and persistent outbound encrypted traffic from daemons that do not normally talk to the outside.
- macOS: applications or launchd jobs making encrypted connections to rare external hosts, and processes not on the approved baseline calling SSL or TLS APIs.
- ESXi: VMware management daemons such as hostd or vpxa starting outbound TLS flows to destinations other than vCenter, update servers or internal systems.
- Network: TLS on ports that are not normally encrypted (MITRE's examples are 8080 and 53), with high-entropy traffic and lopsided client to server ratios, visible in NetFlow, IPFIX or packet inspection.
How to reduce the risk
MITRE lists two mitigations.
- Network intrusion prevention. Use signature-based systems to identify traffic for specific adversary malware.
- SSL/TLS inspection. Inspect encrypted sessions to look for network-based indicators of malware communication protocols.
TLS inspection carries real cost: privacy rules, certificate handling and breakage on pinned applications. Decide where it is justified, for example egress from server segments, and document the exceptions.
Check your own environment
# Linux: processes holding established connections, with the program name
ss -tpn state established
# macOS: processes with network connections
lsof -i -P -n | grep ESTABLISHED
# Windows PowerShell: established connections on ports 8080 and 53 (TLS there is unusual)
Get-NetTCPConnection -State Established | Where-Object { $_.RemotePort -in 8080,53 }
Questions to ask:
- Do you have a baseline of which processes may make outbound TLS?
- Where do you inspect TLS, and where do you deliberately not?
- Can your network sensors see byte-ratio and entropy data, or only connection counts?
Quick check
If the payload is encrypted, what can you still examine?
The process making the connection, the destination, the port, certificate chains, byte ratios between client and server, and entropy, as the MITRE analytics describe.
What does MITRE say about weaknesses in the malware's own encryption?
Implementations may be vulnerable to reverse engineering if secret keys are encoded or generated inside malware samples or configuration files.
