| ID | Name |
|---|---|
| T1521.001 | Symmetric Cryptography |
| T1521.002 | Asymmetric Cryptography |
| T1521.003 | SSL Pinning |
Adversaries may use SSL Pinning to protect the C2 traffic from being intercepted and analyzed.
SSL Pinning is a technique commonly utilized by legitimate websites to ensure that encrypted communications are only allowed with a pre-defined certificate. If another certificate is presented, it could indicate device compromise, traffic interception, or another upstream issue. While benign usages are common, it is also possible for adversaries to abuse this technology to protect malicious C2 traffic.
In normal, not pinned SSL validation, when a client connects to a server using HTTPS, it typically checks whether the server’s SSL/TLS certificate is signed by a trusted Certificate Authority (CA) in the device’s trust store. If the certificate is valid and signed by a trusted CA, the connection is established. However, with SSL Pinning , the client is configured to trust a specific SSL/TLS certificate or public key, rather than relying on the device’s trust store. This means that even if the server’s certificate is signed by a trusted CA, the client will only establish the connection of the certificate or key is pinned.
There are two types of SSL Pinning :
Certificate Pinning: The client stores a copy of the server’s certificate and compares it with the certificate received during the SSL handshake. If the certificates match, then the client proceeds with the connection. This approach also works with self-signed certificates.
Public Key Pinning: Instead of pinning the entire certificate, the client pins just the public key extracted from the certificate. This is often more flexible, as it allows the server to renew its certificate without having to update the pinned certificate or breaking the SSL connection.
| ID | Name | Description |
|---|---|---|
| S0507 | eSurv |
eSurv’s Android version has used certificate pinning for C2 communication.[1] |
| ID | Mitigation | Description |
|---|---|---|
| M1012 | Enterprise Policy |
Certain enterprise policies can be applied to prevent users from adding certificates to the device and to prevent applications from being able to install their own certificates. |
| M1011 | User Guidance |
Users should be advised to not trust or install self-signed certificates. |
| ID | Name | Analytic ID | Analytic Description |
|---|---|---|---|
| DET0646 | Detection of SSL Pinning | AN1725 |
The defender correlates application TLS trust customization activity with subsequent outbound encrypted sessions that bypass enterprise interception visibility or fail only under enterprise inspection conditions. The analytic looks for an app establishing its own certificate or public-key trust logic, then initiating HTTPS sessions to destinations not aligned with approved app behavior, especially from background state or without recent user interaction. Higher-confidence observations come from Android runtime/framework telemetry showing custom trust manager, certificate validation override, or pin validation logic immediately preceding network connection attempts, combined with network evidence of failed-inspection patterns or opaque direct TLS sessions. |
| AN1726 |
The defender correlates supervised-device application posture and background execution context with network-side evidence that an app rejects enterprise inspection or performs certificate/public-key-bound trust behavior during TLS establishment. Because direct app-level pin-validation observability is weaker on iOS, the analytic is anchored primarily to network control-plane effects: repeated TLS handshake rejection under enterprise inspection, destination-specific inspection bypass patterns, or persistent opaque app-to-endpoint encrypted sessions inconsistent with baseline app behavior. Additional confidence comes from managed app identity, background execution context, and supervised device policy state. |