The official pencil down date has passed yesterday. With this last blog post I want to give an overview about what I have achieved during the last 3 months, give you a simple introduction how to use PwnyPot with Cuckoo and reflect my experiences with GSoC and the Honeynet Project.

Overview

As the title of my project already makes clear, the original plan was to make use of the well-known malware analysis tool Cuckoo to manage automatic analysis with the high-interaction client-side honeypot PwnyPot.

Before I started my project, PwnyPot consisted of a DLL that got injected to processes, that have been chosen through a GUI on a guest system / analysis system. Through the same GUI the options for analysis and prevention techniques had been assigned.

All analysis information was logged on the guest system into simple log files and one XML-document. Instead of writing a complete new management software for automated execution and analysis of malware, I decided to modify PwnyPot slightly to work with Cuckoo. Cuckoo is developed continuously since a few years and easy to modify to your needs. The following main changes were necessary:

File transmission from PwnyPot.dll to the Cuckoo result server to transmit analysis information

Cuckoo Pipe inside the PwnyPot.dll to notify Cuckoo for new (sub) processes of the malware

Cuckoo processing module to parse analysis information

Cuckoo reporting module to display the results for example in HTML

Modify Cuckoo to read PwnyPot specific configuration

Enable to inject different DLLs via Cuckoo (instead of cuckoomon.dll)

The modular architecture of cuckoo permits to add all this functionality without touching much of the core files but by just adding new modules. I only changed the analyzer and the analyzer packages of the core to use Cuckoo as wanted. These files needed to be changed to allow injection of another DLL than cuckoomon.dll. As Mark (one of the co-developers of Cuckoo) told me later, this feature may also be interesting for others. Therefore I created this pull request.

The modifications on the code of PwnyPot were also quite easy, because the protocols (ResultServer, NamedPipe) that are used by Cuckoo to retrieve analysis information from the guest are pretty simple. The changes to PwnyPot, that were only necessary in order to work with Cuckoo, were written between preprocessor definitions. A new build configuration was created named “CuckooRelease” which builds PwnyPot.dll with Cuckoo support. The old configuration “Release” still builds the DLL with the original configuration and analysis output.

Against my expectations I managed to implement all these changes, including tests and documentation, around mid-term evaluations. My plan was to use the rest of the time with improving PwnyPot itself. At that time, my knowledge of concrete exploitation and exploit mitigation techniques was quite small. I decided to choose only a few features, from which I could expect to be implemented quite easy. After some research I decided to work on the following features

Both code repositories are hosted on github: Pwnypot – Cuckoo. Inside the Pwnypot git I used the branch “cuckoo_integration” and inside the Cuckoo git the branch “pwnypot_integration”. If you just want to use Cuckoo with PwnyPot, there is no need to checkout out the Pwnypot repo. The pwnypot_integration branch already holds PwnyPot.dll with Cuckoo support.

Note: For a more detailed documentation of usage, features and configuration parameters please read the HTML documentation in cuckoo/docs/book/src or build it inside this directory with `make html`. The documentation to setup Cuckoo, the host and the guest can be found on this website.

Configuration of PwnyPot is done in conf/pwnypot.conf. To analyze a file or URL you can use the web interface or the submit.py script inside the utils folder. Example usage with submit.py:

The web interface can be started by changing directory to web/ and by executing

python manage.py runserver

For the web interface of Cuckoo 1.0 you need to have mongodb enabled in conf/reporting.conf. After analysis you should see your results, if you follow the link Recent in the head navigation of the web interface.

If you allow malware execution in the configuration for pwnypot, cuckoomon.dll is injected into the malware process. Thereby the behavior of the malware after exploitation is analyzed by Cuckoomon. You will find this information in the PwnyPot tab as “Malware Execution”, if such behavior analysis has been performed:

Conclusion

I do not regret, that I have participated in this years Google Summer of Code. It was really a huge amount of work, but I have also learned a lot. Special thanks to my mentors Georg Wicherski, Mark Schlösser and Shahriyar Jalayeri, who were always available for questions. I will try to continue to contribute to both projects in the future.

This blog post is about the work during the past three weeks. As expected the progress with the project has been slowed down a little, because I had to do a lot of research for most of the steps.

Nevertheless I managed to implement further Hooks for protection against DEP and ASLR bypassing. NtSetInformationProcess, SetProcessDEPPolicy, WriteProcessMemory and are now hooked by PwnyPot and their parameters get analyzed for potential malicious behaviour. The first two functions are only additional protection for some Windows Versions before Windows 7. Since Windows 7 DEP is enabled permanently and can not be changed by the process with NtSetInformationProcess or SetProcessDEPPolicy. We still log calls to that function to get a more detailed view of the behaviour of potential malware.

A quite recent method to bypass ASLR in 32bit processes on a Windows 64 OS is the LdrHotPatchRoutine of ntdll.dll. Each 32bit Process has access to the so called SharedUserData object which resides always at a fixed location: 0x7ffe0000. In this memory region are several function pointers placed. One of these pointers is pointing to the LdrHotPatchRoutine, which allows to download a DLL from an UNC path and load it into the process. More information can be found here and here.

I also prepared the project a little to get to its final destination:

I renamed everything inside the project from MCEDP to PwnyPot, as this should be the final name of the project.

Because the Cuckoo developers are currently quite busy preparing the v1.0 release, I decided to merge the current development branch of Cuckoo into my developing branch. This brings some new features and a nice new Web interface. This will make it easy to make a pull request to the official Cuckoo repo at the end of this GSoC project.

For the next two weeks I want to implement SEHOP for all Windows versions. While there already exist patches for Windows VIsta SP1 and newer, I want enable SEHOP for Windows XP, too. Therefore I follow the techniques described in this article. I also need to do more tests with real world exploits for the new bypass protections.

In the last two Weeks I further improved the processing and reporting modules. The ROP analysis is now more detailed and also shows the values of addresses outside of the module address spaces and tries to display ASCII values of it.

Furthermore the hooked WSAPI calls are now always adding information about which socket is used for the current function to the Analysis XML-file. This allows us to display the network dumps inside the reports in a more structured way.

I also added more comments to the code and cleaned it up for the mid-term evaluation.

For the next couple of weeks I plan further improvement on PwnyPot itself, because the management of it via cuckoo is now completely implemented. The main aspects I want to work on:

In the past few days I optimized the configuration of PwnyPot. Originally, PwnyPot was configured through a GUI on the guest manually, which saved some registry keys and values in order to automatically inject itself into configured Programs. For making configuration easy with cuckoo, I now implemented the parsing of an additional cuckoo config file pwnypot.conf. There can be set, what have been set through the GUI before.

Furthermore I improved the processing and reporting of the Shellcode and ROP analysis. I will work further on this till the end of the month with additional exploits.

For the fourth week I planned to write the PwnyPot processing and reporting modules for Cuckoo to visualize the produced data. I focused on the HTML-Report for now.

I did also some optimizations on the outputs of PwnyPot. Most of the output that gets processed by Cuckoo is now inserted into in XML file and sent to the Resultserver. Needed information can be easily extracted from the file when processed.

Further improvement of PwnyPot has been realized by injecting cuckoomon.dll into the shellcode process, if executed. PwnyPot just executed the shellcode without further analysis. Now we can retrieve all API calls, if we really want to execute shellcode.

Some problems appeared in between this week which resulted in a little delay of my project plan. The current modified MCEDP.dll sends all its log and analysis data via a socket to the resultserver. I forgot, that the WSAAPI calls are also hooked by PwnyPot. This is resulted in some weird behaviour and recursions when sending the data. This issue is fixed now, but it took some time to find this out, unfortunately.

I have almost reached all my goals that I planned for the midterm evaluation. Till the end of the month, the reporting module will be filled with even more analysis details. Therefore, more exploits are going to be tested with PwnyPot.

Last Week I managed to transfer all produced Output of Pwnypot to the resultserver of Cuckoo, which includes the general debug log, ROP analysis log, shellcode analysis log and the shellcode binaries. There is still some optimization necessary in the output format of Pwnypot to make processing easier on the host side. This will be done till the end of the week.

Till next week (July 16th) I am also going to write a processing module for the Pwnypot data and add more options to set Pwnypot configuration via Cuckoo.

I recognized how important and helpful it is to keep good contact to the developers of Cuckoo and Pwnypot to reduce unnecessary work. Cuckoo has an own protocol to transfer output of cuckoomon to the the resultserver directly. It was not obvious to me, that this can not be reused for Pwnypot. This misunderstanding was fastly resolved by talking to Mark, one member of the Cuckoo developer team.

The second week was, as I expected, much more productive in sense of coding. I feel more and more comfortable with the code of pwnypot as well as of cuckoo. Especially the documentation and flexibility of cuckoo amazes me again and again.

For the second week I wanted to achieve that pwnypot is placing its output at the correct spots and sends it to the cuckoo result server automatically after it has finished its analysis. The former is realized by reading out the randomized cuckoo results and analyzer paths from the ini files of the current process. This ini file also provides us with the IP and port of the cuckoo result server. The logfile transmission is currently in a very basic state. The logfiles are simply transmitted to the storage folder on the result server.

I had some unexptected problems using a Windows 7 64 bit VM and 32bit applications which was not always working, so I switched to a Windows XP 32 bit VM which has the nice additional advantage, that it runs faster on my laptop …

For the current week was planned to improve the quality Pwnypots output and write a processing module for the ROP analysis to prepare nice output with reports later on. But in order to create the processing and report module in a senseful way, I decided to generate the bson output of the logfiles before that. I also want to enable the pwnypot specific configuration parameters. Therefore, cuckoo needs to be extended to save additional options to the ini file.

My first week of GSoC 2013 was due to some reasons less coding, but still quite enlightening. Because the first week overlaps with one of my courses I chose only small goals for it, which will change for this and the following weeks.

Before starting to code I set up the environment to build the MCEDP.dll. The easiest way is just installing Visual Studio and the Windows SDK. WIth some tweaks it is also possible to only install the Windows SDK and use the MSBuild tool to build the dll, which is a little more “lightweight”.

As a coding goal for the first week I wanted to implement the DLL-injection of MCEDP.dll instead of cuckoomon.dll via the cuckoo submission script into the guest programs. Due to the flexibility of cuckoo, this was much easier than I thought in the first place. All existing analyzer packages have been easily changed to be capable of the new DLL and its injection is no problem at all. By now, the whole analyzer folder is always copied to the guest including all packages and dlls, whether they used or not. This could be improved later on, by just packing the needed resources.

For this week I planned to start the integration on the side of pwnypot. It currently reads out its configuration from the Windows Registry. In order to make the log files and results of pwnypot available for the processing and reporting with cuckoo, it needs to accept configuration that comes over the cuckoo agent to put the files in the right spot. By using preprocessor definitions I want to ensure that the existing functionality can stay in the code as is. The cuckoo dependent code is then only compiled into the dll, when really wanted. The streaming of the log files will be implemented via the upload_to_host function of the analyzer libs at first.