AN1982: Analytic 1982
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] Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Defense Evasion or Command and Control. Monitor for contextual data about a malicious payload, such as compilation times, file hashes, as well as watermarks or other identifiable configuration information. Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Defense Evasion or Command and Control. Monitor for logged network traffic in response to a scan showing both protocol header and body values that may buy and/or steal capabilities that can be used during targeting. Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Defense Evasion or Command and Control. Consider analyzing malware for features that may be associated with malware providers, such as compiler used, debugging artifacts, code similarities, or even group identifiers associated with specific Malware-as-a-Service (MaaS) offerings. Malware repositories can also be used to identify additional samples associated with the developers and the adversary utilizing their services. Identifying overlaps in malware use by different adversaries may indicate malware was obtained by the adversary rather than developed by them. In some cases, identifying overlapping characteristics in malware used by different adversaries may point to a shared quartermaster.[3] Malware repositories can also be used to identify features of tool use associated with an adversary, such as watermarks in Cobalt Strike payloads.[4]
Analyst context for executives and security teams
AN1982 is a detection analytic focused on recognizing adversary infrastructure and tooling patterns that often sit outside a victim organization’s direct visibility: newly issued or reused TLS certificates, certificate defaults in server-side tool components, payload metadata, scan responses, and malware/tooling characteristics such as watermarks or debugging artifacts. The practical value is not a simple alert rule; it is a threat intelligence and incident response capability that helps defenders connect infrastructure, malware samples, and command-and-control indicators before or during an intrusion investigation.
Executive priority
This analytic matters because some meaningful adversary preparation and infrastructure reuse may not appear in internal endpoint or network logs until later stages. Security leaders should treat it as a coverage question for threat intelligence, malware analysis, and managed detection: do teams have access to certificate intelligence, malware repository context, and enough network/security telemetry to pivot from one indicator to related infrastructure? The business decision is whether external intelligence and analysis capabilities are mature enough to support faster scoping, containment, and evidence for incident response and compliance reporting.
Technical view
For SOC, detection engineering, and IR teams, AN1982 should be validated as an enrichment and correlation capability rather than a standalone platform-specific analytic. The supplied ATT&CK object lists platform PRE and no specific tactic, and notes that much of the behavior occurs outside the target organization’s visibility. Teams should confirm whether they can pivot on certificate fields, compare payload metadata such as hashes and compilation times, analyze malware/tool features such as compiler artifacts or watermarks, and correlate any observed infrastructure with later Defense Evasion or Command and Control activity.
Likely telemetry
- Certificate transparency or external certificate intelligence data for newly issued and in-use TLS/SSL certificates
- TLS/SSL certificate metadata observed in network traffic, where collected
- Network traffic logs that preserve protocol header and body values when relevant to scans or responses
- Malicious payload context such as file hashes, compile times, configuration values, and watermarks
- Malware analysis outputs, including compiler indicators, debugging artifacts, code similarities, and tool-specific identifiers
Detection direction
- Validate that certificate pivots can be performed on known certificate fields and default certificate values associated with suspicious infrastructure.
- Use external intelligence cautiously: much of the activity is outside internal visibility, so detections may depend on third-party or repository data rather than local logs alone.
- Correlate infrastructure indicators with payload metadata and malware-analysis findings before escalating, to reduce false positives from shared hosting, common certificates, or benign infrastructure reuse.
- Tune investigations around related lifecycle evidence, especially Defense Evasion or Command and Control, because the analytic itself does not provide a direct internal detection rule.
- Confirm whether malware analysis can identify reusable tool characteristics such as watermarks, compiler artifacts, debugging artifacts, or code similarities without assuming attribution.
Mitigation priorities
- Prioritize visibility and enrichment: ensure SOC and IR workflows can use certificate intelligence, malware repositories, and payload metadata during triage.
- Establish procedures for pivoting from one observed indicator to related certificates, infrastructure, samples, and command-and-control evidence.
- Integrate threat intelligence review with incident response scoping so external infrastructure findings can inform containment decisions without being treated as proof by themselves.
- Document evidence sources and analytic limitations for audit and compliance readiness, especially where detections rely on third-party intelligence or post-incident malware analysis.
- Use findings to improve later-stage detections for command-and-control and defense evasion, where internal telemetry is more likely to provide confirmable evidence.
Analyst notes and limits
The object is an ATT&CK detection analytic, not a technique. It provides descriptive guidance but no official detection field, no relationships, no tactics, and only platform PRE. The strongest supported interpretation is a threat intelligence, malware analysis, and correlation analytic for infrastructure and tooling discovery.
Coverage cannot be inferred from this object alone. Many observations described may occur outside the organization’s visibility and require external certificate services, malware repositories, or specialized analysis. Local data availability, logging depth, legal access to external intelligence, and analyst process determine whether this analytic is actionable.
Analytic 1982
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] Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Defense Evasion or Command and Control. Monitor for contextual data about a malicious payload, such as compilation times, file hashes, as well as watermarks or other identifiable configuration information. Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Defense Evasion or Command and Control. Monitor for logged network traffic in response to a scan showing both protocol header and body values that may buy and/or steal capabilities that can be used during targeting. Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Defense Evasion or Command and Control. Consider analyzing malware for features that may be associated with malware providers, such as compiler used, debugging artifacts, code similarities, or even group identifiers associated with specific Malware-as-a-Service (MaaS) offerings. Malware repositories can also be used to identify additional samples associated with the developers and the adversary utilizing their services. Identifying overlaps in malware use by different adversaries may indicate malware was obtained by the adversary rather than developed by them. In some cases, identifying overlapping characteristics in malware used by different adversaries may point to a shared quartermaster.[3] Malware repositories can also be used to identify features of tool use associated with an adversary, such as watermarks in Cobalt Strike payloads.[4]
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 | 7ef0134db1b1… |
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]
FireEyeSupplyChain
FireEye. (2014). SUPPLY CHAIN ANALYSIS: From Quartermaster to SunshopFireEye. Retrieved March 6, 2017.
Open source URL -
[4]
Analyzing CS Dec 2020
Maynier, E. (2020, December 20). Analyzing Cobalt Strike for Fun and Profit. Retrieved October 12, 2021.
Open source URL -
[5]
mitre-attack AN1982Open 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.