Over 90% of C2 communications hide behind encrypted channels, making traditional deep packet inspection largely ineffective. TLS 1.3 further compounds this problem by encrypting certificate details, cipher suites, and server names that previously provided detection opportunities. Adversaries ranging from commodity infostealers to the FSB's flagship Snake malware use encryption to make their C2 traffic indistinguishable from legitimate web browsing, cloud service usage, and enterprise application traffic. T1573 has two sub-techniques: Symmetric Cryptography (T1573.001) and Asymmetric Cryptography (T1573.002). The critical defensive shift is from payload inspection to behavioral analysis — detecting the patterns of encrypted C2 communication rather than decrypting and reading its contents.
T1573 falls under the Command and Control tactic (TA0011) and covers any use of encryption algorithms to conceal C2 traffic beyond the inherent protections of the communication protocol itself. This includes malware that establishes TLS sessions with self-signed certificates, implants that layer custom AES or ChaCha20 encryption on top of HTTP traffic, backdoors that use RSA key exchange for forward secrecy, and sophisticated platforms like Snake that combine custom encryption with traffic fragmentation and peer-to-peer relay networks. The technique spans Windows, Linux, macOS, ESXi, and network devices. Despite the use of strong encryption algorithms, adversary implementations are often vulnerable to reverse engineering when secret keys are hardcoded in malware samples or derived from predictable configuration data.
MITRE ATT&CK v18 documents dozens of threat groups and over a hundred malware families using T1573, making it one of the most widely adopted C2 techniques in the framework. The list of procedure examples reads as a who's-who of advanced threats: APT29, APT41, Turla, Lazarus Group, FIN7, and essentially every commercially available red team framework including Cobalt Strike, Sliver, and Havoc.
The Two Sub-Techniques
T1573.001 — Symmetric Cryptography
Adversaries use symmetric encryption algorithms — where the same key encrypts and decrypts data — to conceal C2 communications. Common implementations include AES (128-bit and 256-bit), ChaCha20, RC4, XOR-based ciphers, and CAST-128. Symmetric encryption is computationally efficient and widely used for bulk data encryption within C2 sessions.
The practical challenge for defenders is that symmetric keys must be stored somewhere accessible to the malware. The FSB's Snake malware used CAST-128 encryption with keys stored in Windows registry blobs — the FBI and Five Eyes agencies ultimately leveraged this implementation detail to decrypt Snake communications and develop the PERSEUS tool that issued self-destruct commands to infected systems during Operation MEDUSA. APT41's TOUGHPROGRESS uses a hardcoded 10-byte XOR key combined with per-message 4-byte XOR keys to encrypt data stored in Google Calendar events. Cobalt Strike Beacon encrypts its C2 traffic using AES-256 in CBC mode, with session keys derived from an RSA handshake. The Medusa ransomware group uses encrypted C2 channels for coordinating its double-extortion operations across more than 300 victims as documented in the March 2025 CISA advisory.
XOR-based encryption remains common in commodity malware due to its simplicity, though it provides weaker protection than standard algorithms. Researchers have observed RATs communicating via fake TLS to C2 servers, using XOR-obfuscated payloads and generating unique identifiers per compromised machine. The GhostWeaver RAT maintains communication with its C2 server using TLS encryption for secure interactions, while PureRAT uses .NET Reactor obfuscation and encrypted communications over TLS combined with fileless execution to evade detection.
T1573.002 — Asymmetric Cryptography
Adversaries use asymmetric encryption — where a public key encrypts data and a private key decrypts it — to secure C2 communications. Common algorithms include RSA (2048-bit and 4096-bit) and elliptic curve cryptography. Asymmetric cryptography is often used for initial key exchange or session establishment, after which communication switches to faster symmetric encryption for bulk data transfer. This hybrid approach mirrors the legitimate TLS handshake and is used by Cobalt Strike, Sliver, Havoc, and many custom implants.
Sliver C2 framework uses mutual TLS (mTLS) authentication with randomly generated certificates containing over 400 lines of code dedicated to certificate randomization. Each generated certificate is unique, making traditional certificate-based detection useless — pivoting on a certificate hash yields no results. Havoc C2 reuses portions of the Sliver certificate generation code. The FIN7 group has enhanced its operations with custom encryption for Beacon payloads, using ChaCha20 encryption in the DUSTPAN loader to decrypt payloads in memory before execution. APT41's MoonWalk backdoor implements AES-CFB encryption for plugin decryption and uses public-key cryptography through its utility plugin for secure C2 communication via Google Drive.
How Encrypted C2 Channels Work
TLS-Based C2 — Hiding in Plain Sight
The simplest and most common approach is for malware to establish standard TLS connections to attacker-controlled infrastructure, making C2 traffic indistinguishable from legitimate HTTPS browsing. Cobalt Strike's malleable C2 profiles allow operators to customize every aspect of their Beacon's network communication — HTTP headers, URI patterns, POST/GET behavior, cookie formats, and TLS certificate parameters — to mimic the traffic patterns of legitimate services like Amazon, Microsoft 365, or Google Cloud. Since version 4.9, Cobalt Strike has introduced increasingly sophisticated evasion features including BeaconGate for intercepting API calls and the ability to use Cloudflare Workers as C2 infrastructure.
The rise of TLS 1.3 has made passive network inspection significantly harder. Critical metadata that defenders previously relied on — certificate details, cipher suites, and server names (SNI) — are now encrypted or removed from the handshake. Encrypted Client Hello (ECH) further eliminates the SNI field from plaintext observation. Research demonstrates that while payload content remains invisible, behavioral patterns like certificate size inference, application data record patterns, and connection timing still leave detectable traces, but these require specialized analysis techniques rather than simple signature matching.
Custom Protocol Encryption
The most sophisticated adversaries build entirely custom encrypted communication protocols. The FSB's Snake malware is the definitive example: it used custom encryption algorithms with traffic fragmentation layered on top of common network protocols, creating communications that were functionally impossible to decrypt without purpose-built software. Snake operated a global peer-to-peer network where infected computers served as relay nodes, routing disguised operational traffic between the FSB's operators and their ultimate targets. The custom protocol design meant that Snake traffic could not be distinguished from legitimate victim network traffic through standard network monitoring.
GhostSpider, a multi-modular backdoor attributed to Chinese APT operations against telecommunications providers, communicates over encrypted TLS channels using fake media file headers to disguise its traffic. The OrpaCrab backdoor targeting industrial control systems at gas stations uses the MQTT protocol for C2 communication with AES-256-CBC encryption and DNS-over-HTTPS (DoH) for domain resolution, effectively bypassing both traditional DNS monitoring and payload inspection.
Cloud Service Encryption — Legitimate Infrastructure
A growing trend involves adversaries using encryption provided by legitimate cloud services as their C2 channel. APT41 has repeatedly exploited this pattern: TOUGHPROGRESS embeds encrypted commands in Google Calendar events, VOLDEMORT used Google Sheets, DUSTTRAP leveraged public cloud hosting, and MoonWalk communicates through Google Drive. The encryption is provided by the cloud service's own TLS implementation, meaning the C2 traffic is identical to legitimate API calls to Google, Microsoft, or Amazon services. The attacker then adds an additional layer of custom encryption (XOR, AES) within the application data itself.
This creates a dual-encryption problem for defenders: the outer TLS layer protects the transport (which looks legitimate), and the inner custom encryption protects the malicious payload (which is only visible after TLS decryption). Even organizations that perform TLS inspection at the network perimeter would see what appears to be normal Google Calendar API traffic, with the actual C2 commands hidden in encrypted event descriptions.
Multi-Modal C2 Communication
Modern adversaries dynamically switch between communication profiles to balance operational needs. A multi-modal C2 channel might start with fast beaconing over TLS for initial reconnaissance (short intervals, small payloads), transition to a persistent WebSocket connection over a different port for tool upload and lateral movement preparation, and then shift to slow-beacon hibernation mode for long-term persistence. Each mode uses encrypted channels but with different timing, protocol, and behavioral characteristics, complicating detection by ensuring no single detection pattern catches all phases. Active Countermeasures has documented this "Numinon C2" pattern, noting that even when content is encrypted with TLS 1.3, the behavioral transitions between communication modes leave detectable traces.
Why Encrypted Channels Matter
The same encryption that protects legitimate communications also shields adversaries. Organizations cannot simply disable or bypass encryption without creating new vulnerabilities. The challenge is distinguishing malicious encrypted traffic from the 95%+ of internet traffic that is legitimately encrypted — and doing so at network speeds, at scale, without violating privacy requirements or breaking legitimate application functionality.
Deep packet inspection is defeated. Traditional network security tools that relied on reading packet payloads to identify malicious content are largely ineffective against encrypted C2. Signature-based detection that looks for known C2 command strings, encoded shellcode, or malware protocol headers cannot function when the payload is encrypted. This has forced a fundamental shift in network security architecture from content inspection to behavioral analysis, metadata examination, and endpoint-level detection.
TLS 1.3 and ECH eliminate metadata. Prior to TLS 1.3, defenders could extract useful metadata from the TLS handshake without decrypting traffic — including the server certificate (revealing the domain and certificate authority), the cipher suite selection, and the Server Name Indication (SNI) field. TLS 1.3 encrypts the certificate exchange and reduces handshake information. Encrypted Client Hello (ECH) further removes the SNI from plaintext observation, eliminating one of the last reliable indicators available to passive network monitoring.
Encryption is universal and expected. Unlike techniques that generate obviously suspicious traffic (non-standard ports, unusual protocols), encrypted C2 over TLS on port 443 is architecturally identical to every legitimate website visit, cloud API call, and SaaS application interaction. The Picus Red Report 2026 describes this as the "parasitic" model: adversaries burrow into legitimate communication patterns rather than creating their own, making detection a statistical and behavioral problem rather than a signature-matching exercise.
Data exfiltration prevention is failing. The Picus Blue Report 2025, based on over 160 million attack simulations, found that data exfiltration prevention effectiveness dropped from 9% to just 3% — marking it the weakest detection vector for the third consecutive year. When C2 and exfiltration channels are encrypted and blended with legitimate traffic, perimeter controls consistently fail to identify data theft in progress.
Custom encryption makes reverse engineering the only option. For malware using non-standard encryption (Snake's custom protocols, TOUGHPROGRESS's dual XOR scheme, OrpaCrab's AES-256-CBC over MQTT), defenders cannot develop detection signatures without first obtaining and reverse-engineering the malware binary. This creates a "detect the first victim, protect the second" dynamic where the initial compromise may go undetected indefinitely until the malware sample is captured and analyzed by researchers.
Real-World Case Studies
Case 1: FSB Snake Malware — Operation MEDUSA (2003–2023)
The Snake implant, developed by Center 16 of Russia's Federal Security Service (FSB), operated for nearly 20 years as the FSB's flagship cyber espionage tool before the FBI disrupted it in May 2023. Five Eyes agencies described Snake as the most sophisticated cyber espionage tool in the FSB's arsenal, identifying it in over 50 countries across government networks, research facilities, journalists, and critical infrastructure sectors including financial services, manufacturing, and communications.
Snake's encrypted channel implementation was extraordinary in its sophistication. The malware used custom communications protocols that combined encryption with traffic fragmentation, layered on top of common network protocols to hamper detection and collection efforts. Infected computers formed a covert peer-to-peer network where systems served as relay nodes, routing disguised operational traffic to and from the FSB's ultimate targets. Communications between Snake implants were encrypted, fragmented, and sent using customized methodologies, making them nearly impossible to distinguish from legitimate network traffic. The FBI studied Snake for eight years before developing the PERSEUS tool, which mimicked Snake's session authentication protocol to issue self-destruct commands to infected systems. The operation required decrypting and decoding Snake's custom communication protocols — a testament to the encryption's effectiveness and the immense effort required to defeat it.
Case 2: APT41/TOUGHPROGRESS — Google Calendar C2 (2024–2025)
In late October 2024, Google's Threat Intelligence Group discovered that APT41 was using a malware payload called TOUGHPROGRESS that used Google Calendar as its C2 channel. The malware was hosted on a compromised government website and used to target multiple other government entities. TOUGHPROGRESS read and wrote events to an attacker-controlled Google Calendar, creating zero-minute events with encrypted content in the event descriptions. Operators placed encrypted commands in Calendar events, which were polled by the malware, decrypted using a hardcoded 10-byte XOR key plus per-message 4-byte XOR keys, executed on the compromised host, and the results written back to another Calendar event.
This represents a layered encryption approach: Google Calendar's own TLS encryption protects the transport layer (making traffic indistinguishable from legitimate Calendar API usage), while TOUGHPROGRESS's custom XOR encryption protects the C2 payload within event descriptions. APT41 has a history of abusing Google services for C2 — prior campaigns used Google Sheets, Google Drive (MoonWalk backdoor), and Cloudflare Workers. Google disrupted the campaign by taking down malicious Calendars and terminating attacker-controlled Workspace projects.
Case 3: Cobalt Strike Malleable C2 — Universal Encrypted Framework
Cobalt Strike remains the most widely used C2 framework by both red teams and criminal threat actors, and its encrypted channel capabilities set the standard for the industry. Beacon communicates over HTTPS using malleable C2 profiles that allow operators to customize the TLS certificate, HTTP headers, URI paths, data encoding, and traffic timing to impersonate legitimate services. The encryption layer uses AES-256-CBC for session traffic, with keys derived through an RSA key exchange during the initial handshake.
Since version 4.9, Cobalt Strike has introduced significant enhancements including BeaconGate for intercepting supported API calls through a custom Sleep Mask, post-exploitation reflective loader memory cleanup, and the ability to use indirect syscalls. Unit 42 (Palo Alto Networks) published extensive research in 2024 and 2025 on detecting Cobalt Strike malleable C2 profiles, noting that the framework's customization makes it extremely difficult to create static detection signatures. The framework supports C2 over HTTP, HTTPS, DNS, SMB named pipes, and forward/reverse TCP connections, with beacons chainable across protocols for defense evasion.
Case 4: Sliver/Havoc C2 — Next-Generation Open-Source Frameworks
As defensive capabilities against Cobalt Strike have improved, threat actors have increasingly migrated to open-source alternatives. Sliver, developed by BishopFox, uses mutual TLS (mTLS) for its encrypted C2 channel with over 400 lines of code dedicated to randomly generating unique TLS certificates for each deployment. This makes certificate-based detection (JA3/JA4 matching, certificate hash pivoting) exceptionally difficult. Cybereason's Global SOC has documented Sliver being leveraged by numerous threat actors as a Cobalt Strike replacement.
JA4X fingerprinting — which analyzes how certificates are generated rather than the values within them — represents a breakthrough for detecting Sliver's encrypted C2. Because Sliver's certificates are all generated by the same application code, they share the same JA4X fingerprint despite having unique values. Havoc C2 reuses portions of Sliver's certificate generation code, meaning it shares the same JA4X fingerprint but can be differentiated by examining Org Name and Postal Code length fields. This illustrates the arms race between encrypted C2 implementation and detection methodology.
Case 5: Multi-Modal Encrypted C2 — The Numinon Pattern (2025)
Active Countermeasures documented a multi-modal C2 framework that demonstrates the increasing sophistication of encrypted channel usage. The pattern operates in three distinct phases: an initial intelligence-gathering beacon communicating over TLS with regular intervals for approximately four hours, followed by a transition to a persistent WebSocket connection over a different port (also TLS-encrypted) for high-speed tool upload, and finally a shift to long-term slow-beacon hibernation mode to maintain persistence while minimizing detection risk.
Each phase serves a specific operational purpose — enumeration, staging, and persistence — and uses encrypted channels with different behavioral characteristics. The key defensive insight is that while TLS 1.3 prevents payload inspection, the transitions between communication modes and the distinct behavioral fingerprints of each phase remain detectable through traffic analysis. The analysis reinforces that behavioral detection, not content inspection, is the path forward against encrypted C2.
Detection Strategies
Traditional signature-based detection cannot read encrypted C2 traffic. Detection strategies must focus on TLS handshake metadata (JA4+ fingerprinting), behavioral patterns (beaconing analysis, connection timing), certificate anomalies (self-signed certificates, certificate age, generation patterns), and endpoint indicators (malware processes establishing outbound encrypted connections). The shift from content-based to behavior-based detection is the fundamental requirement for detecting T1573.
| Data Source | Component | Detection Focus |
|---|---|---|
| Network Traffic | Network Traffic Content | TLS handshake metadata, JA4+ fingerprints, certificate analysis, unusual cipher suites |
| Network Traffic | Network Connection Creation | Processes establishing outbound TLS connections to unusual destinations or on non-standard ports |
| Network Traffic | Network Traffic Flow | Beaconing patterns, session duration, data volume asymmetry, connection frequency |
| Process | Process Creation | Suspicious processes initiating encrypted outbound connections (rundll32, mshta, PowerShell) |
| Network Traffic | TLS Certificate | Self-signed certificates, short-lived certificates, JA4X generation patterns, unusual certificate authorities |
| Network Traffic | DNS Resolution | DNS-over-HTTPS (DoH) bypassing traditional DNS monitoring, unusual domain resolution patterns |
| Network Traffic | Protocol Metadata | Encrypted traffic on non-standard ports, protocol mismatches, unexpected ALPN values |
Splunk / SIEM Detection Queries
Self-Signed Certificate Detection — Identify outbound TLS connections using self-signed or untrusted certificates, a common indicator of C2 infrastructure:
index=zeek sourcetype="bro:ssl:json" validation_status!="ok"
| where NOT cidrmatch("10.0.0.0/8", id_resp_h) AND NOT cidrmatch("172.16.0.0/12", id_resp_h)
| stats count dc(id_orig_h) as unique_sources values(id_orig_h) as source_ips
by server_name subject issuer ja4
| where count > 5 OR unique_sources > 2
| sort - countBeaconing Interval Analysis — Detect regular callback patterns characteristic of encrypted C2 beacons by analyzing connection timing variance:
index=network sourcetype=firewall action=allowed dest_port=443 bytes_out>0
| bin _time span=1m
| stats count as connections_per_min by src_ip dest_ip
| eventstats stdev(connections_per_min) as timing_stdev
avg(connections_per_min) as timing_avg by src_ip dest_ip
| eval coefficient_of_variation = timing_stdev / timing_avg
| where coefficient_of_variation < 0.3 AND timing_avg > 0.5
| table src_ip dest_ip timing_avg timing_stdev coefficient_of_variationJA4+ Fingerprint Anomaly Detection — Alert on TLS client fingerprints matching known C2 frameworks (Cobalt Strike, Sliver, Havoc) or previously unseen fingerprints from internal hosts:
index=zeek sourcetype="bro:ssl:json" ja4=*
| lookup ja4_threat_intel.csv ja4 OUTPUT threat_name confidence
| where isnotnull(threat_name) OR ja4 NOT IN
[| inputlookup ja4_baseline.csv | fields ja4]
| stats count values(id_orig_h) as source_ips values(server_name) as destinations
first(threat_name) as matched_threat by ja4
| sort - countSuspicious Process Encrypted Outbound Connections — Identify processes that should not be making outbound encrypted connections, particularly common LOLBins used for C2:
index=sysmon EventCode=3 Initiated=true DestinationPort=443
| where match(Image, "(?i)(rundll32|regsvr32|mshta|certutil|msiexec|wscript|cscript|
powershell|cmd)\.exe$")
| stats count dc(DestinationIp) as unique_destinations values(DestinationIp) as dest_ips
by Image SourceHostname User
| where unique_destinations > 3
| sort - unique_destinationsKnown Threat Actors
Nation-State Espionage Groups
| Threat Actor | Encryption Method | Notable Detail |
|---|---|---|
| Turla / FSB Center 16 | CAST-128 custom protocol + P2P relay | Snake malware operated 20 years across 50+ countries; FBI's Operation MEDUSA |
| APT29 / Cozy Bear | TLS with HTTPS malleable profiles | SUNBURST C2 mimicked SolarWinds Orion telemetry over encrypted channels |
| APT41 / Brass Typhoon | XOR + AES-CFB over cloud services | TOUGHPROGRESS (Google Calendar), MoonWalk (Google Drive), DUSTTRAP (cloud hosting) |
| Lazarus Group | Custom AES + TLS | Cross-platform encrypted C2 in Contagious Interview and cryptocurrency theft campaigns |
| Earth Lusca / FishMonger | Encrypted TLS + SOCKS proxy | China-linked espionage targeting governments, telecoms, and NGOs across 5 regions |
| Velvet Ant | Encrypted C2 over F5 load balancers | Abused network appliances for encrypted C2 persistence (Sygnia, 2024) |
| Tropic Trooper | TLS with USBferry | Targeted air-gapped environments via USB with encrypted C2 for connected segments |
| OilRig / APT34 | Custom encrypted channels | Outer Space and Juicy Mix campaigns used encrypted backdoor communications |
| FIN7 | ChaCha20 + AES via DUSTPAN loader | Enhanced operations with EDR bypasses and encrypted payload delivery (2024) |
Ransomware and Cybercrime
| Threat Actor | Encryption Method | Notable Detail |
|---|---|---|
| Medusa Ransomware | Encrypted C2 + asymmetric crypto | 300+ victims; CISA AA25-071A advisory (March 2025) |
| IcedID / BokBot | TLS over HTTPS | Banking trojan turned initial access broker with encrypted C2 callbacks |
| Lumma Stealer | TLS with deceptive domains | Distributed via cracked software, encrypted C2 for credential exfiltration |
| PureRAT | TLS + .NET Reactor obfuscation | MaaS RAT with encrypted comms and fileless execution via AddInProcess32.exe |
| GhostWeaver RAT | TLS-encrypted C2 | Multi-stage infection chain via MintsLoader with encrypted persistence |
| Raccoon / Redline | HTTPS-based C2 | Credential theft pipeline with 3x increase in infostealer activity (2024) |
| Netwire RAT | AES-encrypted custom protocol | Cross-platform RAT with encrypted keystroke logging and file transfer |
C2 Frameworks and Tools
| Framework | Encryption Method | Notable Detail |
|---|---|---|
| Cobalt Strike | AES-256-CBC + RSA key exchange | Malleable C2 profiles; HTTPS, DNS, SMB, TCP protocols; v4.11 with BeaconGate |
| Sliver | mTLS with 400+ lines of random cert generation | Open-source Cobalt Strike alternative; unique JA4X fingerprint despite random certs |
| Havoc | Shared Sliver cert generation code | Same JA4X as Sliver; differentiable by Org Name/Postal Code length |
| Metasploit / Meterpreter | TLS + AES | Reverse HTTPS staged payloads with certificate pinning options |
| Brute Ratel C4 | Custom encrypted channels | Marketed as EDR-evasive; encrypted DNS-over-HTTPS C2 capability |
| Mythic | Various per-agent encryption | Modular framework supporting multiple encrypted C2 agents |
Defensive Recommendations
1. Deploy JA4+ TLS Fingerprinting
Implement JA4+ fingerprinting at the network perimeter to identify encrypted C2 traffic without decryption. JA4 fingerprints are human-readable, resistant to TLS extension randomization, and support QUIC/DTLS protocols that JA3 cannot handle. Build a baseline of legitimate JA4 fingerprints for your environment and alert on new or known-malicious fingerprints. JA4X (certificate generation fingerprinting) is particularly valuable for detecting Sliver, Havoc, and SoftEther VPN abuse, as these tools generate random certificates using the same code patterns. Cloudflare, VirusTotal, AWS, and NetWitness have all adopted JA4+ support.
2. Implement TLS Inspection at Critical Points
Deploy TLS inspection (also called SSL/TLS interception or break-and-inspect) at the network perimeter for traffic categories where inspection is legally and operationally appropriate. This is the only way to detect custom encryption layered within TLS sessions. Deploy carefully — TLS inspection introduces certificate trust chain complexity, potential performance impacts, and privacy considerations. Prioritize inspection of traffic from high-risk processes and to uncategorized or newly registered domains rather than attempting to inspect all traffic.
3. Behavioral Beaconing Detection
Deploy network detection and response (NDR) solutions capable of identifying beaconing patterns in encrypted traffic. Analyze connection timing regularity (low coefficient of variation), consistent payload sizes, and periodic callback intervals. Modern C2 frameworks add jitter to evade simple interval analysis, but statistical methods can still detect the underlying regularity. Monitor for transitions between communication modes (the multi-modal pattern) as these behavioral shifts generate detectable anomalies even in fully encrypted traffic.
4. Certificate Anomaly Monitoring
Monitor for TLS connections using self-signed certificates, certificates with very short validity periods, certificates from unusual or free certificate authorities (Let's Encrypt abuse), and certificates with suspicious attributes (short key lengths, unusual OID values, recently generated certificates for domains accessed from your environment). Build certificate intelligence into your SIEM workflow to correlate certificate anomalies with other indicators.
5. Restrict Outbound Encryption to Authorized Applications
Implement application-aware firewalls that can distinguish between authorized applications making encrypted connections (web browsers, sanctioned SaaS applications) and unauthorized processes establishing TLS sessions. Alert when LOLBins (rundll32, mshta, regsvr32, certutil) or unusual processes initiate outbound encrypted connections. Consider blocking direct HTTPS access for non-browser processes and requiring them to use an authenticated proxy.
6. DNS-over-HTTPS (DoH) Controls
Adversaries increasingly use DNS-over-HTTPS to encrypt DNS resolution and bypass traditional DNS monitoring. Block known DoH provider endpoints at the network perimeter for non-browser applications, enforce organizational DNS resolvers through DHCP and Group Policy, and monitor for DoH traffic from unexpected sources. The OrpaCrab malware targeting industrial systems specifically used DoH to evade DNS-based detection.
7. Cloud Service C2 Detection
Monitor for unusual patterns of access to legitimate cloud services that may indicate C2 abuse. APT41's pattern of using Google Calendar, Google Drive, and Google Sheets for C2 creates traffic that is encrypted and appears legitimate at the network level but may exhibit unusual timing, volume, or API call patterns. Implement CASB solutions or cloud service logs to identify anomalous usage patterns that could indicate encrypted C2 hiding within legitimate service traffic.
8. Endpoint-Level C2 Detection
Because network-level detection of encrypted C2 is inherently limited, complement network monitoring with endpoint detection and response (EDR) capabilities that can observe the malware's behavior before and after encryption. Monitor for processes that establish persistent outbound connections, load cryptographic libraries unexpectedly, or exhibit C2 behavioral patterns (periodic network activity, sleep-then-callback cycles, response to received commands). Sysmon Event ID 3 (network connections) and Event ID 22 (DNS queries) provide critical endpoint visibility into C2 communication patterns.
MITRE ATT&CK Mapping
| Field | Value |
|---|---|
| Technique ID | T1573 |
| Name | Encrypted Channel |
| Tactic | Command and Control (TA0011) |
| Sub-Techniques | T1573.001 Symmetric Cryptography, T1573.002 Asymmetric Cryptography |
| Platforms | ESXi, Linux, Network Devices, Windows, macOS |
| Version | 1.2 (Last Modified October 2025) |
| Data Sources | Network Traffic (Content, Connection Creation, Flow), Process Creation, TLS Certificates, DNS Resolution |
| Related Techniques | T1071 Application Layer Protocol, T1090 Proxy, T1132 Data Encoding, T1001 Data Obfuscation, T1041 Exfiltration Over C2 Channel |
Sources and References
This article draws on government advisories, vendor research, and academic publications. All referenced sources are publicly available.
- CISA/FBI/NSA/Five Eyes — Hunting Russian Intelligence "Snake" Malware (May 2023): cisa.gov
- Google Threat Intelligence Group — Mark Your Calendar: APT41 Innovative Tactics (May 2025): cloud.google.com
- Google Threat Intelligence Group — APT41 Has Arisen From the DUST (July 2024): cloud.google.com
- Zscaler ThreatLabz — MoonWalk: Updated Arsenal of APT41 (April 2025): zscaler.com
- Picus Security — Red Report 2026: Top 10 MITRE ATT&CK Techniques: picussecurity.com
- Unit 42 (Palo Alto Networks) — How the Malleable C2 Profile Makes Cobalt Strike Difficult to Detect (August 2025): unit42.paloaltonetworks.com
- FoxIO — JA4+ Network Fingerprinting (September 2023): blog.foxio.io
- Cloudflare — Advancing Threat Intelligence: JA4 Fingerprints and Inter-Request Signals (October 2025): blog.cloudflare.com
- Active Countermeasures — Malware of the Day: Multi-Modal C2 Communication / Numinon C2 (July 2025): activecountermeasures.com
- Fidelis Security — C2 Detection: Every SOC Must Know (February 2025): fidelissecurity.com
- Novo et al. — Extending C2 Traffic Detection Methodologies: From TLS 1.2 to TLS 1.3-enabled Malware (RAID 2024): dl.acm.org
- MITRE ATT&CK — T1573 Encrypted Channel (v18, October 2025): attack.mitre.org