Most command and control traffic is now encrypted, so defenders have to find it from who is talking, how and when, rather than from what is said. MITRE ATT&CK v20 tracks this as T1573 Encrypted Channel, a Command and Control technique on Windows, Linux, macOS, ESXi and network devices: adversaries use an encryption algorithm to conceal C2 traffic rather than relying only on protections built into a protocol. It has two sub-techniques, Symmetric Cryptography (T1573.001: AES, DES, 3DES, Blowfish, RC4 and custom XOR schemes) and Asymmetric Cryptography (T1573.002: RSA and key exchange, which ATT&CK uses for TLS and SSH). This guide covers the procedure examples ATT&CK records, the v20 detection strategies, metadata and fingerprint detection, where decryption helps, and how to test it. It is for detection engineers, network security and SOC teams. For what TLS hides by design, see the Encrypted Client Hello Guide; for the protocol itself, the How TLS Works Guide.
Key takeaways
- Encryption is the default, not a red flag. ATT&CK v20 lists dozens of groups and families under T1573.002 using HTTPS, TLS over raw TCP or SSH, from Medusa Group to Cyclops Blink.
- Process plus destination beats payload. The v20 strategies start with a process that should not be making encrypted connections, or a crypto library loaded by an unexpected binary.
- Custom crypto is easier to spot than TLS. High-entropy payloads with no TLS handshake, especially on non-standard ports, stand out in flow and IDS data.
- Fingerprints survive encryption. TLS client, server, certificate and SSH fingerprints such as JA4, JA4S, JA4X and JA4SSH identify tools without decrypting anything.
- Appliances are the gap. ATT&CK records Velvet Ant using reverse SSH from load balancers and Volt Typhoon using an AES-encrypting web shell, on systems where EDR rarely runs.
What T1573 covers
ATT&CK separates encryption chosen by the adversary from protections a protocol provides anyway, but in practice the two overlap: ATT&CK places HTTPS C2 under T1573.002 as well as T1071 Application Layer Protocol, because TLS uses asymmetric cryptography to establish keys. Many families layer both, for example Cyclops Blink encrypting each message with AES-256-CBC and then sending it inside TLS.
| Sub-technique | What it is | Procedure examples in ATT&CK v20 | Detection angle |
|---|---|---|---|
| T1573.001 Symmetric Cryptography | Shared-key ciphers, often with keys hard-coded in the sample | Mustang Panda and Contagious Interview using RC4; Darkhotel using AES-256 and 3DES; RedCurl using AES-128 CBC; Volt Typhoon's Awen web shell using AES; UNC3886 malware using RC4 in RedPenguin; LockBit 3.0 using AES; StarProxy using XOR keys | High-entropy payloads with no TLS handshake, often on non-standard ports; keys in samples allow decryption of captures |
| T1573.002 Asymmetric Cryptography | Public key encryption or key exchange, including TLS and SSH | Velvet Ant reverse SSH shell; ShinyHunters SSH from a staging host to C2; FIN6 and FIN8 using Plink to build SSH tunnels; APT42 HTTPS C2 through NICECURL; Operation Wocao upgrading sockets to TLS; Uroburos using Diffie-Hellman with a pre-shared key; LunarWeb sending RSA-4096 encrypted commands | Fingerprints, certificate attributes, destination reputation, process lineage and session timing |
Related techniques: T1132 Data Encoding often wraps ciphertext so it survives text protocols, T1572 Protocol Tunneling covers SSH and other tunnels carrying other traffic, and T1571 Non-Standard Port covers encrypted traffic on unusual ports. See the T1572 Protocol Tunnelling Defensive Guide and MITRE ATT&CK T1571 Non-Standard Port.
Cases worth knowing
- Velvet Ant: Sygnia describes legacy F5 BIG-IP load balancers, outside the corporate firewall and running outdated firmware, opening a reverse SSH tunnel to the attacker. After remediation the actor reconfigured PlugX on a file server as an internal C2 that the F5 reached on a high port, blending with internal traffic. Dwell time was about three years.
- Volt Typhoon: ATT&CK records an Awen web shell variant using AES encryption and decryption for C2, which hides commands inside ordinary HTTPS requests to an internet-facing server. See the Volt Typhoon Threat Actor Profile.
- KV Botnet Activity: ATT&CK records C2 that transmits an RSA public key from the server, followed by further negotiation stages, on compromised small office routers.
- 3CX supply chain attack: ATT&CK records the VEILEDSIGNAL communication module under T1573.001 in the campaign it attributes to AppleJeus.
- Frameworks: commercial and open source C2 frameworks default to TLS or encrypted profiles. See the Sliver, Havoc and Brute Ratel C2 Frameworks Detection Guide and the Cobalt Strike Abuse Detection Guide.
What to detect and where: the v20 detection strategies
ATT&CK v20 ships DET0273 for T1573, DET0143 for T1573.001 and DET0543 for T1573.002, with analytics for all five platforms.
| Platform | What v20 looks for | Data sources named in v20 |
|---|---|---|
| Windows | Processes that do not normally make network connections opening TLS sessions; unexpected loads of crypto libraries (bcryptprimitives.dll for symmetric, rsaenh.dll or crypt32.dll for asymmetric) followed by outbound connections with high-entropy payloads or unusual certificate chains | Sysmon 7 (image load), Sysmon 3 and 22 |
| Linux | curl, wget, python, socat or custom binaries linked to libssl or libcrypto making outbound encrypted sessions; daemons that never talk externally starting TLS | auditd execve, socket and connect; syslog; osquery |
| macOS | launchd jobs or apps calling Security framework crypto APIs, then TLS to rare hosts or self-signed certificates | Unified log |
| ESXi | hostd or vpxa opening encrypted sessions to anything other than vCenter, update servers or known internal services | vpxd logs, vmkernel, esxcli network data |
| Network devices | TLS on ports not normally encrypted (v20 gives 8080 and 53 as examples), high-entropy flows without a TLS handshake, asymmetric byte ratios, malformed certificates or invalid CAs | NetFlow or IPFIX, network sensor connection and TLS logs |
Metadata that still works on encrypted traffic
- TLS client and server fingerprints: JA4 fingerprints the TLS ClientHello and JA4S the server response; a known C2 framework or a script runtime talking to an unknown destination is a lead. The FoxIO repository lists support in Zeek, Wireshark and Arkime, with Suricata support under development, and JA4 alone in several CDNs and cloud WAFs. JA4 is BSD 3-Clause licensed; the other JA4+ methods use the FoxIO License 1.1, which matters for commercial use.
- Certificates: JA4X fingerprints how a certificate was generated; self-signed, very new, short-lived or default-subject certificates on rare destinations are worth review. See the Certificate Transparency Guide.
- SSH sessions: JA4SSH describes SSH session behaviour, which helps separate interactive reverse shells from file transfer and automation.
- Timing and volume: beacon regularity and long-lived low-volume sessions are visible in flow data. See the Beaconing and C2 Detection Guide and the NetFlow and IPFIX Flow Telemetry Guide.
- Handshake absence: on ports where TLS is expected, a high-entropy stream that never performs a handshake is custom symmetric crypto, which v20's network device analytic calls out.
Mitigations
ATT&CK v20 lists M1031 Network Intrusion Prevention for the technique and both sub-techniques, and M1020 SSL/TLS Inspection for the parent and for T1573.002, to see inside encrypted sessions for network indicators of malware protocols. Inspection does not help with custom symmetric encryption carried inside the decrypted stream, and it introduces its own risks, so the controls below, which are NHI Mgmt Group recommendations, start with reducing who can make encrypted connections at all.
- Default deny egress for servers and appliances: load balancers, VPN concentrators, hypervisors and servers reach only named destinations (NIST SP 800-53 SC-7(5)). Velvet Ant's reverse SSH worked because the appliances could reach the internet directly. See M1037 Filter Network Traffic.
- Route user and server web traffic through authenticated proxies: (SC-7(8)) so every TLS session has an identity, a destination category and a fingerprint in the log.
- Inspect selectively: decrypt uncategorised, newly registered and server-originated traffic where law and policy allow; keep pinned and sensitive categories exempt. See M1020 SSL/TLS Inspection and the TLS Inspection Guide.
- Control outbound SSH: allow SSH out only from named jump hosts; block Plink and other unapproved SSH clients with application control on Windows servers.
- Keep signatures and fingerprint lists current: IDS rules and fingerprint blocklists for known frameworks under M1031. See M1031 Network Intrusion Prevention.
- Harden and monitor edge devices: patch or retire end-of-life appliances and forward their operating system logs, as Sygnia recommends.
Rolling it out and testing
- Inventory egress per server tier and appliance; run deny rules in log-only mode for two weeks.
- Enforce for appliances and hypervisors first, then server tiers, with the previous rule set kept for rollback.
- Deploy fingerprint and process-library analytics in alert mode and build an allowlist of approved agents (backup, monitoring, update clients).
- In an authorised exercise, emulate a TLS beacon, a reverse SSH session and a custom-encrypted TCP stream from lab hosts, and confirm each is detected.
Choosing an approach: smaller organisations gain most from egress control and a proxy or secure web gateway with logging. Larger ones should add TLS and SSH fingerprinting on network sensors, process-to-connection correlation from EDR and selective decryption.
Where identity fits
Encrypted C2 carries stolen identities as easily as commands, and some of the most useful controls are identity controls. The interception CA used for TLS inspection and the private keys of your own services are high-value non-human credentials: protect them like tier zero. SSH keys deserve the same treatment, because a reverse SSH tunnel from an appliance often runs on keys nobody inventories. See the mTLS Guide and the Leaked TLS Private Key Response guide.
Detection and measurement
- Egress coverage: share of servers, appliances and hypervisors under deny-by-default egress.
- Fingerprint coverage: share of internet egress points logging TLS and SSH fingerprints.
- Unknown fingerprints: count of new client fingerprints per week from servers, trending down as allowlists mature.
- Emulation results: TLS, SSH and custom-crypto test channels detected within one hour.
- Appliance logging: share of edge devices forwarding operating system logs.
Common failure patterns
- Treating decryption as the whole strategy: custom encryption inside TLS and pinned clients still hide content; metadata detection is needed anyway.
- Open egress from appliances: edge devices outside the firewall reach anything, as in the Velvet Ant case.
- Allowing outbound SSH everywhere: reverse tunnels look like routine administration.
- Static JA3-style blocklists only: fingerprints change with libraries and versions; pair them with process context and destination age.
- Ignoring internal encrypted C2: internal relays on high ports, like the PlugX file server, never cross the perimeter sensor.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK v20 | T1573, T1573.001, T1573.002; DET0273, DET0143, DET0543; M1031, M1020 | Technique, detection strategies, mitigations |
| MITRE D3FEND (related techniques) | D3-NTA Network Traffic Analysis; D3-PMAD Protocol Metadata Anomaly Detection; D3-RTSD Remote Terminal Session Detection; D3-OTF Outbound Traffic Filtering | Metadata analysis, SSH session detection, egress control |
| NIST SP 800-53 Rev. 5 | SC-7(5); SC-7(8); SI-4(4); SI-4(11) | Egress control, proxies, traffic monitoring and anomaly analysis |
| NIST CSF 2.0 | DE.CM-01; PR.IR-01 | Monitor networks; protect networks from unauthorised use |
| CIS Controls v8.1 | 13.3 Deploy a Network Intrusion Detection Solution; 13.6 Collect Network Traffic Flow Logs | Sensors and flow telemetry |
| ISO/IEC 27001:2022 Annex A | 8.16 Monitoring activities; 8.20 Networks security; 8.24 Use of cryptography | Monitoring, network control, governance of your own keys |
Practitioner checklist
- Apply deny-by-default egress to appliances, hypervisors and servers.
- Send web traffic through authenticated, logging proxies.
- Log TLS and SSH fingerprints and certificate attributes at egress.
- Correlate crypto library loads and process lineage with outbound sessions.
- Flag high-entropy flows without a TLS handshake and TLS on unusual ports.
- Restrict outbound SSH to named jump hosts and block unapproved SSH clients.
- Decrypt selectively where lawful, with a governed exemption list.
- Test with authorised TLS, SSH and custom-crypto emulation each quarter.
Standards and references
- MITRE ATT&CK: Encrypted Channel (T1573)
- MITRE ATT&CK: Symmetric Cryptography (T1573.001)
- MITRE ATT&CK: Asymmetric Cryptography (T1573.002)
- MITRE ATT&CK: SSL/TLS Inspection (M1020)
- FoxIO: JA4+ network fingerprinting
- Sygnia: China-Nexus Threat Group Velvet Ant
- MITRE D3FEND: Protocol Metadata Anomaly Detection
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: ATT&CK Command and Control Tactic · Mobile T1521 Encrypted Channel · MITRE ATT&CK T1071 Application Layer Protocol · NDR Guide · MITRE ATT&CK T1132 Data Encoding · MITRE ATT&CK T1001 Data Obfuscation · MITRE ATT&CK T1104 Multi-Stage Channels · MITRE ATT&CK T1568 Dynamic Resolution