AN2017: Analytic 2017
Once adversaries have provisioned compromised infrastructure (ex: a server for use in command and control), internet scans may help proactively discover compromised infrastructure. 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] Consider monitoring for anomalous changes to domain registrant information and/or domain resolution information that may indicate the compromise of a domain. Efforts may need to be tailored to specific domains of interest as benign registration and resolution changes are a common occurrence on the internet. Monitor for queried domain name system (DNS) registry data that may compromise third-party infrastructure that can be used during targeting. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Command and Control. Monitor for logged domain name system (DNS) data that may compromise third-party infrastructure that can be used during targeting. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Command and Control. Monitor for contextual data about an Internet-facing resource gathered from a scan, such as running services or ports that may compromise third-party infrastructure that can be used during targeting. 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
This analytic is about using external internet-scale signals to find infrastructure that may have been compromised or prepared for adversary use, such as command-and-control servers or abused domains. Its business value is early warning: before an incident becomes visible in endpoint alerts, defenders may be able to identify suspicious internet-facing services, certificates, TLS behavior, DNS changes, or domain registration changes that warrant investigation.
Executive priority
Treat this as a threat intelligence and detection-engineering priority, not a standalone control. Leaders should ask whether the organization can monitor its domains and relevant third-party-facing infrastructure for unexpected DNS, registration, service, certificate, and scan-derived changes. The decision value is strongest for incident readiness, brand/domain protection, C2 discovery, and evidence that security teams can detect suspicious infrastructure patterns beyond internal logs alone.
Technical view
SOC and threat intelligence teams should validate whether they can correlate internet scan data, DNS registry data, DNS resolution data, certificate/TLS attributes, and service/port observations for domains and infrastructure of interest. Because the ATT&CK object has platform PRE and no specified tactics or relationships, this should be implemented as pre-compromise or external-threat hunting context that supports later investigation, especially around command-and-control-related infrastructure indicators. Detection logic should be tailored to known-good domain and infrastructure behavior because benign registration, DNS, and service changes are common.
Likely telemetry
- Internet-facing scan results, including open ports, services, banners, and response artifacts
- Certificate metadata and SSL/TLS negotiation characteristics
- DNS registry data, including registrant and registration changes
- DNS resolution data and historical DNS changes for domains of interest
- Contextual enrichment for internet-facing resources gathered from external scanning or threat intelligence sources
Detection direction
- Baseline expected DNS, registrant, certificate, TLS, and exposed-service patterns for domains and infrastructure of interest.
- Tune alerting for anomalous registration or resolution changes, while accounting for routine administrative, hosting, CDN, and certificate-renewal activity.
- Use scan-derived artifacts to identify infrastructure that resembles known suspicious command-and-control patterns, but require analyst validation before escalation.
- Correlate external infrastructure findings with internal DNS, proxy, EDR, firewall, or SIEM evidence where available to determine whether the organization interacted with the infrastructure.
- Document blind spots where external scan coverage, historical DNS visibility, certificate visibility, or asset/domain ownership data is incomplete.
Mitigation priorities
- Maintain an authoritative inventory of owned domains, internet-facing resources, expected DNS records, certificates, and hosting providers.
- Establish change-control and monitoring for domain registration, DNS resolution, certificates, and exposed services.
- Integrate external scan and DNS intelligence into SOC triage workflows so suspicious infrastructure changes can be reviewed quickly.
- Create incident response playbooks for suspected domain compromise or suspicious infrastructure discovery, including validation, containment, and stakeholder notification paths.
- Review third-party and outsourced domain/infrastructure management processes where registrant, DNS, or certificate changes could occur outside normal security visibility.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, AN2017, focused on proactive discovery of potentially compromised infrastructure using internet scans, DNS registry data, DNS logs, certificate/TLS characteristics, and service-response artifacts. No relationships, tactics, aliases, or official detection logic were supplied, so this take emphasizes validation of telemetry and operating process rather than specific rule logic.
The object does not provide a concrete detection query, mapped tactics, related techniques, groups, software, or confirmed exploitation context. Local baselines are required because benign DNS, certificate, registration, and service changes are frequent on the internet. Findings from external scans should be treated as investigative leads, not proof of compromise.
Analytic 2017
Once adversaries have provisioned compromised infrastructure (ex: a server for use in command and control), internet scans may help proactively discover compromised infrastructure. 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] Consider monitoring for anomalous changes to domain registrant information and/or domain resolution information that may indicate the compromise of a domain. Efforts may need to be tailored to specific domains of interest as benign registration and resolution changes are a common occurrence on the internet. Monitor for queried domain name system (DNS) registry data that may compromise third-party infrastructure that can be used during targeting. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Command and Control. Monitor for logged domain name system (DNS) data that may compromise third-party infrastructure that can be used during targeting. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Command and Control. Monitor for contextual data about an Internet-facing resource gathered from a scan, such as running services or ports that may compromise third-party infrastructure that can be used during targeting. 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 | 7adb119b499f… |
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 AN2017Open 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.