Self-Signed TLS Certificates: Defending Against T1587.003

Develop Capabilities: Digital Certificates (T1587.003) is a resource development technique tagged PRE. The adversary creates self-signed SSL and TLS certificates for use in operations.

How attackers use it

MITRE explains that TLS certificates are meant to instill trust. They hold information about a key, the owner's identity and the digital signature of an entity that checked the contents. A self-signed certificate lacks the third-party trust that a certificate authority signature brings.

Adversaries may use self-signed certificates to encrypt command and control traffic, for example asymmetric cryptography over web protocols. A self-signed certificate that has been added to the root of trust can even enable adversary-in-the-middle interception. After creating a certificate, the adversary may install it on infrastructure they control.

How to detect it

MITRE suggests using services that track certificates in use on sites across the internet. In some cases it is possible to pivot on known certificate details to find other adversary infrastructure.

It also points to related behaviors: web protocols, asymmetric cryptography and installation of a root certificate.

On your network, the practical signals are:

• Outbound TLS sessions to servers that present self-signed certificates.
• Certificates with default or odd subject fields on unfamiliar hosts.
• New entries in a host's trusted root store.
• Your own certificate transparency searches, to find certificates you did not request.

How to reduce the risk

MITRE lists Pre-compromise as the mitigation. For the parts you control:

• Alert on changes to root certificate stores on managed devices.
• Where policy allows, block or flag outbound connections whose certificates do not chain to a trusted authority.
• Maintain an inventory of your legitimate certificates and compare with certificate transparency logs.
• Use TLS inspection only where it is lawful, justified and carefully protected, because it also depends on trusted roots.

One more tip: when you do find a self-signed certificate on an outbound connection, record its subject, issuer, serial number and validity dates. MITRE notes that certificate details can be used to pivot to other adversary infrastructure, and those fields are the pivot points. A saved record also lets you check later whether the same certificate shows up on another host.

Check your own environment

• Windows, PowerShell, read-only: Get-ChildItem Cert:\LocalMachine\Root | Select Subject,Thumbprint,NotAfter lists trusted roots. Compare with a known good machine.
• Linux or macOS, read-only: openssl s_client -connect host.example.com:443 -servername host.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates shows the subject, issuer and validity of a server certificate. For a self-signed one, subject and issuer match.
• Search certificate transparency for your domain names and look for certificates you did not order.

Quick check

Sources

• MITRE ATT&CK T1587.003: Digital Certificates