Cobalt Strike Detection: How to Find and Evict Beacons Before Ransomware Deploys

A Cobalt Strike beacon is a shellcode payload that runs inside a legitimate process after injection and communicates with a team server over HTTP, HTTPS, DNS, or SMB. The beacon checks in on a configurable sleep interval (often 60 seconds by default, reduced to seconds during active operations) and receives tasks: run commands, inject into other processes, dump credentials, or pivot laterally.

Why default detection fails: The beacon runs inside legitimate processes (rundll32.exe, svchost.exe, explorer.exe, msbuild.exe) rather than as a standalone process. Process-based allow lists see a trusted binary; the malicious shellcode is invisible at the process level. Signature-based AV often misses custom-packed beacons because threat actors apply XOR encoding, custom packers, or reflective DLL injection to evade static signatures.

Malleable C2 profiles: Cobalt Strike's most powerful evasion feature is its Malleable C2 profile system. Operators configure beacons to disguise their HTTP traffic as legitimate services: Amazon CDN requests, Microsoft update traffic, jQuery CDN responses. The HTTP headers, URI patterns, and response bodies are all configurable. A beacon using the amazon.profile looks identical to legitimate AWS traffic at the network layer.

Staging vs. stageless beacons: Staged beacons download the full payload after initial execution (detectable at the network layer during staging). Stageless beacons embed the full payload at delivery and make no staging request — harder to detect at delivery but larger on disk and more detectable in memory after execution.

Default artifacts that operators often forget to change: Despite Malleable C2's flexibility, operators frequently leave default artifacts in place: default named pipe names, default sleep jitter values, default injected process choices, and default SSL certificate details on team servers. These defaults are your best detection surface.

Memory analysis is the highest-confidence Cobalt Strike detection method because beacons must exist in memory to execute, and their structure is consistent regardless of how they were delivered.

YARA rules for in-memory beacon detection: The Cobalt Strike beacon has a consistent internal structure including a configuration block and characteristic byte sequences. Tools like cs-decrypt-metadata and YARA rules from the community can scan process memory for these patterns. Run YARA scans against all process memory on endpoints using:

• BeaconHunter (open source): scans live processes for Cobalt Strike configuration blocks
• PE-sieve: detects injected shellcode and hollowed processes across all running processes
• Moneta: identifies suspicious executable regions in process memory including reflectively loaded DLLs

Suspicious memory region characteristics: Cobalt Strike injects into processes by allocating RWX (read-write-execute) memory regions — a combination that legitimate processes rarely need. Hunt for:

• Memory regions with RWX permissions that are not backed by a file on disk (unbacked executable memory)
• Private memory regions containing PE headers outside the process's loaded module list
• Memory regions that pass entropy analysis as high-entropy (packed/encrypted shellcode)

PowerShell command to identify unbacked executable memory (Windows): Use Get-InjectedThread or Invoke-PSInjectDetector from the PSHunt module to enumerate threads with start addresses pointing to non-module-backed memory. Any thread starting in a heap or anonymous memory allocation is suspicious.

Network detection catches beacons that memory scanning misses, particularly stageless beacons with custom Malleable C2 profiles. The key is knowing what to look for at the traffic level rather than the signature level.

Default HTTP beacon signatures (no Malleable C2): Default Cobalt Strike HTTP beacons make requests with these characteristics:

• URI patterns: /ca, /dpixel, //__utm.gif, /pixel.gif, /g.pixel, /dot.gif, /updates.rss, /fwlink
• User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; FunWebProducts) — an outdated IE9 string rarely seen in legitimate traffic
• Response body: base64-encoded data wrapped in a consistent structure
• Consistent sleep intervals between connections (beaconing rhythm)

Detecting Malleable C2 profiles by behavioral analysis: Even with Malleable C2, beacons have behavioral tells:

• Beacon rhythm: connections occur at regular intervals with low variance (unlike human browsing). A host connecting to a single IP every 60 seconds ± 10 seconds for hours is a beacon.
• Short-lived HTTPS sessions: beacons check in, receive tasks, and disconnect. Unlike streaming or API traffic, sessions are short and periodic.
• Low data volume per session: a sleeping beacon sends and receives hundreds of bytes per check-in, not kilobytes.
• JA3/JA3S fingerprinting: Cobalt Strike's default TLS implementation has characteristic JA3 hashes. Tools like Zeek can log JA3 fingerprints; search for known Cobalt Strike JA3 values in your proxy and firewall logs.

DNS beacon detection: Cobalt Strike DNS beacons use DNS A record queries for subdomains of the team server domain. Detection signature: a single internal host making high-frequency DNS queries for sequential subdomains (aaa.teamserver.com, aab.teamserver.com) at regular intervals. Cobalt Strike DNS beacons also use TXT record queries for data exfiltration. Baseline DNS query frequency per host and alert on hosts exceeding 3x the baseline.

Named pipes are Cobalt Strike's primary inter-process communication mechanism for lateral movement and process injection. They are one of the most reliable detection surfaces because default pipe names are consistent and rarely appear in legitimate environments.

Default Cobalt Strike named pipe patterns: Cobalt Strike creates named pipes with these patterns by default:

• \\\\.\\\\ MSSE-[0-9]{4}-server
• \\\\.\\\\ msagent_[0-9a-f]{2}
• \\\\.\\\\ DserNamePipe[0-9]{10}
• \\\\.\\\\ postex_[0-9a-f]{4}
• \\\\.\\\\ status_[0-9a-f]{2}
• \\\\.\\\\ mojo\\.\\d+\\.\\d+\\.\\d+

Windows Event ID 18 (pipe connected) and 17 (pipe created) in Microsoft-Windows-Kernel-PnP/Operational log surface these pipe names. Sysmon Event ID 17 and 18 provide named pipe telemetry on endpoints with Sysmon deployed.

Process injection indicators: Cobalt Strike's default injection technique uses VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread — a classic sequence that generates:

• Sysmon Event ID 8 (CreateRemoteThread) where the source process is not a known injector (debugger, AV, etc.)
• A destination process (e.g., notepad.exe) suddenly making network connections it has never made before
• The destination process loading network DLLs (ws2_32.dll, wininet.dll) that the process type does not typically load

Sigma rule for Cobalt Strike named pipe creation:

title: Cobalt Strike Default Named Pipe
status: stable
logsource:
  product: windows
  category: pipe_created
detection:
  selection:
    PipeName|re: '(MSSE-[0-9]{4}-server|msagent_[0-9a-f]{2}|postex_[0-9a-f]{4}|status_[0-9a-f]{2}|DserNamePipe[0-9]{10})'
  condition: selection
falsepositives:
  - Legitimate red team exercises
level: high

Microsoft Sentinel KQL — Cobalt Strike beacon rhythm detection:

CommonSecurityLog
| where DeviceVendor != "Microsoft"
| where RequestURL has_any ("/ca", "/dpixel", "/__utm.gif",
    "/pixel.gif", "/g.pixel", "/dot.gif", "/updates.rss", "/fwlink")
| summarize
    RequestCount = count(),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by SourceIP, DestinationIP, RequestURL
| where RequestCount > 5
| where datetime_diff('minute', LastSeen, FirstSeen) > 10

Sentinel KQL — Unbacked executable memory via Defender for Endpoint:

DeviceEvents
| where ActionType == "CreateRemoteThreadApiCall"
| where InitiatingProcessFileName !in~ (
    "MsMpEng.exe", "svchost.exe", "csrss.exe", "wininit.exe"
)
| project Timestamp, DeviceName, InitiatingProcessFileName,
    TargetProcessId, InitiatingProcessCommandLine
| order by Timestamp desc

Splunk SPL — DNS beaconing detection:

index=dns sourcetype=stream:dns
| bucket _time span=5m
| stats count as query_count, dc(query) as unique_queries
    by _time, src_ip, dest_ip
| where query_count > 50 AND unique_queries < 5
| eval beacon_score = query_count / unique_queries
| where beacon_score > 20
| sort -beacon_score

JA3 hash hunt (Zeek/Corelight): Known Cobalt Strike default JA3 hashes include a0e9f5d64349fb13191bc781f81f42e1 and 72a589da586844d7f0818ce684948eea. Query your Zeek ssl.log or Corelight data:

ssl | where ja3 in ("a0e9f5d64349fb13191bc781f81f42e1", "72a589da586844d7f0818ce684948eea")

Finding a Cobalt Strike beacon during an active intrusion requires careful containment sequencing. The threat actor is monitoring their team server — abrupt network disconnection or process termination signals detection and may trigger accelerated ransomware deployment.

Recommended containment sequence:

1. Passive observation first (15-30 minutes): Before taking action, observe the beacon's behavior. Identify other compromised hosts by watching for lateral movement from the beaconed endpoint. Map the full blast radius before containment.
2. Isolate at the network layer quietly: Use firewall rules or NAC quarantine to block the beacon's C2 IP/domain while keeping internal network access for lateral movement visibility. Blocking C2 prevents the operator from issuing new commands without alerting them that the endpoint is offline.
3. Capture memory before killing the process: Run a full memory dump of the injected process before termination. The memory image preserves the decrypted beacon configuration, team server IP, sleep interval, and any staged payloads — critical evidence for scoping the full intrusion.
4. Identify persistence mechanisms: Cobalt Strike persistence is typically scheduled tasks, registry Run keys, WMI subscriptions, or service installations. Enumerate all persistence before removing the beacon or the operator redeploys immediately.
5. Block team server infrastructure at perimeter: Add the C2 IP and domain to firewall deny rules and DNS sinkholes across all egress points, not just the compromised endpoint.
6. Rotate credentials proactively: Assume the operator has run Mimikatz or similar. Force password reset for all accounts that authenticated on or from the compromised host in the past 30 days.