Current frameworks: the upsides, the downsides, and my ideal

There are currently a lot of amazing frameworks out there (open source or for purchase), so people are probably wondering why I started the long process of creating my own framework. I wanted to take a few minutes to walkthrough some of the current frameworks and discuss what I like, what I wish was different, and finally some of the bigger goals of my framework.

Cobalt Strike

Cobalt Strike is by far the leading post-exploit red teaming framework out there today. This is a commercial tool created by Raphael Mudge after he made the free modifications to Metasploit known as Armitage.

The Upsides

I can’t sing the praises of this tool enough. Mudge provides a lot of documentation about how to use his tool with an extensive manual, with lots of blog posts, a set of tutorials for writing aggressor scripts, and even a large number of youtube videos covering adversary tradecraft and details of Cobalt Strike. This is a commercial tool afterall, but it’s still amazing how much help and support Mudge provides to his clients and to the community for free.

The user interface is also pretty intuitive to use. Lots of frameworks provide a text-based, command-line interface, but Cobalt Strike uses Java to provide a GUI for the operator. You can interact with the individual beacons via a text interface, which supports help menues and tab-completion. Additionally, some information throughout operations is also saved in local files that are loaded between runs of the teamserver (such as listeners). Coblat Strike also has multiple options for generating reports, even mapping some techniques to the MITRE ATT&CK framework. This is something rarely seen in frameworks, but is immensely helpful not only for operators and defenders, but for providing a way to leverage red team data by researchers.

Cobalt Strike also has a novel approach to C2 which Mudge terms Malleable C2. This is one of the coolest features of Cobalt Strike in my opinion and really sets it apart from the others. With a simple, plain-text document, you can configure a bunch of different components about beacon and C2. Specifically:

• How to send data for HTTP GET/POST requests (custom parameters, cookie values, custom headers, modify headers, etc)
• How to encode data (base64, netbios, prepend/append data)
• How to configure callbacks (callback times, pipenames, spawnto processes, useragents, jitter, and abunch of DNS information)
• Specify your own HTTPS Certificates and code signing certificates
• How beacon is staged in memory (rwx pages, compile times, image sizes, obfuscation, string replacements, module stomping, etc)
• How to extend Cobalt Strike’s normal C2 to other mediums/formats with the new External C2

Mudge is also very prompt in taking the latest new techniques and incorporating them into his tool.

The Downsides

Because Cobalt Strike uses Java, you need to make sure the proper version of Java is installed on the teamserver and the operator machines. If you use the default openJDK versions on VMs like Ubuntu or Kali, after a few hours, the interface becomes so laggy that it’s unusable. When this happens, you have to close the client, start it again, let it sync with the teamserver, and then you have another hour or so before you need to repeat the process.

Anybody with the shared key for the teamserver can connect in with any username they choose. This provides a little bit of tracking between users, but if UserA disconnects, I can connect in as UserA. This is used more as a way to loosely track what users are interacting with the beacons, but isn’t meant to provide real tracking or analytics for specific operators.

Not everything is saved off by the teamserver (most is just stored in memory). This means that if you operate across a lot of beacons or for an extended period of time, you need to make sure your teamserver has a large amount of RAM. This also means that if the teamserver dies for some reason (SEFGAULT, user quit, machine reboots, process is killed due to logout, etc) that a lot of your operational data is also gone. Things like keylogging and screenshots for example will be gone forever.

Cobalt Strike is geared towards collaborative Red Teaming on Windows machines. There is a little support to SSH/VNC into *Nix boxes, but there are no payloads that can be dropped to disk or used in memory.

Empire

Empire is one of the leading open-source frameworks for red teaming across all of the major operating systems (Windows, *nix, and macOS) and is developed by @harmjoy, @sixdub, @enigma0x3, rvrsh3ll, @killswitch_gui, and @xorrior. Since this project is open source though, there have been a large number of contributors to the main functionality and to the many modules it supports.

The Upsides

All of the code for Empire is available on github, which means that you’re free to go through and modify it as you wish for your use case. It is python-based, which means any system that runs python can run the server without any crazy requirements. There’s even a docker image that can be used!

With a single interface, Empire has agents that can run on Windows (PowerShell), Linux (python), and macOS (python). This allows you to work across a wide range of targets with a single tool. Additionally, the back-end can be scripted due to its RESTful interface. This allows others to develop around Empire and provide their own tooling such as the DeathStar project and the AutoTTP project.

When you have questions with the project, there is also a slack channel in the BloodHoundGang slack where you can ask questions directly to the authors and power users of the project. You can also look at the issue tracker, pull requests, or just look into the code itself.

Because the project’s UI is text-based on the command-line, the interface supports tab-completion through the whole project. This is immensely useful when you are browsing the plethora of modules or trying to tab-complete the random IDs assigned to callbacks when they first check-in.

The Downsides

Because this isn’t a project for profit, all of the developers are working full time, so it’s easy for the documentation to lag behind (nobody likes doing this part anyway). Similarly, the time for issues to be fixed or pull requests to be merged in varies depending on how much ‘free’ time all of the developers have. Remember, this is a completely free project, so you have to give people time to work on this! Be respectful!

The current interface for the project is all text-based in the terminal. Because of this, it’s prone to some common terminal-based issues. For example, you can run into odd line-overwriting issues if you start doing up/down arrows. You’ll also run into issues where you’re typing and the interface returns information asynchronously back to you, which will split up your line.

Currently, the project does not support multiple users at the same time via the text-based interface. Multiple users can hit the RESTful interface at the same time, but it doesn’t do tracking for what individual users are doing.

The project’s only reporting mechanism is via the RESTful API to get back JSON blobs for tasking. There is currently no automatic report generation.

Apfell

Apfell is the new, open-source, post-exploit, red teaming framework I’m designing for use with macOS. It’s currently just something I work on in my free time to try to address some of the things I wish existed in the current frameworks I use.

User/Implant Tracking

This is one of the main reasons why I’m making a new framework - I want to be able to track callbacks and operators throughout operations. There have been many times while operating that what appeared to be random callbacks would just appear, and I would have to stop what I was doing to track down who created the callback and where it came from. It’s difficult to track when a callback comes in from a spearphish, from a persistence mechanism, from being spawned by a current implant, from a lateral movement technique, etc. It’s also difficult to track who is creating the callbacks or implants. Due to this difficulty of tracking, we often just see callbacks as a list (which can get very overwhelming). Instead, I want to view callbacks (with this new data) in more of a process-tree format with specific, automatic tagging to know how I just got that callback. This will also allow me to track who created what implant, how, when, and track it throughout operations. In Apfell, you’ll already notice that there’s an “Operator” column in the main operations page - this is to help support this effort.

A bigger effort along the same lines is to create the idea of ‘operations’. There’s already lots of work with redirectors to make sure you don’t have to reroll your actual back-end infrastructure, so why not make the back-end infrastructure handle multiple operations? By tracking users specifically with their own unique username and password, I can create larger operations where users are assigned. This provides more of a lead operator management interface to assign operators to specific operations and track everything related to that operation together. This also allows a viewpoint of tradecraft, operators, and usage across multiple operations pretty easily.

Analytic Dashboard

Following along from the previous point, I want to create an analytic dashboard to show information about the current operation or any set of operations. This will include information about the frequency of techniques used (by operation, overall, machine, callback, or operator), how active operators are, how successful spearphishing campaigns are, speed of operations, amount of data sent/received, and much more. The goal of this is for red teamers, red team leads, or managers to view higher level details about operations at a glance to influence tradecraft, future operations planning, and broader situational awareness.

Complete Storage

All of the information throughout any operation is stored within a persistent database. This means that all users see the same information because they’ll only see whats reflected in the database. This also means that even if the server crashes for some reason, all of the data is preserved in the database and will be reloaded when the server starts back up again. This also limits the need to have a massive amount of RAM on the server because it’s all stored in a database and only what’s needed is pulled into memory.

Multiple C2 channels simultaneously

Currently, Apfell’s C2 channel is all RESTful interface interactions. Ideally though, I want the back-end server to be able to handle any number of different C2 protocols at once. One of the features of the callbacks will be that they can swap out their current C2 mechanism as needed as well. The goal is to allow this kind of callback modification without having to do anything overly complicated. For the back-end, you can currently write your own program in any language to handle your specialized C2, then translate that into the appropriate RESTful requests, but that will become smoother in the future.

Broad Access

By having the main operator interface viewable from a browser, users don’t have to install anything specific onto their normal computers to be able to access it. It should easily be accessible to anything with a modern browser. The hard part will be making it easily usable from smaller screens (like on a phone), but from bigger screens (like desktop and tablets) it should be easy.

Reporting

Since one of my main goals is to make this framework work for operators, managers, and research purposes, reporting is a main artifact of that. I will create a reporting interface to expose the underlying database so that the information can be pulled, sorted, and formatted to anything the user wants. In the meantime though, the first step is to generate a few simple reporting features that help describe what happened during an operation, across operations, with a specific user, on a specific host, or by operator. The techniques will also be mapped to MITRE’s ATT&CK framework in the future.

Downsides that can’t be addressed

Similar to Empire, this is just something I’m working on in my free time. Thus, I’m sure documentation, issue fixes, and requests will take a while to be addressed. This is just a side effect of working on an open source project. Apfell also relies on a bunch of other different projects - if any of those projects have issues, they’ll flow downstream to this project as well. I’ll try to make sure they’re called out in the main README.md file though.

Also, due to limitations, Apfell cannot support anything other than macOS. Maybe in the future it’ll be able to handle callbacks and operate with other operating systems.

This also has a bit more of a footprint on the server than some other projects because I force everything through the database.

Conclusion

This was a little long for a post, but I wanted to go through some current frameworks and some future design decisions of Apfell to explain why I’m introducing yet another framework into the world. As I have time, I’d like to also update this with more frameworks as I get a chance to use them.