Adversaries may buy and/or steal SSL/TLS certificates that can be used during targeting. SSL/TLS certificates are designed to instill trust. They include information about the key, information about its owner's identity, and the digital signature of an entity that has verified the certificate's contents are correct. If the signature is valid, and the person examining the certificate trusts the signer, then they know they can use that key to communicate with its owner.
Adversaries may purchase or steal SSL/TLS certificates to further their operations, such as encrypting C2 traffic (ex: Asymmetric Cryptography with Web Protocols) or even enabling Adversary-in-the-Middle if the certificate is trusted or otherwise added to the root of trust (i.e. Install Root Certificate). The purchase of digital certificates may be done using a front organization or using information stolen from a previously compromised entity that allows the adversary to validate to a certificate provider as that entity. Adversaries may also steal certificate materials directly from a compromised third-party, including from certificate authorities.(Citation: DiginotarCompromise) Adversaries may register or hijack domains that they will later purchase an SSL/TLS certificate for.
Certificate authorities exist that allow adversaries to acquire SSL/TLS certificates, such as domain validation certificates, for free.(Citation: Let's Encrypt FAQ)
After obtaining a digital certificate, an adversary may then install that certificate (see Install Digital Certificate) on infrastructure under their control.
View in MITRE ATT&CK®| Capability ID | Capability Description | Mapping Type | ATT&CK ID | ATT&CK Name | Notes |
|---|---|---|---|---|---|
| action.hacking.variety.Unknown | Unknown | related-to | T1588.004 | Digital Certificates | |
| value_chain.development.variety.Other | The variety of development required is known, but is not listed. | related-to | T1588.004 | Digital Certificates |
| Capability ID | Capability Description | Mapping Type | ATT&CK ID | ATT&CK Name | Notes |
|---|---|---|---|---|---|
| cloud_hsm | Cloud Hardware Security Module (HSM) | technique_scores | T1588.004 | Digital Certificates |
Comments
Google Cloud's HSM may protect against adversary's attempts to compromise digital certificates that can used to encrypt data-in-transit or tamper with the certificate owner's communications. Variations of this technique are difficult to mitigate, so a partial score was granted for this control's medium to high coverage factor.
References
|
| cloud_key_management | Cloud Key Management | technique_scores | T1588.004 | Digital Certificates |
Comments
This control manages symmetric and asymmetric cryptographic keys for cloud services and protects against stealing credentials, certificates, keys from the organization.
References
|
| cloud_storage | Cloud Storage | technique_scores | T1588.004 | Digital Certificates |
Comments
The cloud service provider's default encryption setting for data stored and written to disk in the cloud may protect against adversary's attempt to manipulate customer data-at-rest. This technique was rated as partial due to the medium to high protect coverage factor against variations of this attack.
References
|
| Capability ID | Capability Description | Mapping Type | ATT&CK ID | ATT&CK Name | Notes |
|---|---|---|---|---|---|
| aws_cloudhsm | AWS CloudHSM | technique_scores | T1588.004 | Digital Certificates |
Comments
Certificate credentials can be stored in AWS CloudHSM which reduces the attack surface and threat from these sub-techniques.
References
|
| aws_key_management_service | AWS Key Management Service | technique_scores | T1588.004 | Digital Certificates |
Comments
The encryption key for the certificate can be stored in KMS, reducing its attack surface. Score is capped at Partial because adversaries can still misuse keys/certs if KMS and KMS resources are compromised.
References
|