AN1980: Analytic 1980
Consider use of services that may aid in the tracking of newly issued certificates and/or certificates in use on sites across the Internet. In some cases it may be possible to pivot on known pieces of certificate information to uncover other adversary infrastructure.[1] Some server-side components of adversary tools may have default values set for SSL/TLS certificates.[2] Monitor for logged network traffic in response to a scan showing both protocol header and body values that may buy and/or steal SSL/TLS certificates that can be used during targeting. Detection efforts may be focused on related behaviors, such as Web Protocols, Asymmetric Cryptography, and/or Install Root Certificate.
Analyst context for executives and security teams
This analytic is about using SSL/TLS certificate information as a defensive hunting clue. For leaders, the value is not that a certificate alone proves malicious activity, but that certificate reuse, default certificate values, or unusual certificate patterns can help uncover related infrastructure before or during an incident. This can improve threat intelligence, managed detection, and incident response scoping when adversary infrastructure uses web protocols, encrypted channels, or installed certificates.
Executive priority
Prioritize this where the organization depends on Internet-facing services, cloud-hosted assets, or threat intelligence-driven detection. The business decision is whether security teams have the data and process to pivot from a suspicious certificate to related infrastructure quickly enough to support blocking, investigation, and incident scoping. It also supports audit and compliance evidence by showing that encrypted traffic is not treated as invisible simply because payloads may be protected.
Technical view
Validate whether SOC, threat intelligence, and IR workflows can collect and search certificate metadata from Internet scanning services, network logs, proxy logs, TLS inspection metadata where legally and operationally appropriate, and asset inventories. Use certificate fields as pivots, especially when investigating infrastructure related to Web Protocols, Asymmetric Cryptography, or Install Root Certificate behaviors referenced by ATT&CK. Treat matches as leads requiring corroboration with network behavior, hosting context, domain/IP reputation, and observed communications rather than as standalone detections.
Likely telemetry
- TLS/SSL certificate metadata, including issuer, subject, serial number, validity dates, SANs, fingerprints, and public key information
- Network traffic logs showing TLS handshakes and destination IP/domain context
- Proxy, firewall, or secure web gateway logs with certificate and protocol metadata where available
- Internet-wide certificate transparency or certificate search service results
- Internal asset inventory and externally exposed service inventory for comparison against known authorized certificates
Detection direction
- Confirm that certificate metadata is retained and searchable; many environments log connections but not enough certificate detail to pivot effectively.
- Tune analytics to identify suspicious reuse, default values, unexpected certificate issuers, unusual validity patterns, or certificate overlap with known investigated infrastructure.
- Correlate certificate findings with related behaviors such as web-based command channels, encrypted communications, or root certificate installation before escalating severity.
- Account for false positives from shared hosting, CDNs, legitimate certificate reuse, managed service providers, and automated certificate issuance.
- Use certificate pivots to expand incident scope, but require local evidence before blocking or declaring compromise.
Mitigation priorities
- Establish an inventory of authorized certificates for Internet-facing and critical internal services.
- Ensure SOC and IR teams have access to certificate search, certificate transparency, and network metadata sources appropriate to the environment.
- Define playbooks for pivoting from a suspicious certificate to domains, IPs, hosting providers, and observed internal communications.
- Integrate certificate-based leads with existing threat intelligence, web protocol monitoring, and encrypted traffic monitoring workflows.
- Review controls around unauthorized root certificate installation and certificate trust changes where relevant to endpoint and identity security programs.
Analyst notes and limits
ATT&CK provides this as a detection analytic under enterprise ATT&CK with platform listed as PRE and no specific tactic supplied. The object emphasizes certificate tracking and certificate metadata pivoting, supported by references on hunting with TLS/SSL certificates and identifying rogue Cobalt Strike servers. No relationship objects were supplied, so the take is limited to the official description and cited related behaviors.
The official detection field is not provided, and no ATT&CK relationships were supplied. This means there is no validated query logic, data component mapping, or specific technology coverage to assert. Local logging, legal constraints on TLS inspection, asset inventory quality, and threat intelligence sources will determine whether this analytic is practical.
Analytic 1980
Consider use of services that may aid in the tracking of newly issued certificates and/or certificates in use on sites across the Internet. In some cases it may be possible to pivot on known pieces of certificate information to uncover other adversary infrastructure.[1] Some server-side components of adversary tools may have default values set for SSL/TLS certificates.[2] Monitor for logged network traffic in response to a scan showing both protocol header and body values that may buy and/or steal SSL/TLS certificates that can be used during targeting. Detection efforts may be focused on related behaviors, such as Web Protocols, Asymmetric Cryptography, and/or Install Root Certificate.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 174e3a2b2aea… |
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]
Splunk Kovar Certificates 2017
Kovar, R. (2017, December 11). Tall Tales of Hunting with TLS/SSL Certificates. Retrieved October 16, 2020.
Open source URL -
[2]
Recorded Future Beacon Certificates
Insikt Group. (2019, June 18). A Multi-Method Approach to Identifying Rogue Cobalt Strike Servers. Retrieved September 16, 2024.
Open source URL -
[3]
mitre-attack AN1980Open 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.