Creating MHN Honeypots and Ingesting its Data with Splunk — Pt 2

Welcome to Part 2 of Creating MHN Honeypots and Ingesting its Data with Splunk. If you’re looking for how to get started, head over to Part 1.

As a reminder this blog is broken into a 2 part series covering the following :

Part 1

Section 1 — Getting your MHN Cloud Instance Up and Running on Digital Ocean

Section 2 — Installing and Configuring Splunk on your MHN Server

Part 2

Section 3 — Setting up your MHN Logging on your Splunk Server

Section 4 — Deploying your first MHN Honeypot

In the previous section, we got our MHN server installed and configured, as well as installed and configured Splunk . In this next section, we will work to get logging configured and deploy our first honeypot. So let’s get started with Section 3!

Section 3 — Setting up your MHN Logging on your Splunk Server

You should now have a Splunk service that’s started per instructions in Part 1. Next let’s login to our Splunk instance (if you haven’t already) and get logging set up.

• First we need to have MHN create a Splunk log file and ensure it will log to it. To generate a log file , follow the commands below on your MHN server terminal:

cd /opt/mhn/scripts
./install_hpfeeds-logger-splunk

Now log data from your MHN instance will be logged to

/var/log/mhn/mhn-splunk.log

Now let’s head back over to our Splunk web console which should be at (http://[your_mhn/splunk_ip]:8000) . We will now tell it where to find future MHN log data for future ingestion.

• Add data by selecting Add data on the main screen

• Select the Monitor method

• Select Files & Directories and navigate to the location of the Splunk log file of your MHN server. This will be in the /var/log/mhn folder. This is simply telling Splunk to monitor this file continuously and updating the Splunk indexer with data from MHN.

• From the source type section, you should be fine with keeping the default settings as I did.
• You will then save the source type any name you want, and provide a description. For this, I gave it a descriptive name “mhn” and I also changed the app to system. This will ensure the log data is available to the entire system.

For the remaining options such as input settings, I kept all the items as their default settings.

Then you're done! Splunk should be ready to go, and the very last part remains of deploying the honeypot!

Section 4 — Deploying your first MHN Honeypot

Now that we have our MHN and Splunk instance ready to go, it’s time to deploy a honeypot. For this, you will need to deploy another cloud server aka a Digital Ocean droplet(I will call this one the victim). I will deploy it in the same manner as I did my MHN server. However, after I’ve deployed the droplet, I will simply only have to run a few scripts to deploy the actual honeypot.

For my instance, I created a similar Ubuntu 18.04 instance on the cheapest plan within the same DC. However, you can always pick another DC location if you like. I also recommend naming this something to help to differentiate between your MHN/Splunk server and your newly created victim server. After creating the second droplet, I now have two droplets created in my Digital Ocean Dashboard. I utilized the tag feature to help remind me which server was for which purpose.

Now time to get the honeypot scripts deployed to the victim server!

1. Navigate to your MHN web console (http://[mhn –IP]) and identify the type of honeypots you want to deploy.
2. There are several you may be interested in and I recommend you take some time to research each to learn more. I opted for a few on one server. Being familiar with some of the technology, I thought this would help me paint a more holistic picture. I do plan to create an additional honeypot soon and capture some full network traffic!

A little background on the scripts I opted to deploy and test out:

• Snort will give me intrusion detection alerts on the activity it detects as threat actors attempt to attack my system.
• P0f will give me high-level passive network monitoring data that can help me gain more context around the snort alerts.
• Elastichoney is an elastic search honeypot that may catch adversaries who attempt to exploit RCE style vulnerabilities in elastic search instances. At least that’s what the threat actors may think this instance is!

Because your Splunk instance is setup all of these logs associated with these honeypots will automatically be ingested!

Now let’s deploy these scripts on the victim server!

• Head over to the deploy tab within your MHN web console and select the script you want to deploy first, in this example it will be the snort script. You be provided a script to run on you’re the victim server. Copy the deploy command script.

Next log into your victim server , and paste and run the deploy command script from MHN. Pending no installation issues, repeat selecting the other script from your MHN console, copy, and paste the deploy command script on the victim server.

To see if your sensors deployed correctly, on the navigation bar of you MHN web console, navigate to Sensors -> View Sensors. Below is an image showing my successfully deployed sensors to my server!

After you’ve completed running the deployment scripts of choice, and after you let some time pass head over to your Splunk web console to see what data has been ingested ( in my example below this was after about 15 hours!)

You can enter the following command to see a preview of your events:

sourcetype=[logsourcename]

You can also keep an eye on your MHN web console. This also provides very fruitful information on the attacks detected thus far by your honeypot!

There you have it! You have successfully set up your MHN honeypot with Splunk logging! I recommend letting it run for a day or so to get plenty of data you can dig into before destroying your victim server.

In upcoming posts, I’ll begin a profile series highlighting some interesting attacks I’ve seen on my instance, as well as digging into Splunk more to help me visualize and make sense of the data.

Thanks for reading!