Folks, Chengyu Song has been busy the last few weeks and made some upgrades to the honeypot monitoring tool Qebek. He has ported it from QEMU 0.9.1 to QEMU 0.13.0. As a result, Qebek’s performance (boot time) is better and it no longer requires gcc 3.4. You can check it out
svn co https://projects.honeynet.org/svn/sebek/virtualization/qebek/trunk/
If you don’t know what Qebek is or how to use it, take a look at our whitepaper at https://honeynet.
I am very pleased to announce another publication of our Know Your Tools series: Qebek - Conceal the Monitoring authored by Chengyu Song and Jianwei Zhuge from the Chinese Chapter and Brian Hay from the Alaskan Chapter.
The paper is available from https://honeynet.org/papers/KYT_qebek.
Paper abstract
For the last few years, while low-interaction (LI) honeypot systems like Nepenthes and PHoneyC are getting more and more powerful, the progress of high-interaction (HI) honeypot technology has been somewhat slower.
When using hooking technology to intercept system calls, there are two different places to collect information: before the original function is called (precall) and after the original function returns (postcall). For example, in Sebek Win32 client, when callback function OnZwReadFile is called, it first calls the original function s_fnZwReadFile, after the original function returns, it checks whether the original call succeeds, if does, it then calls the data collection function LogIfStdHandle:
Sebek Windows client has two keystroke sources, one is read or write std stream, the other is csrss port. In the callback function of NtReadFile and NtWriteFile, Sebek will check if the given file handle match one of the three standard stream handles. if matches, it then logs the given data of keystrokes:
__asm {
mov EAX, FS:[18h]
mov [pTIB], EAX
}
if(FileHandle == pTIB->pPEB->ProcessParameters->StandardOutput ||
FileHandle == pTIB->pPEB->ProcessParameters->StandardInput ||
One difference in Qebek from other existing virtualization based honeypot monitoring tool is that I want to ‘hook’ the function of system service instead of the dispatcher, more precisely, the ‘sysenter’ or ‘int 2e’ instruction. This is similar to the difference between SSDT (System Service Descriptor Table) hook and kernel inline hook. However, doing it this way must face a problem: how to get the function address? One way is get it directly from SSDT.