Detecting Command & Control beaconing with Sysmon and Splunk

 TL;DR

It's possible to detect short-haul, nearly interactive, C2 beaconing activity including remote access software such as TeamViewer or QuickAssist using Sysmon event id 3 combined with multiple Splunk stats search commands. That said the search can be tweaked to capture whichever beaconing interval or process scope you'd like to target and can be deployed as an automated correlation search rather than a point-in-time hunt.

Effective detection of command and control beaconing behaviour has always been difficult to perform at scale due to the shear volume of network data produced within an enterprise environment and its impact on search performance and rate of false positives, at least from what I've observed. Therefore, this type of detection typically is used in more of a targeted hunt scenario, maybe upon a host suspected of being compromised or as part of long tail analysis. 

I wanted to try to develop a search that could be deployed as a automated correlation search in Splunk without blowing up the SIEM with alerts. Gaining near real-time detection of this tactic based on the general behaviour of beaconing means that the blue team wins regardless of the implant and C2 framework used. 

Ok, let's get into the details...

In order to power this search, you'll need to be collecting all http & https egress traffic using Sysmon event id 3.  

A sample config could look something like this:

<RuleGroup groupRelation="or">
<NetworkConnect onmatch="include">
<DestinationPort name="All traffic on port 443" condition="is">443</DestinationPort>
<DestinationPort name="All traffic on port 80" condition="is">80</DestinationPort>
</NetworkConnect>
</RuleGroup>

Of course you'll need to choose a different destination port if your environment has a web proxy and you may decide to filter out known good processes with the understanding that processes can be spoofed or injected into which could introduce blind spots.

Now that you've got the required data, let's scope this detection based on the available threat intelligence. 

From all the data that I've seen and my understanding of short haul C2, the most popular interval is 60 seconds with some amount of jitter, around 5-25%. From an operator perspective this make sense because having to wait anymore than one minute makes it difficult to perform action on objectives unless many of the tasks are automated. I can see this interval being higher but only for more advanced adversaries.

Here is a screenshot of what this beaconing would look like in Splunk. Each minute there is anywhere from 1-3 events with no sudden spikes and this behaviour remains consistent over time, in this case two hours.

Based on the uptick in the use of Cobalt Strike we can look at which processes are likely to be used for C2. The default process would be rundll32.exe however there are many other options, most of which are binaries located in either C:\Windows\System32\ or C:\Windows\Syswow64. But maybe we also concerning about binary executing out of user land, C:\users\, C:\Programdata, C:\Windows\Temp or C:\Users\Public. I think this is a great starting point.

With the threat defined and the detection scoped, let's look at the Splunk search.

You can find a copy of this search here T1071.001/C2_beaconing in my Git repo. Please take a look at the comments as they contain the logic of what the intention of the search. This search should identify any beacon activity from 30 seconds to 75 seconds. Like with almost all searches, some processes will need to be ignored/allowed as they will exhibit C2 behaviour and therefore blind spots will be introduced as a result. It's important to develop analytics for these blind spots using either additional host or network data given processes can be spoofed or injected into causing this search to miss such malicious activity.

Would love to get feedback on this search and any incorrect assumptions or logic and I really hope you find this search useful in identifying processes of interest.