Friday, June 17, 2016

Cuckoo with Microsoft Enhanced Mitigation Experience Toolkit (EMET)

I have been toying with the idea to retrieve Microsoft event log messages from my Cuckoo instances for a while. But I did not have any chance to make anything out of the idea, until now.

To get this to work, Cuckoo requires an extra auxiliary module for this purpose. Along with the Python WMI module installed on the guest, or at least I ended up using the WMI module, but you could easily use pywin32.

As you already have Python installed on the guest, you can use pip to install it.

Cuckoo runs any auxiliary module that is available in the directory:


So this got me thinking (I know, crazy times!), as I have been doing some other work with EMET or rather logs from EMET. Why not combine the code above with EMET on the guest?

Obviously you need to install EMET (on the guest), do that and make sure it's active. Configure it after your specific needs. As your main goal might not be block, but to only catch EMET in action, you will need to configure EMET from the default blocking to audit mode. This will allow the malicious code to continue running even if it's detected by EMET.  

With the following lines of code, you will be able to retrieve what you need from the event log. Save the content in a file, in the above mentioned directory and you are good to go:

import logging
import wmi
import sys


from lib.common.abstracts import Auxiliary
from lib.common.results import NetlogFile

log = logging.getLogger(__name__)
dadada = []

class EMET(Auxiliary):

    def start(self):"Starting EMET auxilary module")

    def stop(self):"Collecting EMET events...")

        c = wmi.WMI(privileges=['Security'])
        for event in c._raw_query('SELECT * FROM Win32_NTLogEvent'):
            if event.SourceName == "EMET":
               # maybe add more values?
         dadada.append([event.SourceName, event.Category, event.Type, event.ComputerName, event.User, event.Message])

        bleekscheet = "\n".join(str(x) for x in dadada)
        nf = NetlogFile()
        return True

Example of EMET events retrieved from the guest:

[u'EMET', 0, u'Error', u'<COMPUTERNAME>', None, u'EMET version 5.5.5871.31892\nEMET detected MemProt mitigation in iexplore.exe\r\n\r\nMemProt check failed:\n  Application \t: C:\\Program Files\\Internet Explorer\\iexplore.exe\n  User Name \t: <COMPUTERNAME>\\<USER>\n  Session ID \t: 1\n  PID \t\t: 0x474 (1140)\n  TID \t\t: 0x81C (2076)\n  API Name \t: kernel32.VirtualProtect\n  ReturnAddress \t: 0x0000000000446E60\n  CalledAddress \t: 0x000007FEFDA031E0\n  StackPtr \t: 0x00000000029AF4D0\n']

[u'EMET', 0, u'Error', u'<COMPUTERNAME>', None, u'EMET version 5.5.5871.31892\nEMET detected StackPivot mitigation in iexplore.exe\r\n\r\nStackPivot check failed:\n  Application \t: C:\\Program Files\\Internet Explorer\\iexplore.exe\n  User Name \t: <COMPUTERNAME>\\<USER>\n  Session ID \t: 1\n  PID \t\t: 0x71C (1820)\n  TID \t\t: 0x46C (1132)\n  API name \t: kernel32.WinExec\n  ReturnAddress \t: 0x000000007775C8FF\n  CalledAddress \t: 0x00000000775B8D80\n  Thread stack area range: [0x3172000..0x3180000]\n  StackPtr \t: 0x000000000543FB30\n']

Please note that the coding style is not officially approved by @skier_t =)(but I'm as always very grateful for his help!) Hopefully there will be a better way of doing this in the future, natively in Cuckoo.


Friday, February 12, 2016

Defeating WMI detection of VirtualBox take 2

My previous attempt to twart WMI detection of VirtualBox, by disabling the Plug and Play service, had the mildly obnoxious side effect of disallowing the OS to check if it was registered or not.

This resulted in that, already registered installations became unlicensed (The same issue applied to MS Office installations)


Being that It is always hard to find time for fun/interesting research. I had to put this issue back into my ToDo list, until now. And I guess leaving a problem to fend for itself for a while makes you look at it in a more logical way then you previously did, at least this was true for this issue at this time.

So enters my second attempt to solve this issue.

The remaining culprit that enables one to detect the presence of VirtualBox through WMI(1) is the

As we have chosen not install VirtualBox Guest Additions, the device is missing it's driver (Error 28, I will come back to this one later). It is that device that is detected, DEV_CAFE. (If you need a quick fix goto 2.

My first thought was to ty to replace corresponding values in the registry, but that one did not work out either.

Microsoft Windows does not supply you with a command line option to install/remove/uninstall devices by default. They have however an application that is available in their Windows Driver Kit (WDK), called DevCon. 

DevCon sounded like the way to go, given the fact that I had to use a none pre-installed application anyway.

But once again, reality came repelling down the ceiling and smacked me in the head. DevCon was not able to remove a device that was not fully installed, remember the Error 28.

DevManView from Nirsoft(3) to the rescue! While DevCon was not able to remove the device, DevManView were!

So now that we have a working solution that we can script, it was time to figure out how to make it user friendly given that we have to use a 3rd party application.

The easiest way would have been to leave the "user" to move the application to the VM guest themselves... but why miss the opportunity to do something hideous?

So I decided to embed the binary in the batch script by Base64 encode DevManView.exe. The Base64 encoded part is then in the guest decoded, up on execution of the batch script.

I guess I could try to sugar coat this by pointing to the fact that it is a bit more user friendly..

Please remember to pick the version of DevManView corresponding to the guests O architecture.

An updated version of the script can be found at:

As always any kind of feedback is welcomed


(1) If you use previous versions of the antivmdetction script
(2) just right-click on the Base System Device and choose uninstall ;)

Friday, November 13, 2015

Cuckoo Sandbox API with Apache for Cuckoo 2.0

As Cuckoo 2.0 is soon (hopefully) moving from dev to stable, there is one change that is need to be performed in order to keep on using the API via Apache.

The change is only in the in api.wsgi. For the Apache configuration see previous post on the same subject.


import os
import sys


from api import app as application


All you need to do is to change the path to match your cuckoo installation


Friday, March 6, 2015

Modifying VirtualBox settings for malware analysis 2015 ed

I decided to update my script which has been previously published in blog format here.

Now it's located on Github which makes updates and usage much easier.


Friday, October 31, 2014

Cuckoo Sandbox API with Apache

This is yet another short Cuckoo post.

If you would like to quickly get the Cuckoo API to work with Apache this one is for you.

You can have both the API and the Web Interface configuration in the same webserver config.

Add the following to your chosen Apache virtualhost configuration (default, ssl)

 # Cuckoo API  
                WSGIDaemonProcess api user=<USER> group=<GROUP> processes=1 threads=5
                WSGIScriptAlias /api <PATH>/cuckoo/utils/api.wsgi process-group=api
                <Directory <PATH>/cuckoo/utils/>
                         WSGIApplicationGroup %{GLOBAL}
                        <Files api.wsgi>
                        Require all granted

In the Cuckoo utils directory create the file api.wsgi

# make wsgi enabled

import os
import sys

cur_dir = os.path.dirname(__file__)


import bottle
import api

application = bottle.default_app()

/Mikael @nsmfoo

Wednesday, August 6, 2014

Cuckoo Sandbox web interface with Apache

This is a short write-up of how you get the new Django web interface, that ships with current Cuckoo Sandbox working behind Apache.

As the documentation is thin and required some tweaking to get it to work, you might find it useful

The Django interface can be run as a standalone process, using the script, that one is well documented:

So to get it to work behind Apache I had to do the following:

Please note that this might not be the best way or if you plan to publish the web interface directly on the Internet it might also not suit your needs, that being said:

Begin with editing the file which can be found in cuckoo/web/web directory
Set the variable CUCKOO_PATH = "<path to cuckoo> (e.g: /home/user/cuckoo)"

Then continue to edit the file which also can be found in the cuckoo/web/web directory

From this:

               "import os

                     os.environ.setdefault("DJANGO_SETTINGS_MODULE", "web.settings")"

To look like this:

                     import os, sys

                    sys.path.append('<path to cuckoo>)
                   sys.path.append('<path to cuckoo>/web')
                   os.chdir('<path to cuckoo>/web/')

                 os.environ.setdefault("DJANGO_SETTINGS_MODULE", "web.settings")

Over to Apache.

Add the following lines to your chosen Apache virtualhost configuration (default, ssl)

 WSGIScriptAlias /  <path to cuckoo>/web/web/
        <Directory <path to cuckoo>/web/web>
                Require all granted

        Alias /static /<path to cuckoo>/web/static
        <Directory <path to cuckoo>web/static/>
                Require all granted

You will also need to change the user which Apache run as, this is to enabled the web interface to have access to temporary files created by Cuckoo. This is done in the file envvars (/etc/apache2/)

The variables to change are:


export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data


export APACHE_RUN_USER=<cuckoo user>
export APACHE_RUN_GROUP=<cuckoo user group>

The above changes should not be needed if you choose to change the path for the tmp files created by Cuckoo and give the default Apache user access to that directory. This change will have to be made both in cuckoo.conf and in the if you choose to do so.


Thursday, May 8, 2014

Installing Honeyproxy

Just a few quick notes on howto install Honeyproxy.

Honeyproxy which is based on mitmproxy is being re-integrated back into mitmproxy, currently there is no really good installation documentation, so here goes ..

This was tested on a Ubuntu 14.04 Desktop 64-bit.

apt-get install python-dev libxml2-dev libxslt1-dev lib32z1-dev python-pip git
git clone
cd mitmproxy
git checkout integrate_honeyproxy
git submodule update --init --recursive
pip install -r requirements.txt
pip install pyamf protobuf
python install
If everything worked out fine, you can start honeyproxy by running: mitmproxy-gui