Here and there, I’m getting questions that are variants of this post’s title. The inquiry usually goes like this:
I do a lot of internal engagements. I don’t expect that I will always have a Beacon on target due to a phishing or client-side attack. How do I launch a psexec attack directly from the Cobalt Strike team server.
uLTRA tHANG 31337, Certified Professional Cyber Tester
I love these emails. First, the inquiry has a simple answer. Second, it’s an opportunity to explain Cobalt Strike’s model of offense. If you’re used to the Metasploit Framework or another penetration testing framework, it’s a little different.
Vulnerability Verification – It’s all about Modules
Many penetration testing tools offer a pile of offensive capability as modules on the attacker’s system. You either launch these modules directly from your system OR you tunnel these modules through a remote access tool.
This model has some benefits. Namely, the attacker’s system controls the protocol stack for each way it can interact with a target. This gives the attacker full control over these interactions and this is necessary for many memory corruption scenarios.
This model is fine and has few drawbacks for an internal actor working to quickly find and demonstrate the risk of misconfigurations and vulnerable services. If you do not need to pass through border defenses and try to evade an active defender, why would you care about operating “low and slow”?
Cobalt Strike’s Model of Offense
With Cobalt Strike, I always assume that you’re a remote actor with a foothold in your target’s network. I provide tools to help get this foothold, but post exploitation and lateral movement is when Cobalt Strike becomes really interesting.
The Cobalt Strike team server has no remote attacks or built-in offensive capability [with the exception of spear phishing]. Instead, Cobalt Strike pushes all of its offensive actions down to the Beacon payload. The Beacon payload then executes these things on your behalf.
This method of offense plays well with asynchronous communication. I can push a port scanner down to a Beacon and it will run in between check ins. Each time the Beacon checks in, it will communicate intermediate results to me. There’s no need to be in constant contact with my target to perform a scan.
Cobalt Strike’s capabilities to touch targets are built on native Windows APIs and not a third-party protocol stack. If I want to spread laterally, I use Windows APIs to create an access token from the credential material on hand and run my payload on a remote target. I don’t need to worry about whether or not my third-party SMB stack supports SMB signing and this environment requires it. Things just work. I can also task an asynchronous payload to perform these actions. I don’t have to speed up my communication and tunnel a capability through my foothold.
If your goal is to evade defenses and validate an organization’s detect and respond capability, asynchronous control of your targets is table stakes.
So, how do I psexec without an initial Beacon?
Let’s revisit the original question that drove this blog post in the first place. How do you perform Cobalt Strike’s offensive actions without a foothold from a client-side attack?
If you can touch targets and have trust material, then Cobalt Strike is a fine option to start with. Run a Beacon on a red Windows system that you control. Use make_token or pth to create a Windows access token with the desired trust material. Attack the targets you want to use as your initial footholds.