T1048.002: Exfiltration Over Asymmetric Encrypted Non-C2 Protocol
Adversaries may steal data by exfiltrating it over an asymmetrically encrypted network protocol other than that of the existing command and control channel. The data may also be sent to an alternate network location from the main command and control server.
Asymmetric encryption algorithms are those that use different keys on each end of the channel. Also known as public-key cryptography, this requires pairs of cryptographic keys that can encrypt/decrypt data from the corresponding key. Each end of the communication channels requires a private key (only in the procession of that entity) and the public key of the other entity. The public keys of each entity are exchanged before encrypted communications begin.
Network protocols that use asymmetric encryption (such as HTTPS/TLS/SSL) often utilize symmetric encryption once keys are exchanged. Adversaries may opt to use these encrypted mechanisms that are baked into a protocol.
Analyst context for executives and security teams
This technique matters because stolen data can leave the environment inside encrypted traffic that looks like normal business use of protocols such as HTTPS/TLS/SSL, but separate from the adversary’s command-and-control channel. For leaders, the issue is not just encryption; it is whether the organization can prove which systems are allowed to send sensitive data externally, detect unusual encrypted egress, and respond quickly when content inspection is limited.
Executive priority
Prioritize this as an exfiltration resilience question: do critical Windows, Linux, macOS, and ESXi assets have controlled outbound paths, monitored encrypted traffic patterns, and DLP or egress filtering where sensitive data is handled? This technique is associated in ATT&CK with multiple groups, software, and the SolarWinds Compromise campaign, so executives should ask for evidence that exfiltration controls are not dependent on seeing plaintext payloads.
Technical view
SOC and IR teams should validate coverage for outbound encrypted non-C2 channels from ESXi, Linux, macOS, and Windows systems. Because ATT&CK provides no official detection text for this object, detection should be built around the related DET0512 strategy where available, plus local baselining of encrypted egress volume, destination novelty, process-to-network behavior, and deviations from approved data movement paths. Relationship context also points to Rclone and IcedID as software examples, which makes command-line file sync tools, unauthorized cloud storage traffic, and unexpected HTTPS/TLS sessions useful validation areas without assuming any one tool is present.
Likely telemetry
- Network flow records for outbound encrypted sessions, including source, destination, port, volume, timing, and duration
- TLS/SSL metadata where legally and operationally appropriate, such as SNI, certificate details, and JA3/JA4-style fingerprints if collected
- Proxy, firewall, secure web gateway, and egress filtering logs
- Endpoint process execution and process-to-network connection telemetry on Windows, Linux, macOS, and ESXi where available
- DLP alerts and sensitive data movement logs across endpoint, network, and cloud-integrated channels
Detection direction
- Validate whether DET0512 or equivalent analytics are implemented and mapped to this sub-technique, since the ATT&CK object itself does not include official detection guidance.
- Tune for unusual encrypted outbound transfer volume, rare destinations, new certificates or domains, and long-running sessions from systems that do not normally move data externally.
- Correlate network events with endpoint process context to separate approved business applications from unexpected command-line tools or processes initiating encrypted transfers.
- Expect false positives from legitimate backups, software updates, cloud sync, managed file transfer, and administrative activity; require baselines and allowlists tied to asset role.
- Identify blind spots where encryption prevents content inspection, especially unmanaged endpoints, ESXi hosts, direct-to-internet paths, and traffic bypassing proxies or gateways.
Mitigation priorities
- Start with network segmentation so critical assets and sensitive data stores have restricted outbound paths rather than broad internet access.
- Apply network intrusion prevention and filtering at egress points to block or restrict unauthorized encrypted protocols, destinations, and traffic patterns.
- Use DLP to identify, categorize, monitor, and control sensitive data movement across endpoint, network, and cloud-connected channels.
- Maintain approved destination and service inventories for legitimate encrypted data transfer, then alert on exceptions rather than trying to inspect all encrypted content.
- Ensure incident response playbooks include rapid containment of hosts producing suspicious encrypted egress and preservation of network and endpoint evidence.
Analyst notes and limits
This is a sub-technique of Exfiltration Over Alternative Protocol and focuses specifically on asymmetric encrypted non-C2 protocols. The relationship set includes mitigations for Network Segmentation, Network Intrusion Prevention, Filter Network Traffic, and Data Loss Prevention, plus several groups, software, and one campaign that use the technique. Those relationships support prioritizing defensive validation but do not prove current activity in any specific environment.
ATT&CK provides no official detection text for this object, and the supplied DET0512 relationship does not include detailed analytic logic here. Local architecture, data classification, proxy coverage, TLS visibility, endpoint telemetry, and approved business transfer patterns are required to determine practical detection quality and risk.
Exfiltration Over Asymmetric Encrypted Non-C2 Protocol
Adversaries may steal data by exfiltrating it over an asymmetrically encrypted network protocol other than that of the existing command and control channel. The data may also be sent to an alternate network location from the main command and control server.
Asymmetric encryption algorithms are those that use different keys on each end of the channel. Also known as public-key cryptography, this requires pairs of cryptographic keys that can encrypt/decrypt data from the corresponding key. Each end of the communication channels requires a private key (only in the procession of that entity) and the public key of the other entity. The public keys of each entity are exchanged before encrypted communications begin.
Network protocols that use asymmetric encryption (such as HTTPS/TLS/SSL) often utilize symmetric encryption once keys are exchanged. Adversaries may opt to use these encrypted mechanisms that are baked into a protocol.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1048 | Exfiltration Over Alternative Protocol | This object subtechnique of Exfiltration Over Alternative Protocol. |
Groups, software, and campaigns
G0007: APT28
APT28 is a threat group that has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) 85th Main Special Service Center (GTsSS) military unit 26165.[1][2] This group has been active since at least 2004.[3][4][5][6][7][8][9][10][11][12][13]
APT28 reportedly compromised the Hillary Clinton campaign, the Democratic National Committee, and the Democratic Congressional Campaign Committee in 2016 in an attempt to interfere with the U.S. presidential election.[5] In 2018, the US indicted five GRU Unit 26165 officers associated with APT28 for cyber operations (including close-access operations) conducted between 2014 and 2018 against the World Anti-Doping Agency (WADA), the US Anti-Doping Agency, a US nuclear facility, the Organization for the Prohibition of Chemical Weapons (OPCW), the Spiez Swiss Chemicals Laboratory, and other organizations.[14] Some of these were conducted with the assistance of GRU Unit 74455, which is also referred to as Sandworm Team.
G1012: CURIUM
CURIUM is an Iranian threat group, first reported in September 2019 and active since at least July 2018, targeting IT service providers in the Middle East.[1] CURIUM has since invested in building relationships with potential targets via social media over a period of months to establish trust and confidence before sending malware. Security researchers note CURIUM has demonstrated great patience and persistence by chatting with potential targets daily and sending benign files to help lower their security consciousness.[2]
G1054: MirrorFace
MirrorFace is a People's Republic of China (PRC)-aligned cyberespionage actor believed to be a subgroup under the menuPass umbrella based on targeting, tools, and infrastructure overlaps. MirrorFace has been active since at least 2019, at first exclusively targeting Japanese organizations across the media, defense, diplomatic, financial, manufacturing, and academic sectors. Subsequent MirrorFace operations included targets in Central Europe and featured use of LODEINFO, HiddenFace, and UPPERCUT malware.[1][2][3][4][5][6]
G1046: Storm-1811
Storm-1811 is a financially-motivated entity linked to Black Basta ransomware deployment. Storm-1811 is notable for unique phishing and social engineering mechanisms for initial access, such as overloading victim email inboxes with non-malicious spam to prompt a fake "help desk" interaction leading to the deployment of adversary tools and capabilities.[1][2][3][4]
S0483: IcedID
S9011: BRUSHFIRE
S1040: Rclone
C0024: SolarWinds Compromise
The SolarWinds Compromise was a sophisticated supply chain cyber operation conducted by APT29 that was discovered in mid-December 2020. APT29 used customized malware to inject malicious code into the SolarWinds Orion software build process that was later distributed through a normal software update; they also used password spraying, token theft, API abuse, spear phishing, and other supply chain attacks to compromise user accounts and leverage their associated access. Victims of this campaign included government, consulting, technology, telecom, and other organizations in North America, Europe, Asia, and the Middle East. This activity has been labled the StellarParticle campaign in industry reporting.[1] Industry reporting also initially referred to the actors involved in this campaign as UNC2452, NOBELIUM, Dark Halo, and SolarStorm.[2][3][4][5][1][6][7][8]
In April 2021, the US and UK governments attributed the SolarWinds Compromise to Russia's Foreign Intelligence Service (SVR); public statements included citations to APT29, Cozy Bear, and The Dukes.[9][10][11] The US government assessed that of the approximately 18,000 affected public and private sector customers of Solar Winds’ Orion product, a much smaller number were compromised by follow-on APT29 activity on their systems.[12]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.2 | Current bundle | f20649954b02… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
University of Birmingham C2
Gardiner, J., Cova, M., Nagaraja, S. (2014, February). Command & Control Understanding, Denying and Detecting. Retrieved April 20, 2016.
Open source URL -
[2]
mitre-attack T1048.002Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.