Tamper Detection

Whatever the purpose of your rootkit, you can expect to encounter environments that attempt to defeat that purpose. The design goal cannot be total dominance over every environment; there are just too many variables, too many clever users, and too many new anti-rootkit technologies. The design goal should instead be the detection of noncompliance as quickly as possible.

The example in this chapter uses a continuous TCP/IP connection to verify compliance. If the connection is dropped and the client machine continues to respond to ping commands, there is a high likelihood of tampering. This is an easily implemented and nearly foolproof anti-tamper technique that relies upon the network administrator to investigate the reason for noncompliance.

Heartbeats are another great way to ensure compliance because a TCP/IP connection can remain open even though the rootkit is no longer operational. For example, a user might stop a service that’s used to route information to a rootkit. This will effectively disable the rootkit without closing the communication link to the controller, but if the rootkit is expecting periodic heartbeats (small communication bursts) from the service, then stopping the service will cause a condition of noncompliance that can be reported.

Heartbeats are also a great way to detect lost hooks. If your rootkit relies on hooks, periodically calling one of the hooked functions with a special parameter that causes a special reaction in your hook will provide a constant indication that the hook has not been removed. This anti-tamper technique will become increasingly important as unhooking tools such as Rootkit Unhooker gain prominence.

Creating a background task that does nothing more than check the rootkit and broadcast an error message when the rootkit fails to respond is yet another way to ensure compliance. Some high-level use-case scenarios might be of value before implementing this particular solution. Because the reason for the rootkit malfunction will likely be due to rootkit detection and cleansing, the process monitoring of the rootkit should not fall into the same detection category, or there will be a high likelihood that both the rootkit and the monitor will be removed simultaneously, defeating the purpose of the monitor.

In general, the controller needs to keep track of the following:

• Every machine in the controlled environment that can respond to a ping

• Every machine in the controlled environment that has a rootkit installed

• Every machine in the controlled environment that does not have a rootkit installed

• Every machine in the controlled environment that has a responding rootkit