For me, it is the evolution of the Trojan Horse concept. It is, in these days, a complete package of trojanized system utilities, with some interesting add-on programs, like specially designed sniffers and, maybe the most dangerous or frightening, kernel modules whose primary objective is to hide certain processes, directories and/or files. Being at the kernel-level can be quite amusing. Imagine: it is the kernel which gives the ability to execute programs and manage filesystem security.

As system utilities and kernels evolve, so do rootkits. Especially the ones that make use of kernel modules. These are called LKM rootkits. Most rootkits used to be packaged as a set of pre-compiled binaries and an installation script that overwrite files.

As time went on, rootkits started to be a bit more complex at the installation stage: they included the source of the trojan utilities and kernel modules. That gave the attacker the ability to analyze the original utilities installed on the system and make the needed modifications to the trojanized ones. This was done to minimize the differences between the original binaries and the trojanized binaries. They also started requesting a “Master Password” that would be inserted into every compiled trojan. The
Master Password is used to access the special features of a trojan, like a passwordless root login.

Of course, a C compiler and a complete set of header files are needed. One way to thwart installation of these rootkits is to remove all development packages from a production system.

In any event, if the attacker now has the desired UID 0 then he can download and install the needed packages, or just use a pre-compiled rootkit. In both cases there are disadvantages to the cracker. But those disadvantages are advantages from the system administrator’s point of view.