- About us
- Code of Conduct
- Google SoC
- Recent posts
- Security Workshops
I just wanted to share few things with you about my project.
I'm still very excited to work on my project and if anyone is intersted in what I've done, here is a short tutorial I created to setup the project quickly.
If some kind people would like to test it to give me their feedback. It could be the best way for me to improve it.
Last saturday I've finally released a new Glastopf version. There are some new features and many changes under the hood.
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:
TCP was built to allow 2 hosts to exchange a stream of packets reliably. Honeybrid must add a third host to this operation when it decides to investigate further a connection. The keys for this process to work are: 1) a replay process that gets the high interaction honeypot to the same state than the low interaction honeypot; and 2) a forwarding process that translates not only IP addresses but also TCP sequence and acknowledgement numbers. Here is how things work in detail:
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:
One project mentored by the Honeynet Project during GSoC aims at improving nebula, an automated intrusion signature generator. There are two critical components in the signature generator: A clustering engine that groups similar attacks into classes, and a signature assembler that extracts common features and selects some of them for the actual signature.
The first version of the parser is essentially finished. The main goal for the basic version of the parser is to take Sebek data and create two groups of data: one group is comprised of a data structure that holds an event's information, things like the timestamp, event type, what service the event was connected to, etc. The second group is simply a list of each unique event, basically what types of events happened, what ports were used, services used by the events, things of that nature.
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.
due to the length of the whole term Improving the effectiveness of low interaction honeypots, I decided to use Iteolih as uniq abbrevitation. Things are rolling for the project, writing code started, a basic homepage with instructions how to compile/use it was created.
I even had the plan to write about it once or twice, finish something in the code, write about it. When I was done with the code, I got the idea, writing about it was not worth your time.