Building a malware research and honeypot lab from scratch

I recently started to dive into threat intelligence and malware analysis. I’ve already written something about the setup I use to monitor Wordpress attacks in a previous post (How I capture and monitor Wordpress attacks). But this setup was only able to register simple web application attacks and it missed a proper logging mechanism. So it was time to build something better.

Building

I started this project shortly after the WannaCry mess so it was obvious for me to build this setup around an ETERNALBLUE honeypot. As with the Wordpress honeypot, I planned to use real-world honeypots instead of crafted ones so I won’t miss anything.

Using a real-world honeypot has a significant drawback. If an attacker has successfully compromised the honeypot he can basically do anything he wants. So it is necessary to focus on restricting the attacker’s actions to a minimum — sufficient to let them in but too little to cause any significant harm.

To achieve these goals I relied on sandboxing and network isolation. The lab is entirely virtualized which serves as the basic sandboxing. The following graphic shows the schematic setup:

The key parts of the setup are two separate virtual machines. One serves as a router and another serves as a sinkhole which will later receive all network traffic. The two VMs are connected via one isolated network. There is another isolated network for the honeypot VMs. The connection between these two isolated networks is the router VM. The router will reroute all outgoing traffic to the sinkhole. This is done by a simple direct firewall-cmd rule:

$ firewall-cmd --permanent --zone=lab-intern --direct --add-rule ipv4 nat PREROUTING 0 -p tcp ! -d 192.168.0.0/16 -j DNAT --to-destination <sinkhole-ip>
$ firewall-cmd --reload

Additionally, the router forwards specific ports from the honeypot VMs to so-called endpoints. These endpoints are distributed over the internet and expose the honeypot ports to the outside world. This has the advantage that I can easily add new endpoints and IPs to my lab without having to modify something.

The sinkhole VM has several services (mainly written in python) installed which will receive and log all the outgoing traffic. There are (at the time of writing) three different services:

• A DNS server which anwers all requests with a static IP address — based on FakeDNS by Crypt0s (https://github.com/Crypt0s/FakeDns)
• A HTTP server which logs and responds to all requests — based on the python HTTPServer.
• A dummy service which currently listens on all other ports.

Logging

With the basic setup finished it is now time to setup the logging capabilities. For large scale log gathering and analysis, I would always choose an ELK (Elasticsearch, Logstash, and Kibana) stack. One powerful addition to this stack are the so called beats. Beats are small and lightweight services that parse logs and feed them directly into Logstash. Logstash then processes and enriches the data and stores it in Elasticsearch.

Because I am lazy I simply grabbed a prebuild docker ELK stack (https://github.com/deviantony/docker-elk.git). I just needed to modify the Logstash pipeline a bit to match my needs and everything is fine.

As mentioned above I wanted to build a honeypot that captures the ETERNALBLUE exploit and gathers information about used payloads and attack origins. But how can we achieve this?

At first I setup a basic Windows 7 installation (missing the critical MS17–010 patch). Then I installed Sysmon on it. Sysmon is a Windows Sysinternals tool by Microsoft which enables us to log various Windows events like process starts, network connections, file creation, registry modification, etc. This comes in handy when we want to check which processes were started and which files were created during a compromise. Sysmon can be found here https://technet.microsoft.com/en-us/sysinternals/sysmon.

To work Sysmon needs a more or less complicated configuration of what events it should log. Some events may cause a lot of log entries and can cause a high system load. I used the awesome config by SwiftOnSecurity (https://github.com/SwiftOnSecurity/sysmon-config) which I modified a bit to get a better attack coverage.

With this it is possible to activate Sysmon:

> Sysmon64.exe -accepteula -i sysmon-config.xml

Sysmon logs its events in the Windows Event Log. I setup a Winlogbeat (https://www.elastic.co/de/downloads/beats/winlogbeat) to read these events and forward them to my ELK stack. Let’s go hunting…

Hunting

Now comes the most interesting part: the hunting. After I started the lab it only needed a couple of minutes to capture the first attacks:

But unfortunately, my setup had a major problem. I had to manually extract potential payloads from the VM and save them for further analysis. With a number of attacks currently occurring this would be very time-consuming. So I decided to automate this process.

At first, I wrote a python script which regularly queries Elasticsearch and looks for new interesting events (like file creation, process start, etc.). When the script recognizes a new event it downloads the specific file from the honeypot VM and saves it for further analysis. To make it possible to download any file from the honeypot VM I wrote a little web server in PowerShell (… yes that is possible :D). The web server allows the monitor to download any file from the honeypot VM. After the IOCs are downloaded the VM is reset to a snapshot and restarted.

As for now, I have already captured around 15 different WannaCry instances and a couple of other payloads:

The attacks have origins from all over the world:

The next step is to extend my lab with other vulnerable systems and improve the logging of outgoing traffic. The hunt goes on :)