background
CobaltStrike (CS) is a penetration testing device that uses a C/S architecture for distributed team collaboration. CS integrates port forwarding, service scanning, automatic overflow, multi-mode port monitoring, Windows EXE and DLL trojans, Java Trojans, Office macro virus generation, Trojan binding and other powerful functions, deeply loved by the majority of red team students. In order to avoid detection, red teams often use some hidden means to CS, such as cloud function and CDN. These stealth means conceal the real IP address of the CS. Traffic such as DDoS cannot penetrate the CDN to reach the CS, and conventional attacks cannot effectively interfere with and attack the CS server. Is that the end of it? Is there any counterattack against CS? Of course the answer is yes! Next, I will take you to experience a new method of batch forging broilers to play CS. I hope you will take this method as an example.
Analysis of CS online traffic characteristics
First of all, we first study whether the flow of CS online has characteristics. Figure 1 Wireshark was used to analyze the online packet of HTTP Beacon.
Figure 1
From the naked eye, the sensitive information of the online package is hidden in the Cookie, with very obvious characteristics. Through further analysis, we found that the request Cookie value of the online packet is the ciphertext of the controlled host metadata after asymmetric encryption, and the CS server decrypts the Cookie value after receiving it to obtain the controlled host information. The managed host metadata contains several sensitive information, as shown in Figure 2:
Figure 2
Here it is highlighted that the core of HTTP Beacon on-line package lies in Cookie, which is the asymmetric encrypted ciphertext of controlled host metadata.
HTTP Beacon replay experiment
As HTTP is a plaintext transmission protocol, there is a possibility of middleman replay in the on-line process of HTTP Beacon.
We ran a simple test to verify this possibility.
First, the HTTP Beacon online request in the test environment was captured, and the Python script (as shown in Figure 3) was used for replay (note: Header Header information should not be wrong, CS Server is very strict on Header check).
Figure 3
The result shows that the replay Response meets our expectation and CS Server successfully responds to our request. (See Figure 4)
Figure 4.
In addition, red team students will customize the Malleable C2 Profile to modify the default traffic characteristics when using CS, but this has no effect on the middle man replay.
New problems arise.
The man-in-the-middle replay method can only forge online hosts, not new controlled hosts.
Which translates to “no good for nothing.”
All right, that’s enough words. The book continues and comes to the point.
Now focus on the most pressing question: is there a way to fake brand new controlled consoles?
The answer, of course, is yes.
New host forgery
Let’s start with a rendering (see Figure 5).
Figure 5
A large number of hosts went online in a short time. Think about one minute online eight hundred hosts, the red team is not a little panic? How does this work?
Taking Stager Beacon as an example, we reviewed the CS on-line process from the perspective of attackers according to KillChain model (see Figure 6).
Figure 6.
The attacker uses CS Server to generate new Beacon listener (including a pair of asymmetric public and private keys) and generate Stager.
The attacker delivers Stager to the controlled host.
The controlled host performs a small Stager during the Exploit phase;
The controlled host downloads larger and more complex stages from the Beacon Staging Server to the local host according to the characteristics of THE Stager Url request. The Beacon Staging Server verifies the validity of the Url.
Stage decrypts and parses Beacon configuration information (such as PublicKey PublicKey and C2 Server information);
Stage encrypts host metadata through PublicKey PublicKey and sends it to C2 Server.
C2 Server decrypts data with private key to obtain host metadata.
From the above process, we can Get two core points:
Stager Url verification algorithm
Beacon configuration decryption algorithm
The problem of legitimate communication with CS Server is equivalent to the problem of obtaining Stager Url and Beacon decryption, namely:
CS/C2 Server legal communication = (Stager Url verification algorithm, Beacon decryption algorithm)
As long as we get (Stager Url verification algorithm, Beacon decryption algorithm), we have the credentials of legitimate communication with CS/C2 Server. We analyze the above two core points respectively.
Stager Url verification algorithm
The Stager Url verification algorithm can be found in the public NSE script. Key functions include checkSum8, MSFURI, and isStager.
The MSFURI function randomly assigns a character sequence of length from the character array of upper and lower case letters + numbers and calls checkSum8 function to calculate whether the ASCII and modulo of character sequence are equal to fixed values (32-bit Stage and 64-bit Stage use 92 and 93 as fixed values respectively). Returns a character sequence if equal, otherwise continues until a matching character sequence is found. MSFURI (FIG. 7), CheckSUM8 (FIG. 8), isStager (FIG. 9)
Figure 7.
Figure 8.
Figure 9.
If a qualifying character sequence is found, a download request is sent to the Beacon Staging Server as the Stager Url. The Beacon Staging Server verifies the Url validity in the _serve function, as shown in Figure 10.
Figure 10.
So far, we have obtained the verification algorithm of the Stager Url and manually downloaded the Stager. Download effect is shown in Figure 11:
Figure 11.
Very good! That’s half the battle. Next, we will study the decryption algorithm of Beacon configuration.
Beacon Configures the decryption algorithm
Thank our predecessors for planting trees!
Previous releases of decryption algorithms for Beacon configurations, such as JPCERT’s Volatility plugin Cobaltstrikescan (github.com/jpcertcc/aa…
The specific decryption algorithm is not described here, interested students can refer to the above open source tools. Decryption results are shown in Figure 12:
Figure 12
PublicKey and C2 Server addresses are displayed in the decrypted configuration.
OK! We have solved both algorithms, now it’s time to counter CS!
Fight back!
Everything is ready except the east wind!
Imagine the following scenario: the blue team gets a CS address while defending.
First, construct the Stager Url to download the Stage. If the Stage is captured at the same time as the CS online address, this step can be skipped.
Then, the configuration file of Stager Beacon was parsed and the PublicKey PublicKey and C2 Server address were obtained.
Finally, fake host metadata is constructed and encrypted and sent to C2 Server.
CobaltSpam, open source on Github (github.com/hariomenkel…
Finally, we achieved the desired effect by modifying the CobaltSpam code to add custom, more precise host information, as shown in figure 13.
Figure 13
The final effect is shown below (Figure 14)!!
Figure 14
conclusion
Through this method, the blue team students can be very good to confuse the red team students’ line of sight, in order to counter the attacker.
For low-level attackers, this attack is currently not well defended.
Also, the two algorithms mentioned above can be used for Beacon Staging Server and C2 Server mining.
At present, the way to defend against the above countermeasures can be to prevent fake host online and C2 mining by modifying the logic of the above two algorithms in CS code.
In the process of HVV, if CS Trojan samples or CS servers of the red team are found, we can use the above methods to confuse the sight of the red team students, delay their time, and let the red team students into the point of doubt about life.
【 Network Security Learning Materials Notes 】