AKSH - Dancing through clouds
Hello World - Love, AKSH
Necessity is the mother of invention. That’s how AKSH came into being.
When I created the course Red Team Adversary Emulation: Mimicking a real-world cyber attack, I wanted to provide a means to students to practice the attacks in a real-world lab. I wanted to do so without digging a hole in their pockets. I approached a few companies (well, one company TBH) which could make this possible but it didn’t work out. Left with no choice and a determined will to make it possible for students, I set out to learn how to create Discord bots and make them interact with AWS APIs. Lo and behold, AKSH appeared on the planet.
What is AKSH?
Before you think I am harboring an alien of some kind, I am not.
AKSH is a messaging bot that interfaces with AWS via APIs to automate various aspects of managing labs on AWS infrastructure. For example, through AKSH, students can deploy a lab in their own AWS account by issuing a single command (!deploy, that’s it). Behind the scences, AKSH will setup all the necessary lab components (VPC, subnets, gateways, security groups, EC2 instances etc.) without any human intervention. What’s more? AKSH can deploy [and manage] multiple labs (as and when I create more of them) of different complexities at the same time (!deploy -lab name-, that’s it).
Okay AKSH, What can you do?
AKSH features the core functionality students will need to self-manage a lab. Additionally, it also caters to few ancillary commands. Here’s the list of commands AKSH responds to:
Lab Management
!deploy - Deploy the lab.
!destroy - Destroy the lab.
!start - Start lab machines. This command takes in either a single machine name or ALL to start all machines.
!stop - Stop lab machines. This command takes in either a single machine name or ALL to stop all machines.
!reboot - Reboot lab machines. This command takes in either a single machine name or ALL to reboot all machines.
!revert - Revert lab machines to their original state. This command takes in either a single machine name or ALL to revert all machines.
Ancillary Commands
!list - Lists the name of all lab machines.
!status - Display the status of lab machines. This command takes in either a single machine name or ALL to list status of all machines.
!showinfo - Display lab access details.
!ss - Display real-time updates of a lab management operation. (Fun fact: This command was originally !showstatus but it was too much to type frequently, so I shortened it to !ss. Now you know what ss stands for.)
Core components of AKSH
The following five components spin like gears behind the scene and bring AKSH to [-virtual-] life:
Bot Listener - Receives user’s messages (or commands) via the messaging app API.
Lab Management Framework - Command framework that enables AKSH to understand user’s intent and invoke Compute Engine.
Lab Configuration Files (JSON) - Infrastructure as a Code (IaaC) file, written in JSON, containing a cloud lab’s architecture and configuration details. It is used by the Lab Management Framework and Compute Engine to translate user’s intent into compute actions.
Compute Engine - Translates user’s intent into compute actions, performs those actions via cloud service provider’s API and returns their result.
Compute Action - An operation that is performed at the cloud service provider’s end (e.g., launch a compute instance, terminate instance, create snapshots etc.).
How the magic happens?
Here’s how AKSH transforms a simple message into a full-fledged cloud lab (the above diagram will help you visualize this journey):
User sends a message - User uses the messaging app client (mobile or desktop) to send a message (aka command) to AKSH.
AKSH receives the message - The message travels from the messaging app client to the messaging app servers via their API. The messaging app servers delivers that message to the Bot Listener via another set of API.
Identifies the user intent - The Bot Listener hands-over that message to the Lab Management Framework. The Lab Management Frameworks identifies the user’s intent (i.e. the action user wants to perform on the cloud lab - deploy the lab, stop a machine, revert a machine etc.) and the lab configuration to be used. If the user has sent the name of the lab as part of the message, the corresponding lab configuration file will be used. If not, the default lab configuration file will be used.
Generates a set of compute actions - Based on the user’s intent and the lab configuration to be used, the Lab Management Framework invokes the Compute Engine to generate and execute a set of compute actions. A user intent may result in one or more compute actions.
Compute actions are performed - The Compute Engine performs the corresponding operation for each compute action at the cloud service provider’s end and returns the output (success / fail or a custom value). Compute actions are peformed in an ordered manner. The order of compute actions in a set is determined by the user intent. If any action in the set fails, the entire compute action set is considered as failed. A certain level of resiliency has been built-in into AKSH. It also provides other mechanisms to recover from failure.
Infers the result - Once the Compute Engine has finished performing all compute actions in the set or if the set has failed, it parses the output received from the cloud service provider’s end and passes it to the Lab Management Framework. The Lab Management Framework processes the parsed output and hands-over the result message to the Bot Listener.
AKSH communicates the result - The Bot Listner uses the messaging app API to deliver the result message to the messaging app servers. The messaging app server, in-turn, delivers the result message to the messaging app client (mobile or desktop) via API.
User receives the result - The messaging app client notifies the user of an incoming message. User sees the result message and decides what to do (or not to do) next.
End notes
If I am being honest, there’s nothing new happening here (except for using a messaging app for lab management). Infact, many of the lab management service providers and training providers probably use a similar (or even better) design. However, those service often come at a price that might not be affordable by everyone. I created AKSH to provide a pocket-friendly option to my students to work through a red team lab. If you are an instructor in a similar boat, feel free to leverage the above design to create your own lab management setup and reduce dependency on commercial service providers.
I am interested in trying out AKSH, where do I sign-up?
Currently, access to AKSH is restricted to students of the Red Team Adversary Emulation: Mimicking a real-world cyber attack course. If you have purchased or have been provided access to the course, please fill out the Red Team Adversary Emulation Lab - Self-hosting Prerequisites and Eligibility Form.