The Controller

The first step in building a rootkit controller is determine whether the rootkit actually needs to be controlled. It may not be possible, but if you can do without a controller, the absence of a control mechanism will simplify the overall design and make the rootkit much harder to detect. If your goal is to monitor a small number of computers to which you have physical access, perhaps file logging would be better. If your design requires simple remote control, such as on and off, with an occasional status update, perhaps monitoring the HTTP input stream for special packets, and injecting the HTTP output stream to communicate status, would be better.

If you find that you do require external control, the design of the remote controller should progress hand-in-hand with the design of the rootkit. This will become increasingly important as the rootkit grows. We’ve already seen how quickly a simple rootkit that does nothing more than hide itself can grow into a fully functional example demonstrating every major feature employed by modern rootkits. Implementing additional functionality without considering the impact on the controller can lead to inefficient code, redesign, high-bandwidth communication channels, confusing interfaces, and more.

If you are building a professional rootkit that requires external control, you need a professional rootkit controller. This controller will almost certainly include a well-defined graphic user interface (GUI) front end and an industrial database back end. Controller clustering and low-bandwidth control links are also important considerations. In addition, the controller will likely have even more installation considerations than the rootkit. Together, these considerations are likely to add a new component to the overall design: marketing strategy.

At best, marketing professionals will assist in the generation of the specifications for the rootkit, but the remote controller is another story entirely. Be prepared to spend a lot of time with groups of diverse professionals to iron out the remote controller’s design. Whereas the rootkit is classified by many as “low-level technology” and left to developers to implement, the rootkit controller is “interface-driven” software that can be designed without any knowledge of the underlying technology. This enables the rootkit controller’s design to be “market driven.” The efficiency of the communication link, the database schema, the process threading model, and the programming language used to develop the rootkit controller are likely to be classified as “low-level technology” and left to the developers, but the report interface, the status interface, the control interface, the shell interface, and the policy generation interface are likely to be defined by marketing.

Of particular interest are the following:

• The Interface medium– This is the technology used to implement the interface. You might consider a web interface to provide the end user with the flexibility to control rootkit operations from any browser. However, this will add a substantial security risk. Authentication, encryption, tamper prevention, configuration change tracking, and tiered permission levels are of paramount importance in a browser-controlled environment.

  You might also consider a Visual Studio–developed application, such as the example in this chapter. The advantages include the following: physical security, because access to the controller software can be physically controlled; extensibility, because the drag-and-drop theme of Visual Studio (menus, dialogs, command buttons, etc.) lends itself to future additions; efficiency, because the application doesn’t have to conform to a laundry list of technologies such as multibrowser HTML or Java Virtual Machine requirements; and time to market, because Visual Studio jumps from rapid prototyping to implementation so quickly.

• The interface– This is the view the end user will see. A main page and some number of subpages will likely be required. Keep in mind that the functionality of the rootkit will not necessarily map onto the user interface. The purpose of the interface is to control functionality, whereas the purpose of the rootkit is to implement functionality. These might seem to be closely related, but control should be as simple as possible, whereas implementation can be as intricate as necessary. Removing the intricacy of the implementation should be a predominant design goal of the interface.

• The Summary view– This is the page that shows overall status at a glance. Marketing will be particularly interested in this page. Pie charts, three-dimensional bar graphs, color-coded activity levels, and easy access to all major control categories should be features of the summary page.

• Control categories– Here are a few examples of control categories:

  • Monitor Status–Machines, machines with rootkits, currently connected machines

  • Monitor History–Connection history, installation date, rootkit version

  • Event Status–Total events by type, events per machine

  • Event History–Chronological list by type, by machine, by user, by date

  • Policy Development–Create policies, policy database, group policies

  • Policy Implementation–Implement by machine, by group, by user

  • Updates–Code, policy, from vendor, to machines, historical

  • Control Panels–All machines, a group of machines, a single machine

  • Forensics–Data capture, data retrieval, log entries, incident reports

  • Reporting–Report design, running reports, report output format

  • Scheduling–Forensic recovery, rootkit integrity checks, installation