T1048.001: Exfiltration Over Symmetric Encrypted Non-C2 Protocol
Adversaries may steal data by exfiltrating it over a symmetrically 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.
Symmetric encryption algorithms are those that use shared or the same keys/secrets on each end of the channel. This requires an exchange or pre-arranged agreement/possession of the value used to encrypt and decrypt data.
Network protocols that use asymmetric encryption often utilize symmetric encryption once keys are exchanged, but adversaries may opt to manually share keys and implement symmetric cryptographic algorithms (ex: RC4, AES) vice using mechanisms that are baked into a protocol. This may result in multiple layers of encryption (in protocols that are natively encrypted such as HTTPS) or encryption in protocols that not typically encrypted (such as HTTP or FTP).
Analyst context for executives and security teams
This technique matters because data theft may be hidden inside an alternate outbound protocol and additionally protected with attacker-controlled symmetric encryption. For leaders, the issue is not just “encrypted traffic exists”; it is whether the organization can prove that sensitive systems on Linux, macOS, Windows, and ESXi have controlled egress paths and that the SOC can recognize unusual data movement even when payload inspection is limited or impossible.
Executive priority
Prioritize this as an exfiltration-readiness control question: which assets are allowed to send data externally, through which protocols, and with what monitoring evidence? It is especially relevant to incident decision-making and audit evidence because encrypted non-C2 exfiltration can reduce the value of content inspection and shift the burden to network segmentation, egress filtering, intrusion prevention, and behavioral detection. Executives should ask whether critical asset segments and virtualization platforms have explicit outbound allow rules rather than broad internet access.
Technical view
ATT&CK lists this as an exfiltration sub-technique of Exfiltration Over Alternative Protocol affecting Linux, macOS, Windows, and ESXi. The official detection field is not provided, so SOC validation should focus on behavior and control evidence: outbound data movement over protocols separate from any known command-and-control channel, use of natively encrypted protocols such as HTTPS with additional encrypted content, or encrypted payloads over protocols that are not typically encrypted such as HTTP or FTP. Use the related DET0503 detection strategy as a pointer for behavioral coverage, and test whether monitoring can correlate endpoint/process context, network destinations, protocol use, volume, timing, and asset sensitivity.
Likely telemetry
- Firewall, proxy, secure web gateway, and egress filtering logs showing outbound protocol, destination, bytes transferred, and allow/block decisions
- Network flow metadata for high-volume or unusual outbound transfers from Linux, macOS, Windows, and ESXi systems
- Network intrusion detection or prevention alerts and signature hits at network boundaries
- Endpoint telemetry linking processes, users, and hosts to outbound network connections
- Asset and segmentation context identifying whether the source system is a critical server, workstation, or ESXi host
Detection direction
- Validate behavioral detections for unusual outbound volume, uncommon destinations, unexpected protocols, or transfers from assets that should not directly communicate externally.
- Tune detections against business-approved bulk transfer paths to reduce false positives while preserving scrutiny for sensitive segments and ESXi environments.
- Correlate network metadata with endpoint process and user context; payload inspection alone may fail when symmetric encryption is layered inside another protocol.
- Check for blind spots in non-web egress, direct-to-internet server traffic, unmanaged hosts, and segments where only perimeter logs are collected.
- Use relationship context from the parent technique T1048 to ensure coverage is not limited to one protocol family and accounts for alternate network locations.
Mitigation priorities
- Start with network segmentation for critical assets so only required systems and protocols can reach external destinations.
- Enforce network traffic filtering with explicit egress rules, protocol restrictions, and allow-listed paths for approved data movement.
- Use network intrusion prevention at network boundaries where signatures or policy controls can block known or unauthorized traffic patterns.
- Review outbound access from Linux, macOS, Windows, and ESXi systems, especially servers and virtualization infrastructure that may have broader network reach than workstations.
- Maintain evidence of segmentation, filtering, and block/alert decisions for compliance readiness and incident response reconstruction.
Analyst notes and limits
The practical defensive question is whether the organization can detect and contain data movement when the content is encrypted and the channel is separate from the main command-and-control path. Strong coverage usually depends on combining egress governance, segmentation, network metadata, endpoint context, and asset criticality rather than relying on decryption or content inspection alone.
MITRE provides no official detection text for this object in the supplied fields. The related detection strategy is named but not detailed here, so detection logic should be validated locally. No active exploitation, actor attribution, specific tools, or guaranteed detection coverage is stated by the supplied ATT&CK fields.
Exfiltration Over Symmetric Encrypted Non-C2 Protocol
Adversaries may steal data by exfiltrating it over a symmetrically 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.
Symmetric encryption algorithms are those that use shared or the same keys/secrets on each end of the channel. This requires an exchange or pre-arranged agreement/possession of the value used to encrypt and decrypt data.
Network protocols that use asymmetric encryption often utilize symmetric encryption once keys are exchanged, but adversaries may opt to manually share keys and implement symmetric cryptographic algorithms (ex: RC4, AES) vice using mechanisms that are baked into a protocol. This may result in multiple layers of encryption (in protocols that are natively encrypted such as HTTPS) or encryption in protocols that not typically encrypted (such as HTTP or FTP).
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. |
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.1 | Current bundle | 65685af5f068… |
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.001Open 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.