Honeypots Revisited

      22 Comments on Honeypots Revisited

I’ve written in previous posts about my honeypot setups and the visualization software that I use to display the data. You may also recall that I typically run my honeypots on underpowered cloud-based servers in an effort to keep costs low. This has caused a few issues at times. First of all, I’ve found that the various visualization software packages that I use tend to be sluggish when running on the same virtual server as my honeypots.

Another problem I’ve encountered occurs when an attacker figures out that my machine is a honeypot and he/she starts to DDOS me. The resultant log file growth will quickly fill your hard drive. Lastly, sometimes after your honeypots have been running for several months, you may just have collected too much data and your visualization software is behaving even more sluggishly.

Unrelated to the hardware specs of the virtual server, I’ve also had situations where the honeypot that I set up is not really capturing any useful data. I always get plenty of inquiries but sometimes I do not capture any binaries and that’s really the main thing I’m looking to do. Whatever the reason, I’ve found it to be good practice to reset my honeypots from time to time.

When I first started my honeypot journey, I would first install and configure the various honeypot software that I was using. After the honeypots were up and collecting data, I would next add the visualization software to the server. I used DionaeaFR to examine data from my Dionaea honeypot and Kippo Graph for my Cowrie honeypot.

This all worked out fairly well but setting up the visualization software was a somewhat tedious process especially if I had to rebuild my honeypot server with any regularity. Firstly, there were a lot of various dependencies that had to be installed. Secondly, and perhaps most troublesome, the visualization software is, for the most part, not being actively maintained (if it’s even maintained at all).

At first glance, this wouldn’t seem to be a big issue. After all, if the software works as expected what does it matter if it’s maintained? Problems come into play, though, because the dependencies are generally being actively updated. Because of this, every time you reinstall the visualization software, you face the possibility of there being one or more broken dependencies. You never know from one installation to the next what you might run into. At first, I tried to keep track of the versions of the various dependencies that were required to run the software but that just became too tedious.

The answer that I came up with was to split the two functions – honeypot data collection and visualization – onto two different computers. I still have my honeypots on a Digital Ocean droplet but I moved the visualization functions to a local VM on my home network (more detail on this in my next blog entry – coming soon). Now when I have to rebuild my honeypots, it’s a simple matter of creating a new droplet – which take just a minute or two – then installing the honeypots and their minimal dependencies. Here’s the procedure that I use.

Dionaea Installation
Dionaea is the easiest of the two to install. Again, I should note that I’m using Digital Ocean as my cloud server provider. I’m using the least expensive droplet ($5.00 per month).

1. Create a new droplet – be sure to select Ubuntu 14.04
2. Next, change the root password (see **side note below)
3. Now SSH into your droplet and run the following commands:

apt-get update
apt-get upgrade
add-apt-repository ppa:honeynet/nightly
apt-get update
apt-get install dionaea

4. Add your VirusTotal API key (if you have one) to:
/opt/dionaea/etc/dionaea/ihandlers-available/virustotal.yaml

5. Change to /opt/dionaea/etc/dionaea/ihandlers-enabled and use the following command to create a symbolic link to the file you just updated:

ln -s ../ihandlers-available/virustotal.yaml virustotal.yaml

6. Now start the service:
service dionaea start

That’s it. You should now have a Dionaea honeypot up and running.

Note: Unfortunately, Dionaea will not capture WannaCry or SambaCry traffic but it shouldn’t be long – see discussion here.

Cowrie Installation
The Cowrie install is a little more involved but is still pretty straightforward. This procedure mostly follows the steps in Michel Oosterhof’s (Cowrie’s creator) post here.

1. Install dependencies (note: this is all one line):

sudo apt-get install git python-virtualenv libmpfr-dev libssl-dev libmpc-dev libffi-dev build-essential libpython-dev python2.7-minimal authbind

2. Change the port that’s used for connecting and administering your SSH server. To do this, modify the sshd_config file like so:

nano /etc/ssh/sshd_config

(of course, you can use your preferred text editor – I prefer nano)

When you open the file, you’ll see near the top, the port that the SSH daemon is listening on (typically, its 22). Change it to something like 8925.

Now, you’ll need to restart the SSH service with:

service ssh restart

3. Create a user account. It’s strongly recommended to install Cowrie under a dedicated non-root user account. (note: those are 2 dashes before disabled-password)

sudo adduser –disabled-password cowrie

You’ll get this response:

Adding user `cowrie’ …
Adding new group `cowrie’ (1002) …
Adding new user `cowrie’ (1002) with group `cowrie’ …
Changing the user information for cowrie
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n]

Note, you don’t have to specify anything when the questions come up – just hit enter.

4. One problem that we’ll run into now is that you need to be root to listen on ports below 1024 and since we’re starting Cowrie as a non-root user, we’ll get an error. There are a couple of ways around this problem. We’ll use authbind to address the issue. The first part of the process is listed below. We’ll finish up the authbind setup as the Cowrie user.

touch /etc/authbind/byport/22
chown cowrie /etc/authbind/byport/22
chmod 777 /etc/authbind/byport/22

If you are going to use Cowrie to also capture Telnet data, then you’ll want to repeat the three commands above using port 23 instead of 22.

3. Login as the cowrie user and checkout the code:
We’ll perform the remaining steps as the user we just created.

su cowrie
cd

Next:

git clone http://github.com/micheloosterhof/cowrie
Cloning into ‘cowrie’…
remote: Counting objects: 2965, done.
remote: Compressing objects: 100% (1025/1025), done.
remote: Total 2965 (delta 1908), reused 2962 (delta 1905), pack-reused 0
Receiving objects: 100% (2965/2965), 3.41 MiB | 2.57 MiB/s, done.
Resolving deltas: 100% (1908/1908), done.
Checking connectivity… done.

cd cowrie

4. Setup and Activate Virtual Environment – this allows you to keep the required dependencies where they need to be without breaking anything else that may rely on other versions of the same libraries or tools.

$ pwd
/home/cowrie/cowrie

$ virtualenv cowrie-env
New python executable in ./cowrie/cowrie-env/bin/python
Installing setuptools, pip, wheel…done.

Activate the virtual environment and install packages:

$ source cowrie-env/bin/activate
(cowrie-env) $ pip install -r requirements.txt

5. Copy and modify the config file:

cp cowrie.cfg.dist cowrie.cfg

Now, edit the file and make a few changes:

nano cowrie.cfg

Look for the line that reads something like:
hostname = srv04

You’ll probably want to change it to something more enticing like:
hostname = accting01
or something like that.

Now, also in the cowrie.cfg file, let’s continue addressing the authbind config. Cowrie listens on port 2222 by default but we want to change it to 22 (the standard SSH port). Scroll down and look for the line that reads:

#Port to listen for incoming SSH connections.
#(default=2222)

Below this line, add:
listen_port = 22

Note that if you’re also capturing Telnet traffic with your honeypot, you’ll also want to change the listen_port in the Telnet section to 23

Save and exit.

One last thing to change – edit the /home/cowrie/cowrie/bin/cowrie file and change the second line to read:

AUTHBIND_ENABLED = yes
Now we should be ready to start Cowrie.

6. Starting Cowrie

Cowrie is implemented as a module for Twisted, but to properly import everything the top-level source directory needs to be in python’s os.path. This sometimes won’t happen correctly, so make it explicit:
$ export PYTHONPATH=/home/cowrie/cowrie

Start Cowrie as shown below. This will automatically start the virtual environment as well.

bin/cowrie start
Activating virtualenv “cowrie-env”
Starting cowrie with extra arguments [] …

From here you can exit as the cowrie user and exit from your virtual server.

At this point, you now have a Dionaea and a Cowrie honeypot running and capturing data on your VPS.

Here are a few places on your honeypot server to look for data:

Dionaea
/opt/dionaea/var/dionaea/binaries – Captured binaries
/opt/dionaea/var/dionaea/bistreams/YYYY-MM-DD – Session transcripts
/opt/dionaea/var/dionaea/dionaea.log – Dionaea’s text-based log file
/opt/dionaea/var/dionaea/dionaea.sqlite – Dionaea’s SQLite log file

Cowrie
/home/cowrie/cowrie/dl – Captured binaries
/home/cowrie/cowrie/log – .json log files
/home/cowrie/cowrie/log/tty – Session playback files

In the next blog entry, we’ll talk about how to visualize and utilize these data.

22 thoughts on “Honeypots Revisited

  1. Michael

    Nice article. Honeypots definitely need to be one of the tools deployed in an environment. I suggest looking into T-pot which contains docker versions of Dionaea, Cowrie and others as well as an ELK stack to visualize the data. http://dtag-dev-sec.github.io

    Reply
    1. executemalware@gmail.com Post author

      Thanks! I agree about T-pot – it looks really interesting. The only reason I haven’t done anything with it yet is due to server resource requirements. As I mentioned in my blog posts, I’m constrained to doing everything as cheaply as possible (at this point, anyway). I hope to check it out more fully at some point soon.

      I’m also starting to look at “dockerized” components in general for my low-end honeypots.

      I appreciate your comments and your interest. Best regards!

      Reply
  2. didz

    nice post.
    i’ve used both of them but i always ended up being scanned by bots and no binaries at all which is what i’m interested at. i might be doing something wrong though.

    Reply
    1. executemalware@gmail.com Post author

      I’ve had a similar experience at times as well. I’ve found that placing my Digital Ocean droplet in the Amsterdam space gets me a LOT of binaries.

      Reply
    1. executemalware@gmail.com Post author

      Thanks for taking the time to read and comment. Yes, I have tried MHN (you can read my notes in the blog entry on installing a Dionaea honeypot and also in the entry on DionaeaFR).

      The primary reasons I didn’t stay with it are: 1.) I didn’t care for the interface – no ability to drill down into the data. 2.) The overheard used by the management components seemed to be just enough to cause some sluggishness on my low-end VPS and 3.) I had many instances where I wasn’t catching any binaries in my Dionaea honeypot when I set it up with MHN. It seems strange and I don’t get why this was the case but I also read about others who had the same experience.

      Thanks also for the mention of the https issue – I’ll investigate.

      Reply
  3. malwareandpickles

    Great write-up. Never used Dionaea before so spinning up one of those. There is a small typo found in the command add-apt-respository ppa:honeynet/nightly, which I found out, as a member of the copy-paste brigade.

    Reply
    1. executemalware@gmail.com Post author

      Dionaea is really quite nice. I’ll be updating my blog entry on visualizing honeypot data within the next couple of days.

      Thanks for the catch on the typo – I’ll correct it right away.

      Let me know (via Twitter preferably) if you have any Dionaea questions and I’ll try to help if I can.

      Reply
  4. Cesar Diaz

    Great guide. I got Dionaea running in about 5 minutes. Did you have to do any port forwarding to get traffic to privileged ports like 22 and 25 to accept traffic to the honeypot and not the server itself?

    Reply
    1. executemalware@gmail.com Post author

      Thanks!
      No, I didn’t have to do any port forwarding at all. Dionaea just seems to pick up those ports with no problems by default. Are you not seeing traffic to those ports?

      Reply
  5. Luv Ahuja

    Hi all
    Have you guys catching any threats in above honeypot?

    I am planning to deploy this at service provider?

    Reply
    1. executemalware@gmail.com Post author

      Hello – sorry for my delay in responding.

      I catch quite a few binaries in both my Cowrie and Dionaea honeypots. Usually, they’re basic (popular) variants of whatever is making the rounds but every now and then I catch some interesting ones.

      I’m generally using standard, out-of-the-box configurations but I think that with some tweaking, they could be made to try to attract specific attacks (like the latest SMB attacks, for instance).

      Good luck!

      Reply
  6. Billy

    Hi,

    Nice tutorial. But in the process of Cowrie install, after command bin/cowrie start I’ve got message: command not found. Same command on cowrie user get message: permission denied.

    I would like to thank you for the great tutorial. I have been suffering from MHN and Dionaea for weeks. I took advantage of your tutorial and after a dozen hours I have a lot of malware caught.

    You’re right. Dionaea of MHN sucks fo now.

    Reply
    1. executemalware@gmail.com Post author

      Thanks – I’m glad I could help.

      Have a look here – Michel Oosterhof (author of Cowire) has updated his installation instructions recently. Maybe something in there will help.

      MHN really has the right idea and Jason Trost has worked hard on it but it just seems to fall short for now. I tried it again this week and had the same experiences as before.

      Good luck!

      Reply
  7. Luv Ahuja

    Hello

    Not a problem mate however it appears you have collected some of the binaries related to SMB (WannaCry Ransomeware) with cowrie and dionaea honeypot? Correct me if I’m wrong?

    Please help us to understand architecture deployment of such honeypot?
    we are probably thinking to deploy them on gateways using honeydrive or ubuntu platform?
    If you can help me with the configurations needed for deploying such honeypot so that we can catch threats and binaries and can help pubically to the people?

    Reply
    1. executemalware@gmail.com Post author

      While I routinely log SMB in my Dionaea honeypot I have not actually captured binaries related to WannaCry. I’m currently investigating this Dionaea fork:
      https://github.com/gento/dionaea

      which claims that ability.

      Feel free to DM me on Twitter with any further questions – @executemalware .

      Good luck!

      Reply
  8. someguy

    I made a quick script that will let you catch wannacry with MHN default dionaea install.
    This is a script based on other scripts but can deploy a HP in 10 minutes on digital ocean.
    You can take off snort and p0f if you want but i like to keep it on.

    make a .sh
    *change the ip address to your mhn server*

    1)nano install.sh
    2)past script below
    3)save file

    bash install.sh
    ^to run

    Script is below

    # Update
    sudo apt-get update
    sudo apt-get upgrade

    # Get dionaea

    wget “http://putyourmhnserveriphere/api/script/?text=true&script_id=2” -O deploy.sh && sudo bash deploy.sh http://putyourmhnserveriphere QViGmo2N

    # get p0F

    wget “http://putyourmhnserveriphere/api/script/?text=true&script_id=16” -O deploy.sh && sudo bash deploy.sh http://putyourmhnserveriphereQViGmo2N

    # get snort

    wget “http://putyourmhnserveriphere/api/script/?text=true&script_id=3” -O deploy.sh && sudo bash deploy.sh http://putyourmhnserveriphere QViGmo2N

    # update curl, if you dont do this you will not catch binaries properly#

    #! /usr/bin/env bash

    # Install any build dependencies needed for curl
    sudo apt-get build-dep curl

    # Get latest (as of Feb 25, 2016) libcurl
    mkdir ~/curl
    cd ~/curl
    wget http://curl.haxx.se/download/curl-7.50.2.tar.bz2
    tar -xvjf curl-7.50.2.tar.bz2
    cd curl-7.50.2

    # The usual steps for building an app from source
    # ./configure
    # ./make
    # sudo make install
    ./configure –prefix=/usr
    make
    sudo make install

    # Resolve any issues of C-level lib
    # location caches (“shared library cache”)
    sudo ldconfig

    # remove smb files

    rm /usr/lib/dionaea/python/dionaea/smb/smb.py
    rm /usr/lib/dionaea/python/dionaea/smb/include/smbfields.py
    rm /usr/lib/dionaea/python/dionaea/util.py

    cd /usr/lib/dionaea/python/dionaea/
    wget https://raw.githubusercontent.com/gento/dionaea/17da8e1590f0318f66de47c10e7ed8b43548cadb/modules/python/scripts/util.py
    cd /usr/lib/dionaea/python/dionaea/smb/
    wget https://raw.githubusercontent.com/gento/dionaea/17da8e1590f0318f66de47c10e7ed8b43548cadb/modules/python/scripts/smb/smb.py
    cd /usr/lib/dionaea/python/dionaea/smb/include/
    wget https://raw.githubusercontent.com/gento/dionaea/d17ebf359f71b8e53c42a943dccba1e623a9e278/modules/python/scripts/smb/include/smbfields.py

    curl -V
    echo “Make sure curl says 7.50!”

    echo “Script is done!”

    echo “Change the timezone!”

    sudo ufw disable

    #changes time zone so you know the right time binaries hit your pot
    sudo dpkg-reconfigure tzdata
    sudo supervisorctl status
    echo “Services should show running now, and ready to catch malware!, reboot first!”
    sudo reboot

    Reply
    1. executemalware@gmail.com Post author

      Nicely done!

      Incidentally, the SMB changes that were made by @gento_ to allow for capturing WannaCry have been rolled into this Dionaea repository: https://github.com/DinoTools/dionaea

      As far as I know, it’s the only full Dionaea repository that’s still active.

      As I’ve mentioned in previous blog posts, MHN has a bit too much overhead for my under-powered Digital Ocean droplets. I’m also not a big fan of the MHN interface. I’m not sure why, but like many others, I’ve also had trouble capturing binaries with MHN.

      Thanks for your work!

      Reply
  9. Binaryheadache

    Thanks for the write up. A good reference. I just finished setting up a small network of pots myself and am using AWS as well as some RaspberryPis. I collect my data to MHN but that then feeds a Splunk instance on the same VPS. Here’s a screenshot of the overview: http://i.imgur.com/7TcIwf9.png
    This is shows data for 2 dionaea, one p0f, and one cowrie instance..

    Gives you the ability to drill down and create custom queries etc. Also adds links to Virustotal for collected samples. Just sharing some info. Setup details here https://www.anomali.com/blog/splunking-the-modern-honey-network-getting-value-from-your-honeypots-data-part-1

    Reply
    1. executemalware@gmail.com Post author

      Very nicely done! It’s always interesting to see what people are doing with their data. I’m still trying to find the best way to display mine. New post on visualization coming very soon (hopefully today).

      Thanks!

      Reply
  10. Ashley Glenday

    A quick gotcha for anyone trying to set up cowrie now using the instructions from the article (by the way, great article).

    listen_port line has been replaced with listen_endpoints.

    I followed the instructions on the page and couldn’t connect to the honeypot to test until I read the commend above the listen_prot line.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *