Cobalt Strike beacons communicate with command-and-control servers over HTTP, HTTPS, or DNS using configurable profiles that disguise traffic as legitimate web activity. The default profile is well-known and trivially detected. Customized malleable C2 profiles are harder to catch but still produce timing signatures, TLS fingerprints, and behavioral patterns that network monitoring tools identify.
Analysis Briefing
- Topic: Cobalt Strike C2 traffic detection in network monitoring
- Analyst: Mike D (@MrComputerScience)
- Context: A technical briefing developed with Claude Sonnet 4.6
- Source: Pithy Security
- Key Question: If Cobalt Strike traffic is disguised as normal HTTPS, how do defenders actually find it?
Why Malleable C2 Profiles Don’t Hide Cobalt Strike Completely
Cobalt Strike’s malleable C2 profiles let operators customize beacon traffic to mimic legitimate services: Amazon, Microsoft, Google APIs, or CDN traffic. Headers, URIs, and user agents are configurable. The payload is encrypted. On the surface, the traffic looks like any other HTTPS request.
The timing signature is harder to fake. Cobalt Strike beacons check in with their C2 server at a configured interval, with configurable jitter. Default sleep time is 60 seconds with no jitter. Even customized profiles produce a consistent heartbeat pattern that statistical analysis of connection logs identifies as periodic rather than organic.
JA3 TLS fingerprinting identifies the TLS client hello characteristics of Cobalt Strike’s default HTTP client. Many beacon configurations produce a distinctive JA3 hash regardless of the HTTP content profile. Zeek and Suricata both support JA3 logging. A JA3 hash matching known Cobalt Strike signatures in your proxy logs is a high-confidence indicator.
The DNS Beacon That Hides C2 Traffic in Name Lookups
Cobalt Strike’s DNS beacon exfiltrates data and receives commands through DNS queries rather than HTTP. The beacon encodes data in subdomain queries to an attacker-controlled authoritative nameserver. From the network perimeter, the traffic looks like ordinary DNS resolution.
Detection relies on DNS anomaly analysis rather than content inspection. Beaconing DNS traffic produces high query rates to a single domain, unusually long subdomain strings, and consistent timing intervals. Queries with subdomains containing base64 or hex-encoded data are a specific indicator that SIEM rules can catch.
Blocking DNS-over-HTTPS to non-approved resolvers prevents DNS beacon traffic from bypassing corporate DNS monitoring. Centralizing DNS through a monitored resolver ensures the query logs exist for analysis.
When Suricata Rules Actually Catch Beacon Traffic
Emerging Threats and the Cobalt Strike detection rulesets for Suricata include signatures targeting known default profile URIs, HTTP headers, and response patterns. These rules catch unmodified or minimally modified Cobalt Strike deployments reliably.
Red team operators running custom profiles evade signature-based rules. Behavioral detection fills the gap. Connections to recently-registered domains, domains with low Alexa/Majestic rank, or domains with mismatched PTR records combined with periodic timing patterns catch custom profile beacons that signature rules miss.
Correlating network indicators with endpoint telemetry, specifically the parent process of the network-connecting process, remains the highest-fidelity detection approach for mature operators.
What This Means For You
- Enable JA3 fingerprint logging in your proxy and firewall, because Cobalt Strike’s default TLS client hello produces a known JA3 hash that network monitoring tools can match without content inspection.
- Deploy DNS anomaly detection rules in your SIEM targeting high-frequency queries to single domains with long encoded subdomains, because DNS beaconing evades HTTP-focused detection entirely.
- Download and run the Cobalt Strike detection Suricata rules from Emerging Threats against your existing PCAP captures, because unmodified beacon traffic is trivially detectable and many real deployments use default or near-default profiles.
- Correlate periodic outbound connections with process parentage on endpoints, because a browser process making regular 60-second HTTP requests to a CDN is suspicious in ways that the CDN traffic alone is not.
Enjoyed this deep dive? Join my inner circle:
- Pithy Security → Stay ahead of cybersecurity threats.