[Studying] Inside Different Generations of RATs (1990s-2000s)

First Post:

Last Update:

Word Count:
500

Read Time:
3 min

Abstract

This article is part of my series: Inside Different Generations of RATs. If you are interested in the full series, please refer to the linked article above.

At the time of writing, I have posted six articles (the last one is coming soon!) on reverse engineering different generations of remote access trojans (RATs).

I decided to write this article as a summary and conclusion of these works.

Early RAT (1990s)

Examples:

Characteristics of these RATs include transferring data in plain text without any protection (except Back Orifice, which could be cracked). Most RATs of this era were written in Delphi or VB6.

As mentioned in my previous articles, the attacker’s side acts as the client in the network architecture, while the compromised machine acts as the server.

These RATs generate payload executables using a static patch method, which directly modifies the data (e.g., IPv4 address and binding port) of an existing server stub.

Commerical and Blackhat Malware (2000s)

Examples:

Compare to the previous generation, this RAT tools include a builder and are usually packed with UPX. They also have more advanced features, such as DLL injection, API hooking, remote plugins, and persistence techniques.

The principle of remote plugins is uploading the PE file (.*exe or *.dll) to the compromised machine and executing it, or loading it via LoadLibraryA.

Additionally, they often implement a mutex feature to prevent multiple instances of the payload from running simultaneously.

Terminologies

The term “Server” might be confusing from a modern perspective. In early-generation RATs, a “server” executable referred to the payload deployed on the victim machine, while a “client” referred to the application used to control the victim machines. As firewall technologies evolved and network security improved, attackers gradually shifted from direct connections to reverse connections.

Even today, some authors still use the term “server” for a payload that acts as a client from an internet architecture perspective. This is because “server” can refer to the role that provides services to a user (client). This is similar to how the terms “upload” and “download” are used.

Personal Idea

One thing that surprised me is the creativity and ingenuity of the authors. They had already implemented many “fun features” and injection techniques in their tools.

During the process, I learned that reverse engineering a payload is not particularly difficult, but unpacking it can be challenging. Additionally, instead of learning to use a thousand different tools, it is more effective to master one tool.

What Is Next?

This concludes the series summary. So… is this the end of the series?

Of course not! This is just the beginning. Conducting reverse engineering on early RATs has given me a lot of experience and improved my skills. In the next article of this series, I will start analyzing the next generation of RATs, such as Gh0st and njRAT (the whole family).

THANKS FOR READING

≡