About Capture Client Honeypot / Honeyclient

Capture is a high interaction client honeypot (or honeyclient) developed at Victoria University of Wellington by Ramon Steenson and Christian Seifert. 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 current version of Capture various HTTP aware clients, such as Firefox, Opera, Internet Explorer, Adobe Acrobat Reader, MS Office Applications, Open Office Applications and various media players.


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 find 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. 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, registry, 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. Capture allows to automatically collect network dumps and downloaded files (ie malware) when a malicious server is encountered.

Technical Description

The Capture server is a simple TCPIP server that manages several capture clients and the VMware servers that host the guest OS that run the Capture clients. The Capture server takes each URL it receives and distributes them to the available clients in a round robin fashion. The server listens for client that connect to the server upon startup on a specified TCP port. The Capture server is written in Java and controls the VMware servers using the VMware C API that it wraps using jni. The communication protocol between the Capture Server and Capture Client is XML based and described in Capture Communication Protocol.pdf.

The Capture client in turn consists of two components, a set of kernel drivers and a user space process. The kernel drivers operate in kernel space and use event-based detection mechanisms for monitoring the system's state changes. The user space process, which accepts visitation requests from the Capture server, drives the client to interact with the server and communicates the state changes back to the server via a simple TCPIP connection. The user space process captures the state changes from the kernel drivers and filters the events based on the exclusion lists. Each component is written in unmanaged C code.

Kernel Drivers

The Capture client uses kernel drivers to monitor the system by using the existing kernel callback mechanism of the kernel that notifies registered drivers when a certain event happens. These callbacks invoke functions inside of a kernel driver and pass the actual event information so that it can either be modified or, in Capture's case, monitored. The following callback functions are registered by Capture:

  • CmRegistryCallback
  • PsSetCreateProcessNotifyRoutine
  • FilterLoad, FltRegisterFilter

When events are received inside the Capture kernel drivers, they are queued waiting to be sent to the user space component of the tool. This is accomplished by passing a user allocated buffer from user space into kernel space where the kernel drivers then copy information into that buffer, so the application can process it in user space. User Space Process

The user space process is an application that resides in user space. It is the entry point of the Capture application. It is responsible to load the drivers, process the events received by the drivers and output the events to the report.

As mentioned above, the user space application, once it has loaded the drivers, creates a buffer and passes it from user space to the kernel drivers. Passing of the buffer occurs via the Win32 API and the IO Manager. The kernel drivers copy the event data into the buffer, so the user level application can process the events. Each event is serialized and compared against the entries in the exclusion list. The exclusion lists are built using regular expressions, which means event exclusions can be grouped into one line. This functionality is provided by the Boost::regex library. For each monitor, an exclusion list is parsed and internally mapped between event types and allowed regular expressions are created. If a received event is included in the list, the event is dropped; otherwise, it is output to the final report that Capture BAT generates.

Academic References

Below, you will find several papers that have utilized Capture-HPC in one form or the other:

1. M. Egele, P. Wurzinger, C. Kruegel, and E. Kirda, "Defending Browsers against Drive-by Downloads: Mitigating Heap-spraying Code Injection Attacks," Secure Systems Lab, 2009, p. Available from  http://www.iseclab.org/papers/driveby.pdf; accessed on 15 May 2009.

2. C. Seifert, V. Delwadia, P. Komisarczuk, D. Stirling, and I. Welch, "Measurement Study on Malicious Web Servers in the .nz Domain," in 14th Australasian Conference on Information Security and Privacy (ACISP), Brisbane, 2009.

3. C. Seifert, P. Komisarczuk, and I. Welch, "Application of divide-and-conquer algorithm paradigm to improve the detection speed of high interaction client honeypots," in 23rd Annual ACM Symposium on Applied Computing Ceara, Brazil, 2008.

4. C. Seifert, P. Komisarczuk, and I. Welch, "Identification of Malicious Web Pages with Static Heuristics," in Austalasian Telecommunication Networks and Applications Conference, Adelaide, 2008.

5. C. Seifert, I. Welch, P. Komisarczuk, C. Aval, and B. Endicott-Popovsky, "Identification of Malicious Web Pages Through Analysis of Underlying DNS and Web Server Relationships," in 3rd IEEE Conference on Local Computer Networks, Montreal, 2008.

6. C. Seifert, R. Steenson, T. Holz, Y. Bing, and M. A. Davis, "Know Your Enemy: Malicious Web Servers," The Honeynet Project, 2007, p. Available from  http://www.honeynet.org/papers/mws/; accessed on 25 September 2007.

7. M. Xie, Z. Wu, and H. Wang, "HoneyIM: Fast Detection and Suppression of Instant Messaging Malware in Enterprise-Like Networks," in Computer Security Applications Conference, Miami Beach, 2007, pp. 64-73.

When citing Capture-HPC, please use the following bibtex:


Author = {Seifert, Christian and Steenson, Ramon},

Title = {Capture - Honeypot Client (Capture-HPC)},

Publisher = {Victoria University of Wellington, NZ},

Pages = {Available from https://projects.honeynet.org/capture-hpc; accessed on 22 September 2008},

Year = {2006}