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.