Design and Functions of the Browser Control part

Users can control and monitor the system via the Management Console (MC) web interface.  To get started, the user enters or imports a list of URLs that the system will check.  In later versions, this task can be performed by a web crawler that extracts linked URLs from webpages that are already marked as malicious.

In order to avoid jeopardizing security or interrupting performance with constant re-installations, the system visits the URLs within a sandbox.  This sandbox is implemented as a VMware Server guest image.  It is cloned and configured with some of our own bash scripts and the internal VMware C-API.  This procedure can be repeated n-times, depending on how many virtual Windows XP instances are used to check URLs simultaneously. This also depends on the performance of the VMware host system.  To guard the cloning process, the scripts notify the state of the sandbox to the Management Console which shows this on the web interface.

The sandbox images are registered and booted through the VMware Server.  Once the boot process is finished an additional script creates a snapshot of the current state, copies the most recent version of our Browser Control as well as the rootkit in the sandbox and runs the Browser Control.  By using the snapshot technique, the system can do a rollback once a system is infected.  In contrast to deleting the sandbox and creating a new one (which takes about one minute), this process takes only a few seconds.

The Browser Control component first loads the Rootkit as a windows driver in the Windows XP kernel space.  After that, the Browser Control (BC) registers itself with the sandbox and displays the IP address in the Management Console.  At this point, the systems loops through the following steps:

  1. BC asks the MC for the next URL via SOAP.
  2. BC sends the rootkit a message to trigger the system monitor.  All further relevant system calls (CreateFile, DeleteFile, Execute, etc) are then redirected and observed.
  3. BC starts Internet Explorer and hands it the URL it receives.
  4. Once the webpage is loaded completely or a timeout is received for this action, the browser is closed and monitoring stops.
  5. Now it is time for the BC to ask the Rootkit for the results list.  If the page was “clean” this list is empty, otherwise the list includes all suspicious system calls with time/date information as well as the process id (PID) of the corresponding application.
  6. If the list is empty, our BC informs the MC which then marks the URL as clean in the database.  If the list includes entries, these are transferred to the MC as well.  If the sandbox is marked as infected, another script is called to restore the snapshot that was created at the start.  After copying the BC and Rootkit and re-registering with the MC, the system returns to step one.
The Management Console in action