T1521: Encrypted Channel
Adversaries may explicitly employ a known encryption algorithm to conceal command and control traffic rather than relying on any inherent protections provided by a communication protocol. Despite the use of a secure algorithm, these implementations may be vulnerable to reverse engineering if necessary secret keys are encoded and/or generated within malware samples/configuration files.
Analyst context for executives and security teams
Encrypted Channel is a mobile ATT&CK technique describing malware that deliberately encrypts command-and-control traffic on Android or iOS instead of relying only on normal protocol protections. For leaders, the practical issue is visibility: even when network traffic is collected, the content may be unreadable, and defenders may need mobile endpoint, application, configuration, certificate, and behavioral evidence to understand whether a device is communicating with attacker-controlled infrastructure.
Executive priority
Prioritize this as a mobile security and incident response visibility problem. Encrypted C2 can reduce the value of network inspection alone, so executives should ask whether mobile telemetry, managed detection workflows, and incident response procedures can still identify suspicious communications, especially where mobile devices support sensitive operations, identity access, or regulated workflows. Control investment should focus on confirming evidence collection and analysis paths, not assuming that encrypted traffic is either benign or fully inspectable.
Technical view
SOC, detection engineering, and IR teams should validate coverage for Android and iOS behaviors where applications or malware implement known encryption algorithms for C2. ATT&CK provides no official detection text for T1521, but the relationship to DET0641 indicates a detection strategy exists for encrypted channel behavior. The sub-techniques define useful analytic branches: symmetric cryptography, asymmetric cryptography, and SSL pinning. Teams should test whether they can correlate mobile network metadata, application behavior, certificate or pinning indicators where observable, and reverse-engineering findings such as embedded or generated keys in samples or configuration files. Related software examples are Twitoor and AhRat on Android, so Android-focused mobile malware triage should be included where relevant.
Likely telemetry
- Mobile device network connection metadata for Android and iOS
- Mobile application inventory and installation/update history
- Mobile endpoint or MDM/EMM security events where available
- DNS, proxy, firewall, or secure web gateway metadata associated with mobile traffic
- TLS/certificate observation where available, including evidence of certificate pinning limitations
Detection direction
- Do not rely on payload inspection alone; encrypted C2 may hide command content even when traffic is visible.
- Validate DET0641-aligned analytics or equivalent local detections against mobile encrypted-channel behavior, while documenting any telemetry gaps.
- Separate normal encrypted app traffic from suspicious behavior using context such as app reputation, install source, update timing, destination patterns, and unexpected background communications.
- Account for SSL pinning as a visibility blind spot because it may prevent interception and analysis of traffic that would otherwise be inspected.
- Use reverse engineering or malware triage where available to identify known cryptographic algorithms, embedded keys, generated keys, or configuration artifacts.
Mitigation priorities
- Establish baseline visibility for managed Android and iOS devices before an incident, including network metadata and mobile security telemetry.
- Maintain mobile application governance so unexpected or risky apps can be identified and investigated quickly.
- Ensure incident response playbooks include mobile malware collection, app/package analysis, and escalation to reverse engineering when encrypted C2 is suspected.
- Correlate mobile network metadata with identity, device management, and application events to support decision-making when content cannot be inspected.
- Document encryption and SSL-pinning inspection limitations for compliance and audit discussions so leadership understands what evidence is and is not available.
Analyst notes and limits
This object is broad and has no ATT&CK tactic or official detection text supplied. Its value comes from framing mobile encrypted C2 as a visibility and response-readiness issue. The supplied relationships add three analytic branches—symmetric cryptography, asymmetric cryptography, and SSL pinning—and two Android software examples, Twitoor and AhRat. Local validation is required to determine whether an organization has useful telemetry for its mobile fleet.
This take uses only the supplied ATT&CK fields and relationships. It does not assert active exploitation, attribution, enterprise impact, or guaranteed detectability. Platforms are limited to Android and iOS as provided; related software examples supplied here are Android. Specific detection logic, indicators, vendors, and mitigations are not provided by the source fields.
Encrypted Channel
Adversaries may explicitly employ a known encryption algorithm to conceal command and control traffic rather than relying on any inherent protections provided by a communication protocol. Despite the use of a secure algorithm, these implementations may be vulnerable to reverse engineering if necessary secret keys are encoded and/or generated within malware samples/configuration files.
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 |
|---|---|---|---|
| Mobile | T1521.002 | Asymmetric Cryptography Sub-technique | Asymmetric Cryptography subtechnique of this object. |
| Mobile | T1521.001 | Symmetric Cryptography Sub-technique | Symmetric Cryptography subtechnique of this object. |
| Mobile | T1521.003 | SSL Pinning Sub-technique | SSL Pinning subtechnique of this object. |
Groups, software, and campaigns
S1095: AhRat
AhRat is an Android remote access tool based on the open-source AhMyth remote access tool. AhRat initially spread in August 2022 on the Google Play Store via an update containing malicious code to the previously benign application, “iRecorder – Screen Recorder,” which itself was released in September 2021.[1]
S0302: Twitoor
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 | 2.0 | Current bundle | 6e6045219c5c… |
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 T1521Open 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.