DC0104: Response Content
Captured network traffic that provides details about responses received during an internet scan. This data includes both protocol header values (e.g., HTTP status codes, IP headers, or DNS response codes) and response body content (e.g., HTML, JSON, or raw data). Examples:
- HTTP Scan: A web server responds to a probe with an HTTP 200 status code and an HTML body indicating the default page is accessible. - DNS Scan: A DNS server replies to a query with a resolved IP address for a domain, along with details like Time-To-Live (TTL) and authoritative information. - TCP Banner Grab: A service listening on a port (e.g., SSH or FTP) responds with a banner containing service name, version, or other metadata.
Analyst context for executives and security teams
Response Content is the evidence captured from how internet-facing services answer scans, including protocol headers, status codes, DNS answers, banners, and response bodies. For security leaders, its value is exposure clarity: it helps teams understand what outsiders can learn about reachable services, default pages, versions, DNS behavior, and other metadata that may influence prioritization, monitoring, and incident triage.
Executive priority
Treat this data component as a validation point for external attack surface management and SOC readiness. If the organization cannot reliably collect or review response content from internet scans, leaders may have weak evidence for which services are exposed, whether default or unintended content is visible, and whether remediation or compensating controls are working. It can also support audit and risk discussions by showing observable service behavior rather than relying only on asset inventory assumptions.
Technical view
SOC, IR, and exposure management teams should verify whether internet scan results preserve both response metadata and body content where appropriate: HTTP status codes and pages, DNS response codes and TTL/authoritative details, IP and protocol headers, and service banners such as SSH or FTP version strings. Because no ATT&CK detection guidance, platforms, tactics, or relationships are supplied for this object, use it as a telemetry and evidence class rather than as a standalone analytic.
Likely telemetry
- Captured network traffic from internet scans
- HTTP response status codes, headers, and response bodies
- DNS response codes, resolved IP addresses, TTL values, and authoritative response details
- TCP service banners showing service name, version, or metadata
- Raw protocol response data from externally reachable services
Detection direction
- Validate that scan collection retains enough response detail to distinguish open, filtered, redirected, default, and unexpected service behavior.
- Tune review workflows to flag externally visible default pages, unexpected successful responses, unusual DNS answers, or banners exposing service/version metadata.
- Correlate response content with asset inventory and approved exposure records to reduce false positives from known services while highlighting unmanaged or changed services.
- Account for blind spots where scanners store only port state or status summaries and discard headers, banners, DNS detail, or response bodies needed for investigation.
Mitigation priorities
- Prioritize accurate external asset inventory and confirm which services are intended to be internet reachable.
- Reduce unnecessary response detail where business function permits, such as default pages or verbose service banners.
- Use response-content evidence to verify remediation after exposure changes, configuration hardening, or service retirement.
- Retain scan evidence in a way that supports incident response, compliance review, and change validation without over-collecting sensitive content.
Analyst notes and limits
This is a data component, not a technique. Its defensive value is strongest when paired with local scan programs, external attack surface processes, asset ownership data, and incident response workflows. The supplied ATT&CK object provides examples of HTTP, DNS, and TCP banner responses but does not define analytics or associated techniques.
Official detection guidance, platforms, tactics, and relationship context were not supplied. Any assessment of coverage, risk severity, or control effectiveness requires local evidence about scanning scope, retention, asset ownership, and approved internet-facing services.
Response Content
Captured network traffic that provides details about responses received during an internet scan. This data includes both protocol header values (e.g., HTTP status codes, IP headers, or DNS response codes) and response body content (e.g., HTML, JSON, or raw data). Examples:
- HTTP Scan: A web server responds to a probe with an HTTP 200 status code and an HTML body indicating the default page is accessible. - DNS Scan: A DNS server replies to a query with a resolved IP address for a domain, along with details like Time-To-Live (TTL) and authoritative information. - TCP Banner Grab: A service listening on a port (e.g., SSH or FTP) responds with a banner containing service name, version, or other metadata.
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 | 3c848c8cba4d… |
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 DC0104Open 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.