Persistence

The ability to detect and remove rootkits is getting better and better every day, but a well-placed reinstallation routine can thwart even the best of detectors. Installing a “main” rootkit using the Service Control Manager and an “auxiliary” rootkit using ZwSetSystemInformation with SystemLoadAndCallImage (described in the next section) will enable a rootkit to reinsert itself either immediately or after some delay once the auxiliary rootkit discovers that the main rootkit is no longer operating. A time delay here can be very useful because a delayed reappearance is usually much less noticeable than an immediate one.

The basic premise of a backup recovery system is to install the rootkit installation software in a location that cannot be determined from the discovery of the actual rootkit. That way, should the rootkit be discovered and removed, there will be no trace back to the software that originally installed it. If a second rootkit, doing nothing more than monitoring a named pipe for a heartbeat packet from the main rootkit, discovers that the main rootkit is no longer operational, it can then reinstall the main rootkit to restore operations.

Because the main rootkit must by design expose itself to many forms of detection, the possibility of detection and removal is much higher than that of a simple rootkit that only monitors a named pipe. Without hooks or any form of concealment, a secondary rootkit is not likely to be recognized as a rootkit and as such is not likely to be removed along with the primary rootkit.