T1521.002: Asymmetric Cryptography
Adversaries may employ a known asymmetric encryption algorithm to conceal command and control traffic, rather than relying on any inherent protections provided by a communication protocol. Asymmetric cryptography, also known as public key cryptography, uses a keypair per party: one public that can be freely distributed, and one private that should not be distributed. Due to how asymmetric algorithms work, the sender encrypts data with the receiver’s public key and the receiver decrypts the data with their private key. This ensures that only the intended recipient can read the encrypted data. Common public key encryption algorithms include RSA, ElGamal, and ECDSA.
For efficiency, many protocols (including SSL/TLS) use symmetric cryptography once a connection is established, but use asymmetric cryptography to establish or transmit a key. As such, these protocols are classified as Asymmetric Cryptography.
Security context for executives and security teams
Asymmetric Cryptography in mobile ATT&CK describes malware or implants on Android or iOS using public-key encryption, or protocols such as SSL/TLS that rely on it during key exchange, to hide command-and-control traffic. The business issue is not that encryption is unusual; it is that mobile threat activity can blend into expected encrypted traffic, reducing the value of simple network inspection and making device, application, and traffic context more important for response decisions.
Executive priority
Treat this as a mobile visibility and response-readiness problem. Leaders should ask whether managed detection, mobile device controls, and incident response playbooks can distinguish legitimate encrypted mobile app traffic from suspicious encrypted C2 patterns. This is especially relevant where mobile devices carry sensitive data, support executive communications, or are part of regulated evidence chains. Budget and audit discussions should focus on whether Android and iOS telemetry is actually available, retained, and actionable—not on decrypting all traffic by default.
Technical view
For SOC, detection engineering, and IR teams, validate coverage around Android and iOS network behavior where applications or implants establish encrypted channels using asymmetric cryptography or TLS-style key establishment. ATT&CK provides no official detection text for this sub-technique, but relationship context indicates DET0667 detects it. Teams should review that detection strategy and test whether local telemetry can expose suspicious encrypted sessions, unusual destinations, app-to-network mappings, certificate or key-exchange metadata where available, and indicators from reverse engineering when mobile samples or configurations are obtained. Relationship context links this behavior to Operation Triangulation and multiple mobile software entries, including eSurv, CarbonSteal, SilkBean, CHEMISTGAMES, SharkBot, FluBot, and TriangleDB, so mobile threat intelligence should be used to prioritize scenarios without assuming local exposure.
Likely telemetry
- Mobile device network connection metadata for Android and iOS
- App-to-destination mappings, including process or application identity where available
- TLS or encrypted-session metadata where collected, such as destination, timing, certificate, and handshake characteristics
- Mobile EDR/MDM security events and application inventory
- DNS and proxy logs for mobile device traffic when routed through enterprise controls
Detection direction
- Do not rely on payload inspection alone; encrypted C2 may look normal unless correlated with device, app, destination, timing, and reputation context.
- Validate DET0667-aligned logic against the organization’s actual Android and iOS telemetry sources, since the ATT&CK object itself provides no official detection procedure.
- Tune for false positives from legitimate mobile apps and standard SSL/TLS usage; asymmetric cryptography is common in benign protocols.
- Prioritize detections that connect encrypted sessions to suspicious or unauthorized apps, abnormal destinations, newly observed infrastructure, or threat intelligence linked to known mobile campaigns or software where evidence exists.
- Assess blind spots from unmanaged personal devices, direct-to-internet mobile traffic, limited iOS inspection, short log retention, and lack of app identity in network logs.
Mitigation priorities
- Establish mobile asset and application visibility first, including which Android and iOS devices are managed and which apps are authorized.
- Route managed mobile traffic through enterprise-observable controls where appropriate and lawful, preserving useful metadata even when payloads remain encrypted.
- Use MDM/mobile security controls to restrict untrusted applications, enforce platform security settings, and support rapid containment or collection during incidents.
- Integrate mobile threat intelligence and malware-analysis findings into detection engineering rather than treating encrypted traffic as inherently malicious.
- Document telemetry coverage, retention, and response procedures as compliance and incident-readiness evidence.
Additional notes and limits
This take is based only on the supplied ATT&CK fields and relationships. The object is a mobile sub-technique of Encrypted Channel and applies to Android and iOS. ATT&CK relationship data shows use by one campaign and several mobile software entries, including surveillanceware, banking malware, and an iOS implant, but that does not imply the behavior is present in any specific environment.
MITRE provides no official detection text and no tactics for this object in the supplied fields. Practical detection depends heavily on local mobile management, network routing, endpoint telemetry, privacy constraints, and access to mobile malware or configuration artifacts. Encryption itself is normal, so local baselining and correlation are required.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Asymmetric Cryptography
Adversaries may employ a known asymmetric encryption algorithm to conceal command and control traffic, rather than relying on any inherent protections provided by a communication protocol. Asymmetric cryptography, also known as public key cryptography, uses a keypair per party: one public that can be freely distributed, and one private that should not be distributed. Due to how asymmetric algorithms work, the sender encrypts data with the receiver’s public key and the receiver decrypts the data with their private key. This ensures that only the intended recipient can read the encrypted data. Common public key encryption algorithms include RSA, ElGamal, and ECDSA.
For efficiency, many protocols (including SSL/TLS) use symmetric cryptography once a connection is established, but use asymmetric cryptography to establish or transmit a key. As such, these protocols are classified as Asymmetric Cryptography.
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 | Encrypted Channel | This object subtechnique of Encrypted Channel. |
Groups, software, and campaigns
S0507: eSurv
S0555: CHEMISTGAMES
CHEMISTGAMES is a modular backdoor that has been deployed by Sandworm Team.[1]
S0529: CarbonSteal
CarbonSteal is one of a family of four surveillanceware tools that share a common C2 infrastructure. CarbonSteal primarily deals with audio surveillance. [1]
S1216: TriangleDB
TriangleDB is an Objective-C written implant deployed after Binary Validator and after root privileges are obtained during Operation Triangulation’s infection chain. Upon execution, TriangleDB communicates with the C2 server, relaying information about the victim device.[1]
S1055: SharkBot
S0549: SilkBean
S1067: FluBot
FluBot is a multi-purpose mobile banking malware that was first observed in Spain in late 2020. It primarily spread through European countries using a variety of SMS phishing messages in multiple languages.[1][2] An international law enforcement operation of 11 countries eventually disrupted the spread of FluBot.[3]
C0054: Operation Triangulation
Operation Triangulation is a mobile campaign targeting iOS devices.[1] The unidentified actors used zero-click exploits in iMessage attachments to gain Initial Access, then executed exploits and validators, such as Binary Validator before finally executing the TriangleDB implant.
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 | 2e52721b0195… |
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]Lookout eSurv
A. Bauer. (2019, April 8). Lookout discovers phishing sites distributing new iOS and Android surveillanceware. Retrieved September 11, 2020.
Open source URL - [2]CYBERWARCON CHEMISTGAMES
B. Leonard, N. Mehta. (2019, November 21). The Secret Life of Sandworms. Retrieved December 31, 2020.
Open source URL - [3]Lookout Uyghur Campaign
A. Kumar, K. Del Rosso, J. Albrecht, C. Hebeisen. (2020, June 1). Mobile APT Surveillance Campaigns Targeting Uyghurs - A collection of long-running Android tooling connected to a Chinese mAPT actor. Retrieved November 10, 2020.
Open source URL - [4]SecureList OpTriangulation 21Jun2023
Kucherin, G., et al. (2023, June 21). Dissecting TriangleDB, a Triangulation spyware implant. Retrieved April 18, 2024.
Open source URL - [5]nccgroup_sharkbot_0322
RIFT: Research and Intelligence Fusion Team. (2022, March 3). SharkBot: a “new” generation Android banking Trojan being distributed on Google Play Store. Retrieved January 18, 2023.
Open source URL - [6]proofpoint_flubot_0421
Crista Giering, F. Naves, Andrew Conway, Adam McNeil . (2021, April 27). FluBot Android Malware Spreading Rapidly Through Europe, May Hit U.S. Soon. Retrieved February 28, 2023.
Open source URL - [7]mitre-attackT1521.002Open source URL
- [8]mitre-attackT1521.002Open source URL
- [9]SecureList OpTriangulation 21Jun2023
Kucherin, G., et al. (2023, June 21). Dissecting TriangleDB, a Triangulation spyware implant. Retrieved April 18, 2024.
Open source URL - [10]Lookout Uyghur Campaign
A. Kumar, K. Del Rosso, J. Albrecht, C. Hebeisen. (2020, June 1). Mobile APT Surveillance Campaigns Targeting Uyghurs - A collection of long-running Android tooling connected to a Chinese mAPT actor. Retrieved November 10, 2020.
Open 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.