Mimic

# Mimic Command and Control Framework

## Introduction
This file contains the documentation of the **Mimic** Command and Control Framework.
This framework is private and designed for educational purposes. This is the only documentation existing about this framework.

A C2 framework allows an attacker to communicate with the compromised victim machines after a successful cyber intrusion.

Implants are executables generated by the C2 framework to create a backdoor.
The operator of the C2 framework (attacker) needs to drop, install and start the execution of the implant himself.

Mimic is designed to blend its network traffic in the usual HTTP traffic. To ensure that it is not easily detectable, it also uses real webpage and a python Flask server to mimic a real website activity.


## Server
The server is a simple python Flask server. Flask is a framework designed to help developers to make a web server in a few lines of code. It also uses template system allowing developers to easily make HTML page dynamically inside the server. This template system can be somehow compared to the EJS system used by Node.js .

The server runs a second thread. This thread is an operator interface allowing the attacker to send command to the implant.
As it is only for educational purposes, if a command is entered it will be send in the next HTTP response. It doesn't care about the target IP, nor check if the target is an implant or a web user.

In the webpage sent to the implant in the HTTP response the server add several available links. These links are a list of potential next target for the implant.



## Implant
The Mimic's implant is designed to mimic a web user browsing the website on the Mimic's server. 

The first HTTP request of the Mimic's implant at start is always for the target "/" or the target "/home"
To ensures that the browsing mimic an usual user behavior, the implant will select the next URI in the webpage received in the HTTP response.

The Mimic's implant uses a heartbeat system with randomly selected interval. By default these intervals are between 3 seconds and 15 seconds.
The implant only uses URIs from the appropriate dictionary. These dictionary are split into URIs used with the GET method, and URIs used with POST method. The method chosen depends if data need to send to the server, in this case the implant uses the POST method, or not and then uses the GET method.

## Accepted Commands
- *ls*: The implant will list the working directory content and send it to the server in a POST request.
- *create*: The implant will create a file, not data are exfiltrated during this process.
- *screen*: The implant will take a screenshot and send it to the server in a POST request.
- *kill*: The implant will stop its processes and stop sending HTTP request.


## Server and Implant Behaviors
- The implant is started in the compromised device. It directly send a HTTP request for the "/" or "/home" URI after its setup. 
- The server receiving the HTTP request will answer with the appropriate webpage, assuming that no command are in the queue before the first connection. The webpage sent in the HTTP response contains link that are in the dictionaries of the implant, also as other link that are not in these dictionaries. 
- The implant receiving this first HTTP response will match the URI that are in the dictionaries associated to the GET method to sort useful and useless URIs. Then randomly choose one link in the filtered URIs set and sent the HTTP request. Assume the time between two HTTP request depends on a timer that is randomly chosen between, by default, 3 seconds and 15 seconds. This assertion is True for all HTTP requests sent by the implant.
- In the same time the operator of the server add a command *ls* to the queue. This command is intended to respond with data containing the *ls* linux command result of the working directory.
- The server receives the second HTTP request and prepare the webpage to send. As a command is in the queue, it will be popped out this queue and added in an hidden div in the webpage. The webpage filled with the command *ls* is finally send in the HTTP response.
- The implant receive this second webpage, analyze if a command is present. In this case it will find the *ls* command and then execute it. The result of the *ls* need to be send to the server. For this it will choose a link that match these in the dictionary associated to the POST method. Then prepare a HTTP POST request with the result data and send it to the server.
- The server receives these data and print it in the operator interface directly. Then it sends a webpage with no command as the queue is empty.
- The implant receives this webpage, choose a correct link for the next HTTP GET request and send the next HTTP requests with the appropriate URI.
- After a certain time, the operator wanted to kill the implant to avoid beacon to be detected, he add the command *kill* to the queue and the server send it in the next HTTP response it will send.
- The implant receiving this command will kill its processes and stop sending HTTP request.

## Dictionaries