Command-and-Control (C2) beaconing is malicious communication between a Command-and-Control (C2) server and malware on an infected host. C2 servers can orchestrate a variety of nefarious acts ranging from denial of service attacks to ransomware deployment to data exfiltration. Beaconing occurs when an internal host makes egress requests to an external server at predetermined asynchronous intervals through a network boundary.

A beacon is post-exploitation network traffic. Ideally, the threat actor wants to maintain communication, and command and control over the compromised endpoint. However, firewalls can easily detect this continued network connection, and recognize it as malicious traffic. As a result, threat actors utilize various evasion techniques like malware beaconing to hide their activities. An infected endpoint periodically sends a beacon signal to a C2 server for new instructions, such as to perform a directory listing, exfiltrate data, and so on. The C2 server hosts instructions for the malware, which are then executed on the infected machine after the malware checks in. The check-in interval for beacons and the methods they use for this communication are typically configured by the attacker. Another evasion tactic involves waiting long, randomized periods before communicating (known as jitter). Beaconing enables the threat actor to undertake any of his nefarious activities remotely, and with a high degree of stealth. Common whitelisting and blacklisting techniques often fail against a sophisticated adversary since they use common services like Twitter as their communication channel for C2. An adversary will determine through reconnaissance and intelligence gathering which methods are likely to be effective and pre-configure their malware payloads to utilize those that will bypass common firewall rulesets.

Detecting Beaconing

The PCAP file to be analyzed in this article can be downloaded from the link provided here.

Finding Beacons: Long and Cumulative Connections

In determining long and cumulative connections, we are concerned about the following:

The total time for each connection

Which connections have gone on the longest?

Cumulative time for all pair connections

The total amount of time the pair has been in contact.

To obtain some basic information about the file, we enter the following commands.

The time window of the network activity being audited is 23.99583 hours and the size of the associated PCAP file is 82 MB. For files that are too large for capinfos, the following command can be entered to ascertain the time window of network activity.

To identify traces of evil, we will begin by analyzing the file with Zeek. Fundamentally, Zeek turns raw network traffic into comprehensive metadata logs. These logs act as a high-level overview of all of the network activity broken down into many different categories. This can make it easier to focus on one type of traffic thereby simplifying analysis. To generate these logs, feed the PCAP to Zeek as shown below.

To gain insight into every connection on the network, we will analyze the conn.log file. It allows network and security teams to find unusual flows, unexpected protocols, policy-prohibited connections, and more. We can inspect the content of this file by using the less command as follows:

less -Sx20 conn.log

To identify long connections, we will need to extract the following fields:

Source IP address - id.orig_h
Destination IP address - id.resp_h
Duration of each connection - duration

To review specific fields of interest within this file, we use the zeek-cut command as follows.

The above shows the longest unique connections for the 24 hours of network activity. The longest connection is just a little short of the 86,398-second capture duration. To identify the cumulative time, we will utilize the datamash utility. The datamash command is the utility that enables us to retrieve cumulative talk times by adding connection times (3) of identical source (1) and destination (2) IP addresses.

Note the first entry is still the same, but all others are new. IPv6 addresses due to their length are not properly aligned. The threat hunter might want to investigate these destination IP addresses to find answers to the following questions.

Who manages ASN?
Geolocation information
IP delegation
PTR records

The longest connection appears to be business partner-related
The second longest connection is used to keep Windows 10 updated

Neither of these connections appears to be malware-related. The next step is to detect evil by looking for persistent outbound signals. Here we want to identify which internal IPs are connecting to individual external IPs most frequently. We also want to determine consistency in session size. This might lead us to effectively detect beaconing in the network. To achieve this, we need to clearly identify the following:

Number of unique connections over the 24 hours (not the number of packets) and the amount of payload data transferred.
Zeek displays both bytes sent and received. Our focus is on the bytes sent (orig_bytes).

To identify the highest number of unique connections, we enter the command shown in the figure below. The external IP 104.248.234.238 seen below should fall into the radar of our investigation. The rest are just local multicast traffic.

To analyze the session size to determine persistency, we will enter the following command. As revealed in the figure below, every session resulted in 477 bytes sent to the external host 104.248.234.238. This could indicate a beacon that was not activated over the 24 hours.

Now that we found a suspicious IP pair, we will analyze the payloads in these sessions. The ngrep utility can be used to search for patterns within the payload of all packets. We will focus on the suspicious IP pairs as follows:

ngrep -qI fiesta_24hr.pcap host 192.168.99.51 and host 104.248.234.238 | less

Now, we need to identify all of the URIs requested from this external host. This is stored by Zeek in the http.log file. The fields of interest are:

Source IP address - id.orig_h
Destination IP address - id.resp_h
URI - uri

Searching Google for rmvk30g revealed it is Fiesta EK malware, a C2 channel used in beacon communication.

To get the statistics of all the services inside this data stream, we will investigate the service field inside the conn.log file.

To determine the timestamps of network connections, we will extract the ts field in the conn.log file as follows. This is useful for trying to determine that someone is trying to use applications outside their approved hours.

Eliminating DNS and blank entries due to noise will give us an overview of services used in the network as shown below.

The most talkative hosts (originator) in the network can be obtained by entering the following command. The IP address of interest has been highlighted in the figure below.

The IP address that receives the most traffic can be obtained as follows. The IP address of interest has been highlighted in the figure below.

To obtain the destination ports that are connected to the most, we will enter the following command. The ports of interest are highlighted below.

To determine connections that have been opened the longest (connection persistency), we will enter the following command.

Elastic search listens on port 9200. The longest open connection is therefore not suspicious as it is a SIEM platform. However, the next persistent connection is between our host and the suspicious IP address discovered earlier on the insecure port HTTP. A quick trick for converting the duration time from seconds to a more understandable format is shown below.

Finding Beacons: Detecting C2 Over DNS

To identify C2 communications, beacons, and other malicious DNS queries, we will filter out normal internet and internal company-related traffic from the dns.log file so that we are left with DNS traffic only.

Note: This should be done with caution as C2 communications have been established using common services like Twitter, Github, Microsoft Teams, and so on.

We will extract the result to a text file, sort, and count. We will also review FQDNs per domain. The following steps might give an insight into DNS beaconing.

Check domains with a lot of FQDNs
Get a list of IP addresses returned
Compare against traffic patterns

Are internal hosts visiting this domain
Is it just nameservers

The following are indications of C2 over DNS.

Lots of FQDN queries
But no one ever connects to these systems
Many C2 over DNS tools use TXT record types to create a channel

Filtering out normal internet and internal company-related traffic from the dns.log file leaves us with only DNS queries as shown in the figure below.

We can also filter out the DNS answers by replacing 'query' in the above command with answers.

For unique domains that have been queried via DNS, we will enter the following commands.

Extracting the IP addresses that were queried is done by executing the following command.

To obtain the statistics of DNS record types, we will need to extract the "qtype_name" and "query" fields for each record.

Nothing odd has been found so far. We can pivot to the http.log file to find more artifacts. We can look out for suspicious user agent strings by entering the following command.

We will also investigate data requests and transmissions by obtaining statistics for POST and GET methods.

We enter the following command to obtain filenames from phishing downloads or data exfiltration. Here I focus on the suspicious IP address for brevity.

To check for potential drive-by attacks, we will compare the host domain to the referrer site as follows.

To identify files uploaded or downloaded based on HTTP GET or POST requests, we will extract the mime_types fields as follows.

To obtain the statistics of files that were transferred, source, and destination IP address, we will query the files.log file as follows.

The following command displays filenames and their extensions.

To obtain statistics on bytes transferred, we will enter the command given below.

At this point, we should consider another beacon detection tool to make our investigation more robust. We are going to cross-check our findings with RITA to be sure we did not miss out on any artifacts. RITA provides a consistent interface for identifying C2 activity. Even very slow beacons can be detected. First, we will import all Zeek logs into a target database so we can use all the Machine Learning and data statistics that are built into this tool to find evil.

To list the available databases, we enter the following command.

The following command shows the longest unique connections in the network.

To identify beacons in the network, we will enter the following command. It should be noted that RITA scores beacon on a scale of 0 - 1 with 1 being a perfect beacon score. Scores of 0.8 and above should therefore be investigated as they are indicative of beaconing activity.

To investigate C2 over DNS we will enter the command as given below. The result does not reveal any evidence of DNS beaconing.