Monday, October 25, 2021


 It's been a few years since I used this blog. I thought I should, going forward write some semi recurring posts about random things that I spend about an hour on (mostly because that's about the time I have for random things)

I do learn rather easy, but I "forget" as easily as well, at least if I don't use the knowledge on a more day today basis. 

During the days "reversing" mostly stops with C2 info and some characteristics as that's what needed and because there is tons of other things to be looked at.... Hopefully, given a few "hours" I will refresh some knowledge at least...

I picked a random sample to look at for my first post.

- Sample Name: vbc.exe

- SHA1: 5a4a29b0980ea0b5b42da76d878102bf7a00807e


If we start off with running the sample in a controlled environment. Tracking all the changes made to the filesystem and traffic generated, we can quickly see that it (the sample) tries to reach out to the following domain:   (

This domain is also later visible during debugging.

During execution the original sample is deleted and move to a hidden folder under the users %APPDATA%\Roaming\<"random named catalogue, six characters"> folder, more on that later on.

By looking at the API imports we could have guessed that something like that was able to happen:

MoveFileA and DeleteFileW    

The sample was not stripped of it's debug information so we can learn the following:

Age: 19

Timestamp: Sun Sep 26 22:56:51 2021 (For reference the compiler timestamp says: Mon Jan 25 04:24:02 2021, so possible time stomping in play)

 PDB path: c:\vobevipusilolo59.pdb

This sample applies a variety of anti debugging measures, like:

RaiseException, GetTickCount, IsDebuggerPresent, UnhandledExceptionFilter etc

The value from which the "moved" sample and directory got it's name from (it's most likely derived from the infected host)


Although visible in the traffic from the malware infection, performed earlier it's also rather easy find the same User Agent information during debugging:


And given the UA, it point's to this sample being LOKI.

Besides the above, here is a long list of software that is being targeted, probably corresponds to all possible variants of certain software types found on =)


  • Comodo IceDragon
  • Maple Studio Chrome Plus
  • Google Chrome
  • Nichrome
  • RockMelt
  • Spark
  • Chromiu
  • Titan Browser
  • Torch
  • YandexBrowser
  • Epic Privacy Browser
  • CocCoc Browser
  • Vivaldi
  • Chromodo
  • Superbird
  • Coowon
  • Mustang Browser
  • 360Browser
  • Citrio
  • Chrome SxS
  • Orbitum
  • Iridium
  • Opera Next
  • Sleipnir
  • Firefox
  • SeaMonkey
  • Flock
  • K-Meleon
  • BlackHawk
  • Cyberfox
  • Pale Moon
  • Lunascape

Mail clients:

  • Thunderbird
  • PostBox
  • FossaMail
  • Foxmail
  • IncrediMail
  • Outlook 

FTP/SCP/SSH Clients:

  • 32-Bit-FTP
  • BitKinex
  • BlazeFtp
  • ClassicFTP
  • Cyberduck
  • EasyFTP
  • ExpanDrive
  • Far
  • FileZilla
  • FlashFXP
  • Fling
  • FreshFTP
  • FTPBox
  • FTPGetter
  • FTPInfo
  • FTP Navigator
  • FTP Now
  • FTPShell
  • DeluxeFTP
  • GoFTP
  • AbleFTP
  • JaSFtp
  • LinasFTP
  • MyFTP
  • NetDrive
  • NETFile
  • NexusFile
  • NovaFTP
  • Notepad++
  • Odin Secure FTP Expert
  • KiTTY
  • PuTTY
  • SecureFX
  • SftpNetDrive
  • sherrod FTP
  • SmartFTP
  • Staff-FTP
  • Syncovery
  • Total Commander
  • UltraFXP
  • WinFtp Client
  • WS_FTP
  • Xftp

This was about all I was able to get out of the sample during my "hour", obviously LOKI does a lot more.


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.