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.
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.
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.
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:
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:
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.
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.
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.
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.
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!
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.