AN2003: Analytic 2003
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. Once adversaries have provisioned a server (ex: for use as a command and control server), internet scans may reveal servers that adversaries have acquired. 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]
Analyst context for executives and security teams
This analytic matters because some adversary infrastructure may be set up before it ever touches the organization, leaving little or no internal telemetry. The practical value is not guaranteed detection inside the enterprise, but earlier awareness through external infrastructure hunting: scanning for internet-facing servers with response patterns, certificates, services, or TLS characteristics associated with known command-and-control tooling.
Executive priority
Treat this as a visibility-gap issue. Leaders should ask whether the security program relies only on internal logs, or whether threat intelligence and external infrastructure monitoring are used to identify likely command-and-control infrastructure before or during an incident. This can support incident readiness, managed detection scoping, and evidence that the organization considers adversary lifecycle stages that occur outside its direct perimeter.
Technical view
The ATT&CK object describes a PRE-platform detection analytic with no tactic specified and no formal detection logic. SOC, threat intelligence, and IR teams should validate whether they can consume and analyze external internet scan data for indicators such as listening services, certificates, SSL/TLS negotiation features, and other response artifacts associated with adversary C2 software. Because much of the behavior occurs outside target visibility, this analytic should be paired with later-stage detections, especially command-and-control monitoring, rather than treated as a standalone internal detection.
Likely telemetry
- External internet scan data
- Server service banners and listening service metadata
- Certificate metadata
- SSL/TLS negotiation characteristics
- Network response artifacts from internet-facing infrastructure
Detection direction
- Validate whether external scan-derived indicators can be operationalized in threat intelligence, SOC triage, or IR workflows.
- Correlate suspected infrastructure with internal command-and-control telemetry where available instead of alerting on external infrastructure alone.
- Tune for false positives: shared hosting, benign security tools, reused certificates, common services, and generic TLS traits can resemble suspicious infrastructure.
- Document blind spots where adversary infrastructure is not exposed to public scans or lacks distinctive response artifacts.
- Use the cited research direction as context for analytic development, but require local validation before treating matches as actionable.
Mitigation priorities
- Prioritize command-and-control detection and response coverage because the ATT&CK description notes that provisioning activity may be outside the organization’s visibility.
- Integrate threat intelligence and external infrastructure monitoring into incident response playbooks where appropriate.
- Define escalation criteria for when suspected external infrastructure becomes relevant to an investigation, such as correlation with internal network activity.
- Maintain evidence of visibility limitations and compensating controls for audit, risk, and security program reviews.
Analyst notes and limits
This object is a detection analytic, not a technique. It emphasizes infrastructure hunting using external scan artifacts after adversaries provision servers, including potential command-and-control servers. No relationships, tactics, or official detection logic were supplied, so the take focuses on defensive validation and operational use rather than specific detection rules.
The supplied ATT&CK fields provide a high-level description only. There is no official detection field, no relationship context, no specific ATT&CK tactic, and no internal platform telemetry beyond PRE. Local tooling, external scan data access, threat intelligence processes, and internal C2 telemetry determine whether this analytic is useful in practice.
Analytic 2003
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. Once adversaries have provisioned a server (ex: for use as a command and control server), internet scans may reveal servers that adversaries have acquired. 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]
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 | 5d27ab8b25bf… |
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 AN2003Open 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.