DET0273: Detection Strategy for Encrypted Channel across OS Platforms
This detection strategy is meant to help identify encrypted command-and-control behavior associated with ATT&CK technique T1573, Encrypted Channel. The bus...
Analyst context for executives and security teams
This detection strategy is meant to help identify encrypted command-and-control behavior associated with ATT&CK technique T1573, Encrypted Channel. The business issue is not that encryption is suspicious by itself, but that adversaries can use custom or malware-embedded encryption to hide C2 traffic from routine inspection. For leaders, this makes network visibility, malware analysis capability, and C2 investigation workflows important to resilience because encrypted traffic can reduce the usefulness of content-based monitoring.
Executive priority
Treat this as a coverage-validation item for command-and-control detection rather than a standalone control. Security leaders should ask whether SOC and IR teams can investigate suspicious encrypted traffic across the environments named for the related technique: ESXi, Linux, macOS, and network devices. Priority should go to confirming telemetry availability, incident response playbooks for opaque outbound traffic, and evidence that monitoring does not rely only on decrypting payload content.
Technical view
The supplied detection strategy has no official description or detection logic, but it is explicitly related to T1573 Encrypted Channel under command-and-control. Detection engineering should therefore validate behavioral and metadata-based analytics around encrypted C2 indicators rather than assume payload inspection will work. Useful validation areas include unusual encrypted outbound sessions, non-standard encryption implementations, anomalous destinations, recurring beacon-like timing, unexpected encrypted traffic from infrastructure systems, and malware/configuration analysis where keys may be embedded or generated in samples. Because the related technique includes ESXi, Linux, macOS, and network devices, teams should verify whether those asset classes are represented in network, endpoint, and infrastructure telemetry.
Likely telemetry
- Network flow metadata for encrypted sessions, including source, destination, ports, timing, volume, and duration
- DNS and destination reputation/context associated with encrypted outbound connections
- Proxy, firewall, IDS/IPS, VPN, and egress-control logs where available
- Endpoint or server process-to-network connection telemetry for Linux and macOS where available
- Infrastructure and network-device logs that can show unexpected outbound encrypted communications
Detection direction
- Validate that detections do not depend solely on decrypting traffic contents; encrypted C2 may require metadata, behavior, and host-context correlation.
- Tune for command-and-control patterns such as unusual periodicity, rare destinations, unexpected encrypted protocols or ports, and encrypted traffic from assets that normally should not initiate external sessions.
- Review blind spots for ESXi, Linux, macOS, and network devices, since these platforms are listed on the related ATT&CK technique and may have weaker endpoint telemetry than standard workstations.
- Expect false positives from legitimate encrypted administration, backup, monitoring, VPN, and cloud-service traffic; baselining by asset role is important.
- Use relationship context to map this strategy to T1573 coverage and to identify where local logging, asset inventory, and egress visibility are insufficient.
Mitigation priorities
- Establish asset-role baselines and egress expectations for systems that should have limited outbound encrypted communication.
- Improve collection of network flow, DNS, proxy, firewall, and endpoint network telemetry before building high-confidence detections.
- Apply least-privilege egress controls and segmentation where business processes allow, especially for infrastructure and network-management assets.
- Ensure incident response can preserve and analyze malware samples or configurations when encrypted C2 is suspected, since the related technique notes that keys may be encoded or generated in malware/configuration files.
- Document coverage and gaps as compliance and audit evidence, especially where encrypted traffic inspection is limited by privacy, architecture, or operational constraints.
Analyst notes and limits
MITRE provides the detection strategy name and relationship to T1573, but no official description or detection text for DET0273. The practical value is therefore in using the relationship to Encrypted Channel to drive coverage questions: what encrypted C2 behaviors can be observed, which platforms are visible, and whether defenders can investigate without payload visibility.
This take is constrained by sparse official fields. The detection strategy itself has no specified platforms, tactics, description, or detection logic. Platform and tactic context comes only from the related T1573 technique. Local environment data is required to determine actual exposure, telemetry coverage, detection quality, and control priorities.
Detection Strategy for Encrypted Channel across OS Platforms
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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 | T1573 | Encrypted Channel | This object detects Encrypted Channel. |
All related ATT&CK context
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.0 | Current bundle | 3f5015de0521… |
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]
mitre-attack DET0273Open 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.