DC0106: Response Metadata
Contextual information about an Internet-facing resource collected during a scan, including details such as open ports, running services, protocols, and versions. This metadata is typically derived from interpreting scan results and helps build a profile of the targeted system. Examples:
- Port and Service Details: - Open ports (e.g., 22, 80, 443). - Identified services running on those ports (e.g., SSH, HTTP, HTTPS). - Service Versions: Detected software version information (e.g., Apache 2.4.41, OpenSSH 8.2). - Operating System Information: OS fingerprinting data (e.g., Linux Kernel 5.4.0). - TLS/SSL Certificate Data: Information about the TLS/SSL certificate, such as the expiration date, issuer, and cipher suites.
*Data Collection Measures:*
- Scanning Tools: - Nmap: Collects port, service, and version information using commands like nmap -sV
Analyst context for executives and security teams
Response Metadata is the inventory-style evidence produced when Internet-facing systems are scanned: open ports, exposed services, software versions, operating system fingerprints, and TLS/SSL certificate details. Its business value is not just technical discovery; it helps leaders understand what outsiders can learn about exposed assets and whether defenders have enough visibility to prioritize remediation, validate cloud exposure, and support incident response decisions.
Executive priority
Treat this data component as a visibility and risk-prioritization input for external attack surface management. Security leaders should ask whether the organization can reliably identify exposed services, outdated versions, certificate issues, and cloud-hosted Internet-facing resources before an incident or audit forces the question. It is especially relevant to vulnerability management, cloud security oversight, compliance evidence, and SOC readiness because missing or stale response metadata can hide externally visible risk.
Technical view
SOC, detection engineering, and IR teams should validate that authorized scan results, firewall/IDS/IPS logs, Zeek or Suricata-style network metadata, OSINT exposure data, and cloud security monitoring outputs can be correlated to known Internet-facing assets. Because ATT&CK provides no tactics, platforms, relationships, or detection logic for this data component, teams should use it as an evidence source rather than a standalone detection. Key validation questions include whether service banners, port exposure, protocol details, certificate metadata, and observed scan traffic are collected, normalized, time-stamped, and mapped to asset ownership.
Likely telemetry
- Authorized external scan results for open ports, services, protocols, versions, and OS fingerprints
- Firewall, IDS, or IPS logs showing inbound scan attempts or Internet-facing service exposure
- Network security metadata such as Zeek or Suricata logs
- TLS/SSL certificate metadata including issuer, expiration, and cipher suite information
- OSINT or external attack surface records from aggregated Internet scan sources
Detection direction
- Validate coverage by comparing known Internet-facing assets against collected response metadata; gaps often indicate unmonitored cloud resources, unmanaged services, or stale asset inventory.
- Tune interpretation carefully: scan traffic and exposed-service observations may come from legitimate monitoring, third-party assessment, Internet background scanning, or unauthorized reconnaissance.
- Correlate response metadata with asset ownership, vulnerability data, change records, and cloud resource context so SOC teams can distinguish expected exposure from unexpected exposure.
- Do not treat this data component as a complete detection by itself; ATT&CK supplies no official detection text or relationship context for this object.
Mitigation priorities
- Maintain an accurate inventory of Internet-facing resources and confirm each exposed service has a business owner.
- Use authorized scanning and cloud security monitoring to keep port, service, version, and certificate metadata current.
- Prioritize remediation or exposure reduction for unnecessary services, outdated versions, and certificate weaknesses identified through response metadata.
- Preserve response metadata as compliance and incident response evidence showing what was externally visible at a point in time.
Analyst notes and limits
This object is a data component, not a technique. Its main defensive value is enabling external exposure validation, vulnerability prioritization, and investigation context. Glexia would use it to help clients test whether their asset inventory, cloud monitoring, SOC telemetry, and vulnerability management processes agree on what is visible from the Internet.
The supplied ATT&CK object includes no platforms, tactics, official detection guidance, or relationships. Any assessment of coverage, risk, or priority must be confirmed against the organization’s actual Internet-facing assets, cloud environments, logging architecture, and approved scanning processes.
Response Metadata
Contextual information about an Internet-facing resource collected during a scan, including details such as open ports, running services, protocols, and versions. This metadata is typically derived from interpreting scan results and helps build a profile of the targeted system. Examples:
- Port and Service Details: - Open ports (e.g., 22, 80, 443). - Identified services running on those ports (e.g., SSH, HTTP, HTTPS). - Service Versions: Detected software version information (e.g., Apache 2.4.41, OpenSSH 8.2). - Operating System Information: OS fingerprinting data (e.g., Linux Kernel 5.4.0). - TLS/SSL Certificate Data: Information about the TLS/SSL certificate, such as the expiration date, issuer, and cipher suites.
*Data Collection Measures:*
- Scanning Tools: - Nmap: Collects port, service, and version information using commands like nmap -sV
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 | 2.0 | Current bundle | 2c019e67b2aa… |
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]
mitre-attack DC0106Open 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.