Web Protocols

HTTP and HTTPS are the most common protocols on any network, carrying the overwhelming majority of ordinary web browsing and application traffic. This makes them an attractive channel for command and control communication too, since malware traffic riding over the same protocol as everything else has an enormous amount of legitimate activity to hide inside.

Rather than inventing a custom protocol that stands out immediately, an attacker's malware makes what looks like an ordinary web request, carrying its actual instructions and responses inside normal-looking HTTP fields.

Once installed, the malware periodically reaches out to its command and control server using standard HTTP or HTTPS requests, checking in for new instructions and reporting back results. A single one of these requests is often indistinguishable from a real user's browser making an ordinary web request, especially over HTTPS where the actual content is encrypted.

What gives this away is not any one request but the pattern across many of them. Malware check-ins tend to repeat on a regular interval, since the malware is following code rather than the irregular rhythm of an actual person browsing, and the requests are often more uniform in shape (method, path structure, user agent) than genuine human traffic.

Data source: web proxy access logs, one record per request with timestamp, destination hostname, URI path, request duration, response status and the proxy's own action

{
  "url": {
    "domain": "example-c2.example"
  },
  "host": {
    "name": "proxy01"
  },
  "http": {
    "request": {
      "method": "GET"
    }
  },
  "event": {
    "action": "tcp_refresh_modified"
  },
  "source": {
    "ip": "10.0.0.101"
  }
}

Prebuilt Elastic rule: Statistical Model Detected C2 Beaconing Activity (requires the Network Beaconing Identification integration)

Group outbound connections by source and destination, then look at the time between successive connections rather than any single connection's content. A tight, regular interval, especially combined with a static or near-static request shape, is the tell; genuine human browsing produces bursty, irregular timing.

A failed connection attempt in this pattern is still real evidence, and often the earliest available signal, since a C2 channel that has not yet succeeded still means the host is compromised right now. Do not wait for a successful beacon to treat repeated, regular failed attempts as worth investigating.

On this range, group proxy requests by source.ip and url.domain and measure the interval between successive requests; low variance in that interval, especially paired with a static request method and path, is the pattern. A blocked attempt (event.action: "tcp_denied") on a regular interval is still a real, often earlier signal than a successful one, since the host is already compromised and beaconing whether or not any individual attempt gets through.

Plenty of legitimate software checks in on a fixed schedule: monitoring agents, update checkers, license validation, health checks, and telemetry SDKs all produce genuinely periodic HTTP traffic as their normal, intended behavior.

The distinguishing signal is whether the source process and destination are an expected, known pairing for this host's role. A monitoring agent checking its own management server on a fixed interval is routine; the same interval-and-shape pattern from an unexpected process, or toward a destination with no obvious legitimate purpose for that host, is a different story.

• MITRE ATT&CK: T1071.001 Application Layer Protocol: Web Protocols
• Elastic Security: Statistical Model Detected C2 Beaconing Activity

1 scenario in this catalog covers T1071.001. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →