Beiträge von Megapanzer

The lifecycle of a trojan horse

2009-03-17 15:03:58 by carrumba

Summarizing the lifecycle of a trojan horse as “configuration, infection, action, deletion” would be too brief
and you would miss a lot of important and valuable information that makes you understand how they are
constructed, how the internal structure looks like and how to breathe life into them. I want to give you the
whole, big picture of the trojan horse lifecycle, beginning from the stage of configuration over to its deletion
and all the steps in between.

Trojan horse configuration and generation

What a trojan horse needs first are its configuration settings. The information it knows what to do once it is
executed on the target system. At this point we have to know the trojan horse is divided into two different
parts: the client and the server. The server is the part that is installed on the victims systems, the client is the
controlling component on at the attackers side.

[SERVER]
|
[SERVER] | [SERVER]
\ | /
\ | /
\ | /
[ATTACKER CLIENT]-----[SERVER]

The names server and client in this context are a little confusing because normally a client is the one that
connects to a server and sends commands to it. This is the way the setup was in use some years ago. The
attackers on the client machines connected to the servers on the infected victim machines. But nowadays it
works exactly the opposite. The infected victim systems establish a reverse connection to the controlling
master system. The reason why it works today like this lies in the history; since the Internet access providers
and the hardware vendors began selling only NAT routers with integrated firewall functionality and the
computers were equipped with desktop firewalls. From then on it was impossible to an attacker to connect to
their servers on the victim systems. A new technique was needed and so the malware developers decided to
let the infected systems establish a reverse connection to their controlling system. But instead of changing
the notation of client and server that way it makes sense again (in networking terminology a client normally
connects to the server) they kept it as it was and changed the notation how the connection is established,
namely in reverse, a reverse connection.

1. Normally, integrated into the client, you find a tool with which an attacker builds and configures a new
trojan packet. Settings like the clients hostname to which the server has to connect back, the servers ID to
recognize it after it was installed on the system, whether to install it on the target system at all or execute it
only and let it disappear after the reboot, how to start it automatically after a reboot (via registry, as a service
etc.) amongst other things. So first the configuration GUI on the client takes a raw, unconfigured damage
routine and customizes it according the attackers settings.

2. The second component that is configured by the configuration GUI is the dropper. The dropper is the part
in a trojanized packet that installs the damage routine on the target system. It saves it in a safe place on the
targets file system, it ignites it and also makes sure it gets started automatically after a system reboot.

3. The last step the configuration GUI performs is to join/bind the previously configured damage routine, the
dropper and the last piece I didn’t mention so far: the entertainer file which the victim is expecting to see
when double clicking the trojanized file.

Propagate and drop the malware

Once the trojan horse is configured and all the components are merged and glued together to one package
the next step is to propagate it. It depends on the creativity of an attacker how to release the package into
the wild and how to convince the big mass of victim(s) to execute it. Some common ways are …

• Sending it via email and pretending to be a familiar person

• Sending a victim an email with a link to a homepage containing malicious content that installs the
trojan automatically
• Spread it in file sharing networks to install it on random victims computer

This are only some few examples to show which ways exist at all but I will go into the details later in an other
article/chapter dedicated especially to this subject.

Executing the dropper

1. After the package reaches the victims machine and was executed the dropper component becomes active
first. The dropper extracts the damage routine and the entertainer to the victims harddrive.

2. After extracting them it has to decide what happens with the damage routine, i.e. where to put it exactly.
Has it to be copied to a specific directory and do we have to execute it? For example, we don’t have to
execute a simple hosts file (with our new bogus host name entries) that contains only text data. A password
recovery routine instead we have to execute.

3. The dropper has to decide whether it is necessary to start the damage routine automatically after a reboot.
If the dropper was configured to do so there are several ways to do it as for example using the Windows ini
files, the system registry etc. I don’t go deeper into this subject here because it would be to much information
and has to be covered in a separate chapter/article.

4. If everything is installed and configured according the attackers wishes the last thing the dropper has to do
before deleting itself is to start the entertainer file. This is necessary so everything behaves as expected and
the victim doesn’t become suspicious.

Executing the damage routine

After the dropper has finished the installation it is up to the damage routine to do its job. Silently, in the
background, without attracting the victims attention, collecting sensitive information as account information,
documents, emails, the browser history file, modifying system settings, etc. But also here I don’t go into the
details what the damage routine does exactly and how it does it. I will cover this subject later in an other
chapter/article.

Removing the malware

At the end of any lifecycle there is normally the death of the object. There are two ways the life of a trojan
horse will finish :

1. The trojan horse has finished its work and removes all the files it generated over time it was running on a
target system, cleans the system log file entries and just making sure no traces are left after removal. At the
very end it deletes itself from the system. The trojan horse commits suicide.

2. The trojan horse was not able to avoid detection on a target system and a copy of the damage routine was
sent to a AV (Anti Virus) company to analyze its behaviour and subsequently create a fingerprint. The
fingerprint pattern is sent to the AV company customers and the trojan horse will finally be detected, stopped
and removed from the system. The trojan horse gets murdered.