# A Hacker's Guide to Building and Automating Security Tools

> Cuckoo Sandbox is an open-source project that allows you to run malware samples on safe virtual machines, and then analyze and report on how the malware behaved in the virtual…

Canonical: https://codelivly.com/a-hackers-guide-to-building-and-automating-security-tools
Last updated: 2024-07-19

| | |
|---|---|
| Category | [Cyber Security](https://codelivly.com/blog/category/cyber-security) |
| Author | rocky |
| Published | 2024-07-19 |
| Reading time | 6 min |

**Cuckoo Sandbox** is an open-source project that allows you to run malware samples on safe virtual machines, and then analyze and report on how the malware behaved in the virtual sandbox without the threat of the malware infecting your real machine. The application is written in **Python**, and **Cuckoo Sandbox** also offers **a REST API**. This allows a programmer using any language to fully automate many of **Cuckoo's** features, such as running sandboxes, running malware, and receiving reports. In this section, we'll do all of this using easy-to-use **C#** libraries and classes. However, there's a lot of work to do, such as setting up a virtual environment to use **Cuckoo**, before we can start testing and running malware samples using **C#**. You can find more information and download **Cuckoo Sandbox** at [https://www.cuckoosandbox.org](https://www.cuckoosandbox.org) /.

## Setting up the Cuckoo Sandbox

In this section, we will not cover setting up **Cuckoo Sandbox** as the instructions can vary greatly between operating systems and depending on which version of Windows you use as your VM sandbox. This section assumes that you have properly set up **Cuckoo Sandbox** with a **Windows** guest and that **Cuckoo is fully functional. Be sure to follow the instructions on the main Cuckoo Sandbox** website ( [https://cuckoo.readthedocs.io/en/latest/](https://cuckoo.readthedocs.io/en/latest/)) for up-to-date and detailed documentation on installing and configuring the software. In the **conf/cuckoo.conf** file that comes with **Cuckoo Sandbox**, I recommend changing the default timeout configuration to be shorter (I set it to 15 seconds) before you start working with **the API**. This will make testing easier and faster. In your cuckoo.conf file, you will see a section at the bottom that looks like the listing below.

![The default timeout configuration section in cuckoo .conf](https://codelivly.com/uploads/2023/blog-restored/b29b25a3b3-183-1024x164.png)

The default timeout for **Cuckoo** testing is set to **120** seconds **[1]**. A large timeout may make you impatient to see if you have fixed the problem while debugging since you will have to wait for the timeout to expire before the report is ready, but setting this value between **15** and **30** seconds should be useful for our target system.

**Launching the Cuckoo Sandbox API manually.**

Like **Nessus, Cuckoo Sandbox** uses the **REST** pattern (if you need a refresher, see the description of **REST** in section 5). However, **the Cuckoo Sandbox API** is much simpler than **the Nessus API, as we only need to interact with a couple of** **API** endpoints. To do this, we will continue to use the session/manager pattern and first implement the **CuckooSession** class, which defines how we will interact with **the Cuckoo Sandbox API**. However, let's check that you have configured **Cuckoo Sandbox** correctly before we start writing code.

**Launching API**

**Once Cuckoo Sandbox** is installed, you can run it locally using the **./cuckoo.py** command, as shown in the listing below. If you get an error message, make sure the virtual machine you are using for testing is running.

A successful startup **of Cuckoo** should result in a fun **ASCII** art banner appearing, followed by some quick information lines about how many VMs have been booted. Once the main script has started, **Cuckoo** needs to start **the API** that we will be talking to. Both of these **Python** scripts need to be running at the same time! The **cuckoo.py Python** script is the engine of **Cuckoo Sandbox**. If we run the **api.py** script without running the **cuckoo.py script, as shown in the listing below, our** **API** requests will do nothing. In order for us to use **Cuckoo Sandbox** from **the API, both** **cuckoo.py** and **api.py** need to be running. By default, **the Cuckoo Sandbox API** listens on port **8090**, as shown in the listing below.

![Running the HTTP API for Cuckoo Sandbox](https://codelivly.com/uploads/2023/blog-restored/cedbf4c8ad-185.png)

To specify **the IP** address to listen on (the default is **localhost**), you can pass **the -H** argument to the **utils/api.py** script, which tells **the API the IP** address to use when listening for **API** requests. In this case, we've set **0.0.0.0** as the listening **IP**, which means all network interfaces (both internal and external system **IPs**) will have port **8090** available for communication, since we're using the default port. **The URL** that **the Cuckoo API** is listening on is also printed to the screen after startup. This **URL** allows us to interact with **the API** to manage **Cuckoo Sandbox** in the rest of this section.

**Checking Cuckoo's Status**

We can test **the API** to make sure it's set up correctly using the **Curl** command-line tool, just as we did in previous sections for other **APIs**. Later in this section, we make similar **API** requests to create a task, watch it run until it completes, and create a file report to see how it behaved when it ran. But first, the listing below shows how to use **Curl to retrieve** **Cuckoo Sandbox** state information in **JSON** format using **the HTTP API**.

![Using curl to retrieve the Cuckoo Sandbox status via the HTTP API](https://codelivly.com/uploads/2023/blog-restored/6c93d19efd-186-706x1024.png)

The status information is quite useful and details many aspects of the **Cuckoo Sandbox** system. Of note is the aggregated task information **[2]**, which includes the number of tasks that **Cuckoo** has started or is running, along with their status. A task could be parsing a running file or opening a web page with **a URL**, although in this section we'll only look at submitting a file for analysis. You can also see the number of VMs available for analysis **[1]**, and the current version **of Cuckoo [3]**. Great, **the API is up and running! We'll use this same status** **API** endpoint later to test our code as we write it, and to discuss **the JSON** it returns in more detail. For now, we just need to confirm that **the API** is up and running.

That’s all. Have a nice day, everyone!

❤️ If you liked the article, **like and subscribe** to my channel **“ [Codelivly](http://t.me/codelivly) ”.**

👍 If you have any questions or if I would like to discuss the described hacking tools in more detail, then **write in the comments**. Your opinion is very important to me!