Just in time for this weekend’s North East Collegiate Cyber Defense Competition event, I have a fresh update to Armitage and Cobalt Strike. Here’s the highlights:
Beacon
1. Beacon now auto-dumps keystrokes every time it wakes up. I found it too cumbersome to issue a command each time I wanted keystrokes.
2. Beacon has a changed traffic profile.
3. I spent significant time testing Beacon’s ability to communicate through a proxy server. It was always a given to me that Beacon would stage and communicate through a transparent proxy. What happens if an explicit server is configured? No problem, Beacon will stage and communicate through that too. What happens if the proxy server requires authentication? Well, it depends. If it requires static credentials, then we’re out of luck for now. If it requires domain credentials, that’s another story altogether. On Windows 7, WinINet will transparently manage NTLM authentication. On older versions of Windows (e.g., XP), there’s a flag that must be set to allow WinINet to authenticate for us. Beacon now sets this flag and the Metasploit Framework’s reverse_http stager uses this flag now too.
Performance
4. This update optimizes Armitage and Cobalt Strike’s communication to the team server over high latency networks. These optimizations have the active console tab poll the server more often than inactive ones. This update also creates more connections to the team server, which allows more messages to process in parallel. If you’re connected to a remote team server, these changes will allow Cobalt Strike and Armitage to stay responsive, even if you have a lot of tabs open.
Cortana
5. Cortana now includes a publish, query, subscribe API to allow scripts to communicate using the team server. Several changes were made to make Cortana scripts more robust when interacting with a compromised host. The documentation was updated as well. A future blog post will document some of the new things that are possible with Cortana. For now, check out the updated Raven folder in the Cortana Github repository for a preview.
The full list of changes is in the Cobalt Strike release notes. Licensed users may use the update program to get the latest.
Update 3/6/13 2000h: And my editor (me), missed that March is the third month of the year, not the fourth. No time travel technology was invented by Strategic Cyber. Oops.
Deprecation Notice: Metasploit source checkouts will NO LONGER update over SVN - Move to Git
The official home of the Metasploit Framework’s source code has been github for a while now. Ever since the move to Git, Rapid7 has operated a subversion server that allowed older Metasploit Framework environments to continue to receive updates. Soon this SVN server will shut down (it’s time). That’s what these messages are about:
If you installed the Metasploit Framework with the 4.4 installer or earlier, you’ll need to take action. You won’t get updates from msfupdate without action. You can uninstall the Metasploit Framework and setup an environment with the 4.5 installer. Beware, it’s different from the previous installers. The 4.5 installer requires you to register for a Metasploit Community Edition key to use msfupdate. The 4.5 installer also uses the same Metasploit code base / db tables for the open source and commercial interfaces. This has already led to some fun.
Here’s the word from Tod Beardsley on these changes:
The benefit of the 4.5 installer is that it pulls tested changes only. The Rapid7 QA team works through a snapshot of the framework once a week and clears it for release. In the 4.5 environment, this tested snapshot is what msfupdate will pull if you register for a key.
If you want to use Git and not register, Tod’s blog post offers several options. I’d like to offer another one. You can continue to install the Metasploit Framework with the 4.4 installer. The 4.4 and 4.5 installers ship with the same dependencies. It’s easy to convert the 4.4 environment to pull updates via Github. Here’s how to do it:
At this point, your Metasploit Framework source code is now pulled from Github. If you use msfupdate, the script will detect the Git tree and pull updated source code from the master branch. Pretty easy. (more…)
My Software Development Practices: The Joel Test
Joel Spolsky is one of my favorite writers on the topic of software development. He coined a 12-step Joel Test to determine if your company had sane development practices. A lot of these are very common sense, but I’d like to share a little about how I work and this seems a good way to do it.
1. Do you use source control? Yes
I have a private git repository for development of Cobalt Strike. Armitage uses Subversion still (mostly because I’m too lazy to move it from Google Code).
2. Can you make a build in one step? Yes
Yes. I use a fairly standard Apache Ant build file for my Java projects. I think Ant is cumbersome for some things, so I tie multiple build steps together with a shell script that carries out all steps to create trial and production Cobalt Strike packages to deliver to my end users.
Cobalt Strike has a couple of sub-projects written in C for Windows and Linux. These sub-projects each have their own build process for their respective development environments. I’m toying with using a cross-compiler to build the Windows code where I can get away with it.
One example where I can’t use a cross compiler is Beacon. It is tied to a specific Visual Studio environment because of the Reflective DLL injection code it depends on.
3. Do you make daily builds? Sort of
I make builds when I finish a bug fix or make intermediate progress on a feature. On the days I write code, I am doing full builds of Cobalt Strike multiple times.
4. Do you have a bug database? No
I don’t have a formal database. I still track bugs and notes in a text file. When I start growing development beyond myself, I will pick a simple solution to work with. I do not have a bug database for customers to report bugs into. I still handle this over email.
If I can reproduce the problem and I’m confident I know what the bug is, I will fix it before I work on a new feature. I prefer having a few features that work extremely well over a myriad of features that half work. When I have a bug report, I will go quite far to try to reproduce it. I have an MSDN subscription and I use it to replicate environments when I need to. However, I’ve had bugs that are too hard to reproduce. Sometimes, I’m put in a situation where I have to wait for more clues before I can track down the bug.
6. Do you have an up-to-date schedule? No
I do not work on a schedule. Generally, I aim for a release every 1-3 weeks. I aim to have ~10 logged changes per release. I know which features I intend to build and they have a prioritization. I do not tie these features to specific dates because some genius suggestion, customer request, or bug report may come along and take priority.
In November, I was contacted about Cobalt Strike’s spear phishing tool. I had a trial user who really needed the ability to authenticate to an SMTP server and he was willing to provide access to his infrastructure for testing. I dropped my current development tasks and took advantage of the opportunity to add SMTP authentication to Cobalt Strike’s spear phishing tool. I had always planned to add this, but it became a higher priority when someone asked for it.
7. Do you have a spec? Yes
Another classic Joel Spolsky series is Painless Functional Specifications. In this short series, Joel describes how to write a functional specification to describe a product. I wrote a specification for what would become Cobalt Strike and built the product from it. This spec helped me build my initial product, but I don’t use specs for maintenance. Sometimes, when I’m planning to build a significant feature, I will write a spec and send it to my trusted board of users who have the opportunity to chime in on it.
8. Do programmers have quiet working conditions? Yes
I work from home where I have a comfortable and quiet setup. Sometimes I listen to music, but often times I prefer to work in crisp silence. I once worked for a defense contractor where phones would ring and people would have meetings on their speakerphone in the cubes around me. This was a miserable experience. I will never do this to a programmer. 🙂
Sometimes, I work from Affinity Lab. Affinity Lab is a coworking space in Washington, DC with ~60 companies. It’s Strategic Cyber’s official business address too. Affinity Lab is less quiet, but I go there when I need to be around people and accomplish administrative tasks. I sometimes write code there too, when the change of scenery is enough to jumpstart the brain.
9. Do you use the best tools money can buy? Yes
This is a very strong yes. Anything I can spend to grow my business, improve my product, or make myself more efficient is a write-off. Taxes incentivize me to spend! If I don’t spend the money, I get to keep a portion of it. If I spend it, the full amount goes to grow my business. I commit money to software, hardware, contractors, and licensed technology quite regularly. I try not to be foolish with this though. For example, I’m on the fence about upgrading my MSDN Operating Systems subscription to a full MSDN subscription. The full subscription is quite expensive, so I don’t know if I will extract that value out of it. Generally though, when a case can be made, I’m quick to invest back into my business. I work off of a maxed out MacBrook Pro and an Apple Thunderbolt display.
10. Do you have testers? No
Yes, I have testers, they’re called users. When I have enough changes to cut a release, I do so. Cobalt Strike changes make it to customers and trial users very quickly. When the product was under private development, I had a team of beta testers who acted as a stand-in for the customers I would eventually get. I still use this team as an advisory board.
Generally, my releases focus on one feature area making them easier to test. I don’t believe in monolithic point releases. Sometimes, I will introduce a bug or error, and if it’s a show stopper, I recut the release or create a special build for the customer that needs it. These cases are very rare.
In terms of user feedback, Cobalt Strike benefits greatly from building on Armitage. I try to keep the code for the two interfaces as close as possible. This gives Armitage’s significantly larger user base a chance to chime in on something that will improve both products.
I spend a lot of time testing the foundation I build on too. Cobalt Strike builds on the Metasploit Framework which is one of the fastest moving projects I’ve ever touched. Something that works today, could change, and ripple into my product in an unexpected way. I also have the pleasure of serving a user community that likes to use the latest development version of the Metasploit Framework. Talk about a catch-22!
I mitigate this scenario with unit tests. Before I cut a Cobalt Strike release, I update to the latest version of the Metasploit Framework. I run several Cortana-based unit tests to exercise the Metasploit Framework, automatically hack into hosts, and do basic post exploitation. The unit tests help me test the Metasploit Framework and exercise my interfaces to it. I also exercise a few basic scenarios. Occasionally, I stage a node on Amazon’s EC2 and conduct a penetration test against an enterprise network lab environment I host on a Shuttle PC.
Each release, I publish the version I tested with my release notes for customers to match their environment to. If someone chooses to update to the latest version of the framework’s code. That’s up to them. If they encounter a problem, they can downgrade to the last tested version.
Of course the best testing is real world use. I don’t do services / pen testing work now (development is a full time job!), so >exercises are the closest I come to real world use with my tools. When invited, I play red team in exercises and war games. These opportunities provide valuable feedback that helps me make my tools better. Generally, I spend March and April doing nothing but exercises. These months are so busy that I sometimes leave at the tail end of one exercise to catch a flight to the next one.
11. Do new candidates write code during their interview? Not Applicable
I’m not interviewing developers yet. When that time comes, I will not hire from a typical interview. I will carve out a small project, hire someone on a contract basis, and see how well we work together. This will answer the questions that an interview is ill-suited for. I’m okay risking money on a test project to see how well someone works out.
12. Do you do hallway usability testing? No
The Joel Test asks, how often do you observe a stranger trying to complete a random task through your software? I do usability testing, but I don’t do it by pulling people out of a hallway. I do it through classes. I teach two classes. I teach a free 4-hour workshop on Armitage and Cobalt Strike at various conferences. When hired to, I teach the Advanced Threat Tactics course.
I don’t get a lot of usability feedback from the 4-hour workshop. Generally there isn’t a lot of time for the labs and the labs are very scripted. However, I sometimes receive a gem of a suggestion or see where something could be made intuitive.
The usability goldmine for me is the Advanced Threat Tactics course. The class ends with a capstone exercise. The exercise takes place in my enterprise network lab environment. The environment is seeded with data and services to create the sense of a living world. I put my students into teams and I assign each team one of four goals. The students are expected to get a foothold in the lab environment and iterate through the network attack process until they accomplish their goal. Some of the goals are very open-ended (e.g., you’re a hacktivist, expose ACME for their wrong doing). The exercise is where I observe how well my toolset and its workflow clicks with users.
The host labels feature added to Cobalt Strike and Armitage last month came from a January run of the Advanced Threat Tactics course.
Advanced Threat Tactics is so effective for usability testing, that I also have a private invite-only session I run. I ran it twice last year and I plan to run it later this year. During this private session, I invite a mix of people. I always make sure I have two people who have never hacked before. I also invite some of the most experienced penetration testers and researchers I know. This is an intimidating group to “teach”, but it’s a useful way to see how different skill levels approach the toolset.
My goal is to make sure Cobalt Strike is valuable to experienced pen testers without forcing them to learn a new way to do everything. The fact that Cobalt Strike provides full access to the Metasploit Framework console helps greatly with this. I also watch to make sure that novice users are able to get things done with Cobalt Strike after a reasonable amount of instruction.
Cobalt Strike Boxed Set comes to ShmooCon
It’s the middle of February, love is in the air, and… I’m busy preparing for my favorite hacker conference ShmooCon.
This year, for the second year in a row, Strategic Cyber LLC is sponsoring ShmooCon.
Last year, I had intended to launch Cobalt Strike. Except, it wasn’t called Cobalt Strike and someone else beat me on filing a trademark application on the original name–by about five days. Pure coincidence and I learned a lesson about retaining an IP lawyer early in the business formation process. Anyways…
Cobalt Strike is having its first year at ShmooCon and I plan to make it a good one. I’m unveiling a Limited Edition Boxed Set and giving away more of the popular Pen Test Lab DVDs. Read on…
Limited Edition Boxed Set (Seriously)
If you haven’t bought Cobalt Strike yet, now is your opportunity. Leading up to and during ShmooCon, a few Limited Edition Boxed Sets are available. If you buy a Cobalt Strike license now through this weekend and present the key at the Cobalt Strike table, I will issue a boxed set to you (while supplies last).
These sets are beautiful. They include a professionally bound copy of the Cobalt Strike manual, a DVD with the Cobalt Strike software, and a Cobalt Strike sticker.
Most big software companies ask for a big check. In exchange, you get some 1s and 0s transmitted to you over the internet. When’s the last time someone bothered to put those 1s and 0s into a box? I rest my case.
Penetration Testing Lab DVD
If you haven’t tried Cobalt Strike yet, we have a slight problem. I don’t want you to buy without putting the software through its paces. I’m quite serious about this. If you want to try Cobalt Strike, stop by the table and get a Penetration Testing Lab DVD.
This DVD has everything you need to put Cobalt Strike through its paces from the comforts of your laptop. This DVD includes an attack virtual machine, a Cobalt Strike trial package, and two victim virtual machines with self-guided hacking labs. I think of it as a chemistry kit for learning hacking. You can follow the steps or invent your own experiments.
I plan to burn a few hundred of these. I’m doing it now. I will run out. I always do. If you want one, come get it as early into the conference as you can.
Come say Hi!
I work the Strategic Cyber LLC table the entire time. If you have questions about Armitage or Cobalt Strike or if you’d like to see a demonstration, come on by. I’m looking forward to seeing you at ShmooCon!
A Vision for Distributed Red Team Operations
Last year I gave a talk on Force Multipliers for Red Team Operations. In that talk, I elaborated on my search for capabilities that make us more effective with our hacking tools. I spelled out three areas of work: collaboration, automation, and distribution. I’ve put a lot of work into collaboration capabilities already and the DARPA-funded Cortanastarted my exploration of automation.
My Force Multipliers talk left the distribution question open. How do we use our team hacking tools through multiple points of presence on the internet? Today’s Cobalt Strike update is my answer to this question.
You may now use one Cobalt Strike client to manage multiple team servers spread out around the internet.
Here’s how it works:
When you connect to two or more servers, Cobalt Strike will show a switchbar with buttons for each server at the bottom of your window. Click a button to make that server active. It’s a lot like using tabs to switch between pages in a web browser.
To make use of multiple servers, designate a role for each one. Assign names to each server’s button to easily remember its role.
Dumbly connecting to multiple servers isn’t very exciting. The fun comes when you seamlessly use Cobalt Strike features across servers. For example:
Designate one server for phishing and another for reconaissance. Go to the reconaissance server, setup the system profiler application. Use the phishing tool to deliver the reconaissance website through the phishing server. This is easy to do because Cobalt Strike’s phishing dialog lets you embed a site from any server you’re connected to.
Web drive-by exploits are especially interesting. Clone a website and embed an exploit on one server. Set the embedded exploit to reference a Beacon listener on another server. When a vulnerable user visits this site, their system will start beaconing to the beacon server.
This is trivial to do because Cobalt Strike will let you setup an attack that references a listener on any server you’re connected to.
Distributed operations has its drawbacks. Each penetration testing server is a silo with a limited picture of the engagement. Cobalt Strike makes great strides to solve this problem. When you ask for a report, Cobalt Strike queries each server you’re connected to, combines the data, and generates one report. For example, if you send a phishing attack from one server and it references a site on another server, Cobalt Strike will cross-reference the information from both servers and present a coherent picture of the social engineering engagement.
Are you curious what all of this looks like? Watch the video:
This distributed operations capability is in today’s Cobalt Strike update. Licensed users may update Cobalt Strike with the included update program. See the releasenotes.txt file for a full list of changes in today’s update. If you’re interested in getting a quote, start the process by filling out the form.
Enjoy.
Getting Started with Armitage and the Metasploit Framework (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:
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.
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.
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:
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.
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
Go to Hosts -> Nmap Scan -> Intense Scan, all TCP ports
Type the IP address of the Metasploitable Virtual Machine Wait for the scan to complete. It will take some time.
Right-click the Metasploitable host and select Services
Exploit
Go to Attacks -> Find Attacks
Wait for Attack Analysis complete dialog.
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.
Type: whoami and press enter in the new Shell 1 tab.
Brute Force VNC
Select the Metasploitable host in the target area
Navigate to auxiliary -> scanner -> vnc -> vnc_login in the module browser. Double-click this module.
Press Launch
Open a Terminal and type: vncviewer metasploitable IP:5900. Use the password vnc_login helped you discover to connect.
Tomcat Manager Deploy Exploit
Select the Metasploitable host in the target area
Navigate to auxiliary-> scanner -> http -> tomcat_mgr_login in the module browser. Double-click this module.
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?
Press Launch
Navigate to exploit -> multi -> http -> tomcat_mgr_deploy in the module browser. Double-click this module
Change RPORT, USERNAME, and PASSWORD to their correct values. Step 4 should have yielded a valid username and password for you.
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:
Type _login in the search box below the module browser
Launch the *_login module you’re interested in. Type _login in the box below the module browser to search for these modules
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
Double-click on the wordlists folder
Choose the unix_users.txt file
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)
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:
Try to brute force credentials to the postgres database running on the system
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 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 red team operations and adversary simulations. Cobalt Strike’s 3.0 release no longer depends on the Metasploit Framework. It’s a stand-alone toolset, separate from Armitage. Use Cobalt Strike in situations where you need to work as an external actor and stealth matters a great deal.
In June 2012, I released Cobalt Strike, a commercial penetration testing package that picks up where Armitage leaves off. Cobalt Strike is a direct expression of what I think a penetration test looks like. If you’re interested in this vision, this post will walk you through it.
The term penetration test is overloaded and may mean something different with each person that you ask to define it. To some people, a penetration test is a vulnerability verification exercise. To others, it’s an expert using the tactics and techniques of a skilled adversary to assess a mature security program’s ability to cope with a targeted attack.
I used to work as a contractor, providing red team services to a DoD customer. I saw gaps between the abilities of my tools and what I had to do. There isn’t much help for those of us who have to execute a full-scope external engagement. I wrote Cobalt Strike to fill the gaps I saw. Cobalt Strike is a tool execute a targeted attack. Let’s go through what a targeted attack looks like.
Reconnaissance
We’ll start where the active part of a penetration test begins, reconnaissance. Cobalt Strike’s system profiler is a web application to probe and report the client-side attack surface of anyone who visits it. The system profiler reports the applications a user is running along with version information. This report isn’t comprehensive. The system profiler can’t discover all applications, but it does discover the common ones that attackers target. I liken this to the client-side version of a port scan with a banner grab.
Once you have a system profile, you can plan an attack. If your client doesn’t allow client-side attacks, that’s fine. A system profile alone is enough to generate a client-side vulnerability report. If you’re allowed to go further, the tools are there.
Access
Cobalt Strike recommends client-side exploits based on a system profile. You may choose to use one of these exploits in your targeted attack. You have one problem though. The client-side exploits in the Metasploit Framework are caught by most anti-virus products. I don’t blame the Metasploit Framework for this. The project does not promise anti-virus evasion. This is a problem that’s up to the user to solve.
If you want to deliver a client-side memory corruption exploit, that’s fine. Set up a virtual machine and install the anti-virus product your target uses. Change obvious strings in the Metasploit module until it passes the anti-virus product you’re interested in. Cobalt Strike will happily use your modified Metasploit Framework modules.
Java Drive-by Exploits
Lately, the client-side whipping boy is Java. Several Java attacks disable the Java security sandbox and allow an attacker to silently execute code without alerting the user. These attacks are extremely reliable and do not rely on memory corruption. If the user’s Java is patched, you may deliver a signed Java applet to a user and hope they give your applet permission to run without restrictions. This is a staple social engineering attack.
This week’s Java 1.7u11 release makes some attempts to mitigate Java attacks in a generic way. We’ll see how much the new security settings affect penetration testers. You may find a target is running an outdated Java, giving you a free pass into their system. You may find your target is up to date and this may influence your attack strategy.
If you do choose to use a Java attack, know that there is a downside. The Metasploit Framework’s Java exploits are tightly coupled to a few payload options with no randomization at all. Popular anti-virus products detect the Java exploits and payloads. There is no option to use an anti-virus safe Jar file with a Java exploit module.
If you want to use a Java attack in a penetration test, you must reimplement it and host it yourself. I did this for you. Cobalt Strike includes an implementation of the signed Java applet attack. I also include a Smart Applet attack that detects the current version of Java and disables the security sandbox with an exploit before it executes your payload. If you want something intelligent, start the Web Drive-by Exploit server and tell it to use Java attacks only. With this feature, Cobalt Strike will detect the version of Java a visitor has and deploy the Smart Applet attack if it makes sense or fall back to the Signed Applet.
Of course, there’s another problem: anti-virus. It’s only a matter of time before every anti-virus product on the planet screams at the sight of my Java attack kit. For my customers, I provide a small SDK with the source code to Cobalt Strike’s Applet Kit. The build files are there. Modify the code as you see fit and rebuild it. Load an included Cortana script to make Cobalt Strike use your changes. This collection of source code, ready to tweak for AV evasion, is the Cobalt Strike arsenal.
Hacking with Features
Exploits aside, there’s another class of attacks well supported by Cobalt Strike: features. I expose several gems in the Metasploit Framework to add a Macro to Word and Excel files, generate a Java JAR file, or trojanize a Windows executable. If there’s no exploitation opportunity, use Cobalt Strike to add an agent to a regular file.
At this point, you have a package that will execute code on workstation. Great! Now, let’s make this package into something that won’t raise suspicion. You can register a domain and setup a fake website that plays to your pretext. If you’re in a hurry, use Cobalt Strike’s website clone tool to clone a site and embed your attack into it.
Spear Phishing
Now, you need to get the attack to the user. Spear phishing is a common way. Let’s talk about that. Most penetration testers have a dust-covered Perl script that will connect to a mail server and deliver a message. This piece is trivial to do. The hard part is crafting a message that matches your pretext. No matter how hard any tool developer tries, our hacking tools can’t and should not try to replace a modern email client to compose a message. If this sounds out of left field, stay with me for a minute.
A successful spear phishing attack requires a good pretext. Period. The pretext is the ruse you create to convince a user to open your attack package and give you access to that system. In your pretext, someone is sending the message. This person works for an organization. They have a signature block, they use certain fonts in their message, they may have that stupid legal notice at the bottom. Whatever it is, you should base your phish on a real message. If you have a message from that person, save it and edit it in a text editor to say what you want. If the phish’s sender isn’t real, compose a message in an email client and send it to yourself. In both cases, you have a message composed in an email program that looks right and says what it needs to support your pretext.
Now, you need to repurpose this message and get it to the user. This is where Cobalt Strike helps. Its spear phishing tool imports saved email messages. Import the message and Cobalt Strike will strip most of the headers from it. Cobalt Strike will also replace all links in the message with a link to your attack package. If you want to attach a file, that’s OK too.
Cobalt Strike’s spear phishing tool communicates directly with your target’s external mail server to deliver the message. If you have a mail server that will deliver messages, give Cobalt Strike the details to authenticate to it and Cobalt Strike will use this option instead.
Command and Control
Now, you have a package that will give you code execution, pass host anti-virus, and a way to deliver it. What else is there? Command and control.
If you get code execution on a user’s system, you need a way for their system to communicate with you. This is necessary if you’re going to take data from the system or use it as a hop point for other attacks
One option is Meterpreter. Its reverse HTTP[S] payloads will communicate through a transparent proxy. Its reverse TCP payload will connect to you on an any port you choose. Cobalt Strike supports these options.
An alternative is Cobalt Strike’s Beacon payload. Beacon works like some of the advanced malware in the wild. Once it’s staged, it limits its communication to you. Beacon will make a DNS request using the resolver built into Windows. It will ask if a host exists on one of several domains you control. If the host exists, Beacon uses this as a signal to phone home and request a task. If the domain doesn’t exist, Beacon goes to sleep. To manage this, Cobalt Strike ships with its own DNS server. You simply point the NS records to your attacker system and Cobalt Strike takes care of the rest.
Beacon is the tool to maintain a foothold in a network. Beacon has a few post exploitation capabilities too. It will log keystrokes, execute commands, and inject shellcode into memory. With Beacon in place, you may give yourself a Meterpreter session when you’re ready to use it.
As a placeholder, Beacon has several advantages over Meterpreter. It’s not chatty. It communicates with you on a set interval. The DNS variation of Beacon, will not communicate with you unless there is a task. Further, you may deploy Beacon with multiple domains embedded inside of it. If one of your domains is blocked, Beacon will still reach you through the others. This makes your placeholder more resilient. These capabilities make Beacon desirable for your first access. You don’t want to go to the trouble to get an access and then lose it because Meterpreter crashed or your attacker IP was blocked.
Post Exploitation
For post-exploitation, Cobalt Strike offers the same tools as Armitage to control Meterpreter. You can setup proxy pivots, launch privilege escalation exploits, download and upload files, take screenshots, and interact with a command shell. As an added bonus, you can automate your post-exploitation activity using Cortana scripts. Cortana is the scripting technology paid for by DARPA’s Cyber Fast Track program. It’s open source. You can use Cortana scripts with Armitage or Co
balt Strike.
During a targeted attack, another problem arises that Cobalt Strike is well suited for. It’s likely you have one or two accesses into a network and multiple teammates. I built Cobalt Strike’s tools into Armitage because I saw a natural complement here. Armitage is a solid foundation for red team collaboration. You may communicate activity in a chatroom, share sessions, and have access to the same data as your teammates. Now, those one or two sessions aren’t a problem. Your team, each member with a different job to do, can set to work on the target’s network by sharing those accesses. If a penetration tester encounters a system they don’t have the knowledge to deal with, a specialist can connect to the teamserver and set to work from the position in the network you worked hard to get.
Lateral Movement
It’s unlikely that the system you land on is your destination. Once you have a foothold in a network, you will need to attack other hosts. With Armitage and Cobalt Strike, you can set up a pivot through Meterpreter, discover and scan hosts, and launch remote exploits. While this is nice, the juicy stuff is abusing trust relationships.
Lateral movement in a network involves abusing your position of trust to compromise otherwise patched hosts. In an active directory network, you simply authenticate to a host, copy an executable to it, and schedule this executable to run. To authenticate to a Windows host, there are three artifacts that will help you: tokens, password hashes, and plaintext passwords.
Token Stealing
In Windows, every thread has an access token associated with it. This token acts as a cookie to identify the user, their groups, and the privileges the token holds. If an attacker controlled thread has a token for say, a domain administrator, then the attacker may do anything that the domain administrator user can do. These actions aren’t restricted to local actions either. You can execute commands to interrogate a host, list files, and move files between hosts. Why, you can even schedule tasks if you’re an administrator.
Meterpreter has a lot of functionality for listing and stealing tokens. Both Armitage and Cobalt Strike have dialogs to manage this functionality. You can steal a token directly from a process–this gives your meterpreter session the rights of that user or you can list all tokens available on the system and impersonate one of them.
To move laterally with a token, Cobalt Strike provides a dialog for the Metasploit Framework’s psexec with current user token module. This dialog lists all meterpreter sessions you have and which token is associated with each. Simply select one and the Metasploit Framework will create a share through the meterpreter session you select and ask the target hosts to schedule a job to execute a program hosted in that share.
The phrase execute a program should raise a red flag and signal alarm bells in your head. This is an opportunity for our very dear friend anti-virus to stop us. If you rely on the executable generated by the Metasploit Framework, you’re caught.
Cobalt Strike’s psexec dialogs allow you to specify any executable that you’d like. This saves you from the executable generated by the Metasploit Framework, but it forces you to step away from the flow of the penetration test and work on crafting an executable that anti-virus doesn’t catch.
Another option is to load a Cortana script that intercepts any psexec actions, extracts your payload parameters, and generates an AV-safe executable for you. I wrote a generic HOWTO on anti-virus evasion with Cortana awhile ago. For Cobalt Strike customers, I went a step further. I wrote a simple AV by-pass executable and made it and its source code available in the Cobalt Strike arsenal.
Pass-the-Hash
Cobalt Strike and Armitage expose Meterpreter’s ability to extract password hashes if you’re SYSTEM on a host. You may use the password hash to login to a host, copy an executable, and schedule it to run. This is the pass-the-hash attack. It works because the password hash is not salted and it’s all you need to authenticate to a host with. This doesn’t work with all users though. You need a password hash for a local administrator or domain administrator user.
Fun with Passwords
If you manage to get plaintext credentials, you can use them with Cobalt Strike’s psexec dialog, the same as you would use password hashes. One way to get plaintext password is to log keystrokes. I built the keystroke logger into Beacon for this purpose. Beacon’s keystroke logger tracks the active window with the current keystrokes.
Separate from Cobalt Strike, there are two innovative programs you should know about: mimikatz and Windows Credential Editor. These programs will grab cached Windows user credentials from memory for you. I’d include either of these programs in Cobalt Strike if I could work out a licensing deal with either author. In the meantime, you can use Cortana to integrate either of these tools into Cobalt Strike. I wrote a script for Windows Credential Editor already. The freedom to integrate external tools with Cortana is one of Cobalt Strike’s strengths.
Plaintext credentials are the best thing that can happen to you. You may use them to login to internal web applications, servers, maybe access a VPN for employees, or use RDP. The sooner you can dump hacking tools and switch to normal administration tools–the better.
VPN Pivoting
Once you’re inside a network, there’s a lot more you can do. You can sniff traffic and attempt to capture information that way. You can host a rogue smb server and use it to capture or relay the credentials of any system that touches your server. There’s a lot of opportunity that opens up.
Unfortunately, these opportunities require being inside the network. Layer 2 access, as if your system is plugged into that network.
Cobalt Strike can help you here. Its Covert VPN feature bridges you into your target’s network using a compromised Windows workstation as a hop point. How does it work? Think of it as a two-way packet sniffer. Covert VPN sets up a network interface on your attacker system. Anything that passes through this interface is dumped as-is on your target’s network. On the compromised host, acting as a relay, any frames it sees are made available to the network interface created by Covert VPN.
The covert part of Covert VPN is the ability to choose how it relays traffic back and forth. You can relay frames using a UDP transport. This is fast and works like a traditional VPN. You can relay frames using a reverse TCP connection. Or, you can relay frames as HTTP GET and POST requests. This last option is useful if the only way out of a network is through a proxy server. None of these options is very quiet though, a VPN is always chatty.
With Covert VPN, you have the option to bring other tools into your engagement. You’re now in the target’s network and can do what you need to do.
Epilogue
This is where Cobalt Strike will take you to. We started at the beginning of an attack, the reconnaissance phase. I showed you how a system profiler will help you gather the information necessary to execute an attack. We talked about attack options and anti-virus evasion. We then brought spear phishing into the picture. Once you gained a foothold, I discussed how to abuse it to spy on the user and to abuse your position in the network to attack other hosts. From the perspective of Cobalt Strike, this is how you hack into a typical enterprise network.
One Shot, One Kill - An Intelligent Web Drive-by Exploit Server
One of my favorite features in Cobalt Strike is the system profiler. This web application digs deep into your browser to discover the client-side applications that I, as the attacker, can touch. To go along with the system profiler, I maintain a database that maps these applications to exploits in the Metasploit Framework. The system profiler uses this mapping to report client-side vulnerabilities. Are you with me so far? Good.
Mapping the information reported by the browser to exploits isn’t always trivial. Take the case of Internet Explorer. Internet Explorer reports the base installed version. This reported information does not change, even as you apply patches. I could simply punt and report any instance of Internet Explorer as vulnerable to everything, but this is part of the reason hackers hate automated tools. Instead, I try to be a little more intelligent about it. I painstakingly created a database to track the release dates of Windows Media Player and the JavaScript Engine that’s installed. I use these two hints to better map Internet Explorer to a ballpark date, that I then use to best estimate which vulnerabilities a visitor’s Internet Explorer is open to.
That’s a lot of intelligence in a simple system profiler. Now, on with the story:
In last week’s Cobalt Strike update, I opted to implement Cobalt Strike versions of the popular Java applet attacks. The open source versions of these attacks are burned by anti-virus, with no evasion options on the Java side. Reimplementing them is required to use them during a penetration test.
The dropper for Cobalt Strike’s Java Applets is pretty novel. I’m taking advantage of some JNI action to inject shellcode directly into memory.
Anyways, these new Java attacks led me to a neglected Cobalt Strike feature–the web drive-by exploit server. The original implementation was decent, but hard to maintain and update as more reliable exploits with broad coverage appeared.
I finally had the epiphany–wouldn’t it be cool if I could merge the intelligence of Cobalt Strike’s system profiler with the web drive-by exploit server?
So, I set into a marathon coding session to do just that. I now have the scariest weaponized browser fingerprinting kit on this side of the legal line.
A user visits the Cobalt Strike hosted web drive-by exploit server. The code at this point is the same as the system profiler. Cobalt Strike receives a profile and does all of its version heuristics and exploit mapping.
At this point, the web drive-by exploit server is able to cross-reference running exploits and the list of exploits that the system profiler believes are valid.
The last matter is to choose the best exploit from the resulting list.
Because I have a system profile, I’m able to do some very smart things. For example, two recent Metasploit Framework IE exploits depend on Java 1.6 to execute code on Windows 7 and Windows Vista. I’m able to use the information from the system profiler to eliminate these exploits from the running when necessary.
Once I apply several sanity checks, I arrive at a smaller list of exploits. I simply choose the exploit that has the highest reliability score I’ve assigned and that’s what Cobalt Strike serves.
Here’s a video of the web drive-by exploit server in action:
Pure pwnage.
Fresh Paint for the Java Applet Attack
Java is a popular vector for penetration testers and those who penetrate networks without an invitation. An attacker creates a website to host a Java applet. In the simplest case, the Java applet is signed with a certificate. The user is asked “do you want to allow this applet to run?” The user’s yes response gives the attacker control over their system.
The signed applet attack requires user interaction. Recent Java exploits take advantage of API loopholes to disable the Java security sandbox, giving the attacker control without asking the user.
Today, I’d like to introduce you to Cobalt Strike’s take on the Java Applet Attacks.
A self-signed Java applet attack, by itself, isn’t novel. The special piece is the Cobalt Strike Java payload.
Cobalt Strike’s Java payload use’s a native library to inject shellcode for your Windows listener into memory. You may deploy Beacon or Meterpreter through Java attacks. If the environment is not conducive to running a Windows listener, Cobalt Strike will dynamically link and run a Java meterpreter payload for you.
You also have the option of launching a smart applet attack. The smart applet will detect the Java version that’s running and attempt to disable the security sandbox using known exploits. This attack uses Cobalt Strike’s Java payload too.
These cross-browser and cross-platform Java attacks are part of today’s Cobalt Strike update. Read the release notes to learn what else is new. Licensed users may update with the built-in update program.
Licensed Cobalt Strike users may get the source code to Cobalt Strike’s Java injector and attacks through the Cobalt Strike arsenal. The Cobalt Strike arsenal provides source code, build files, and Cortana scripts to make Cobalt Strike use your modifications.
My exploits can beat up your exploits
TL;DR Rapid7 wrote a blog post claiming that their exploits are better. I think the Metasploit Framework’s coverage is fine, but some other vendors do better with AV-safe client-side exploits. Over time, memory corruption exploits will become less relevant to penetration testers. Let’s talk about how penetration testing is evolving, not who has “the best” exploits.
Generally, we act like politicians on the campaign trail fifteen months before an election. We either act like the other parties don’t exist, take very light jabs, or look for ways to cooperate.
Today, Rapid7 has a blog post on Open Source vs. Pay-for-Play exploit packs. In this post, a Product Marketing Manager at Rapid7 makes his case as to why Rapid7’s hybrid open source and commercial model yields more reliable and relevant exploits than other commercial-only contenders.
Nico Waisman, a Regional Manager and accomplished Security Researcher from Immunity Inc., had an interesting reaction to this particular post:
The end of Rapid7’s blog post invited opinions, so here’s mine.
First, the Rapid7 blog post labels Metasploit Framework contributors like myself as the Rapid7 Security Community. I am not a member of the Rapid7 Security Community. I am a contributor to the Metasploit Framework. Refer to us as the Metasploit community, please.
Next, I can see where this post is coming from. Core Security labels their exploits as commercial grade. I perceive this as a light jab against the open source Metasploit Framework. I read Rapid7’s post as a response to the commercial grade label.
After I published this post, a Core cofounder and former CTO responded to the commercial grade label. My perception of this label wasn’t the intention of it. Thanks for clarifying. The tweets are below.
For remote service exploits, it is my belief that all products have similar coverage. The most common remote service exploit to demo is 2008’s ms08_067_netapi. As we turn near 2013, I believe all products have this one well covered. There are other useful remote exploits, but I’m not aware of a magical remote service exploit in any product that by itself, makes the product a must-have. No one has an edge here.
Now, if your work involves penetrating systems, not verifying remote service vulnerabilities, then client-side attacks matter to you. Again, I believe the Metasploit Framework has good coverage of client-side attacks. However, some of its pure commercial competitors have an edge in this area.
The Metasploit Framework’s client-side attacks are eaten alive by anti-virus products. The problem is so bad, that part of my roadmap involves porting a few key attacks to Cobalt Strike so I can give my customers options. Core Security tries to stay ahead of some anti-virus products. I haven’t read a blog post from Immunity and Saint about this topic, so I can’t speak to how they handle this problem here.
Now of course, anyone can modify the Metasploit Framework’s exploits to evade an anti-virus product and submit a pull request. This is rare though. My guess is that if someone modifies a Metasploit Framework client-side exploit they hold onto it to get the most use out of their modification. I expect pen testers to have the skill to modify an exploit to pass AV, but many penetration testers find themselves squeezed to mimic a threat in a tight timespan, anything we can do as vendors to help them is welcome.
Access strategies change over time though. 10 years ago, the game was memory corruption exploits against remote services. 4-5 years ago, the game shifted to memory corruption exploits against user applications (client-side attacks). Organizations continue to become smarter about vulnerability and patch management. Software will continue to become harder to exploit. Despite this progress, organizations today get owned with executables disguised to look like PDFs.
As memory corruption exploits become less relevant, we must focus on reconnaissance and look for opportunities to abuse information disclosures, design flaws, configuration mistakes, trust relationships, and the behavior of systems. David Kennedy’s Social-Engineer Toolkit is an example of this. Its Java Signed Applet attack uses existing functionality to get access and it is constantly updated to stay ahead of anti-virus.
I believe organizations will one day assume an attacker can get a foothold. At that point, a pen tester will add value by helping an organization assess their ability to detect, frustrate, and contain an attacker. Our tools will need to evolve to better support this service offering.
How should they evolve? Let’s start with these questions: How do you maintain access to a system without tripping an alarm? How do you establish Command and Control when facing a very restrictive firewall and web proxy server? How do you carry out those neato insider threat attacks from a foothold? How do you quickly identify privilege escalation opportunities? How do you automate your engagement? How do we as vendors better help our pen testers match capabilities to opportunity? How do you manage large-scale penetration testing infrastructure to better mimic an adversary with control of multiple hop points? These areas are stagnant in penetration testing tools and ready for innovation.
As we get better at mitigating vulnerabilities, in what other ways will pen tester service offerings evolve? As more organizations trust cloud services, we’re seeing social engineering attacks that take advantage of differing vendor policies about which information is safe to give out vs. which information authenticates you. Who is working to address this?
Successful attacks are just as much about a lucky opportunity from good timing as they are about good products and planning. A two-week window is hit or miss in terms of opportunity. What would an economical year-long penetration test look like? How can we as vendors better support the next penetration testing service models?
Attackers continue to evolve. Penetration testing is slowly evolving. We’re not away from the vulnerability verification mindset yet, but we’re getting there. I believe that swinging swords around who has better exploits is irrelevant. Vendors who want to lead should discuss where the field is going and work to help it get there.
"I have a dream that hackers will one day not be judged by the color of their hat, but by the content of their exploits." – @jack_daniel
