detect CobaltStrike Beacon in memory

Hunt Hypothesis

This hypothesis posits that adversaries are deploying Cobalt Strike beacons into volatile memory to establish persistent command-and-control channels while evading traditional disk-based detection mechanisms. Proactive hunting for this behavior within Azure Sentinel is critical because early identification of these in-memory artifacts allows the SOC team to isolate compromised endpoints before lateral movement or data exfiltration occurs, despite the rule’s initial low severity classification.

YARA Rule

rule CobaltStrike {
          meta:
            description = "detect CobaltStrike Beacon in memory"
            author = "JPCERT/CC Incident Response Group"
            rule_usage = "memory scan"
            reference = "https://blogs.jpcert.or.jp/en/2018/08/volatility-plugin-for-detecting-cobalt-strike-beacon.html"
            hash1 = "154db8746a9d0244146648006cc94f120390587e02677b97f044c25870d512c3"
            hash2 = "f9b93c92ed50743cd004532ab379e3135197b6fb5341322975f4d7a98a0fcde7"

          strings:
            $v1 = { 73 70 72 6E 67 00 }
            $v2 = { 69 69 69 69 69 69 69 69 }

          condition: all of them
}

Deployment Notes

This YARA rule can be deployed in the following contexts:

• Microsoft Defender for Endpoint — Custom indicators / advanced hunting
• Email Gateway — Attachment scanning
• File Share Monitoring — Periodic scanning of shared drives
• YARA CLI — Manual threat hunting on endpoints

This rule contains 2 string patterns in its detection logic.

References

• https://blogs.jpcert.or.jp/en/2018/08/volatility-plugin-for-detecting-cobalt-strike-beacon.html
• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the detect CobaltStrike Beacon in memory rule, along with suggested filters or exclusions:

• Software Development & QA Testing Environments

  • Scenario: Developers and QA engineers frequently run Cobalt Strike (CS) locally to simulate attack chains, test beacon configurations, or validate network segmentation. These legitimate testing activities often involve spawning beacon.exe processes that mimic the memory signatures of a real-world compromise.
  • Suggested Filter/Exclusion: Exclude hosts belonging to specific Active Directory Organizational Units (OUs) such as OU=Dev-Workstations or OU=QA-Labs. Alternatively, filter by process parentage where the parent process is Visual Studio, Jenkins Agent, or a known CI/CD runner.

• Scheduled Vulnerability Scanning and Patch Management

  • Scenario: Enterprise vulnerability scanners (e.g., Tenable Nessus, Qualys) or patch management tools (e.g., SCCM/MECM, Ivanti) may utilize Cobalt Strike beacons as temporary agents to perform deep memory analysis or deploy custom scripts during scheduled maintenance windows. This results in legitimate beacon processes running on managed endpoints.
  • Suggested Filter/Exclusion: Create an exclusion based on the process command line arguments containing specific flags (e.g., -scan, -deploy) and restrict the alert trigger to specific time windows (e.g., 02:00–06:00 local time). Additionally, whitelist the specific Service Account used by these tools (e.g., svc-tenable-scanner).

• IT Administration and Remote Support Sessions

  • Scenario: Help desk technicians or system administrators use Cobalt Strike beacons as a lightweight remote access tool to troubleshoot difficult endpoints without installing heavy RDP agents. An admin logging into a server via