Disclaimer even though I may talk about creating “trojans” and “malware”, the purpose is to create software for legal activity such as testing the security of networks and computers where you have explicit permission to do so. I do not condone any illegal activity.
I am writing this blog as I started developing a RAT during the spring of 2020 and wanted a place to document my ideas and progress with this project. This is something I have been planning on doing for a couple of years, but I did not get around to actually writing any code until this spring.
RustRAT is as its name suggests, a Remote Access Trojan written in rust, and even though it is not included in the name, lua. The idea is to use rust for initialization and some necessary functionality, but keep as much as possible of the functionality in lua. Implementing functionality in lua makes it possible to change the functionality at any time, even while the executable is running. It also makes it possible to keep the size of the initial executable small, as most of the functionality can be loaded at a later time by sending the RAT lua source or bytecode.
There are other ways to achieve this, but this is an attempt to decrease the amount of “scary” actions the RAT has to do before any useful work can be done. With liblua, there is no need to allocate additional executable memory to execute the received code.1 It also avoids having to worry about things like AMSI that might be an issue in the .net world. This approach will come with its own host of problems, but I do not yet know how large and how many those problems are going to be.
Initially, the RAT will only target Windows. However, I am hoping to keep as much code as possible platform agnostic in the hope that this will make it easier to port the RAT to other operating systems in the future.
Some parts of RustRAT are planned in advance, but I will mostly be going along implementing whatever I find interesting at the time. I will be publishing new posts as development on RustRAT continues, and also releasing all the source code on GitHub.
Be sure to check in later for my first post on developing RustRAT, which will be me gluing liblua and libffi together with rust. If a shared library has to be loaded into memory it is not possible to avoid allocating executable memory entirely, but I do not know of any way to avoid that if you want to load a new shared library. ↩︎
If a shared library has to be loaded into memory it is not possible to avoid allocating executable memory entirely, but I do not know of any way to avoid that if you want to load a new shared library. ↩︎