Konstantin Seliadtsou


## Project Background

### Description

Meduza C2 is a modular, collaborative Command and Control framework developed using Golang (server), C# (agent), and ReactJS (client). The project has been in development for a relatively short time, initially aiming to rewrite an older C2 project created by ksel172 in C# and Blazor.

### Features

The project consists of three main components and aims to implement the following features:

- **Containerized and easy-to-deploy framework** with extensive customizability
- **Multiplayer command and control**, allowing teams and roles for users
- **Payload compilation using the .NET framework**
- **Dynamic module loading for agents**, featuring dependency resolution and streamlined development with the [ModuleBase NuGet package](https://github.com/ksel172/Meduza.Agent.ModuleBase)
- **Support for multiple listener types**, including external listener implementation
- **External agent support**
- **Intuitive and easy to navigate user interface** coded in ReactJS
- **Built-in MITRE ATT&CK visualization**, providing easy access to adversary tactics and techniques
- **Multi-platform support**, ensuring compatibility across different operating systems
- **Encrypted communication** using AES 256 bit with message integrity verification and TLS/SSL support

### Architecture

![image displaying the basic moving components of the framework](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/C2-architecture.jpg)

---

## Demo

> **Note:** The functionality will be previewed using Postman to interact with the teamserver API, as the client-server communication is not fully implemented in this milestone (v0.3).

### Startup

#### Requirements:

- Docker
- .NET 8 Runtime
- npm

#### Starting the Server

The server's Docker Compose configuration includes four containers and a volume:

- **teamserver** – Main server container
- **postgres** – Database
- **redis** – Used for caching and pub/sub functionality
- **pgadmin** – Database management interface

The server can be started using the following command, with a `.env` file containing the necessary configuration:

```shell
docker compose --env-file .env.dev up --force-recreate --build
```
![running the docker compose command](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/teamserver-build.png)

Currently, the following arguments can be configured in the server `.env` file:

```shell
# teamserver conf
TEAMSERVER_HOSTNAME=teamserver
TEAMSERVER_PORT=8080

# Possible values: dev || debug
TEAMSERVER_MODE=dev

# golang debug
DLV_PORT=2345

# listener exposed port range
LISTENER_PORT_RANGE_START=8000
LISTENER_PORT_RANGE_END=8010

# postgres
POSTGRES_HOST=meduza-db
POSTGRES_PORT=5432
POSTGRES_NAME=postgres
POSTGRES_PASSWORD=postgres
POSTGRES_USER=postgres
POSTGRES_DB=meduza-db
POSTGRES_SCHEMA=meduza_schema

# redis
REDIS_HOST=meduza-redis
REDIS_PORT=6379
REDIS_PASSWORD=redis

# pgadmin
PGADMIN_DEFAULT_EMAIL=admin@meduza.dev
PGADMIN_DEFAULT_PASSWORD=10tacles

# jwt secret
JWT_SECRET=<some_secret>

# refresh token cookie 
COOKIE_PATH=/
COOKIE_DOMAIN=localhost 
REFRESH_SECURE=false
REFRESH_HTTP=true

MODULE_UPLOAD_PATH=./teamserver/modules
```

#### Starting the Client

Navigate to the client folder and run:

```shell
npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev
```

#### Running an Agent

After a payload is compiled (as will be shown in Usage), the executable can be downloaded and transported to the target, or it can be used in combination with a loader to stage the payload. After it is executed, an agent is registered along with agent_info, agent_config (inheriting the payload_config), and agent_task.

### Usage

#### Authenticating as a User

In the image below, I authenticate as the default admin user `Meduza:Meduza` and obtain the auth token, which I set across my Postman requests as the Bearer.
![authentication using the default admin](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/teamserver-auth.png)

The user interface (already functional sign-in during v0.3):
![authentication user interface](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/auth-ui.png)

#### Starting a Listener

To start a listener, we first need to create it. Based on the listener type, we get different configuration options for listener-agent communication. In this case, v0.3 only supports HTTP listeners. However, the logic has been written for resolving other listener types and will be completed in the next version.

Below, I created an HTTP listener with a basic configuration:
![creation of an http listener](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/listener-create.png)

After creating the listener, we can get its ID and start it:
![get listeners](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/get-listeners.png)

![starting a listener](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/start-listener.png)

Which looks like this in the server log:
![logger showing listener starting](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/listener-start-cli.png)

Listener creation also works in the user interface in v0.3:
![listener creation user interface](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/listener-ui.png)

#### Running Shell Commands

Once an agent is created and registered, we can start running commands (sending tasks to the agent). There are several command types to choose from. The most basic one is the `shell` command, which executes a command in the cmd using the `/c` prepend.

Here we will run a list directory command:
![setting a shell task](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/set-shell-task.png)

#### Uploading Modules

One of the main goals of the project is modularity. Once a module is developed, it can be packaged and released on GitHub. We will be using the following example: [Meduza.ListDirectory](https://github.com/ksel172/Meduza.ListDirectory).

Once we have installed the release of the module, we can upload the `.zip` to the server:
![uploading a module](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/module-upload.png)

The module will be extracted and saved on the teamserver under `/modules/*`:
![uploaded module](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/module-file.png)

#### Running Module Commands

After a module is uploaded, we can utilize the commands that come with it. Commands can be listed using a `help` command in the terminal (which isn't functional yet in v0.3). In the future, the `ModuleName.json` file will be enumerated, and the usage, as well as other module metadata, will be easily accessible on the teamserver.

Below, we will use the ListDirectory module command from the `Meduza.ListDirectory` module:
![setting a module task](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/set-module-task.png)

#### Command Output

Once a command is executed, the agent will contact the server with the command output. Below, we can see the output of both commands that we ran prior, using pgadmin:
![command output](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/task-output.png)

User Interface for the terminal:
![agent page](/assets/img/blogs/2025-2-9-meduza-version-0.3-demo/agent-page.png)

## Module Development

### Module Base

Modules utilize the [ModuleBase NuGet package](https://github.com/ksel172/Meduza.Agent.ModuleBase) to easily create and release modules for the Meduza framework. The Module Base allows the agent to load any external assemblies that integrate the interfaces that are provided.

### ListDirectory Module

The project referenced earlier, [Meduza.ListDirectory](https://github.com/ksel172/Meduza.ListDirectory), is an example of how a module can be developed, packaged, and deployed.

Meduza Framework v0.3 Demo


#### Description: This packet capture seems to show some suspicious traffic

## Challenge

When we start with the challenge we are greeted by a pcap file with surprisingly very little traffic.
![PCAP Capture](/assets/img/blogs/2024-11-18-keep-tryin-HTB/image1.png)

Two specific requests immediately stand out:
- POST request to `/lootz`
- POST request to `/flag`

The other eye-catching packets are the first 4 DNS packets at the beginning of the capture.

Starting off I checked the request to ``lootz`` by viewing the whole TCP stream. 
![/lootz](/assets/img/blogs/2024-11-18-keep-tryin-HTB/image2.png)

Decoding the base64 gives us the following result:
```bash
┌──(kali)-[~]
└─$ echo "S2VlcCB0cnlpbmcsIGJ1ZmZ5Cg==" | base64 -d
Keep trying, buffy
```

Hmm, not too helpful. Next I checked out the POST request to ``/flag``:
![/flag](/assets/img/blogs/2024-11-18-keep-tryin-HTB/image3.png)

TryHarder? Ok... Let's see what that is. 
![packet](/assets/img/blogs/2024-11-18-keep-tryin-HTB/image4.png)

Looking at the bottom of the request we see that the value belongs to a form with the value ``Key:``, this might be useful.

Continuing onwards I decided to check out the DNS requests. First I followed a stream which seems to have more base64 embedded in a TXT record.
![packet](/assets/img/blogs/2024-11-18-keep-tryin-HTB/image5.png)

```bash
┌──(kali)-[~]
└─$ echo "c2VjcmV0LnR4dHwx" | base64 -d
secret.txt|1
```

That's interesting! Seems like a name of a file but considering it's in a request it might be a header from a file! Let's continue and see where this brings us.
![packet](/assets/img/blogs/2024-11-18-keep-tryin-HTB/image6.png)

This stream also has a TXT record with base64, however when I extracted the base64 and tried decoding it, I got random characters, meaning it's probably encrypted.
![packet](/assets/img/blogs/2024-11-18-keep-tryin-HTB/image7.png)

It's encrypted. First I changed my base64 to urlsafeB64 considering the format and after thinking of a few options I remembered the ``Key`` value we find earlier with the contents ``TryHarder``. After trying and failing a few encryptions in CyberChef I reached RC4 and got a result!
![result](/assets/img/blogs/2024-11-18-keep-tryin-HTB/image8.png)

This definitely looks like it might be a file! Using the inbuilt download function in CyberChef I downloaded the file and it gave me the secret.txt file.
![secret.txt](/assets/img/blogs/2024-11-18-keep-tryin-HTB/image9.png)

And we get the flag.

HTB Challenge: Keep Tryin (Forensics Challenge)

Vladimir Seliadtsou


## Resources

The measurements are done using 2 Shelly PM Mini Gen 3 power meters. The installation for these power meters is intrusive but there are non-intrusive alternatives like the Shelly Pro 3EM. A different power meter manufacturer can be used, as well as a mix of different manufacturers.

The broker platform being used is EMQX. EMQX is rich in integrations letting us route data to a local or cloud database instance or directly as an HTTP request to a webhook. It can also be used to route data to other applications for processing.

The data is routed from EMQX to Redis via Upstash. Redis is a key-value NoSQL database that supports different data formats. I have used Redis objects, but JSON can also be used. Upstash is a serverless data platform which I used for our integration with Redis. EMQX also supports routing to other cloud data-streaming services. I have made an example by routing data from EMQX to Azure Event Hub to prove its support with other systems that can be used for the centralization of the system.

For pulling and displaying the data I made a .NET application (the language being of no importance, because we are only required to support Redis to pull from a remote endpoint). Jedis can be used to make an implementation in Java.

## Background

This project has been an idea for a while but I took action on its actual development after my relocation to a new apartment where I set up a boiler and an AC, the energy consumption of which, had me very interested. After doing some research and using my background from studying electrotechnics, I quickly found several options for taking measurements for energy consumption.

After deciding to go with the cheaper and more intrusive alternative, I bought 2 Shelly PM Mini Gen 3s, which are usually installed in a socket to measure the consumption out of it. Instead, I figured out how to set it in my apartment's main distribution panel. After installing the Shellies and configuring all the details, I visited the control panel at `https://control.shelly.cloud/`.

The data was insightful indeed but it sparked me with a new idea - what if I connect the device to an MQTT Broker (the main protocol the shellies, and most smart meters use, as any other smart device, is MQTT). From there I got the idea to collect and pipe the data to the cloud where I'd store it and then create another client to retrieve the information and display it locally. This not only allows to collect data remotely like shelly cloud does, but it also allows the user to mix and match different smart meter manufacturers into one platform.

## Process

After the initial configurations I took my time to research the topic. The documentation was quite limited but I did discover a few ways I could make my idea work with Azure IoT hubs. Attempting to do so I learned a very important thing about shelly devices - they have functionality for SSL/TLS certificates, but it doesn't work.

Struggling with getting it to work with Azure Hubs I gave up and decided to test the shellies as a whole in terms of their MQTT connectivity. After using the HiveMQ public MQTT broker I managed to establish a connection and concluded I'd need to try something else. Experimentation led me to EMQX.

In the meantime I also made the great discovery of Shelly scripts. From there I coded a script for automating the power usage collection and sending it via MQTT to the desired topic. The data is collected and sent precisely every hour for the desired time zone.

```javascript
if (lastHourTimestamp === 0) {
    lastHourTimestamp = Math.floor(currentTimestamp / 3600) * 3600;
}
  
hourlyEnergyTotal += currentEnergy - lastEnergyReading;
hourlyRetEnergyTotal += currentRetEnergy - lastRetEnergyReading;
if (currentTimestamp >= lastHourTimestamp + 3600) {
    publishHourlyUsage();
    hourlyEnergyTotal = 0;
    hourlyRetEnergyTotal = 0;
    lastHourTimestamp = Math.floor(currentTimestamp / 3600) * 3600;
}
  
lastEnergyReading = currentEnergy;
lastRetEnergyReading = currentRetEnergy;
}

function publishHourlyUsage() {
    if (MQTT.isConnected()) {
        let status = {
            operational: true,
            id: Shelly.getDeviceInfo().id,
            mac: Shelly.getDeviceInfo().mac,
            fw_ver: Shelly.getDeviceInfo().ver,
            hourly_energy_usage: hourlyEnergyTotal,
            hourly_ret_energy_usage: hourlyRetEnergyTotal,
            timestamp: lastHourTimestamp
        };
        MQTT.publish("/system/" + Shelly.getDeviceInfo().id + "/status", JSON.stringify(status), 0, false);
    } else {
        console.log("MQTT not connected. Skipping publish.");
    }
}

Timer.set(60 * 1000, true, updateHourlyUsage);
```

Using this script I configured a few pubsub routes on the remote MQTT broker (EMQX) and experimented with different options for the script. I used a feature in EMQX called a "sink" to pipe the data to my remote database which I hosted in upstash.

For the body I used this pattern:
```json
{
    "fw_ver": "1.4.0-beta1",
    "hourly_energy_usage": 564.559,
    "hourly_ret_energy_usage": 0,
    "id": "shellypmminig3-ecda3bc4ddb0",
    "mac": "ECDA3BC4DDB0",
    "operational": true,
    "timestamp": 1720717200
}
```

For data I used the following key format:
```
prefix:devicemac_timestamp
```

For the device and device script I used:
```
device:devicemac
script:devicemac
```

After that I made a basic app in C# (not the prettiest but it was meant as a PoC) to pull the data from Redis. Getting the final result was definitely relieving since I've skipped many of the problems I've encountered along the way, especially due to the lack of documentation. At the end I also succeeded to push data to Azure Event Hubs.

## Automation

### Concept

Automation is the process of removing the need of manual user configurations via application programming interfaces (API) or any other methods of transferring configurations. Automation features 3 main components:

- **Configuration interface**: The page where all the configuration details are entered by the user.
- **Transferring application**: Whatever method is used for transferring the configuration to its destination. In this case an MQTT broker is used in combination with the Shelly API/RPC components.
- **Accepting Interface**: Protocol that will accept, parse and write the data to the device. Shelly API/RPC as mentioned above.

The automation should be capable of automating both registration/integration, as well as updating/support and configuration. Successfully creating such automation for the product will increase the product marketability by making it more appealing to users with less knowledge and experience with technology.

Another benefit of automation is that it simplifies the installation and management of big electrical installations. For instance, if a customer makes an installation of a 100+ devices and wants to update the firmware, it will be tedious to do so without proper automation of the process. The same applies to any sort of configurations or changes to the devices.

### Process

The process is split into 3 steps:

1. **Initial network setup and configuration** of the device. A customer can connect a meter device either himself/herself or by hiring a professional to do it. After installing the measuring device and integrating it with the application, the initial configuration will be sent to the measuring device using the Shelly RPC API. The Shelly RPC (Remote Procedure Calls) API is an API component for configuration and management of Shelly devices. Called with:

   ```
   http://<ip>/rpc/Component.Option
   ```

   Using `/rpc/MQTT.Option`, MQTT can be configured from the web page, easiest way being sending a config using `/rpc/MQTT.SetConfig` with the config parameter to upload the configuration made in the user interface to the device.

   For uploading a custom script to the Shelly device `/rpc/Script.Create`, `/rpc/Script.PutCode` and `/rpc/Script.Start` can be used to create the script, upload the code and start the script respectively.

   Additionally, information about the Shelly can be gathered using `/rpc/Shelly.GetDeviceInfo` and `/rpc/Shelly.GetStatus` for the status of the device.

   SSL/TLS certificates and keys can be uploaded to the Shelly device using `/rpc/Shelly.PutTLSClientCert`, `/rpc/Shelly.PutTLSClientKey` or a bundle with `/rpc/Shelly.PutUserCA`.

2. **Support and updates** for the device are necessary throughout its lifespan. By having a configuration interface in our application, we can easily carry out any updates or push configurations to the devices using the method specified above. Making these changes involves having our scripts and configurations stored without the variable data (unless the configuration already exists). When the client decides to create/modify a configuration, the application pulls/creates the configuration and replaces the values that are needed from the UI. Once that is done the configuration is sent to the device and uploaded. Firmware updates can be carried automatically or manually depending on user preference the same way.

3. **Continuous logging** is important to keep the user informed about the device's integrity and events. Thankfully, this can also be done due to Shelly's implementation of logs accessible at `<clientID>/debug/log`.

![BarChart](/assets/img/blogs/2024-11-18-building-smart-home-energy-monitor/barchart_image.png)
![Devices](/assets/img/blogs/2024-11-18-building-smart-home-energy-monitor/devices_image.png)
![Metrics](/assets/img/blogs/2024-11-18-building-smart-home-energy-monitor/metrics_image.png)

## Final Thoughts

This project ended up being a little internship project for me and I wrote a big PoC document with more details on the process. I am pleased with the result and would love doing something like this again. Thank you for reading!

Smart Home Energy Monitor with Shelly Devices PoC

Konstantin Seliadtsou

Articles by Konstantin Seliadtsou

Meduza Framework v0.3 Demo

HTB Challenge: Keep Tryin (Forensics Challenge)

Smart Home Energy Monitor with Shelly Devices PoC