Background
When attackers access a victim device and determine they want to run commands on that device in the future, they often install backdoor implants. A feature of these implants is the ability to beacon to an attacker's Command & Control (C2) server. Each beacon is a callback that tells the attacker the implant is still active and then retrieves and executes instructions assigned to the implant. One example of these instructions is tasking the implant to execute automated commands (such as changing the frequency of beacons, looking for information stored on the device, scanning the network for vulnerabilities, or attempting to exploit additional machines) and transmitting the results back to the C2 server. This workflow allows the attacker to operate asynchronously by assigning instructions to multiple devices, knowing they will be executed in the near future. Alternatively, when an attacker needs to interactively execute a series of specific commands based on quickly analyzing the results of previous commands, they can place an instruction on the C2 server for the implant to initiate a tunnel to the attacker's computer. This connection to the C2 server can occur over any protocol or even raw TCP/UDP; the remainder of this blog focuses on encrypted beacons over SSL/TLS.
Figure 1 Example of C2 Beaconing
Attackers want predictability for when the next beacon will occur. They expect to not wait too long between when the command is issued on the C2 server and executed on the compromised device, though they also hope that patterns in the callbacks do not draw the attention of security software or analysts. Backdoor implants such as Cobalt Strike help attackers achieve this balance by initiating beacons to C2 servers at a set interval (for example, every 4 or 24 hours) with some amount of jitter (random variation) in this interval; jitter was added to prevent security tools from identifying connections that occur at precise intervals.
Problem
The presence of an implant beaconing to a C2 server means an attacker compromised at least one device on your network and is able to remotely execute commands on the device. When analyzing connections over SSL/TLS, it can be difficult to differentiate between a computer legitimately accessing a HTTPS URL on a benign web server and a malicious C2 beacon. (This blog focuses on identifying C2 beacons over SSL/TLS with the assumption that we cannot decrypt the packets to read payloads.)
Detecting Known Beaconing Activity
FortiNDR Cloud Detections recognize when a single network connection – or a single packet – is clearly involved in malicious behavior. Expert systems involve aggregating multiple connections and calculating statistics (for example, counting the number of times an IP called back to a specific domain over the course of 24 hours) and applying a threshold to each aggregation to filter down to events. FortiNDR Cloud Observations occur when a trend is identified by analyzing more than one connection using either an expert system or a machine learning model. High-confidence Observations also result in the creation of a Detection to alert security analysts.
Each existing FortiNDR Cloud beaconing Detection recognizes the characteristics of a specific strand of malware. Detections identify when implants such as Cobalt Strike, Sliver, Mythic, and others beacon back to C2 servers.
An existing FortiNDR Cloud expert system identifies recurring, high-frequency SSL connections to a domain that – for each individual customer – only recently was visited by endpoints on the customer network.
SSL C2 Beaconing ML model
FortiGuard ATR supplemented FortiNDR Cloud's defense-in-depth strategy by training a new ML model to identify beaconing behavior. Twenty statistics are calculated for all SSL/TLS connections from each client device to the remote server; each statistic measures a different aspect of the connection, such as how regularly the device calls back to the server and if a recognizable jitter exists. These statistics are the features used to train the ML algorithm. The ML model learned the combinations of statistics that characterize when the underlying connections are indicative of long-term beaconing activity – with or without jitter.
Figure 2 - FortiNDR Cloud Obervations of SSL C2 Beaconing
Additional known behaviors of malicious actors are used to differentiate C2 beaconing events from both client computers surfing the web and custom APIs checking in with legitimate servers. The result is a successful application of AI that recognizes when a threat actor established a toehold on a defended network.
FortiNDR Cloud Provides Defense-in-depth
FortiNDR Cloud, Fortinet’s leading SaaS-based Network Detection and Response (NDR) solution employs a defense-in-depth strategy. In addition to detecting attempts to compromise devices, FortiNDR Cloud also identifies post-compromise behaviors such as lateral movement and C2 beaconing.
FortiGuard Labs Applied Threat Research (ATR)
The FortiGuard Labs ATR detection engineers develop detection rules that identify malicious behaviors found in individual streams and packets. When these methods are not sufficient to identify a specific behavior, the ATR Analytics team trains machine learning (ML) models to recognize complex patterns.
Learn More About the Fortinet Security Fabric Platform
SSL C2 beaconing is just one example of how FortiNDR Cloud can be used to enhance daily security operations and streamline detection and response processes. Learn more about the FortiNDR Cloud by visiting the webpage today, and to stay up to date on our threat coverage details subscribe to the FortiNDR Cloud Community Knowledge Base here.
