AN1986: Analytic 1986
Once adversaries have provisioned software on a compromised VPS (ex: for use as a command and control server), internet scans may reveal VPSs 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
AN1986 is about finding adversary-prepared VPS infrastructure by observing how it appears from the public internet, such as exposed services, certificates, TLS behavior, or other response artifacts associated with command-and-control software. Its business value is not that an organization can always see this directly, but that external infrastructure hunting can improve threat intelligence, incident scoping, and earlier recognition of C2 patterns that may later interact with the enterprise.
Executive priority
Treat this as a threat intelligence and detection-engineering priority rather than a traditional endpoint control. Leaders should ask whether the organization has a repeatable way to consume external scan intelligence, enrich suspicious infrastructure, and connect those findings to SOC monitoring for Command and Control. The main risk decision is whether C2 infrastructure patterns are being used to inform blocking, investigation, and incident response, or whether defenders only react after internal systems communicate with known-bad endpoints.
Technical view
The supplied analytic applies to the PRE platform and describes external observation of potentially compromised VPS infrastructure after adversary software has been provisioned. Because MITRE notes much of the activity occurs outside target visibility and provides no formal detection logic, SOC and IR teams should validate adjacent coverage: enrichment of suspicious internet hosts, TLS/certificate/service fingerprint review, correlation with outbound network connections, and escalation paths when external infrastructure resembles known C2 response artifacts. Relationship context is not supplied, so detections should remain behavior- and evidence-driven rather than tied to a specific technique relationship.
Likely telemetry
- External internet scan data or third-party scan intelligence
- Observed listening services and exposed ports on internet hosts
- TLS/SSL certificate metadata and certificate reuse indicators
- TLS negotiation characteristics and server response artifacts
- Threat intelligence records for suspected C2 infrastructure
Detection direction
- Validate whether external scan findings can be operationalized by the SOC, not just collected by threat intelligence teams.
- Correlate VPS fingerprints, certificates, and service responses with internal outbound network telemetry before escalating to incident response.
- Tune for false positives because exposed services, certificates, and TLS features can overlap with benign infrastructure.
- Focus detections on related lifecycle stages, especially Command and Control, because the provisioning and scanning activity may be outside the organization’s direct visibility.
- Document visibility gaps where public scan data, TLS metadata, or outbound network logs are unavailable or not retained long enough for investigation.
Mitigation priorities
- Prioritize collection and retention of outbound DNS, proxy, firewall, and network session evidence needed to validate contact with suspicious infrastructure.
- Establish a threat intelligence workflow for reviewing external scan intelligence and converting high-confidence findings into SOC enrichment or watchlists.
- Use certificate, service, and TLS response characteristics as investigation pivots, with human review or confidence scoring before blocking decisions.
- Ensure incident response playbooks include steps for infrastructure enrichment and C2 correlation when suspicious external VPSs are identified.
- Maintain compliance evidence showing how external threat intelligence is evaluated, actioned, and linked to detection or response decisions.
Analyst notes and limits
The official object is a detection analytic, not a technique, and includes no ATT&CK tactics or relationship context. The strongest defensive use is as a reminder to connect external infrastructure research with internal C2 monitoring and incident response workflows. The cited references support the idea of internet-scale infrastructure hunting and scan-data-driven detection, but local evidence is required before concluding that a given VPS is relevant to an organization.
MITRE provides no formal detection logic, no specific data components, no relationships, and no target-environment visibility assumptions beyond noting that much of the activity occurs outside the target organization. This take does not assert active exploitation, attribution, or confirmed detection coverage.
Analytic 1986
Once adversaries have provisioned software on a compromised VPS (ex: for use as a command and control server), internet scans may reveal VPSs 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 | f2efc0b961c7… |
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 AN1986Open 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.