SSL Pinning
Where this stands
No Sigma rule can address this — the telemetry MITRE names has no Sigma logsource behind it.
Sigma has no logsource taxonomy for mobile platforms. MITRE's telemetry here is mobile EDR and device APIs, which no Sigma rule can address.
What the technique is
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. […]
Read it on attack.mitre.orgWhat MITRE says you would watch
- 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. […]
- 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. […]
Technique names and descriptions © MITRE ATT&CK®, CC BY 4.0. Not endorsed by MITRE.