Blog Post

Cutting through the noise: chaining activities to detect Cobalt Strike Beacon using Network Detection and Response Solutions


If you are reading this blog, you are likely aware of the widespread usage of Cobalt Strike as a post-exploitation toolkit. It is adversary simulation software leveraged by red teams and threat actors alike. For those of you who are unfamiliar, or simply want to learn more about it, I thoroughly recommend Mandiant’s overview of its capabilities. From a threat intelligence perspective, BlackBerry’s Threat Research team recently released a must-read book on mapping and identifying Cobalt Strike Team Servers based on observed characteristics. This blog will look at detecting the usage of Cobalt Strike using network detection and response solutions; delving into how we can chain events together that on their own may seem inconsequential, but when combined can reveal malicious activity typical of the software.

Detection strategy

The Arista NDR detection strategy places an emphasis on the identification of consequential artifacts over direct artifacts. To summarize, direct artifacts are those that the attacker has control over; consequential artifacts are those that are left behind by the standard operating procedure of technology. To draw a comparison with file execution on a Windows device: the name of a malicious file, its sha256 hash, or file path would be examples of direct artifacts; an entry being created in the shimcache for the purposes of version compatibility is a consequential artifact of the execution (most of the time).

This means we approach this detection problem by prioritizing the question “what artifacts must be created for bad activity to be successful?” over “what specific indicators of compromise (IOCs) can we find that are associated with a particular threat?” Attackers therefore cannot avoid detection by simply changing infrastructure. Whilst we do leverage the latter, it must be considered that such direct artifacts can become outdated very quickly or dynamically changed at the whim of an adversary.

Building blocks – detection logic

Based on data collected and analyzed during multiple incident response engagements undertaken by Arista’s Awake Labs Incident Response team involving Cobalt Strike, a common theme in lateral movement was observed. This involved an infected device creating and starting a remote Service to run malicious code on a target Windows device (lateral movement, execution), followed closely by the target device reaching out to the Team Server (command and control). This pattern of behavior occurs when Cobalt Strike’s default malware payload – Beacon – is used to establish an additional Beacon on another device in the network. In relation to the Service being created on the target, commonly the ‘Image Path’ or ‘Service File Name’ (what the service will run) will either be an executable file with a 7-character alphanumeric filename, or an encoded PowerShell script – which will typically decrypt and launch a payload (stager for Beacon) in memory. An example 7045 event, showing such a Service creation within the System event log, is shown in Figure 1.

Cobal Strike Beacon identification

Figure 1: System event log showing Windows Service creation indicative of Cobalt Strike Beacon

Stripping this back and looking at these events, there are two activities that must occur in order:

  • Service creation on a target device;
  • Connection to Cobalt Strike Team Server made by the target device.

Attempting to detect each of the above individually will generate a lot of false positives because remote Service creation is a common occurrence in Windows system administration, and looking at all suspicious domains to identify a Cobalt Strike Team Server is simply not practical.

We, therefore, asked ourselves how we could use Arista NDR’s adversarial modeling language to detect such consequential artifacts in sequence, rather than having a detection for each relatively innocuous item individually and tying them together (Figure 2).

Cobal Strike Beacon

The first link in the chain is the remote Service creation, so we first want to identify this activity. When a device attempts to create a Service on a remote Windows target device, it connects to the target on the SVCCTL DCE/RPC interface, allowing it to interact with the Service Control Manager. During this connection, an opnum must be specified. This is a numeric identifier for a method within the specified interface. In respect of the SVCCTL interface, any of the four below opnums are related to the creation of a Service:

  • 12: RCreateServiceW;
  • 24: RCreateServiceA;
  • 44: RCreateServiceWOW64A;
  • 45: RCreateServiceWOW64W.

The W represents UTF-16 and the A represents ANSI. UTF-16 characters are called wide characters, to distinguish them from 8-bit ANSI characters. Other than this, the definitions for each are the same:

  • Opnums 12 and 24 indicate creation of the service records in the SCM database.
  • Opnums 44 and 45 indicate creation of the service records for a 32-bit service on a 64-bit device with the path to the file image automatically adjusted to point to a 32-bit file location on the device.

These are searchable via Arista NDR because the platform parses the Service Control Manager Remote (MS-SCMR) Windows Protocol.

Based on previous experience with Beacon, we know that if this is successful, the target device will typically begin beaconing to the Team Server almost immediately. To look for evidence of connections to such a server, we can leverage Arista NDR’s domain analytics functionality to identify connections to domains that are suspicious. It is trivial within the platform to search for connections to domains with a risk score of at least ‘medium’ for this purpose. Once more, a search for such activity alone can generate a lot of results – there are a lot of suspicious domains out there!

Putting it all together – finding the bad

Now it’s about bringing these two links in the chain together. An obstacle here is that we are not looking to chain different activities on the same device, i.e., device A performs activity X, then activity Y. We are looking to chain different activity on different devices, i.e., device A performs activity X, then device B performs activity Y. The link in the chain is device B (Figure 3).

cobalt strike beaconKnowing this, we can use a function within Arista’s adversarial modelling language that allows us to take the IP address of the destination device from one activity and use it as the source IP address for a following activity as part of the detection logic. Thanks to this functionality, we can now build a detection that says: show me instances where a device creates a Service on a target device, followed within 10 seconds by the target device reaching out to a suspicious domain.

Figure 4 shows an example of this being used to detect Beacon being staged on remote devices during a recent incident response engagement (confidential items are redacted).

Cobalt Strike Beacon


By breaking down consequential artifacts that must be left behind as part of an attack kill chain, we have created an adversarial detection model that takes two innocuous activities and chains them together to detect malicious behavior. Since implementing this model, we have had 0 false positive detections, indicating this is a high-fidelity way to chain consequential, innocuous artifacts together to detect malicious activity, such as that involving Cobalt Strike Beacon. This detection strategy can also speed up the time taken to detect and respond to such incidents, due to the high fidelity and simple presentation of results cutting through the noise.


Thanks to Kevin Ekbatani for contributing to the research and blog post.



If you liked what you just read, subscribe to hear about our threat research and security analysis.

Kieran Evans
Kieran Evans

Threat Hunting and Incident Response Specialist