AN1985: Analytic 1985
Consider analyzing malware for features that may be associated with the adversary and/or their developers, such as compiler used, debugging artifacts, or code similarities. Malware repositories can also be used to identify additional samples associated with the adversary and identify development patterns over time. 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. Consider use of services that may aid in the tracking of capabilities, such as certificates, in use on sites across the Internet. In some cases it may be possible to pivot on known pieces of information to uncover other adversary infrastructure.[1] 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.
Analyst context for executives and security teams
This analytic is about using malware and infrastructure context—such as compiler artifacts, debugging traces, code similarities, hashes, compilation times, configuration watermarks, and TLS/SSL certificate clues—to connect related malicious payloads or infrastructure. Its business value is less about direct in-environment alerting and more about improving threat intelligence, incident scoping, and prioritization when an organization has malware samples or known indicators to investigate.
Executive priority
Treat this as an intelligence and incident-response capability rather than a conventional detection rule. Leaders should ask whether the organization can enrich malware findings, pivot from known indicators to related samples or infrastructure, and turn that context into containment and monitoring decisions. Because MITRE notes much of this activity occurs outside the target organization’s visibility, expectations should be set around investigative value, not guaranteed real-time detection.
Technical view
For SOC, IR, and threat intelligence teams, validate the workflow for extracting and preserving payload context: file hashes, compile timestamps, compiler/debug artifacts, code similarities, embedded configuration, watermarks, and certificate-related infrastructure clues. Since no ATT&CK tactic is specified and the platform is PRE, this analytic should be mapped to pre-compromise intelligence, malware analysis, and enrichment workflows, with downstream detections focused on related Defense Evasion or Command and Control activity where local telemetry exists.
Likely telemetry
- Malware sample metadata and static-analysis results
- File hashes and related repository enrichment
- Compilation timestamps and compiler/debugging artifacts
- Embedded configuration values, watermarks, or identifiers
- Code similarity or family-clustering results from malware repositories
Detection direction
- Confirm whether analysts can pivot from a known payload or certificate clue to related samples or infrastructure using approved malware repositories or intelligence sources.
- Tune expectations: this is not primarily host or network detection inside the victim environment because the official description says much of the activity is outside target visibility.
- Use findings to seed detections for observable follow-on behavior, especially Defense Evasion or Command and Control, rather than treating artifact similarity alone as proof of activity in the environment.
- Account for false positives and uncertainty: shared code, reused certificates, misleading compile times, and commodity tooling can weaken attribution or clustering confidence.
- Document how enriched indicators are promoted into SOC monitoring, IR scoping, and threat intelligence reporting.
Mitigation priorities
- Establish a malware-analysis and enrichment process for samples and indicators collected during investigations.
- Maintain access to reputable malware repositories or intelligence services where appropriate for the organization’s risk profile.
- Integrate enriched indicators into SIEM, EDR, network monitoring, and incident-response playbooks only after confidence and relevance are assessed.
- Prioritize monitoring for related observable behaviors in later lifecycle stages, especially command-and-control or evasion behaviors, where internal telemetry can provide evidence.
- Preserve analysis outputs as audit and investigation evidence, including source, timestamp, confidence, and rationale for any pivots.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique, and has no relationship context. Its strongest use is in threat intelligence enrichment and IR scoping. The cited Splunk reference supports certificate-based hunting as one possible pivot method, but the object does not prescribe a vendor-specific implementation.
Official detection content is not provided, tactics are not specified, and the only platform listed is PRE. The object explicitly states that much of the behavior may occur outside the visibility of the target organization, so local detection coverage depends on available samples, indicator sources, malware-analysis capability, and downstream telemetry.
Analytic 1985
Consider analyzing malware for features that may be associated with the adversary and/or their developers, such as compiler used, debugging artifacts, or code similarities. Malware repositories can also be used to identify additional samples associated with the adversary and identify development patterns over time. 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. Consider use of services that may aid in the tracking of capabilities, such as certificates, in use on sites across the Internet. In some cases it may be possible to pivot on known pieces of information to uncover other adversary infrastructure.[1] 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.
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 | 81346634ccb2… |
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]
mitre-attack AN1985Open 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.