TheAllCommander: Revolutionizing C2 Communication Modeling
TheAllCommander
Framework for modeling and researching C2 communications for developing efficient filtering and detection logic.
TheAllCommander 2.1 (April 2024) includes support for logging telemetry data gathered from test daemons, as well as alpha support for PyInstaller deployment and installation as a Windows service. Featured in DEFCON Demolabs 2022!!!!
Hidden Users
Why TheAllCommander?
TheAllCommander allows researchers to easily develop their 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 environment’s 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 not 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 inputting 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.
Install & Use
Copyright (C) 2024 matt-handy
