AN2006: Analytic 2006
Once adversaries have provisioned software on a compromised server (ex: for use as a command and control server), internet scans may reveal servers that adversaries have compromised. Consider looking for identifiable patterns such as services listening, certificates in use, SSL/TLS negotiation features, or other response artifacts associated with adversary C2 software.[1][2][3] 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 Command and Control.
Analyst context for executives and security teams
AN2006 is about using external internet-scan evidence to identify infrastructure that may have been provisioned or compromised for adversary command-and-control use. Its business value is not that it guarantees detection inside the enterprise; MITRE explicitly notes much of the activity occurs outside the target organization’s visibility. The practical takeaway is that security teams should decide whether external infrastructure intelligence is part of their threat intelligence and incident response process, especially when investigating command-and-control activity.
Executive priority
Treat this as a readiness and intelligence question: does the organization have a way to use external scan data, certificate patterns, service banners, TLS characteristics, and related response artifacts to support investigations and prioritization? This can improve incident decision-making and threat intelligence enrichment, but it should not be presented as a primary control or guaranteed detection source because the ATT&CK object provides no direct detection logic and notes visibility limitations.
Technical view
For SOC, threat intelligence, and IR teams, AN2006 points to validation of external-facing infrastructure hunting rather than endpoint or internal network monitoring. Teams should assess whether they can collect or access internet scan datasets and use them to compare suspicious infrastructure against known or researched C2-related response patterns, including listening services, certificates, SSL/TLS negotiation traits, and other server response artifacts. Because no tactics are specified and no formal detection analytic is provided, this should be tied to related investigation workflows such as command-and-control triage rather than treated as a standalone alert.
Likely telemetry
- External internet scan data covering services exposed on public IPs
- Service banners and protocol response artifacts
- TLS/SSL certificate metadata
- TLS negotiation characteristics
- Threat intelligence enrichment records for suspected command-and-control infrastructure
Detection direction
- Validate whether external scan intelligence is available to analysts and whether its freshness, coverage, and licensing support operational use.
- Use scan-derived patterns as enrichment and hypothesis generation, not as sole proof of malicious infrastructure.
- Tune for false positives: shared hosting, reused certificates, common software stacks, and benign services can resemble suspicious infrastructure patterns.
- Correlate externally observed infrastructure traits with internal command-and-control investigations where available.
- Document visibility gaps, since the ATT&CK description states much of this activity may occur outside the target organization’s visibility.
Mitigation priorities
- Prioritize strong command-and-control detection and response workflows, since MITRE notes detection may need to focus on related lifecycle stages.
- Add external infrastructure intelligence capability where it supports threat intelligence, SOC triage, or incident response decisions.
- Create procedures for validating scan-derived leads before escalation or blocking.
- Maintain evidence handling and documentation so scan intelligence can support audit, compliance, and incident review without overstating certainty.
- Review public exposure and asset ownership processes so defenders can distinguish owned infrastructure from third-party or adversary-controlled infrastructure during investigations.
Analyst notes and limits
This object is a detection analytic, not a technique, and it has no supplied relationship context, tactics, or official detection logic. The strongest supported interpretation is external infrastructure hunting for possible adversary C2 software based on observable server characteristics. The cited references support the general concept of infrastructure research and scan-based hunting, but local implementation depends on available data sources and analyst workflow.
ATT&CK provides no formal detection query, no relationships, no specific platform beyond PRE, and no claim that this detects activity inside a victim environment. Any operational use requires local telemetry, external scan access, validation criteria, and correlation with other evidence.
Analytic 2006
Once adversaries have provisioned software on a compromised server (ex: for use as a command and control server), internet scans may reveal servers that adversaries have compromised. Consider looking for identifiable patterns such as services listening, certificates in use, SSL/TLS negotiation features, or other response artifacts associated with adversary C2 software.[1][2][3] 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 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 | 2b3020376605… |
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]
ThreatConnect Infrastructure Dec 2020
ThreatConnect. (2020, December 15). Infrastructure Research and Hunting: Boiling the Domain Ocean. Retrieved October 12, 2021.
Open source URL -
[2]
Mandiant SCANdalous Jul 2020
Stephens, A. (2020, July 13). SCANdalous! (External Detection Using Network Scan Data and Automation). Retrieved November 17, 2024.
Open source URL -
[3]
Koczwara Beacon Hunting Sep 2021
Koczwara, M. (2021, September 7). Hunting Cobalt Strike C2 with Shodan. Retrieved October 12, 2021.
Open source URL -
[4]
mitre-attack AN2006Open 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.