SSH Sessions

Cobalt Strike controls UNIX targets with a built-in SSH client. This
SSH client receives tasks from and routes its output through a parent
Beacon.

Right-click a target and go to Login -> ssh to authenticate with a username and password. Go to Login -> ssh (key) to authenticate with a key.

From a Beacon console: use ssh [target] [user] [password] to launch an SSH session from a Beacon. Use ssh-key [target] [user] [/path/to/key.pem] to authenticate with a key.

These commands run Cobalt Strike’s SSH client. The client will report any connection or authentication issues to the parent Beacon. If the connection succeeds, you will see a new session in Cobalt Strike’s display. This is an SSH session. Right-click on this session and press Interact to open the SSH console.

Type help to see a list of commands the SSH session supports. Type help followed by a command name for details on that command.

Running Commands

The shell command will run the command and arguments you provide. Running commands block the SSH session for up to 20s before Cobalt Strike puts the command in the background. Cobalt Strike will report output from these long running commands as it becomes available.

Use sudo [password] [command + arguments] to attempt to run a command via sudo. This alias requires the target’s sudo to accept the –S flag.

The cd command will change the current working directory for the SSH session. The pwd command reports the current working directory.

Upload and Download Files

The upload command will upload a file to the current working directory. The download command will download a file. Files downloaded with the download command are available under View -> Downloads. You may also type downloads to see file downloads in progress. The cancel command will cancel a download that’s in progress.

SOCKS Pivoting and Reverse Port Forwards

Use the socks command to create a SOCKS server on your team server that forwards traffic through the SSH session. The rportfwd command will also create a reverse port forward that routes traffic through the SSH session and your Beacon chain.

There is one caveat to rportfwd: the rportfwd command asks the SSH daemon to bind to all interfaces. It’s quite likely the SSH daemon will override this and force the port to bind to localhost. You need to change the GatewayPorts option for the SSH daemon to yes or clientspecified.