Archive for the ‘Cobalt Strike’ Category


Cobalt Strike 3.14 – Post-Ex Omakase Shimasu

May 2, 2019

Cobalt Strike 3.14 is now available. This release benefits the OPSEC of Beacon’s post-exploitation jobs. To take a screenshot, log keystrokes, dump credentials, or scan for targets: Beacon often spawns a temporary process, injects the capability into it, and receives results over a pipe. While Cobalt Strike has a lot of flexibility around launching temporary processes, it has had too few options for the actions that come next. This release changes that.

Malleable Process Injection, pt. 2

It makes sense to start this discussion with process injection. This is a key part of Beacon’s post-exploitation attack chain. The process injection code-path in Beacon is some of the oldest code in the payload and it was originally designed to “just work” in the myriad of corner cases this offense technique requires. These corner cases are not trivial. x86 -> x86, x86 -> x64, x64 -> x86, and x64 -> x64 in both suspended and not suspended processes are cases that a process-injection implementation needs to account for. The above becomes more complicated as some options fail across desktop session boundaries and others are riskier on older Windows XP-era systems. You can say “I don’t care about Windows XP”, and to some extent I don’t either, but Cobalt Strike’s Beacon circa 2012 had to cope with this.

Cobalt Strike 3.12 made some progress on process injection flexibility. This release picks up where 3.12 left off. Here’s what it looks like:

process-inject {
	# set remote memory allocation technique
	set allocator "NtMapViewOfSection";

	# shape the content and properties of what we will inject
	set min_alloc "16384";
	set userwx    "false";

	transform-x86 {
		prepend "\x90";

	transform-x64 {
		prepend "\x90";

	# specify how we execute code in the remote process
	execute {
		CreateThread "ntdll!RtlUserThreadStart";

Remote Memory Allocation

The process-inject -> allocator Malleable C2 option presents two paths to allocate memory within and copy data to a remote process.

The default VirtualAllocEx uses the venerable VirtualAllocEx -> WriteProcessMemory combination. The NtMapViewOfSection option has Beacon create a file mapping in the current process, copy the code to this local section, and map it into the remote process with NtMapViewOfSection. This option is limited to same-architecture target process (VirtualAllocEx is always the fallback).

Code Execution

3.14 also offers control over which techniques Beacon uses to execute code in a remote process and in which order it attempts them. This is done with the process-inject -> execute block. When executing code in a remote process: Beacon examines each option in the execute block, determines if the option is fair game for the current context, tries it if it’s relevant, and stops this process if code execution was successful.

Cobalt Strike’s options include:

  • CreateThread
  • CreateThread “module!Function+0x##”
  • CreateRemoteThread
  • CreateRemoteThread “module!Function+0x##”
  • NtQueueApcThread
  • NtQueueApcThread-s
  • RtlCreateUserThread
  • SetThreadContext

The CreateThread option is specific to self-injection.

The SetThreadContext and NtQueueApcThread-s options are specific to the temporary processes Beacon launches for its post-exploitation jobs. These functions take over the main thread of the suspended process and use it to execute the injected post-exploitation capability. The NtQueueApcThread-s option is Cobalt Strike’s implementation of the so-called Early Bird technique.

NtQueueApcThread, RtlCreateUserThread, and CreateRemoteThread are standard-issue options to inject code into a remote process. The RtlCreateUserThread option has an implementation variant for x86 -> x64 injection. CreateRemoteThread and RtlCreateUserThread both handle x64 -> x86 injection. All other options cover x86 -> x86 and x64 -> x64 injection.

CreateThread and CreateRemoteThread have variants that spawn a thread with the address fo another function, update the suspended thread to execute our code, and then resume the thread. This is useful to duck past techniques like Get-InjectedThread. Use [function] “module!function+0x##” to specify the start address to spoof. For remote processes, ntdll and kernel32 are the only recommended modules to pull from. The optional 0x## part is an offset added to the start address.

With the execute block, you may arrange these functions in an order of preference you’d like to use in your operations. It’s OK to omit or include options to tailor Beacon’s behavior to the adversary capability you’d like to emulate.

Revised Post-exploitation DLLs

Cobalt Strike 3.14 adds a post-ex block to Malleable C2. This block collects options to tweak the content and behavior of the post-exploitation jobs in Cobalt Strike.

post-ex {
	# control the temporary process we spawn to
	set spawnto_x86 "%windir%\\syswow64\\WerFault.exe";
	set spawnto_x64 "%windir%\\sysnative\\WerFault.exe";

	# change the permissions and content of our post-ex DLLs
	set obfuscate "true";

	# pass key function pointers from Beacon to its child jobs
	set smartinject "true";

	# disable AMSI in powerpick, execute-assembly, and psinject
	set amsi_disable "true";

Existing options such as spawnto_x86, spawnto_x64, and amsi_disable were moved to the post-ex block.

The obfuscate option scrambles the content of the post-ex DLLs and settles the post-ex capability into memory in a more OPSEC-safe way. It’s very similar to the obfuscate and userwx options available for Beacon via the stage block.

The smartinject option directs Beacon to embed key function pointers, like GetProcAddress and LoadLibrary, into its same-architecture post-ex DLLs. This allows post-ex DLLs to bootstrap themselves in a new process without shellcode-like behavior that is detected and mitigated by watching memory reads of the export address table in kernel32 and friends.

Blocking Vendor DLLs

Process injection does not exist in Windows solely to enable offense software. Some security products inject DLLs into user processes too. They do this to get deeper visibility into and veto power over the activities of the process. This is accomplished by hooking functions associated with common offense techniques.

Related: Google found that Chrome users were 15% more likely to experience a crash when injected code is present in the Chrome process space. Google decided to push back and block these DLLs from the Chrome process space. As an offense engineer, I thought it would benefit my processes if I could ALSO block these unwanted third-party DLLs from my processes. It turns out… this is possible.

Use blockdlls start and Cobalt Strike will launch child processes in a way that denies third-party DLLs access to the same process space. This is accomplished by running the process with a binary security policy attribute that restricts DLL loads to Microsoft-signed DLLs only. This is an option present in Windows 10 since late-2017.

Revised Process and File Browser Tabs

The 3.14 process browser now organizes the process information into a tree. Highlight a process in the tree and it will immediately highlight in the right-side detailed view of the processes. Your current process also shows in yellow. This is a lot easier than trying to follow a flat ps output and figure out which process is the parent of which process:

The 3.14 file browser is now (slightly) friendlier to Beacon’s asynchronous communication style. Each file browser now caches the folder/file listings it has seen. A tree on the left-hand side of the file browser shows which known folders are in the cache and which are not. Colored folders are in the cache. Grey folders are not. Click on an uncached folder in the tree and the file browser will ask Beacon to list that folder on its next check-in. In this way, you can revisit folders you’ve already seen, request multiple folders, and queue up multiple actions (e.g., download, execute, delete) in between Beacon checkins.

These changes should make post-exploitation a little more fun.

Check out the release notes to see a full list of what’s new in Cobalt Strike 3.14. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.


Cobalt Strike Team Server Population Study

February 19, 2019

From February 4, 2019 to February 15, 2019 Strategic Cyber LLC connected to several live Cobalt Strike team servers to download Beacon payloads, analyze them, and study the information within these payloads.

We conducted the survey from a system that exists separate of this company’s logs and records. The survey results were available on the same system. We did not use our logs or records to seed this survey.

We granted access to our survey system and results to a few parties we trusted. We did this to seek feedback on the data, process, and ideas for appropriate use. We also invited these parties to submit team servers for analysis as well. Unfortunately, one of those parties posted many domains from this system’s results to Twitter without our approval or knowledge. Some of these domains included red team infrastructure used by customers. While anyone could conduct the same survey, it was our system’s results that were used.

One of the top priorities at Strategic Cyber LLC is to not disclose or impact the red team operations or penetration tests of our customers. We see this aggregate and unapproved disclosure of domains, from our survey system, as undermining that goal.

The rest of this post details the survey process, what it extracted, and how to make your team server less visible to these types of analysis.

Why did we do this survey?

We conducted this survey as part of our continuous efforts to evaluate and improve our product controls.

How was the survey done?

We used techniques well-known in the blue community to identify Cobalt Strike team servers. We then connected to those servers to request a Beacon payload stage and analyzed its configuration and PE characteristics. We did not circumvent any technological measures to perform the survey.

What information does this analysis yield?

A lot of configuration information (necessary for the Beacon payload to function) is embedded in the Beacon payload DLL. Our analysis extracted hosts, URIs, User-Agents, and other behavior related configuration information. Our analysis also sought to identify: trial vs. licensed, authorization ID, version, and whether or not the product was altered in certain ways.

How did you find these team servers?

Here are the common techniques to identify Cobalt Strike team servers on the internet:

1) The Cobalt Strike product ships with a default SSL certificate for HTTPS communication. This self-signed certificate has no place in a live operation, but it’s still used in many Cobalt Strike deployments. One technique to find Cobalt Strike Beacon controllers is to search for the SHA-256 hash of Cobalt Strike’s default certificates:

2) Cobalt Strike’s DNS server (when it’s enabled) will respond to any request it receives with the bogon IP A search for DNS servers that respond to an arbitrary DNS request with this answer will find Cobalt Strike systems. It will also find non-Cobalt Strike systems as well. It’s a noisy indicator.

3) Search for systems with port 50050 open. This is the controller for Cobalt Strike’s team server.

4) Another technique is to look for 404 Not Found root page with empty content and a text/plain Content-Type. This is the default response of Cobalt Strike without a redirector or content explicitly hosted at /.

How was the payload stage requested?

As part of its feature set and workflows, Cobalt Strike hosts the Beacon payload stage on its built-in web server. Cobalt Strike is compatible with the Metasploit Framework’s staging protocol. Any HTTP request that has the proper checksum8 value will yield a Beacon payload. Our system makes a request for a payload in the same way a Metasploit Framework stager would.

Protecting your team server

The process we used for our survey is nothing new or unknown. If you’d like to reduce the visibility of your team server to these mass analysis studies, here are a few tips:

1) Do not use the default HTTPS certificate within Cobalt Strike. If your goal is to emulate a low-tier actor with a self-signed certificate—use the https-certificate Malleable C2 block to generate a self-signed certificate that supports your exercise narrative. If you have a live operation, use a valid SSL certificate with your HTTPS Beacon.

2) The is a well-known indicator of the DNS beaconing feature in Cobalt Strike. Use the dns_idle Malleable C2 option to change this to something else.

3) Edit the last line of the teamserver script to change the port from 50050 to something else. This is a very minimal measure. A better solution is to limit who can connect to this port with a host-based firewall.

4) If Cobalt Strike is hosting a Beacon payload stage, it will send payload stages in response to a valid request. This remains true, even if you configure the http-stager block in Cobalt Strike. The http-stager block reconfigures staging indicators within Cobalt Strike. It does not disable the compatibility with the Metasploit Framework. If you do not want Cobalt Strike to host a payload stage, set the host_stage Malleable C2 option to false. This option will require some changes to how you operate.

5) Use an Apache or Nginx web server as a redirector for your Cobalt Strike team server. Limit 80/443 connections to your team server to these redirectors. A properly configured redirector will smooth out indicators specific to Cobalt Strike’s web server (e.g., the JA3S fingerprint for SSL connections). A redirector is also an opportunity to serve legitimate content in response to non-staging and non-command and control URIs. The Red Team Infrastructure Wiki has advice on this topic.


Cobalt Strike 3.13 – Why do we argue?

January 2, 2019

Cobalt Strike 3.13 is now available. This release adds a TCP Beacon, process argument spoofing, and extends the Obfuscate and Sleep capability to the SMB and TCP Beacons.

TCP Beacon

Cobalt Strike has long had the ability to pivot over named pipes. Cobalt Strike 3.13 expands this peer-to-peer pivoting model with the TCP Beacon. Now, you can use the bind TCP Beacon as a target for privilege escalation and lateral movement. Like the SMB Beacon, you may disconnect from the TCP Beacon and reconnect to it from another Beacon (in the same Cobalt Strike instance) later.

Pivot Listeners in Cobalt Strike 3.13 are now stageless Reverse TCP Beacon listeners. You may bind a pivot listener from a Beacon session and export a stageless TCP Beacon artifact that connects to it.

Cobalt Strike’s SSH sessions have the ability to control TCP Beacon sessions too! Yes, you can now SSH into a pivot host and use it to resume control of a Beacon mesh.

Pivot Listeners for the Reverse TCP Beacon work from SSH sessions too, but with one caveat: the SSH daemon often restricts reverse port forwards to localhost only. You can change this with the GatewayPorts option in your SSH configuration. For those of you who use dropbear as a *NIX RAT (*cough*I know you’re out there*cough*), this is a nice added pivoting option.

Process Argument Spoofing

One of 2018’s must-watch talks for red teamers is Red Teaming in the EDR Age by Will Burgess. This talk discusses a few techniques for EDR evasion, to include: spoofing parent processes, process argument spoofing, and hiding in-memory. After Will’s talk, I opted to take a look at how to add process argument spoofing as a session prepping option in Cobalt Strike. Here’s what I came up with:

Beacon’s argue command allows you to add a command and a set of fake arguments to an internal list. When Beacon launches one of these commands [an exact match is required], it will launch it with fake arguments in a suspended state. Beacon then updates the process memory with the real arguments and resumes its execution. Tools that subscribe to new process creation events will see the old arguments. The child process will execute with the spoofed arguments. This technique is a way to push back on detections that look for malicious process arguments.

As usual, this isn’t the 100% works everywhere silver bullet for red teaming. This technique relies on reading and writing to memory in a remote process. That’s an indicator of badness.

This technique, as I’ve implemented, works x86 -> x86 and x64 -> x64. Also, this technique requires that the fake arguments are as long as or longer than the real arguments. And, finally, programs that determine process arguments by reading the process PEB will see your real arguments and not our fake arguments.

Still, this technique is another way to mask your activity when you absolutely need to run a process on target to get something done.

In-memory Obfuscation, Continued

I’ve long thought it would be cool to have a payload that could obfuscate itself in memory. This is a great way to push back on point-in-time analysis that look for static strings. Cobalt Strike 3.12 introduced this for the HTTP/HTTPS and DNS Beacon payload.

Cobalt Strike 3.13 extends this feature to the SMB and TCP Beacons too. Now, these Beacons will obfuscate themselves while they wait for a new connection. They will also obfuscate themselves while they wait to read information from their parent Beacon. In effect, these Beacons will spend a lot of time obfuscated.

To enable this behavior, set stage -> sleep_mask option to true in your Malleable C2 profile. For the cleanest in-memory experience, I recommend setting stage -> cleanup to true, and working primarily with stageless payloads.

Token Magic

The execute-assembly, net, portscan, and powerpick commands now use your current token. This release also updates the make_token command. It now stores your provided credentials within Beacon. Beacon will fall back to CreateProcessWithLogonW, using these credentials, when it does not have privileges to run the new process with your newly created token. This makes make_token largely usable from an unprivileged context.

Check out the release notes to see a full list of what’s new in Cobalt Strike 3.13. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.


Cobalt Strike 3.12 – Blink and you’ll miss it

September 6, 2018

Cobalt Strike 3.12 is now available. This release adds an “obfuscate and sleep” in-memory evasion feature, gives operators [some] control over process injection, and introduces hooks to shape how Beacon launches PowerShell.

Obfuscate and Sleep

One method to find adversary presence in an environment is to sweep all running processes for common strings that indicate offense activity. For example, a hunt for the ReflectiveLoader string will find memory-resident Reflective DLLs that don’t change the name of this exported function. Point-in-time analysis of memory is a powerful tool in the defender’s arsenal of capabilities.

To push back, Cobalt Strike 3.12 introduces obfuscate-and-sleep. This feature is exactly what it sounds like: Beacon is (mostly) a single-threaded beaconing agent. It requests tasks, executes those tasks, and it goes to sleep. Beacon spends most of its time sleeping. When obfuscate-and-sleep is enabled, Beacon will obfuscate itself, in memory, before it goes to sleep. When the agent wakes up, it will restore itself to its original state.

To enable obfuscate-and-sleep, set the stage -> sleep_mask option to true in your Malleable C2 profile.

stage {
	set sleep_mask "true";

This feature plays well with Cobalt Strike’s other in-memory evasion/threat emulation features. I recommend the use of Cobalt Strike 3.11’s cleanup option when sleep_mask is enabled.

Re: the SMB Beacon

The obfuscate-and-sleep feature benefits the HTTP, HTTPS, and DNS Beacon. The SMB Beacon doesn’t sleep in the way these agents do. This means the SMB Beacon will not obfuscate itself (it has no opportunity to do so). A future Cobalt Strike update may find a way to sneak this feature into the SMB Beacon too.

Malleable Process Injection

Process Injection is an important offense technique, used heavily throughout Cobalt Strike. This release gives operators control over how Beacon does process injection. This is done via the Malleable C2 process-inject block:

process-inject {
	# do not allocate anything less than this
	set min_alloc "16384";

	# permissions RWX, RX
	set startrwx "true";
	set userwx   "false";

	# fudge the content.
	transform-x86 {
		prepend "\x90\x90\x90";

	transform-x64 {
		# ...

	# we do not want to use this call.
	disable "CreateRemoteThread";

These options shape both the injected content and Beacon’s process injection behavior:

The min_alloc option specifies the minimum amount of memory Beacon will allocate in a remote process. The startrwx and userwx options give control over the initial and final permissions of the memory allocated in a remote process.

The transform-x86 and transform-x64 blocks pad any injected DLLs or shellcode. If you choose to prepend data, make sure it’s valid code for the specific architecture. There’s no check for this.

Finally, the disable verb asks Beacon to avoid certain API calls when doing its standard process injection routine. Right now, you can disable CreateRemoteThread, RtlCreateUserThread, or SetThreadContext.

More Power(Shell) to You!

Cobalt Strike uses PowerShell in a lot of its automation. The powershell command allows operators to execute arbitrary cmdlets. psexec_psh bootstraps a session on a remote target with a PowerShell one-liner. The spawnas command uses PowerShell to run a new session as another user.

While it’s possible to operate without PowerShell, sometimes a few adjustments are all that’s needed to safely use PowerShell in an environment. Cobalt Strike 3.12 introduces options to shape the PowerShell command-line and download cradle used in Beacon’s automation.

These options are in Cobalt Strike 3.12’s Resource Kit. Go to Help -> Arsenal to download it.

Notice: Certificate Change Over

The update infrastructure for Cobalt Strike is due for an HTTPS certificate change-over next week. After this change, the update program built into Cobalt Strike 3.11 and earlier will complain about the certificate change (and not download updates). Cobalt Strike 3.12’s updater is aware of the new certificate.

To continue to get updates, without interruption, download the latest Cobalt Strike Trial package with the updated updater. Your license key allows you to skip the trial request process. This action is recommended for all licensed Cobalt Strike users.

Check out the release notes to see a full list of what’s new in Cobalt Strike 3.12. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.


PowerShell Shellcode Injection on Win 10 (v1803)

May 24, 2018

Cobalt Strike’s process to inject shellcode, via PowerShell, does not work with the latest Windows 10 update (v1803). While it’s possible to work without this capability, a lot of CS automation uses PowerShell.

I’ve pushed an out-of-band update to Cobalt Strike 3.11 with a fix for this issue.

What happened?

The PowerShell shellcode injection scripts in Cobalt Strike use PowerShell internal methods that map directly to GetProcAddress and GetModuleHandle. The latest PowerShell build (included with the latest Windows 10) includes a second GetProcAddress mapping. This made my ask for GetProcAddress ambiguous. The fix? Refresh the PowerShell scripts to ask for a GetProcAddress binding with a specific signature.

Get the latest…

Use the built-in update program to get the latest. This out-of-band update includes a few other fixes and improvements as well. Check out the release notes for the full list.


Cobalt Strike 3.11 – The snake that eats its tail

April 9, 2018

Cobalt Strike 3.11 is now available. This release adds to Cobalt Strike’s in-memory threat emulation and evasion capabilities, adds a means to run .NET executable assemblies without touching disk, and implements the Token Duplication UAC bypass attack.

In-Memory Threat Emulation

One of the things that makes Cobalt Strike different is its ability to emulate multiple toolsets with one agent and one platform. Malleable C2 (2014) was the start of this. Malleable C2 focused on wire indicators because that’s what defenders could most easily observe. Today, wire indicators have their place, but defenders are just as likely to rip a DLL from memory to extract indicators and understand what they’re up against.

Cobalt Strike 3.7 introduced Malleable PE to give Beacon indicator flexibility in-memory. Cobalt Strike 3.11 takes this further.

1. Malleable C2 profiles now have the ability to specify the checksum, entry point, exported DLL name, and rich_header of the Beacon DLL.

2. This release also adds a peclone utility to Cobalt Strike’s Linux package. The peclone utility parses a DLL and reports a ready-to-use Malleable C2 stage block. This allows red teams to quickly extract and apply indicators from a malicious executable or DLL to Cobalt Strike’s Beacon.

3. The stomppe option controls whether or not Beacon’s loader stomps the MZ, PE, and e_lfanew values after loading. This option controls a common in-memory evasion tactic. Set this option to false and Beacon becomes a more obvious in-memory target.

4. Of course, flexible indicators have little utility without ground truth to give to the blue team. The Indicators of Compromise report in Cobalt Strike 3.11 now includes more information about the profiles used during the engagement. Each profile is presented as a unique “malware sample” with a summary of PE headers, contacted hosts, an HTTP traffic sample, and interesting strings.

Here’s the IOCs report with the HaveX Malleable C2 profile loaded:

In-Memory Evasions

February 2018’s In-memory Evasion course discusses heuristics to find injected DLLs in memory, explains why these heuristics work, and offers strategies to push back on these defenses. Cobalt Strike 3.11 adds more options to challenge and train defenders that use memory hunting techniques.

Less DLL, Please

One way to avoid detection as a memory injected DLL is to not look like an injected DLL at all (go figure). Cobalt Strike’s existing Malleable PE obfuscate option provides some help here. It masks Beacon’s import table and other fields in Beacon’s DLL. Cobalt Strike 3.11 takes this to the next level. Now, when obfuscate is set to true, Beacon’s Reflective Loader will situate Beacon in its new memory without bringing over any of its DLL headers.

Of course, the above raises a problem. It’s nice that the final Beacon DLL is better disguised. What about the memory that contains Beacon and its self-bootstrapping Reflective Loader? That package still has the MZ, PE, and e_lfanew values.

Set the cleanup option to true. This hint asks Beacon to release the memory associated with its loader. When this operation succeeds, your Beacon will live in-memory without the package that put it there.

Together, obfuscate and cleanup allow Beacon to live in-memory without content that screams memory-injected DLL.

Module Stomping

The above does raise another problem. What about the permissions of that memory? We still have pages with execute permissions that are not tied to a loaded module. These permissions exist in legitimate applications, but these properties are a warm flame that attracts the hunters from their cyber blinds.

Cobalt Strike 3.11 also adds module stomping to Beacon’s Reflective Loader. When enabled, Beacon’s loader will shun VirtualAlloc and instead load a DLL into the current process and overwrite its memory.

Set module_x86 to a favorite x86 DLL to module stomp with the x86 Beacon. The module_x64 option enables this for the x64 Beacon.

While this is a powerful feature, caveats apply! If the library you load is not large enough to host Beacon, you will crash Beacon’s process. If the current process loads the same library later (for whatever reason), you will crash Beacon’s process. Choose carefully.

In-memory .NET Assembly Execution

In Modern Defenses and YOU!, I advised that operators who depend on PowerShell should brush up on working without it. I also advised that payload developers, myself included, would do well to embrace the use of .NET assemblies in their platforms.

Cobalt Strike 3.11’s execute-assembly command makes good on this. This command accepts a path to a local executable assembly and runs it on the target in a temporary process. This temporary process benefits from all of your session prepping steps (e.g., ppid, spawnto, etc.). You may pass arbitrary arguments, quoted or not, to this program as if you ran it from a command shell. Scripters may build on execute-assembly with &bexecute_assembly.

This video demonstrates the Internal Monologue attack with help from execute-assembly:

Token Duplication UAC Bypass

But wait, there’s more! Cobalt Strike 3.11 adds a module that implements the Token Duplication UAC Bypass discovered by James Forshaw and originally weaponized by Ruben Boonen.

This UAC loophole allows a non-elevated process to use a token, stolen from an elevated process, to launch an elevated process of the attacker’s choosing. This loophole requires the attacker to remove several rights assigned to the elevated token. The abilities of your new session will reflect these restricted rights (e.g., you can’t interact with processes outside of your current desktop session).

This attack can bypass Always Notify. This requires that an elevated process is already running in the current desktop (as the same user). This attack also works on Windows 7 and later.

Use elevate uac-token-duplication [listener] to bypass UAC and get a session. This module does run a PowerShell one-liner to run a payload stager. Optionally, use runasadmin [command] [arguments] to bypass UAC and run an arbitrary command in an elevated context. The runasadmin command does not use PowerShell.

Check out the release notes to see a full list of what’s new in Cobalt Strike 3.11. Licensed users may use the update program to get the latest. A 21-day Cobalt Strike trial is also available.


Beware of Slow Downloads

March 9, 2018

I often receive emails that ask about slow file downloads with the Beacon payload. Here are the symptoms:

  • It takes multiple hours to grab a few megabytes
  • The sleep time makes no difference
  • File uploads are fast and not affected by this “slowness”

When I get these emails, I usually ask the user about their Malleable C2 profile. Malleable C2 is a technology to change the network and memory indicators for Cobalt Strike’s Beacon payload. In some cases, it can alter the tool’s behavior too.

I sometimes get a reply that the operator is using a custom profile derived from one of the Malleable C2 profiles on my Github repository. Inevitably, I’ll learn that the base profile is a profile that uses HTTP GET requests to download tasks from AND send data back to Cobalt Strike’s team server.

Cobalt Strike’s Beacon payload downloads tasks from its team server via an HTTP GET (or POST) request. The payload limits itself to 1MB of encrypted data per request. This is enough to download most task packages in one request.

By default, Cobalt Strike’s Beacon payload sends data back to Cobalt Strike’s team server with an HTTP POST request. In this default, the Beacon payload embeds its encrypted data into the body of the POST request. Here, the limit is again, 1MB. If you’re downloading a file, Beacon will deliver it in 512KB pieces. This 1MB limit is enough to send a 512KB file piece and some output in one HTTP POST request.

The default is what most Cobalt Strike users are used to and it’s the behavior most Cobalt Strike users expect when they use the HTTP and HTTPS Beacon payloads.

Cobalt Strike 3.6 extended Malleable C2 to allow operators to change where, in the HTTP request, Beacon embeds data it sends back to the team server. The default is still to embed data into the body of an HTTP POST request. But, you also have the flexibility to embed Beacon’s data into the URI, an HTTP header, or a URI parameter. You can also change the HTTP verb associated with this request too. This is amazing flexibility to put into an operator’s hands.

The above flexibility has consequences though. I can stick 1MB of data into the body of an HTTP POST request, no problem. I can’t stick 1MB of data into a URI, an HTTP header, or a URI parameter. That won’t work. What does Cobalt Strike’s Beacon do in these situations? Beacon chunks its output.

The chunker will divide any data, destined for the team server, into ~100 byte chunks. Each piece is sent back to the team server in its own HTTP request. This is where the behavior change comes.

I can send a 512KB file piece in the body of one HTTP POST request. That same file piece requires over 5,240 HTTP requests when divided into 100 byte chunks. Beacon does not make these HTTP requests in parallel. Rather, it makes one request, and waits for the response. It then makes the second request and waits for its response. This happens until all needed HTTP requests are made. The latency associated with each request is the thing that affects your download speed.

If you’ve seen this behavior in your use of Cobalt Strike, I hope this blog post helps clarify why you’re seeing it.