Detecting Beacons With Jitter
One of the most common problems in beacon detection is identifying beacons where the attacker is varying the timing of the command and control (C&C) channel. This is commonly referred to as “jitter“, and adds a random level of uncertainty into the beacon timing. In this blog post I’ll talk about how AI-Hunter deals with the problem of jitter so that beacon activity is consistently detected.
Jitter and How it Works
Jitter is the introduction of randomness into the beacon timing. Imagine I have a beacon signal that is set to call home once per minute. I could introduce jitter by programming the Remote Access Trojan (RAT) to vary that timing by +/- 50%. So rather than calling home at specific 60 second intervals, the RAT would call home at time intervals varying from 30 seconds to 90 seconds. Because of this variance in the timing, the beacon signal now becomes more difficult to detect, as it’s not quite so predictable.
Plotting Jitter Over Time
To get an idea of how jitter can look when introduced to a beacon signal, have a look at Figure 1. Our X-axis is the time gap between beacon signals while the Y-axis is quantity. The graph shows that a majority of the time, about 1,500 samples, had an 18 second time gap between them. Approximately 1,200 samples had a 17 second time gap, while approximately 1,100 samples had 19 seconds between beacon signals.
Figure 1: This figure charts how often a specific time interval occurred between beacon signals.
When Random is Not so Random
While jitter has been introduced into the beacon timing shown in Figure 1, we can see that the jitter is not completely random. Because it varies off of an absolute time period, most of the data points end up close to this interval. The result is a timing plot that has a bell shaped curve to it. This is a pattern we can then match on in order to identify beacons with jitter.
The other possibility is that the attacker uses a truly random interval. For example, they could simply program the RAT to grab a random number between 30 and 90. This value then becomes the timing gaps between two signals. This process is then repeated each time the RAT calls home. Because the results would be better randomized, the result would be more of a box shaped curve. Again, this would give us a pattern that we can then match against.
Analyzing Beacons in Large Time Blocks
Another way we can analyze the data is to group it into large time buckets. An example is shown in Figure 2. Here we are simply counting the number of beacon signals that occur each hour, over a 24 hour period of time. Note that our graph is almost completely flat. On a per hour basis, we are seeing a consistent beacon quantity. Even though our beacon signal timing is changing, the variances are being normalized by the long sample period.
Figure 2: A beacon signal with jitter plotted over 24 hours. Note that even with a variance, we are seeing about the same number of beacons per hour.
Let’s go back to our original example of a beacon signal that is every 60 seconds, but jitters +/- 50% and use that to describe what we are seeing. A fixed 60 second beacon interval is going to generate about 60 beacons per hour. If I vary the timing, and have about as many beacon intervals below 60 seconds as above it, I’m still going to average out to about 60 beacons per hour. By looking at the signal over large time chunks, we can effectively normalize out the timing impacts of jitter. The result is that we still have a beacon signal that can still be detected.
Beacons with jitter can be extremely difficult to detect when small time samples are used. If I am only looking at a 60 – 120 second time periods, a 60 second beacon that jitters +/- 50% can easily stay under the radar. However, by looking at much larger time blocks, like an hour or a full day, the impact of jitter can be normalized out of the data so that the beacon can still be detected.
Chris has been a leader in the IT and security industry for over 20 years. He’s a published author of multiple security books and the primary author of the Cloud Security Alliance’s online training material. As a Fellow Instructor, Chris developed and delivered multiple courses for the SANS Institute. As an alumni of Y-Combinator, Chris has assisted multiple startups, helping them to improve their product security through continuous development and identifying their product market fit.