DET0027: Detection of Web Protocol-Based C2 Over HTTP, HTTPS, or WebSockets
DET0027 is a detection strategy for command-and-control traffic that hides inside normal-looking web protocols such as HTTP, HTTPS, or WebSockets. Its busi...
Analyst context for executives and security teams
DET0027 is a detection strategy for command-and-control traffic that hides inside normal-looking web protocols such as HTTP, HTTPS, or WebSockets. Its business value is that web traffic is usually allowed through networks, so leaders should not assume perimeter filtering alone will expose or stop this behavior. The key decision is whether the organization can distinguish legitimate web communications from suspicious C2-like patterns using network, proxy, DNS, TLS, and endpoint context.
Executive priority
Prioritize this as a resilience and SOC readiness question: can the organization investigate and contain suspected web-based command-and-control without disrupting normal business web access? Because the related ATT&CK technique is T1071.001 under command-and-control, this matters for incident escalation, egress visibility, audit evidence around monitoring, and control investment in network detection, proxy logging, and response playbooks. It is especially important where related platforms include ESXi, Linux, macOS, and network devices, since those assets may have different logging depth and response options.
Technical view
The supplied ATT&CK object has no official detection text and no platforms of its own, but it detects T1071.001 Web Protocols. SOC and detection teams should validate coverage for web-protocol C2 indicators and behaviors rather than relying on simple allow/block rules. Useful validation areas include outbound HTTP/HTTPS/WebSocket session metadata, unusual destinations, abnormal beacon-like timing, uncommon user agents or headers where visible, TLS and certificate metadata, proxy outcomes, DNS resolution context, and endpoint process-to-network associations. Detection engineering should account for the fact that HTTP/S and WebSocket traffic is common and therefore high-noise without enrichment and baselining.
Likely telemetry
- Web proxy logs and secure web gateway events
- Firewall and network flow records for outbound web traffic
- DNS query and response logs
- TLS metadata, including SNI and certificate details where collected
- HTTP metadata such as method, host, URI path, status code, user agent, and headers where legally and technically available
Detection direction
- Validate that web egress telemetry is retained and searchable across direct internet access, proxy-mediated access, and device or server segments.
- Tune detections around combinations of weak signals: rare destinations, newly observed domains, repetitive timing, unusual byte ratios, uncommon web methods or headers, long-lived sessions, and endpoint process context.
- Establish baselines for normal business web traffic to reduce false positives from software updates, monitoring agents, developer tools, and cloud services.
- Confirm visibility for HTTPS where payload inspection is unavailable; rely on metadata, destination reputation, DNS, TLS, flow behavior, and endpoint context rather than assuming content inspection.
- Review blind spots for non-user assets and related platforms such as ESXi, Linux, macOS, and network devices, where proxy use and endpoint logging may differ.
Mitigation priorities
- Start with complete asset and egress visibility: know which systems can initiate outbound HTTP, HTTPS, or WebSocket traffic and through which controls.
- Route web egress through monitored control points where operationally feasible, and reduce unmanaged direct-to-internet paths.
- Apply least-privilege egress rules for servers, infrastructure, and network devices, allowing only required destinations and services where business requirements support it.
- Ensure incident response playbooks include containment options for suspicious web-protocol C2, such as isolating hosts, blocking destinations, and preserving relevant network and endpoint logs.
- Use detection testing and tabletop exercises to prove that SOC teams can investigate suspicious web traffic without relying on payload visibility alone.
Analyst notes and limits
This take is based on DET0027 and its relationship to T1071.001 Web Protocols. The ATT&CK object itself does not provide an official description, detection logic, tactics, or platforms; the practical guidance therefore comes from the supplied relationship context and common defensive validation needs for web-protocol command-and-control.
No active exploitation, adversary attribution, specific tool behavior, vendor control, or guaranteed detection coverage is stated in the supplied fields. Local network architecture, logging configuration, TLS visibility, proxy design, and endpoint telemetry determine actual coverage and false-positive rates.
Detection of Web Protocol-Based C2 Over HTTP, HTTPS, or WebSockets
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1071.001 | Web Protocols Sub-technique | This object detects Web Protocols. |
All related ATT&CK context
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 | 978c82832ce5… |
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 DET0027Open 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.