Hello everyone, I’m your lovely Miss lmn. Today, we’re going to explore some basic knowledge about Beacon. If you haven’t read the previous articles in this series, you can click the images below to read them.
Cobalt Strike, as a post-exploitation tool, enables reconnaissance, spear phishing, browser pivoting, and other attack techniques. In the previous article, we introduced that Cobalt Strike consists of a client and a server. The server side is called the Team Server. The Team Server acts as both the controller of the Beacon payload and the host providing social engineering functions in Cobalt Strike. It also stores collected data and log records. The working model is shown below:
One of the most frequently mentioned terms in Cobalt Strike tutorials is Beacon. Today, we will focus on introducing Beacon and Listener.
0x00 Introduction to Beacon
Beacon is the payload that Cobalt Strike runs on the target host. It operates over covert channels to provide services for long-term control of the compromised host. Its working mechanism is similar to the Metasploit Framework Payload. In actual penetration testing, we can embed it into executable files, attach it to Word documents, or deliver it through host vulnerabilities.
Beacon’s functionalities include:
1. Using HTTP or DNS to check for pending tasks
2. Connecting to multiple C2 domains
3. Automatically migrating after segmented transmission
4. Seamless integration with Cobalt Strike, delivering Beacon through social engineering, host vulnerabilities, and sessions
The term “Beacon” can be understood as a signal in the network, telling us: “Hey, I’m a compromised machine, I’m here…” We can refer to the diagram below to understand how Beacon works:
Once Beacon runs on the target host, it actively sends request information to the pre-configured Listener (Ding! A new host is online).
After receiving the request, the Team Server checks for pending tasks. If there are any, it delivers the tasks to Beacon.
One important concept to mention here is payload staging. Many attack frameworks use segmented shellcode to prevent excessively long shellcode from overwriting data in the previous function stack frame, which could cause exceptions. When discussing segmented shellcode, we must mention stagers. A stager is a small piece of code that connects to download the actual payload and injects it into memory. Using a stager helps solve the problem of long shellcode.
Cobalt Strike also supports segmented payloads:
Regarding the advantages and disadvantages of segmented payloads, this article will not discuss them. It’s like choosing between the chicken and the egg. The author of Cobalt Strike ultimately chose the egg, so… In versions after Cobalt Strike 3.5.1, you can restrict segmented payloads by adding the host_stage option in Malleable C2.
In Cobalt Strike 4, it is recommended to use unstage payloads as much as possible. This ensures security (since you cannot guarantee that the stager’s downloaded stage is not subject to a man-in-the-middle attack unless SSL is used like MSF). Additionally, if we are navigating through multiple proxies within an internal network, using a segmented payload could result in losing a Beacon if network transmission issues occur and the stage fails to load. Unstage payloads provide more reliability.
More references on staging:
https://cloud.tencent.com/developer/news/335831
https://blog.cobaltstrike.com/2016/06/22/talk-to-your-children-about-payload-staging/
https://blog.cobaltstrike.com/2016/06/15/what-is-a-stageless-payload-artifact/
Beacon has two communication strategies (communicating with the Team Server, which acts as the C2 in Cobalt Strike):
1. Asynchronous communication = In asynchronous mode, communication frequency is low, and speed is slow. As shown in the diagram above, Beacon actively requests a task list and then enters a SLEEP state.
2. Interactive communication = The C2 directly controls Beacon in real-time.
Plagiarism from Xue’s article?
0x01 Beacon Classification
Based on the built-in Listener, Beacons can be categorized as:
1. HTTP and HTTPS Beacon
2. DNS Beacon
3. SMB Beacon
The Listener is a Cobalt Strike module used to receive Beacon request information. This article only introduces Cobalt Strike’s built-in Listeners.
1. HTTP and HTTPS Beacon
HTTP and HTTPS Beacons are straightforward. The key point is that Beacon downloads tasks via GET requests.
It is important to note that the addresses entered in these two windows serve different purposes.
2. DNS Beacon
DNS Beacon is my favorite method, without a doubt. Cobalt Strike uses DNS to complete Beacon check-ins. If the DNS response indicates pending tasks, Beacon will use HTTP to retrieve the tasks. The specific mechanism is illustrated below:
It is worth noting that DNS Beacon now has two transmission methods (the second method uses TXT records). This topic will be covered in detail in a future article on DNS Beacon. Stay tuned!
0x02 Beacon Security
Imagine a scenario where someone hijacks your communication traffic and can monitor the data your Beacon sends back to the Team Server. What would happen?
The answer is: nothing would happen. This is because Beacon has multiple built-in security features (except for the fourth one):
1. The Beacon stage verifies the Team Server upon connection.
2. Beacon’s task requests and outputs are encrypted.
3. Beacon has replay protection.
4. Beacon stagers have no security mechanisms.
When you start the Team Server and create a Beacon Listener, the Team Server generates a public-private key pair to ensure the security of subsequent transmissions. Let’s take the segmented payload transfer as an example to explain Cobalt Strike’s security features in detail.
1. When the stager downloads the stage, the public key is also sent along with it:
2. When the Beacon stage is ready to check in, the first step is to send metadata about the beacon session. This metadata includes basic information such as the user, PID, computer name, and IP address. Additionally, the metadata contains a random session key generated by the Beacon stage. To ensure security, the Beacon stage encrypts the metadata (including the session key) using the public key. This means that only the Team Server can decrypt the data packet.
3. When the Beacon downloads tasks from the Team Server, the Team Server encrypts these tasks using the session key, and the Beacon stage decrypts the task list using the session key.
4. Similarly, when returning task results, the Beacon stage encrypts the task output using the session key.
As you can see, Raphael carefully considered security when designing Cobalt Strike, so… feel free to use it with confidence, wink~
0x03 Acknowledgments
This article references and modifies content from the following sources. Many thanks to the original authors.
Highly recommended: Snowming’s in-depth article on Cobalt Strike: http://blog.leanote.com/post/snowming/62ec1132a2c9
Exploring the Secrets Behind Metasploit Payload Modes: https://cloud.tencent.com/developer/news/335831
Out of the Blue: https://www.recordedfuture.com/identifying-cobalt-strike-servers/
Cobalt Strike Series 2: Listener and Payload: https://blog.csdn.net/weixin_42140534/article/details/104163391
SMB Beacon Setup and Use: https://www.youtube.com/watch?v=J3BEeIx6Xzk
Volatility Plugin for Detecting Cobalt Strike Beacon: https://blogs.jpcert.or.jp/en/2018/08/volatility-plugin-for-detecting-cobalt-strike-beacon.html
Analysis of Meterpreter Payload Execution Principles: https://xz.aliyun.com/t/1709/
Basic Functions and Usage of Cobalt Strike: https://www.jianshu.com/p/8d823adbc6b5