FrameworkGuidesModulesRelease NotesAbout

Detecting Cobalt Strike Beacon Activity with Veil

Cobalt Strike is one of the most widely used commercial adversary simulation tools, and its Beacon implant is frequently encountered in both authorized red team exercises and real-world intrusions. Understanding how Beacon operates — and specifically how to detect it — is a critical skill for defensive security teams.

This page examines Beacon from a detection perspective: network indicators, endpoint telemetry, memory forensics, and the hunting techniques that reveal C2 activity. We frame this as a defensive exercise because that is where the value lies — not in operating the tool, but in finding it operating against you.

Why Beacon Detection Matters

Beacon-style implants represent the standard for modern command-and-control (C2) infrastructure. They use techniques like sleep intervals, jitter, malleable profiles, and encrypted channels that make traditional detection approaches (static signatures, simple network indicators) unreliable.

If your SOC cannot detect a Beacon in your environment, you likely cannot detect any sophisticated C2. This makes Beacon detection a useful benchmark for your overall detection maturity.

Network-Level Detection

HTTP/HTTPS Indicators

Beacon typically communicates over HTTP or HTTPS. Default configurations have recognizable patterns, but malleable profiles can customize virtually every aspect of the network traffic. Focus on:

  • JA3/JA3S fingerprints — TLS handshake patterns that can identify Beacon even through encrypted traffic
  • Beacon timing analysis — Regular intervals with consistent jitter are detectable through traffic analysis
  • URI patterns — Default profiles use characteristic URI structures
  • HTTP header anomalies — Custom headers or unusual header combinations

DNS Indicators

DNS-based Beacon communication uses TXT or A records for data exfiltration:

  • High-volume DNS queries to a single domain
  • Unusually long subdomain labels (data encoding)
  • DNS queries that do not match legitimate application behavior

Named Pipe Indicators

Beacon uses named pipes for peer-to-peer communication:

  • Default pipe names have known patterns
  • SMB traffic between workstations (unusual in most environments)
  • Pipe creation events visible through Sysmon Event ID 17/18

Endpoint Telemetry

Process Behavior

  • Process injection — Beacon frequently migrates into legitimate processes; Sysmon Event ID 8 (CreateRemoteThread) captures this
  • Spawning patterns — Default behaviors include spawning rundll32.exe or dllhost.exe
  • Memory-only execution — No file on disk, but process telemetry still captures execution

Memory Forensics

Memory analysis is the most reliable detection method for in-memory implants:

  • Scan for known Beacon shellcode patterns in process memory
  • Look for injected threads in processes that should not have them
  • Identify reflectively loaded DLLs without corresponding file-backed sections

Hunting Techniques

Structured hunting for Beacon activity:

  1. Network traffic pattern analysis — Look for regular callback intervals across all outbound connections
  2. Process genealogy review — Identify processes with suspicious parent-child relationships
  3. Named pipe enumeration — Catalog all named pipes and identify anomalous ones
  4. Service creation review — Check for recently created services with unusual binaries
  5. Scheduled task analysis — Review tasks created around the time of suspected compromise

Lab Exercise: Detection Validation

In your lab environment, test detection of C2 patterns by:

  1. Configuring comprehensive logging (Sysmon, PowerShell, network capture)
  2. Establishing a baseline of normal traffic patterns
  3. Introducing C2-pattern activity
  4. Verifying that your detection stack identifies the key indicators
  5. Tuning detection rules based on findings

This exercise validates whether your organization can detect the specific techniques used by the most common adversary simulation tools.

Related