Effective C2 Beaconing Detection

To illustrate the challenges with IPS solutions, here is one of the Snort rules to detect the Zeus Trojan (Snort):

Figure 3: Snort Rule (Zeus Trojan)

Snort and many IPS solutions allow various matches of content or headers at layers 3 and 4, as well as at the application level as indicated by the action verbs in the rule. Many matches such as the content rule option are static byte/character matches, while the pcre rule option is a regular expression match.

When looking side-by-side at both the adversary side (e.g., the C2 Malleable Profile for gmail seen previously) and the the defensive side (e.g., the Zeus snort rule), the static hard-coded matching and fragility is clear. Imagine that an attacker had created and deployed a new Zeus variant that used Cobalt Strike and a Snort IPS had the above Zeus rule in place that effectively detected the new malware. The attacker could easily change one character in the profile, such as adding a space in MSIE to avoid matching: content:"|3B 20|MSIE|20|"; and the malware could evade the IPS signature.

While there is contextual awareness and state tracking, the IPS signature approach is inherently limited due to its static matching, which results in false negatives and easy evasion (literally changing one character in one field could bypass an IPS rule).

This is not to say that IPS solutions aren’t useful. Rather, IPS signatures should be retained, as they serve a useful perimeter defense, blocking many known network exploits in a quick and efficient manner. In this case, even if an IPS only achieved 60% detection rates, that 60% can be blocked/alerted on easily, avoiding costly downstream processing.

Other traditional approaches, such as the use of block lists (IP or URLs), are often applied in an effort to prevent the initial access or download of malware during web browsing, as well as to block potential C2 traffic.

A common challenge with block lists is that they are often out-of-date, causing false positives and are reactive in that they are updated post-compromise of target #1 or patient zero.

This is exacerbated by IP/domain indirection techniques used to hide the domain or IP address of the C2 server. Cobalt Strike has redirectors, which could be as straight-forward as IP proxies, to obfuscate the true domain or IP of the C2 server. There are also other techniques such as domain fronting using CDNs, or domain masquerading, that take advantage of TLS (SNI) vs HTTPS (host) mismatches to hide the final malicious domain from some URL security filters.

A different approach involves the use of heuristics, typically applied to network traffic patterns based on volume or time. The classic example is to detect regular outbound communication (e.g., every 60 minutes), perhaps to an IP address with no registered DNS A record.

To evade detection, C2 framework toolkits allow easy configuration of a random factor in the beaconing delay by use of the jitter setting in a Cobalt Strike Malleable Profile:

Figure 4: C2 Malleable Profile Settings (beaconing timing)

These settings specify a call-home interval of 60 seconds +/- 15%, which means the actual interval will range from 51 to 69 seconds, evading simple checks for recurring beaconing at constant intervals.

The problem with current approaches is that they do not effectively detect malleable C2 communications and are easily evaded even if specifically tuned. They do serve a purpose in efficiently detecting attack techniques that are static with well-known indicators, but miss more dynamic or sophisticated attacks or create a large number of false positives.

As one data point, when testing the most common Cobalt Strike C2 Malleable Profiles from public repos, out of the box IPS solutions such as Snort and Suricata detected substantially less than 20% of the C2 communications from the most common C2 framework toolkits.

Even after specifically adding rules to match as many of the public profiles as possible, optimizing for this specific test, coverage could only increase reasonably to ~60% without introducing significant false positives that would be very problematic in a production environment.

There are numerous problems with efficacy: not only higher false positives, but also the resulting configuration is rigidly constructed for the specific test in question, and is easily evaded by slight tweaking of the profiles. And at the end of the day, there are still ~40% of the profiles which remain undetected, which is a very high false negative rate. Not to mention the additional false negatives from a determined attacker who customizes the C2 profiles to mimic existing well known applications in a slightly different way.