T1071.001: Web Protocols
Adversaries may communicate using application layer protocols associated with web traffic to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server.
Protocols such as HTTP/SCitationCrowdStrike Putter Panda and WebSocketCitationBrazking-Websockets that carry web traffic may be very common in environments. HTTP/S packets have many fields and headers in which data can be concealed. An adversary may abuse these protocols to communicate with systems under their control within a victim network while also mimicking normal, expected traffic.
Security context for executives and security teams
Web Protocols (T1071.001) matters because command-and-control can hide inside traffic every organization must allow: HTTP, HTTPS, and WebSockets. For leaders, the issue is not whether web traffic exists, but whether the organization can distinguish normal business web use from remote control traffic across Windows, Linux, macOS, ESXi, and network devices.
Executive priority
Prioritize this as a resilience and visibility question: do network boundaries, endpoints, and SOC processes provide usable evidence for suspicious web-based command-and-control, including encrypted or high-volume web traffic? The relationship set shows this technique appearing across many reported campaigns, including espionage, ransomware, supply-chain, government, energy, critical infrastructure, MSP/ISP, and network-device-focused activity, so coverage should be treated as a core control-validation item rather than a niche malware signature problem.
Technical view
ATT&CK provides no official detection text for this sub-technique, but it is associated with detection strategy DET0027: Detection of Web Protocol-Based C2 Over HTTP, HTTPS, or WebSockets. SOC and detection teams should validate visibility into outbound and lateral web traffic, especially unusual HTTP/S or WebSocket sessions, uncommon destinations, abnormal request patterns, suspicious headers or user-agent behavior where visible, and endpoint processes initiating web connections inconsistent with their role. Because this is a sub-technique of Application Layer Protocol under command-and-control, detection should focus on behavior and context rather than assuming web ports or TLS imply benign traffic.
Likely telemetry
- Proxy and secure web gateway logs for HTTP, HTTPS, and WebSocket traffic
- Firewall, egress, ingress, and lateral traffic logs
- Network IDS/IPS alerts and signature matches at network boundaries
- Network flow metadata such as source, destination, ports, timing, volume, and session duration
- HTTP metadata where available, including host, URI, method, headers, and user-agent fields
Detection direction
- Map current detections to DET0027 and confirm they cover HTTP, HTTPS, and WebSocket-based command-and-control patterns, not only cleartext HTTP.
- Baseline expected web traffic by server role, workstation group, network device, and administrative function so anomalous destinations, timing, volume, or client behavior can be reviewed in context.
- Tune carefully for false positives from legitimate web applications, software updates, APIs, collaboration tools, and administrative platforms that may use persistent HTTPS or WebSocket sessions.
- Pay special attention to blind spots created by encrypted HTTPS, unmanaged endpoints, network devices with limited logging, ESXi management paths, and traffic that bypasses proxies or inspection points.
- Use relationship context from campaigns involving exposed servers, network devices, MSP/ISP environments, supply chain activity, ransomware intrusion, and critical infrastructure to guide tabletop scenarios and threat hunting priorities without assuming local exposure.
Mitigation priorities
- Implement M1037 Filter Network Traffic by enforcing ingress, egress, and lateral traffic rules based on authorized business needs.
- Use M1031 Network Intrusion Prevention with intrusion detection/prevention signatures at network boundaries, recognizing that signatures should supplement—not replace—behavioral monitoring.
- Restrict public-facing server access to authorized sources where applicable, consistent with the supplied mitigation guidance.
- Review which systems are allowed to initiate outbound web traffic directly, especially servers, ESXi hosts, network devices, and administrative infrastructure.
- Ensure filtering and monitoring policies produce audit-ready evidence showing what web traffic is allowed, blocked, inspected, or logged.
Additional notes and limits
The supplied object identifies web protocols as a command-and-control sub-technique and lists HTTP/S and WebSocket as examples. The many campaign relationships make this strategically important, but they do not prove current activity against any specific organization. Use them to justify control validation, hunting hypotheses, and IR readiness exercises rather than attribution conclusions.
MITRE did not provide official detection text for this object, and the related detection strategy is named but not described in detail here. Local architecture, encryption policy, proxy coverage, endpoint telemetry, and allowed-business-traffic baselines are required to determine actual detection coverage and control effectiveness.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Web Protocols
Adversaries may communicate using application layer protocols associated with web traffic to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server.
Protocols such as HTTP/SCitationCrowdStrike Putter Panda and WebSocketCitationBrazking-Websockets that carry web traffic may be very common in environments. HTTP/S packets have many fields and headers in which data can be concealed. An adversary may abuse these protocols to communicate with systems under their control within a victim network while also mimicking normal, expected traffic.
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.
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.
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.