User-driven AttacksOctober 1, 2014
A user-driven attack is an attack that relies on a feature to get code execution. Most penetration testers I know rely on user-driven attacks over public memory corruption exploits. User-driven attacks are less likely to see a patch and they usually target an application in a way that works across many versions. What’s not to like?
Cobalt Strike offers several user-driven attacks. In this post, I’ll give you a quick tour of what’s available. These are my options to help you get a foothold.
This attack combines a payload stager and a document into an executable. When run, this executable drops the document to disk, opens it, and silently loads your payload. This attack is low on the sophistication scale, but it’s very common in targeted attacks. To help with evasion, the final executable is made by Cobalt Strike’s Artifact Kit.
Go to Attacks -> Packages -> Windows Dropper to create this package.
Tip: Use a resource editor to change the icon of the executable, burn it to a disk, and mail it to your target. Used this way, the document dropper is an effective attack.
This attack stands up a website that asks the user to install a Firefox add-on. If the user installs the add-on, you get code execution. Cobalt Strike relies on the Metasploit Framework’s implementation of this attack.
Go to Attacks -> Web Drive-by -> Firefox Add-on Attack to start this attack.
Go to Attacks -> Packages -> HTML Application to create this package.
Java Signed Applet
The Java Signed Applet attack is the ms08_067_netapi of user-driven attacks. It’s so common in demonstrations that you’d think it’s the only social engineering attack out there. This attack starts a web server that hosts a Signed Java Applet. You get code execution if the user allows the applet to run. Cobalt Strike’s Applet Kit uses JNI to inject your payload into memory.
Go to Attacks -> Web Drive-by -> Signed Applet Attack to start this attack.
Tip: By default, Java 1.7u51 and later do not allow applets with self-signed certificates to run. To get the most from this attack, buy a code signing certificate. Go to Help -> Arsenal in Cobalt Strike to download the source code to the Applet Kit. Sign the applet and load the included Cortana script to make Cobalt Strike use your applet.
Microsoft Office Macro
This is my favorite attack in this bunch. This package generates a VBA macro. Embed this macro into a Word document or Excel spreadsheet and send it to your target. The user has to click Enable Content to run your macro. If they do, look out! This attack will spawn a new process and inject your shellcode into it.
Go to Attacks -> Packages -> MS Office Macro to create this package.
Why Cobalt Strike?
In this post, I took you through Cobalt Strike’s user-driven attack options. These are staple attacks that integrate well with Cobalt Strike’s existing features. What are the benefits of using Cobalt Strike to execute these attacks?
Each of these attacks can deliver Cobalt Strike’s Beacon payload. Beacon is a “low and slow” post-exploitation payload that allows you to use custom indicators. Special care went into the shellcode that stages Beacon too. The HTTP stager takes steps to get out through restrictive web proxies. You may also stage Beacon over DNS as well. A well executed attack is no good if you can’t get out of your target’s network.
Cobalt Strike provides a path for evasion. The attacks that rely on executables use Cobalt Strike’s Artifact Kit. This is a source code framework to make executables that smuggle shellcode past anti-virus products. Source code for the Applet Attack is available if you need to change it as well.
The attacks that inject shellcode into memory intelligently account for 64-bit and 32-bit applications. You won’t lose a shell because the user ran your macro in 64-bit Microsoft Word. The attacks that inject shellcode also migrate your payload right away. This protects you if the user closes the application.
A lot of thought goes into each feature in Cobalt Strike. The user-driven attacks are no exception to this.