Beaconing attacks can be difficult—but not impossible—to detect. The more you know about these stealthy attacks, the better you’ll be able to uncover and respond to them.
Command-and-control (C2) beaconing is a type of malicious communication between a C2 server and a suspicious program on an infected host. C2 servers can orchestrate a number of different nefarious attacks — for example, denial-of-service (DoS), ransomware, or data exfiltration attacks.
The goal of a beaconing attack is system access. To succeed, an attacker generates multiple data packets, known as beacons, over the network. Based on the attack type, these packets can contain malicious code or requests for data from the target system.
Beaconing attacks can be difficult to detect and respond to as they are sent in small chunks with multiple groups. Moreover, because adversaries can gradually expand access into a targeted system over time, they can remain undetected for longer periods of time.
Though traffic beaconing looks similar to normal network traffic, it does have some unique characteristics with respect to timing and packet size. Thus, it’s possible for organizations to use modelling, standard statistical, and signal organization techniques to detect beaconing.
Attack Scenario |
|
Group 1 |
Group 2 |
|
|
Description: Group 2 shows that the attack generates five (5) events per second. Between intervals, the sleep time is two (2) seconds. We have observed many types of beaconing attempts.
For each group of beaconing events, traffic will be blocked and then, it will be allowed at only one time.
| Source | Look for the same IP. In some scenarios, check for the same subnet of IP. E.g., 1.2.3.4 Subnet 1.2.3.5 | Total number of events between source and destination |
| Destination |
Destination_Address (Service)
URL
Domain
|
|
| AVG_Count_Events Per Second | Average number of events per second should be <=2 for each source to destination. |
If the average count of events is => 2, it is a non-human effort. In this case, check for pattern, bytes, destination, user agent, URL, target port, and total number of events.
|
| Pattern of Communication |
For each pattern of communication please hunt for how many such sets are getting generated.
For example, for each second, three (3) requests are generated, and 10 sets are observed for such transactions.
|
More sets mean it is easy to detect. If sets are random, it’s more difficult.
For example, 1,2,3 for each second 1 request generated with five (5) sets, but in between, other sets are coming.
Consider, three (3) event sets are generated every second, but in between, there is a random set of more than three (3) events.
3 (1) -- 2 (1) -- 4 (2) -- 3 (2)
3 sets (1event) -- 2 sets (1 event) -- 4 sets (2 events) -- 3 sets (2 events)
|
| Sleep Duration | It is a gap of two (2) groups that are generating similar pattern of events. | The longer the sleep duration, the more difficult it is to detect. |
| Bytes In / Bytes Out |
Hunt for scenarios:
1. The same number of bytes in as bytes out.
2. With a persistent number of bytes out or bytes in communication.
3. A progressive increase in bytes transaction.
|
Many devices don’t give byte information. In these cases, packet analysis is useful. |
Screenshot from BigQuery result
The impact of beaconing with circumvention of control can be severe. If attackers can beacon from a compromised system, they can infiltrate any potential payload to access sensitive data and information about the network. They can also use the compromised system as a launchpad for further attacks.
Beaconing attacks are difficult to detect because of the crafting of packets, frequency in which they can be modeled. One of the best ways to detect a beaconing attack is by analyzing a long trail of data so that threat hunters can uncover patterns of communications. Block the IPs and find all the suspicious communication from the Google Chronicle search window.
To learn more about new attacks and threats, visit Netenrich Knowledge Now and subscribe for daily threat news and alerts.
Rakesh Krishnan: Wed, Apr 03, 2024 @ 09:32 AM
This is a preliminary report based only on the data leak site (DLS), listed victims, and other observed patterns. A detailed investigation will...
Netenrich: Tue, Feb 06, 2024 @ 12:25 AM
As the first, exclusive pure-play Google Chronicle SecOps partner, Netenrich is 100% committed to the Chronicle SecOps and Mandiant technology stacks...
Rakesh Krishnan: Mon, Feb 05, 2024 @ 05:00 AM
This article focuses on my research to uncoverthe identity of Hunters International ransomware group’s (Surface Web) Dedicated Leak Site (DLS). It...
Rohit Sadgune