Effective C2 Beaconing Detection

A comprehensive set of signals is required and should include source, destination, and traffic characteristics such as SSL/TLS certificates used on both source (malware inside environment) and destination (C2 server), domain/IP/URL, source characteristics such as the user agent/process characteristics, traffic size/burstiness/patterns, HTTP headers/payload/URI, to name just a few.

When looking at various signals across time, volume, network layers, and overall traffic profiling, behavioral detection can provide a general and effective mechanism for detecting the latest malware via suspicious and malicious C2 beaconing activity.

Figure 6: Comprehensive Signals

There are several dimensions to the signal types:

• Network flow: source and destination attributes, as well as traffic patterns
• Network layers: different signals from layer 3 to 7 (anomalies across TCP/IP headers, SSL/TLS fingerprints, HTTP headers/payloads, and application-level content)
• Time: frequency, anomalous timing patterns to detect infrequent and slow activity
• Data: content and volume (anomalous packet sizes, bursts, cumulative stats)

Additionally, there are several signal types:

• Traffic pattern-based (volume, timing, content) including repeated beaconing in conjunction with unusual user agent or domain.
• Heuristics (e.g., suspect registrars or known malicious SSL fingerprints)
• Anomalies (unusual domain, user agents, or SSL fingerprints)

One important point is that some of the above signals are part of current approaches and existing solutions. This reinforces the point that a particular signal such as traffic spike (large volume) is neither good or bad, effective or ineffective by itself. Rather, the context and processing of the signal is the determining factor. When used at a network perimeter to block/allow traffic, a signal that is prone to false positives can cause severe operational problems. However, when fed into an anomaly detection system that incorporates that signal into a granular risk metric (discussed below) and a well-trained model, it can be extremely effective at detecting new threats in a robust manner with low false positives.

Effective detection of C2 beaconing from C2 framework toolkits requires machine-learning models based on a more comprehensive range of signals to identify today’s C2 framework toolkits and future suspicious network behavior that could indicate C2 activity.

Figure 7: Anomaly Detection

Anomaly detection should be based on models at the user/device, role, and organization level. That is, anomalies presume that we have a valid “normal” baseline of activity or behavior to compare against. Detecting suspicious activity can occur under different circumstances. There are anomalies based on a user’s actions vs their historical “normal” baseline or vs the organization’s “normal” baseline or vs the individuals in similar roles. All have their valid use cases that are exclusive of the others, and a good approach will incorporate multiple models with different scopes.

Training data sets should include both malicious and benign traffic:

• Malicious traffic can be simulated using general C2 testing tools, specific C2 adversarial beaconing tests based on publicly available configurations of C2 framework tools, as well as customized configurations from a red team perspective and official red team exercises.
• Benign traffic or valid traffic is best gathered from a significant number of actual users at real organizations over enough time to normalize against user and organizational biases.

Training datasets are the flip-side of testing datasets, and a lot of time should be spent analyzing and validating good training and testing data. Some of the factors in coming up with good testing datasets are discussed in a subsequent section.

The output of the anomaly detection is critical. The best approach does not perform simple block/allow or alert/silent determinations based on a raw signal, but instead tracks and adjusts fine-grained risk metrics at the user, role, and organization level, which can then be used for remediation actions such as alerting, coaching, or blocking.

This approach to tracking and acting upon risk is fundamentally different than what is typically used today. Most perimeter defenses that are preventative and typically block/alert on/allow traffic are generally static and prone to high false positive rates. The net result is that these solutions are enabled with a conservative policy to block certain and known risks, which then opens up a large number of false negatives. With firewalls, we see false positive problems with overly-aggressive block actions based on IP threat intelligence. With IPS solutions, we’ve been discussing the false positive challenges with static signatures trying to detect highly-configurable and dynamic C2 traffic.

But false positives at a perimeter layer can be very useful as a signal to a more intelligent layer. In this scenario, we would not use it for a binary assessment (allow/block, alert/ignore) but as a fine-grained risk metric adjusted over time (e.g. user risk score) with a tuned threshold before taking action. A granular risk metric, for example, a risk score of 1000 (no risk) to 0 (extreme risk) on a user or device or even IP address, allows us to model the spectrum of gray associated with real-world threats, where there are rarely clear 100% malicious or 100% benign assessments.

Conceptually, this is captured in the following illustration, where three different signals might be detected, which by themselves would be prone to false positives. However, when associated with incremental risk and evaluated by a tuned machine learning model, the same signals assess cumulative risk over time and ultimately deliver a high-confidence anomaly detection.

Figure 8: Granular Risk Metrics

Note that the signals in this example may not be as simple as static signals. For example, an “unusual domain unrecognized user agent and SSL/TLS certificate” could be an anomaly when compared against the past “normal” baseline of traffic for that specific user or against similar job roles of users or the whole organization. A “suspect registrar” may be an amalgamation of domain reputation correlated over time. And “periodic beaconing” is no longer a simple match of a fixed rate or duration, but instead can be detecting abnormal but regular and repeated activity within a time window that is similar to bot-related activity as opposed to valid application daemon callouts.

In practice, this allows us to adjust a risk score incrementally and appropriately based on a low-fidelity signal. It causes no blocking or alerting action until the cumulative risk score exceeds a tuned, high threshold. This allows us to capture cases where there are a lot of low-fidelity slightly risky indicators, which when combined with a higher-fidelity, higher-risk indicator for a particular user or device, cumulatively generates a critical risk alert and action with a drastically lower chance of false positives.

A new approach can theoretically be sound and in practice fail miserably, and the proof quite often comes down to data or testing. Vendors providing solutions and organizations looking for solutions require a robust approach to testing new threats and evaluating solutions. To achieve accurate results, it’s essential to test with a diverse dataset that includes both malicious and benign traffic.

Benign Traffic
Benign traffic should be realistic, comprehensive, and similar to production in terms of the number of users and activity. Good traffic, often user-dependent, should be studied across a large sample of users and a reasonable time period. This test dataset will measure false positive (FP) rates. The key variance in the datasets will be client signals such as the applications, user agents and client SSL/TLS certificates being used, destination signals seen in the destination domains/IP addresses, and traffic pattern signals in the headers, payload, size, and timing.

The good news is that good benign traffic is easily gathered from the day-to-day operations of the organization’s users, while the bad news is that it has to be validated as benign. The practical approach is to statistically sample the benign traffic to a certain reasonable confidence factor, then spend the majority of time focusing on the alerts from the C2 detection solution being tested, verifying the alerts as true positives or false positives. In other words, upfront sample and verify to form a baseline, assume the benign dataset is clean, then proceed to identify false positives based on testing.

Figure 9: Benign Traffic Testing

Malicious Traffic
Using public profiles from popular C2 framework tools provides a solid foundation for testing bad traffic. These profiles represent practical, frequently used configurations that evade defenses, and help measure false negative (FN) rates. However, a lot of consideration must be given to coming up with a representative “bad traffic” dataset, as there are potentially multiple levels to the coverage and what the datasets test, as illustrated in the following diagram:

Figure 10: Malicious Traffic Testing

1. Breach and attack simulation tools such as SafeBreach are excellent for coverage testing and repeated testing. Their C2 test cases typically include at least some simulation of C2 frameworks activity. The advantage is that a large breadth of functionality is available including general malware attacks, with well-designed GUIs and architectures, and repeatable testing procedures and reports. These tools can give you a breadth of scenarios including: low-slow activity, to IaaS/CSP infrastructure, HTTP and non-HTTP traffic to SSL/HTTPS traffic and spoofing of a variety of user agents.
2. C2 framework tools (public profiles). In-depth testing of C2 frameworks requires focused work. One approach is to create a test dataset based on the specific public profiles of C2 framework tools e.g., Cobalt Strike. These public malleable profiles tend to be shared widely and used by many users and malicious actors since they include useful emulations of benign applications such as gmail. This approach provides typically more comprehensive testing around the specific C2 frameworks.
3. C2 framework tools (custom profiles). Internal customization of the C2 Malleable Profiles can provide even more realistic testing of C2 frameworks. These custom configurations can be done during internal red team operations. This requires more work and investment as red team operators must be fluent in the C2 framework tools.
4. Realistic attacks. The most realistic testing involves black-box testing with external pen-testing or bug-bounty programs. In these scenarios, the requirements of the exercise are carefully constructed to require or incent actual POC exploits that use specific C2 framework tools or any C2 beaconing behavior, with caveats of avoiding detection over a period of time. The goals of the exercises are not only to test initial access vectors which is the norm, but to focus on post-breach activity by showing an ability to install a backdoor payload with demonstrated C2 activity. This enriches the test dataset beyond the C2 frameworks and can test backdoor POC code with custom C2 communications, and is also an excellent test of any detection tool’s resilience to a skilled “attacker” utilizing different or custom TTP.

Testing can involve some or multiple approaches, but there should be explicit choices made on how to create, gather, and validate the test datasets and how to measure expected outcomes. Creating and collecting the test datasets is very important so that testing can be automated and easily repeated.

It is also crucial to measure complete metrics during testing: true and false positives, true and false negatives. While collecting all metrics sounds obvious, being precise in definition and clear and repeatable in measurement methodology is difficult, leading to misleading results.

False Positive and False Negative Targets
With the new evasive threats created by C2 frameworks, any newer detection solutions will lack widely-accepted FP and FN rates. However, it is vital to create FP and FN targets. With known quality test datasets, baselines can be created for the current environment and users/devices, which then allows reasonable targets to be created, relative to those baselines.

For example, suppose an organization with only an IPS is starting an evaluation of new C2 detection solutions and it’s unclear what FP/FN rates are acceptable. The organization can still come up with reasonable targets by following a testing methodology such as:

• Create quality test data for benign traffic based on production data and malicious traffic based on for example, public C2 malleable profiles for Cobalt Strike, and by validating samples of those datasets manually.
• Create a clear, repeatable test methodology by defining testing and measurement tools.
• Measure all metrics (TP/TN/FP/FN) during testing
• Test new solutions and compare metrics. For example, the IPS could be tuned specifically for better TP rates for the malicious traffic, but ensure that FP/TN/FN rates are also measured and validated. Then the efficacy of different solutions can be properly evaluated, especially in the total impact to the organization as described in the Impact section below.
• Test new datasets and compare. Look to customize the datasets to reflect reasonable adjustments by an attacker. There are several ways to do this.
  • For example, when testing Cobalt Strike, its C2 Malleable Profiles can be easily modified to emulate benign apps a little differently or completely new benign apps that are used within the specific organization. This can be done with sniffing HTTP/S outbound traffic via a proxy.
  • Test not just one but multiple C2 framework tools, as they differ in capabilities and techniques. Using a different C2 framework tool is also a good change as its C2 traffic shaping will be different.
  • Creating a custom test payload with its own hand-coded C2 communications is yet another way to change the test datasets but requires the most time and investment.

Resilience Testing
By testing with new datasets across different solutions, we also gain valuable insights into the rigidity vs resilience of different solutions. In this paper, we have raised the issue that hard-coded and signature-based approaches are not only less effective for detecting C2 frameworks but they are also rigid, resulting in high FP/FN rates and allow easy bypass with simple attack changes, like malleable profile changes.

Resilience of any solution can be tested by ensuring that the datasets are modified within reason (i.e., staying within the same TTP category). In other words, we can perform a realistic resilience test by changing the C2 communications within the malicious traffic dataset using C2 malleable profiles and monitoring the TP/TN/FP/FN rates. We see how the coverage varies, and we also understand what changes in the detection solution need to be made to maintain coverage for particular TP/TN/FP/FN targets.

Retesting with changed datasets in this way is analogous to an attacker changing their TTP. It evaluates the resiliency and effectiveness of the new detection solution as we can see if it is still able to detect changes within the same threat technique category (C2 communications over HTTP/S).

False Positive and False Negative Impact
Measurement of FP/FN rates is good and allows for relative improvement, but we also need to measure or at least estimate the impact of FPS and FNs, otherwise it’s impossible to evaluate the true usefulness of any detection solution. In other words, a 1% FP rate or an improvement of 5% in the FP rate has no context unless we can measure the impact of that 1% or +5% in some way that makes sense to security budget decision-makers.

Here are two approaches that can help translate TP/TN/FP/FN rates into more quantifiable impact:

1. User impact over time: Look at the absolute number of false positives that are equivalent to the FP rates and normalize as a rate per user over time. This is a qualitative measure but often makes more sense than % rates or absolute numbers. For example, rather than 1% FPs or 2,437 false positives, it may be easier to assess impact from 0.1 false positives per user per day. If this were a secure web gateway, someone in the organization could make a determination of whether a certain FP target is acceptable based on the user impact over time. In this case C2 framework-enabled malware results in breaches, and the user impact is more characterized as downtime or data loss per user over a time period. We have a N% chance of $X loss per user every year. These are often rough estimates, but any start is useful as it can be revised and improved with regular iteration. If impact is assessed in terms of users over time, then it becomes easy to evaluate detection or protection solutions, which often are priced on the number of users per year.
2. Security Operations impact in terms of time, money, and breach probability. Besides end user impact, administrative impact should be assessed, particularly operations people who often spend time on handling detection alerts. The time spent on responding to noisy alerts can be translated directly into FTE salary cost. The additional factor of alert fatigue is a real impact that can be estimated in terms of efficacy (time to respond) and more importantly as the loss of time and attention to truly higher-impact threats that are lost or not investigated. This latter impact becomes a factor in breach impact–breaches are more likely to happen when security operations have too many false positives to investigate and delete.

An impact assessment is often the only way to understand crucial insights such as the true cost from detection efficacy. For example, an overly aggressive detection solution with a configuration of low FNs and high FPs is useless and harmful because security operations waste an inordinate amount of time responding to low-fidelity alerts instead of engaging in higher-leverage activities. Likewise, an overly conservative detection solution with low FPs but high FNs, exposes the organization to high risk for a potential breach, which can be unacceptable from an overall risk assessment view.

Impact should be estimated and assessed at the same time as core TP/FP/TN/FN metrics.

Realistic Testing

Red team with humans, not just automated breach or pen test tools. It is highly recommended to use not only production users and environments for testing C2 beaconing solutions, but also use realistic adversarial scenarios such as pen testing or bug bounties. By adjusting bounty amounts and requirements to show the explicit implantation and successful post-exploitation actions of popular C2 framework toolkits, we can make the “malicious traffic” real and measurable. This could be widened to any C2 beaconing activity including custom code to test resiliency of the detection solution, and the testing requirement should include demonstration of successful daily beaconing activity and command execution over a week, without detection.

If an external pen test or bug bounty program is repeated, the differences in detection rates will be measurable and useful for evaluating efficacy and ROI.

With a rigorous approach to testing, not only will testing efficacy be measured comprehensively, but ongoing targets and goals can be created relative to a current/historical baseline. And certainly, if the same testing and measurements are performed for multiple solutions, it is trivial to compare performance and make buying/implementation decisions.

Research and design involving these concepts and overall approach are discussed in more detail in: Security systems and methods for detecting malleable command and control (Mulugeta).