Honeypots mailing list archives

Nested honeypots


From: Nick Smith <nick.smith () telus net>
Date: Wed, 09 Jun 2004 11:51:38 -0700

Hi,

This thought popped into my head today while doing something completely
unrelated. I am sure that some of you have already thought of this, but
since I cannot it recall it being mentioned in the past, I thought that
I would float the idea...

So far, we have been using our honeypots to determine how attackers go
about exploiting normal systems. However, savvy attackers are now aware
of the existence of honeypots and are developing anti-honeypot
techniques. With this in mind, how about setting up a honeypot within a
honeypot (honeycrystal??? i.e. something even sweeter within the
honeypot) so that we can see how an attacker will behave once s/he
discovers that the resource that they are interacting with appears to be
a honeypot of some kind?

I'm not picking on honeyd, but it sprung to mind as an example because
its virtualization capabilies and because, being lower interaction, it
*might* be easier to fingerprint. The scenario would be something like:
Attacker is interacting with the virtual hosts created within honeyd.
Something causes attacker to become suspicious, which results in some
fingerprinting activity. Attacker concludes that honeyd is being used
and goes about either exploiting honeyd (not aware of any exploits, but
who knows) or directly attacking the host that honeyd is running on.
However, the system hosting honeyd is also a honeypot, so we get to see
what the attacker does once s/he thinks that they have bypassed honeyd.

The value of this may be more apparent when the attacker is using
encrypted sessions...

Taking this up a notch, how about using VMware. Guest OS is, say, RH 6.2
(with lots of low-hanging fruit) with sebek and modified bash. Attacker
compromises it and thinking how easy it was, decides to check whether
s/he has exploited a honeypot. Attacker discovers that the system is
indeed a honeypot and takes measures to neutralize our data capture
tools. Since the attacker is using an encrypted session, s/he thinks
that we are unable to see the commands s/he executes since our network
based capture tools will only see encrypted traffic. However, the VMware
host is also configured with the necessary data capture tools so,
unbeknown to the attacker, we can follow every action that they make. Of
course, the attacker might be really smart and decide to check out the
VMware host, in which case they would probably discover and neutralized
our data capture mechansims. However, by this time we may have captured
some new, important data that may help us to make our existing honeypot
techonologies more stealthy.

Cheers,


Nick


Current thread: