Raffi’s Abridged Guide to Cobalt StrikeMay 25, 2016
This blog post is a fast overview of Cobalt Strike. I assume that you are familiar with Meterpreter, Mimikatz, and make use of Offensive PowerShell in your work. This post does not replace the documentation or videos, but it’s a quick way to become familiar with Cobalt Strike concepts that are not immediately obvious.
Starting Cobalt Strike
Cobalt Strike ships as a client program and a server program. The server is the team server. The team server must run on Linux with Java installed. To start it:
$ ./teamserver [your IP address] [team password]
The Windows, Linux, and MacOS X packages for Cobalt Strike include a launcher to start the client. Launch the client, put your name in the user field, set everything else properly and press Connect. You’re up and running.
Cobalt Strike supports a concept of user-defined network indicators in its Beacon payload. This feature is Malleable C2. I do not recommend that you use Cobalt Strike with the default profile. Several example profiles are on Github. Use something from the normal folder. Specify the profile you want to use when you run your team server:
$ ./teamserver [your IP address] [team password] [/path/to/profile]
Cobalt Strike refers to its payload handlers as listeners. Go to Cobalt Strike -> Listeners. Press Add. Fill in the information for your team server host. The HTTP and HTTPS Beacon are straight forward to configure. You will want to read the documentation before you try out the DNS Beacon. Once a listener is setup, Cobalt Strike’s team server is listening for connections.
The First Foothold
“where are the exploits?” “how do I scan targets?” “how do I get that first Beacon on target?” Cobalt Strike is designed for engagements where you work as an external actor. It’s my assumption that you either have a foothold, through another means, or that you will gain one through a targeted attack. Cobalt Strike has tools to help with the targeted attack process.
Cobalt Strike has several user-driven attack options to get a foothold in a target
network. These options exist under Attacks -> Packages and Attacks -> Web Drive-by. Each of these features ask you to choose a listener. This is the payload the attack will deliver.
Metasploit Framework Exploits
Optionally, you may use a Metasploit Framework exploit to deliver Beacon. Pick a Windows exploit, point LHOST and LPORT at your listener, and set PAYLOAD to windows/meterpreter/[type of stager]. Cobalt Strike is compatible with Metasploit’s staging protocol. So long as you match stagers, this process should work. I recommend setting PrependMigrate to True as well.
The Beacon Console
When you get an access, right-click on it and press Interact. This will open the Beacon console. You will spend most of your time here.
Asynchronous Post Exploitation
Beacon is an asynchronous agent. This means commands you type will not execute right away. Instead, they go into a queue. When the agent checks in, Beacon downloads them, and executes them [mostly] in order. Beacon then presents output to you. In between check-ins, Beacon goes to sleep. Your Malleable C2 profile sets the default sleep time. The sleep command changes it.
Meterpreter users will feel at home with Beacon. The two have many commands in common. Type help to see a list of commands. Type help and a command name to get more information on a command.
The cd command changes Beacon’s current working directory. Don’t put quotes around the folder name (even if there are spaces). The shell command will run the command you specify with cmd.exe and present its output to you. The powershell-import command imports a local PowerShell script into Beacon. This command does not execute or check the script. Use the powershell command to evaluate your imported script and run the cmdlet and arguments you specify. The powerpick command does the same thing, but without powershell.exe.
Beacon does not have a migrate command. In general, you should not need this. Many post-exploitation tasks (e.g., screenshot, keylog) will inject into a process you specify and feed results back to your Beacon. Use the inject command to inject a Beacon into an x86 or x64 process.
Use the download command to download files. Downloaded files are stored on the team server. Go to View -> Downloads to see downloaded files. Highlight one or more files in this dialog and press Sync Files to bring files to your local system.
If you take screenshots or log keystrokes, be aware that Cobalt Strike presents these under View -> Screenshots and View -> Keystrokes. These windows will auto-update when there is new data.
Cobalt Strike has a few options to aid privilege escalation. The bypassuac command runs the Bypass UAC attack. Use this if your user is a local admin, but you’re in a medium integrity context. The spawnas command will let you use known credentials to spawn a session as another user. PowerUp works well with Beacon’s powershell and powerpick commands.
Once you elevate, use hashdump to recover local account password hashes. Type logonpasswords to harvest credentials with mimikatz. The mimikatz command will run arbitrary mimikatz commands. Credentials are available under View -> Credentials.
x64 vs. x86
It helps to match Meterpreter’s architecture to the native architecture of your Windows target. Many post-exploitation actions fail otherwise. This is not necessary with Cobalt Strike. Beacon executes some of its post-exploitation tasks in new processes. If a task is architecture sensitive, Beacon will spawn a process that matches the native architecture and inject the post-exploitation capability into it.
Cobalt Strike supports SOCKS proxy pivoting. Type socks [port] to create a SOCKS server tied you to your Beacon. Use sleep 0 to ask Beacon to speed up its communication. The SOCKS server runs on your Cobalt Strike team server. Connection requests and traffic sent through this SOCKS server are passed to the associated Beacon to take action on.
The portscan command runs Beacon’s built-in port scanner. Beacon’s net computers command maps computer accounts in the domain’s Domain Computers group to IP addresses. PowerView works well with Beacon’s powershell and powerpick commands too. Known host and service information is available under View -> Targets.
Access Token Manipulation
When you interact with a remote target through Beacon, Windows will use the credentials from your access token’s Logon Session or the contents of your Kerberos Tray to authenticate you. Cobalt Strike has commands to manipulate these items.
The steal_token command impersonates a token from another process. The make_token command creates an access token to pass the plaintext credentials you provide. The pth command creates an access token to pass the domain, username, and password hash you provide.
Confusingly, the make_token and pth commands will report your current username, regardless of the user you specify. This is not a bug in Cobalt Strike. This is a by-product of how Windows creates tokens to pass unverified credentials. The make_token and pth commands create a new Logon Session to pass the credential material you specify. They then attach the Logon Session to a copy of your current token. The Logon Session’s contents only affect interactions with remote targets. Your identity on the current system is still the same. This is why your token’s username does not change.
Cobalt Strike relies heavily on token manipulation for lateral movement and interactions with remote targets. These commands allow you to execute manual or automated lateral movement actions with a different identity.
Beacon commands for lateral movement include: psexec, psexec_psh, winrm, and wmi. Each command accepts a target and a listener name. The psexec command requires that you specify a share (it drops an executable to that share).
While these commands are nice, I tend to execute lateral movement steps by hand. I feel this gives more flexibility. Here’s my process: (1) Go to Attacks -> Packages -> Windows Executable (S) to export a stageless Beacon payload. Choose the right artifact for your lateral movement method. (2) Use the upload command to upload that artifact to Beacon. (3) Use shell copy artifact \\target\C$\whatever to copy the lateral movement artifact to your target. (4) Use at, schtasks, sc, or wmic through Beacon’s shell command to start the artifact on the remote target. (5) If you ran an SMB Beacon this way, use link [target] to assume control of it.
Named pipe Pivoting
The SMB Beacon uses named pipes to receive commands and route output through another Beacon. Named pipes are a Windows method for inter-process communication. Processes may communicate with other processes on the same system or on remote systems. Windows encapsulates remote process-to-process communication in the SMB protocol. This is why I call the Beacon that communicates over named pipes the SMB Beacon.
One Beacon may control multiple Beacons over named pipes. You may also use an SMB Beacon to control other SMB Beacons. Cobalt Strike users often chain Beacons together, multiple levels deep. Beacon’s SOCKS pivoting and other features work well, even through a deep chain.
The SMB Beacon is ideal for privilege escalation. Target an SMB Beacon listener with bypassuac, elevate, or spawnas and your new access will stage and communicate through your current Beacon.
This feature is also nice for lateral movement. It allows you to control systems that can’t or shouldn’t egress through an existing access in the target’s network.
Cobalt Strike -> Set Target View -> Pivot Graph draws a nice picture that depicts your named pipe pivot chain. This will help you understand which Beacons are linked to each other. This feature is indispensable for complex pivoting situations.
I’m a fan of agentless post-exploitation techniques to control hard targets (e.g., Invoke-Command, Invoke-WMICommand, and others). Cobalt Strike’s Access Token Manipulation capability and PowerShell integration makes Beacon a nice platform for these techniques. As you use Cobalt Strike, think beyond the commands built into Beacon. Native tools are a big part of Cobalt Strike’s offensive process.
Cobalt Strike logs everything on the team server. This logging happens regardless of whether a client is connected or not. To find the logs, go to the folder you ran the team server from. The logs live in a folder called logs. The logs folder is organized by date and then target. There are individual files for each Beacon session. Cobalt Strike saves screenshots and keystrokes here too.
Where to go from here…
This blog post is a quick orientation to Cobalt Strike. If you’d like to learn more, there are other resources. The product manual is kept up to date with each release. The 9-part Advanced Threat Tactics course is six hours of material on the concepts in this post. The Cobalt Strike Support page also documents individual features with most having a short demo video.