Detect Web Protocols in Elastic Security
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/S and WebSocket 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.
MITRE ATT&CK
- Tactic
- Command and Control
- Technique
- T1071 Application Layer Protocol
- Sub-technique
- T1071.001 Web Protocols
- Canonical reference
- https://attack.mitre.org/techniques/T1071/001/
Elastic Detection Query
FROM logs-endpoint.network-*, logs-network_traffic.*
| WHERE @timestamp > NOW() - 24h
| WHERE event.type == "connection" AND event.outcome == "success"
| WHERE destination.port IN (80, 443, 8080, 8443)
| WHERE NOT CIDR_MATCH(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8")
| WHERE destination.ip IS NOT NULL AND process.name IS NOT NULL
| STATS
connection_count = COUNT(*),
bytes_sent = SUM(source.bytes),
bytes_received = SUM(destination.bytes),
first_seen = MIN(@timestamp),
last_seen = MAX(@timestamp),
unique_urls = COUNT_DISTINCT(url.full)
BY host.hostname, process.name, destination.ip, destination.port
| EVAL duration_seconds = DATE_DIFF("second", first_seen, last_seen)
| EVAL avg_interval = CASE(connection_count > 1, TO_DOUBLE(duration_seconds) / TO_DOUBLE(connection_count - 1), 0.0)
| EVAL sent_recv_ratio = CASE(bytes_received > 0, TO_DOUBLE(bytes_sent) / TO_DOUBLE(bytes_received), 999.0)
| WHERE connection_count > 15 AND avg_interval > 1 AND avg_interval < 900
| EVAL beacon_confidence = CASE(
avg_interval >= 55 AND avg_interval <= 65, "high",
avg_interval >= 295 AND avg_interval <= 305, "high",
avg_interval >= 895 AND avg_interval <= 905, "high",
connection_count > 100 AND avg_interval < 120, "high",
"medium"
)
| KEEP host.hostname, process.name, destination.ip, destination.port, connection_count, avg_interval, bytes_sent, bytes_received, sent_recv_ratio, beacon_confidence, first_seen, last_seen
| SORT connection_count DESCUses Elasticsearch ES|QL (aggregation query language available in Elastic Stack 8.x) to detect HTTP/HTTPS beaconing from endpoints to public IPs over common web ports. Aggregates outbound network connections per host, process, and destination over 24 hours, computes average inter-connection interval from min/max timestamps, and scores beacon confidence based on known C2 intervals (60s, 300s, 900s). Requires Elastic Endpoint telemetry (logs-endpoint.network-*) or a network traffic integration such as Zeek/Packetbeat (logs-network_traffic.*). Deploy as a threshold-type detection rule in Elastic Security with a scheduled query interval of 1h.
Data Sources
Required Tables
False Positives & Tuning
- Software update agents such as Windows Update, Chrome auto-update, or antivirus definition services making regular HTTP check-in connections to CDN endpoints at fixed intervals will trigger high connection counts and consistent average intervals
- Application performance monitoring agents (Datadog, New Relic, Dynatrace) sending periodic telemetry heartbeats every 60 or 300 seconds to cloud collection endpoints will match the high-confidence beacon interval thresholds
- Video conferencing and collaboration platforms (Zoom, Microsoft Teams, Slack) maintaining persistent HTTP long-poll or WebSocket keep-alive connections with regular renegotiation packets to regional infrastructure will accumulate high connection counts
Other platforms for T1071.001
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1HTTP C2 Beaconing via curl
Expected signal: Sysmon for Linux Event ID 3: Network connection from curl to 127.0.0.1:80, repeated 10 times at 10-second intervals. Proxy logs showing identical HTTP GET requests to /updates/check with Internet Explorer User-Agent.
- Test 2HTTPS C2 with PowerShell WebClient
Expected signal: Sysmon Event ID 1: Process creation for powershell.exe with command line containing Net.WebClient. Sysmon Event ID 3: Network connections to 127.0.0.1:443 at 15-second intervals. PowerShell ScriptBlock Log Event ID 4104 with full script content.
- Test 3WebSocket C2 Simulation
Expected signal: Sysmon for Linux Event ID 3: Network connection from curl to 127.0.0.1:8080. Proxy logs showing HTTP request with 'Upgrade: websocket' header. The connection attempt will be long-lived if a WebSocket server is present.
References (7)
- https://attack.mitre.org/techniques/T1071/001/
- https://arxiv.org/ftp/arxiv/papers/1408/1408.1136.pdf
- http://cdn0.vox-cdn.com/assets/4589853/crowdstrike-intelligence-report-putter-panda.original.pdf
- https://securityintelligence.com/posts/brazking-android-malware-upgraded-targeting-brazilian-banks/
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1071.001/T1071.001.md
- https://github.com/activecm/rita
- https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967/
Unlock Pro Content
Get the full detection package for T1071.001 including response playbook, investigation guide, and atomic red team tests.