AN2027: Analytic 2027
Monitor for contextual data about an Internet-facing resource gathered from a scan, such as running services or ports that may buy, lease, or rent 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. Once adversaries have provisioned infrastructure (ex: a server for use in command and control), internet scans may help proactively discover adversary acquired 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] Detection efforts may be focused on related stages of the adversary lifecycle, such as during Command and Control. Monitor for queried domain name system (DNS) registry data that may buy, lease, or rent 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 buy, lease, or rent 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. Consider use of services that may aid in tracking of newly acquired infrastructure, such as WHOIS databases for domain registration information. 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
AN2027 is about using external scan, DNS, certificate, and registration context to spot infrastructure that may have been newly acquired or configured for adversary use, especially infrastructure that could later support command and control. Its value is proactive: it helps teams look beyond their own logs and use internet-scale evidence to identify suspicious servers, domains, services, certificates, or response patterns before or during an incident.
Executive priority
Treat this as a threat intelligence and managed detection maturity question, not just a SOC rule. Leaders should ask whether the organization can correlate internal alerts with external infrastructure intelligence, DNS registry data, scan data, and certificate/service fingerprints. This can improve incident triage, command-and-control investigations, and evidence for security program readiness, but it requires data access, analytic maintenance, and analyst review because ATT&CK provides no finished detection logic for this analytic.
Technical view
The supplied ATT&CK object is a PRE-platform detection analytic with no specified tactic and no provided detection implementation. SOC and threat intelligence teams should validate whether they can monitor contextual data from internet-facing resource scans, DNS registry information, DNS logs, WHOIS-style registration data, certificates, SSL/TLS negotiation features, listening services, ports, and other response artifacts. The analytic is most useful when these external observations are correlated with known suspicious infrastructure patterns or with later-stage activity such as possible command-and-control events.
Likely telemetry
- Internet scan data for exposed services, ports, banners, certificates, and response artifacts
- SSL/TLS certificate metadata and negotiation characteristics
- DNS registry and WHOIS-style domain registration data
- Logged DNS data from enterprise resolvers or other DNS logging sources
- Threat intelligence records about infrastructure patterns associated with suspected C2 software
Detection direction
- Confirm access to reliable external scan, DNS registry, DNS log, certificate, and WHOIS-style data sources before assuming coverage.
- Build analytic workflows around identifiable infrastructure patterns such as listening services, certificates in use, TLS behavior, and response artifacts; ATT&CK does not supply a rule or threshold.
- Correlate external infrastructure findings with internal DNS, proxy, firewall, or endpoint observations to reduce false positives from benign hosting, shared infrastructure, scanners, and legitimate administrative services.
- Tune carefully for newly acquired or recently changed infrastructure, but require analyst validation because domain registration and internet scan signals alone do not prove malicious use.
- Use the cited external-reference context as supporting research direction, while keeping local detections grounded in the organization’s own telemetry and risk model.
Mitigation priorities
- Prioritize collection and retention of DNS, proxy/firewall, certificate, and external scan intelligence needed to support infrastructure hunting.
- Establish a repeatable threat intelligence process for tracking suspicious domains, certificates, services, and hosting patterns relevant to command-and-control investigations.
- Integrate external infrastructure indicators into SOC triage and incident response workflows so findings can be checked against internal activity quickly.
- Document data sources, analytic assumptions, review steps, and limitations for compliance readiness and audit evidence.
- Avoid relying on this analytic alone for blocking or incident declaration; use it to enrich investigations and guide corroborating evidence collection.
Analyst notes and limits
This object is an ATT&CK detection analytic rather than a technique. It is focused on proactive discovery of adversary-acquired infrastructure using scan and DNS-related context. The object includes useful examples of observable patterns but does not provide a concrete detection rule, specific tactic mapping, or relationship context.
Official detection content is not provided, tactics are not specified, relationships are absent, and the only listed platform is PRE. Any operational implementation requires local decisions about data providers, retention, enrichment quality, false-positive handling, and how external infrastructure observations are correlated with enterprise telemetry.
Analytic 2027
Monitor for contextual data about an Internet-facing resource gathered from a scan, such as running services or ports that may buy, lease, or rent 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. Once adversaries have provisioned infrastructure (ex: a server for use in command and control), internet scans may help proactively discover adversary acquired 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] Detection efforts may be focused on related stages of the adversary lifecycle, such as during Command and Control. Monitor for queried domain name system (DNS) registry data that may buy, lease, or rent 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 buy, lease, or rent 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. Consider use of services that may aid in tracking of newly acquired infrastructure, such as WHOIS databases for domain registration information. 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 | 22e30f8aa706… |
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 AN2027Open 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.