Varonis Threat Labs developed Jitter-Trap, a new technique to detect one of the most evasive steps in the cyberattack lifecycle: post-exploitation and C2 communication.
Beacons are being used by various threat actors, including state actors and criminal groups, and many of these cases stay undetected. Our analysis demonstrates how patterns of randomness, often employed for evasion, can be leveraged to uncover the presence of such traffic. By focusing on these identifiable patterns, security professionals can enhance their detection capabilities and bolster their defenses against advanced threats.
Continue reading to explore how defenders can use the Jitter-Trap technique to identify even the stealthiest beacons by analyzing behavioral signatures and network anomalies.
Post-exploitation frameworks
While initially designed for legitimate red teaming and penetration testing, frameworks like Cobalt Strike, Sliver, Empire, Mythic, and Havoc are frequently co-opted by threat actors to maintain access, execute commands, move laterally, and exfiltrate data — all while evading detection.
Key features of beacon frameworks:
- Modular architecture – Most frameworks provide a highly modular setup, allowing users to load additional payloads, scripts, or modules dynamically
- C2 communication – Beacons communicate with their operators using various protocols (HTTP/S, DNS, SMB, TCP, WebSockets, etc.), enabling stealthy data exfiltration and command execution
- Evasion techniques – Advanced frameworks include obfuscation, encryption, and traffic shaping to evade security tools like firewalls, EDR, and SIEM systems.
- Persistence and lateral movement – They support multiple persistence techniques, privilege escalation, and credential dumping to help operators maintain long-term access
- Malleable C2 Profiles – Cobalt Strike’s Malleable C2 Profiles allow users to customize the network traffic of beacons to mimic legitimate services and evade detection. Operators can configure HTTP headers, payload encryption, and data encoding to appear like legitimate traffic (e.g., a Microsoft update, GitHub, or Cloudflare request.
Other frameworks, like Sliver and Mythic, offer similar evasion and customization capabilities, making them viable alternatives to Cobalt Strike. Security teams must continuously update detection strategies, analyze C2 traffic patterns, and employ behavior-based detections to keep pace.
Detecting beacon activity
There are a variety of techniques to detect beacon activities, including:
- Known IOCs associated with specific frameworks and operators, such as file hashes, IP addresses/domains/other known artifacts, and signature-based methods for identifying known binaries
- File and registry monitoring.
- PowerShell and scripting activity monitoring used for downloading secondary payloads
- Sandboxing and static analysis, which can identify the byte patterns at the start of the beacon configuration file, have various sets of Yara rules exist for beacon sample detection, and dynamic analysis can be used for encrypted samples
- Network analysis for beacon detection by looking for patterns consistent with beacon communication
- UEBA, used for monitoring unusual user behavior that deviates from typical patterns
However, evasion evolves just as fast. New samples with unknown IOCs are easily generated, Yara rules can be bypassed by additional obfuscation, and various tools are available with already implemented functionality to evade EDR detection.
For example, updated methods for process injection, running unmanaged PowerShell and more, like GitHub — Redefining Reality/Cobalt-Strike, enhance Cobalt Strike's functionality and its ability to evade antivirus/EDR detection.
In this blog, we’ll focus mainly on behavioral and network analysis for HTTP/s based beacons, and show how an evasion techniques can be actually used for detection.
Beacon vs Benign traffic: Characteristics for behavioral detection
Sleep times and jitter — Mainstream and Jailstream:
Sleep and jitter are parameters related to how the beacon manages its communication or ‘polling’ intervals in the context of post-exploitation frameworks. Sleep and Jitter parameters are considered basic concepts and are widely used in different frameworks.
The “sleep” parameter defines the fixed interval of time that the beacon will wait to check in for the next command. Its purpose is to control how often the beacon communicates with its operator.
The “jitter” parameter adds randomness to the sleep duration. Instead of having a fixed sleep time, jitter introduces variability, so the beacon will not always communicate with the server at the same interval. The main and only purpose of jitter is to obscure the predictable patterns of communication that could be used for detection and make it harder to identify.
With that in mind, let's take a closer look.
No jitter profile
Configuring no jitter (0) yields constant sleep times between requests and can be considered very noticeable.
However, there’s a lot of benign traffic caused by polling techniques used in web applications, where the client repeatedly requests data from the server at fixed intervals. This is often used to check for updates or changes in data without requiring the server to push updates to the client.
For example, it’s used in social media platforms to refresh notifications, with real-time collaboration tools to check for updates made by users, and financial trading platforms to poll updates of market data, prices, and so on.
The following photo is an example of benign traffic with exact constant time differences (i.e., sleep time with no jitter)
Constant sleep times are easily found with a timediff analysis that gives low standard deviation. In the above example we can see a benign session with 0 timediff standard deviation with different (per session) constant polling times in mean_diffs_set
Constant sleep times are easily found with a timediff analysis that gives low standard deviation. In the above example we can see a benign session with 0 timediff standard deviation with different (per session) constant polling times in mean_diffs_set
Below is an example of two benign different sessions of polling traffic originated from same source device to two different destinations with different constant sleep times.
Here we can see two examples of benign traffic, with different intervals but consistent sleep times. Google.com with a 600sec sleeptime and amazon with 60sec.
Here we can see two examples of benign traffic, with different intervals but consistent sleep times. Google.com with a 600sec sleeptime and amazon with 60sec.
Benign communication with fixed sleep times is not unique to malicious beacon traffic.
Profiles with jitter and the Jitter-Trap
The jitter property for sleep-time between requests exists to create light randomness with the intent to look natural and like real traffic caused by users, which is considered a stealthy option.
Now, let’s look a Bing Search Malleable C2 profile configuration. As seen below, this profile defines a sleep time of 60 seconds with 20% jitter.
Sleep and Jitter configuration for ’Bing Search’ profile
Sleep and Jitter configuration for ’Bing Search’ profile
Here we see the requests over time:
Sleep with jitter visualization, malleable C2 Bing search profile
Sleep with jitter visualization, malleable C2 Bing search profile
By adding timediff calculation between any two consecutive requests to make further analysis, we can see mostly values in the expected range.
Sleep with jitter data sample, malleable C2 ‘bing search’ profile
Sleep with jitter data sample, malleable C2 ‘bing search’ profile
Most of the values, as set in the predefined profile with sleep of 60sec and 20%jitter (12sec) that gives values in the range [48, 72].
Generally, when random values are generated many times, they form a uniform distribution. In this case, the number of values are the number of http requests during the attack session, while the random values are derived directly from the timediffs.
Looking on timediff distribution created by the profile (preprocessing of cleaning edge values is needed before hand) we can observe that as expected in random values — it forms a uniform distribution with values in the expected range:
Almost a uniform distribution of timediffs when jitter is applied
Almost a uniform distribution of timediffs when jitter is applied
The longer the session lasts, the more random values in the range are calculated and form a clearer uniform distribution. Distribution analysis leads to a detection of traffic with random sleep times which is a fingerprint of the jitter characteristic. Moreover, when recognized the sleep and jitter parameters can be calculated.
Distribution analysis can be done using ‘distribution tests’ which are hypothetical tests that determine whether a sample data (timediffs in our case) is drawn from a population that follows the hypothesized distribution (uniform distribution in our case).
A test statistic describes how closely the distribution of our data matches the tested distribution under the null-hypothesis of the statistical test used. In our case, we used both ‘Kolmogorov-Smirnov’ and ‘chi-square’ tests which yield satisfactory results.
Sleep with jitter configuration is considered a stealthier option. In trending frameworks such as Sliver, the jitter option is configured by default.
Sliver C2 – uses jitter by default
Sliver C2 – uses jitter by default
However, we found that traffic identified with jitter is more noticeable and less common within benign traffic.
Distribution of beacon-like patterns within benign traffic. Sleep without jitter (poll) - 8.25%; Jitter-like traffic – 3.95%
Distribution of beacon-like patterns within benign traffic. Sleep without jitter (poll) - 8.25%; Jitter-like traffic – 3.95%
The following profiles were extracted from the recent Cobalt Strike beacon samples, with low detection rate among different agents, both on sample hash and operator domain, and lead to variety of different communication profiles.
All the above are configured with non-default settings of SleepTime with Jitter.
The same approach can be taken towards data jitter analyzing download sizes distribution. Data jitter enables the operator to append a random length of null data up to the amount set creating again — uniformly distributed download sizes:
Data jitter configuration
Data jitter configuration
Usually, most of the GET requests in the session have the exact same size containing regular check-in for further commands (much like sleep time without jitter) but adding the data_jitter will cause a random-size request with uniform distribution of upload sizes within the http requests in session.
And more generally, this analysis can be used for every case of a large amount of randomly chosen property from a final property set.
URLs — and some more randomness
While using HTTP/s protocol to blend in, the requests should include some basic protocol headers, such as the URL. Different post-exploitation frameworks offer different URL configuration options. Some frameworks choose the URLs based on particular known URLs of a selected profile; others provide different methods for creating semi-random values, all trying to blend in the best way.
For example, a possible configuration in PoshC2 framework uses words from a large pre-defined word list to create the URL for each request.
Randomly concatenated words from ‘wordlist,’ which means that the whole URL string is not a completely randomized character string but includes meaningful words, and appears legitimate per request.
PoshC2 Wordlist
PoshC2 Wordlist
However, configurations that have high variations of URLs per request lead to a very high ratio of distinct URLs, as can be seen in the following logs.
PoshC2 traffic events. Generated URLs example
PoshC2 traffic events. Generated URLs example
Sliver C2 framework also offers randomness in URLs, building the final URL up to randomized number of path segments and their content:
Sliver URls default configuration
Sliver URls default configuration
Although randomness is a feature for better evasion and harder signing, it can be used in our favor, as randomness is not necessarily a natural behavior, especially when used excessively.
By analyzing benign traffic sessions, we can see that the ratio between the number of distinct URLs to total requests count during a session doesn't tend to be high.
URLs ratio histogram of benign traffic
URLs ratio histogram of benign traffic
‘Distinct URL per request’ configuration for a beacon client creates a distinct URL per request, which causes a very high ratio of distinct to total requests to the domain (ratio of ~1). The histogram above of benign traffic shows that a high ratio is not common within natural traffic behavior, which differentiates beacon traffic from benign traffic.
Conclusion and recommendations
In conclusion, even if initial security measures fail to recognize and block a beacon sample, the detection of beacon traffic during the post-exploitation phase remains crucial.
Our analysis demonstrates how patterns of randomness, often employed for evasion, can be leveraged to uncover the presence of such traffic. By focusing on these identifiable patterns, security professionals can enhance their detection capabilities and bolster their defenses against advanced threats.
For those responsible for safeguarding their organizations, it is imperative to integrate the discussed methods into their threat detection strategies. Employing threat hunting techniques to actively search for these indicators can significantly improve your organization's resilience against covert beacon activities.
Additionally, consider combining various detection features into more sophisticated algorithms that remain feasible and actionable within your operational environment.
By adopting these proactive measures, you can transform evasion tactics into opportunities for detection, ultimately strengthening your organization's cybersecurity posture. Stay informed, stay vigilant, and continue to evolve your threat detection strategies to counteract the ever-evolving landscape of cyber threats.
