Beaconing Detection: How Attackers Stay Hidden

Introduction

Attackers, after an initial compromise, look to remain inside a network for as long as possible. For this, they use different methods. Beaconing is one of the common techniques used to maintain this access. Beaconing activity can easily blend into normal traffic and can remain unnoticed for long periods. Therefore, it is important for IT and security teams to understand how beaconing works in order to effectively carry out beaconing detection and response.

What a Beaconing Attack Is and Why It Exists

A beaconing attack is one in which malicious communication occurs between a command-and-control (C&C or C2) server and malware on an infected host. C&C servers are responsible for putting together many malicious activities, including ransomware, DDoS attacks, and data exfiltration.

As the host becomes infected, it periodically checks in with the C&C server on a regular schedule, and this is where the term beaconing comes from. The reason attackers depend on beaconing is its ability to maintain long-term control over infected systems while keeping communication small and easy to hide within normal traffic. In this case, the pattern differs from legitimate traffic due to the regularity of the intervals. However, beaconing on common ports and protocols obscures malicious traffic within normal traffic, helping the attacker bypass firewalls. Attackers sometimes use another evasion tactic, which involves waiting for long periods chosen randomly before communicating.

How Beaconing Shows Up During a Real Attack

Beaconing does not appear at the start of an attack. It always appears after the initial compromise. Once malware is installed, the infected host starts making outbound connections to the infrastructure controlled by the attacker. These connections have the following traits:

• They are small in size.
• These connections are repeated over time.
• They are sent to the same destination or a small set of destinations.

Communication occurs at fixed or semi-regular intervals, from every few minutes to hours. Each connection carries a small amount of data, such as system status or a request for instructions.

For a team that is monitoring the activity, here’s what they will see:

• Outbound traffic is sent from the same host multiple times.
• Connections that occur at the same time repeatedly.
• Every session has the same packet size.

In many cases, there won’t be any malicious activity right away. The beaconing continues quietly, with the attacker gathering more information to prepare for the next stage of the attack.

This quiet approach allows the attacker to maintain long-term access without triggering obvious alerts. It is very beneficial in environments where there is no strict monitoring of the outbound traffic.

How Beaconing Patterns Have Changed Over Time

In the past, malware was dependent on fixed and predictable beacon intervals. There would be some sort of contact between the infected hosts and the C&C server every few minutes or hours, with minimal variation. As a result, security teams would easily detect the malware by pointing out the regular timing patterns in network traffic.

With the improvement in detection techniques, attackers adjusted their approach as well. Now, malware doesn’t use strict schedules as much as it used to in the past. The use of random beaconing intervals has increased. In this, attackers add small variations between each connection, a technique known as jitter. This makes traffic look less mechanical. As a result, security teams can’t easily distinguish between malicious and legitimate activity.

Attackers have also increased the time between beacons. Some malware only checks in a few times a day or even less. Such a low frequency reduces the visibility of check-ins. Moreover, the threat remains active for extended periods without drawing anyone’s attention.

In some advanced cases, beaconing doesn’t depend on time. Communication only occurs on specific occasions, such as a system change or user activity. As a result, traditional detection methods based on intervals have become ineffective.

Normal Traffic That Often Gets Mistaken for Beaconing

Not every instance of outbound traffic that is regularly scheduled is malicious in nature. There are numerous legitimate applications that produce traffic patterns that greatly resemble beaconing. Because of this, timing alone cannot be used as a determining factor for identifying beaconing activity.

Below are some examples of normal outbound traffic patterns, which have been documented on numerous occasions:

• Software update mechanisms that periodically connect to vendor servers and retrieve any new versions or patches.
• Monitoring agents and endpoint management tools, which send periodic status updates to their respective management systems or consoles, at preset intervals.
• Cloud computing applications utilize application programming interfaces (APIs) to connect to the vendor's cloud services via polling methods to retrieve updated configurations and/or synchronization data.
• Backup applications, SaaS integrations, and other types of cloud-based applications can exhibit similar behaviors, in that they typically use the same types of communication protocols (HTTP or HTTPS) and the same packet sizes in order to communicate back and forth with one another. This can create a challenge for security teams and others to differentiate between normal and malicious traffic based solely on available data.

Because of how prevalent these types of periodic outbound traffic examples are in most enterprise networks, classifying all periodic outbound traffic as potentially harmful will generate an abundance of false positives. Hence, to effectively analyze the characteristics of beaconing activity, it is necessary to have some contextual understanding of both application and host behavior, rather than solely based on the regularity of the interval pattern.

Signals That Help Separate Beaconing from Noise

It’s not possible to identify beaconing only through timing. Many legitimate applications communicate at regular intervals, which is why additional signals are needed to reduce the noise.

• Interval consistency over time is a useful signal. Typical application traffic varies depending on the usage or status of the system, whereas malicious beaconing tends to maintain the same patterns of connection gaps over time.
• An additional indicator of beaconing is the repeated size of the requested payload. During an initial check-in, malicious beaconing tends to send several small, repeated requests in close succession.
• The destination pattern of repeated communications from one host to the same external IP address or domain, with no discernible purpose, raises a suspicion that the traffic may be part of malicious beaconing.
• Malicious beaconing usually happens without user activity or normal application events.

Seeing these signals together makes beaconing easier to confirm than looking at any single one on its own.

Where Beaconing Appears Across Network, Endpoint, and DNS Data

Beaconing activity doesn’t show up in just one place. Teams can get a clearer picture after viewing the activity across multiple data sources.

Beaconing is identified by the behavior of repetitive outbound connections from a single device to a limited number of external devices. These types of connections are typically of small to moderate size and occur with some degree of frequency at regular or semi-regular intervals, and sometimes will occur when there is no visible indication of activity occurring on the device.

From the perspective of endpoints, beaconing is associated with the activities of processes running on the endpoint. A background process may generate an almost continuous series of network connection requests without user interaction being required to initiate these types of requests. Some processes may be created from a location that is not the expected location of the executable or may continue to run after multiple reboots of the device.

DNS also provides an additional level of visibility into the ability to identify infected machines. Infected endpoints will frequently query the same DNS domains over and over or generate automated DNS lookups based on specific patterns. In many cases, an infected endpoint will contact a DNS domain that serves no legitimate business purpose.

Why Beaconing Detection Fails in Practice

The issues with beaconing detection are mainly related to the simplistic nature of its underlying algorithmic design. This design focuses solely on scheduling expected time intervals between events. However, as there are numerous legitimate applications that can have the same level of regular timing between events, these applications will add significant noise and therefore create a greater number of false positives.

Another common problem is the presence of encryption on user traffic over HTTPS or other encrypted transport protocols. When user data is transmitted using these secure connections, only the associated metadata is visible to the network for detection purposes. Therefore, it becomes difficult to separate the malicious or non-malicious traffic due to the lack of clarity between the metadata of encrypted communications. Attackers will typically use randomized delays, or jitter, in order to disrupt predictable timing intervals and make it harder to detect them through any rule-based methods.

Another common issue is the use of low-frequency beaconing behaviors. In these instances, short-lived intervals of monitoring can fail to capture malware behaviors that only occur a handful of times per 24-hour period. In addition, without the appropriate context regarding the endpoint and DNS data, beaconing alerts provide little information about their validity or intent.

How Attackers Hide Beaconing Activity

Attackers typically change their beaconing patterns on a regular basis to evade simple detection mechanisms.

One way attackers have modified their behavior is by randomizing their beaconing intervals. This means that attackers do not have a predictable schedule; instead, the malware causes the connection to be delayed for short and inconsistent periods of time. Attackers also attempt to reduce how often beaconing occurs, sometimes limiting communication to only a few times per day or less. This creates a very small time window for monitoring the activity, almost rendering it useless.

Beaconing traffic is sent through a common protocol, such as HTTPS, which makes it very difficult for users to inspect encrypted traffic. HTTPS traffic also makes the communication appear like a legitimate application talking to another legitimate application. It is common for malware to keep payloads small and repetitive, sending only the information required to send and receive a beacon signal.

In some cases of beaconing, beaconing activity has been linked to specific system operations rather than just being linked to time. This enhances the level of blending, where malicious activity occurs alongside normal system behavior.

How SOC Teams Should Validate and Measure Beaconing Detection

SOC teams should consider beaconing alerts as indicators of potentially suspicious activity rather than as isolated occurrences. To validate these alerts, analysts must confirm whether the activity persists over a longer period of time. A longer review period allows analysts to determine whether the beaconing behavior continues or changes over time.

After validating the alert, analysts will then correlate all the possible sources of information. For example, they will review the network traffic associated with the alert, along with what was observed on the endpoints and what the domain names were associated with those endpoints. Alerts will also be correlated with known applications, update services, or tools used by the organization, so they can be accurately recorded and suppressed.

Beaconing alerts should be evaluated based on their quality, not just how often they occur. In this way, as teams monitor the number of times that a beaconing alert leads to validation, they can also measure how long it took to validate an alert and how frequently tuning was required. If a detection generates a high volume of alerts but does not result in any action, then it is considered ineffective.

For beaconing detection to improve, there needs to be a continuous cycle of reviewing, adjusting, and measuring. All of this should be done as part of normal SOC operations.

Conclusion

The reason beaconing detection is difficult is that it can blend into normal activity. Regular traffic patterns and encryption make it difficult for simple detection methods to work. Additionally, low-frequency communication makes detection even more challenging. For reliable detection, teams need to focus on combining multiple signals, validating them over time, and acknowledging that tuning is an ongoing process. This is where SafeAeon can help, as their expert team treats beaconing as a process rather than a single alert. This helps the in-house teams gain better visibility and more actionable results.