Testing honeypots using Multipass

It's sometimes useful to test our honeypots using a local (on your laptop) virtual host. Multipass (and these instructions) make that super-easy

This tutorial is intended to help you in your early stage evaluations of our platform; you want to see what we can do, but you don't want to introduce our software into your environment just yet.

So, the perfect solution would be to somehow spin up a virtual server to act as a host, and deploy our seeds to it. Even better would be if this is totally under your control, no need to sign contracts, engage your support teams or suppliers, etc.

In this situation, we would recommend using Multipass (https://multipass.run/). This is a free and open source solution by Canonical that allows you to spin up local instances of Ubuntu with a single command, on your worktop (windows or mac). You could also choose to do the same thing using Virtualbox or UTM or similar, but I personally think Multipass is the easiest.

Just follow the steps below:

Prerequisites

These instruction are written with the following prerequisites assumed to be in place:

• You have already created your seedata.io account (instructions for this are available here: Quick Start)

• You have internet access from the device you are using

• You have sufficient privileges on your device to install new software

Step 1: Install Multipass

Follow the default instructions for installing Multipass, based on your operating system

These are available here: https://multipass.run/install

Step 2: Provision your virtual host

Launch a command prompt / terminal session on your device, and type the following;

$ multipass launch

This will create your new virtual host, using the default image and a random host name provided by multipass. If you want to exercise more control over the host creation, there are a wide range of parameters you can specify (read more here: https://multipass.run/docs/create-an-instance)

Next, you need to access your new host, as all future commands will be run on it (rather than on your device). Type the following command to get a shell on your new host, where <instance-name> is the name of the instance you previously created

$ multipass shell <instance-name>

Step 3: Configure the network on your new host

All the following commands will be run on your new multipass instance

Find your current network details

First, find out the name of your network interface card (NIC) and IP address

$ ip a

this will give you a reply that looks something like this

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:96:1c:ba brd ff:ff:ff:ff:ff:ff
    inet 192.168.64.112/24 metric 100 brd 192.168.64.255 scope global dynamic enp0s1
       valid_lft 86228sec preferred_lft 86228sec
    inet6 fd52:fcf:d0fd:2627:5054:ff:fe96:1cba/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591892sec preferred_lft 604692sec
    inet6 fe80::5054:ff:fe96:1cba/64 scope link 
       valid_lft forever preferred_lft forever

From the response above, I can see my NIC name is "enp0s1" and my IP address in "192.168.64.112". your details will be in the same place (part of section in the reply)

Find a free IP address

You need to know an IP address is available before you go binding it to your new virtual host. You can do this by choosing the next IP address upwards from your current one (so, in my example, 192.168.64.113) and send a ping to see if anything replies

$ ping 192.168.64.113

You will get a timeout if the IP address is available, and you can use it in the next step. If something actually responds to the ping, try the next IP address upwards (just increase the last octet by 1) until you get a timeout

Create the netplan config file

Now you're going to do the most complicated bit of the whole process (and it's not that complicated). You're going to add the additional IP addresses.

Type the following command, to create a new netplan config file and edit it in vi:

$ sudo vi /etc/netplan/99-custom-iface.yaml

Within vi, enter insert mode (push "i"), and paste the code below, making sure to change the IP address one that you know to be empty (do a ping test first), and the NIC to be the same name as yours

network:
    version: 2
    renderer: networkd
    ethernets:
        enp0s1:
            addresses:
            - 192.168.64.113/24

if you want to add more than one (a good idea), you can repeat the last two steps and add further lines to the end of the netplan file. For example

            - 192.168.64.114/24

Then apply the changes with the following command

$ sudo netplan apply

You may get some warnings about permissions (these can be ignored), but you may also get a fail message with an explanation.

IMPORTANT: The indentation of the netplan file is critical. you must follow the exact layout as above or it wont work. Hidden spaces and line returns are a nightmare here, so be patience and diligent in equal measure

Finally, once the netplan has applied successfully, confirm the new IP addresses are available on your NIC, with the following command

$ ip a

The response will be longer this time, and show secondary IP addresses added to your NIC

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:96:1c:ba brd ff:ff:ff:ff:ff:ff
    inet 192.168.64.113/24 brd 192.168.64.255 scope global enp0s1
       valid_lft forever preferred_lft forever
    inet 192.168.64.114/24 brd 192.168.64.255 scope global secondary enp0s1
       valid_lft forever preferred_lft forever
    inet 192.168.64.112/24 metric 100 brd 192.168.64.255 scope global secondary dynamic enp0s1
       valid_lft 86389sec preferred_lft 86389sec
    inet6 fd52:fcf:d0fd:2627:5054:ff:fe96:1cba/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591991sec preferred_lft 604791sec
    inet6 fe80::5054:ff:fe96:1cba/64 scope link 
       valid_lft forever preferred_lft forever

Step 4: Deploy a honeypot seed

Rather than repeat the instructions for this step, I'll guide you to read them here: Planting a VM honeypot seed

Step 5: Simulate an event

Now, we revert back to your device (so, not the multipass instance), and we're going to make a network request of the honeypot.

You can do anything you like here, provided it interacts with the honeypot, so make sure you are using the IP address that you deployed the honeypot on to. Some examples that work well are as follows

Send a curl command

Type the following command into your terminal/cmd prompt (replacing <seed-ip-address> with the IP address that you deployed the seed to):

$ curl -i -H "Accept: application/json" -H "Content-Type: application/json" -X GET http://<seed-ip-address>

Make a HTTP request

Go to a browser and type the seed IP address into the address bar

Create an SSH connection

Go to terminal/cmd and open an SSH connection with the following command (replacing <seed-ip-address> with the IP address that you deployed the seed to):

$ ssh admin@<seed-ip-address>

Perform a port scan

Using an application such as NMAP (see more here: https://nmap.org/) you can scan the seed IP address and get a report of which ports are open / blocked / filtered

Step 6: Review alerts and intel

After you have interacted with the seed, you should see two things happen:

• Any alert recipients you have configured on seedata.io (such as email, slack, jira, webhook, etc) should be fulfilled in line with their parameters

• New events should be visible on the seedata.io platform (this will also be linked to by the alerts described above).