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 :
1. 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.
2. 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.
Analyst context for executives and security teams
SSL pinning matters because it can make malicious mobile command-and-control traffic harder to inspect. On Android and iOS, a malicious app can be built to trust only a specific certificate or public key, defeating many normal TLS interception or proxy-based analysis workflows. For leaders, the practical issue is not that SSL pinning is always malicious—it is also common in legitimate apps—but that mobile investigations and monitoring programs cannot depend solely on decrypted network visibility.
Executive priority
Treat this as a mobile security and incident-response readiness concern. If the organization relies on mobile devices for sensitive operations, executives should ask whether security teams can analyze suspicious mobile apps and traffic when TLS inspection fails. Budget and control decisions should prioritize enterprise mobile policy, user guidance, app governance, and evidence collection that does not assume network decryption will be available.
Technical view
For SOC, detection engineering, and IR teams, validate coverage on Android and iOS for suspicious encrypted channels where certificate or public-key pinning may block interception. Because ATT&CK provides no official detection text for this object, use the related detection strategy DET0646 as a prompt to test local capability: can analysts recognize pinned TLS behavior during mobile app analysis, failed proxy interception, or dynamic testing? Also treat this as a sub-technique of Encrypted Channel, so network indicators alone may be insufficient. The related software entry eSurv shows this behavior is documented in mobile surveillanceware, but the supplied data does not support broader prevalence or attribution claims.
Likely telemetry
- Mobile app inventory and provenance from EMM/MDM or equivalent enterprise mobile management
- Mobile network connection metadata, including destinations, timing, TLS handshake characteristics, and proxy/interception failures
- Static and dynamic mobile app analysis results showing pinned certificates, pinned public keys, or custom TLS validation behavior
- Mobile device security alerts and investigation artifacts from Android and iOS devices
- Policy compliance data showing whether devices are managed and whether risky app installation behavior is controlled
Detection direction
- Do not rely only on TLS decryption; pinned connections may intentionally resist interception.
- Tune analysis to distinguish legitimate SSL pinning in approved apps from suspicious pinning in unknown, sideloaded, or investigation-relevant apps.
- Validate whether mobile malware analysis workflows can identify certificate pinning and public-key pinning without needing offensive bypass instructions.
- Correlate pinned encrypted traffic with app provenance, device management state, user behavior, and any suspicious mobile software findings.
- Document blind spots where unmanaged devices, limited mobile telemetry, or lack of app analysis capability prevent confident assessment.
Mitigation priorities
- Use enterprise mobile policy through EMM/MDM to control allowed mobile behavior where applicable.
- Provide user guidance that reduces risky mobile app installation and configuration behavior.
- Maintain mobile app governance processes for apps used in sensitive business workflows.
- Prepare IR procedures for cases where encrypted mobile traffic cannot be decrypted and app/device-level evidence is required.
- Use the SSL pinning finding as a trigger to review mobile visibility assumptions rather than as proof of malicious activity by itself.
Analyst notes and limits
SSL pinning is dual-use: legitimate applications commonly use it to strengthen TLS trust decisions, while adversaries may abuse it to protect mobile C2 traffic from interception and analysis. The most important analytic distinction is context: app legitimacy, device management state, destination behavior, and whether the pinned communication aligns with expected business use.
The ATT&CK object does not specify tactics and does not provide official detection guidance. Relationship context includes a detection strategy, two mitigations, the parent Encrypted Channel technique, and one software use relationship. Local telemetry, mobile management coverage, and app analysis capability are required to determine actual exposure or detection coverage.
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 :
1. 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.
2. 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.
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
All related ATT&CK context
Mitigation direction
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 | ff93e9e25123… |
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 T1521.003Open 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.