Beacon is Cobalt Strike's payload to model advanced attackers. Use Beacon to egress a network over HTTP, HTTPS, or DNS. You may also limit which hosts egress a network by controlling peer-to-peer Beacons over Windows named pipes.
Beacon is flexible and supports asynchronous and interactive communication. Asynchronous communication is low and slow. Beacon will phone home, download its tasks, and go to sleep. Interactive communication happens in real-time.
Beacon's network indicators are malleable. Redefine Beacon's communication with Cobalt Strike's malleable C2 language. This allows you to cloak Beacon activity to look like other malware or blend-in as legitimate traffic.
Right-click on a Beacon session and select interact to open that Beacon's console. The console is the main user interface for your Beacon session. The Beacon console allows you to see which tasks were issued to a Beacon and to see when it downloads them. The Beacon console is also where command output and other information will appear.
In between the Beacon console's input and output is a status bar. This status bar contains information about the current session. In its default configuration, the statusbar shows the target's NetBIOS name, the username and PID of the current session, and the Beacon’s last check-in time.
Each command that's issued to a Beacon, whether through the GUI or the console, will show up in this window. If a teammate issues a command, Cobalt Strike will pre-fix the command with their handle.
You will likely spend most of your time with Cobalt Strike in the Beacon console. It’s worth your time to become familiar with its commands. Type help in the Beacon console to see available commands. Type help followed by a command name to get detailed help.
Right-click on a Beacon or inside of a Beacon's console to access the Beacon menu. This is the same menu used to open the Beacon console. The Access menu contains options to manipulate trust material and elevate your access. The Explore menu consists of options to extract information and interact with the target’s system. The Pivoting menu is where you can setup tools to tunnel traffic through a Beacon. The Session menu is where you manage the current Beacon session.
Some of Cobalt Strike's visualizations (the pivot graph and sessions table) let you select multiple Beacons at one time. Most actions that happen through this menu will apply to all selected Beacon sessions.
Be aware that Beacon is an asynchronous payload. Commands do not execute right away. Each command goes into a queue. When the Beacon checks in (connects to you), it will download these commands and execute them one by one. At this time, Beacon will also report any output it has for you. If you make a mistake, use the clear command to clear the command queue for the current Beacon.
By default, Beacons check in every sixty seconds. You may change this with Beacons sleep command. Use sleep followed by a time in seconds to specify how often Beacon should check in. You may also specify a second number between 0 and 99. This number is a jitter factor. Beacon will vary each of its check in times by the random percentage you specify as a jitter factor. For example, sleep 300 20, will force Beacon to sleep for 300 seconds with a 20% jitter percentage. This means, Beacon will sleep for a random value between 240s to 300s after each check-in.
To make a Beacon check in multiple times each second, try sleep 0. This is interactive mode. In this mode commands will execute right away. You must make your Beacon interactive before you tunnel traffic through it. A few Beacon commands (e.g., browserpivot, desktop, etc.) will automatically put Beacon into interactive mode at the next check in.
Beacon's shell command will task a Beacon to execute a command via cmd.exe on the compromised host. When the command completes, Beacon will present the output to you.
Use the run command to execute a command without cmd.exe. The run command will post output to you. The execute command runs a program in the background and does not capture output.
Use the powershell command to execute a command with PowerShell on the compromised host. Use the powerpick command to execute PowerShell cmdlets without powershell.exe. This command relies on the Unmanaged PowerShell technique developed by Lee Christensen. The powershell and powerpick commands will use your current token.
The psinject command will inject Unmanaged PowerShell into a specific process and run your cmdlet from that location.
The powershell-import command will import a PowerShell script into Beacon. Future uses of the powershell, powerpick, and psinject commands will have cmdlets from the imported script available to them. Beacon will only hold one PowerShell script at a time. Import an empty file to clear the imported script from Beacon.
The execute-assembly command will run a local .NET executable as a Beacon post-exploitation job. You may pass arguments to this assembly as if it were run from a Windows command-line interface. This command will also inherit your current token.
If you want Beacon to execute commands from a specific directory, use the cd command in the Beacon console to switch the working directory of the Beacon’s process. The pwd command will tell you which directory you’re currently working from.
The setenv command will set an environment variable.
Last, but not least, Beacon can execute Beacon Object Files without creating a new process. Beacon Object Files are compiled C programs, written to a specific convention, that run within a Beacon session. Use inline-execute [args] to execute a Beacon Object File with the specified arguments.
Use the spawn command to spawn a session for a listener. The spawn command accepts an architecture (e.g., x86, x64) and a listener as its arguments.
By default, the spawn command will spawn a session in rundll32.exe. An alert administrator may find it strange that rundll32.exe is periodically making connections to the internet. Find a better program (e.g., Internet Explorer) and use the spawnto command to state which program Beacon should spawn sessions into.
The spawnto command requires you to specify an architecture (x86 or x64) and a full path to a program to spawn, as needed. Type spawnto by itself and press enter to instruct Beacon to go back to its default behavior.
Type inject followed by a process id and a listener name to inject a session into a specific process. Use ps to get a list of processes on the current system. Use inject [pid] x64 to inject a 64-bit Beacon into an x64 process.
The spawn and inject commands both inject a payload stage into memory. If the payload stage is an HTTP, HTTPS, or DNS Beacon and it can’t reach you—you will not see a session. If the payload stage is a bind TCP or SMB Beacon, these commands will automatically try to link to and assume control of these payloads.
Use dllinject [pid] to inject a Reflective DLL into a process.
Use the shinject [pid] [architecture] [/path/to/file.bin] command to inject shellcode, from a local file, into a process on target. Use shspawn [archicture] [/path/to/file.bin] to spawn the "spawn to" process and inject the specified shellcode file into that process.
Use dllload [pid] [c:\path\to\file.dll] to load an on-disk DLL in another process.
Use ppid [pid] to assign an alternate parent process for programs run by your Beacon session. This is a means to make your activity blend in with normal actions on the target. The current Beacon session must have rights to the alternate parent and it's best if the alternate parent process exists in the same desktop session as your Beacon. Type ppid, with no arguments, to have Beacon launch processes with no spoofed parent.
The runu command will execute a command with another process as the parent. This command will run with the rights and desktop session of its alternate parent process. The current Beacon session must have full rights to the alternate parent. The spawnu command will spawn a temporary process, as a child of a specified process, and inject a Beacon payload stage into it. The spawnto value controls which program is used as a temporary process.
Each Beacon has an internal list of commands it should spoof arguments for. When Beacon runs a command that matches a list, Beacon:
The effect is that host instrumentation recording a process launch will see the fake arguments. This helps mask your real activity.
Use argue [command] [fake arguments] to add a command to this internal list. The [command] portion may contain an environment variable. Use argue [command] to remove a command from this internal list. argue, by itself, lists the commands in this internal list.
The process match logic is exact. If Beacon tries to launch "net.exe", it will not match net, NET.EXE, or c:\windows\system32\net.exe from its internal list. It will only match net.exe.
x86 Beacon can only spoof arguments in x86 child processes. Likewise, x64 Beacon can only spoof arguments in x64 child processes.
The real arguments are written to the memory space that holds the fake arguments. If the real arguments are longer than the fake arguments, the command launch will fail.
Use blockdlls start to ask Beacon to launch child processes with a binary signature policy that blocks non-Microsoft DLLs from the process space. Use blockdlls stop to disable this behavior. This feature requires Windows 10.
The download command will download the requested file. You do not need to provide quotes around a filename with spaces in it. Beacon is built for low and slow exfiltration of data. During each check-in, Beacon will download a fixed chunk of each file its tasked to get. The size of this chunk depends on Beacon’s current data channel. The HTTP and HTTPS channels pull data in 512KB chunks.
Type downloads to see a list of file downloads in progress for the current Beacon. Use the cancel command, followed by a filename, to cancel a download that’s in progress. You may use wildcards with your cancel command to cancel multiple file downloads at once.
Go to View -> Downloads in Cobalt Strike to see the files that your team has downloaded so far. Only completed downloads will show up in this tab. Downloaded files are stored on the team server. To bring files back to your system, highlight them here, and press Sync Files. Cobalt Strike will then download the selected files to a folder of your choosing on your system.
The upload command will upload a file to the host.
When you upload a file, you will sometimes want to update its timestamps to make it blend in with other files in the same folder. Use the timestomp command to do this. The timestomp command will match the Modified, Accessed, and Created times of one file to another file.
Use the ls command to list files in the current directory. Use mkdir to make a directory. rm will remove a file or folder. cp copies a file to a destination. mv moves a file.
Use reg query [x86|x64] [HIVE\path\to\key] to query a specific key in the registry. This command will print the values within that key and a list of any subkeys. The x86/x64 option is required and forces Beacon to use the WOW64 (x86) or native view of the registry. reg queryv [x86|x64] [HIVE\path\to\key] [value] will query a specific value within a registry key.
Beacon's tools to log keystrokes and take screenshots are designed to inject into another process and report their results to your Beacon.
To start the keystroke logger, use keylogger pid x86 to inject into an x86 process. Use keylogger pid x64 to inject into an x64 process. Use keylogger by itself to inject the keystroke logger into a temporary process. The keystroke logger will monitor keystrokes from the injected process and report them to Beacon until the process terminates or you kill the keystroke logger post-exploitation job.
Be aware that multiple keystroke loggers may conflict with each other. Use only one keystroke logger per desktop session.
To take a screenshot, use screenshot pid x86 to inject the screenshot tool into an x86 process. Use screenshot pid x64 to inject into an x64 process. This variant of the screenshot command will take one screenshot and exit. screenshot, by itself, will inject the screenshot tool into a temporary process.
The screenwatch command (with options to use a temporary process or inject into an explicit process) will continuously take screenshots until you stop the screenwatch post-exploitation job.
Use the printscreen command (also with temporary process and inject options) to take a screenshot by a different method. This command uses a PrintScr keypress to place the screenshot onto the user's clipboard. This feature recovers the screenshot from the clipboard and reports it back to you.
When Beacon receives new screenshots or keystrokes, it will post a message to the Beacon console. The screenshot and keystroke information is not available through the Beacon console though. Go to View -> Keystrokes to see logged keystrokes across all of your Beacon sessions. Go to View -> Screenshots to browse through screenshots from all of your Beacon sessions. Both of these dialogs update as new information comes in. These dialogs make it easy for one operator to monitor keystrokes and screenshots on all of your Beacon sessions.
Beacon treats each shell, powershell, and keystroke logger instance as a job. These jobs run in the background and report their output when it's available. Use the jobs command to see which jobs are running in your Beacon. Use jobkill to kill a job.
Use socks 8080 to setup a SOCKS4a proxy server on port 8080 (or any other port you choose). This will setup a SOCKS proxy server to tunnel traffic through Beacon. Beacon's sleep time adds latency to any traffic you tunnel through it. Use sleep 0 to make Beacon check-in several times a second.
Beacon's HTTP data channel is the most responsive for pivoting purposes. If you'd like to pivot traffic over DNS, use the DNS TXTrecord communication mode.
You may use proxychains to tunnel external tools through Beacon.
Use socks stop to disable the SOCKS proxy server.
Use the rportfwd command to setup a reverse pivot through Beacon. The rportfwd command will bind a port on the compromised target. Any connections to this port will cause your Cobalt Strike server to initiate a connection to another host and port and relay traffic between these two connections. Cobalt Strike tunnels this traffic through Beacon. The syntax for rportfwd is: rportfwd [bind port] [forward host] [forward port].
Use the rportfwd_local command to setup a reverse pivot through Beacon with one variation. This feature initiates a connection to the forward host/port from your Cobalt Strike client. The forwarded traffic is communicated through the connection your Cobalt Strike client has to its team server.
Use rportfwd stop [bind port] to disable the reverse port forward.
Use the spunnel command to spawn a third-party tool in a temporary process and create a reverse port forward for it. The syntax is spunnel [x86 or x64] [controller host] [controller port] [/path/to/agent.bin]. This command expects that the agent file is position-independent shellcode (usually the raw output from another offense platform). The spunnel_local command is the same as spunnel, except it initiates the controller connection from your Cobalt Strike client. The spunnel_local traffic is communicated through the connection your Cobalt Strike client has to its team server.
Some post-exploitation commands require system administrator-level rights. Beacon includes several options to help you elevate your access.
Type elevate to list privilege escalation exploits registered with Cobalt Strike. Run elevate [exploit] [listener] to attempt to elevate with a specific exploit. You may also launch one of these exploits through [beacon] -> Access -> Elevate.
Use runasadmin, by itself, to list command elevator exploits registered with Cobalt Strike. Run runasadmin [exploit] [command + args] to attempt to run the specified command in an elevated context.
Cobalt Strike separates command elevator exploits and session-yielding exploits because some attacks are a natural opportunity to spawn a session. Other attacks yield a "run this command" primitive. Spawning a session from a "run this command" primitive puts a lot of weaponization decisions (not always favorable) in the hands of your tool developer. With runasadmin, it’s your choice to drop an executable to disk and run it, to run a PowerShell one-liner, or to weaken the target in some way.
If you'd like to use a PowerShell one-liner to spawn a session, go to [session] -> Access -> One-liner. This dialog will setup a localhost-only webserver within your Beacon session to host a payload stage and return a PowerShell command to download and run this payload stage. This webserver is one-use only. Once it's connected to once, it will clean itself up and stop serving your payload. If you run a TCP or SMB Beacon with this tool, you will need to use connect or link to assume control of the payload manually. Also, be aware that if you try to use an x64 payload—this will fail if the x86 PowerShell is in your $PATH.
Cobalt Strike does not have many built-in elevate options. Exploit development is not a focus of the work at HelpSystems. It is easy to integrate privilege escalation exploits via Cobalt Strike’s Aggressor Script programming language though. To see what this looks like, download the Elevate Kit. The Elevate Kit is an Aggressor Script that integrates several open source privilege escalation exploits into Cobalt Strike.
Use runas [DOMAIN\user] [password] [command] to run a command as another user using their credentials. The runas command will not return any output. You may use runas from a non-privileged context though.
Use spawnas [DOMAIN\user] [password] [listener] to spawn a session as another user using their credentials. This command spawns a temporary process and injects your payload stage into it. You may also go to [beacon] -> Access -> Spawn As to run this command as well.
Use getsystem to impersonate a token for the SYSTEM account. This level of access may allow you to perform privileged actions that are not possible as an Administrator user.
Another way to get SYSTEM is to create a service that runs a payload. The elevate svc-exe [listener] command does this. It will drop an executable that runs a payload, create a service to run it, assume control of the payload, and cleanup the service and executable.
Microsoft introduced User Account Control (UAC) in Windows Vista and refined it in Windows 7. UAC works a lot like sudo in UNIX. Day-to-day a user works with normal privileges. When the user needs to perform a privileged action—the system asks if they would like to elevate their rights.
Cobalt Strike ships with two UAC bypass attacks. These attacks will not work if the current user is not an Administrator. To check if the current user is in the Administrators group, use run whoami /groups.
elevate uac-token-duplication [listener] will spawn a temporary process with elevated rights and inject a payload stage into it. This attack uses a UAC-loophole that allows a non-elevated process to launch an arbitrary process with a token stolen from an elevated process. This loophole requires the attack to remove several rights assigned to the elevated token. The abilities of your new session will reflect these restricted rights. If Always Notify is at its highest setting, this attack requires that an elevated process is already running in the current desktop session (as the same user). This attack works on Windows 7 and Windows 10 prior to the November 2018 update.
runasadmin uac-token-duplication [command] is the same attack described above, but this variant runs a command of your choosing in an elevated context.
runasadmin uac-cmstplua [command] will attempt to bypass UAC and run a command in an elevated context. This attack relies on a COM object that automatically elevates from certain process contexts (Microsoft signed, lives in c:windows*).
Type getprivs to enable the privileges assigned to your current access token.
Beacon integrates mimikatz. Use the mimikatz command to pass any command to mimikatz's command dispatcher. For example, mimikatz standard::coffee will give you a cup of coffee. Beacon will take care to inject a mimikatz instance that matches the native architecture of your target.
Some mimikatz commands must run as SYSTEM to work. Prefix a command with a ! to force mimikatz to elevate to SYSTEM before it runs your command. For example, mimikatz !lsa::cache will recover salted password hashes cached by the system.
Once in awhile, you may need to run a mimikatz command with Beacon's current access token. Prefix a command with a @ to force mimikatz to impersonate Beacon's current access token. For example, mimikatz @lsadump::dcsync will run the dcsync command in mimikatz with Beacon’s current access token.
To dump hashes, go to [beacon] -> Access -> Dump Hashes. You may also use the hashdump command from the Beacon console. These commands will spawn a job that injects into LSASS and dumps the password hashes for local users on the current system.
The logonpasswords command will use mimikatz to recover plaintext passwords and hashes for users who are logged on to the current system. The logonpasswords command is the same as [beacon] -> Access -> Run Mimikatz.
Use dcsync [DOMAIN.FQDN] to pull password hashes for all accounts from a domain controller. This technique uses Windows APIs built to sync information between domain controllers. It requires a domain administrator trust relationship. Beacon uses mimikatz to execute this technique. Use dcsync [DOMAIN.FQDN] [DOMAIN\user], if you want a specific password hash.
Credentials dumped with the above commands are collected by Cobalt Strike and stored in the credentials data model. Go to View -> Credentials to pull up the credentials on the current team server.
The chromedump command will use mimikatz to [attempt to] recover saved passwords from the current user's Google Chrome.
Beacon has a built in port scanner. Use portscan [targets] [ports] [discovery method] to start the port scanner job. You may specify a comma-separated list of target ranges. The same goes for ports as well. For example, portscan 172.16.48.0/24 1-1024,8080 will scan hosts 172.16.48.0 through 172.16.48.255 on ports 1 to 1024 and 8080.
There are three target discovery options. The arp method uses an ARP request to discover if a host is alive or not. The icmp method sends an ICMP echo request to check if a target is alive. The none option tells the portscan tool to assume that all hosts are alive.
The port scanner will run, in between Beacon check ins. When it has results to report, it will send them to the Beacon console. Cobalt Strike will process this information and update the targets model with the discovered hosts.
Beacon's net module provides tools to interrogate and discover targets in a Windows active directory network. Use the net dclist command to find the domain controller for the domain the target is joined to. Use the net view command to find targets on the domain the target is joined to. Both of these commands populate the targets model as well. The net computers command finds targets by querying computer account groups on a Domain Controller.
Beacon's net module contains commands built on top of the Windows Network Enumeration APIs. These commands are direct replacements for many of the built-in net commands in Windows. There are also a few unique capabilities here as well. For example, use net localgroup \\TARGET to list the groups on another system. Use net localgroup \\TARGET group name to list the members of a group on another system. These commands are great during lateral movement when you have to find who is a local admin on another system.
Use help net to get a list of all the commands in Beacon's net module. Use help net command to get help for each individual command.
When a user logs onto a Windows host, an access token is generated. This token contains information about the user and their rights. The access token also holds information needed to authenticate the user to another system on the same Active Directory domain. You may steal a token from another process and apply it to your Beacon. When you do this, you may interact with other systems on the domain as that user.
Use steal_token [process id] to impersonate a token from an existing process. If you'd like to see which processes are running use ps. The getuid command will print your current token. Use rev2self to revert back to your original token.
If you know credentials for a user; use make_token [DOMAIN\user] [password] to generate a token that passes these credentials. This token is a copy of your current token with modified single sign-on information. It will show your current username. This is expected behavior.
Use mimikatz to pass-the-hash with Beacon. The Beacon command pth [DOMAIN\user] [ntlm hash] will create and impersonate an access token to pass the specified hash.
Use kerberos_ticket_use [/path/to/ticket] to inject a Kerberos ticket into the current session. This will allow Beacon to interact with remote systems using the rights in this ticket. Try this with a Golden Ticket generated by mimikatz 2.0.
Use kerberos_ticket_purge to clear any kerberos tickets associated with your session.
Once you have a token for a domain admin or a domain user who is a local admin on a target, you may abuse this trust relationship to get control of the target. Cobalt Strike’s Beacon has several built-in options for lateral movement.
Type jump to list lateral movement options registered with Cobalt Strike. Run jump [module] [target] [listener] to attempt to run a payload on a remote target.
|psexec||x86||Use a service to run a Service EXE artifact|
|psexec64||x64||Use a service to run a Service EXE artifact|
|psexec_psh||x86||Use a service to run a PowerShell one-liner|
|winrm||x86||Run a PowerShell script via WinRM|
|winrm64||x64||Run a PowerShell script via WinRM|
Run remote-exec, by itself, to list remote execution modules registered with Cobalt Strike. Use remote-exec [module] [target] [command + args] to attempt to run the specified command on a remote target.
|psexec||Remote execute via Service Control Manager|
|winrm||Remote execute via WinRM (PowerShell)|
|wmi||Remote execute via WMI (PowerShell)|
Lateral movement is an area, similar to privilege escalation, where some attacks present a natural set of primitives to spawn a session on a remote target. Some attacks give an execute-primitive only. The split between jump and remote-exec gives you flexibility to decide how to weaponize an execute-only primitive.
Aggressor Script has an API to add new modules to jump and remote-exec. See the Aggressor Script documentation (the Beacon chapter, specifically) for more information.
Beacon has a few other commands not covered above.
The clear command will clear Beacon's task list. Use this if you make a mistake.
Type exit to ask Beacon to exit.
Use kill [pid] to terminate a process.
Use timestomp to match the Modified, Accessed, and Created times of one file to those of another file.