Playing with honeypots: part 1

I've been interested in honeypots for some time and, having recently set up an Office 365 environment with an Azure subscription, I decided to spin up a honeypot in an Azure VM and see what nasties came my way.  First though, I need to explain what a honeypot is and why they're useful.

What is a honeypot?

A honeypot is a system that's been set up in an environment but for which there is no legitimate traffic.  Its purpose is to exist and never be touched by a legitimate user (or by a user for a legitimate purpose).  When you've deployed one you generally don't shout about it, it just sits and runs.  Few people know of the honeypot's existence and there's no real data or services there for the majority of an organisation's users.

Because there's no legitimate traffic we know that anything touching the honeypot is malicious.  Obviously there are different classes of malicious traffic:

• Curious legitimate users
  Your organisation's staff notice a system on the network and curiosity gets the better of them.  They have a look and probably then do nothing[1]
• Malicious legitimate users
  The insider threat.  A member of staff looking to do the organisation harm and stumbles into the honeypot.  This user is potentially very dangerous as they already have more access than an outside intruder
• Curious illegitimate users
  Someone outside of your organisation stumbles on the honeypot.  They're not looking to do anything nasty, they're just looking around.  More likely to occur for Internet published honeypots (otherwise why and how are they on your network?!)
• Illegitimate, malicious users
  People outside your organisation that are intent on doing you harm - data theft, using you as a jump point for further attacks etc.

For the purposes of this post series, I'm going to refer to someone interacting with the honeypot as an attacker.

What do they look like?

That's a bit like asking what a person looks like - a honeypot's looks vary.  You could deploy a physical device to be your honeypot - a Raspberry Pi would be a low cost option to do this.  Alternatively the honeypot could be a virtual machine (VM), as it is in my case.

In terms of what a honeypot looks like on the network, they almost certainly won't advertise the fact they are honeypots - that would defeat the point.  You configure a honeypot to look however you want, running whatever services you want and holding files you think may be of interest.

What's a honeytoken?

Similar to honeypots, there's no legitimate access to a honeytoken, which could be a file or a record in a database.  The token is planted and access to it is audited to detect who is nosing around.  Potentially there's an ethical quandary here, as the token is placed in areas legitimate users work (for example a file called BonusPayments.xlsx in the staff shared drive, or a database record for a famous person), so you could argue there's an element of entrapment here.  A honeypot is more covert, so the ethics are somewhat clearer.

Honeypot types

Honeypots can be grouped into interaction levels based on how much they emulate a real system.  Obviously you could run a full system as a honeypot, for example a full copy of Windows Server, and that would be termed a pure honeypot.  In terms of my use case that was overkill.

A low interaction honeypot will simulate the services that you've chosen.  It might indicate that it's listening and accepting connections on a port, perhaps pretending to be an SMTP (email) server on TCP port 25, but wouldn't do anything further.

Medium to high interaction honeypots provide a more complete environment for an attacker.  By providing an immutable interactive environment the attacker could spend more time looking around, potentially giving network defenders longer to detect and resolve their security problem.

Can honeypots be detected?

It's definitely possible to detect a device is a honeypot although how easy that is can vary.  If you build your honeypot using a piece of software and then leave the defaults in place an attacker gaining access would be able to tell the system was identical to others they'd probed.  Detection may not be a concern - it depends on the purpose you created the honeypot for.

But why use a honeypot?

Probably the biggest question - why?  There's a few reasons and I've already alluded to one: attackers wasting time.  You could deploy honeypots in your production environment in the hope an attacker will find them, spend time examining them, and then get caught / locked out by the defence team who have had time to track them down.  Another advantage is that your real systems aren't being touched because the attacker is focussing on the honeypot.  Sadly this seems statistically unlikely to me - in a production environment with perhaps one honeypot for every fifty real servers you'd have to be very fortunate if the attacker stumbled on your honeypot.  Plus it's not unusual for an attacker to be working on multiple systems at once.

Next up there's honeypots as an early warning system.  Suppose you have honeypots with IP addresses mixed in with your production environment.  If an attacker were to scan your network they would trigger alerts from your honeypot because there's no legitimate traffic for them.

Lastly: research, which is what I'm interested in here.  My honeypot is running in Microsoft's Azure cloud environment which is isolated from all of my systems.  Attackers can interact with my honeypot as much as they like but doing so won't warn me of a risk to my production environment.  What I do get though is logs, so I can see what's happening.

What's next?

This is a brief series of blog posts so in part two I'll describe how my honeypot is set up.  Once the honeypot has been running for a while I'll investigate the traffic that's hit the honeypot (it must be malicious traffic) and see what conclusions I can draw from the exercise.

Banner image: MIELE by dordy on OpenClipart.org (modified)

[1] They might contact IT about "this thing I've found, what's it for?" but that's not the end of the world.