Detect WEBC2 by identifying web-based command-and-control patterns, including regular HTTP or HTTPS callbacks, odd user-agent values, and requests that do not match normal browser or application use. Review proxy, DNS and endpoint telemetry for beaconing hosts, unexpected script execution and traffic to domains with little prior history.
What WEBC2 detection looks like in practice
WEBC2 usually leaves a behavioural footprint rather than a single signature. Teams should look for repeated browser-like callbacks, especially short interval HTTP or HTTPS requests that do not fit the host’s normal role, script-heavy activity that appears out of sequence, and destinations that suddenly begin receiving traffic from a system with no prior relationship. The goal is to distinguish covert command traffic from ordinary web use.
One useful way to frame the problem is as web traffic that is technically valid but operationally odd. A proxy log may show apparently normal web requests, while endpoint telemetry reveals that a script, macro, scheduled task or other process is generating them. That mismatch between the network view and the process view is often the first clue that the web channel is being used as command-and-control.
Detection becomes much stronger when teams correlate patterns across proxy, DNS and endpoint data. Proxy logs help identify beaconing cadence and unusual header patterns, DNS can expose domains with little history or repeated lookups tied to a single host, and endpoint data can show the parent process, child processes and script execution chain behind the traffic. A single signal is rarely enough; the value comes from joining the transport pattern to the local execution context.
Signals that matter most for web-based command-and-control
Focus first on repeatability and mismatch. Regular callbacks to the same host, odd or inconsistent user-agent strings, and requests that resemble browser traffic but omit normal browsing behaviour are all useful indicators. Also watch for systems that create outbound web traffic despite having no business need to browse externally, since that often marks a tool or implant rather than a user session.
Domain age and reputation can add context, but they should not be treated as proof on their own. A newly seen domain, a domain that only one or two internal hosts ever contact, or a domain that appears only in narrow time windows can be worth investigation because it may support staging, tasking or recovery by an operator. The strongest cases are those where the domain relationship, timing and host behaviour all line up.
Endpoint investigation should look for the execution path that produced the traffic. Unexpected PowerShell, wscript, mshta, browser child processes, or other script interpreters can reveal how the web channel was established. If the telemetry shows a legitimate application making the request, verify whether that application normally talks to that destination and whether the content, interval and sequence match expected behaviour.
How to separate benign web use from WEBC2 activity
Benign traffic usually has a user-driven explanation, a stable application pattern, and a clear relationship between the process and the destination. WEBC2 traffic often lacks one or more of those anchors. It may be periodic rather than event-driven, isolated to one host, sourced from an unusual process tree, or tied to a domain that has no meaningful history inside the environment.
Process context is especially important when the network data alone looks normal. If the same request pattern appears from an endpoint service, script engine or parent process that should not be making external web calls, treat that as a stronger indicator than any single header field or URL path. Detection is most reliable when teams ask not only “what was requested?” but also “what process was allowed to request it?”
At scale, prioritisation matters. Large environments will generate false positives from software updates, SaaS integrations and automated health checks, so teams should baseline known callback patterns and expected agents before chasing every repeat connection. This is where a resource like Malware Guide can help practitioners place web C2 behaviour in the broader malware detection workflow without confusing it with ordinary web telemetry.
Risk and Threat Considerations
WEBC2 is attractive because it blends into common enterprise traffic, which can delay detection and extend dwell time. If defenders only alert on obviously malicious ports or protocols, an implant can hide inside ordinary HTTP or HTTPS and keep receiving tasking even after initial compromise has been noticed.
Failure mechanism: The attacker abuses web protocols, timing regularity and process disguise to make command traffic look like routine browsing or application activity. When proxy, DNS and endpoint logs are not correlated, the beaconing host can remain indistinguishable from legitimate web use.
Impact: The result is sustained remote control, easier staging of follow-on actions, and a larger window for lateral movement, data theft or further payload delivery before defenders recognise the pattern.
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 CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1071.001 — Web Protocols | WEBC2 uses web channels for command traffic, which maps directly to web protocol abuse. |
| Recommendation — Map observed beaconing and web callback patterns to T1071.001 in your hunt and detection logic. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | WEBC2 detection depends on monitoring proxy, DNS and network telemetry for anomalous callbacks. |
| Recommendation — Monitor proxy, DNS and endpoint telemetry for periodic web callbacks and unusual destination patterns. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Correlation of proxy, DNS and endpoint records is central to finding covert web C2 activity. |
| Recommendation — Analyze audit and network logs together to surface beaconing hosts and process-to-destination mismatches. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Detecting web C2 requires continuous network monitoring, alerting, and traffic analysis. |
| Recommendation — Deploy network monitoring to flag repetitive web callbacks, odd user agents and suspicious destinations. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | The answer relies on reviewing telemetry and logs to identify suspicious request patterns. |
| Recommendation — Log request context, user agents and origin data so anomalous web callback patterns are visible. | ||
Practitioner Guidance
What to verify: Confirm whether the destination domain has any legitimate business relationship, whether the user-agent and request cadence match the host role, and whether an unexpected process created the connection. If the traffic is recurring but the endpoint owner cannot explain it quickly, treat it as suspicious until proven otherwise.
Decision rule: If the same web destination is contacted on a fixed interval by a process that should not browse externally, prioritise containment of that endpoint and collection of process, DNS and proxy evidence before spending time on content inspection alone.
Practitioner takeaway: WEBC2 detection is strongest when teams investigate the relationship between process, timing and destination, not just the URL or protocol. A believable web session can still be malicious if the host behaviour and execution chain do not fit the environment.