About Capture
Only a few high interaction client honeypot clients are available today. Capture differs from existing client honeypots in various ways. First, it is designed to be fast. State changes are being detected using an event based model allowing to react to state changes as they occur. Second, Capture is designed to be scalable. A central Capture server is able to control numerous clients across a network. Third, Capture is suppose to be a framework that allows to utilize different clients. The intitial version of Capture supports Internet Explorer, but additional clients will be supported with upcoming versions of Capture.
Functionality
In this section, we describe the existing functionality of Capture at a high level. Following, we provide a glimps into the future and describe our plans to extend Capture .
Capture allows to search and identify malicious servers on a network. Capture is split into two functional areas: a Capture Server and Capture Client. The primary purpose of the Capture Server is to control numerous Capture clients to interact with web servers. It allows to start and stop clients, instruct clients to interact with a web server retrieving a specified URI, and aggregating the classifications of the Capture clients regards the web server they have interacted with. The server provides this functionality in a scripting fashion, but also in interactive mode for debugging purposes.
The Capture clients actually perform the work. They accept the commands of the server to start and stop themselves and to visit a web server. As a Capture client interacts with a web server, it monitors its state for changes on the file system and processes that are running. Since some events occur during normal operation (e.g. writing files to the web browser cache), exclusion lists allow to ignore certain type of events. If changes are detected that are not part of the exclusion list, the client makes a malicious classification of the web server and sends this information to the Capture server. Since the state of the Capture client has been changed, the Capture client resets its state to a clean state before it retrieves new instructions from the Capture server. In case no state changes are detected, the Capture client retrieves new instructions from the Capture server without resetting its state.
Our plans to extend Capture are as follows. Since we currently only support monitoring of processes and the file system, the most pressing need is to expand the capabilities to monitor the system. This includes monitoring the registry, clip board, and network connections. The exclusion capabilities of existing process and file monitor need to be extended. Currently, it allows only for an all or nothing exclusion, but we believe it is necessary to have more fine grain control allowing to specify event types (e.g. read, write) as well as groups (e.g. directory A, but not file b in directory A). Third, we would like to expand Capture to support additional clients. Most likely, we will add additional browsers, such as Firefox and Opera, but also non-browser type of clients, such as Multimedia Players. Most of these enhancements are scheduled to be completed in Q1 and Q2 of 2007.
Architecture
In this section, we describe the architecture of Capture as well as some underlying technical details. As mentioned above, Capture consists of a Capture server and Capture client as shown in the figure above. The Capture clients consists of a VMware Server that hosts numerous host operating systems that, in turn, host the Capture client component. The Capture server, a simple perl script, interacts with the clients in two ways. First, it controls the VMware Server and can instruct it to start, stop, and reset the host operating systems via the VMware Perl Scripting API. Second, once a host operating system is started and the Capture client component has registered with the Capture server via a simple network connection on port 7070, the Capture server can communicate with the Capture client. Via this network channel, it can instruct the Capture client to visit uris and receive the events and classifications of the client.
The Capture client component is written in C# and communicates with the server via a simple network connection on port 7070. Monitoring the system occurs by registering monitors (file system and processes) with the Win32 API. As events occur, the monitors are notified about the events. Unless the event is excluded using the exclusion list, it would result in a malicious classification of the web server the client was interacting with.
This work is licensed under a Creative Commons License