Cuckoo Sandbox 1.2 :
* Added Python analysis module
* Added analysis deletion to web interface
* Added machine information in reports
* Added un-hook (if malware removes cuckoo’s hooks) detection
* Added Microsoft Crypto API hooks
* Added process memory processing module
* Added support for more Volatility plugins
* Added more memory analysis information to web interface
* Added memory dump to vmware workstation module
* Added terminate_processes option to terminate processes before vm shutdown
* Added optional aggressive sleep skipping mode
* Added option to skip an area when comparing screenshots, avoiding duplicates
* Added automatic generation of yara rules indexes
* Added display of PE compilation time
* Added support for Pillow (PIL fork)
* Added search by string to web interface
* Added dynamic search of API call logs to web interface
* Added fix for SQLite database locks
* Added machine utility to automatically update machinery configuration
* Added physical machine analysis
* Added distributed analysis
* Adedd memory dump to mongo db
* Added loader option to DLL package
* Added additional signatures helper functions
* Allow Auxiliary modules to run a callback at the very end of an analysis
* Replaced ./utils/clean.sh with ./cuckoo.py –clean
* Replaced diStorm3 disassembler with Capstone disassembler
* Refactored analysis packages and simplified syntax
* Fixed process.py to use delete_original and delete_bin_copy when used in auto mode
* Fixed issue with tcpdump filters
* Fixed analysis of HTML pages without a proper extension
* Fixed logic bug in mouse activity emulator
* Fixed bug in the sleep skipping mechanism
* Fixed memory leak if using a old version of python-magic
* Fixed out of memory exceptions when calculating hash of big files
* Fixed BFP filter to skip agent traffic from PCAP
* Fixed a variety of bugs in Windows analyzer
* Fixed a number of anti-sandbox tricks
* Removed hpfeeds reporting module
Cuckoo Sandbox is an Open Source software for automating analysis of suspicious files. To do so it makes use of custom components that monitor the behavior of the malicious processes while running in an isolated environment.
+Installing the Agent
+From release 0.4 Cuckoo adopts a custom agent that runs inside the Guest and
+that handles the communication and the exchange of data with the Host.
+This agent is designed to be cross-platform, therefore you should be able
+to use it on Windows as well as on Linux and OS X.
+In order to make Cuckoo work properly, you’ll have to install and start this
+It’s very simple.
+In the *agent/* directory you will find and *agent.py* file, just copy it
+to the Guest operating system (in whatever way you want, perhaps a temporary
+shared folder or by downloading it from a Host webserver) and run it.
+This will launch the XMLRPC server which will be listening for connections.
+On Windows simply launching the script will also spawn a Python window, if
+you want to hide it you can rename the file from *agent.py* to **agent.pyw**
+which will prevent the window from spawning.
+If you want the script to be launched at Windows’ boot, just place the file in
+Creation of the Physical Machine
+Once you have :doc:
properly installed <../host/requirements> your imaging software
+software, you can proceed on creating all the physical machines you need.
+Using and configuring your imaging software is out of the scope of this
+guide, so please refer to the official documentation.
+ .. note::
+ You can find some hints and considerations on how to design and create
+ your virtualized environment in the :doc:
+ .. note::
+ For analysis purposes you are recommended to use Windows XP Service Pack
+ 3, but Cuckoo Sandbox also proved to work with Windows 7 with User
+ Access Control disabled.
+When creating the physical machine, Cuckoo doesn’t require any specific
+configuration. You can choose the options that best fit your needs.
+Preparing the Guest (Physical Machine)
+At this point you should have configured the Cuckoo host component and you
+should have designed and defined the number and the names of the physical
+machines you are going to use for malware execution.
+Now it’s time to create such machines and to configure them properly.
+Now it’s time to setup the network for your physical machine.
+Before configuring the underlying networking of the sandbox, you might
+want to tweak some settings inside Windows itself.
+One of the most important things to do is **disabling** *Windows Firewall* and the
+*Automatic Updates*. The reason behind this is that they can affect the behavior
+of the malware under normal circumstances and that they can pollute the network
+analysis performed by Cuckoo, by dropping connections or including irrelevant
+You can do so from Windows’ Control Panel as shown in the picture:
+ .. image:: ../../_images/screenshots/windows_security.png
+ :align: center
+Using a physical machine manager requires a few more configuration options than
+the virtual machine managers in order to run properly. In addition to the steps
+laid out in the regular Preparing the Guest section, some settings need to be changed
+for physical machines to work properly.
+ – Enable auto-logon (Allows for the agent to start upon reboot)
+ – Enable Remote RPC (Allows for Cuckoo to reboot the sandbox using RPC)
+ – Turn off paging (Optional)
+ – Disable Screen Saver (Optional)
+In Windows 7 the following commands can be entered into an Administrative command prompt to enable auto-logon and Remote RPC.
+ reg add “hklm\software\Microsoft\Windows NT\CurrentVersion\WinLogon” /v DefaultUserName /d <USERNAME> /t REG_SZ /f
+ reg add “hklm\software\Microsoft\Windows NT\CurrentVersion\WinLogon” /v DefaultPassword /d <PASSWORD> /t REG_SZ /f
+ reg add “hklm\software\Microsoft\Windows NT\CurrentVersion\WinLogon” /v AutoAdminLogon /d 1 /t REG_SZ /f
+ reg add “hklm\system\CurrentControlSet\Control\TerminalServer” /v AllowRemoteRPC /d 0x01 /t REG_DWORD /f
+ reg add “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System” /v LocalAccountTokenFilterPolicy /d 0x01 /t REG_DWORD /f
+Now you need to decide how to make your physical machine able to access Internet
+or your local network.
+While in previous releases Cuckoo used shared folders to exchange data between
+the Host and Guests, from release 0.4 it adopts a custom agent that works
+over the network using a simple XMLRPC protocol.
+In order to make it work properly you’ll have to configure your machine’s
+network so that the Host and the Guest can communicate.
+Testing the network access by pinging a guest is a good practice, to make sure the
+virtual network was set up correctly.
+Use only static IP addresses for your guest, as today Cuckoo doesn’t support DHCP
+and using it will break your setup.
+This stage is very much up to your own requirements and to the
+characteristics of your virtualization software.
+For physical machines, make sure when setting the IP address of the guest to also set
+the Gateway and DNS server to be the IP address of the cuckoo server on the physical network.
+For example, if your cuckoo server has the IP address of 192.168.1.1, then you would set the
+Gateway and DNS server in Windows Settings to be 192.168.1.1 as well.
+ .. image:: ../../_images/screenshots/windows_network.png
+In order to make Cuckoo run properly in your physical Windows system, you
+will have to install some required software and libraries.
+Python is a strict requirement for the Cuckoo guest component (*analyzer*) in
+order to run properly.
+You can download the proper Windows installer from the
+Also in this case Python 2.7 is preferred.
+Some Python libraries are optional and provide some additional features to
+Cuckoo guest component. They include:
Python Image Library_: it’s used for taking screenshots of the Windows desktop during the analysis.
+They are not strictly required by Cuckoo to work properly, but you are encouraged
+to install them if you want to have access to all available features. Make sure
+to download and install the proper packages according to your Python version.
official website: http://www.python.org/getit/
Python Image Library: http://www.pythonware.com/products/pil/
+At this point you should have installed everything needed by Cuckoo to run
+Depending on what kind of files you want to analyze and what kind of sandboxed
+Windows environment you want to run the malware samples in, you might want to install
+additional software such as browsers, PDF readers, office suites etc.
+Remember to disable the “auto update” or “check for updates” feature of
+any additional software.
+This is completely up to you and to what your needs are. You can get some hints
+by reading the :doc:
+Additional Host Requirements
+The physical machine manager uses RPC requests to reboot physical machines.
net command is required for this to be accomplished, and is available
+ from the samba-common-bin package.
+ $ sudo apt-get install samba-common-bin
+In order for the physical machine manager to work, you must have a way
+for physical machines to be returned to a clean state. In development/testing
+Fog (http://www.fogproject.org/) was used as a platform to handle re-imaging
+the physical machines. However, any re-imaging platform can be used
+(Clonezilla, Deepfreeze, etc) to accomplish this.
-The physical machine manager provides Cuckoo with the ability to
-communicate with, and run samples on physical sandboxes. This capability
-provides the ability to analyze malware that is capable of detecting whether
-or not it is being run in a virtualized environment.
-The physical machine manager uses RPC requests to reboot physical machines.
net command is required for this to be accomplished, and is available
– from the samba-common-bin package.
– $ sudo apt-get install samba-common-bin
-In order for the physical machine manager to work, you must have a way
-for physical machines to be returned to a clean state. In development/testing
-Fog (http://www.fogproject.org/) was used as a platform to handle re-imaging
-the physical machines. However, any re-imaging platform can be used
-(Clonezilla, Deepfreeze, etc) to accomplish this.
-Setup using Fog
-The Fog User Guide (http://www.fogproject.org/wiki/index.php/FOGUserGuide) is
-an excellent resource for setting up a Fog server to handle imaging computers.
-Upon setting up Fog, the general procedure for using physical machines as
-sandboxes is as follows:
– 1. Install OS onto computer
– 2. Install additional applications (Microsoft Office, Adobe Reader, Java, etc.)
– 3. Prepare the physical machine to run samples (see below)
– 4. Create new Image task in Fog
– 5. Reboot computer, upload image to Fog server
– 6. Configure Fog server to schedule a deployment of images (cron-style)
– 7. Edit cuckoo configuration file to include new physical machines
– 8. Run samples
-Preparing The Guest (Physical Machine)
-Using a physical machine manager requires a few more configuration options than
-the virtual machine managers in order to run properly. In addition to the steps
-laid out in the regular Preparing the Guest section, some settings need to be changed
-for physical machines to work properly.
– – Enable auto-logon
– – Enable Remote RPC
– – Turn off paging (Optional)
– – Disable Screen Saver (Optional)
-In Windows 7 the following commands can be entered into an Administrative command prompt to enable auto-logon and Remote RPC.
– reg add “hklm\\software\\Microsoft\\Windows NT\\CurrentVersion\\WinLogon” /v DefaultUserName /d <USERNAME> /t REG_SZ /f
– reg add “hklm\\software\\Microsoft\\Windows NT\\CurrentVersion\\WinLogon” /v DefaultPassword /d <PASSWORD> /t REG_SZ /f
– reg add “hklm\\software\\Microsoft\\Windows NT\\CurrentVersion\\WinLogon” /v AutoAdminLogon /d 1 /t REG_SZ /f
– reg add “hklm\\system\\CurrentControlSet\\Control\\TerminalServer” /v AllowRemoteRPC /d 0x01 /t REG_DWORD /f
– reg add “HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System” /v LocalAccountTokenFilterPolicy /d 0x01 /t REG_DWORD /f
-Setup using VMWare (Bonus!)
-Traditionally cuckoo requires the cuckoo server to be running some sort of virtualization software (e.g. VMware, Virtualbox, etc). This machine manager will also work with other virtual machines, so long as they are configured to revert to a snapshot on shutdown/reboot, and running the agent.py script. A use case for this functionality would be to run the cuckoo server and the guest sandboxes each in their own VM on a single host, allowing for development/testing of cuckoo without requiring a dedicated Linux host for cuckoo.
Intallation and download :
git clone git://github.com/cuckoobox/cuckoo.git
If you want to clone a specific branch:
git clone -b <branch name> git://github.com/cuckoobox/cuckoo.git