HOWTO Integrate third-party tools with Cortana

March 13, 2013

One of the goals of Cortana is to give you the ability to integrate third-party tools and agents into Armitage and Cobalt Strike’s red team collaboration architecture. Last year, I was able to put the base language together, but the API had a major gap. There was no sanctioned way for Cortana bots to communicate with each other. Without this ability, I could not integrate a tool in the way this diagram envisions:

The latest Armitage and Cobalt Strike update addressed this gap by adding publish, query, and subscribe primitives to the Cortana API. Any script may publish data that other scripts (even across the team server) may consume. The query function makes it possible for any script to consume published data, in the order it happened. Optionally, scripts may share a “cursor”, so only one script may consume any published item or scripts may each provide their own cursor allowing each script to consume all published items in the order they’re made available. Scripts also have the option to subscribe to data. The subscribe function has Cortana periodically poll the team server, query data, and fire local events when new data is available. These three primitives are very powerful tools.

Let’s Integrate Raven

In the Cortana github repository is a Windows backdoor called Raven. Raven regularly polls a web server for taskings. These taskings are shellcode that Raven injects into a new notepad.exe proces. With today’s update, Raven gets a user interface and provides an example of integrating third-party agents into Armitage and Cobalt Strike through Cortana.

Here’s how it works

One system hosts the web server that Raven communicates to. To bridge Raven into the red team collaboration architecture, this system runs a server.cna script. This script watches Raven checkins by tailing the web server’s access.log file. When someone connects to the web server, it publishes information that clients may consume. Likewise, this server script subscribes to any commands that clients have published. When a client publishes a command (containing a URI and shellcode), this script creates that file on the web server so the Raven agent can download this task when it checks in next.

Thanks to server.cna, we now have a feed of data that raven clients may consume. We also have a way to publish data for the raven agent to act on. Now, we need a client. The client should subscribe to commands that server.cna publishes and present this information to the user. The client should also give the user a way to task the Raven agent. And, the client should give the user a way to configure a Raven DLL or executable.

Fortunately, Cortana was always good at this part. I took a lot of the GUI conventions that exist in Armitage and made them simple to recreate from a script. Here’s what the client.cna I wrote looks like:

Start a multi/handler for windows/meterpreter/reverse_tcp on port 4444

When the agent checks in, right-click it in the Raven tab, and task it to give you a Meterpreter TCP session on your ip:4444

The beauty of this system is that I have to create client.cna and server.cna once. Now, any number of users connecting to my team server (locally or remotely) may load client.cna. They now have the ability to control this Raven agent managed by server.cna for me.

This integration doesn’t have to apply just to agents. If there’s a tool with an RPC interface, you may create a server.cna script that exposes its capabilities to a client.cna script that you write.

This was always part of the vision behind Cortana. Unfortunately, one year ago, the team server didn’t have the primitives to support a publish, query, subscribe API. It does now.