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