Introducing RETURNINGPATIENT

In our previous post, Red Teaming: Command and Control protocols, we performed a very brief introduction of RETURNINGPATIENT in the general context of choosing different command and control strategies in our red teaming campaigns. In this post, we will take a deeper dive into RETURNINGPATIENT itself and discuss its properties and its limitations.

Architecture

RETURNINGPATIENT is a client-server based command and control framework. The implant is written in Mono C# and is designed to be easily deployable inside a targeted organisation, either by using the executable itself and embedding it in a social engineering attack vector or by using its source code directly ala msbuild. The server side of it is based on the web2py framework. It is a web2py application that can be deployed on an existing web2py installation.

Single purpose tool

RETURNINGPATIENT is a single purpose tool, no more and no less. While it can be extended, and it is designed to be extendable, when we were building it we wanted to address a specific need, that of having a covert, blendable, long haul channel back to our attack infrastructure.

DNS-based call back protocol

RETURNINGPATIENT uses DNS A and TXT records as a callback mechanism. It uses a user-configured call-back interval and jitter and checks back with a simple DNS request per its configuration. The overall exchange mechanism is the following:

• The web application allows the creation of campaigns with related implant details such as direct or recursive mode, server IP or authoritative domain, server encryption key, etc.
  The implant binary or source code will be downloaded from the web application itself. Note: Recursive mode requires the web application to run on a server registered as a DNS authoritative server for a user-controlled domain.
• Once the implant (referred to as the “client”) is executed on the target machine, it attempts to contact the server with a registration request.
  The registration request contains a client-generated session key, encrypted with the server public key. Depending on the selected mode, the behaviour will be:
  1. In direct mode, the implant sends DNS packets directly to the server IP address.
  2. In recursive mode, the implant appends the user-controlled domain to each packet and sends the requests to the local DNS server which will then forward the same to the user controlled-server.
• Upon a registration request, the server obtains the client session key and uses it to reply back with a unique user ID encrypted with the defined session key.
• If the client can successfully decrypt the server response, the key exchange succeeded and, the same key will be used for the next communication. The client will then provide the server with its hostname to complete the registration.
• Once a client is registered, it will poll the server at regular intervals to check if there is any instruction set for it.

Limited functionality

Having a single purpose defined as above means it does not support the full gamut of actions a red teamer will need but instead supports a very narrow use case. As such, there was no point in building advanced functionality to it but only the features used to support its use cases. Namely:

1. Call back: The implant uses this functionality to check back with the server and see if there are any pending actions to execute.
2. Execute command: It is used to execute a command on the workstation the implant is operating on. This can either be a shell command, a PowerShell command or a pre-existing executable on that workstation.
3. Download and execute file: In this functionality, the implant downloads and runs an executable on the workstation the implant resides on. In the vast majority of cases, this will be the new short-haul implant for that campaign.
4. Terminate the implant: Remotely shut down the implant when it is not needed anymore.

Multi-user and multi-campaign

The server side of RETURNINGPATIENT supports multiple users and multiple engagements running off it. As such, you can have multiple users working the same engagement, one user working various campaigns and any combination in between. To be fair, and given RETURNINGPATIENT’s purpose, we expect this to be the least used of its features - at least the multi-user aspect - but we used it since it was there, offered by the framework and imposed no real overhead to us and its development.

Data Encryption

The protocol of choice for communication is standard DNS over UDP. Therefore, there is no specific channel or content encryption by default. The aim of RETURNINGPATIENT is to provide enough protection in terms of confidentiality of data coming from the targeted machines.

An essential factor that was accounted for, while choosing the best encryption solution, was the ability to implement it within the implant without over-engineering it. Both symmetric and asymmetric encryption is used when setting up the session key. The implant has a hardcoded RSA public key that corresponds to a private key residing on the server. When the implant executes, it generates a session key and sends this to the server by encrypting it with the public key we discussed above. The new session key is used for the subsequent exchange of information between the server and the implant using AES in CBC mode.

Encryption does affect the performance of the tool in terms of DNS packets required for each command/response exchange. However, it guarantees the security of the exchanged information.

Please note that at this stage, files sent from the server to the client don’t get encrypted.

Usage Workflow

While we will not go into any details for the installation of RETURNINGPATIENT, you can get that from the project’s git directory, we would like to present a sample workflow below to help people get the hang of it more quickly.

Concept wise, Campaigns are the high-level containers of implants inside RETURNINGPATIENT. Hosts can be associated with a campaign, essentially belonging to the engagement related with that campaign. Implants are campaign specific. 

Campaign creation

From the dashboard, we can create a new campaign which will appear in the campaigns list.

By selecting the campaign from the list, we can edit its details and download the implant.

Note: You need to submit the campaign details and polling time at least once before being able to download the implant, as this is generated on those details. If the server will be used in direct mode, the IP address needs to be set in the Server Status menu before an implant can be downloaded.

Starting the server

In the Server Status menu, we can select a local interface to listen on, or specify a custom IP address if it’s not picked automatically. You need to submit the details at least once before you can start the server!

Implant execution and sample commands

With the server started (we can check its status from the campaign details too) we can download the implant as an exe binary and execute it on a target host.

Once the host connected back to the server, it will get listed in the “Unassociated host” of all the campaigns.

By clicking “Add”, we can associate it to our campaign and remove it from the unassociated list.

Note: each host can be associated with one campaign at a time.

Once the host is associated, we can click on it to get to the command page. Just typing a command and clicking on “Add Command” will add it to the queue of commands. The host will get the first each time it polls back to the server.

The command will then move to a “SENT” state and move to the Executed command list once the result is back. Clicking on the executed commands will show the results:

From the web interface, it is also possible to send files to a host or terminate the implant!

So that is for this post, we hope you get to play with RETURNINGPATIENT, use it in your red teaming engagements and have fun with it.

This blog post was written in collaboration with Zacharias Pigadas.