Student: Sebastian Poeplau
Primary mentor: Tillmann Werner
Ghost is a honeypot for USB malware. It is capable of capturing malware that propagates via USB storage devices without any further knowledge. This is done by emulating a USB thumb drive and tricking malware into infecting the emulated device. Due to the fact that a machine must be infected in order for the virtual device to detect the malware, the honeypot is designed to run on Windows systems, which are mainly targeted by malware at the moment.
Currently, Ghost only supports Windows XP and is in an early development stage, although its concept has been shown to work well, and the code is stable. If Ghost detects an infection, then it will currently only report that the machine is possibly infected, without including any additional information.
The goal of this project is to extend the reporting capabilities of Ghost, and to make it run on other versions of Windows. What does that mean in detail?
First, we'd like the honeypot to collect as much information as possible about processes that infect USB storage devices. This includes such things as process identifiers, the process executable or a list of loaded DLLs. Also, we need a well-structured way to communicate this information from kernel-space to user-space and from our user-space component to the user.
Secondly, we will add support for other versions of Windows. Especially Windows 7 is a target, and we hope to also support 64-bit versions.
- Sometime in the past: Adding support for Windows 7
Should also cover Windows Vista, but that's yet to be confirmed.
- June 1 - July 15: Information gathering and communication
- Communication between kernel-mode and user-mode components
The information collected in kernel mode must be transferred to our user-mode component in order to be presented to the user. At the moment, we see two possible ways to do so:
- IOCTLs can be used for querying information from devices. Applications can send IOCTLs from user space, and it is possible to attach data to the reply, which will allow us to communicate infection details. We need to check yet how well blocking queries are possible when using IOCTLs.
- Another option is to read from a device. This way, we could define a more sophisticated communication protocol and use blocking reads to query information efficiently. However, it is yet to be evaluated whether the effort of migrating from the current IOCTL-based approach provides substantial benefit in our particular case.
- Information gathering
We'll collect as much information as possible about processes that infect our emulated device. At the moment, we plan on including process and thread IDs, the process executable, and a list of loaded DLLs. More elements might be added as we reach this step of development.
- Other improvements
There are some other bits and pieces that we'd like to implement:
- We should support some more IOCTLs from the operating system in order to achieve a more realistic emulation.
- The honeypot is supposed to generate an alert directly after some malware has written data to the emulated device rather than at the time of unmounting. Here the ability to do blocking calls to our kernel-mode component comes in handy.
- We have to make sure that the images of emulated devices are created in a safe manner. Otherwise, our tool could be instrumented to overwrite existing files.
- July 16 - July 20: Testing and mid-term evaluation
We'll make sure that the code is stable, which is particularly important for kernel-mode components. We'll check that everything works as desired, allowing us to move on to the user-space part of the honeypot.
- July 20 - August 26: User interface
- Frontend application
We'll design and develop an application that allows the user to configure the honeypot's operation and to view reports generated by the kernel-mode component.
When started for the first time, the honeypot should install its drivers and get ready for operation. This way, we hope to avoid a lengthy install process and simplify the usage of our tool.
- August 27 - August 31: Testing and final evaluation
Again, we'll make sure that the code is stable and that all features work as specified.
- After the first testing period (July 20), we will provide improved drivers and our implementation of the new communication model.
- After the second testing period (August 31), the new user interface will be published along with the easy-to-install binary package.
Project Source Code Repository:
All source code written for this project is published on Google Code.
Regular Project Updates:
The project's issue tracker is used to keep track of the current progress in development. In my blog, we will post articles on interesting issues related to the project.
You can find a presentation of Ghost on Youtube.