Attackers use web protocols such as HTTP or HTTPS to blend malicious traffic with normal browsing and to reach external command and control infrastructure. They may host payloads, exfiltrate data, or stage additional tools through standard web requests. Defenders should inspect unusual destinations, request patterns, user agents, and encrypted traffic metadata.
How web protocols help attackers hide in plain sight
HTTP and HTTPS are attractive to attackers because they sit inside traffic that organisations already expect, allow outbound communication through ordinary network paths, and can carry many different payload types without looking unusual at first glance. That makes the protocol itself part of the abuse path, not just the transport. Standard-looking requests can deliver commands, collect results, or relay data to external infrastructure.
Attackers also use web protocols to inherit normal browser behaviour, such as familiar user agents, cookies, redirects, and certificate-based encryption. Those features can reduce the visibility of malicious activity unless defenders inspect destination reputation, request structure, session patterns, and the metadata that remains observable even when content is encrypted.
When that abuse is used for command and control, the protocol choice becomes a detection problem as much as a transport problem. NHIMG’s Command and Control (C2) Guide is useful here because it shows how beaconing, protocol tunnelling, egress filtering, and web service C2 overlap in real attack chains.
What attackers actually do over HTTP and HTTPS
In practice, attackers use web protocols for several distinct purposes. They may retrieve payloads from a remote server, send stolen data back out, fetch second-stage tooling, or issue tasking to compromised hosts. Because those actions are wrapped in common request methods and response flows, the traffic can blend with ordinary browsing, software updates, API calls, and SaaS communications.
The same mechanism can support both initial access and post-compromise activity. A malicious download over HTTPS may look like a routine file fetch, while later outbound requests can carry encoded commands, exfiltrated archives, or polling traffic that keeps a foothold in touch with its controller. That is why protocol abuse is often less about a single suspicious packet and more about the sequence, timing, and destination profile of the full exchange.
For defenders, the key clue is often not the use of HTTP or HTTPS itself, but whether the pattern fits the host’s normal role. A server, workstation, or automation workload that suddenly makes rare outbound web connections, uses unusual paths or parameters, or talks to destinations with no business context deserves closer inspection.
What defenders should look for in web-protocol abuse
Detection works best when network, endpoint, and identity context are combined. Unusual destinations, uncommon request rates, non-browser user agents, long or repetitive URI paths, odd header combinations, and encrypted sessions with weak reputation are all useful signals. Traffic that appears normal at the protocol layer may still stand out when compared against the asset’s baseline and the application’s expected communication pattern.
Encrypted traffic does not remove visibility, it shifts it. Even where payload content is hidden, defenders can still analyse server names, certificate characteristics, connection frequency, packet size patterns, response timing, and whether the endpoint is speaking to infrastructure that has no legitimate business purpose. IANA registries can help validate protocol and port expectations when you are separating normal web use from something more suspicious.
At response time, web protocol abuse should be treated as both a network issue and a compromise indicator. If an endpoint is using HTTP or HTTPS to reach unapproved infrastructure, investigators should assume the traffic may be part of staging, tasking, or exfiltration until the process, user, and destination are explained.
Risk and Threat Considerations
Web protocols are high-value abuse channels because defenders usually permit them, proxy them, and monitor them less aggressively than obviously suspicious protocols. That creates a persistent blind spot, especially when malicious traffic is embedded in encrypted sessions or looks like normal application browsing.
Failure mechanism: Attackers exploit trust in standard web traffic by using ordinary HTTP or HTTPS exchanges to blend command, payload delivery, and data theft into allowed outbound communication. That hides malicious activity behind a protocol that is broadly necessary for business operations.
Impact: Organisations can miss early-stage compromise, lose data through outbound requests, and allow compromised hosts to maintain reliable contact with external infrastructure for longer than expected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1071.001 — Application Layer Protocol: Web Protocols | Covers attacker use of HTTP/HTTPS for command, control and data transfer. |
| T1105 — Ingress Tool Transfer | Applies when attackers use web requests to retrieve payloads or second-stage tools. | |
| Recommendation — Map web-protocol traffic to T1071.001 and hunt for beaconing, staging and exfiltration patterns. Correlate inbound web fetches with tool transfer events and isolate unexpected download paths. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Web-protocol abuse is often found by analysing logs, metadata and anomalous session patterns. |
| Recommendation — Review proxy, DNS and endpoint logs for unusual web destinations and request patterns. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Effective detection depends on retaining and analysing network and endpoint evidence. |
| Recommendation — Centralise and analyse logs needed to spot abnormal HTTP and HTTPS activity. | ||
Practitioner Guidance
What to prioritise: Start with destinations and patterns, not just payload inspection. If a host is reaching unfamiliar domains, using atypical user agents, or making repetitive web calls that do not match its role, treat that as a higher-priority investigation than a single isolated alert.
What to verify: Confirm whether the traffic is expected for the asset, whether the process generating it is legitimate, and whether the session pattern matches the application’s normal behaviour. If HTTPS hides the content, use metadata, proxy logs, DNS history, and endpoint telemetry to rebuild the activity chain.
Practitioner takeaway: The practical defence is to baseline ordinary web use so that protocol-normal traffic still becomes suspicious when the destination, rhythm, or surrounding host behaviour stops making business sense.