Overview

Web Protocols (T1071.001) describes adversaries using HTTP, HTTPS, and WebSocket as the transport layer for command-and-control (C2) communication. Rather than inventing custom protocols, attackers embed instructions and exfiltrated data inside legitimate-looking web requests and responses, making their traffic structurally indistinguishable from normal browser or application activity.

Because HTTP and HTTPS are permitted through virtually every corporate firewall and proxy, this technique is one of the most reliable ways for attackers to maintain persistent access while evading network-based controls. Every security team must be able to distinguish malicious C2 web traffic from legitimate business traffic, because failing to do so means an attacker can operate indefinitely inside your environment.

Attacker Perspective

Attackers leverage web protocols specifically because outbound HTTP/HTTPS traffic is almost universally allowed, making C2 communication trivially easy to hide in plain sight.

• Cobalt Strike HTTP/S Beacon: The default Cobalt Strike beacon polls a C2 server over HTTP or HTTPS on a configurable sleep interval (e.g., 60 seconds), sending check-ins via GET /updates HTTP/1.1 with encoded data in the URI or a custom HTTP header, mimicking CDN or analytics traffic through malleable C2 profiles.
• Metasploit Meterpreter over HTTPS: Meterpreter’s reverse_https handler establishes a persistent encrypted session to an attacker-controlled server, with TLS certificates often self-signed or issued to lookalike domains, carrying command output base64-encoded in the response body.
• Sliver C2 HTTP implant: The open-source Sliver framework generates implants that communicate over HTTP/HTTPS using randomized URI paths and jitter-based polling, with operator commands and results chunked into standard-looking web requests that blend with SaaS application traffic.
• WebSocket-based RATs (e.g., BraZking malware): Malware abuses the WebSocket protocol (ws:// or wss://) to maintain a full-duplex, persistent channel to a C2 server, using an initial HTTP Upgrade: websocket handshake that most proxies pass without inspection.

This technique is attractive because it requires no special network access, survives proxy enforcement, and the sheer volume of legitimate HTTP/S traffic provides exceptional cover for blending in.

Detection Strategy

Required Telemetry

• Proxy / Web Gateway Logs: Enable full HTTP/HTTPS inspection logs from your forward proxy (Zscaler, Blue Coat, Squid, Palo Alto URL filtering). Required fields: source IP, destination IP, destination domain/URL, HTTP method, user-agent string, response code, bytes sent, bytes received, request timestamp, and content-type. Without SSL/TLS inspection enabled, HTTPS connections will be opaque — enable TLS inspection for non-exempted categories.
• DNS Query Logs: Enable DNS logging on internal resolvers (Windows DNS debug logging, BIND query log, Infoblox, or a network sensor like Zeek). Required fields: client IP, queried domain, query type, response IP(s), response code, timestamp. On Windows DNS servers, enable debug logging: DNS Manager → Server Properties → Debug Logging → check “Log packets for debugging,” which writes to %SystemRoot%\System32\dns\dns.log.
• Network Flow / Packet Capture (NetFlow/IPFIX/Zeek): Deploy Zeek (formerly Bro) or enable NetFlow on perimeter and core switches. Zeek generates conn.log, http.log, ssl.log, and files.log — all required. NetFlow provides at minimum: src/dst IP, src/dst port, protocol, bytes, packets, duration, and start/end timestamps.
• Endpoint Process and Network Telemetry (Windows): Enable Sysmon with a production config (e.g., SwiftOnSecurity or Olaf Hartong templates). Key Event IDs: Event ID 1 (Process Create — includes full command line and parent process), Event ID 3 (Network Connection — process name, destination IP, destination port), Event ID 7 (Image Loaded), Event ID 22 (DNS Query — process name and queried domain). Enable via Sysmon deployment; no native Windows audit policy generates equivalent process-to-network telemetry.
• Endpoint Process and Network Telemetry (Linux/macOS): For Linux, deploy Auditd with rules: -a always,exit -F arch=b64 -S connect -k outbound_connections to capture outbound socket calls, and -w /proc/net/tcp -p r -k proc_net for network state reads. For macOS, enable EndpointSecurity framework via an EDR agent (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) — native macOS audit (auditd) does not reliably capture outbound connections per-process without an EDR. Both platforms: collect process execution logs with parent PID, full command line, and user context.
• EDR Agent Telemetry: Any commercial EDR (CrowdStrike Falcon, Microsoft Defender for Endpoint, Carbon Black, SentinelOne) provides enriched process-network correlation. Ensure network connection events and DNS telemetry are enabled in the EDR policy — these are often disabled by default to reduce volume.
• Firewall / Next-Generation Firewall Logs: Enable application-aware logging. Required fields: source IP, destination IP, destination port, application ID (if NGFW), action (allow/deny), bytes, and session duration. Palo Alto: ensure App-ID is enabled and traffic logs are forwarded to SIEM.

Key Indicators

• Beaconing Behavior — Proxy or NetFlow logs: Field destination_domain or destination_ip receiving connections from a single host at highly regular intervals (e.g., every 60 seconds ±5 seconds). Use standard deviation on connection intervals: stddev(connection_interval) < 5 seconds over a 1-hour window is a strong beaconing signal.
• Low-and-Slow Data Transfer — Proxy logs: Field bytes_out consistently small (under 500 bytes per request) while bytes_in is also small but non-zero — characteristic of C2 check-in/task polling rather than file downloads or page loads.
• Suspicious User-Agent Strings — Proxy or Zeek http.log: Field user_agent matching known malware patterns: curl/7.* from a Windows host (uncommon for browsers), python-requests/2.* from a non-developer workstation, empty/null user-agent strings, or Cobalt Strike default agents like Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0;) — an outdated IE string is a red flag in modern environments.
• Non-Browser Process Making HTTP/S Connections — Sysmon Event ID 3 or EDR: Field Image (process path) is cmd.exe, powershell.exe, wscript.exe, mshta.exe, regsvr32.exe, rundll32.exe, or any non-browser/non-updater binary making outbound connections to DestinationPort = 80 or 443.
• Newly Registered or Rarely Seen Domains — DNS logs or Proxy logs: Field queried_domain with domain age under 30 days (enrich via WHOIS/VirusTotal API), or domains seen by fewer than 5 internal hosts in the last 30 days (low prevalence). DGA-generated domains will show high entropy: compute entropy(domain_label) > 3.5 on the second-level domain.
• Self-Signed or Mismatched TLS Certificates — Zeek ssl.log or NGFW: Fields cert_subject ≠ server_name (SNI mismatch), cert_issuer matching cert_subject (self-signed), or certificate validity period over 2 years for a non-internal CA. Zeek fields: ssl.log: validation_status = "self signed certificate".
• HTTP POST to Non-Standard URI Patterns — Proxy or Zeek http.log: Field uri matching patterns like /submit.php, /gate.php, /check, /updates, /images/[random].png receiving HTTP POST requests with content_type = application/octet-stream or blank content-type — common in C2 frameworks exfiltrating data disguised as image or binary uploads.
• WebSocket Upgrade Requests — Zeek http.log or proxy logs: Field request_header["Upgrade"] = websocket initiated by a non-browser process, or WebSocket connections to IPs with no associated domain name (bare IP:port connections).
• Parent Process Anomalies — Sysmon Event ID 1 or EDR: ParentImage = explorer.exe spawning powershell.exe with CommandLine containing -WindowStyle Hidden, -EncodedCommand, IEX, Invoke-WebRequest, WebClient, DownloadString, or Start-BitsTransfer — all common patterns for HTTP-based payload staging and C2.

Detection Logic

Rule 1 (Broad — High Sensitivity): Non-Browser Process Initiating Outbound HTTP/S Connection
IF process.name IN ["powershell.exe","cmd.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","regsvr32.exe","certutil.exe","bitsadmin.exe"] AND network.destination_port IN [80, 443, 8080, 8443] AND network.direction = "outbound" AND NOT network.destination_ip IN [internal_ip_ranges] THEN alert

This rule catches the most common pattern of script interpreters and LOLBins being used to initiate C2 HTTP channels. Expect moderate-to-high volume in environments where PowerShell is used for administration — tune aggressively using the guidance below. Most valuable as a pivot point for investigation rather than a high-confidence standalone alert.

Rule 2 (Medium — Beaconing Detection): Regular Interval Outbound HTTP Connections to Same Destination
IF count(network.connection_events) WHERE destination_ip = X AND source_host = Y OVER 60min >= 10 AND stddev(connection_interval_seconds) < 10 AND NOT destination_domain IN [known_good_domains_whitelist] THEN alert

Beaconing is one of the strongest behavioral signals for C2 over HTTP. This rule fires when a host contacts the same external IP on a highly regular schedule — something legitimate applications rarely do without also appearing in your known-good domain list. Expected alert volume is low-to-medium; most false positives come from software updaters and telemetry agents (see Tuning Guidance).

Rule 3 (Medium — Suspicious User-Agent): HTTP Traffic with Anomalous or Known-Bad User-Agent
IF http.user_agent MATCHES ["curl/*","python-requests/*","Go-http-client/*","Wget/*","libwww-perl/*",""] AND http.source_process NOT IN ["curl.exe","python.exe","wget"] AND network.destination_port IN [80,443] AND NOT source_host IN [developer_workstations, build_servers] THEN alert

Malware frequently uses scripting-language HTTP libraries and either forgets to set a browser-like user-agent or uses a hardcoded one that doesn’t match the OS. This is a high-precision rule on non-developer systems. Alert volume should be low if developer and build system exclusions are applied correctly.

Rule 4 (Narrow — High Precision): PowerShell HTTP Download Cradle Detected
IF process.name = "powershell.exe" AND process.command_line MATCHES ["*IEX*","*Invoke-Expression*","*DownloadString*","*WebClient*","*Invoke-WebRequest*","*Start-BitsTransfer*"] AND network.destination_port IN [80,443] AND NOT process.parent_name IN ["sccm.exe","ccmexec.exe","wsus*"] THEN alert HIGH

PowerShell download cradles are a near-universal technique for HTTP-based payload staging and C2 initialization. This rule has very low false positive rates outside of managed software deployment systems and warrants immediate investigation every time it fires. Treat as high-confidence and escalate promptly.

Tuning Guidance

• Software Updaters and Telemetry Agents: Tools like Windows Update (svchost.exe running wuauserv), Chrome/Edge auto-update (GoogleUpdate.exe, MicrosoftEdgeUpdate.exe), and vendor telemetry services make regular, interval-based HTTP connections that will trigger beaconing rules. Baseline these destinations and exclude known update CDN domains and IPs: add destination_domain IN [update.microsoft.com, dl.google.com, edgedl.me.gvt1.com] to exclusion lists.
• SCCM / Endpoint Management Tools: Microsoft SCCM, Tanium, and similar tools spawn powershell.exe and cmd.exe children that make HTTP connections to internal management servers. Exclude by parent process: parent_process IN ["ccmexec.exe","smsagent.exe","taniumclient.exe"] and restrict exclusion to connections toward internal IP ranges only.
• Developer Workstations: Developers legitimately use curl, python-requests, wget, and PowerShell Invoke-WebRequest daily. Create an asset group for developer machines and apply a separate, stricter ruleset focused on destination reputation rather than process behavior: exclude source_host IN [developer_asset_group] for user-agent rules, but still alert on connections to newly registered or low-reputation domains.
• Security and Monitoring Tools: EDR agents, vulnerability scanners (Tenable, Qualys), and SIEM forwarders make frequent outbound HTTP connections. Identify their process names and service accounts and add to a global exclusion: exclude process.name IN ["nessus.exe","cbsensor.exe","falcon-sensor","splunkd"] from network connection rules.
• Cloud Sync and Collaboration Apps: OneDrive (onedrive.exe), Dropbox (dropbox.exe), Slack, Teams, and Zoom all maintain persistent HTTP/WebSocket connections that resemble beaconing. Exclude by destination domain and application process name rather than blanket-excluding the protocol pattern.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Navigate to the raw log source (proxy logs, Sysmon Event ID 3, or EDR telemetry) and confirm the triggering event exists with all expected fields populated. Check for log ingestion delays or parsing errors in your SIEM that may have mangled field values and caused a false parse-based alert.
2. Identify the affected host and user: Use the source IP from the network event to identify the hostname via DHCP logs or your asset inventory, then correlate against authentication logs (Windows Event ID 4624 or EDR user context) to identify the logged-in user at the time of the event. Flag immediately if the account is privileged (domain admin, service account, or has access to sensitive systems).
3. Pull the full process and parent chain: In your EDR or Sysmon (Event ID 1), retrieve the full command line of the process making the connection, its parent process, and the grandparent — trace back at least three generations. Look specifically for cmd.exe or powershell.exe spawned by Office applications (winword.exe, excel.exe), browser processes, or unusual parent/child relationships that indicate process injection or living-off-the-land execution.
4. Examine network connections and transferred data: In proxy logs or Zeek http.log, pull all HTTP transactions for the flagged host in the 24 hours surrounding the alert — review URIs, user-agents, HTTP methods, response codes, and data transfer volumes. Check Zeek files.log or proxy content inspection for any files downloaded, and compute hashes of anything written to disk for VirusTotal lookup.
5. Hunt for lateral movement from this host: Query Windows Security Event ID 4648 (explicit credential use), 4624 (logon), and Sysmon Event ID 3 for outbound SMB (port 445), RDP (port 3389), WinRM (port 5985/5986), or other internal connections initiated from the affected host in the 48 hours following the first C2 indicator. Any successful authentication to additional internal hosts should be treated as confirmed lateral movement.
6. Search for persistence mechanisms: On the affected host (via EDR, Autoruns data, or remote registry query), check for newly created scheduled tasks (Windows Event ID 4698), registry Run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), new services (Event ID 7045), and modified startup folders. On Linux/macOS, check crontab entries (crontab -l for all users), systemd unit files in /etc/systemd/system/, and launchd plist files in /Library/LaunchDaemons/.
7. Make the escalation decision: Escalate to a confirmed incident if any of the following are present: a known malicious hash or domain IOC confirmed via threat intel, evidence of privilege escalation or credential access, lateral movement to additional hosts, or data staged for exfiltration. Treat as benign or low-priority only if the process, destination, and behavior are fully explained by a known legitimate application with documented behavior matching all observed indicators.

Response Playbook

Containment

• Isolate the host — keep it powered on: Use your EDR’s network isolation feature (CrowdStrike: “Network Contain,” Defender for Endpoint: “Isolate Device,” Carbon Black: “Quarantine”) to immediately cut all network connectivity except the EDR management channel. Do not power off or reimage until forensic collection is complete — volatile memory may contain C2 keys, injected shellcode, or credentials.
• Block C2 infrastructure at the perimeter: Add identified C2 IP addresses and domains to your firewall deny list and DNS sinkhole. In Palo Alto: create an address object and block in Security Policy. In Windows DNS: create a DNS Response Policy Zone (RPZ) that returns NXDOMAIN for the malicious domain. Block at both ingress and egress to prevent any other potentially infected hosts from beaconing out.
• Disable the affected user account: In Active Directory, immediately disable the account: Disable-ADAccount -Identity [username]. If the account is a service account, rotate the password immediately and audit all systems where the account has permissions. If using Entra ID (Azure AD), use Revoke-AzureADUserAllRefreshToken to invalidate all active sessions and tokens.
• Kill the malicious process: Via EDR remote response console, terminate the identified C2 process by PID. Confirm termination and check for child processes that may respawn it — if a persistence mechanism is already active, process killing alone is insufficient without also removing the persistence entry.
• Notify firewall and proxy teams: Push updated block lists to all enforcement points simultaneously — perimeter firewall, internal segmentation firewall, web proxy, and email gateway — to prevent the C2 domain from being reached by any host in the environment, not just the confirmed victim.

Eradication

• Remove identified persistence mechanisms: Delete malicious scheduled tasks via schtasks /delete /tn "[task_name]" /f or Group Policy. Remove malicious registry Run keys: Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "[malicious_entry]". For Linux, remove cron entries and systemd unit files, then run systemctl daemon-reload.
• Locate and delete dropped payloads: Use your EDR’s file search capability or Sysmon Event ID 11 (FileCreate) to identify files written by the malicious process. Hash all identified files and search for the same hash across the entire environment using EDR fleet search before deleting — confirm scope before eradicating.
• Reset credentials for all exposed accounts: Force password resets for the affected user and any accounts whose credentials may have been accessed from the compromised host (check browser credential stores, Windows Credential Manager, and memory for credential theft artifacts using Event ID 4663 on LSASS). If a domain admin account was accessed, assume full domain compromise and follow domain-level credential reset procedures.
• Audit and remediate lateral movement targets: For every internal host the compromised system connected to, run a targeted persistence and IOC hunt using EDR fleet search for the same malware hashes, C2 domains in DNS history, and the same malicious process names. Treat any hit as a confirmed secondary infection requiring its own containment cycle.
• Rotate exposed secrets and API keys: If the compromised host had access to cloud credentials, API keys, certificates, or secrets stored in environment variables or config files, revoke and rotate all of them immediately. Check AWS CloudTrail, Azure Activity Logs, or GCP Audit Logs for any API calls made with those credentials during the compromise window.

Recovery

• Verify clean state before reconnecting: Before removing network isolation, run a full EDR scan and confirm zero detections, validate that all identified persistence mechanisms have been removed, and check Autoruns output manually. If confidence in a clean state is less than high — particularly if the host was compromised for more than 24 hours before detection — reimage from a known-good golden image rather than attempting manual remediation.
• Re-enable the user account under controlled conditions: Only re-enable the affected user account after confirming no persistence remains on their primary workstation and any other hosts they authenticated to during the compromise window. Force a password reset at next login and consider temporarily enabling enhanced logging (verbose audit policy) on the account for 72 hours post-reinstatement.
• Conduct 72-hour post-remediation monitoring: Create a targeted watchlist in your SIEM for the previously affected host’s IP, hostname, and user account. Set up alerts for any outbound connections to new external destinations, any new scheduled task creation, and any new process execution from unusual parent processes. Any hit within 72 hours should be treated as reinfection and escalated immediately.
• Document the full incident timeline: Record the initial compromise vector (if identified), the first beacon timestamp, all affected hosts and accounts, all IOCs (IPs, domains, hashes, process names), containment actions taken, and time-to-contain. Submit IOCs to your threat intelligence platform and share with ISACs if appropriate.
• Update detection rules based on new IOCs: Incorporate any new user-agent strings, URI patterns, destination domains, or process behaviors observed during this incident into your detection rules. If the attacker used a malleable C2 profile that bypassed your existing rules, analyze exactly what was different and build a specific detection for it before closing the incident.