h1

SpecterOps acquires MINIS

November 1, 2017

Today, SpecterOps announces its acquisition of MINIS LLC. The company is doing its social media thing to spread the word. I wanted to take a moment to share the news and comment on it in my own words. If you want press release language, we have that too.

To evaluate an operation, military planners often discuss measures of performance and effectiveness.

Performance discusses the technical execution of the operation. How well did the operators adhere to the plan? How skillfully did they carry out the complex tasks asked of them? It’s quite possible to have perfect execution and fail to meet the objective of the operation. That’s why performance is one measure. Effectiveness is the other. Effectiveness is a measure of the success of the operation, overall.

In a highly technical role, like adversary simulations, it’s easy to lose ourselves in measures of performance. How many shells did you get? How many findings are there? Did we get DA? How evasive, scary, and cool is our malware? What kind of bypasses did we use? Our community is regularly abuzz with discussion of technical innovations. It’s good stuff.

There are too few voices discussing the big picture of red team operations and adversary simulations. How do we do this in a professional, safe, and repeatable way? How do these efforts directly benefit a program? How do we measure this benefit? This is the big picture “measure of effectiveness” stuff.

We care about this at SpecterOps. We don’t execute an engagement, write a report, and leave. We care about how to make this work have a lasting impact on our customers. We care about disseminating best practices to all.

And, that’s why I’m so excited about the MINIS LLC team joining SpecterOps.

Andrew Chiles, Derek Rushing, James Tubberville, and Joe Vest are skilled operators. All spent parts of their career with a Department of Defense red team. Today, they’re an important voice on the big picture topics related to red team operations and adversary simulations. How do we do this in an effective and impactful way?

Since MINIS LLC was founded, several firms sought them out to learn tradecraft and sharpen their red team offerings. This opportunity to influence expanded a great deal when James Tubberville and Joe Vest co-authored the SANS Red Teaming and Threat Emulation course. Their course focuses heavily on the big picture topics. MINIS LLC gets “threat emulation” and I’ve always seen them as a key ally, helping to drive these ideas forward.

They. Them. Not anymore! Us. I’m very excited to welcome Andrew, Derek, James, and Joe to SpecterOps. You’ve done so much under the MINIS banner. I’m very excited about what we’ll do together.

h1

Modern Defenses and YOU!

October 25, 2017

Part 9 of Advanced Threat Tactics covers a lot of my thoughts on evasion. The ideas in that lecture are still relevant, the defenses discussed there didn’t go away! That said, there are other defenses and realities offensive operators must contend with today. This blog post discusses some of these and provides tips for adjusting your operations.

Think Plausible

I used to describe host evasion as smuggling known bad (your payload and its stager) into memory. The real worry, after that, was egress. If you could get an agent into memory AND establish positive control of it, you were usually safe to operate.

Today, things are a little different. It’s no longer enough to control a process on a target and work. You have to think about the process you live in and the actions acceptable from it. notepad.exe (and for that matter, rundll32.exe) has no business phoning home to some controller on the internet. A savvy operator will hide their Beacon in a browser process or an updater for some application (*cough* jupdate.exe *cough*).

Infrastructure Matters

A successful call out doesn’t mean you’re safe. Some defenders watch for malicious infrastructure indicators. How old is that domain you phone home to? Is that site categorized? Have others from this same organization visited that domain? Techniques like domain fronting help here. Beacon, configured to only use HTTP GETs may look less like a C2 channel (especially when used with domain fronting).

Mind Your Processes

Still, a safe channel doesn’t buy you too much. Every process you launch is a risk. Why is cmd.exe a child of firefox.exe? Some defenders have the ability to ask this question. For the operator, the trick is to know your tools. Some commands launch a process. Others don’t. You should favor commands and actions that map to APIs, when possible. If you must launch a process, careful session prepping can help that action blend in.

Session prepping is configuring how Cobalt Strike’s Beacon payload spawns new processes and temporary jobs. Here’s how I session prep:

  1. Use the ps command to understand which programs are running. This command maps to an API.
  2. Use the ppid [pid] command to request that Beacon spoof the specified PID as the parent process for the programs it runs. explorer.exe is a personal favorite.
  3. Use spawnto x86 c:\path\to\program.exe to configure the x86 program Beacon should spawn for its temporary x86 jobs. Many Beacon post-exploitation actions spawn a temporary process, inject a capability into it, retrieve results, and kill the temporary process. spawnto x64 configures the x64 variant of this setting. Pick a plausible program.exe that fits well with your chosen parent process.

These steps do a lot to make your new processes (and post-exploitation jobs) blend in with normal activity.

Avoid Process Injection

The rabbit hole goes deeper though. It’s not enough to work only with APIs. You have to know which APIs are considered unsafe. Process injection stands out as an unsafe action. It’s helpful to know which commands do it and to know their alternatives.

For example, I often inject into a remote process to spawn a payload in another desktop session. An alternative is drop an executable to disk and use runu to run that executable as a child to a process in another desktop session. Same effect, except one depends on remote process injection, the other does not.

Do you absolutely need to run a Beacon command that injects into something? Inject into your current process. Beacon will treat this situation differently from a remote process injection. Beacon knows to use CreateThread instead of CreateRemoteThread (and other similar functions) in these cases.

If you need to discipline yourself to working this way: set the Malleable C2 option create_remote_thread to false. This will disable remote process injection in Beacon. Set hijack_remote_thread to false to disable Beacon’s method of process hollowing for its temporary jobs.

Avoid PowerShell

Other dangerous actions include any and all use of PowerShell. Once a major boon for offensive operations, PowerShell is now one of the most well instrumented technologies on the Windows platform (We love you Lee). If you depend on PowerShell for your operations, it’s time to brush up on working without it.

Many Beacon commands that use PowerShell have simpler primitives that don’t rely on it (e.g., spawnas -> runas, spawnu -> runu, etc.).

Some Beacon commands for lateral movement (winrm, wmi, and psexec_psh) use PowerShell too. Don’t don’t limit yourself to these. There are so many options for lateral movement, get creative!

Of course, I rely on a lot of PowerShell scripts to automate various offensive tasks. These same things would work well as .NET assemblies too. Payload developers, such as myself, would do well to embrace the use of .NET assemblies in their platforms.

In-memory OPSEC

All of this assumes you have an agent that safely resides in memory. That’s not a given anymore either. I think of host-based prevention technologies in terms of touchpoints. A traditional anti-virus product might look at my payload when I touch disk or load content in a browser. If I defeat that, I win. Not so today!

Now, the battleground is the functions we use to get our payloads into memory. Creating a new thread? Make sure its start address is tied to a loaded module, avoid RWX pages, and for the love of your favorite deity… don’t look like a PE file!

My advice to Cobalt Strike users?

  1. Ditch stagers, when you can. Their memory OPSEC is terrible. It’s possible to operate stageless with Cobalt Strike.
  2. Become familiar with the Malleable PE options I’ve added to Cobalt Strike. These, combined with stageless payloads, can land you in memory in a way that’s OPSEC-safe (in some instances).
  3. I also recommend x64 payloads on x64 systems. Functionally, an x86 and x64 Beacon do similar things. In reality, they take different paths to achieve the same results (especially when it comes to things like process injection).
  4. Avoid remote process injection. Process hollowing, in some cases, might be OK. Beacon uses a form of process hollowing for its post-ex jobs that depend on temporary processes.
  5. And, finally, remember… context matters. An unsigned executable may find itself subject to aggressive hooks and heuristics to detect malicious behavior. A signed executable may receive some extra leeway. An executable signed by a trusted entity may get a free pass altogether.

Closing Thoughts

Defenses are evolving and that’s a good thing. As blue TTPs gain ground, it’s on us to adjust our operations and find ways to challenge these TTPs. This is how both sides get better.

h1

Kits, Profiles, and Scripts… Oh my!

October 3, 2017

If I had to describe Cobalt Strike in one word, I’d say ‘flexible’. There are a lot of options to control Cobalt Strike’s features and indicators. In this post, I’ll introduce these options, explain the rationale for each, and point you to resources to explore them further.

Aggressor Script

Aggressor Script is Cobalt Strike’s built-in scripting language. It is the preferred way to add features to Cobalt Strike, override existing behaviors (kits take advantage of this), and automate your engagements.

Several public scripts add new workflows and features to Cobalt Strike. For example, CACTUS TORCH adds user-driven attack options to Cobalt Strike with x64 and stageless variations too. Tyler Rosonke wrote a script to add persistence options for Beacon.

Cobalt Strike also ships with a headless client, agscript, that connects to a team server and hosts an Aggressor Script for you. This client is designed for long-running bots. Common uses of headless Aggressor Scripts is to force DNS beacons to “check in” or notify an operator, via a text or email, that they have a new session.

If you’d like to dig deeper into Aggressor Script, jump over to the Aggressor Script documentation. I also regularly post Aggressor Script snippets as Github gists. Finally, Lee Kagan has created an Aggressor Scripts Collection that aggregates many of the publicly available scripts into one place.

Applet Kit

A kit is source code to a Cobalt Strike feature coupled with a script that forces Cobalt Strike to use your implementation over the built-in one. Kits give you control over the artifacts and processes that deliver the beacon payload.

The concept of kits in Cobalt Strike came out of necessity.

For a long time, Java Signed Applets and Java Applet exploits were a staple client-side attack option. In January 2013, I implemented Cobalt Strike-native versions of these attacks. The Smart Applet attack bundled several Java exploits into one package. The Java Signed Applet attack hosted a self-signed Java applet on Cobalt Strike’s web server. If a vistor let the applet run, it’d result in code execution for the attacker.

While the above options were great, at the time, my users needed an option to modify these attacks to evade detection. This is where the Applet Kit came in. The Applet Kit is the source code to Cobalt Strike’s Java Applet attacks. Included with the Applet Kit is an applet.cna script. When you load this script, Cobalt Strike uses your applet attacks instead of its built-in options.

The Applet Kit is available from the Cobalt Strike arsenal. This is a one-page site available to licensed Cobalt Strike users. Go to Help -> Arsenal from Cobalt Strike to reach it.

As Java in the browser became more constrained, Cobalt Strike users would often sign the built-in Java Signed Applet attack with their code-signing certificate. The use of a valid code-signing certificate kept this attack alive past its expected expiration date.

Artifact Kit

Introduced in January 2014, the Artifact Kit controls Cobalt Strike’s process to generate executable and DLL files.

The contract of the Artifact Kit is simple. Cobalt Strike provides shellcode and meta-information to a scripted function. The scripted function is responsible for returning an executable or DLL that runs that shellcode.

The Artifact Kit is also available from the Cobalt Strike arsenal. The arsenal hosts my implementation of the default artifacts in Cobalt Strike. A few variations are available in the Artifact Kit distribution as well.

To use the Artifact Kit: download the default implementation, make changes, build it, and load the artifact.cna script that registers itself to handle executable and DLL file requests in your Cobalt Strike.

Resource Kit

Many Cobalt Strike attacks and workflows take advantage of PowerShell, Python, and VBA scripts to get the job done. The Resource Kit controls the PowerShell, Python, and VBA script templates in Cobalt Strike.

Again, the contract here is simple. Cobalt Strike provides a registered script with shellcode, meta-information, and a description of what it wants. The registered script returns a script that executes the shellcode.

The Resource Kit is also available in the Cobalt Strike Arsenal.

Many Cobalt Strike users combine the Resource Kit with Invoke-Obfuscation to make Cobalt Strike’s PowerShell scripts much less obvious.

Elevate Kit

It’s a goal of Cobalt Strike to make it easy to combine your team’s “secret sauce” with the toolset. One spot where this comes together well is privilege escalation. Aggressor Script exposes APIs that allow scripts to register privilege escalation exploits with Beacon’s elevate command and Elevate Privileges dialog.

The Elevate Kit is a collection of public privilege escalation exploits integrated with Cobalt Strike via these APIs. The Elevate Kit demonstrates how to integrate Reflective DLL implementations of privilege escalation attacks from the Metasploit Framework. It also shows how to repurpose attack POCs implemented in PowerShell as well.

The Elevate Kit is hosted on Github. Load the elevate.cna script and you’re ready to go. Don’t be afraid to extend or add to the Elevate Kit. It’s pretty easy. During a recent cyber exercise, I was able to recompile a POC from Github as a Reflective DLL and fire it with Cobalt Strike. The entire process took less than 30 minutes.

Custom Reports

Cobalt Strike’s built-in reports are designed to convey red team activities and indicators to a blue team training audience. While the built-in reports are serviceable, it’s not well-known that you can write custom reports for Cobalt Strike too.

The Aggressor Script documentation covers Custom Reports and hosts the source code for the built-in reports too.

I’ve used this feature to generate variations of Cobalt Strike’s built-in reports, split up by IP address ranges, to give tailored information to the blue teams at a large cyber defense exercise.

External C2

I’ve had quite a few requests for third-party command and control options with Cobalt Strike’s Beacon payload. The External C2 specification (November 2016) was my answer to these requests.

External C2 documents how to control Beacon over a named pipe and provides a TCP/IP interface to configure an SMB Beacon stage, receive it, and relay traffic between the SMB Beacon and Cobalt Strike. How this traffic is transported and relayed is up to your imagination.

I never announced External C2 as a feature. I wrote the specification, implemented it, and distributed it to customers who requested this feature. I wanted to see what (if anything) these users would do with the specification.

The fine folks at Outflank B.V. were the first, that I know of, to build and use an external C2 with Cobalt Strike. They contacted me to share the success story from one of their engagements. They also asked if (and when), they could publish a blog post to share their code and document the feature. This led to the Cobalt Strike over external C2 – beacon home in the most obscure ways post on their blog. Their External C2 uses a corporate file server as a dead drop for communication between a hard-to-reach target and their Beacon controller. Their external_c2 source code is on Github too.

Shortly after Outflank’s post, MWR Labs posted their thoughts on External C2 and demonstrated a POC to control Beacon via Office 365 Tasks. In both cases, I’m very impressed and I find these first results encouraging. Needless to say, even though it’s not announced, the External C2 specification is public and is implemented as-described in Cobalt Strike today.

Malleable C2 Profiles

Malleable C2 profiles control the indicators and behaviors in the Beacon payload and its stagers. I consider Malleable C2 the most important technology in Cobalt Strike today.

I introduced Malleable C2 as part of Cobalt Strike 2.0 (July 2014). The first release of Malleable C2 controlled the indicators in Beacon’s HTTP communication. Malleable C2 made it possible to use Beacon, but look like the havex trojan or something completely innocuous.

Today, Malleable C2 isn’t just network traffic. Malleable C2 profiles control which SSL certificate Cobalt Strike uses. Profiles also specify the code-signing certificate used to sign executables and DLLs. Malleable C2 profiles have options to influence Beacon’s memory indicators too.

I very much intended Malleable C2 as a threat emulation technology, but it’s much more than that. I didn’t imagine domain fronting when I added Malleable C2 to Cobalt Strike. Yet, when this technique became known, Cobalt Strike was a go-to platform to take advantage of it. Today, I heard about a customer using the string replace feature (for Beacon’s stage) to alter how Beacon runs PowerShell scripts. Again, I wouldn’t have thought of that.

The Malleable C2 Profiles Github repository has several example profiles to start with. You can use one of these, but the barrier to making your own “never seen” profile is very low. I recommend reading the Malleable C2 documentation as well.

Closing Thoughts

Today, there are few things in Cobalt Strike that users don’t have direct control over. Through these tools you may add to Cobalt Strike’s features, modify behaviors that get in your way, change the files that deliver the Beacon payload, and edit the product’s indicators. As red team needs and tradecraft evolve, this flexibility is how Cobalt Strike keeps pace.

h1

Cobalt Strike 3.9 – Livin’ in a Stager’s Paradise

September 20, 2017

Cobalt Strike 3.9 is now available. This release brings several additions to Malleable C2 with an emphasis on staging flexibility.

Malleable HTTP/S Staging

Stagers are tiny programs that download the Beacon payload and pass control to it. Stagers are a way to use a size-constrained attack to deliver a large payload like Beacon. While I recommend working stageless, stagers are helpful in some situations. Wouldn’t it be nice if you could disguise staging to look like something else? That’s possible now.

This release introduces Malleable C2 flexibility into Beacon’s HTTP and HTTPS stagers. Cobalt Strike 3.9 profiles may modify the HTTP staging URI, add client headers, add URI parameters, and place arbitrary data before or after the encoded payload stage. Here’s the Malleable C2 profile for the above screenshot:

http-stager {
	set uri_x86 "/_init.gif";
	set uri_x64 "/__init.gif";

	client {
		parameter "key1" "value1";
		parameter "key2" "value2";
		header "Host" "yeah this works too";
	}

	server {
		header "Content-Type" "image/gif";

		output {
			prepend "\x01\x00\x01\x00\x00\x02\x01\x44\x00\x3b";
			prepend "\xff\xff\xff\x21\xf9\x04\x01\x00\x00\x00\x2c\x00\x00\x00\x00";
			prepend "\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x80\x00\x00\x00\x00";
			print;
		}
	}
}

And, here’s a recorded demonstration:

More Malleable C2 Features

While the HTTP staging gains the most flexibility in this release, 3.9 enhances Malleable C2 in other ways too.

The dns_stager_prepend option places a string before the encoded payload stage delivered via DNS TXT records. This offsets the content in this process and pushes back on signatures that target fixed TXT records in Cobalt Strike’s DNS staging process.

set dns_stager_prepend "v=spf1 mx include:_spf.google.com -all other:";

This release adds an obfuscate setting to the Malleable PE directives. This option masks the Beacon DLL’s import table. Together, the obfuscate setting and strrep (introduced in 3.7), give you a lot of control over which strings are visible in the Beacon stage.

stage {
	set obfuscate "true";

And, Malleable C2 gains a mask statement for its data transform blocks. The mask statement generates a random 4-byte value, masks your data with this value, and prepends this 4-byte value to the masked data. This last step makes it possible to reverse the mask step. The mask statement is interpreted and applied with each Beacon transaction. The mask statement makes it possible to randomize parts of your profile.

Authorization Files

The licensed version of Cobalt Strike 3.9 and later now requires an authorization file to start. The update program, distributed with the Cobalt Strike trial, downloads this authorization file.

The authorization file includes your license expiration date and a unique customer ID. Cobalt Strike 3.9 and later embeds this ID into the Beacon payload stage and any stagers generated by Cobalt Strike. This value is the last 4-bytes of the Beacon payload stager.

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

h1

Living the Ghost Life: Announcing Specter Ops, Inc.

July 10, 2017

Have you seen this cute ghost inside of a hexagon? The logo is for Specter Ops, Inc., a new cyber-security consulting firm. Today’s the company’s launch day. The press release is here. The website is here.

Today, Specter Ops, Inc. is 13 people who have given me technical guidance on Cobalt Strike, trained Cobalt Strike users, and made amazing contributions to the security community (to include open source projects and content Cobalt Strike users benefit directly from).

In terms of services: Specter Ops, Inc. has three focus areas: We offer adversary simulation services (red team ops), breach assessments (hunt), and adversary resilience assessments. The last one is particularly interesting. Resilience assessments help harden large Active Directory environments by identifying lateral movement vectors and measuring an organization’s adherence to the principle of least privilege. It’s good stuff. We offer assessments, staff augmentation, training, and program development in each of these areas.

The firm is new, but if you check out the team page, you’ll see there are several familiar faces. You’ll also note I said “we”. I have responsibilities at Specter Ops, Inc. as well. I’m the company’s President and my duties include: strategic guidance, mentoring, and starting conversations with “I remember when I was technical…”.

Day-to-day, I’m still in a Strategic Cyber LLC office space. I continue to argue with procurement people about contract details (yes, really), provide support to my users, and develop Cobalt Strike. This continues to happen under the Strategic Cyber LLC banner. Nothing’s changed here.

For Cobalt Strike users, this is exciting. Specter Ops, Inc. is an official “go to” for Cobalt Strike training and offers services that Strategic Cyber LLC never had the man-power to do. If you’d like engage Specter Ops, Inc., direct your queries to info@specterops.io.

I want to say thank you to each member of the Specter Ops, Inc. team. Thank you for taking the next steps of your career with this firm. I look forward to building an amazing company with you and I’m very excited for the things that will come next. I’m also very proud of all of you for pulling together this launch.

Onwards!

h1

OPSEC Considerations for Beacon Commands

June 23, 2017

A good operator knows their tools and has an idea of how the tool is accomplishing its objectives on their behalf. This blog post surveys Beacons commands and provides background on which commands inject into remote processes, which commands spawn jobs, and which commands rely on cmd.exe or powershell.exe.

API-only

These commands are built-into Beacon and rely on Win32 APIs to meet their objectives.

cd
cp
download
drives
exit
getuid
kerberos_ccache_use
kerberos_ticket_purge
kerberos_ticket_use
jobkill
kill
link
ls
make_token
mkdir
mv
ppid
ps
pwd
rev2self
rm
rportfwd
socks
steal_token
timestomp
unlink
upload

House-keeping Commands

The following commands are built into Beacon and exist to configure Beacon or perform house-keeping actions. Some of these commands (e.g., clear, downloads, help, mode, note) do not generate a task for Beacon to execute.

cancel
checkin
clear
downloads
help
jobs
mode dns
mode dns-txt
mode dns6
mode http
note
powershell-import
sleep
socks stop
spawnto

Post-Exploitation Jobs (Process Execution + Remote Process Injection)

Many Beacon post-exploitation features spawn a process and inject a capability into that process. Beacon does this for a number of reasons: (i) this protects the agent if the capability crashes, (ii) this scheme makes it seamless for an x86 Beacon to launch x64 post-exploitation tasks. The following commands run as post-exploitation jobs:

browserpivot
bypassuac
covertvpn
dcsync
desktop
elevate
hashdump
keylogger
logonpasswords
mimikatz
net
portscan
powerpick
psinject
pth
screenshot
shspawn
spawn
ssh
ssh-key
wdigest

OPSEC Advice: Use the spawnto command to change the process Beacon will launch for its post-exploitation jobs. The default is rundll32.exe (you probably don’t want that). The ppid command will change the parent process these jobs are run under as well.

Process Execution

These commands spawn a new process:

execute
runas
runu

OPSEC Advice: The ppid command will change the parent process of commands run by execute. The ppid command does not affect runas or spawnu.

Process Execution: Cmd.exe

The shell command depends on cmd.exe.

The pth and getsystem commands get honorable mention here. These commands rely on cmd.exe to pass a token to Beacon via a named pipe.

OPSEC Advice: the shell command uses the COMSPEC environment variable to find the preferred command-line interpreter on Windows. Use Aggressor Script’s &bsetenv function to point COMSPEC to a different cmd.exe location, if needed. Use the ppid command to change the parent process the command-line interpreter is run under. To pth without cmd.exe, execute the pth steps by hand.

Process Execution: PowerShell.exe

The following commands launch powershell.exe to perform some task on your behalf.

powershell
spawnas
spawnu
winrm
wmi

OPSEC Advice: Use the ppid command to change the parent process powershell.exe is run under. Be aware, there are alternatives to each of these commands that do not use powershell.exe:

  • spawnu has runu which runs an arbitrary command under another process.
  • spawnas has runas which runs an arbitrary command as another user.
  • powershell has powerpick, this command runs powershell scripts without powershell.exe.
  • It’s also possible to laterally spread without the winrm and wmi commands.

Remote Process Injection

The post-exploitation job commands (previously mentioned) rely on process injection too. The other commands that inject into a remote process are:

dllinject
inject
shinject

Service Creation

The following internal Beacon commands create a service (either on the current host or a remote target) to run a command. These commands use Win32 APIs to create and manipulate services.

getsystem
psexec
psexec_psh

h1

Cobalt Strike 3.8 – Who’s Your Daddy?

May 23, 2017

Cobalt Strike 3.8 is now available. This release adds features to spawn processes with an alternate parent process. This release also gives the operator control over the script templates Cobalt Strike uses in its attacks and workflows.

Processes with Alternate Parents

A favorite hunt technique is to instrument a host to report all new processes, their arguments, and the parent process. Hunt operators (and automated solutions) separate the noise from the interesting by looking for odd parent/child process relationships.

This release of Cobalt Strike pushes back on this technique with the ppid command. The PPID command tasks Beacon to launch cmd.exe, powershell.exe, and other processes with an alternate parent. This feature takes advantage of an API, introduced with Windows Vista, to enable consent.exe to launch elevated processes with the non-elevated requester as the parent.

This opens a lot of possibilities. For example, if I’m in a user context, I might set explorer.exe as my parent with something plausible (e.g, iexplore.exe) for my temporary processes. If I’m in a SYSTEM context, I might use services.exe as my parent process and ask Beacon to use svchost.exe for its temporary processes.

To benefit from the ppid command, your session must have rights to access the parent process. I also recommend that you specify a parent process that exists in the same desktop session. If you don’t, random commands and workflows may fail.

Another way to hop Desktop Sessions

It’s possible, with a few extra steps, to run commands under a parent that lives in another desktop session. Programs run this way will take on the rights and identity of their parent.

Beacon’s runu command runs an arbitrary command as a child of another parent. This command takes the necessary extra steps to do this across session boundaries.
The spawnu command builds on this primitive to spawn a session with powershell.exe.

These commands offer means to spawn a payload, in another desktop session, without remote process injection. As detection of remote process injection becomes more common, it’s important to have other ways to achieve our goals without this offensive technique.

The Resource Kit

Cobalt Strike 3.8’s Resource Kit finally gives you a way to change Cobalt Strike’s built-in script templates! The Resource Kit is a collection of Cobalt Strike’s default script templates and a sample Aggressor Script to bring these into Cobalt Strike. Go to Help -> Arsenal from a licensed copy of Cobalt Strike to download the Resource Kit.

The Resource Kit benefits from new Aggressor Script hooks to provide the PowerShell, Python, and VBA script templates Cobalt Strike uses in its workflows.

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