Malware of the Day – Understanding C2 Beacons – Part 2 of 2

Introduction

As a teacher of mine was fond of saying, “In science, you seek the ideal, but often encounter the real.” In our previous article, we postulated ‘the ideal’ based on first principles. We predicted how Command and Control (C2) beacons would appear in AC-Hunter and how this appearance might change as we altered delay, jitter, and introduced multiple redirectors with different host rotation strategies.

This follow-up article delves into ‘the real.’ We’ve conducted extensive simulated compromises mirroring all the C2 beaconing setups discussed in the previous post, and so today we’ll compare our findings from AC-Hunter to those predictions.

Before we proceed, please note the following two important points:

1. As the title suggests, this is the second in a two-part series. While it holds value on its own, we strongly recommend first reading the preceding article to fully benefit from the content.

2. We’re pleased to share that datasets for all nine attack simulations presented here are available at the bottom of this page. We encourage you to follow along in AC-Hunter to gain direct experience in observing compromises firsthand. This also presents an excellent opportunity to explore various C2 beacons in our newest version of RITA (version 5), which you can download here.

It’s our sincere desire that these two articles will help you develop keen insight into not only the appearance of C2 beacons in AC-Hunter/RITA, but how the appearance might change in response to varying key factors. Ultimately, we believe that this skill will help you recognize a wider variety of attacks so that you are empowered to keep your organization safe against them.

 

Quick Recap

Before diving into our results, let’s quickly recap some key concepts from our previous article that are critical to interpret this article’s findings.

As discussed before, most modern C2 frameworks allow for a beacon/implant (essentially a C2 client) in which both delay and jitter can be set. In Cobalt Strike, the framework we’ve used to generate today’s data, we can specify the delay in seconds and jitter as a percentage. This percentage is then subtracted from the delay to create our expected histogram range.

Consequently, a C2 beacon with delay and jitter will produce a histogram containing three important values:

1. The minimum range value
2. The maximum range value
3. The mode, which represents the peak of the histogram

All three of these values are illustrated in Image 1 below.

 

As shown in the image, the histogram’s maximum value is equal to D (the delay), while the minimum value can be calculated as the delay minus the product of delay and jitter (as a fraction). Mathematically, we can express this minimum value as D – Dj, which can be rewritten as D(1-j).

Furthermore, we see that the highest point on our histogram is represented by the symbol Mo. If Mo is exactly halfway between D and D(1-j), its value can be expressed as D – (Dj/2), which can be rewritten as (D(2-j))/2.

To recap, our minimum range value, maximum range value, and mode can be determined using the following formulas:

 

Finally, it’s important to note that in AC-Hunter, all values on the X-axis are reported as whole, positive integers: 0, 1, 2, 3, 4, etc. In reality, network connections don’t conform to this precise timing and can occur in fractions of a second. To address this, AC-Hunter truncates these numbers, rounding them down. For example, a 2.2-second interval is considered 2 seconds, and a 4.8-second interval is considered 4 seconds. We will account for this rounding in the final step of our calculations to ensure our predictions align with AC-Hunter’s display format.

And with all that, let’s dig into our results.

 

Base Histogram

Our first dataset will serve as the baseline (i.e. “departure point”) for all other sets. For this we are using a delay (D) of 30 seconds, and jitter of 25%.

We’d thus expect our histogram values to be:

 

So now that we have some idea of what to expect, let’s check in and have a look at our results from AC-Hunter – see Image 2 below.

 

For now, let’s pay attention only to the histogram shown in the top right – see Image 3 below.

 

Upon closer inspection, we can see that our histogram indeed aligns with our expected values – with our minimum value at 22, maximum value at 30, and mode at 26. Note that we overlaid the bell curve trendline (in orange) to emphasize that, while our histogram largely conforms to this ideal, reality is often a little messier.

Let’s also have a quick look at our results in RITA – see Image 4 below.

 

Our connection was successfully categorized as Critical (1 of only 3) among approximately 100 different connections. It also received the Rare Signature modifier. For HTTP connections, RITA compares the user agent string to those used in all other connections. Since this was the only connection using this specific user agent (Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/5.0), RITA applied the Rare Signature modifier.

This modifier should always interest threat hunters, as attackers may struggle to predict user agents on target systems without extensive reconnaissance. Many attackers are often careless when assigning user agents in C2 configs, as few defensive tools besides RITA and AC-Hunter report unique uses like this.

Note however that, as is almost always the case, this is not in and of itself indicative of a compromise. Misconfigurations, employee violations, or hosts with specialized applications communicating to a single external host can also trigger this modifier.

Now that we’ve got a good feeling for our baseline dataset, let’s have a look at what happens when we vary our delay.

 

Decreased Delay

In our second dataset we’ve kept our jitter (j) fixed at 25% while decreasing our delay (D) to 10 seconds.

 

Let’s once again compare this to our results from AC-Hunter – see Image 5 below.

 

Let’s once again pay closer attention to our histogram – see Image 6 below.

 

Again, our values more-or-less align with what we predicted using our formulas. Further, our entire histogram has shifted to the left, just as we predicted. Though the scale of the graph changed, we can confirm that whereas before our maximum range value (i.e. delay) was at 30, it’s now at 10.

Now let’s turn our attention to what happens when we increase our delay.

 

Increased Delay

In our third dataset we’ve once again kept our jitter (j) fixed at 25%, while this time increasing our delay (D) to 300 seconds.

 

Let’s compare this to our results from AC-Hunter – see Image 7 below.

 

Let’s once again focus on our histogram – see Image 8 below.

 

Once again, as predicted our entire histogram has shifted to the right on the x-axis – our new maximum range value is now 300. However, even though our values all align with where we’d expect them to be, we can also see that the actual shape of our histogram has disintegrated. Our orange trend line no longer mirrors the results in any meaningful sense, and we can witness many localized peaks and valleys (i.e. noise). Any honest individual would be hard-pressed to call this a bell-curve.

It’s thus interesting to reflect that despite this, AC-Hunter still assigned a 100% histogram score to this dataset (Image 7, above). This is because, under the hood, RITA (and thus by proxy AC-Hunter) uses a form of data smoothing to minimize noise and focus on the overall trend.

What exactly is meant by data smoothing? Without veering too far off into the weeds, let’s see for example what happens if we take those same values from Image 8 (above), and apply a moving average smoothing technique, averaging every 10 consecutive values. In other words we recreate our graph by creating new data points that are an average of 10 neighboring data points. Doing so transforms our histogram to Image 9 (below).

 

As we can see, though the result by no means produced a “perfect” bell curve, we’ve ironed out localized peaks and valleys and the result better communicates the overall trend we are interested in. Data smoothing is thus used to help us avoid “mistaking the trees for forest”, especially when we are dealing with large ranges, as is the case here.

Now that we’ve investigated what happens when we vary our delay, let’s now turn our attention to what occurs when we instead alter jitter.

 

Decreased Jitter

In our fourth dataset we’ve kept delay (D) fixed at 30 seconds, while this time decreasing our jitter to 10%.

 

Let’s compare this to our results from AC-Hunter – see Image 10 below.

 

Once again let’s have a closer look at our histogram – see Image 11 below.

 

Overall our values align with our predictions, and if we compare this image with our baseline (image 3, above), we can indeed observe that the entire shape of our bell curve has changed. Our bell curve’s height has increased relative to its width, resulting in a “sharper” peak, just as we predicted it would in our previous post.

Something else that’s interesting is that we can observe a single outlier that took 33-seconds (see green arrow), well beyond our predicted range. Keep in mind that even though this beacon was configured to transmit network signals exactly within the range of 27 – 30 seconds, the actual transmission time can be affected by various external factors.

Once the packet is on the wire en route to the C2 server, a variety of factors such as network congestion, routing issues, or temporary outages along the transmission path can potentially delay its arrival. So the presence of these outliers on our histogram underscores the inherent variability in real-world network conditions, even when the sending mechanism is programmatically controlled.

Let’s now see what happens when we increase our jitter.

 

Increased Jitter

In our fifth dataset we’ve once again kept delay (D) fixed at 30 seconds, this time however jitter has increased to 99%, the maximum value.

 

Once again, let’s compare this to our results from AC-Hunter – see Image 12 below.

 

Let’s pay closer attention to our histogram – see Image 13 below.

 

Our expected values align nicely, however as was the case earlier, we can see that spreading our data out over a large range results in the histogram starting to lose its archetypal bell curve shape. Now of course we could once again attempt to apply a data smoothing technique to see if we could tease the shape out – this time however we’ll leave it up to the reader to attempt this on their own if they so desire.

Finally, let’s see what happens in the case that no jitter is being used.

 

No Jitter

In this dataset we’ve once again kept delay (D) fixed at 30 seconds, however this time no jitter was applied. As a result we expect our minimum range, maximum range, and mode to all converge on a single point at exactly 30 seconds.

Let’s jump into AC-Hunter to see if this is indeed the case – see Image 14 below.

 

And below in Image 15 we can see our histogram in greater detail.

 

As expected, practically all the connections are at exactly 30 seconds. In fact, out of a predicted 2880 connections (24 hr/30 sec), a total of 2859 connections were observed at this interval – a fidelity rate of 99.27%. We also see 3 outliers here – 1 at 2 seconds, 1 at 28, and then a straggler at 174 seconds – again underscoring the impact of external factors.

Let’s dip back into RITA and look at the results for this connection – Image 16, below.

 

RITA once again correctly identified this connection as Critical. In addition to the Rare Signature modifier, RITA has now labeled it as having a MIME Type Mismatch.

A MIME type mismatch occurs when there’s a discrepancy between the declared content type and the actual data in an HTTP/HTTPS response. Typically, when you request data via HTTP/HTTPS, the server responds with the requested data in the message body and includes a ‘Content-Type’ field in the response headers specifying the MIME type of the data.

In simpler terms, the server provides both the requested data (in the body) and a description of the data type (in the header). Generally, we expect these to match. However, when they don’t – for example, if the body contains JSON data but the header’s ‘Content-Type’ field reports it as image/jpeg – it’s known as a MIME type mismatch.

While often attributed to misconfigurations, MIME type mismatches can sometimes indicate potentially malicious activity. In C2 scenarios specifically, a server might send encoded executable content while declaring it as harmless plain text.

Let’s jump into the traffic capture of this dataset to see if we can locate the offending packet using WireShark – see image 17 below.

 

We can see here that the HTTP response (originating from the C2 server) indicates the content of the packet body to be text/plain (green rectangle) in the header. However, while the body contains some form of encoded data, RITA actually compares the path extension to the Content-Type. In this case, our path has no extension (/bbbbbbbbbb), which is not what we would expect if it were indeed text/plain. Consequently, RITA has concluded that this must be a MIME Type Mismatch.

This discrepancy between the declared content type and the actual path structure raises a red flag, as legitimate text/plain content typically includes appropriate file extensions. The lack of an extension, combined with encoded data in the body, further reinforces the suspicion of potential malicious activity or, at the very least, an unusual server configuration.

And that’s it for varying our jitter. Let’s now have a look at the results from using two redirectors, starting with the round robin host rotation strategy.

 

Round Robin Host Rotation Strategy

We’re once again simulating a departure from our baseline case, that’s to say where our beacon has a delay of 30 seconds, with a jitter of 25%. In our previous post, we predicted that using two redirectors with the round robin rotation strategy would result in a beacon that looked similar to one with double the delay, that is to say 60 seconds.

If this was the case we’d expect our resulting histogram values to be:

 

So let’s see how well this lines up with our results in AC-Hunter – see Image 18 below.

 

Once again let’s take a closer look at our histogram – see Image 19 below.

 

Our values align well with our prediction – when we use two directors with the round robin host rotation strategy it is indeed as if the delay was doubled for a single redirector. The round robin host rotation strategy thus does little in the way of altering the shape of our histogram.

This is however not the case when we change the rotation strategy from round robin to random.

 

Random Host Rotation Strategy

In the previous article we predicted that using multiple redirectors with a random host rotation strategy would create an asymmetrical histogram according to the “coin flip model”. We expect it to show positive skew (“a long tail”), with actual connections appearing at multiples of the delay, in this case 30 seconds.

Let’s have a look at the result from AC-Hunter – Image 20, below.

 

Let’s pay closer attention to the histogram on – Image 21, below.

 

Connection intervals closely correspond to multiples of our delay at 30, 58, 90, 118, 150 seconds, and so on. The frequency of occurrence approximately halves for each subsequent interval, aligning with our ‘coin flip model’ prediction.

Finally, let’s also see what would happen if we introduced some jitter (25%) into this exact same setup – see Image 22, below.

 

And let’s zoom in on our histogram one final time – Image 23, below.

 

The histogram maintains its overall positive skew while becoming more filled out. Instead of individual connection bars at multiples of our delay, we now observe small clusters. The graph has taken on a fractal-like quality, with ‘mini’ bell curves appearing at delay multiples. The amplitude of these curves approximately halves for each subsequent cluster, and as with our symmetrical histograms, the maximum range value of each cluster aligns with multiples of the delay.

 

Conclusion

In today’s Malware of the Day post, we concluded our in-depth exploration of C2 beacons, their fundamental properties, and how varying those properties affect their appearance in AC-Hunter by validating our previous hypotheses with real-world data.

Specifically, we examined data from AC-Hunter, and in some cases RITA, when we:

• Varied the beacon delay (D)
• Varied beacon jitter (j)
• Applied the round robin host rotation strategy with 2 redirectors
• Applied the random host rotation strategy with 2 redirectors

 

Overall, our predictions held up – we could accurately predict our minimum range, maximum range, and mode values using the formulas we developed. We observed that specific changes in properties led to predictable outcomes in our graphs.

However, as is often the case when “the ideal” meets “the real”, we saw that reality can sometimes be a bit messier than our paper-bound predictions. For instance, when our connections are spread out over a large range, the ideal bell curve shape begins to disintegrate. Additionally, some outliers are occasionally seen due to the influence of external factors beyond our control. Regardless, being aware of these due to some first-hand experience will help us recognize it, ensuring it does little to impede our threat hunting efforts.

We encourage you to not only download the data provided below and explore these attacks yourself, but also generate your own unique datasets by performing simulations with distinct properties. Use what you’ve learned here to make predictions and then see if you can more easily identify the attacks in AC-Hunter based on them. Ultimate mastery results from applying what you’ve learned to suit your own unique needs.

We hope this two-part series has helped you gain further insight into the fundamental workings of C2 beacons, and more importantly, what you can expect them to look like in AC-Hunter based on a wide range of potential properties. We will continue our mission of helping you become proficient at harnessing the full potential of AC-Hunter, ultimately helping protect your organization against these types of attacks. We’re grateful to be on this journey together to ensure your organization remains safe and secure.

 

Video Summary

 

 

Below are capture files of this network traffic. Would you be able to easily identify these C2 channels within your network?

 

Capture Files

PCAPs

Because… PCAPs, or it didn’t happen. 😊

The following PCAP files are packet captures taken from the same lab environment over a 1-hour time frame and a 24-hour time frame. The files were generated using Wireshark from the target host and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The PCAPs are safe, standard PCAP files and do not include any actual malware.

Delay 30 seconds Jitter 25% 1 Hour Capture
delay_var_d30_j25_1h.pcap
Size: 19.40 MB
SHA256 Checksum: 661574788c32ff819985aff510822d0488097acb7de22bce60609a76b46ea4c6

Delay 30 seconds Jitter 25% 24 Hour Capture
delay_var_d30_j25_24h.pcap
Size: 2.26 GB
SHA256 Checksum: ad2325087f3b55ee4ba23592b76d1b179505ff8bc08f7e0f52ad44ab5f47d2bd

Delay 10 seconds Jitter 25% 1 Hour Capture
delay_var_d10_j25_1h.pcap
Size: 7.8 MB
SHA256 Checksum: d01b6a4ca71cb1d70205c74d845e9fc7bf6e2aa5f0f2d7c670fad397f3901010

Delay 10 seconds Jitter 25% 24 Hour Capture
delay_var_d10_j25_24h.pcap
Size: 384.9 MB
SHA256 Checksum: 5684f4be2d04e129ac50cbd0f5bc377416ac516a933e3597a8062182baf3e88f

Delay 300 seconds Jitter 25% 1 Hour Capture
delay_var_d300_j25_1h.pcap
Size: 4.8 MB
SHA256 Checksum: d07a9fdabdcd4e241e3ce685fae5b083c88d5604454e38bb7804c4f88ac98f4f

Delay 300 seconds Jitter 25% 24 Hour Capture
delay_var_d300_j25_24h.pcap
Size: 4.51 GB
SHA256 Checksum: 7d5623298f283dd29a49e2adce4065a165867b8d86cc07cc65d635a91a49e653

Delay 30 seconds Jitter 10% 1 Hour Capture
jit_var_d30_j10_1h.pcap
Size: 6.2 MB
SHA256 Checksum: ed45ddd8e53021665f0616aaede3b92913bb152cceeec30e7897fdd202a22aad

Delay 30 seconds Jitter 10% 24 Hour Capture
jit_var_d30_j10_24h.pcap
Size: 353 MB
SHA256 Checksum: e814fc169dd9f4e300dd63d38d1a08acdd33ee981406647880c29ab87855a74b

Delay 30 seconds Jitter 99% 1 Hour Capture
jit_var_d30_j99_1h.pcap
Size: 7.00 MB
SHA256 Checksum: 1d754f369490eb943e9f1a9663aa1a09db8ed3cec80db39e687d2f96e315c155

Delay 30 seconds Jitter 99% 24 Hour Capture
jit_var_d30_j99_24h.pcap
Size: 193.2 MB
SHA256 Checksum: 931d4cea7c6ceb40d17caec9a3385eceaedd6ff2cc402dc447e771ded4ef8928

Delay 30 seconds Jitter 0% 1 Hour Capture
jit_var_d30_j0_1h.pcap
Size: 5.95 MB
SHA256 Checksum: 822a579f85d5fbb3e800e3b611beb7a4bf03d28691bf30a65ac629ae2bd4456a

Delay 30 seconds Jitter 0% 24 Hour Capture
jit_var_d30_j0_24h.pcap
Size: 501.30 MB
SHA256 Checksum: dfc64b43015eb95cd4d46c31a2955af8a879222fc1e64fcdbd013834fd9f5e1d

Round Robin Redirector, Delay 30 seconds Jitter 25% 1 Hour Capture
round_rob_r2_d30_j25_1h.pcap
Size: 6.00 MB
SHA256 Checksum: a51d536d4da2acafe4e18c702d2d7488030178b1b7abe2ab7821276830fe1c6c

Round Robin Redirector, Delay 30 seconds Jitter 25% 24 Hour Capture
round_rob_r2_d30_j25_24h.pcap
Size: 647.50 MB
SHA256 Checksum: 1a9bcff3fd85b5228046cf86aaa11628f164ffc2265a05a69b128beea414a

Random Redirector, Delay 30 seconds Jitter 25% 1 Hour Capture
random_d30_j25_1h.pcap
Size: 12.6 MB
SHA256 Checksum: 6e5c5758b24c0e6f4fb9d8ea0eeb14f470663d2d7ebfeb0207d1ef7167edc975

Random Redirector, Delay 30 seconds Jitter 25% 24 Hour Capture
random_d30_j25_24h.pcap
Size: 309 MB
SHA256 Checksum: 993b97fdbeaac6b44dacba0b57cc7ebe0cc0328aa44f6326d7d5591e01d73304

Random Redirector, Delay 30 seconds Jitter 0% 1 Hour Capture
random_d30_j0_1h.pcap
Size: 7.6 MB
SHA256 Checksum: fc31e3ea6e3b322f57c8d3abeeef4b7510e151e87a7d875057409915a12511a2

Random Redirector, Delay 30 seconds Jitter 0% 24 Hour Capture
random_d30_j0_24h.pcap
Size: 302.6 MB
SHA256 Checksum: 595536a1ab81ba5868514483526307b333d73eb09a1e5d95825122ebdcfac724

 

Zeek Logs

If you are an AC-Hunter or RITA user, we are providing 24-hours of Zeek logs for you to import directly into AC-Hunter or RITA. The following Zeek Logs have been taken from the same lab environment over a 24-hour time frame and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The Zeek logs are safe, standard log files and do not include any actual malware.

The following is an example of how to import Zeek logs into AC-Hunter or RITA:

ssh into your AC-Hunter or RITA server and upload all the Zeek logs contained in the zip file below (all files that have the ‘.log.gz’ extension) into a temporary directory on the server. In this example, we are uploading the Zeek logs into /tmp/example-logs/

Then run the following command:

For AC-Hunter v6.x and RITA v4.x and earlier:

rita import /tmp/example-logs/*log.gz example

For RITA v5.x:

rita import --logs=/tmp/example-logs/*log.gz --database=example

You will now have a new database in the AC-Hunter UI/web interface or RITA CLI titled “example” you can select and view.

 

Delay 30 seconds Jitter 25% 24 Hour Zeek Logs
delay_var_d30_j25_zeek_logs.zip
Size: 4.86 MB
SHA256 Checksum: 3a68c1bffa3b840e4a8c73482e60f5ed519087c7e68fdeaa5cc54f0e073091b5

Delay 10 seconds Jitter 25% 24 Hour Zeek Logs
delay_var_d10_j25_zeek_logs.zip
Size: 5.09 MB
SHA256 Checksum: a99d7688065e65c801e1643de36b991b25822e34556913db019298bb4ef98ef7

Delay 300 seconds Jitter 25% 24 Hour Zeek Logs
delay_var_d300_j25_zeek_logs.zip
Size: 3.73 MB
SHA256 Checksum: 88bac80fa9b8f3d8252d97221ee71f651428c67d106d5f4e6a5a6339db240110

Delay 30 seconds Jitter 10% 24 Hour Zeek Logs
jit_var_d30_j10_zeek_logs.zip
Size: 3.91 MB
SHA256 Checksum: 624128047fb89a91ed9af4c89d8246c087257887285e9104b96ded013c15c2cd

Delay 30 seconds Jitter 99% 24 Hour Zeek Logs
jit_var_d30_j99_zeek_logs.zip
Size: 4.49 MB
SHA256 Checksum: d0787aee3c4d88ef429db2ca96553187e597bdf524b2277470b2abcb2c80bd71

Delay 30 seconds Jitter 0% 24 Hour Zeek Logs
jit_var_d30_j0_zeek_logs.zip
Size: 8.48 MB
SHA256 Checksum: 16d379ba4cdd3af5fa5efed6019dc0c17db9701aaf2a7c44c84f9a1b5ccb6b3f

Round Robin Redirector, Delay 30 seconds Jitter 25% 24 Hour Zeek Logs
round_rob_d30_j25_zeek_logs.zip
Size: 4.43 MB
SHA256 Checksum: 78288f66f401f02f2e9553dcf602a04d8c89b3364d71058c44b17d523721092b

Random Redirector, Delay 30 seconds Jitter 0% 24 Hour Zeek Logs
random_d30_j0_zeek_logs.zip
Size: 4.34 MB
SHA256 Checksum: fba9d5c476fdb1db2e80222d700ee0a077d24335e1bc0f8b593b9e5f10980852

Random Redirector, Delay 30 seconds Jitter 25% 24 Hour Zeek Logs
random_d30_j25_zeek_logs.zip
Size: 4.39 MB
SHA256 Checksum: ecd5d77903025cfe840c6d31e150f510ee142de97ae65c219b528612be7ffc1d

 

NOTE: You may notice some slight variances in scoring and time when importing these files into your AC-Hunter or RITA instance compared to our screenshots. This can be caused by inconsistencies in capture export timing and by manually importing PCAP files and Zeek logs into AC-Hunter or RITA, but it is not an indication of an issue.

 

Discussion

Want to talk about this or anything else concerning threat hunting? Want to share how good (or not so good) other detection tools were able to detect this sample?
You are welcome to join our Discord server titled “Threat Hunter Community” to discuss topics surrounding threat hunting. We invite you to join our server here.

 

A huge thanks to Keith Chew and Chris Brenton for allowing me the opportunity to contribute to this awesome initiative, as well as their guidance, helpful feedback, and for being a couple of stand-up gents.

Live long and prosper!

 

< Understanding C2 Beacons Part 1