Cobalt Strike Incident Response Guide

Incident Triage Steps

Within the first 30 minutes, prioritize speed to understand the intrusion’s scope and prevent further damage. Cobalt Strike is a post-exploitation framework often deployed after initial access, so focus on identifying the beaconing activity and potential lateral movement.

1. Confirm and Isolate Initial Alert: If your EDR solution, SIEM platform, or network IDS alerted on a suspicious process (e.g., rundll32.exe with unusual arguments, powershell.exe making long-lived connections), immediately isolate the host from the network if possible. Do not power it off yet.

2. Scope Assessment - Identify Beacons: Cobalt Strike beacons call back to Command and Control (C2) servers. Query your network logs and proxy/ firewall data for:

   • HTTP/HTTPS Beacons: Look for consistent, periodic HTTP GET/POST requests to unknown domains or IPs. Beacons often use common user-agent strings but with unusual timing (e.g., every 60 seconds) or to non-business related domains.
   • DNS Beacons: Check DNS logs for repeated queries for subdomains of a common domain (e.g., a.target.com, b.target.com) which is a common DNS tunneling tactic.
   • SMB Beacons: Search for anomalous IPC$ or ADMIN$ share connections from workstations to other internal systems, which may indicate lateral movement via named pipes.

3. Identify Affected Systems: Use your EDR console or execute a centralized query across all endpoints to find processes with the following suspicious characteristics associated with Cobalt Strike:

   • Processes spawning from rundll32.exe, regsvr32.exe, or msiexec.exe with network connections.
   • powershell.exe processes with encoded command-line arguments containing large blocks of base64.
   • Examine artifacts in memory: use a trusted memory analysis tool to scan for the reflective DLL injection signature common to Cobalt Strike payloads.

4. Determine Data Exfiltration: Check for signs of staging and theft. Cobalt Strike operators often use built-in commands like upload, download, screenshot, and keylogger.

   • Review outbound data transfer volumes from suspected hosts, especially large, sustained transfers to external IPs.
   • Check for the creation of archive files (ZIP, RAR) in unusual temporary directories (e.g., C:\Windows\Temp\, C:\Users\Public\) shortly before outbound connections.
   • Search for the use of living-off-the-land tools like robocopy or 7za.exe that may have been used to package data.

Evidence Collection

Before any remediation, collect forensic evidence to understand the attack chain and for potential legal proceedings.

1. Volatile Memory: On critical, confirmed compromised hosts, take a full memory dump using a trusted forensic tool. Cobalt Strike payloads often reside only in memory (fileless execution), making RAM capture essential.

2. Process and Network Information: From isolated hosts, collect:

   • A full process listing with command-line arguments, parent process IDs, and loaded DLLs (e.g., via tasklist /v or pslist).
   • Current network connections and listening ports (e.g., via netstat -anob).
   • A timeline of recent process creation from the Windows Event Log (Event ID 4688) or via EDR telemetry.

3. Cobalt Strike-Specific Artifacts:

   • Malleable C2 Profile Artifacts: Check the Windows registry for keys related to the initial persistence mechanism (common locations include HKCU\Software\Microsoft\Windows\CurrentVersion\Run and HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run). Also, examine scheduled tasks for jobs with random or obfuscated names.
   • Beacon Artifacts: Search the filesystem for potential stage-2 payloads. Look for:
     • Files in %APPDATA%, %TEMP%, or C:\ProgramData with random alphanumeric names and no file extension.
     • DLL files in C:\Windows\System32 or C:\Windows\SysWOW64 with recent timestamps and low prevalence.
     • Examine the C:\Windows\Tasks folder for job files (*.job) that may be used for persistence.
   • Logs: Export relevant Windows Event Logs (Security, System, PowerShell Operational) from the time of the initial alert backwards for at least 30 days. Specifically look for log clearing (Event ID 1102) or suspicious PowerShell execution (Event ID 4104).

4. Network Evidence: Preserve full packet captures (PCAPs) from border firewalls, internal network sensors, or the host’s own network interface if possible, focusing on traffic to and from the identified C2 IPs/domains.

Containment Procedures

Contain the threat to prevent further beacon communication and lateral movement.

1. Network Segmentation:

   • Immediately block all identified C2 server IP addresses and domains at the network firewall, web proxy, and DNS server levels.
   • Isolate confirmed compromised hosts by moving them to a quarantined VLAN with no access to production systems or the internet.
   • If the infection is widespread, consider segmenting entire network blocks to contain lateral movement, paying special attention to SMB (ports 445/139) and RDP (port 3389) traffic.

2. Credential Security: Assume credentials have been harvested via Cobalt Strike’s hashdump or mimikatz modules.

   • Force password resets for all user and service accounts that were active on compromised systems. Prioritize domain administrator and other high-privilege accounts.
   • Immediately rotate Kerberos Ticket Granting Ticket (TGT) secrets (KRBTGT account password) twice if there is any suspicion of Golden Ticket creation.
   • Review and revoke any Kerberos tickets (using the klist purge command) and monitor for anomalous ticket requests.

3. C2 Communication Blocking:

   • Update your intrusion prevention system (IPS) and endpoint firewall rules to block traffic to the fingerprint of the Cobalt Strike team server, such as the default SSL certificate or specific JA3/S signatures if known.
   • Implement sinkholing for identified C2 domains at the DNS level where possible, to track other potentially infected hosts attempting to call home.

Eradication and Recovery

Completely remove the threat and restore systems to a trusted state.

1. Complete Removal: Follow the detailed, step-by-step procedures in the Cobalt Strike Removal Guide for each affected system. This includes:

   • Terminating malicious processes and deleting associated files.
   • Removing persistence mechanisms from the registry, scheduled tasks, and service configurations.
   • Clearing any malicious WMI event subscriptions or COM hijacks.

2. Restoration: For critically compromised systems (e.g., domain controllers, file servers), the most secure method is to rebuild from scratch using trusted installation media.

   • For other systems, restore from known-clean backups that predate the earliest evidence of compromise. Ensure backups are not also infected before restoration.
   • Before reconnecting to the network, fully patch the operating system and all applications to close the vulnerability used for initial access.

3. Verification: Before returning a system to production:

   • Re-scan it with updated antivirus and endpoint detection tools.
   • Validate that no unusual processes, services, or scheduled tasks remain.
   • Confirm that no unexpected outbound network connections are present.
   • Use a memory analysis tool to check for any residual malicious code in RAM.

Lessons Learned Checklist

After containment and eradication, conduct a formal review to improve defenses.

• Initial Access Vector: How did Cobalt Strike get in?
  • Was it via a phishing email with a malicious document? A vulnerable public-facing application (e.g., VPN gateway, web server)? An exploited unpatched system?
• Control Failures: What security controls failed or were absent?
  • Email Filtering: Did it miss the malicious attachment/link?
  • Endpoint Protection: Why did the initial dropper execute? Were next-gen AV or EDR features disabled or not alerting?
  • Patch Management: Was the exploited vulnerability already patched by the vendor but not applied?
  • Network Segmentation: Was lateral movement too easy? Were critical assets on the same flat network segment?
• Detection Gaps: Where were the delays in detection?
  • Were Cobalt Strike’s network patterns (beaconing) not baselined or alerted on in your SIEM?
  • Did your EDR not flag the specific LOLBIN (Living-Off-The-Land Binary) abuse or reflective DLL injection?
  • Review the Cobalt Strike Detection Guide and implement any missing detection rules.
• Improvement Plan: Based on the above:
  • Update and test incident response playbooks.
  • Implement stricter application whitelisting or script blocking policies.
  • Enhance network monitoring for beacon-like activity and anomalous internal SMB/RDP connections.
  • Mandate multi-factor authentication (MFA), especially for administrative access, to mitigate credential theft impact.
  • Schedule purple team exercises to test defenses against Cobalt Strike tradecraft.

For more information on this threat, refer to the Cobalt Strike Overview.