| ID | Name |
|---|---|
| T1521.001 | Symmetric Cryptography |
| T1521.002 | Asymmetric Cryptography |
| T1521.003 | SSL Pinning |
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.
| ID | Name | Description |
|---|---|---|
| S0529 | CarbonSteal |
CarbonSteal has performed rudimentary SSL certificate validation to verify C2 server authenticity before establishing a SSL connection.[1] |
| S0555 | CHEMISTGAMES |
CHEMISTGAMES has used HTTPS for C2 communication.[2] |
| S0507 | eSurv |
eSurv’s Android version has used public key encryption for C2 communication.[3] |
| S1067 | FluBot |
FluBot has encrypted C2 message bodies with RSA and encoded them in base64.[4] |
| C0054 | Operation Triangulation |
During Operation Triangulation, the threat actors used RSA to encrypt C2 communication.[5] |
| S1055 | SharkBot |
SharkBot has used RSA to encrypt the symmetric encryption key used for C2 messages.[6] |
| S0549 | SilkBean | |
| S1216 | TriangleDB |
TriangleDB has encrypted data using RSA.[5] |
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
| ID | Name | Analytic ID | Analytic Description |
|---|---|---|---|
| DET0667 | Detection of Asymmetric Cryptography | AN1762 |
For Android, detect Asymmetric Cryptography from documented management, network, or vetting evidence; treat state queries as periodic observations rather than real-time events. Correlate Application Permission via Android Enterprise DPC / Application Vetting [DevicePolicyManager.getPermissionGrantState(); PackageManager manifest/requested-permission review]; Application State via Android Enterprise / EMM [Managed package inventory/status and package metadata]; File Creation via Application Vetting / Forensic Acquisition [Dynamic filesystem trace or acquired app-container/filesystem artifacts: App writes asymmetric-encrypted blob or encoded ciphertext to local staging path before network transmission — encrypted staging artifact]. Alert on a sequence or state change inconsistent with the device/app baseline, approved management policy, or expected user workflow; do not infer unobserved API calls, file/process activity, or payload content from management state alone. |
| AN1763 |
Indirect evidence of asymmetric cryptographic channel usage inferred through key exchange-like network patterns and application background execution behavior, where direct observation of keypair operations is limited. Detection correlates app entitlement posture + background execution + asymmetric handshake patterns + subsequent encrypted communication. |