a) SEBEK Development: (Working with Ktwo) Even though SEBEK (windows) is still in active service and meets existing and future requirements (with additional development phases,) several fundamental architectural limitations have become apparent. Documented in several research papers and other online publications, are weaknesses and various "attacks" against Sebek which impact the overall utility and longevity of its model as a whole. To address these attacks, original design and architectural decisions must be validated with present day technologies, techniques and knowledge. A new series platform has been initiated which can counter known attack measures to date while still delivering equivalent functionality.

The fundamental requirement which necessitates Sebek is the ability to monitor network traffic when it is in an encrypted form. To this end, Sebek is architected around eavesdropping on the encryption demarcation, where the plaintext or rather the subset of communicated information is used to facilitate some form of command or operation on the target honey host.
This model will fundamentally shift focus and attempt to validate the existing host-based paradigm. It's our conclusion that the existing Sebek detection capabilities are well developed and likely to outpace evolutions in the current model without a focused engineering effort. By radically changing the operational characteristic of Sebek, a significant gain can be reaped rather quickly and provide a new basis for input. A MITM (Man in the middle) based, transparent proxy, which wraps PE binaries (or binaries encoded with a method readily decoded on the target system) with an initial execution payload that is purposely built to analyze and recover encryption key material, from the dynamic operation of the embedded PE binary. The key material would then be sent immediately towards the same MITM proxy for storage. This would later allow decryption of the attacker's actions with impunity. A full session decode, beyond current capabilities, would allow inspection of communication protocol dialects in use, greater introspection into connected bot-networks and full transparency for identifying automated efforts or manual tasking by an attacker.

b) Virtual Introspection: Virtual introspection is the act of divining activity of a virtual machine from the host. We have explored two mechanisms; modifying the QEMU functions and observing the state of a VM from the Virtual Machine Monitor (VMM). WE will brief some of this work at the Honeynet workshop.

2. List tools you enhanced during the last year: Several in development: SEBEK (windows) and VM monitoring.

3. Would you like to integrate this with any other tools, or you looking for help or collaboration with others in testing or developing the tool? Not at this time.

4. Explain what kind of help or tools or collaboration you are interested in. When our T3 line gets up and running, I am interested in hosting GD nodes and continuing our development of monitoring tools.

FINDINGS

1. Highlight any unique findings, attacks, tools, or methods. None.

2. Any trends seen in the past year? None

3. What are you using for data analysis? Walleye and local scripts.

4. What is working well, and what is missing, what data analysis functionality would you like to see developed? Data repository.

PAPERS AND PRESENTATIONS

1. Are you working on or did you publish any papers or presentations, such as KYE or academic papers? If yes, please provide a description and link (if possible) : Roy briefed the QEMU work at HICSS this year.

2. Are you looking for any data or people to help with your papers? Always!