Free Community Edition

Command-and-control Malware Traffic Playbook

Command-and-Control Malware Response Playbook


Malicious actors operate command-and-control (C&C/C2) servers to interact with their victims’ computers. These C2 servers are intended to instruct the compromised PCs to do undesired things, such as stealing the user’s passwords, encrypting the files for ransom or attacking other computers on the network.

One of the major threats today, ransomware (Cryptolocker, Locky, Petya), also relies on C2 services for generating and storing the file encryption/decryption keys. Similarly, banking Trojans (Zeus, Dridex, Shifu) also use remote servers to collect personal and financial data from their victims.

For keeping the communication between the compromised assets and the C2 server under the radar, a covert channel needs to be established. Although different protocols can be used (e.g. IRC, DNS, ICMP), the most common one is HTTP(S). Web-based C2 channels, disguised as a browsing activity, can nicely blend into the general HTTP traffic on any infrastructure.

Because the mere presence of a covert channel is a tell-tale sign of a compromise, it makes C2 traffic an ideal candidate for identifying any affected PC. This article gives an overview of the C2 traffic identification techniques first, then discusses the common remediation strategies powered by playbooks.

Identifying C2 Traffic

Luckily, the covert channel between the C2 server and the compromised device leaves traces all over the infrastructure. Therefore, we can analyse multiple sources of information for discovering C2 traffic patterns, such as:

  • HTTP Proxy logs
  • DNS query logs
  • Firewall logs
  • Netflow logs
  • Endpoint telemetry data
  • Indexed full packet capture

Also, the standard signature-based network IDS/IPS can also help us with the finding suspicious connections.

To pinpoint compromised devices on the infrastructure, we need to correlate the sea of data with known indicators of C2 activity. These indicators can originate from:

  • Threat Intelligence feeds
  • Data from the internal information sharing platform (for instance Soltra, MISP)
  • Static and dynamic analysis of the malware
  • Other public data sources (e.g. blogs or tweets of malware analysts)
  • Your national CERT
  • Industry-specific information sharing forums, like FS-ISAC or E-ISAC

Suspicious traffic could also be singled out by:

  • Hunting activities
  • IT staff and end-users noticing suspicious behaviour

Also, third-parties can also notify us of the covert channels in extreme cases:

  • Internet Service Provider
  • Botnet sinkholes

Your C2 Playbook

Once a C2 activity is spotted on your network, the relevant playbook should roll into action. Bear in mind, however, that covert channels can exist for two good reasons: it either belongs to a commodity malware, or you have an adversary (i.e. hacker) on your network. Therefore, two separate playbooks should be written for managing the two different scenarios.

Your playbook for managing commodity malware should focus on the rapid eradication of the threat. Quick action minimises the risk of your data being encrypted on the network shares by ransomware, or passwords stolen from the users by information stealing malware. Therefore, the primary goal of the playbook is taking the infected PCs offline as soon as possible – one by one – for wiping. Refer to our playbook from earlier on handling ransomware infections.

On the other hand, a different approach is appropriate if a human is moving around on the network. If the compromised computers were taken offline one by one, the malicious actor might fight back by changing its Tactics, Techniques, and Procedures (TTPs). This could prevent us from eradicating the threat, and turn the remediation efforts into a whack-a-mole game. Therefore, assets must be disconnected at the very same time to get rid of the attacker.

Both playbooks should cover additional activities, however. First of all, we must investigate how “patient zero” was compromised in the first place. Information on the initial attack vector could help us preventing further infections by blocking the related malicious URLs, IPs or emails on the perimeter. Secondly, incident handlers should be pivoting on the initial indicators of the C2 traffic to find other compromised devices across the infrastructure.

Playbook Example




Hunting for commodity malware related C2 traffic


<document last modification date>


<your name>

Objective Statement

This playbook provides practical instructions for discovering malware-related C2 traffic on Royal Acacia’s infrastructure.

The primary goal is to find compromised assets, and take them offline. This is to prevent:

  • The theft of sensitive information
  • Files to be encrypted on the mapped network drives (ransomware)

The secondary purposes of this playbook are:

  • Finding related C2 IPs to identify other compromised assets
  • Identifying and blocking the phishing email that was delivering the malware

Scope and Applicability

Company PCs of L3 incident analysts. This playbook should be run at least once at 10:00 am on workdays. The shift log must be updated even if nothing was found.

Methodology and Procedures

Query Splunk for finding traffic between our company and known C2 IPs

  1. Download the list of known C2 servers from
  2. Run the following command to extract the raw IP addresses:
    $ cat c2-ipmasterlist.txt | grep -v ^# | cut -d , -f1 | sort -u > c2ips_20150509.csv
  3. Upload the CSV file to Splunk
  4. Run the saved query with the new CSV file
  5. If any result is found, jump to the next section for validation

Validating the C2 traffic

  1. Go to
  2. Enter remote IP address on the top search input field
  3. If remote IP can be tied to malware activity, create a ticket and move to the next section. Otherwise, proceed with the next IP.

Taking the compromised host offline

  1. Call Helpdesk on #12345
  2. Tell them to collect the compromised asset from the owner
  3. Ask Helpdesk to rotate the user’s AD credentials
  4. Ask them to prioritise this request as ‘P1’
  5. Add the ticket number from Helpdesk to our ticket
  6. Move on to the next section to search for other affected devices

Pivot on the IP

  1. Still on, open the pulse related to the C2 IP
  2. Scroll down to “Indicators of Compromise”
  3. Enter “ipv4” to the Search field
  4. Copy and paste all IP addresses into a new CSV file
  5. Upload the CSV file to the ticket
  6. Upload the CSV file to Splunk
  7. Run an ad-hoc query again to search for the listed IPs
  8. If any result is found, repeat the process again follow “Validating C2 traffic” and “Taking the compromised host offline“ sections. There is no need to pivot again on these IPs.
  9. Once finished with processing all IPs, go to the next section to find the initial compromise

Finding the initial compromise

  1. Go to the mailboxes of the users of the compromised assets
  2. Scan through the emails from the past three (3) days
  3. Look for emails with attachments and web links
  4. If you find an email with a suspicious file or link in it, validate that on VirusTotal
  5. If you find a dodgy email, which could have caused the compromise, export the full email and upload it to the ticket
  6. Engage a colleague of yours to run the Phishing playbook on the email

Final steps

  1. If you managed to pivot on all IPs and did not find any further compromised devices, resolve incident
  2. Update the shift log with a brief summary of the actions taken
  3. If anything unusual happened during the incident, bring it up to the weekly post-mortem meeting


Malicious activity typically involves some form of covert communication with a remote host on the Internet. Logs, network sensors, or telemetry data should capture the metadata of these connections. We should rely on external data feeds, internal tools, malware analysis, and third-parties for identifying the C2 traffic. Once a compromised device is discovered, we determine the mitigation strategy first and run the corresponding playbook afterwards. All affected computers should be identified, then taken offline to eradicate the threat from the infrastructure.

Useful Links

Threat Intelligence feeds:

List of malware researchers:


Botnet sinkholes:

DGA Checker: